No errors in the log files, it binds the widget without a blip but somewhere b/w executing the binding and the transformations, the selected values are not reflected in the form.
-----Original Message----- From: Marc Portier [mailto:[EMAIL PROTECTED] Sent: Thursday, April 15, 2004 11:02 PM To: [EMAIL PROTECTED] Subject: Re: Help with <fb:multi-value/> binding - CFORMS 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
