cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Woody binding to incomplete XML documents
Date Mon, 08 Sep 2003 20:24:00 GMT
Marc Portier wrote:

> Sylvain,
>
> just saw the commit fly by
> looks good,
> this covers already much of the lenient stuff if I interpret this 
> correctly 


Partly. Two things are still to do :
- add a "lenient" on the various wb:* elements (sets up the leniency for 
the current element and its children). Currently, I create a 
JXPathContext in the flowscript (on which I set lenient to true), and 
use it for form load & save operations.
- update JXPath ! I found a bug in leniency inheritance when using 
JXPathContext.getRelativeContext(). This is bug #22988 in bugzilla, and 
I will update the JXPath library once the patch is committed.

> thx for doing this already, my planning is drifting anyway... 


Mine feels better now that XML elements can be created on the fly ;-)

> Sylvain Wallez wrote:
>
>> Hi,
>>
>> I'm using Woody to modify data in an XML document and encountered a 
>> lot of binding problems because the document is initially incomplete 
>> (not all elements are present).
>>
>> 1/ Loading a form fails with a freshly created document because some 
>> elements don't exist. A solution to this is to make the JXPathContext 
>> lenient (IIRC, Marc proposed it some time ago) so that binding 
>> doesn't fail if a path doesn't exist.
>>
>> 2/ The same reasons (non-existent elements) lead the saving to fail. 
>> The solution is to use createPathAndSetValue() instead of just 
>> setValue(). In the general case, this will also fail unless a JXPath 
>> AbstractFactory is provided to the JXPathContext. I wrote one for DOM 
>> elements.
>>
>
> yep,
> this is why I mentioned the possibility for adding maybe some 
> insert-node for value-binding in case it would need to create stuff
>
> so if I read this right you are saying here that for DOM stuff this 
> will just create elements and textnodes to comply to the paths specified? 


Exactly !

>> 3/ When a field value is null, I would like the corresponding path to 
>> be deleted rather than setting its value to null. This will remove 
>> elements rather than emptying them. Should this be configurable (i.e. 
>> delete-on-null="true") ? Note that this only impacts DOM bindings 
>> since deleting on JavaBeans is exactly the same as setting the value 
>> to null (the property cannot be removed from the class!).
>>
>> How does this sound ?
>>
>> Ah, and some additional goodies I wrote (need a bit testing before 
>> committing) :
>> - a simple binding for repeaters that deletes all values before 
>> re-adding them. This avoids the need for unique row-ids as required 
>> by the current repeater binding.
>
>
> another one removed from my todo list ;-)
> guess it wasn't itching enough on my side yet... 


But itching big time on mine ;-P

>> - a stylesheet to generate the binding from <wd:binding> elements and 
>> wb:* attributes in the form definition. Very convenient, as it avoids 
>> the need for a separate binding file.
>
>
> here here!
> (however: did I miss this in the commitmails?) 


Nope, I did not commit this for now. But I will do it so that we can 
learn from it for the future unification of file formats !

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message