Hi all
A friend mentioned you guys were discussing CarrierWave (cw), so I thought I would jump in. long post ahead...
cw was definitely designed to support the retrieval of arbitrary, type equivalent, object graphs from a remote app server.
it supports this in two ways.
the first is lazy loading of the graph. objects fault into your client jvm as you walk the graph. obviously you can define the depth of each fetch, so you aren't stuck with one object at a time.
the second is by defining the closure of the graph, and requesting the graph in one request. these graph closure definitions are called graph-plans. you can pass them by-value or by-reference. the later expects you stored the plans, by name and version, in the plan repository.
so if you have a web app and one screen edits an invoice, you can 'select invoice version 2 where customer has cust id 99'. edit the graph, by rendering it out as html etc. then post (update) back the dirty objects to the app server. you never lose relationships between identifiable objects (those with an permanent id).
or if you have a rich client, you can fetch the objects you need on demand. or you can instantiate a new graph from a plan (create invoice version 2),and fill in the blanks.
I did build a 'universal' gui that will attach to a cw enabled app server and let you arbitrarily edit objects and their relationships. this works because a tremendous amount of meta-data is stored in the image classes. so you can manipulate an image-graph through a model (DataModel, DocModel andGraphModel). the gui was very beta when I threw in the towel. more on that later....
on the server side, there are four main types of objects, all of which client side dto objects are generated (images) and mirror the type hierarchy of the server side imageable type. identifiable, dependent, actions, and finders.
identifiable have identities. server side objects and client side images both share a reference called an icon (an objectified IOR).
dependent types have identity only in relationship to their parent identifiable object. delete the identifiable, you lose the dependents.
actions can be thought of as a method object. it executes things on the server, with a possible return value or graph.
finders are wrappers for persistence engine api's. so instead of making a new finder method, you make a parameterized object. the client side image takes the same parameters you define on the server side class. if a parameter is a business object, you can provide a image prototype or an icon that identifies it.
when you fetch a graph with a plan, you get an image-graph. it has no server side dependencies (like hibernate). except those necessary to communicate with cw. you can add new images, or remove existing ones. once you have modified the graph, you update the graph on the server. deletes are special cases, and are not part of an update, too many side-effects.
you can also roundtrip, select an image-graph, update it, update the server with it and get it back, all in one call. this is useful if some methods on the server creates new objects or change relationships.
I left the code stable and functionally complete. there is also a bunch of weird crap tangential to it. like a tool that will, from the command line, extract an object graph into xml. and you can either edit it and push it back. or use it as a backup or a way to init a development server (push a bunch of test objects into a system after a major schema change).
a lot of the code in cw is to support abstracting out all the 'proprietary'api's (ejb, hibernate, jboss, toplink, etc). a lot of that code can be dumped for Spring I expect.
but the work I do now is very document/entity centric. cw just isn't a fit for me right now. when I was doing business objects (ejb etc), cw made our development very agile. strong separation between client and server developers. no client/presentation functions leaking into the server. and no server side dependencies in the client. type safety for those who want it, and rich models for managing graphs for those who don't.
anyways, back to hacking e4x on the server side....
ckw
Leave a comment