Bug 988401

Lukáš Fryč <lfryc> made a comment on jira RF-13107

Hey Jonas, have you tried to observe any issues using e.g. these steps?

https://gist.github.com/lfryc/6123495

Lukáš Fryč <lfryc> made a comment on jira RF-13107

I have attached a <a4j:log mode="console" /> and now I can see this error:

{code}
RichFaces: New request added to queue. Queue requestGroupingId changed to j_idt14:j_idt18 log.js.jsf?ln=org.richfaces:153
RichFaces: Queue will wait 0ms before submit log.js.jsf?ln=org.richfaces:153
RichFaces: richfaces.queue: will submit request NOW log.js.jsf?ln=org.richfaces:153
RichFaces: Received 'begin' event from <input id=j_idt14:j_idt18 ...> log.js.jsf?ln=org.richfaces:153
RichFaces: Received 'beforedomupdate' event from <input id=j_idt14:j_idt18 ...> log.js.jsf?ln=org.richfaces:153
RichFaces: [object Object] log.js.jsf?ln=org.richfaces:153
RichFaces: [object Object] log.js.jsf?ln=org.richfaces:153
RichFaces: richfaces.queue: ajax submit error log.js.jsf?ln=org.richfaces:153
RichFaces: richfaces.queue: Nothing to submit log.js.jsf?ln=org.richfaces:153
RichFaces: Received 'error@malformedXML' event from <input id=j_idt14:j_idt18 ...> log.js.jsf?ln=org.richfaces:153
RichFaces: [200] undefined: undefined log.js.jsf?ln=org.richfaces:153
RichFaces: Received 'complete' event from <input id=j_idt14:j_idt18 ...> log.js.jsf?ln=org.richfaces:153
{code}

Lukáš Fryč <lfryc> made a comment on jira RF-13107

The real error message revealed by debugging:

{code|title=jsf.js:2220}
 } catch (ex) {
                    sendError(request, context, "malformedXML", ex.message);
                    return;
                }
{code}

{{ex.essage}}: "During update: j_idt8:j_idt11 not found"

Lukáš Fryč <lfryc> made a comment on jira RF-13107

The real error message revealed by debugging:

{code:title=jsf.js:2220}
 } catch (ex) {
                    sendError(request, context, "malformedXML", ex.message);
                    return;
                }
{code}

{{ex.message: "During update: j_idt8:j_idt11 not found"}}

Lukáš Fryč <lfryc> made a comment on jira RF-13107

The {{j_idt8:j_idt11}} stands for the {{<rich:message for="surname"/>}}.

----

Workaround is using {{limitRender}}:

{code:xml}
<a4j:commandButton value="Submit" execute="content" render="content" limitRender="true" />
{code}

Lukáš Fryč <lfryc> made a comment on jira RF-13107

The {{j_idt8:j_idt11}} stands for the {{<rich:message for="surname"/>}}.

----

Workaround is using {{limitRender}}:

{code:xml}
<a4j:commandButton value="Submit" execute="content" render="content" limitRender="true" />
{code}

Another workaround is using {{mode="ajax"}} for {{tabPanel}}:

{code:xml}
<rich:tabPanel switchType="ajax">
{code}

Lukáš Fryč <lfryc> made a comment on jira RF-13107

Note: Visitor which scans for ajaxRenderer components shouldn't descend to subtrees which are not renderered.

Lukáš Fryč <lfryc> made a comment on jira RF-13107

Idea: Visitor which scans for ajaxRenderer components shouldn't descend to subtrees which are not renderered.

Jonáš Trantina <jtrantin> made a comment on jira RF-13107

The customer is using switchType = "ajax" already and is experiencing the issue. However in a clean project it works just fine.

Jonáš Trantina <jtrantin> made a comment on jira RF-13107

I have attached reproducer, that shows the problem I described above. Tab panel with two tabs on each there is rich:message, when sending an ajax it says "During update: vertragsAuswahl:j_idt24 not found" where the ID is the rich:message in the non-visible tab.

Lukáš Fryč <lfryc> made a comment on jira RF-13107

The issue is very similar to the {{mode=server}}: once the initial page is loaded, it does contain just a DOM for first tab (all others are loaded lazily as you switch to them).

That's why {{Submit}} works when you switch to second tab and then back. And that's also why it worked in previous sample with mode=ajax - we had reproduced on second tab and message on first tab.

