Skip to main content
J
jsulak1-Visitor
1-Visitor
January 5, 2011
Question

handling XUI listitem events

  • January 5, 2011
  • 7 replies
  • 1545 views
Hi Adepters,

I have a bit of a XUI problem. While I can capture the DOMActivate event on a <listbox/>, I can't do the same for any of its <listitem/> children. In other words, this works, setting target to the label of the selected listitem:

<listbox>
<script ev:event="DOMActivate" id="hitsscript" type="text/javascript">
target = Application.event.target.getAttribute("value");
</script>
...
</listbox>

But any listener attached to a <listitem/> using listitem.addEventListener("DOMActivate", listener, false) never fires.

The reason I need to do this is that I'm creating a listbox where the labels are not guaranteed to be unique. So instead of acting on listitem/@label, I want to act on listitem/@appdata, which as far as I can tell, isn't accessible from the listbox domactivate event. Also, listitem/@selected never gets set to "true," so I can't find the selected listitem that way, either.

Does anyone have any pointers?

Thanks,

James

    7 replies

    C
    ClayHelberg18-Opal
    18-Opal
    January 5, 2011
    Hi James--

    Er, just to play devil's advocate (or something like that), what is the
    use case for having a listbox with duplicate entries? How does the user
    disambiguate between the first instance of "foo" and the second instance
    of "foo" in the list? The fact that they would have different @appdata
    values indicates that multiple instances of "foo" would not be
    equivalent.

    Maybe the user has some external knowledge (maybe based on order of
    entries in the list) that allows them to choose the correct one. In this
    case, I'd recommend constructing a label that somehow incorporates that
    external knowledge, e.g. instead of "foo" for every instance of "foo",
    use "Chapter 1:foo", "Chapter 2:foo" etc. (or however it breaks down).

    Since @appdata is unique for the items, maybe this could be tweaked to
    be user-presentable and used as listitem labels?

    Other than that, I'm not sure what to advise. AFAICT you're right, the
    only thing that gets updated when the user selects a listitem in a
    listbox is listbox/@value, which is set to the value of the selected
    listitem's @label attribute.

    If you have to work around this, and can't augment the labels to
    disambiguate them, the next thing I'd try is tapping into ACL using the
    dlgitem_*() functions to see if you can skirt the AOM limitation that
    way.

    --Clay
    B
    bibach1-Visitor
    1-Visitor
    January 5, 2011
    As a last resort, if none of Clay's suggestions pan out, perhaps you
    could add extra whitespace on to the end of the labels to disambiguate
    them. A series of one or more zero-width spaces (if XUI handles them
    correctly) should make no difference as far as the user can see, but
    should let your code tell the items apart.

    -Brandon 🙂


    B
    berard1-Visitor
    1-Visitor
    January 5, 2011
    I'm sort of with Clay on this, even if the user can't see the spaces,
    how would they know which one to pick?

    I know we get around this type of condition by putting a numeric value
    before each item in the list, then when selected, we display
    additional information about the node in a separate textbox.

    Iterator i = newItems.keySet().iterator();
    int count=1;
    while(i.hasNext()) {
    String appdata = (String)i.next();
    String display = (String)newItems.get(appdata);

    Element li = XUIHelper.createListItem(this.xuiDoc,appdata,display);

    li.setAttribute("label", Integer.toString(count++) + ": " +
    li.getAttribute("label"));

    this.listSandbox.appendChild(li);
    }

    keith

    On Wed, Jan 5, 2011 at 11:50 AM, Brandon Ibach
    <brandon.ibach@single-sourcing.com> wrote:
    > As a last resort, if none of Clay's suggestions pan out, perhaps you
    > could add extra whitespace on to the end of the labels to disambiguate
    > them. A series of one or more zero-width spaces (if XUI handles them
    > correctly) should make no difference as far as the user can see, but
    > should let your code tell the items apart.
    >
    > -Brandon 🙂
    >
    >
    >
    J
    jsulak1-VisitorAuthor
    1-Visitor
    January 5, 2011
    Thanks everyone for their answers. Yeah, I realize that having non-unique list items is a bit odd, and I'll probably abandon that, but it works okay in this case because there is external context that lets the user know which one they are picking. I was surprised that XUI apparently didn't support events on list items or update listitem/@selected, and wanted to verify that with people who know more than me. For now I'll just number the items in the list, which will take care of the uniqueness problem.

    Thanks,

    James


    B
    bibach1-Visitor
    1-Visitor
    January 5, 2011
    I agree, Keith. My suggestion was intended as a last resort option if
    the application requirements would not allow for changing the labels
    to make them unique.

    -Brandon 🙂


    B
    berard1-Visitor
    1-Visitor
    January 5, 2011
    Oh, sorry Brandon, I wasn't so much replying to your suggestion, so
    much as the thread in general.

    Very inventive solution, I'll keep that in mind for myself if I ever
    need to do something like that.

    keith

    On Wed, Jan 5, 2011 at 12:43 PM, Brandon Ibach
    <brandon.ibach@single-sourcing.com> wrote:
    > I agree, Keith. My suggestion was intended as a last resort option if
    > the application requirements would not allow for changing the labels
    > to make them unique.
    >
    > -Brandon 🙂
    >
    >
    >
    B
    bibach1-Visitor
    1-Visitor
    January 5, 2011
    On Wed, Jan 5, 2011 at 1:32 PM, Keith Berard <-> wrote:
    > Oh, sorry Brandon, I wasn't so much replying to your suggestion, so
    > much as the thread in general.

    No worries, Keith. Smiley Happy

    > Very inventive solution, I'll keep that in mind for myself if I ever
    > need to do something like that.

    Thank you.

    -Brandon Smiley Happy
    Terms & ConditionsAccessibility statement