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
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
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:
xsl:if test=not(fi:{at-symbol}disabled='disabled'] or
fi:{at-symbol}readonly='readonly'] or fi:{at-symbol}hidden='hidden'])
around the calendar HTML anchor.The modified code segment in that file now
reads:
!-- calendar popup --
xsl:if test=not(fi:{at-symbol}disabled='disabled'] or
fi:{at-symbol}readonly=readonly'] or fi:{at-symbol}hidden='hidden'])
a href= name={$id} id={$id}
img src= border=0 alt=Calendar/
/a
/xsl:ifAll that I added was the surrounding xsl:if 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
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
Reading the HTML spec [1], the difference between disabled and readonly are: - readonly is only available on input and textarea. 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 fi:styling readonly=readonly/. 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: Reading the HTML spec [1], the difference between disabled and readonly are: - readonly is only available on input and textarea. 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 fi:styling readonly=readonly/. 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
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
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: 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 input and textarea. 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 fi:styling readonly=readonly/. 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
Linden H van der (MI) wrote: Sylvain, I think he means that adding readonly='readonly' as attribute to his own fi:styling 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: 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,
fi:styling 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:
ft:widget
id="StatusMessage" fi:styling readonly="readonly"
type="textarea" rows="4" cols="75"
wrap="hard"class="DocOrdersStatusMessage"//ft:widget
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:
xsl:if test="not(fi:{at-symbol}disabled='disabled'] or
fi:{at-symbol}readonly='readonly'] or fi:{at-symbol}hidden='hidden'])"
around the calendar HTML anchor.The modified code segment in that file now reads:
!-- calendar popup --
xsl:if test="not(fi:{at-symbol}disabled='disabled'] or
fi:{at-symbol}readonly=readonly'] or fi:{at-symbol}hidden='hidden'])"
a href="" name="{$id}" id="{$id}"
img src="" border="0" alt="Calendar"/
/a
/xsl:ifAll that I added was the surrounding xsl:if 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
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,
fi:styling 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:
ft:widget
id="StatusMessage" fi:styling readonly="readonly"
type="textarea" rows="4" cols="75"
wrap="hard"class="DocOrdersStatusMessage"//ft:widget
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:
xsl:if test="not(fi:{at-symbol}disabled='disabled'] or
fi:{at-symbol}readonly='readonly'] or fi:{at-symbol}hidden='hidden'])"
around the calendar HTML anchor.The modified code segment in that file now reads:
!-- calendar popup --
xsl:if test="not(fi:{at-symbol}disabled='disabled'] or
fi:{at-symbol}readonly=readonly'] or fi:{at-symbol}hidden='hidden'])"
a href="" name="{$id}" id="{$id}"
img src="" border="0" alt="Calendar"/
/a
/xsl:ifAll that I added was the surrounding xsl:if 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: 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, fi:styling 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:
ft:widget id=StatusMessage
fi:styling readonly=readonly type=textarea rows=4 cols=75
wrap=hard
class=DocOrdersStatusMessage/
/ft:widget
Again, I can't find it. If the forms/samples directory:
$ find . -type f | xargs grep readonly
./forms/binding/01value-bind.xml: fb:value id=readonly
./forms/binding/01value-def.xml:fd:field id=readonly
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: CONTRIBUTION: forms-calendar-styling defect when widget disabled
Sylvain,
I think he means that adding readonly='readonly' as attribute to his
own fi:styling 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, fi:styling 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:
ft:widget id=StatusMessage
fi:styling readonly=readonly type=textarea rows=4
cols=75
wrap=hard
class=DocOrdersStatusMessage/
/ft:widget
Again, I can't find it. If the forms/samples directory:
$ find . -type f | xargs grep readonly
./forms/binding/01value-bind.xml: fb:value id=readonly
./forms/binding/01value-def.xml:fd:field id=readonly
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
