Controlling how multiple checkboxes display

Here's a hackish-kind of idea - try including some HTML code in some of the labels.
If the label appears before the checkbox:
<option value="e" label=" e"/>
or
<option value="e" label="<![CDATA[ ]]>e"/>
or
<option value="e" label=" e"/>

If the label appears after the associated checkbox just switch them around - e.g.:
<option value="e" label="e "/> ...

I have NOT tried this out - just suggesting a possible work-around (let us know if any of them work)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Hmm, this seems to be a really good idea, but I think XML is going to get in the way.

Either of these options:
<option value="e" label=" e"/>
<option value="e" label="<![CDATA[ ]]>e"/>

yield an error of "The value of attribute "label" must not contain the '<' character."

This option:
<option value="e" label=" e"/>

yields no error, but results in being displayed next to the field's label, not actually parsed by the browser. So, it would seem I need a way to escape the < from the xml, but have it treated as literal HTML.

Updated: I tried (somewhat in desperation) adding a after the <option> tag, thus:
<option value="e" label="e"/> 
And, as expected, it was completely ignored.

Jonathon
Independent Interwoven Contractor

Edited by JonathonG on 08/02/04 03:52 PM (server time).

Bummer. I was afraid that the processing code wouldn't like any of my suggestions - but it seemed a reasonable idea to try out.

Is it at all possible to handle this with one of the CSS's?
Is it possible to maybe do something like:

<option value="e" label="e" id="br"/>
or
<option value="e" label="e" class="br"/>

and define something in the CSS so that when it sees that id or class directive it inserts a line-break before/after the resultant code?
(just grasping at straws of ideas here - I'm not a CSS-expert)

Another thought (just as fleeting): <option value="e" label="e"> </option>

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Frederik

all I can say is that we too in our last project would have liked this feature... having not found a solution, we just made the multi-select box long enough (luckily size 10 was enough). Do post the solution if you find it. Greets -Fred.

Hmm, no joy on this:

<option value="e" label="e"> </option>

A few issues I see with the CSS approach:
1) I don't think you can insert line breaks through CSS (but I could be wrong)
2) It doesn't appear that the datacapture passes any "class" attribute through to the rendered page.
3) I'm still working with 5.5.2, so I don't have access to the CSS on a per-template basis, and I can't make a global change like that (centrally managed TS servers, and I'm working in only one of the client groups)

I tried manipulating the label with FormAPI, thinking I could avoid the parser problems that way. But again, no joy. This:

var cbOpts = IWDatacapture.getItem("/metadata2/state_dd").getOptions();
cbOpts[1].text = cbOpts[1].text + " ";
IWDatacapture.getItem("/metadata2/state_dd").setOptions(cbOpts);

simply results in the 2nd option having " " displayed next to the label. I'm beginning to think that this is impossible. Smiley Sad

Jonathon
Independent Interwoven Contractor

lhdavis

What about trying to use an inline callout for this?

Of course, you could run into the same problem processing the XML when using a within the <substitution> tags since it still has to follow the datacapture5.0.dtd. Could be worth exploring though.

Maybe a feature request for something like the <rowcontinue> element on the <item> tag would be in order.

Luke Davis
Open Technology Group, Inc.
luke.davis@med.va.gov

How about breaking it up into multiple items, and then letting the PT reassemble them correctly?

--

Current project: TS 5.5.2/6.1 W2K

How about breaking it up into multiple items, and then letting the PT reassemble them correctly?

I was just thinking the same thing - except that if you have a requirement that at least 1 item needs to be selected - you would have to code that requirement validation within the FormAPI code as you couldn't use the built-in procedure for specifying that there needs to be at least one selection made from these N fields in the DCT's XML code.

