cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uchenna Igwebuike" <uche...@sbcglobal.net>
Subject RE: Help with <fb:multi-value/> binding - CFORMS
Date Sat, 17 Apr 2004 00:44:51 GMT
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:mpo@outerthought.org] 
Sent: Thursday, April 15, 2004 11:02 PM
To: users@cocoon.apache.org
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:mpo@outerthought.org] 
> Sent: Wednesday, April 14, 2004 6:06 AM
> To: users@cocoon.apache.org
> Cc: dev@cocoon.apache.org
> 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/
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



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


Mime
View raw message