cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms simple-repeater binding sample?)
Date Fri, 05 Dec 2003 12:19:45 GMT

Timothy Larson wrote:

> --- Marc Portier <> wrote:
>>the rudimentary dox (see wiki) on the simple-repeater-binding are 
>>explaining this:
>>It is currently only supporting binding back to XML (so I suspect that 
>>you were testing versus a java beans backend model here?)
> I was attempting and failing to bind to an XML document.  The load worked,
> but the save gave the exception.


I know Sylvain created this:
exactly to cater for the automatic creation (factory) of DOMNodes 
triggered from jxpath createPath statements...

But I have to admit I can't find where that thingy gets registered on 
the jxpath context (too much relying on the advanced search of eclipse?)

>>we briefly discussed this recently (and I was getting into doing it, but 
>>am caught up on a local conference here the next few days)
>>see this thread:
>>the idea would be to have a similar entry for <on-insert-row> nested in 
>>the simple-repeater-binding as borrowed from the classic repeater-binding?
> While waiting for a response about the simple repeater binding, I modified
> the main repeater binding to support binding without a unique id.  You just
> leave off the unique-row-id and unique-path attributes, and it acts like a
> simple repeater binding but with the on-* elements added. Is this near what
> you are thinking?  If it is, I will post it when I get back to work tomorrow.

not entirely
I see a need for a combination of the 'simple' strategy _and_ the use of 
unique identifiers:

suppose your bean is only sparsely bound to the form-widgets: then you 
would loose some fields when you just delete and rebuild --> so you 
would need to
1/ copy them over from some back-up space
2/ when you find them back based on their unique ID

of course this kind of expects that we can augment the declarations 
(more atts) to communicate the methods on the parent-bean to create that 
clone of kids, and to reset/empty that list.

>>in fact I started thinking about this some more first (also based on 
>>some private mails with Jeremy who was so kind to let me in on some more 
>>  hibernate details and issues in his current project)
>>some (random order) observations/suggestions on repeater binding as is now:
>>- repeater-bindings have no @readonly to shut down the save() operation
>>   like the field-binding has it.
>>- in fact it also struck me that the @readonly concept only allows us to 
>>choose between two modes of operation : 1/ do load AND save 2/ do only 
>>load.  Maybe we should provide a generic attribute on all bindings that 
>>looks like @direction and can hold load|save|both (probably even 
>>implement this at the level of the abstract base class?)
> +1  I was thinking this also.
>>- 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
> Please see the repeater modification mentioned above.

pls see my comments above :-)

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?)

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)

which brings me to the aspect of developer-confusion: we should change 
the names:

- RepeaterBinding suggests it is the only one (which is a claim we 
cannot make given Sylvain's and Jeremy's use case ?)

- SimpleRepeaterBinding has a name which actually more reflects the 
developer appreciation of the algorithm used, then it is giving a 
functional hint about its usefulness
(as I was jokingly saying to Bruno: its a bit like naming your class 
TheLessThen500LoCImplementation vs TheMoreThen1000LoCImplementation :-))

new suggestions coming to mind:
RepeaterBinding --> DiffRepeaterBinding   (wb:repeater/@strategy="diff")

SimpleRepeaterBinding --> RebuildRepeaterBinding 
(wb:repeater/@strategy="rebuild", which would be my default choice, even 
if that breaks backwards compat, we are still beta after all)

of course using the Strategy pattern things would look slightly different.

>>- 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?
> +1  I do not have a use case myself yet, but I faintly remember someone
> else may have presented one?

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)

>>oh, I also thought some about this:
>>and currently have a patch on HD that is introducing an extra attribute 
>>row-path-insert for the classic (not-simple) repeater-binding that is 
>>used for depicting where the rows to be inserted should go in... (in 
>>stead of just reusing the @row-path for that purpose)
> Not sure I understand this yet.  Would you expand on this?  Explain it
> in different words and I might catch the idea.

here comes:
you start off with a backend-model that has
[ITEM(@id=A, @x=1), ITEM(@id=B,@x=1), ITEM(@id=C,@x=2), ITEM(@id=D,@x=1)]

using current repeater impl you can load this stuff by filtering with an 
xpath-predicate ./ITEM[@x=1]

which results in having a repeater-rows in the form only showing the 
ITEMS A,B and D (which match the predicate)

now suppose an added row in the repeater ITEM(id=E) that needs to be 
added after the existing D-ITEM... using the row-path with predicate 
this will result in an error, since the repeater-strategy is just 
building this xpath: ./ITEM[@x=1][5] which is (a bit logically) not 
supported by jxpath's create-path statement (too much conditionals to 
know what to explicitely build?)

my first naieve thought was to autmatically parse/remove the predicate 
from the row-path to deduce the row-path-insert (to use for the inserts)

however these predicates can occur inside every step of the row-path, 
and why not just make it explicit so the user can even specify another 
location for the inserted-rows?

I'm ready to commit this, supposedly the cvs-diff will make this very clear?

>>but maybe we should take a more holistic view on things and maybe first 
>>discuss a broader binding-syntax redo starting from above suggestions?
>>(by the way: any suggestions from users having a more usability opinion 
>>is welcome, maybe I was (we are) a tad too much focussed on processing 
>>the thing when we defined the original semantics of the file?)
>>in any case I hope we can synchronize our updating efforts here?
> I think so.
>>PS: sorry for lagging behind on your new widget-types, but wouldn't they 
>>require separate and specific binding-types rather then fixing the 
>>repeater-binding to work on them as well?
> I *am* creating new specific binding types, but I also have some repeater

ah ok, didn't catch that, thx for explaining

> needs that are not satified yet when using the new binding types to create
> the form design gui's binding. I need the repeater to load and save items
> that are not wrapped in a commonly named element. The current repeater
> binding can deal with this:
>   <contacts>
>     <contact>
>       <name>John Doe</name>
>     </contact>
>     <contact>
>       <name>John Doe's twin</name>
>     </contact>
>   </contacts>
> 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!

> because the row elements "wt:widget-label" and "wt:widget" differ and are
> not each wrapped in a commonly named row element like "contact" in the
> first example.

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

> I tried to continue my modifications to the repeater binding to support
> this, but it is difficult due to the semantics of the path and context
> calls in jxpath.  Loading works now, but if you have any ideas how to do
> the saving without invasive changes to the existing bindings I would jump
> for joy.  I just want each bound vidget to be appended as the last child
> of the containing element.  I almost have a very inefficent method working.

see above?

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

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message