reducing <label> elements produced by XFormsGroupHandler

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

reducing <label> elements produced by XFormsGroupHandler

Adrian Baker
In upgrading from an older version of Orbeon to 3.5.1 we've noticed that additional <label> elements were being produced for <xf:group> spans, which was affecting our layout.

We were about to update our css to reflect the change, but then thought we'd better check for the source of the extra <label> elements first.

It looks like the group handler is now outputting labels using:

    reusableAttributes.clear();
    reusableAttributes.addAttribute("", "class", "class", ContentHandlerHelper.CDATA, "xforms-label");
    outputLabelFor(handlerContext, reusableAttributes, effectiveGroupId, labelValue);

whereas previously it would use a call to:

    handleLabelHintHelpAlert(effectiveGroupId, "label", groupXFormsControl);

(which it can't use t anymore because the label needs to be output in the start() method). The effect is the same, except the labels are now output unconditionally, even if the group has no <xf:label> element. Whereas the
handleLabelHintHelpAlert method won't output anything if no <xf:label> is present.

The conditional behavior can be preserved with:

    if(handlerContext.isGenerateTemplate() || groupXFormsControl.getControlElement().element(XFormsConstants.XFORMS_LABEL_QNAME) != null) {
        reusableAttributes.clear();
        reusableAttributes.addAttribute("", "class", "class", ContentHandlerHelper.CDATA, "xforms-label");
        outputLabelFor(handlerContext, reusableAttributes, effectiveGroupId, labelValue);
    }

Does this seem like a sensible check? Groups are frequently used without labels, so this cuts down the number of redundant empty <label> elements produced.

Adrian








--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: reducing <label> elements produced by XFormsGroupHandler

Erik Bruchez
Administrator
Adrian,

Thanks a lot, I entered a bug, integrated your fix, and closed the bug:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=307380&group_id=168&atid=350207

The code is even simpler if you use groupXFormsControl.hasLabel(). There
is one minor issue with this fix which is that in theory, when you
generate the template, you should not generate markup for the label
unless needed. To know that there is a label though, you must statically
look at the tree of controls, and this is not possible in start() since
the handler is SAX-based.

Maybe XFormsControls should just support a method to obtain a control
element by id. This could solve this problem and similar issues in other
places as well.

But things work this way so I just added a TODO to remind us to think
about improving this. I also added a repeat-groups.xhtml sample which
just repeats groups with and without labels so we can test this.

-Erik

Adrian Baker wrote:

> In upgrading from an older version of Orbeon to 3.5.1 we've noticed that
> additional <label> elements were being produced for <xf:group> spans,
> which was affecting our layout.
>
> We were about to update our css to reflect the change, but then thought
> we'd better check for the source of the extra <label> elements first.
>
> It looks like the group handler is now outputting labels using:
>
>     reusableAttributes.clear();
>     reusableAttributes.addAttribute("", "class", "class",
> ContentHandlerHelper.CDATA, "xforms-label");
>     outputLabelFor(handlerContext, reusableAttributes, effectiveGroupId,
> labelValue);
>
> whereas previously it would use a call to:
>
>     handleLabelHintHelpAlert(effectiveGroupId, "label", groupXFormsControl);
>
> (which it can't use t anymore because the label needs to be output in
> the start() method). The effect is the same, except the labels are now
> output unconditionally, even if the group has no <xf:label> element.
> Whereas the handleLabelHintHelpAlert method won't output anything if no
> <xf:label> is present.
>
> The conditional behavior can be preserved with:
>
>     if(handlerContext.isGenerateTemplate() ||
> groupXFormsControl.getControlElement().element(XFormsConstants.XFORMS_LABEL_QNAME)
> != null) {
>         reusableAttributes.clear();
>         reusableAttributes.addAttribute("", "class", "class",
> ContentHandlerHelper.CDATA, "xforms-label");
>         outputLabelFor(handlerContext, reusableAttributes,
> effectiveGroupId, labelValue);
>     }
>
> Does this seem like a sensible check? Groups are frequently used without
> labels, so this cuts down the number of redundant empty <label> elements
> produced.
>
> Adrian
>
>
>
>
>
>

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws