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 Massimo Manghi <mx...@apache.org> on 2012/03/24 01:11:05 UTC
checkbutton and radiobutton labels
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
Re: checkbutton and radiobutton labels
Posted by Jeff Lawson <je...@bovine.net>.
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
>