Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
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'])
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 so > 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 [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
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 so important ;-)
Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
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 [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
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 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 [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
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'])
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'])
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 ? 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'])
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 [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
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 [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
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