You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2004/04/27 08:30:16 UTC
Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
Joerg Heinicke wrote:
> On 26.04.2004 23:43, Sylvain Wallez wrote:
>
>>> They would also be reset after request.
>>>
>>> These stylings make only sense if the form widget values are not
>>> evaluated. I can imagine a confirmation page, where just the submit
>>> widget (ok vs. cancel) is evaluated.
>>
>>
>> BooleanField is special as "no parameter" means "false", but for
>> regular Fields, what do you think about not resetting the value to
>> null if the request parameter is not present? This would make
>> @type="output" more useful than it is today.
>
>
> I would like to see a more explicite setting for this behaviour - and
> also supporting all widget types. We already talked a bit about a
> direction="save|load|both" for the field definition in relation to
> reading the values from request. This would replace fd:output and
> styling="output" with the above mentioned consequences.
Having this handled by a widget state rather than a particular styling
sounds better. But although save/load/both makes sense for the binding,
it doesn't IMO fit for widgets. What's the meaning of a widget in
"save-only" mode? A widget that can be given a value by the user but
which is never output by the application? It doesn't make sense.
At the time where we discussed this, I proposed active/disabled/hidden,
which is more traditional for GUI widgets:
- active is the normal behaviour (what we have today)
- disabled is like @type=output with the additional behaviour that the
request parameter isn't considered (avoids hacking using forged requests)
- hidden means that the widget doesn't output its SAX fragment,
effectively hiding the value along with ignoring the request parameter
as in disabled state.
This kind of feature is a must-have for complex workflows or
authorization schemes as it allows a single form and template to be
easily adjusted to the authorized visibility and modification, depending
on the application context.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Widget states again (was Re:
fi:booleanfield[fi:styling/@type='output'])
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2004-04-27 at 08:30, Sylvain Wallez wrote:
> Joerg Heinicke wrote:
>
> > On 26.04.2004 23:43, Sylvain Wallez wrote:
> >
> >>> They would also be reset after request.
> >>>
> >>> These stylings make only sense if the form widget values are not
> >>> evaluated. I can imagine a confirmation page, where just the submit
> >>> widget (ok vs. cancel) is evaluated.
> >>
> >>
> >> BooleanField is special as "no parameter" means "false", but for
> >> regular Fields, what do you think about not resetting the value to
> >> null if the request parameter is not present? This would make
> >> @type="output" more useful than it is today.
> >
> >
> > I would like to see a more explicite setting for this behaviour - and
> > also supporting all widget types. We already talked a bit about a
> > direction="save|load|both" for the field definition in relation to
> > reading the values from request. This would replace fd:output and
> > styling="output" with the above mentioned consequences.
>
>
> Having this handled by a widget state rather than a particular styling
> sounds better. But although save/load/both makes sense for the binding,
> it doesn't IMO fit for widgets. What's the meaning of a widget in
> "save-only" mode? A widget that can be given a value by the user but
> which is never output by the application? It doesn't make sense.
>
> At the time where we discussed this, I proposed active/disabled/hidden,
> which is more traditional for GUI widgets:
> - active is the normal behaviour (what we have today)
maybe "enabled" is better as name, opposite of disabled?
> - disabled is like @type=output with the additional behaviour that the
> request parameter isn't considered (avoids hacking using forged requests)
> - hidden means that the widget doesn't output its SAX fragment,
> effectively hiding the value along with ignoring the request parameter
> as in disabled state.
>
> This kind of feature is a must-have for complex workflows or
> authorization schemes as it allows a single form and template to be
> easily adjusted to the authorized visibility and modification, depending
> on the application context.
So I presume the goal is to make this adjustable on the instance-level.
I see no problem when doing this as a one-time configuration after
creation of the form. I imagine people will however be changing this
dynamically also, i.e. between form submits. This might then give
troubles (or unexpected results) if a user goes back and submits an old
form, i.e. one in which a few widgets were disabled, to a form instance
where now those widgets are enabled. I see this mostly as a problem the
application developer should handle.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
Posted by Joerg Heinicke <jo...@gmx.de>.
On 27.04.2004 11:51, Bruno Dumon wrote:
> This makes me think: enabled/disabled has nothing to do with
> visible/invisible. The last one sounds much more like a styling concern.
> Do we need the hidden widget state at all?
Sounds good.
Joerg
Re: Widget states again (was Re:
fi:booleanfield[fi:styling/@type='output'])
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2004-04-27 at 10:31, Joerg Heinicke wrote:
> On 27.04.2004 08:30, Sylvain Wallez wrote:
>
> >> I would like to see a more explicite setting for this behaviour - and
> >> also supporting all widget types. We already talked a bit about a
> >> direction="save|load|both" for the field definition in relation to
> >> reading the values from request. This would replace fd:output and
> >> styling="output" with the above mentioned consequences.
> >
> > Having this handled by a widget state rather than a particular styling
> > sounds better. But although save/load/both makes sense for the binding,
> > it doesn't IMO fit for widgets.
>
> I did not want to propose direction="save|load|both" for the definition,
> it was just the comparison to the current syntax in the binding.
>
> > What's the meaning of a widget in
> > "save-only" mode? A widget that can be given a value by the user but
> > which is never output by the application? It doesn't make sense.
>
> Password fields :)
>
> > At the time where we discussed this, I proposed active/disabled/hidden,
> > which is more traditional for GUI widgets:
> > - active is the normal behaviour (what we have today)
> > - disabled is like @type=output with the additional behaviour that the
> > request parameter isn't considered (avoids hacking using forged requests)
> > - hidden means that the widget doesn't output its SAX fragment,
> > effectively hiding the value along with ignoring the request parameter
> > as in disabled state.
>
> Do you mean no SAX fragment at all, i.e. not even <input
> type="hidden"/>?
Yes, I'd interpret it that way.
hidden = disabled + invisible
> Of course we preserve the state server side, i.e. the
> value round trip through the form like before-cforms-times is not
> needed, but some scripts might need the value.
the value of disabled/hidden widgets shouldn't be changeable by
processing a client request.
It is true that such widgets are less useful in stateless scenario's,
but that's the case with the output widget today already.
If you want the state to come back from the request, use an enabled
widget but with an appropriate styling option to hide it.
This makes me think: enabled/disabled has nothing to do with
visible/invisible. The last one sounds much more like a styling concern.
Do we need the hidden widget state at all?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
Posted by Joerg Heinicke <jo...@gmx.de>.
On 27.04.2004 08:30, Sylvain Wallez wrote:
>> I would like to see a more explicite setting for this behaviour - and
>> also supporting all widget types. We already talked a bit about a
>> direction="save|load|both" for the field definition in relation to
>> reading the values from request. This would replace fd:output and
>> styling="output" with the above mentioned consequences.
>
> Having this handled by a widget state rather than a particular styling
> sounds better. But although save/load/both makes sense for the binding,
> it doesn't IMO fit for widgets.
I did not want to propose direction="save|load|both" for the definition,
it was just the comparison to the current syntax in the binding.
> What's the meaning of a widget in
> "save-only" mode? A widget that can be given a value by the user but
> which is never output by the application? It doesn't make sense.
Password fields :)
> At the time where we discussed this, I proposed active/disabled/hidden,
> which is more traditional for GUI widgets:
> - active is the normal behaviour (what we have today)
> - disabled is like @type=output with the additional behaviour that the
> request parameter isn't considered (avoids hacking using forged requests)
> - hidden means that the widget doesn't output its SAX fragment,
> effectively hiding the value along with ignoring the request parameter
> as in disabled state.
Do you mean no SAX fragment at all, i.e. not even <input
type="hidden"/>? Of course we preserve the state server side, i.e. the
value round trip through the form like before-cforms-times is not
needed, but some scripts might need the value.
Joerg
Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
Posted by Joerg Heinicke <jo...@gmx.de>.
On 27.04.2004 10:19, Bruno Dumon wrote:
>>>...At the time where we discussed this, I proposed
>>>active/disabled/hidden, which is more traditional for GUI widgets:
>>>- active is the normal behaviour (what we have today)
>>>- disabled is like @type=output with the additional behaviour that the
>>>request parameter isn't considered (avoids hacking using forged
>>>requests)
>>>- hidden means that the widget doesn't output its SAX fragment,
>>>effectively hiding the value along with ignoring the request parameter
>>>as in disabled state....
>>
>>Sorry to jump in suddenly, just my two cents on the terminology: I
>>think "editable / readonly / hidden" would express these widget states
>>more clearly.
>>But I don't want to interfere if you guys have been discussing this
>>already ;-)
>
> Don't remember if it's already discussed. The names you suggest make
> sense for e.g. a field widget, but would then sound strange when applied
> to eg a repeater widget (an "editable" repeater?).
I also thought of readonly first, but it makes indeed no sense for the
most widgets. I had a look at the XUL elements
(http://xulplanet.mozdev.org/references/elemref/) and they all have an
@disabled (checkbox, menu, radio, textbox, etc.). Textbox provides
additionally @readonly, menulist @editable.
I agree to Bruno's proposal: enabled (= default behaviour), disabled,
hidden.
Joerg
Re: Widget states again (was Re:
fi:booleanfield[fi:styling/@type='output'])
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2004-04-27 at 13:36, Bertrand Delacretaz wrote:
> Le 27 avr. 04, à 11:57, Bruno Dumon a écrit :
> > ...You could look at it that way, but I like enabled/disabled better
> > (IMHO)...
>
> You're the one (or one of the ones) who's doing actual work here, so
> your HO certainly wins over mine!
> I was just suggesting anyway. But I find enabled/disabled more
> consistent than Sylvain's original active/disabled proposal.
>
> -Bertrand, who doesn't want to be noisy but good names are sooooo
> important ;-)
I agree that good names are very important, so your suggestions are more
then welcome, sorry if I gave another impression. And I won't be coding
that particular thing either, so according to that rule my HO doesn't
count anymore then yours :-)
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 27 avr. 04, à 11:57, Bruno Dumon a écrit :
> ...You could look at it that way, but I like enabled/disabled better
> (IMHO)...
You're the one (or one of the ones) who's doing actual work here, so
your HO certainly wins over mine!
I was just suggesting anyway. But I find enabled/disabled more
consistent than Sylvain's original active/disabled proposal.
-Bertrand, who doesn't want to be noisy but good names are sooooo
important ;-)
Re: Widget states again (was Re:
fi:booleanfield[fi:styling/@type='output'])
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2004-04-27 at 11:44, Bertrand Delacretaz wrote:
> Le 27 avr. 04, à 10:19, Bruno Dumon a écrit :
>
> > On Tue, 2004-04-27 at 08:37, Bertrand Delacretaz wrote:
> >> Le 27 avr. 04, à 08:30, Sylvain Wallez a écrit :
> >>> ...At the time where we discussed this, I proposed
> >>> active/disabled/hidden, which is more traditional for GUI widgets:
> >>> - active is the normal behaviour (what we have today)
> >>> - disabled is like @type=output with the additional behaviour that
> >>> the
> >>> request parameter isn't considered (avoids hacking using forged
> >>> requests)
> >>> - hidden means that the widget doesn't output its SAX fragment,
> >>> effectively hiding the value along with ignoring the request
> >>> parameter
> >>> as in disabled state....
> >>
> >> Sorry to jump in suddenly, just my two cents on the terminology: I
> >> think "editable / readonly / hidden" would express these widget states
> >> more clearly.
> >> But I don't want to interfere if you guys have been discussing this
> >> already ;-)
> >
> > Don't remember if it's already discussed. The names you suggest make
> > sense for e.g. a field widget, but would then sound strange when
> > applied
> > to eg a repeater widget (an "editable" repeater?).
>
> Why not? If a repeater is a container for things, an "editable
> repeater" could be a container for "editable things" (IMHO).
You could look at it that way, but I like enabled/disabled better
(IMHO).
Or if we'd drop the hidden state, we could simply have
enabled="true/false".
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 27 avr. 04, à 10:19, Bruno Dumon a écrit :
> On Tue, 2004-04-27 at 08:37, Bertrand Delacretaz wrote:
>> Le 27 avr. 04, à 08:30, Sylvain Wallez a écrit :
>>> ...At the time where we discussed this, I proposed
>>> active/disabled/hidden, which is more traditional for GUI widgets:
>>> - active is the normal behaviour (what we have today)
>>> - disabled is like @type=output with the additional behaviour that
>>> the
>>> request parameter isn't considered (avoids hacking using forged
>>> requests)
>>> - hidden means that the widget doesn't output its SAX fragment,
>>> effectively hiding the value along with ignoring the request
>>> parameter
>>> as in disabled state....
>>
>> Sorry to jump in suddenly, just my two cents on the terminology: I
>> think "editable / readonly / hidden" would express these widget states
>> more clearly.
>> But I don't want to interfere if you guys have been discussing this
>> already ;-)
>
> Don't remember if it's already discussed. The names you suggest make
> sense for e.g. a field widget, but would then sound strange when
> applied
> to eg a repeater widget (an "editable" repeater?).
Why not? If a repeater is a container for things, an "editable
repeater" could be a container for "editable things" (IMHO).
-Bertrand
Re: Widget states again (was Re:
fi:booleanfield[fi:styling/@type='output'])
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2004-04-27 at 08:37, Bertrand Delacretaz wrote:
> Le 27 avr. 04, à 08:30, Sylvain Wallez a écrit :
> > ...At the time where we discussed this, I proposed
> > active/disabled/hidden, which is more traditional for GUI widgets:
> > - active is the normal behaviour (what we have today)
> > - disabled is like @type=output with the additional behaviour that the
> > request parameter isn't considered (avoids hacking using forged
> > requests)
> > - hidden means that the widget doesn't output its SAX fragment,
> > effectively hiding the value along with ignoring the request parameter
> > as in disabled state....
>
> Sorry to jump in suddenly, just my two cents on the terminology: I
> think "editable / readonly / hidden" would express these widget states
> more clearly.
> But I don't want to interfere if you guys have been discussing this
> already ;-)
Don't remember if it's already discussed. The names you suggest make
sense for e.g. a field widget, but would then sound strange when applied
to eg a repeater widget (an "editable" repeater?).
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 27 avr. 04, à 08:30, Sylvain Wallez a écrit :
> ...At the time where we discussed this, I proposed
> active/disabled/hidden, which is more traditional for GUI widgets:
> - active is the normal behaviour (what we have today)
> - disabled is like @type=output with the additional behaviour that the
> request parameter isn't considered (avoids hacking using forged
> requests)
> - hidden means that the widget doesn't output its SAX fragment,
> effectively hiding the value along with ignoring the request parameter
> as in disabled state....
Sorry to jump in suddenly, just my two cents on the terminology: I
think "editable / readonly / hidden" would express these widget states
more clearly.
But I don't want to interfere if you guys have been discussing this
already ;-)
-Bertrand