RE: CONTRIBUTION: forms-calendar-styling defect when widget disabled
> There is, but it's pure HTML. It has nothing to do with > CForms. Unknown > attributes on fi:styling are just copied to the output, e.g. > @class and also @readonly. > This is still true. I had a look at the stylesheets when this topic was on. Bye, Helma
Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled
On 15.03.2005 23:33, Sylvain Wallez wrote: Again and again, there is no such "readonly" attribute. You can set the state of a widget to "disabled" which leads to something similar to what you describe: the input is readonly, and the calendar icon is still visible but disabled. There is, but it's pure HTML. It has nothing to do with CForms. Unknown attributes on fi:styling are just copied to the output, e.g. @class and also @readonly. I did not have a look at CForms since the adding of the states, so I don't know how much in the meantime is handled automatically and no longer in the template. Joerg
Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled
depub2 wrote: Pardon me, but I appreciate all of your discussion about this... I simply ask that you place TWO LINES OF CODE in forms-calendar-styling.xsl to support hidden and disabled widgets associated with calendars. We have discussed this issue at length and decided how it would be handled to be consistent with the CForms widget model and widget states. As an extra convenience to me and other users, I'd also appreciate it if you also include the passthru readonly test - no direct widget support needed; security concerns not relevant - just keeping simple users from getting confused, not trying to protect from hackers. Impact of adding support for readonly=NONE. Yes, confusion. All widgets react to the "disabled" state and there is no "readonly" state. Adding such a state specifically on the calendar popup will just add confusion. Now if you want to use a different rendering and/or behaviour in your application, use a locally-modified version of the CForms stylesheets. These XSLs are provided in the samples directory and are architected in a modular way exactly for this: to allow easy customization if the HTML they produce doesn't match your rendering needs. David "Just do it - Nike" "Sure, but do it well - Sylvain" -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
RE: CONTRIBUTION: forms-calendar-styling defect when widget disabled
Pardon me, but I appreciate all of your discussion about this... I simply ask that you place TWO LINES OF CODE in forms-calendar-styling.xsl to support hidden and disabled widgets associated with calendars. As an extra convenience to me and other users, I'd also appreciate it if you also include the passthru readonly test - no direct widget support needed; security concerns not relevant - just keeping simple users from getting confused, not trying to protect from hackers. Impact of adding support for readonly=NONE. David "Just do it - Nike" The change was simple, in cocoon/samples/blocks/forms/resources/forms-calendar-styling.xsl I added: around the calendar HTML anchor.The modified code segment in that file now reads: All that I added was the surrounding block. It works great!! > >So, to sum it up: "readonly" as attribute is supported in > the current > >version of the styling XSL files, but there will be no > widget support > >for this due to security issues. If treatment of the "readonly" > >attribute should differ from the current situation, it is up to the > >user to modify the styling XSL files. > > > > > > Exactly. Very good summary! > > Furthermore, the choice between readonly/disabled is IMO really a > presentation concern, and not an application concern. That's why I > consider that distinguishing them at the widget level by > introducing an additional state would be useless. So there is one action left: where do we put this information to inform the original requester and to avoid a recycle of this discussion? Bye, Helma
RE: CONTRIBUTION: forms-calendar-styling defect when widget disabled
> >So, to sum it up: "readonly" as attribute is supported in > the current > >version of the styling XSL files, but there will be no > widget support > >for this due to security issues. If treatment of the "readonly" > >attribute should differ from the current situation, it is up to the > >user to modify the styling XSL files. > > > > > > Exactly. Very good summary! > > Furthermore, the choice between readonly/disabled is IMO really a > presentation concern, and not an application concern. That's why I > consider that distinguishing them at the widget level by > introducing an additional state would be useless. So there is one action left: where do we put this information to inform the original requester and to avoid a recycle of this discussion? Bye, Helma
Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled
Linden H van der (MI) wrote: Reading the HTML spec [1], the difference between disabled and readonly are: - readonly is only available on and . disabled is available on all controls - readonly sends back the value to the server, which is of no use if the widget is not active - readonly inputs receive focus and are includes in tab navigation. What's the purpose of this is the value can't be changed? The only purpose I can think of is accessibility: I can imagine that reading out loud text vs a readonly input field/textarea is different. And it can also have a shortcut key, which output widgets displayed as "plain" text don't have, for quick(er) navigation. The HTML disabled state seems to me to match closely with the CForms disabled state, as it applies to a wider range of controls and doesn't send back the value to the server. Agreed. Now if people want to use HTML readonly, they can do it on active widgets (which won't loose their value because it's sent back) by adding a . This works because the stylesheets copy verbatim their unknown attributes to the produced HTML element. Agree. The only point in the discussion was that they liked different styling based on the presence/absence of the "readonly" attribute. Now from a security POV, using HTML readonly is risky as nothing prevents the value to be modified before being sent back, either by some injected javascript (very hyped nowadays to hack gmail and google maps) or some forged request. :-( Good point. So, to sum it up: "readonly" as attribute is supported in the current version of the styling XSL files, but there will be no widget support for this due to security issues. If treatment of the "readonly" attribute should differ from the current situation, it is up to the user to modify the styling XSL files. Exactly. Very good summary! Furthermore, the choice between readonly/disabled is IMO really a presentation concern, and not an application concern. That's why I consider that distinguishing them at the widget level by introducing an additional state would be useless. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
RE: CONTRIBUTION: forms-calendar-styling defect when widget disabled
> Reading the HTML spec [1], the difference between disabled > and readonly are: > - readonly is only available on and . disabled is > available on all controls > - readonly sends back the value to the server, which is of no > use if the > widget is not active > - readonly inputs receive focus and are includes in tab navigation. > What's the purpose of this is the value can't be changed? The only purpose I can think of is accessibility: I can imagine that reading out loud text vs a readonly input field/textarea is different. And it can also have a shortcut key, which output widgets displayed as "plain" text don't have, for quick(er) navigation. > The HTML disabled state seems to me to match closely with the CForms > disabled state, as it applies to a wider range of controls > and doesn't send back the value to the server. Agreed. > Now if people want to use HTML readonly, they can do it on active > widgets (which won't loose their value because it's sent > back) by adding > a . This works because the > stylesheets > copy verbatim their unknown attributes to the produced HTML element. Agree. The only point in the discussion was that they liked different styling based on the presence/absence of the "readonly" attribute. > Now from a security POV, using HTML readonly is risky as nothing > prevents the value to be modified before being sent back, > either by some injected javascript (very hyped nowadays to hack gmail and > google maps) or some forged request. :-( Good point. So, to sum it up: "readonly" as attribute is supported in the current version of the styling XSL files, but there will be no widget support for this due to security issues. If treatment of the "readonly" attribute should differ from the current situation, it is up to the user to modify the styling XSL files. WDYT? Bye, Helma
Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled
Linden H van der (MI) wrote: Ok. He can add whatever attribute to his styling, the stylesheets are True. built for this, but I don't want to see this "readonly" attribute handled in the stylesheets, as we have other mechanisms for this, namely widget states. Agree, however, "readonly" is part of the HTML textarea specification. IIRC there is a slight difference between "disabled" and "readonly". The first one is addressed by widget states, the latter is not. Reading the HTML spec [1], the difference between disabled and readonly are: - readonly is only available on and . disabled is available on all controls - readonly sends back the value to the server, which is of no use if the widget is not active - readonly inputs receive focus and are includes in tab navigation. What's the purpose of this is the value can't be changed? The HTML disabled state seems to me to match closely with the CForms disabled state, as it applies to a wider range of controls and doesn't send back the value to the server. Now if people want to use HTML readonly, they can do it on active widgets (which won't loose their value because it's sent back) by adding a . This works because the stylesheets copy verbatim their unknown attributes to the produced HTML element. Now from a security POV, using HTML readonly is risky as nothing prevents the value to be modified before being sent back, either by some injected javascript (very hyped nowadays to hack gmail and google maps) or some forged request. Sylvain [1] http://www.w3.org/TR/html401/interact/forms.html#h-17.12 -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
RE: CONTRIBUTION: forms-calendar-styling defect when widget disabled
> Ok. He can add whatever attribute to his styling, the stylesheets are True. > built for this, but I don't want to see this "readonly" attribute > handled in the stylesheets, as we have other mechanisms for > this, namely widget states. Agree, however, "readonly" is part of the HTML textarea specification. IIRC there is a slight difference between "disabled" and "readonly". The first one is addressed by widget states, the latter is not. > It's important to use widget states for this not only for > consistency, > but also because non-active (i.e. disabled/output/hidden) > widget states > instruct the widget not to read its value from the request, > which would otherwise reset their value. Agree. > I am still missing something? Well... Reading the HTML textarea specs on "readonly" I get the impression that it is not covered by any widget state. Of course there is the "artistic freedom" to define your own states, but I think that CForm widgets should at least be able to result in all possible HTML state variations as they are defined. Even more so when the general idea of CForms is to overcome the limits of HTML form fields. Just my 2 cents. Bye, Helma
Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled
Linden H van der (MI) wrote: Sylvain, I think he means that adding "readonly='readonly'" as attribute to his own tag is passed through the styling XSL files. IIRC there is a template that deals with extra attributes in the styling tag. Ok. He can add whatever attribute to his styling, the stylesheets are built for this, but I don't want to see this "readonly" attribute handled in the stylesheets, as we have other mechanisms for this, namely widget states. It's important to use widget states for this not only for consistency, but also because non-active (i.e. disabled/output/hidden) widget states instruct the widget not to read its value from the request, which would otherwise reset their value. I am still missing something? Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
RE: CONTRIBUTION: forms-calendar-styling defect when widget disabled
Sylvain, I think he means that adding "readonly='readonly'" as attribute to his own tag is passed through the styling XSL files. IIRC there is a template that deals with extra attributes in the styling tag. HTH. Bye, Helma > -Original Message- > From: Sylvain Wallez [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 15 March 2005 23:33 > To: dev@cocoon.apache.org; [EMAIL PROTECTED] > Subject: Re: CONTRIBUTION: forms-calendar-styling defect when > widget disabled > > > depub2 wrote: > > > > > > > > > Well actually, the readonly="readonly" works! Try it!!! > And there > > are some cases where disabled="disabled" is problematic > > (binding/saving) and I think something else I can't > remember right > > now (pulldown selections? calendar selections? - can't > remember). > > (note {at-symbol} above must be translated to @ - seems that > > symbol is not allowed on the archives.) > > > > > > > > Sorry, but I really don't know what you're talking about. Is this > > 'readonly' in the binding? If so, what's the relation with > the styling > > XSLs?? > > > > It is in the template file, tag. I believe that > > readonly="readonly" simply gets passed along as an attribute to the > > "input" tag and is valid xhtml which the browser then > interprets to be > > like disabled="disabled", but slightly different. Here's an > example usage: > > > > > >cols="75" > > wrap="hard" > > class="DocOrdersStatusMessage"/> > > > > > Again, I can't find it. If the forms/samples directory: > $ find . -type f | xargs grep readonly > ./forms/binding/01value-bind.xml: ./forms/binding/01value-def.xml: > > The only "readonly" in the whole CForms samples (which > include the XSLs) > is the name of a widget. > > Can you please give me the URL of the relevant file under > http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/s rc/blocks/forms/ > Anyway, inserting that small code segment in the source (see below) > and then playing with the samples to disable the calendar widget will > show you what I mean - and try readonly as a styling attribute to see > that at work too. Then try disabling the calendar without my > modifications and you'll notice that the date can be changed, even > though the widget is disabled. Again and again, there is no such "readonly" attribute. You can set the state of a widget to "disabled" which leads to something similar to what you describe: the input is readonly, and the calendar icon is still visible but disabled. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled
depub2 wrote: Well actually, the readonly="readonly" works! Try it!!! And there are some cases where disabled="disabled" is problematic (binding/saving) and I think something else I can't remember right now (pulldown selections? calendar selections? - can't remember). (note {at-symbol} above must be translated to @ - seems that symbol is not allowed on the archives.) Sorry, but I really don't know what you're talking about. Is this 'readonly' in the binding? If so, what's the relation with the styling XSLs?? It is in the template file, tag. I believe that readonly="readonly" simply gets passed along as an attribute to the "input" tag and is valid xhtml which the browser then interprets to be like disabled="disabled", but slightly different. Here's an example usage: class="DocOrdersStatusMessage"/> Again, I can't find it. If the forms/samples directory: $ find . -type f | xargs grep readonly ./forms/binding/01value-bind.xml: The only "readonly" in the whole CForms samples (which include the XSLs) is the name of a widget. Can you please give me the URL of the relevant file under http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/blocks/forms/ Anyway, inserting that small code segment in the source (see below) and then playing with the samples to disable the calendar widget will show you what I mean - and try readonly as a styling attribute to see that at work too. Then try disabling the calendar without my modifications and you'll notice that the date can be changed, even though the widget is disabled. Again and again, there is no such "readonly" attribute. You can set the state of a widget to "disabled" which leads to something similar to what you describe: the input is readonly, and the calendar icon is still visible but disabled. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
RE: Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled WAS repeater-widget (insert row): InsertRowsActionDefinition
Title: Message Sounds like a good idea. Since I'm working on the styling XSL sheets anyway, should I include this? Bye, Helma -Original Message-From: depub2 [mailto:[EMAIL PROTECTED] Sent: Tuesday, 15 March 2005 19:58To: CocoonDev; [EMAIL PROTECTED]Subject: RE: Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled WAS repeater-widget (insert row): InsertRowsActionDefinition Well actually, the readonly="readonly" works! Try it!!! And there are some cases where disabled="disabled" is problematic (binding/saving) and I think something else I can't remember right now (pulldown selections? calendar selections? - can't remember). (note {at-symbol} above must be translated to @ - seems that symbol is not allowed on the archives.) Sorry, but I really don't know what you're talking about. Is this 'readonly' in the binding? If so, what's the relation with the styling XSLs?? It is in the template file, tag. I believe that readonly="readonly" simply gets passed along as an attribute to the "input" tag and is valid xhtml which the browser then interprets to be like disabled="disabled", but slightly different. Here's an example usage: class="DocOrdersStatusMessage"/> Anyway, inserting that small code segment in the source (see below) and then playing with the samples to disable the calendar widget will show you what I mean - and try readonly as a styling attribute to see that at work too. Then try disabling the calendar without my modifications and you'll notice that the date can be changed, even though the widget is disabled. Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Also, I have a "2 line" minor tweak to the forms-calendar-styling.xsl that disables the "calendar icon/popup" when a datetype="date" widget is set to readonly, disabled, or hidden (in these cases, we don't want an icon or popup - ESPECIALLY when the widget is supposed to be "hidden").The change was simple, in cocoon/samples/blocks/forms/resources/forms-calendar-styling.xslI added: around the calendar HTML anchor.The modified code segment in that file now reads: All that I added was the surrounding block. It works great!!Should I move this to a separate CONTRIBUTION thread or is this simpleenough that you would just get it into the cvs archive??
RE: Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled WAS repeater-widget (insert row): InsertRowsActionDefinition
Well actually, the readonly="readonly" works! Try it!!! And there are some cases where disabled="disabled" is problematic (binding/saving) and I think something else I can't remember right now (pulldown selections? calendar selections? - can't remember). (note {at-symbol} above must be translated to @ - seems that symbol is not allowed on the archives.) Sorry, but I really don't know what you're talking about. Is this 'readonly' in the binding? If so, what's the relation with the styling XSLs?? It is in the template file, tag. I believe that readonly="readonly" simply gets passed along as an attribute to the "input" tag and is valid xhtml which the browser then interprets to be like disabled="disabled", but slightly different. Here's an example usage: class="DocOrdersStatusMessage"/> Anyway, inserting that small code segment in the source (see below) and then playing with the samples to disable the calendar widget will show you what I mean - and try readonly as a styling attribute to see that at work too. Then try disabling the calendar without my modifications and you'll notice that the date can be changed, even though the widget is disabled. Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Also, I have a "2 line" minor tweak to the forms-calendar-styling.xsl that disables the "calendar icon/popup" when a datetype="date" widget is set to readonly, disabled, or hidden (in these cases, we don't want an icon or popup - ESPECIALLY when the widget is supposed to be "hidden").The change was simple, in cocoon/samples/blocks/forms/resources/forms-calendar-styling.xslI added: around the calendar HTML anchor.The modified code segment in that file now reads: All that I added was the surrounding block. It works great!!Should I move this to a separate CONTRIBUTION thread or is this simpleenough that you would just get it into the cvs archive??