Uchenna Igwebuike wrote:
Hello Mark,
I tried out your suggestions and it works for binding the selected
values from the form to the bean but when I call form.load(bean) ie
binding from bean to form, it doesn't seem to work, the selected values
do not show up on the form. Any thoughts on this?. Thanks in advance.
hm, bummer, any exceptions along the way?
Maybe messages in log files?
(relevant portion of dump after setting log-level to debug on log-target 'forms' might help as well)
-marc=
NB. I am modeling the field as a long data type.
shouldn't make a difference: meaning it should work for all datatypes, but those datatypes need to match between backend and frontend for sure.
Uchenna
-----Original Message-----
From: Marc Portier [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 6:06 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Help with <fb:multi-value/> binding - CFORMS
copying dev since there is some food for design-thought...
Joerg Heinicke wrote:
On 12.04.2004 16:14, Uchenna Igwebuike wrote:
When I bind a form without selecting any data to the bean, I don't
get
any errors, but when it contains some selections I get the following error
uncaught JavaScript exception: at material
(file:/C:/projects/zes/construction/jboss-3.2.3/server/default/tmp/deplo
y/tmp16629ZESApplication-0.1.ear-contents/Mercury.war/inventory/flow/inv
entory.js, Line 64) at (resource://org/apache/cocoon/forms/flow/javascript/Form.js, Line
164):
org.apache.commons.jxpath.JXPathException: Exception trying to create xpath measureCollection; Factory is not set on the JXPathContext - cannot create path: /facility[1]
I guess the problem is only the predicate [1]. JXPath can not create a
node for an XPath with a predicate. Can you try for testing some thing
like facility1, facility2 and so on? Of course this looks like a hack,
hm, this will not work IMHO
but I don't know how you can fix it in a good way. Someone more experienced with JXPath might help here. Marc or Bruno?
Hm, I suppose the predicate is not in the Uchenna's binding file, but rather introduced by the execution of the multi-value binding: it wants to create a space to store each value from the multi-value array...
Suggestion:
I assume your backend now has some method: Object[] getFacility() that produces an array (more likely a List I'm afraid) in which the various facilities to be bound are present?
IIf it is acceptable that
1/ the type of this facility would become Object[] (in stead of List)
2/ and you can provide a setFacility(Object[]) accessor as well
then you could find a work-around in using the classic value-binding (this is because the widget-value is also of type Object[]
Pls let us know if this works for you.
For the interested reader, some more info:
[1 - on the reported error]
The error 'factory is not set' from jxpath indicates that no node-factory (jxpath terminology) is available (to the jxpath context) to create new 'nodes' in the backend (i.e. a bigger array in the bean, or additional objects to add to the list).
I assume the multi-value binding was only tested versus XML backends since those have by default a node-generation factory installed (and thus the problem never occurs)
Towards javaBean backends this reveals that the the multi-value lacks the feature of declaring such a factory (to compare: this is what the <on-insert> inside the repeater binding is for)
IMHO multi-value binding code looks like an early clone of the simple-repeater binding. This issue kinda re-affirms my feeling that there is no reason to maintain this multi-value-binding in the future.
[2 - on the confusing naming of the bindings]
Of course this leads me to some other observation: the names of the bindings are way too look-alike to the names of the widgets!
Because of this the misconception has grown that the binding file is a duplicate of your definition file that needs to allocate the matching binding-component to the matching widget. THIS IS NOT THE CASE. (see e.g. the last binding-sample '03aggregate': there an aggregate widget gets bind using both the aggregate-binding and the value-binding: that just works, and it's not a hack, nor an after-thought.)
In the form-definition one needs to select those widgets that build up the 'form-model' that is capable of supporting the end-user-interaction (ie both html form generation and request parameter processing) and validating/datatyping the entered values.
In the binding definition there is a different goal/concern: there one needs to select not a (passive) model, but an active 'strategy' or process that describes how you want to let load/save of data to happen.
Since that strategy mostly matches the actual capabilities of the widgets we have ended up here: having (mostly) matching names between the chosen widgets and the bindings: but this is a consequence, and as pointed out is often misleading our users.
With the above observation we could argue if we need to reconsider (naming and structure) of our binding components (just one thing more to
reconsider about cforms it seems :-))
comments welcome.
HTH, -marc=
-- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
