cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject Re: [cforms] Repeater Binding Revisited.
Date Tue, 30 Mar 2004 19:26:34 GMT
On Tue, Mar 30, 2004 at 08:39:02PM +0200, Marc Portier wrote:
> Tim Larson wrote:
> >On Tue, Mar 30, 2004 at 12:24:55AM +0200, Marc Portier wrote:
> >>Over time our RepeaterBinding has been reported as behaving 'odd' and as 
> >>'not expected', in the best cases some argumentation could bend those 
> >>into 'unobvious'...
> >>The brave among us probably just patch the beast or make their own 
> >>'SimpleRepeaterBinding' and go on with their job...
> >
> >
> >Marc, could you also consider the "virtual rows" concept that is shown
> >in the TempRepeaterBinding? You can look at the Form Model GUI to see
> >how it is used. I do not care what it is called, and if you have a
> >better solution I am all ears.
> >
> >
> >
> thx chap, I did miss that!
> In fact when reading the postings I'm still missing it :-(
> care to clarify or should I just hit the code?

JXPath seems to be rather limited when it comes to collections. Certain
relative positions are hard to specify.  For example, if you have an XML
document that has a list of elements with different names, and you want
to map all of these elements into one repeater with a row for each
element, then all is fine until you try to use the "save" side of the
binding. How do you specify the position where you want to insert the
element "peach" in this example?
    <apple frog="toad"/>
    <peach cat="furry"/> <!-- Trying to insert this new element -->
    <prune wrinkled="true"/>
Your first reaction may be "bad document structure -> fix it", but
changing the structure of the document is not allowed, because the whole
point of this is to be able to edit existing XML documents by feeding
them into a form via the binding. For a real example without the fruit,
see the Form Model GUI where you can edit a cforms form model file that
the binding loaded into the GUI form.

The "virtual row" concept solves this nicely by creating a virtual
jxpath context for each row, so you do not have to say "insert peach in
the second slot", but just "append peach right here". The repeater uses
the erase-all-old-data-and-write-out-all-new-data plan, so after you do
all of the inserts (appends) into a virtual row, then the *contents* of
the row are appended to the surrounding context, and tada! The original
document structure is preserved and we worked past jxpath's collection
handling limitations.

Besides, when dealing with a row, why should you have to specify
positions relative to the whole list? If you did not have a row-specific
context, then it would be too easy for a row binding (especially via a
javascript or custom binding) to accidentally mess up data in other rows
of the back-end or proxy.

> -marc=
> PS: sudden idea: widgets have recently been attribute-enabled, sounds 
> like something we could use to hook in some 'item-identity' on the 
> row-level (argh, or fix the row class so it can just store that 
> member!... hm, have to think some more)

I'll be listening...

--Tim Larson

View raw message