You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Jeff Lawson <je...@bovine.net> on 2012/04/05 19:43:06 UTC
Re: checkbutton and radiobutton labels
Part of the problem with that previous logic was that creating a radio
or checkbox that lacked a -label argument caused the -value to be used
and displayed as the label. We were using -values that are not
intended to be human readable, and we did not want to display a -label
either. I suppose we could have specified -label "" to explicitly
request a blank label, but I'm instead attaching the diff of another
proposal.
Basically if you leave off the -label, it no longer assumes -value for
it (you have to explicitly specify -label if you want one).
Additionally it uses the <label for=...> syntax to let you click on
its label text, which is also an accessibility improvement.
It does introduce a package dependency on "uuid" (comes with tcllib),
but maybe you can think of a better way to generate a unique
identifier if the element wasn't given one.
On Fri, Mar 23, 2012 at 7:11 PM, Massimo Manghi <mx...@apache.org> wrote:
> A recent commit made by Karl for the 'form' class removed from the
> 'field' an if clause that checked if labels had been defined for a
> checkbutton or a radiobutton and in case the label was emitted.
>
> This is breaking some of my scripts based on the form package (luckily
> not so many) because labels disappeared from the output altogether.
> eg
>
> myform radiobuttons fruit -values {big medium small} \
> -labels {Watermelon Orange Strawberry} \
> -class myradiobclass
>
> was expected to print something like
>
> <input type="radio" name="fruit" class="myradiobclass"
> label="Watermelon" value="big" />Watermelon
> ...
> ...
>
> (Admittedly I thought the label was within the <input ...> element)
>
> now the output is something like
>
> <input type="radio" name="fruit" class="myradiobclass"
> label="Watermelon" value="big" />
>
> Having labels printed in this way might look to an HTML5 wizard as old
> style HTML, but tags can be styled anyway and after all it might help to
> have the labels automatically embedded. The way the package is supposed
> to work is documented in the manual and at least it needs update now.
>
> Is there a solution that might work for both cases? What about a new
> '-print_labels' for this type of input elements? How am I supposed to
> get label printed if I cannot access low level HTML of an input form
> being bred by the package?
>
> thanks
>
> -- Massimo
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
Re: checkbutton and radiobutton labels
Posted by Massimo Manghi <mx...@apache.org>.
Hi
It took me a while before I could catch up with this. Sorry.
I applied your patch to the form package and it's ok. This brings
up the issue of the need of an unique identifier package for Rivet,
as you said.
I remember some reluctance in forcing Rivet to require extra stuff,
at least in general. OTOH Tcllib is part of every battery included
installation and every Linux Tcl distribution I know of ships a
tcllib package. We may, as long as no better solution is in sight,
make Tcllib as a required library to let the 'form' packages work.
Session package has an alternative solution, but I don't know if
md5 generated IDs would be an alternative and acceptable solution
for Jeff. They're good to be, but they tend to make debug output
verbose and awkwardly readable.
I will commit it if no objections are raised.
-- Massimo
On 05.04.2012 18:43, Jeff Lawson wrote:
> Part of the problem with that previous logic was that creating a
> radio
> or checkbox that lacked a -label argument caused the -value to be
> used
> and displayed as the label. We were using -values that are not
> intended to be human readable, and we did not want to display a
> -label
> either. I suppose we could have specified -label "" to explicitly
> request a blank label, but I'm instead attaching the diff of another
> proposal.
>
> Basically if you leave off the -label, it no longer assumes -value
> for
> it (you have to explicitly specify -label if you want one).
> Additionally it uses the <label for=...> syntax to let you click on
> its label text, which is also an accessibility improvement.
>
> It does introduce a package dependency on "uuid" (comes with tcllib),
> but maybe you can think of a better way to generate a unique
> identifier if the element wasn't given one.
>
>
> On Fri, Mar 23, 2012 at 7:11 PM, Massimo Manghi <mx...@apache.org>
> wrote:
>> A recent commit made by Karl for the 'form' class removed from the
>> 'field' an if clause that checked if labels had been defined for a
>> checkbutton or a radiobutton and in case the label was emitted.
>>
>> This is breaking some of my scripts based on the form package
>> (luckily
>> not so many) because labels disappeared from the output altogether.
>> eg
>>
>> myform radiobuttons fruit -values {big medium small} \
>> -labels {Watermelon Orange Strawberry} \
>> -class myradiobclass
>>
>> was expected to print something like
>>
>> <input type="radio" name="fruit" class="myradiobclass"
>> label="Watermelon" value="big" />Watermelon
>> ...
>> ...
>>
>> (Admittedly I thought the label was within the <input ...> element)
>>
>> now the output is something like
>>
>> <input type="radio" name="fruit" class="myradiobclass"
>> label="Watermelon" value="big" />
>>
>> Having labels printed in this way might look to an HTML5 wizard as
>> old
>> style HTML, but tags can be styled anyway and after all it might
>> help to
>> have the labels automatically embedded. The way the package is
>> supposed
>> to work is documented in the manual and at least it needs update
>> now.
>>
>> Is there a solution that might work for both cases? What about a new
>> '-print_labels' for this type of input elements? How am I supposed
>> to
>> get label printed if I cannot access low level HTML of an input form
>> being bred by the package?
>>
>> thanks
>>
>> -- Massimo
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
>> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: checkbutton and radiobutton labels
Posted by Massimo Manghi <mx...@apache.org>.
On 05.04.2012 18:43, Jeff Lawson wrote:
> Part of the problem with that previous logic was that creating a
> radio
> or checkbox that lacked a -label argument caused the -value to be
> used
> and displayed as the label. We were using -values that are not
> intended to be human readable, and we did not want to display a
> -label
> either. I suppose we could have specified -label "" to explicitly
> request a blank label, but I'm instead attaching the diff of another
> proposal.
>
why decoupling the two switches wasn't enough?
> Basically if you leave off the -label, it no longer assumes -value
> for
> it (you have to explicitly specify -label if you want one).
> Additionally it uses the <label for=...> syntax to let you click on
> its label text, which is also an accessibility improvement.
>
sensible point
> It does introduce a package dependency on "uuid" (comes with tcllib),
> but maybe you can think of a better way to generate a unique
> identifier if the element wasn't given one.
>
no, I don't have it, but Session package has one. It creates MD5 hash
of
a string generated from a series of different independent information,
including a string provided by the caller IIRC. Also /dev/random is
used to get some entropy into the input string.
I will test this patch ASAP. In case would you write a few words for
the manual page?
cheers
-- Massimo
>
> On Fri, Mar 23, 2012 at 7:11 PM, Massimo Manghi <mx...@apache.org>
> wrote:
>> A recent commit made by Karl for the 'form' class removed from the
>> 'field' an if clause that checked if labels had been defined for a
>> checkbutton or a radiobutton and in case the label was emitted.
>>
>> This is breaking some of my scripts based on the form package
>> (luckily
>> not so many) because labels disappeared from the output altogether.
>> eg
>>
>> myform radiobuttons fruit -values {big medium small} \
>> -labels {Watermelon Orange Strawberry} \
>> -class myradiobclass
>>
>> was expected to print something like
>>
>> <input type="radio" name="fruit" class="myradiobclass"
>> label="Watermelon" value="big" />Watermelon
>> ...
>> ...
>>
>> (Admittedly I thought the label was within the <input ...> element)
>>
>> now the output is something like
>>
>> <input type="radio" name="fruit" class="myradiobclass"
>> label="Watermelon" value="big" />
>>
>> Having labels printed in this way might look to an HTML5 wizard as
>> old
>> style HTML, but tags can be styled anyway and after all it might
>> help to
>> have the labels automatically embedded. The way the package is
>> supposed
>> to work is documented in the manual and at least it needs update
>> now.
>>
>> Is there a solution that might work for both cases? What about a new
>> '-print_labels' for this type of input elements? How am I supposed
>> to
>> get label printed if I cannot access low level HTML of an input form
>> being bred by the package?
>>
>> thanks
>>
>> -- Massimo
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
>> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org