It comes again to problem that {{ajaxRendered=true}} components shouldn't be rendered when they are not present on the page.

----

We can either

1. detect the presence of the ajax-rendered component on server-side

* no idea how we should know it was already rendered or not

2. we can intercept {{jsf.ajax.response}} and remove all irrelevant parts of partial-response

* in this case we should provide debug message that partial response is being stripped

Lukáš Fryč <lfryc> made a comment on jira RF-13107

The issue is very similar to the {{mode=server}}: once the initial page is loaded, it does contain just a DOM for first tab - see attached image (all others are loaded lazily as you switch to them).

That's why {{Submit}} works when you switch to second tab and then back. And that's also why it worked in previous sample with mode=ajax - we had reproduced on second tab and message on first tab.

It comes again to problem that {{ajaxRendered=true}} components shouldn't be rendered when they are not present on the page.

----

We can either

1. detect the presence of the ajax-rendered component on server-side

* no idea how we should know it was already rendered or not

2. we can intercept {{jsf.ajax.response}} and remove all irrelevant parts of partial-response

* in this case we should provide debug message that partial response is being stripped

Lukáš Fryč <lfryc> made a comment on jira RF-13107

The issue is very similar to the {{mode=server}}: once the initial page is loaded, it does contain just a DOM for first tab - see attached image (all others are loaded lazily as you switch to them).

That's why {{Submit}} works when you switch to second tab and then back.

And that's also why it worked in previous sample with mode=ajax - we had reproduced on second tab and message on first tab.

It comes again to problem that {{ajaxRendered=true}} components shouldn't be rendered when they are not present on the page.

----

We can either

1. detect the presence of the ajax-rendered component on server-side

* no idea how we should know it was already rendered or not

2. we can intercept {{jsf.ajax.response}} and remove all irrelevant parts of partial-response

* in this case we should provide debug message that partial response is being stripped

Lukáš Fryč <lfryc> made a comment on jira RF-13107

Note that a workaround with {{limitRender=true}} still works here!

Lukáš Fryč <lfryc> made a comment on jira RF-13107

Interesting part is here: RenderVisitContext is extended visit context which visits all components which are {{ajaxRendered}}.

We should REJECT visiting of subtrees which are not active: there is a interface for switchable panels called [{{boolean AbstractTogglePanelItemInterface#shouldProcess();}}|https://github.com/richfaces/richfaces/blob/5.0.0.Alpha1/framework/src/main/java/org/richfaces/ui/toggle/AbstractTogglePanelItemInterface.java#L41].

It's [implemented by AbstractTab|https://github.com/richfaces/richfaces/blob/5.0.0.Alpha1/framework/src/main/java/org/richfaces/ui/toggle/tabPanel/AbstractTab.java#L225].

I suggest to generalize this shouldProcess method to {{ActivableComponent}} or {{SwitchableComponent}} interface

Lukáš Fryč <lfryc> made a comment on jira RF-13107

Interesting part is here: RenderVisitContext is extended visit context which visits all components which are {{ajaxRendered}}.

We should REJECT visiting of subtrees which are not active: there is a interface for switchable panels called [{{boolean AbstractTogglePanelItemInterface#shouldProcess();}}|https://github.com/richfaces/richfaces/blob/5.0.0.Alpha1/framework/src/main/java/org/richfaces/ui/toggle/AbstractTogglePanelItemInterface.java#L41].

It's [implemented by AbstractTab|https://github.com/richfaces/richfaces/blob/5.0.0.Alpha1/framework/src/main/java/org/richfaces/ui/toggle/tabPanel/AbstractTab.java#L225].

I suggest to generalize this shouldProcess method to {{ActivableComponent}} or {{SwitchableComponent}} interface

----

Note that we can't use {{isRendered}}, because the component is marked as {{rendered=true}} event though it's not active.

Lukáš Fryč <lfryc> updated the status of jira RF-13107 to Coding In Progress

Lukáš Fryč <lfryc> updated the status of jira RF-13107 to Resolved

Brian Leathem <bleathem> made a comment on jira RF-13107

The generalized API introduced is: VisitChildrenRejectable#shouldVisitChildren()

https://github.com/richfaces4/core/blob/master/api/src/main/java/org/richfaces/component/VisitChildrenRejectable.java

Pavol Pitonak <ppitonak> made a comment on jira RF-13107

Verified in 4.3.4, it's ready to be closed.

We don't need one-off for now. Closing this bug.