cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Larson <>
Subject Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms simple-repeater binding sample?)
Date Fri, 05 Dec 2003 16:36:05 GMT
--- Marc Portier <> wrote:
> Timothy Larson wrote:
> > --- Marc Portier <> wrote:
> I see a need for a combination of the 'simple' strategy _and_ the use of 
> unique identifiers:

Not sure if I caught this correctly...
are you suggesting to have these three strategies?:

  * update in place per changed item (currently in "repeater")
  * delete and re-add per changed item (new)
  * delete all items and re-add all item (currently in "simple-repeater")

> >>- confusion between simple and classic repeater binding... I understand 
> >>that we have two strategies that both have their special uses cases, but 
> >>I would like to have a more syntactic similarities between both to lower 
> >>the usage confusion (and switching effort) ... in fact maybe we should 
> >>even go for a single <wb: element-name for both and switch between both 
> >>by using some @strategy, @flavour or @type
> in every case, since my comment here was about user-confusion:
> I would like the fact that we make this chosing of binding strategy 
> reflected in a very explicit attribute (rather then the more implicit 
> changing behaviour you have now?)

+1 to using a single wb: element name with @strategy.

> as a consequence we should probably keep the implementation classes 
> separate as well (although since more and more declaration stuff gets 
> shared between both some strategy pattern might make sense)

Because they share a lot of code, I don't see why we should keep the
implementing classes separate.  Could you explain?

<snip name discussion/>

The names are intriquing , but lets decide if we even need split
classes if we use @strategy.

> >>- in any case we should remove the XML only limitation from the simple 
> >>repeater, since it's somewhat fighting with the principle of least 
> >>surprise, no?
> yep, Jeremy in the mentioned thead above
> but even without it, it just makes sense to maintain this (implicit?) 
> contract of the JXPathBinding family: it is expected to both work for 
> XML and Beans
> (subclasses should never lower contracts from their parents)

I agree in priciple, but do not have the will right now to fix it myself.

<snip new explaination of @row-path-insert/>
> I'm ready to commit this, supposedly the cvs-diff will make this very clear?

The new explaination and the diff make it very clear, thanks.  Looks good.

> > But it cannot handle this:
> >   <wt:repeater-widget>
> >     <wt:widget-label id="sample-field"/>
> >     <wt:widget id="sample-field"/>    
> >   </wt:repeater-widget>
> wow, you make me very curious here!!!
> are you doing what I think you are doing? mucho exciting stuff man!

Yes, I am trying to allow the editing of any XML file, with the intention
of round-tripping form definitions, templates, etc. in the CocoonForms-based
forms and reports development GUI.

> hm, a repeater of binding-context-nodes could do this?
> but maybe I'm missing something?

Would you explain what you mean?  Your second explainations seem to be very
clear.  My current code gets the underlying Node and adds children to it
directly.  If you have a way that is more generic JXPath, I'm all ears.

> > Thanks for your consideration,
> happy to, sorry for the delay in the roundtrip, higher availability 
> today (for some more hours)

Hope you get a good return on the time you spend on this.

--Tim Larson

Do you Yahoo!?
Free Pop-Up Blocker - Get it now

View raw message