looks like I missed out on this posting earlier, sorry for that.
Timothy Larson wrote:
--- Marc Portier <[EMAIL PROTECTED]> wrote:
Timothy Larson wrote:
--- Marc Portier <[EMAIL PROTECTED]> wrote:
Timothy Larson wrote:
--- Marc Portier <[EMAIL PROTECTED]> wrote:
== Repeater-binding update-strategy ==
This is a summary to check if our thoughts are in sync.
Options: With unique rows: delta (update in place) or rebuild (remove all and re-insert) With non-unique rows: only rebuild
Delta On load Row order in repeater will match row order in xml. All or selected rows may be loaded into repeater widget. On save Row order in xml is preserved, new rows appended in repeater order. Rows not present in repeater will not be changed in xml.
Rebuild On load Row order in repeater will match row order in xml. All or selected rows in xml are loaded into repeater. On save Row order in xml is changed to match row order in repeater. Rows not present in repeater will be removed from xml.
great summary! that's it.
2/ @strategy="rebuild" with unique-id and path known to survive sparse-ness
(Q: do we need an additional attribute explicitely stating that the parse-ness is to be taken care off? or should we always try when the unique-id is known?)
I think you are suggesting for the rebuild strategy to have an attribute to indicate that selected rows are to be "officially" loaded into the repeater, while the rest of the rows should be loaded as "hidden" rows to allow them to be preserved on save. Is this the right interpretation?
I was rather talking about not-bound columns then about non-bound rows...
suppose repeater-values-in-model:
id | att_x | att_y ----+--------+------- 1 | A | yes 2 | B | no
and you bind this into a form-model that only shows/allows to edit the att_x part:
form looks like this: att_x [ A] [ B]
then upon bind-save using the rebuild strategy we will not have the original values of the att_y present in the repeater context (unless, they would be there as hidden variables)
the point I try to make is that the rebuild-strategy that KNOWS about unique-ids really is capable of preserving the att_y values by matching the id's of the rows (like this you would only need one hidden var for the id and still recover all the fields that were not bound)
actually in this case the term 'rebuild' reflects the fact that we rebuild the list and it's order, but not really rebuild the child-elements that already existed (rather move them back in from some back-up copy before rebuilding the list)
Just preserving your mental note for you:
(mental note to self: recent row-path-insert needs to get a place in side this new multiple strategy stuff...)
just a concern about not cluthering too much inside one class, so we could put the common things in a shared base-class but still separate out the distinct algorithms into disctinct classes?
I think you have me convinced...
yeah, I like the idea of the @strategy be _interpreted_ by the Binding-building process and thus yield directly classes shaped for that particular strategy.
... because I agree with you here for the performance reasons you described.
But euh, the wt:repeate-widget can contain pretty much everything in the content model, right?
pfew, this comes close to trying to building a generic DOM-constructor editor, no?
Yes, with the ability to interpret and support the domain-specific knowledge
that is being encoded in the DOM.
so what does your form-definition and form-template for editing these files look like, maybe that gives me some inspiration here?
Watch for an update coming soon to the big patch on my wiki page: http://wiki.cocoondev.org/Wiki.jsp?page=TimLarson The other code in the patch is required to make the definitions and templates work, because they use "union", etc..
reading up... haven't applied the diff yet :-(
-marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
