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 <mxman...@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-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
