strange behaviour on panels containing an update attribute of type @form

aknuth commented 7 years ago

please check the following code (bootsfaces 1.1.1 on myfaces 2.2.12) and try the select box inside the panel. expected behaviour: selectbox opens and shows the entries observed behaviour: selectbox opens and closes immediately

I think it behaves like getting a doubleclick ... if you remove the update attribute it behaves correct.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:ui="http://java.sun.com/jsf/facelets"
    xmlns:h="http://xmlns.jcp.org/jsf/html"
    xmlns:f="http://xmlns.jcp.org/jsf/core"
    xmlns:b="http://bootsfaces.net/ui">
<f:view contentType="text/html">
    <h:head>
        <title>test</title>
        <meta content='text/html; charset=UTF-8' http-equiv="Content-Type" />
    </h:head>
    <h:body>
        <h:form id="loginForm">
            <b:container layout="fluid">
                <b:panel title="paneltitle" look="info" id="panel1"  update="@form">
                    <b:row>
                        <b:column medium-screen="4">
                            <b:label text="Job" />
                            <b:selectOneMenu>
                                <f:selectItem itemLabel="(Please select)" itemValue="0" />
                                <f:selectItem itemLabel="anything" itemValue="1" />
                                <f:selectItem itemLabel="anythingOther" itemValue="2" />
                            </b:selectOneMenu>
                        </b:column>
                    </b:row>
                </b:panel>
            </b:container>
        </h:form>
    </h:body>
</f:view>
</html>

stephanrauh commented 7 years ago

I'm not sure if this is a bug. Neither am I sure whether we should fix it or not.

Thing is, the update attribute refers to the default AJAX event of the panel. That's the click event. And the panel is not just the panel header. It also includes the panel body.

So when you click the combobox, you also click the panel, triggering an AJAX update. By default, comboboxes are rendered in the closed state, and that's exactly what you've observed.

Reducing the range of the click event to the header sounds like a simple, pragmatic solution. But it also reduces the range of the onmouseover event to the panel header. That, in turn, is unexpected.

As a quick workaround I recommend to add the event name (onexpand="ajax:myBean.myMethod()").

aknuth commented 7 years ago

the code snipplet above is just a part of the reality. The goal is to have a few panels inside an accordion and update the whole according/form structure (e.g. rendered attribute) after clicking on one of panel headers ... Meanswhile I realized it using primefaces:

<p:accordionPanel activeIndex="#{bean.panelId}">
  <p:ajax event="tabChange" listener="#{bean.onTabChange}" update="@form" />
  <p:tab title="title1" look="default" id="panel1" rendered="#{bean.panelvisisble[1]}">
     ....
  </p:tab>
  <p:tab title="title2" look="primary" id="panel2" rendered="#{bean.panelvisisble[2]}">
    ....
  </p:tab>
</p:accordionPanel>

I'm not sure if this is possible using bootsfaces ?

By the way I tried an exclusion of of all input fields inside the panel - like this:

update="@form @(:not(input))"

but bootsfaces won't work using double colons inside the expression ... it might be that the expression is not 100% correct.

stephanrauh commented 7 years ago

As for the jQuery expression: I've implemented the jQuery expression parser in a very minimalistic way. So by default, I'd suspect the fault on our side :).

stephanrauh commented 7 years ago

As for the original topic: the equivalent of

<p:ajax event="tabChange" listener="#{bean.onTabChange}" update="@form" />

is our onexpand or oncollapse event. The difference being that you have to define the onexpand listener on every rib of the accordion.

stephanrauh commented 5 years ago

I've tried the original code snippet, and it doesn't show the reported behaviour. So I assume we've solve the bug during the last two years. I'm closing this ticket.

TheCoder4eu / BootsFaces-OSP

strange behaviour on panels containing an update attribute of type @form #775