You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2005/03/14 21:44:44 UTC
[cforms] Widget states in request-scoped forms
Today I've tried to run a form that uses the widget state "INVISIBLE" and when
the form state is saved in the request. (my experiments are based on the form1
action example)
If I use the event framework to change the state from ACTIVE to INVISIBLE,
toggling works, but the value of the changed widget gets lost.
Looking at the samples I can't figure out ...
- How can a widget have the state "INVISIBLE"? Where is this information stored,
or better from where is it read?
- If I'm right and the described behavior (losing the values of INVISIBLE
widgets) is a bug, how can it be fixed? Any ideas?
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [cforms] Widget states in request-scoped forms
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Sylvain Wallez wrote:
>
>> Reinhard Poetz wrote:
>>
>>> Sylvain Wallez wrote:
>>>
>>>> Reinhard Poetz wrote:
>>>>
>>>>> Sylvain Wallez wrote:
>>>>>
>>>>>>> Another idea I had is, that I could work on making the form
>>>>>>> object serializable and save the state in a hidden form field.
>>>>>>> The price to pay would be increased network traffic but the
>>>>>>> advantage of a stateless presentation layer wouldn't get lost.
>>>>>>> Hmmm the more I think about it the more I like this idea .... wdot?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> You should have a look at the XMLAdapter class in
>>>>>> o.a.c.form.util. It does handles form
>>>>>> serialization/deserialization in XML. AFAIK it doesn't keep
>>>>>> state, but this could easily be added.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thanks for the pointer! This should be very helpful, if I go this
>>>>> way.
>>>>>
>>>>> Is there anything else that is necessary to _completly_ describe
>>>>> the state of a form, except the value and the "visibility state"?
>>>>> (events, validation errors, ...?)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Events are inherently transient (i.e. they are produced and
>>>> consumed as part of the processing of a request). Validation errors
>>>> are part of the global state of a form, as non-active widgets will
>>>> loose their value and any validation as they don't read their value
>>>> on the request.
>>>>
>>>> You also have to include <fd:repeater-size> in your form template
>>>> so that the size of repeaters is transmitted back and forth as a
>>>> hidden input.
>>>
>>>
>>>
>>>
>>>
>>> ok, so we need following information to describe the state of a form:
>>>
>>> 1. widget value
>>> 2. widget visibility state
>>> 3. validation errors
>>> 4. repeater size
>>
>>
>> Yes, that should be ok.
>
Thinking further, the use of <ft:repeater-size> isn't needed as this
information will be part of the serialized state.
>>> This means that I would have to enhance XMLAdapter to save this
>>> information too. Then I would extend the FormsTransformer to add a
>>> hidden input field that contains the compressed and encrypted XML.
>>
>>
>>
>> Encrypted? Beware of security through obscurity, which is not a good
>> solution, especially when the encryption/decryption code is
>> opensource ;-)
>
>
> yes, but if the encryption key is customizeable (e.g. in cocoon.xconf)
> this shouldn't be a problem
Ah, ok. That makes sense.
>>> When the request comes back to the server, the controller checks for
>>> the hidden field and deserializes it.
>>
>>
>> By 'controller', do you mean FormSubmitAction?
>
>
> for example, yes.
It would be cool to have a ready-to-run action in Cocoon for those
situations where you cannot use flowscript.
Maybe this could be implemented as a new <ft:serialized-state/> template
instruction.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [cforms] Widget states in request-scoped forms
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> Reinhard Poetz wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Reinhard Poetz wrote:
>>>
>>>> Sylvain Wallez wrote:
>>>>
>>>>>> Another idea I had is, that I could work on making the form object
>>>>>> serializable and save the state in a hidden form field. The price
>>>>>> to pay would be increased network traffic but the advantage of a
>>>>>> stateless presentation layer wouldn't get lost. Hmmm the more I
>>>>>> think about it the more I like this idea .... wdot?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> You should have a look at the XMLAdapter class in o.a.c.form.util.
>>>>> It does handles form serialization/deserialization in XML. AFAIK it
>>>>> doesn't keep state, but this could easily be added.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thanks for the pointer! This should be very helpful, if I go this way.
>>>>
>>>> Is there anything else that is necessary to _completly_ describe the
>>>> state of a form, except the value and the "visibility state"?
>>>> (events, validation errors, ...?)
>>>
>>>
>>>
>>>
>>>
>>> Events are inherently transient (i.e. they are produced and consumed
>>> as part of the processing of a request). Validation errors are part
>>> of the global state of a form, as non-active widgets will loose their
>>> value and any validation as they don't read their value on the request.
>>>
>>> You also have to include <fd:repeater-size> in your form template so
>>> that the size of repeaters is transmitted back and forth as a hidden
>>> input.
>>
>>
>>
>>
>> ok, so we need following information to describe the state of a form:
>>
>> 1. widget value
>> 2. widget visibility state
>> 3. validation errors
>> 4. repeater size
>
>
>
> Yes, that should be ok.
>
>> This means that I would have to enhance XMLAdapter to save this
>> information too. Then I would extend the FormsTransformer to add a
>> hidden input field that contains the compressed and encrypted XML.
>
>
>
> Encrypted? Beware of security through obscurity, which is not a good
> solution, especially when the encryption/decryption code is opensource ;-)
yes, but if the encryption key is customizeable (e.g. in cocoon.xconf) this
shouldn't be a problem
>
>> When the request comes back to the server, the controller checks for
>> the hidden field and deserializes it.
>
>
> By 'controller', do you mean FormSubmitAction?
for example, yes.
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [cforms] Widget states in request-scoped forms
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Sylvain Wallez wrote:
>
>> Reinhard Poetz wrote:
>>
>>> Sylvain Wallez wrote:
>>>
>>>>> Another idea I had is, that I could work on making the form object
>>>>> serializable and save the state in a hidden form field. The price
>>>>> to pay would be increased network traffic but the advantage of a
>>>>> stateless presentation layer wouldn't get lost. Hmmm the more I
>>>>> think about it the more I like this idea .... wdot?
>>>>
>>>>
>>>>
>>>>
>>>> You should have a look at the XMLAdapter class in o.a.c.form.util.
>>>> It does handles form serialization/deserialization in XML. AFAIK it
>>>> doesn't keep state, but this could easily be added.
>>>
>>>
>>>
>>>
>>> Thanks for the pointer! This should be very helpful, if I go this way.
>>>
>>> Is there anything else that is necessary to _completly_ describe the
>>> state of a form, except the value and the "visibility state"?
>>> (events, validation errors, ...?)
>>
>>
>>
>>
>> Events are inherently transient (i.e. they are produced and consumed
>> as part of the processing of a request). Validation errors are part
>> of the global state of a form, as non-active widgets will loose their
>> value and any validation as they don't read their value on the request.
>>
>> You also have to include <fd:repeater-size> in your form template so
>> that the size of repeaters is transmitted back and forth as a hidden
>> input.
>
>
>
> ok, so we need following information to describe the state of a form:
>
> 1. widget value
> 2. widget visibility state
> 3. validation errors
> 4. repeater size
Yes, that should be ok.
> This means that I would have to enhance XMLAdapter to save this
> information too. Then I would extend the FormsTransformer to add a
> hidden input field that contains the compressed and encrypted XML.
Encrypted? Beware of security through obscurity, which is not a good
solution, especially when the encryption/decryption code is opensource ;-)
> When the request comes back to the server, the controller checks for
> the hidden field and deserializes it.
By 'controller', do you mean FormSubmitAction?
> Does this sound reasonable?
Absolutely!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [cforms] Widget states in request-scoped forms
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> Reinhard Poetz wrote:
>
>> Sylvain Wallez wrote:
>>
>>>> Another idea I had is, that I could work on making the form object
>>>> serializable and save the state in a hidden form field. The price to
>>>> pay would be increased network traffic but the advantage of a
>>>> stateless presentation layer wouldn't get lost. Hmmm the more I
>>>> think about it the more I like this idea .... wdot?
>>>
>>>
>>>
>>> You should have a look at the XMLAdapter class in o.a.c.form.util. It
>>> does handles form serialization/deserialization in XML. AFAIK it
>>> doesn't keep state, but this could easily be added.
>>
>>
>>
>> Thanks for the pointer! This should be very helpful, if I go this way.
>>
>> Is there anything else that is necessary to _completly_ describe the
>> state of a form, except the value and the "visibility state"? (events,
>> validation errors, ...?)
>
>
>
> Events are inherently transient (i.e. they are produced and consumed as
> part of the processing of a request). Validation errors are part of the
> global state of a form, as non-active widgets will loose their value and
> any validation as they don't read their value on the request.
>
> You also have to include <fd:repeater-size> in your form template so
> that the size of repeaters is transmitted back and forth as a hidden input.
ok, so we need following information to describe the state of a form:
1. widget value
2. widget visibility state
3. validation errors
4. repeater size
This means that I would have to enhance XMLAdapter to save this information too.
Then I would extend the FormsTransformer to add a hidden input field that
contains the compressed and encrypted XML.
When the request comes back to the server, the controller checks for the hidden
field and deserializes it.
Does this sound reasonable?
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [cforms] Widget states in request-scoped forms
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Sylvain Wallez wrote:
>
>>> Another idea I had is, that I could work on making the form object
>>> serializable and save the state in a hidden form field. The price to
>>> pay would be increased network traffic but the advantage of a
>>> stateless presentation layer wouldn't get lost. Hmmm the more I
>>> think about it the more I like this idea .... wdot?
>>
>>
>> You should have a look at the XMLAdapter class in o.a.c.form.util. It
>> does handles form serialization/deserialization in XML. AFAIK it
>> doesn't keep state, but this could easily be added.
>
>
> Thanks for the pointer! This should be very helpful, if I go this way.
>
> Is there anything else that is necessary to _completly_ describe the
> state of a form, except the value and the "visibility state"? (events,
> validation errors, ...?)
Events are inherently transient (i.e. they are produced and consumed as
part of the processing of a request). Validation errors are part of the
global state of a form, as non-active widgets will loose their value and
any validation as they don't read their value on the request.
You also have to include <fd:repeater-size> in your form template so
that the size of repeaters is transmitted back and forth as a hidden input.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [cforms] Widget states in request-scoped forms
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
>> Another idea I had is, that I could work on making the form object
>> serializable and save the state in a hidden form field. The price to
>> pay would be increased network traffic but the advantage of a
>> stateless presentation layer wouldn't get lost. Hmmm the more I think
>> about it the more I like this idea .... wdot?
>
> You should have a look at the XMLAdapter class in o.a.c.form.util. It
> does handles form serialization/deserialization in XML. AFAIK it doesn't
> keep state, but this could easily be added.
Thanks for the pointer! This should be very helpful, if I go this way.
Is there anything else that is necessary to _completly_ describe the state of a
form, except the value and the "visibility state"? (events, validation errors, ...?)
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [cforms] Widget states in request-scoped forms
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Bruno Dumon wrote:
>
>> On Tue, 2005-03-15 at 09:11 +0100, Reinhard Poetz wrote:
>>
>>> if the widget is invisible, there is no request value any more and
>>> as the form is not saved in the session, the widget loses its value.
>>
>>
>>
>> Yep, though I'd say that's not a bug but a limitation. If you choose to
>> work stateless, there are some features you loose (for example, value
>> changed events won't do anything meaningful either).
>
>
> In particular the value changed event works for me as long as I don't
> change the widget's state. But you're right, saving the form in the
> request-scope brings some limitations.
Ah ok, I understand now as I missed the fact that you were using
stateless forms. Yes, in this context there are some strong limitations
on what you can use.
> I try to find these limitations and then I can decide together with my
> customer what we will do.
Yes. We could even add some code in CForms so that a Form knows whether
it runs in stateful or stateless mode and can then throw meaningful
exceptions when a statefull feature is used in stateless mode.
> Another idea I had is, that I could work on making the form object
> serializable and save the state in a hidden form field. The price to
> pay would be increased network traffic but the advantage of a
> stateless presentation layer wouldn't get lost. Hmmm the more I think
> about it the more I like this idea .... wdot?
You should have a look at the XMLAdapter class in o.a.c.form.util. It
does handles form serialization/deserialization in XML. AFAIK it doesn't
keep state, but this could easily be added.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [cforms] Widget states in request-scoped forms
Posted by Reinhard Poetz <re...@apache.org>.
Bruno Dumon wrote:
> On Tue, 2005-03-15 at 09:11 +0100, Reinhard Poetz wrote:
>
>>Sylvain Wallez wrote:
>>
>>>Reinhard Poetz wrote:
>>>
>>>
>>>>Sylvain Wallez wrote:
>>>>
>>>>
>>>>>Reinhard Poetz wrote:
>>>>>
>>>>>
>>>>>>Today I've tried to run a form that uses the widget state
>>>>>>"INVISIBLE" and when the form state is saved in the request. (my
>>>>>>experiments are based on the form1 action example)
>>>>>>
>>>>>>If I use the event framework to change the state from ACTIVE to
>>>>>>INVISIBLE, toggling works, but the value of the changed widget gets
>>>>>>lost.
>>>>>>
>>>>>>Looking at the samples I can't figure out ...
>>>>>>
>>>>>>- How can a widget have the state "INVISIBLE"? Where is this
>>>>>>information stored, or better from where is it read?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Have a look at AbstractWidget.{get|set|getCombined}State() and also
>>>>>at WidgetState.
>>>>>
>>>>>
>>>>>>- If I'm right and the described behavior (losing the values of
>>>>>>INVISIBLE widgets) is a bug, how can it be fixed? Any ideas?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>If it behaves as you describe it, then yes it's a bug. A field only
>>>>>reads its value when in ACTIVE state, and keeps its current value
>>>>>otherwise.
>>>>
>>>>
>>>>
>>>>and here seems to be the bug: the inactive widget can't keep its state
>>>>as its state would have to be available as request parameter and this
>>>>never comes (as it's inactive).
>>>
>>>
>>>
>>>Hmm... before being invisible, the widget is active, no? So that means
>>>that its value is submitted along with the action that will change the
>>>state. So, except if you have some fancy layout, it should read its
>>>value before having its state changed.
>>
>>I assume that it works so far but ...
>>
>>
>>>And later, once invisible, the widget doesn't read its value on the
>>>request.
>>
>>if the widget is invisible, there is no request value any more and as the form
>>is not saved in the session, the widget loses its value.
>
>
> Yep, though I'd say that's not a bug but a limitation. If you choose to
> work stateless, there are some features you loose (for example, value
> changed events won't do anything meaningful either).
In particular the value changed event works for me as long as I don't change the
widget's state. But you're right, saving the form in the request-scope brings
some limitations.
I try to find these limitations and then I can decide together with my customer
what we will do.
Another idea I had is, that I could work on making the form object serializable
and save the state in a hidden form field. The price to pay would be increased
network traffic but the advantage of a stateless presentation layer wouldn't get
lost. Hmmm the more I think about it the more I like this idea .... wdot?
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [cforms] Widget states in request-scoped forms
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2005-03-15 at 09:11 +0100, Reinhard Poetz wrote:
> Sylvain Wallez wrote:
> > Reinhard Poetz wrote:
> >
> >> Sylvain Wallez wrote:
> >>
> >>> Reinhard Poetz wrote:
> >>>
> >>>>
> >>>> Today I've tried to run a form that uses the widget state
> >>>> "INVISIBLE" and when the form state is saved in the request. (my
> >>>> experiments are based on the form1 action example)
> >>>>
> >>>> If I use the event framework to change the state from ACTIVE to
> >>>> INVISIBLE, toggling works, but the value of the changed widget gets
> >>>> lost.
> >>>>
> >>>> Looking at the samples I can't figure out ...
> >>>>
> >>>> - How can a widget have the state "INVISIBLE"? Where is this
> >>>> information stored, or better from where is it read?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Have a look at AbstractWidget.{get|set|getCombined}State() and also
> >>> at WidgetState.
> >>>
> >>>> - If I'm right and the described behavior (losing the values of
> >>>> INVISIBLE widgets) is a bug, how can it be fixed? Any ideas?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> If it behaves as you describe it, then yes it's a bug. A field only
> >>> reads its value when in ACTIVE state, and keeps its current value
> >>> otherwise.
> >>
> >>
> >>
> >> and here seems to be the bug: the inactive widget can't keep its state
> >> as its state would have to be available as request parameter and this
> >> never comes (as it's inactive).
> >
> >
> >
> > Hmm... before being invisible, the widget is active, no? So that means
> > that its value is submitted along with the action that will change the
> > state. So, except if you have some fancy layout, it should read its
> > value before having its state changed.
>
> I assume that it works so far but ...
>
> >
> > And later, once invisible, the widget doesn't read its value on the
> > request.
>
> if the widget is invisible, there is no request value any more and as the form
> is not saved in the session, the widget loses its value.
Yep, though I'd say that's not a bug but a limitation. If you choose to
work stateless, there are some features you loose (for example, value
changed events won't do anything meaningful either).
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [cforms] Widget states in request-scoped forms
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> Reinhard Poetz wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Reinhard Poetz wrote:
>>>
>>>>
>>>> Today I've tried to run a form that uses the widget state
>>>> "INVISIBLE" and when the form state is saved in the request. (my
>>>> experiments are based on the form1 action example)
>>>>
>>>> If I use the event framework to change the state from ACTIVE to
>>>> INVISIBLE, toggling works, but the value of the changed widget gets
>>>> lost.
>>>>
>>>> Looking at the samples I can't figure out ...
>>>>
>>>> - How can a widget have the state "INVISIBLE"? Where is this
>>>> information stored, or better from where is it read?
>>>
>>>
>>>
>>>
>>>
>>> Have a look at AbstractWidget.{get|set|getCombined}State() and also
>>> at WidgetState.
>>>
>>>> - If I'm right and the described behavior (losing the values of
>>>> INVISIBLE widgets) is a bug, how can it be fixed? Any ideas?
>>>
>>>
>>>
>>>
>>>
>>> If it behaves as you describe it, then yes it's a bug. A field only
>>> reads its value when in ACTIVE state, and keeps its current value
>>> otherwise.
>>
>>
>>
>> and here seems to be the bug: the inactive widget can't keep its state
>> as its state would have to be available as request parameter and this
>> never comes (as it's inactive).
>
>
>
> Hmm... before being invisible, the widget is active, no? So that means
> that its value is submitted along with the action that will change the
> state. So, except if you have some fancy layout, it should read its
> value before having its state changed.
I assume that it works so far but ...
>
> And later, once invisible, the widget doesn't read its value on the
> request.
if the widget is invisible, there is no request value any more and as the form
is not saved in the session, the widget loses its value.
>>> However, a field does read its value from the request when switched
>>> from ACTIVE to INVISIBLE: Form.readFromRequest() traverses the whole
>>> widget tree and buffers any event occuring during this phase and
>>> fires them when after traversal. This is needed for the widget tree
>>> to be globally consistent when listeners are called.
>>>
>>> Maybe you're experiencing such a condition, i.e. the http submit that
>>> changes to inactive state doesn't contain the appropriate parameter?
>>
>>
>>
>> think so. the value of the invisible widget can't be set as it isn't
>> available (at least looking at the HTML sources makes me think so).
>
>
>
> Yes, but how is the HTML before doing the action that makes it invisible?
As said above, I think the problem is caused when the form is redisplayed with
the invisible widget - the widget state gets lost there.
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [cforms] Widget states in request-scoped forms
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Sylvain Wallez wrote:
>
>> Reinhard Poetz wrote:
>>
>>>
>>> Today I've tried to run a form that uses the widget state
>>> "INVISIBLE" and when the form state is saved in the request. (my
>>> experiments are based on the form1 action example)
>>>
>>> If I use the event framework to change the state from ACTIVE to
>>> INVISIBLE, toggling works, but the value of the changed widget gets
>>> lost.
>>>
>>> Looking at the samples I can't figure out ...
>>>
>>> - How can a widget have the state "INVISIBLE"? Where is this
>>> information stored, or better from where is it read?
>>
>>
>>
>>
>> Have a look at AbstractWidget.{get|set|getCombined}State() and also
>> at WidgetState.
>>
>>> - If I'm right and the described behavior (losing the values of
>>> INVISIBLE widgets) is a bug, how can it be fixed? Any ideas?
>>
>>
>>
>>
>> If it behaves as you describe it, then yes it's a bug. A field only
>> reads its value when in ACTIVE state, and keeps its current value
>> otherwise.
>
>
> and here seems to be the bug: the inactive widget can't keep its state
> as its state would have to be available as request parameter and this
> never comes (as it's inactive).
Hmm... before being invisible, the widget is active, no? So that means
that its value is submitted along with the action that will change the
state. So, except if you have some fancy layout, it should read its
value before having its state changed.
And later, once invisible, the widget doesn't read its value on the request.
>> However, a field does read its value from the request when switched
>> from ACTIVE to INVISIBLE: Form.readFromRequest() traverses the whole
>> widget tree and buffers any event occuring during this phase and
>> fires them when after traversal. This is needed for the widget tree
>> to be globally consistent when listeners are called.
>>
>> Maybe you're experiencing such a condition, i.e. the http submit that
>> changes to inactive state doesn't contain the appropriate parameter?
>
>
> think so. the value of the invisible widget can't be set as it isn't
> available (at least looking at the HTML sources makes me think so).
Yes, but how is the HTML before doing the action that makes it invisible?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [cforms] Widget states in request-scoped forms
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> Reinhard Poetz wrote:
>
>>
>> Today I've tried to run a form that uses the widget state "INVISIBLE"
>> and when the form state is saved in the request. (my experiments are
>> based on the form1 action example)
>>
>> If I use the event framework to change the state from ACTIVE to
>> INVISIBLE, toggling works, but the value of the changed widget gets lost.
>>
>> Looking at the samples I can't figure out ...
>>
>> - How can a widget have the state "INVISIBLE"? Where is this
>> information stored, or better from where is it read?
>
>
>
> Have a look at AbstractWidget.{get|set|getCombined}State() and also at
> WidgetState.
>
>> - If I'm right and the described behavior (losing the values of
>> INVISIBLE widgets) is a bug, how can it be fixed? Any ideas?
>
>
>
> If it behaves as you describe it, then yes it's a bug. A field only
> reads its value when in ACTIVE state, and keeps its current value
> otherwise.
and here seems to be the bug: the inactive widget can't keep its state as its
state would have to be available as request parameter and this never comes (as
it's inactive).
>
> However, a field does read its value from the request when switched from
> ACTIVE to INVISIBLE: Form.readFromRequest() traverses the whole widget
> tree and buffers any event occuring during this phase and fires them
> when after traversal. This is needed for the widget tree to be globally
> consistent when listeners are called.
>
> Maybe you're experiencing such a condition, i.e. the http submit that
> changes to inactive state doesn't contain the appropriate parameter?
think so. the value of the invisible widget can't be set as it isn't available
(at least looking at the HTML sources makes me think so).
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [cforms] Widget states in request-scoped forms
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
>
> Today I've tried to run a form that uses the widget state "INVISIBLE"
> and when the form state is saved in the request. (my experiments are
> based on the form1 action example)
>
> If I use the event framework to change the state from ACTIVE to
> INVISIBLE, toggling works, but the value of the changed widget gets lost.
>
> Looking at the samples I can't figure out ...
>
> - How can a widget have the state "INVISIBLE"? Where is this
> information stored, or better from where is it read?
Have a look at AbstractWidget.{get|set|getCombined}State() and also at
WidgetState.
> - If I'm right and the described behavior (losing the values of
> INVISIBLE widgets) is a bug, how can it be fixed? Any ideas?
If it behaves as you describe it, then yes it's a bug. A field only
reads its value when in ACTIVE state, and keeps its current value otherwise.
However, a field does read its value from the request when switched from
ACTIVE to INVISIBLE: Form.readFromRequest() traverses the whole widget
tree and buffers any event occuring during this phase and fires them
when after traversal. This is needed for the widget tree to be globally
consistent when listeners are called.
Maybe you're experiencing such a condition, i.e. the http submit that
changes to inactive state doesn't contain the appropriate parameter?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [cforms] Widget states in request-scoped forms
Posted by Sylvain Wallez <sy...@apache.org>.
Tim Larson wrote:
>On Mon, Mar 14, 2005 at 09:44:44PM +0100, Reinhard Poetz wrote:
>
>
>>Today I've tried to run a form that uses the widget state "INVISIBLE" and
>>when the form state is saved in the request. (my experiments are based on
>>the form1 action example)
>>
>>If I use the event framework to change the state from ACTIVE to INVISIBLE,
>>toggling works, but the value of the changed widget gets lost.
>>
>>Looking at the samples I can't figure out ...
>>
>>- How can a widget have the state "INVISIBLE"? Where is this information
>>stored, or better from where is it read?
>>
>>- If I'm right and the described behavior (losing the values of INVISIBLE
>>widgets) is a bug, how can it be fixed? Any ideas?
>>
>>
>
>I do not know if it is the same bug or not, but I re-encountered the bug
>that made me temporarily change fireEvents to be public so it could be
>called from flowscript (iirc it was reverted when I forgot how to trigger
>the bug.)
>
That's me who reverted this as I did not understood the need for making
it public.
>The bug is that the firing of events sometimes get delayed
>until after showForm returns, causing very strange behavior. Sorry I
>have not had time yet to track down the source of the problem.
>
>
Ok. Let's wait until 2.1.7 is out and we will then add some code to
check if there are some buffered when there normally should be none, and
throw an exception in that case. That should quickly show where the
problem is :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [cforms] Widget states in request-scoped forms
Posted by Tim Larson <ti...@keow.org>.
On Mon, Mar 14, 2005 at 09:44:44PM +0100, Reinhard Poetz wrote:
>
> Today I've tried to run a form that uses the widget state "INVISIBLE" and
> when the form state is saved in the request. (my experiments are based on
> the form1 action example)
>
> If I use the event framework to change the state from ACTIVE to INVISIBLE,
> toggling works, but the value of the changed widget gets lost.
>
> Looking at the samples I can't figure out ...
>
> - How can a widget have the state "INVISIBLE"? Where is this information
> stored, or better from where is it read?
>
> - If I'm right and the described behavior (losing the values of INVISIBLE
> widgets) is a bug, how can it be fixed? Any ideas?
I do not know if it is the same bug or not, but I re-encountered the bug
that made me temporarily change fireEvents to be public so it could be
called from flowscript (iirc it was reverted when I forgot how to trigger
the bug.) The bug is that the firing of events sometimes get delayed
until after showForm returns, causing very strange behavior. Sorry I
have not had time yet to track down the source of the problem. Sounds
like there is at least a chance this is related to your problem.
--Tim Larson