cocoon-dev mailing list archives

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


Sylvain Wallez wrote:

> Marc Portier wrote:
> 
>>
>>
>> Sylvain Wallez wrote:
>>
>> <snip />
>>
>>>>> I was attempting and failing to bind to an XML document.  The load 
>>>>> worked, but the save gave the exception.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Sylvain?
>>>>
>>>> I know Sylvain created this:
>>>> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/util/jxpath/DOMFactory.java

>>>>
>>>> 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?)
>>>
>>>
>>>
>>>
>>>
>>> Sorry, I'm very late on all this.
>>>
>>> Actually, there's currently no use of this class in Cocoon samples, 
>>> but I use it on my projects. Here's how: in the flow, I don't 
>>> load/save the DOM directly, but through a JXPathContext as follows;
>>>
>>>  var doc = readDocument(url);
>>>  var bindingCtx = createBindingContext(doc);
>>>  form.load(bindingCtx);
>>>  form.showForm("pipeline");
>>>  form.save(bindingCtx);
>>>
>>> And here's the createBindingContext function:
>>>
>>> function createBindingContext(document) {
>>>   // Create a JXPath context on the document.
>>>   var xpathContext = 
>>> Packages.org.apache.commons.jxpath.JXPathContext.newContext(document);
>>>   // Set it to lenient
>>>   xpathContext.setLenient(true);
>>>   // Add the necessary factory create elements and attributes as 
>>> needed on non-existing paths
>>>   xpathContext.setFactory(new 
>>> Packages.org.apache.cocoon.util.jxpath.DOMFactory());
>>>   return xpathContext;
>>> }
>>>
>>>
>>
>> Thx for explaining!
>>
>>> Having to explain how this work yesterday during a training, I felt 
>>> that it should be better hidden in the binding machinery, since this 
>>> is somehow needed every time we bind a form do a DOM (unless the DOM 
>>> already contains the whole XML structure).
>>>
>>> So what about adding this into the AbstractJXPathBinding: if the 
>>> object passed to load/save is a Node, then add the DOMFactory 
>>> automatically.
>>
>>
>>
>> Makes sense!
>> (that is were I was looking for the registration in the first place :-))
>>
>>
>> Only thing to look out for is the possible combination with the 
>> insert-node binding? (haven't checked yet how jxpath handles multiple 
>> registries)
> 
> 
> 
> We may create a child JXPathContext in InsertNodeJXPathBinding to avoid 
> overriding the DOMFactory, but I'm wondering if using a factory is 
> needed at all in InsertNode: isn't a simple "appendChild" enough?
> 
> i.e. Node node = 
> (Node)jxPathContext.getContextPointer().getNode().appendChild(toInsert)
> 

that is what the factory is doing :-)
but I catch your drift: the detour is not really needed...

in any case: I'll have a special look at this when I make the changes

>> On a side-note: isn't the utility class a more natural addition to 
>> jxpath (in the long run?)
> 
> 
> 
> Sure, we may contribute it. But there's still a problem that needs to be 
> fixed, which is that it fails to create an attribute whose owner element 
> doesn't exist.
> 

fine, was just a thought popping up, thx for explaining

>> And finally:
>> I'm taking it you are quite ok with the rest of the proposal?
>> (just wanted to check)
> 
> 
> 
> Basically, I'm ok with having the two kinds of binding sharing a similar 
> syntax (on-bind, on-insert, etc), but I'm not sure merging them in a 
> single binding is a good idea, as apart "row-path" and "parent-path", 
> their other attributes are very, very different.
> 

yep, that is the exercise ahead of us: find an optimal way to do it, as 
you can see from the mails, my own vision is still shifting...

> So I would better be in favor of some more explicit names such as 
> "delta-repeater" for "repeater" and "override-repeater" for 
> "simple-repeater".
> 
> WDYT?
> 

I'm still closer to the strategy attribute idea, but I definately agree 
it could be separated classes.... (shared stuff common, different stuff 
separated?)

IMHO having separate elements confuses people more then having a 
strategy-selecting attribute, but that might be just an impression?

maybe odd, but a side-effect of the attribute thingy will be that the 
alternatives are more naturally documented together...

I like the name delta-repeater more then my own proposal of diff-repeater,
but simple and override score less then the rebuild-repeater?

more opinions?
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message