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:if>All 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
