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 Thu, 04 Dec 2003 03:21:51 GMT
--- Marc Portier <> wrote:
> Timothy,
> 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.
> 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.

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

> 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.

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

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
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:
      <name>John Doe</name>
      <name>John Doe's twin</name>
But it cannot handle this:
    <wt:widget-label id="sample-field"/>
    <wt:widget id="sample-field"/>    
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.

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.

Thanks for your consideration,
--Tim Larson

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

View raw message