--- 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.
> 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?
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..
--Tim Larson
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
