Saturday, June 05, 2004
Leveraging storing objects in a database
So, since I now have this handy way to magically pull objects from the database, I've started reconsidering how I'm designing what I'll call my "entrance" points. e.g. to edit client 10, the old fashion was to go to http://purplefurfle/lawoffice/admin/addClient/10. Under the new system, you go to http://purplefurfle/lawoffice/clients/10.edit() -- this seems like an insignificant difference, until you realize that 'clients/10' maps a portion of the URL to an object stored in the database. The system deserializes the object stored at that reference and then calls its "edit" method. The "edit" method then uses Cocoon's standard pipelines to interact with the user. So what have we gained here? We have a greater sense of object-oriented programming -- the logic for editing clients is now stored in the ClientJSBean object itself, rather than some random JavaScript file, and have separated two concerns: manipulating the data and accessing it in the backend.
I was feeling quite smug, until I realized there were some major issues with this. For example, let's say client 6 has a file associated with him. Call it file 3. How do I invoke methods on file 3? You see, at present, 'clients/10' identifies the resource labelled '10' in the collection labelled 'clients'. The file objects are stuffed away somewhere deep inside the '10' resource's XML structure. So we can invoke methods on the client object, since he's at the root of the XML structure, but invokng methods on his contained items is much more difficult. -- sure, we can deserialize the client himself, which will then deserialize his related children, pull the child out in some convoluted fashion, and invoke methods on that, but then how does he know where to store himself?
We could perhaps make the Serializer store arrays as subcollections, and items in arrays as resources within those subcollections.
A downside of this, is we lose part of the structure that storing data in an XML file gives us, namely the natural ordering of elements. An XML file is easily ordered from the top down, but an entire collection tree traversal? I could settle on doing pre/post/in-order traversals, but I'll still need to pick a standard for ordering resources within a collection. No matter how you cut it, I lose some ordering capabilities. Mildly annoying.
An upside of this is that if we made the (Des|S)erializer smart enough, we could allow for granular locking of resources, and minimize database transaction activity.
Blargh, this will take some time to implement... Ah well, it will be a very nice foundation to work with when it's all done.
I was feeling quite smug, until I realized there were some major issues with this. For example, let's say client 6 has a file associated with him. Call it file 3. How do I invoke methods on file 3? You see, at present, 'clients/10' identifies the resource labelled '10' in the collection labelled 'clients'. The file objects are stuffed away somewhere deep inside the '10' resource's XML structure. So we can invoke methods on the client object, since he's at the root of the XML structure, but invokng methods on his contained items is much more difficult. -- sure, we can deserialize the client himself, which will then deserialize his related children, pull the child out in some convoluted fashion, and invoke methods on that, but then how does he know where to store himself?
We could perhaps make the Serializer store arrays as subcollections, and items in arrays as resources within those subcollections.
A downside of this, is we lose part of the structure that storing data in an XML file gives us, namely the natural ordering of elements. An XML file is easily ordered from the top down, but an entire collection tree traversal? I could settle on doing pre/post/in-order traversals, but I'll still need to pick a standard for ordering resources within a collection. No matter how you cut it, I lose some ordering capabilities. Mildly annoying.
An upside of this is that if we made the (Des|S)erializer smart enough, we could allow for granular locking of resources, and minimize database transaction activity.
Blargh, this will take some time to implement... Ah well, it will be a very nice foundation to work with when it's all done.
