Need design hints for Managed class

Question

I need help understanding the underlying LCDS mechanisms when a complex object hierarchy is managed in LCDS.  I have a custom Assembler because I have specialized persistence requirements.  My object hierarchy is basically the following:
Document
    Chapter
        Page
            Text
Document is the [Managed] class.  When a new Document is created, it is initialized with a Chapter.  Pages and Text are created when the document is edited.  I create new instance of Document and initialize it with an instance of Chapter.  On the client, I invoke the DataService using the createItem method.  My custom Assembler is called, I do the necessary persistence operation and return.  Back on the client I receive the ItemReference containing the AS Document.  This all works ok.  I am now faced with the runtime operations when the user starts creating Chapters, Pages and entering text.
Given that I start the editing session with a single ItemReference, I don't understand how to handle the Document sub-tree.  The LCDS documentation says the purpose of the [Managed] class tag is so the entire object tree does not need to be transmitted when a property changes on a child object.  Its the responsibility of the sub class to keep the remote object in sync.  But, I don't know the best way to go about doing this.
The [Managed] annotation makes the properties of the managed class bindable.  I can add an event listener to the ItemReference to handle property changes on the Document, but what about the rest of the object tree?    Do I explicitly make the properties of the child objects bindable?  Do I make each parent object an event listener for its child object properties and propagate the event up the tree?
Any suggestions or patterns to make this a little more understandable would be greatly appreciated.

Answer 1

If Hibernate cannot read/write your persistence layer (i.e. its not a database) then you probably wont be able to deploy a model and have the server side 'just work'.  You can specify the assembler class in the model annotations and we will configure a destination of that type for each entity (you can specify a custom assembler for each different entity).  This may not be a road that you want to go down, as manually configuring each assembler for each association will give you more transparency and control.
But you can still use the model in FlashBuilder to generate all of your client side value objects and you may be able to use the generated service wrappers.
Note that for each association, you will need an assembler.  So there is the Document assembler, the Chapter assembler and the Page assembler.  Each one is responsible for managing the persistence of each item type.  You would then define the <one-to-many> relationships in the destination config, along with the destination that manages that type of item:
<destination id="DocumentAssembler">
  <metadata>
    <identity property="id">
    <one-to-many property="chapters" destination="ChapterAssembler" lazy="true" paged="true" page-size="10" />
  </metadata>
</destination>
<destination id="ChapterAssembler">
  <metadata>
    <identity property="id">
    <one-to-many property="pages" destination="PageAssembler" lazy="true"  paged="true" page-size="10" />
  </metadata>
</destination>
And so on for PageAssembler.  This is how the system can manage each item class.  I made the associations lazy and paged, but you don't have to do this if you don't need it.
On the client, each of the managed collections (Documents, Chapters, Pages) is monitored for changes and the appropriate create/update/delete in the assembler is performed when a commit() is called.  You perform a DataService.fill() on the "DocumentAssembler" destination to start things off, you get back a managed collection and just go to town, modifying the whole object tree as you see fit, then calling DataService.commit() on the Document, and all of the nested 'stuff' that you did will be persisted to each assembler for each type of collection (documents, chapters, pages).  It is pretty powerfull.
To help reduce the work, you can use a model to generate code, then never generate it again.  Or just define the AS value objects manually, using the generated code as a guide.  The trick is to make sure the collection properties like "chapters" and "pages" are labeled with the [Managed] metadata.
There are plenty of 2 level association examples on the DevCenter and out in the web (check out Tour De LiveCycle for instance).  You are just going down one more level.
All this being said, you can skip most of this and just have a single destination that does Documents and takes a full object graph of stuff each time.  This will be pretty 'blunt force' as the whole Document will be handed to the updateItem function and you have to figure out how to persist it and all its sub-properties.  I am not familiar with Jackrabbit, so I don't know how fine grained your persistence is.
Anyway, let us know what you come up with!