It also seems like a hackish solution (which, in that respect, doesn't differ too much from my already proposed ideas ;-) and it seems to me that there's a feature request burried in all this - but it would be nice to figure out how to phrase it correctly (i.e. is it number-of-options-per-line? or length-of-labels+checkboxes-per-line? or something else?)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

It also seems like a hackish solution
Agreed - I just couldn't come up with cleaner way to do it

is it number-of-options-per-line? or length-of-labels+checkboxes-per-line? or something else?
How about having the ability to specify the same item more than once with the same name? To give you more control visually, but treat it as one item internally. That might be handy in other instances, too. Perhaps with a radio button, you'd like butttons 1, 2, and 3 followed by some block of options that relate to them (proably enabled by FormAPI) and that followed by buttons 4, 5, and 6, along with THEIR options.

--

Current project: TS 5.5.2/6.1 W2K

is it number-of-options-per-line? or length-of-labels+checkboxes-per-line? or something else?
How about having the ability to specify the same item more than once with the same name? To give you more control visually, but treat it as one item internally. That might be handy in other instances, too. Perhaps with a radio button, you'd like butttons 1, 2, and 3 followed by some block of options that relate to them (proably enabled by FormAPI) and that followed by buttons 4, 5, and 6, along with THEIR options.
Hmm, well I can see where that would work, but I was thinking of being able to have the options "intelligently" wrap based on the window dimensions / font size / etc. - rather than hard-coding n-options per item-instance (though the wrapping could apply in either case, so I think the combination of the two ideas is worth considering as part of the formal feature request)

Question - before we go too far here ... Since this stuff is being rendered by the browser ... how much real control do we have over stuff like this in basic HTML pages? I.e. if you can't do it in HTML, chances are they can't do it in the TST UI.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

how much real control do we have over stuff like this in basic HTML pages?
In "real" HTML pages, there is no container relationship between various checkboxes, other than the form that owns them all. Checkboxes are grouped logically by having them share the same name attribute. That is, there's noting wrong with something like this:


<form>
    <item name="box1" type="checkbox" value="dog"> Dog
    <br>Dog's name: <item name="dog name" type="text">
    <hr>
    <item name="box1" type="checkbox" value="cat"> Cat
    <br>
    Cat's name: <item name="cat_name" type="text">
</form>

The fact that both checkboxes have the same name is the only thing that ties them together.

--

Current project: TS 5.5.2/6.1 W2K

Doh! of course - thanks - I was apparently mentally blocked when I asked that question because I was thinking of the syntax of a select list rather than checkboxes or radio-buttons and clearly they are different types of things.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

It's an easy mistake to make, because TS templating does treat them as the same basic sort of entity. So if you're in a "TeamSite state of mind" (sounds like a Billy Joel song

) you're going to tend to lump them together.

--

Current project: TS 5.5.2/6.1 W2K

Yeah, just tried that. And it works....if you can stomach the multiple actual items representing one logical item. Where this breaks down is if/when you change the options. You would have to make sure not to change which physical item is in a given container. Which means your options would have to be sorted historically (in the order they were added to the DCT) instead of alphabetically. This is a killer if the options are populated dynamically from somewhere that is highly likely to change (which is the case for us)...

Jonathon
Independent Interwoven Contractor

Any one of these sounds good to me. Unfortunately, I can't open a FR nor add my current customer to it. For some reason, the group that owns the support contract is reluctant to open support cases. I don't understand why, never have, but that's reality here Smiley Sad

Also, a Feature Request doesn't solve my current issue. But I think I'm resigned to the fact that my issue is unresolvable in current software Smiley Sad

Jonathon
Independent Interwoven Contractor

Which means your options would have to be sorted historically (in the order they were added to the DCT) instead of alphabetically
Not necessarily.

If you wrap all of this inside a container, then just walk through all of the child elements of that container to get your values. In essence, the container is the real "item." It just happens to be instantiated by being spread over multiple child items.

It makes your presentation template more complicated, but it gives you the ability to change the positioning of your checkboxes at will.

The only other problem (which just occurred to me as I was typing that last sentence) is that you've got a problem with reloading the data into the data capture form if the order changes. So you'd have to have some FormAPI to handle it. For that matter, the FormAPI could could eliminate the complexity in the presentation template. Have a hidden field which is the "real" set of values. The FormAPI code sets the "visual" checkboxes based on the hidden value at startup, and then the onChange event for the visible boxes updates the hidden value. Complex, but do-able, I would think.

--

Current project: TS 5.5.2/6.1 W2K

The only other problem (which just occurred to me as I was typing that last sentence) is that you've got a problem with reloading the data into the data capture form if the order changes

That's actually the problem I had in mind. Complex PTs are definitely doable.

...Have a hidden field which is the "real" set of values...

Hmm, now that might have legs. Let me pound on that one a bit with some of my co-workers, but its promising. I knew I liked you, Dwayne, I just couldn't remember why Smiley Wink

Jonathon
Independent Interwoven Contractor

Gee, thanks.

I think.

Current project: TS 5.5.2/6.1 W2K