You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2004/07/01 13:46:55 UTC
question on UnionBinding
Starting with the question: Does it make sense to process all sub bindings of a
UnionBinding?
At the moment the UnionBinding behaves just like a ContextBinding, all sub
bindings are processed. While the processing of a UnionWidget depends on the
caseWidget the same is not true for the binding.
My use case: I have different cases that need the same widget to be displayed
and later on saved back to bean. But the value is not saved to the bean only for
the current case but for all cases and so my case5 always wins, though another
case might have been selected.
My binding:
<fb:class id="voucher-class">
<fb:value id="voucher" path="voucherAvailable" direction="save"/>
</fb:class>
<fb:union id="eventData" path=".">
<fb:struct id="some other cases that don't need the voucher widget">
...
</fb:struct>
<fb:struct id="case1" path=".">
<fb:new id="voucher-class"/>
</fb:struct>
<fb:struct id="case2" path=".">
<fb:new id="voucher-class"/>
</fb:struct>
<fb:struct id="case3" path=".">
<fb:new id="voucher-class"/>
</fb:struct>
<fb:struct id="case4" path=".">
<fb:new id="voucher-class"/>
</fb:struct>
<fb:struct id="case5" path=".">
<fb:new id="voucher-class"/>
</fb:struct>
</fb:union>
The usage of voucherAvailable on the bean is exclusive, so I don't want to have
5 fields were one would be sufficient.
Was the UnionBinding implemented that way because nobody thought about my use
case or was there a use case for the current behaviour?
Joerg
Re: question on UnionBinding
Posted by Tim Larson <ti...@keow.org>.
On Thu, Jul 01, 2004 at 08:16:01AM -0600, Jason Johnston wrote:
<snip example/>
> Maybe I'm not understanding your example, but shouldn't all those
> <fb:struct>s be wrapped in <fb:case>s with the same id? If I understand
> correctly it's actually the fb:case binding that does conditional
> processing of its subbindings; the fb:union binding just acts as a dumb
> container.
Thanks for spotting this.
I updated the TimLarson wiki page by adding the union binding syntax.
--Tim Larson
Re: question on UnionBinding
Posted by Tim Larson <ti...@keow.org>.
On Thu, Jul 01, 2004 at 08:22:40PM +0200, Joerg Heinicke wrote:
<snip/>
> Use case: user will trigger an event, he can choose the event, the
> events are parameterized differently. The choose is the select
> box/caseWidget. The sample booleanfield is needed for a few of the
> cases, for other cases other fields are needed and some of them - now
> the reason for the asymmetry - have default values. As the switch from
> one case to another one is caused by submit-on-change on the select box
> now binding will be caused. Does this make sense?
Yes, thank you. (I am just trying to make sure the "masks" proposal
will not leave out important use cases.)
--Tim Larson
Re: question on UnionBinding
Posted by Joerg Heinicke <jo...@gmx.de>.
On 01.07.2004 20:44, Tim Larson wrote:
>>But it has another drawback: The model binding is now also load only
>>conditionally. What I need is to load the whole model but to save only
>>the one selected. For this I had to add this binding twice: once with
>>direction="load" as direct child of union binding and once with
>>direction="save" as child of case binding.
>
>
> That seems is kinda strange, but probably only because your use case
> is different than mine. Could you explain why you need to bind the
> non-selected cases so I can understand your use case better? To put
> it another way, what makes your use case need an asymetrical binding?
>
> For example, if you look at the (admittedly needing to be worked on)
> Form Model GUI's binding, you will see code that figures out and sets
> the union's case based on the actual data that is being bound, and
> then that is used by the union and cases to make sure that only the
> relevant bindings for the current case get invoked and that the other
> bindings do not get invoked.
Use case: user will trigger an event, he can choose the event, the
events are parameterized differently. The choose is the select
box/caseWidget. The sample booleanfield is needed for a few of the
cases, for other cases other fields are needed and some of them - now
the reason for the asymmetry - have default values. As the switch from
one case to another one is caused by submit-on-change on the select box
now binding will be caused. Does this make sense?
Joerg
Re: question on UnionBinding
Posted by Tim Larson <ti...@keow.org>.
On Thu, Jul 01, 2004 at 07:27:35PM +0200, Joerg Heinicke wrote:
> On 01.07.2004 16:32, Joerg Heinicke wrote:
<snip remember-to-use-case-with-union-binding/>
> But it has another drawback: The model binding is now also load only
> conditionally. What I need is to load the whole model but to save only
> the one selected. For this I had to add this binding twice: once with
> direction="load" as direct child of union binding and once with
> direction="save" as child of case binding.
That seems is kinda strange, but probably only because your use case
is different than mine. Could you explain why you need to bind the
non-selected cases so I can understand your use case better? To put
it another way, what makes your use case need an asymetrical binding?
For example, if you look at the (admittedly needing to be worked on)
Form Model GUI's binding, you will see code that figures out and sets
the union's case based on the actual data that is being bound, and
then that is used by the union and cases to make sure that only the
relevant bindings for the current case get invoked and that the other
bindings do not get invoked.
--Tim Larson
Re: question on UnionBinding
Posted by Joerg Heinicke <jo...@gmx.de>.
On 01.07.2004 16:32, Joerg Heinicke wrote:
>>Maybe I'm not understanding your example, but shouldn't all those
>><fb:struct>s be wrapped in <fb:case>s with the same id? If I understand
>>correctly it's actually the fb:case binding that does conditional
>>processing of its subbindings; the fb:union binding just acts as a dumb
>>container.
>
> *argh* Why I did not see the obvious? You are so right. It works with additional
> <fb:case>s. Thanks for your hint.
But it has another drawback: The model binding is now also load only
conditionally. What I need is to load the whole model but to save only
the one selected. For this I had to add this binding twice: once with
direction="load" as direct child of union binding and once with
direction="save" as child of case binding.
Joerg
Re: question on UnionBinding
Posted by Joerg Heinicke <jo...@gmx.de>.
Jason Johnston <jason.johnston <at> Intrado.com> writes:
> Maybe I'm not understanding your example, but shouldn't all those
> <fb:struct>s be wrapped in <fb:case>s with the same id? If I understand
> correctly it's actually the fb:case binding that does conditional
> processing of its subbindings; the fb:union binding just acts as a dumb
> container.
*argh* Why I did not see the obvious? You are so right. It works with additional
<fb:case>s. Thanks for your hint.
Joerg
Re: question on UnionBinding
Posted by Jason Johnston <ja...@Intrado.com>.
On Thu, 2004-07-01 at 05:46, Joerg Heinicke wrote:
> [snip]
> My binding:
>
> <fb:class id="voucher-class">
> <fb:value id="voucher" path="voucherAvailable" direction="save"/>
> </fb:class>
> <fb:union id="eventData" path=".">
> <fb:struct id="some other cases that don't need the voucher widget">
> ...
> </fb:struct>
> <fb:struct id="case1" path=".">
> <fb:new id="voucher-class"/>
> </fb:struct>
> <fb:struct id="case2" path=".">
> <fb:new id="voucher-class"/>
> </fb:struct>
> <fb:struct id="case3" path=".">
> <fb:new id="voucher-class"/>
> </fb:struct>
> <fb:struct id="case4" path=".">
> <fb:new id="voucher-class"/>
> </fb:struct>
> <fb:struct id="case5" path=".">
> <fb:new id="voucher-class"/>
> </fb:struct>
> </fb:union>
Maybe I'm not understanding your example, but shouldn't all those
<fb:struct>s be wrapped in <fb:case>s with the same id? If I understand
correctly it's actually the fb:case binding that does conditional
processing of its subbindings; the fb:union binding just acts as a dumb
container.
--Jason
Re: question on UnionBinding
Posted by Joerg Heinicke <jo...@gmx.de>.
Tim Larson <tim <at> keow.org> writes:
> > At the moment the UnionBinding behaves just like a ContextBinding, all sub
> > bindings are processed.
>
> I do not have time to dig in the code right now, but this looks like a bug
> (oversight) that needs fixed. Only the current case should be processed.
Thanks for the confirmation.
The code is quite easy "iterate over all sub bindings":
Binding[] subBindings = getChildBindings();
if (subBindings != null) {
int size = subBindings.length;
for (int i = 0; i < size; i++) {
subBindings[i].saveFormToModel(unionWidget, subContext);
}
}
I will see if I can fix it.
Joerg
Re: question on UnionBinding
Posted by Tim Larson <ti...@keow.org>.
On Thu, Jul 01, 2004 at 11:46:55AM +0000, Joerg Heinicke wrote:
> Starting with the question: Does it make sense to process all sub bindings of a
> UnionBinding?
>
> At the moment the UnionBinding behaves just like a ContextBinding, all sub
> bindings are processed. While the processing of a UnionWidget depends on the
> caseWidget the same is not true for the binding.
>
> My use case: I have different cases that need the same widget to be displayed
> and later on saved back to bean. But the value is not saved to the bean only for
> the current case but for all cases and so my case5 always wins, though another
> case might have been selected.
<snip example/>
> The usage of voucherAvailable on the bean is exclusive, so I don't want to have
> 5 fields were one would be sufficient.
>
> Was the UnionBinding implemented that way because nobody thought about my use
> case or was there a use case for the current behaviour?
I do not have time to dig in the code right now, but this looks like a bug
(oversight) that needs fixed. Only the current case should be processed.
--Tim Larson