cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: CForms binding problem
Date Fri, 11 Mar 2005 19:49:28 GMT


Claus Straube wrote:
> Hello,
> 
>  
> 
> I’ve got two problems with the CForms binding. First a likely simple one:
> 
>  
> 
> How can I add a new node to an existing xml file? I’ve got something like:
> 

http://cocoon.apache.org/2.1/userdocs/forms/binding.html#fb%3Ainsert-node

detailed syntax depend on how the form and the flow looks like, but you 
should be able to work things out from there, and if not you'll easily 
find the way back to the list with some more detail

in fact it might even be required that you add some DOM handling code to 
exactly get what you want, at that time you might consider not to use 
the binding at all.

> 
>  
> 
> And I’ll get an other ‘name’ and ‘password’ out of my form, that simply 
> should be put into a ‘userdata’ element attached at the end of the 
> ‘userdata’ list.
> 
>  
> 
> The other problem/question is: Can I bind a JS Bean as load and a XML 
> file for save?
> 

yes.

it is very likely though that you will need two distinct bindings to do 
achieve what you want,

you could off course first try with only one that holds two fb:context's 
(http://cocoon.apache.org/2.1/userdocs/forms/binding.html#fb%3Acontext)
each one indicating the other '@direction'


>  
> 
> What I want to do is:
> 
> -          Load some variables from a JS bean into a CForm (for example 
> ‘role’ - that works fine)
> 
> -          After submitting the form everything should be saved as a new 
> node (see first question) in the XML file.
> 
>  
> 
> I looked at the samples in the CForms section and but I couldn’t find a 
> solution for my problem. Thanks for your help!
> 
>  

Just something to consider: "binding is not a must" :-)

The binding framework is intended as a help over extensive (and 
duplicate: load/save) form-api calls in the majority (80-20 rule) of 
cases where the flow and form deal with the back-end model in a very 
symmetrical way.

Meaning most people will only use one binding per form, and load/save 
back to the same model instance. (and truly collect the bonus of using 
the binding)

The system is flexible enough to be used outside those typical use cases 
for sure (and do some pretty hefty things by leaving the paved road)...

Just know that there is an alternative: in stead of bending your mind 
over until you succeed expressing your problem in terms of fb:* elements 
you can consider just getting into the form's API and structure right 
away and get out the data you need:

(oh blast, I was going to insert: 
http://cocoon.apache.org/2.1/userdocs/forms/api_java.html or its 
javascript equivalent :-))

anyways form.lookupWidget(path-like-pointer-into-the-widget-tree) should 
be your help together with widget.get/setValue()


Note: I didn't say you should abandon binding in your or any non-trivial 
case, far from it.  I just know that there is no way you can consider 
the alternative if you don't know about it :-)


regards,
-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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message