You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Marc Portier <mp...@outerthought.org> on 2004/04/14 15:05:47 UTC
Re: Help with 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
Re: Help with binding - CFORMS
Posted by Marc Portier <mp...@outerthought.org>.
Daniel Fagerstrom wrote:
> Marc Portier wrote:
> <snip/>
>
>> 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)
>
>
> Yes, I only tested the XML binding part. I wrote a note about that in
> ths CVS-log, a note in the javadoc or the wiki-doc that I newer wrote
> had been easier to find I guess ;)
>
well, objectively they're equally easy to find of course, it really is a
matter of what comes first to mind (yes, often the wiki :-))
>> 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.
>
>
> Yes, it is based on the simple-repeater binding code. First I tried to
> reuse the simple-repeater binding whithout doing copy and modify, but
> the data model for the multi-value widget and the repeater widget are
> quite different so it would have required a refactoring of both widgets,
yep, I realize that, the other approach is to solve everything in some
wrapper on the side of the binding, but it seems a tad more logical to
have some RepeatableWidget or IteratableWidget interface that could be
implemented by both. That would make it easier for some common binding
to attach to both.
The feeling I still have is that these repeatable widget-values (i.e.
the rows to the repeater-widget) would need some notion of their
'identity' which for a multivalue-field seems to be not-existent (it
behaves like a bag, not a list), and in other use cases would boil down
to their 'index' (meaning the identity is their position in the
surrounding RepeatableWidget)
> and that propagates to a lot of other code in the form framework,
> something that I didn't have time to do when I wrote the binding code :/
> I agree completely with another of your posts that we have to refactor
> the form code so that it becomes comprehensible and that now is the time
> to do it.
>
> IMO we need better interfaces for the widgets than the current ones:
> Widget and ContainerWidget. If we take a look at the repeater widget it
> implements ContainerWidget but it does not contain real implementations
> of the (to few) methods of ContainerWidget, instead it uses a number of
I started a page on the wiki [WoodyRefactoring] to capture the floating
impl-ideas-on-this-refactoring, feel free to jot down your hints when
you come down to it...
> own methods for accessing its contents. The multi-value field does not
> implement container, but instead uses an Object[] as input and output.
> What we need are interfaces for container widgets that contains enough
> methods so that the "repeater" binding can be written in terms of the
> interface instead of in terms of the repeater class. Then the
yep I agree, but I think it is another aspect then the Container thing
container == have child-widgets
iteratable == have mutliple values
(I think I now finally parse Peter's hint some weeks ago saying that
being multi-valueable is just an aspect that could be attached to
different widgets)
> multi-value widget should implement this interface and we could through
> away the mult-value bindning.
>
good idea.
>
>> [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.)
>
>
> I believe that the "misconception" depends on the weak interfaces for
> the widgets that in turn makes the binding classes more widget specific
> than they ideally should be.
>
more +1
> Need to review the widget and binding classes in more detail to give any
> more detailed suggestion on what the stricter interfaces should look
> like, though.
>
> WDYT?
>
good ideas, they surely help clearing out
-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
Re: Help with binding - CFORMS
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Marc Portier wrote:
<snip/>
> 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)
Yes, I only tested the XML binding part. I wrote a note about that in
ths CVS-log, a note in the javadoc or the wiki-doc that I newer wrote
had been easier to find I guess ;)
> 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.
Yes, it is based on the simple-repeater binding code. First I tried to
reuse the simple-repeater binding whithout doing copy and modify, but
the data model for the multi-value widget and the repeater widget are
quite different so it would have required a refactoring of both widgets,
and that propagates to a lot of other code in the form framework,
something that I didn't have time to do when I wrote the binding code :/
I agree completely with another of your posts that we have to refactor
the form code so that it becomes comprehensible and that now is the time
to do it.
IMO we need better interfaces for the widgets than the current ones:
Widget and ContainerWidget. If we take a look at the repeater widget it
implements ContainerWidget but it does not contain real
implementations of the (to few) methods of ContainerWidget, instead it
uses a number of own methods for accessing its contents. The multi-value
field does not implement container, but instead uses an Object[] as
input and output. What we need are interfaces for container widgets that
contains enough methods so that the "repeater" binding can be written in
terms of the interface instead of in terms of the repeater class. Then
the multi-value widget should implement this interface and we could
through away the mult-value bindning.
> [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.)
I believe that the "misconception" depends on the weak interfaces for
the widgets that in turn makes the binding classes more widget specific
than they ideally should be.
Need to review the widget and binding classes in more detail to give any
more detailed suggestion on what the stricter interfaces should look
like, though.
WDYT?
/Daniel
Re: Help with binding - CFORMS
Posted by Marc Portier <mp...@outerthought.org>.
Uchenna Igwebuike wrote:
> 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.
>
strange, have you debugged this to the level were you have some proof of
those values being set onto the widget?
-marc=
>
> -----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
RE: Help with binding - CFORMS
Posted by Uchenna Igwebuike <uc...@sbcglobal.net>.
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
Re: Help with binding - CFORMS
Posted by Marc Portier <mp...@outerthought.org>.
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
RE: Help with binding - CFORMS
Posted by Uchenna Igwebuike <uc...@sbcglobal.net>.
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.
NB. I am modeling the field as a long data type.
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
RE: Help with binding - CFORMS
Posted by Uchenna Igwebuike <uc...@sbcglobal.net>.
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.
NB. I am modeling the field as a long data type.
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