cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: Help with <fb:multi-value/> binding - CFORMS
Date Wed, 14 Apr 2004 13:05:47 GMT
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

Mime
View raw message