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 <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

Reply via email to