Ajax region submit triggers re-render of different region

[gbilodeau]

Hi guys,

We have a single-page application that contains multiple forms, which are rendered or not depending on a node selected in a left-hand navigation tree. Each form is defined within a separate a4j:region, and each form is backed by an object of a different class, some inheriting from the same parent class.

In one of these forms, an a4j:support triggers an Ajax submit to perform validation checks. This fails with an error message saying that a property cannot be found on a given object during the apply request values phase, but this property is referred to in another form, one that isn't currently rendered.

Why is this? If I understand correctly, only data from the current form is being submitted, and since the submit is coming from a given a4j:region, only this region will be decoded on the server side.

Thanks guys,
GB

[gbilodeau]

Somehow I was able to fix this by changing the order of some <ui:include> tags, but this hardly seems like a stable solution.

I'm still confounded by the time it takes to process a single Ajax request. It seems that the entire component tree is being walked through for different phases (decode? process? encode?) when only the region from which the request originated should be considered. To be safe I even added renderRegionOnly=true to my regions, but to no avail.

Am I missing something?

Cheers,
GB

[gbilodeau]

I've done some quick profiling and it seems that a major bottleneck is the Ajax4Jsf XML parser. The default Tidy parser gobbles up to 70% of all processing time for Ajax requests; the Neko parser uses less at 40% but it's still significative. Using no parser makes Ajax requests hang - they never return and the a4j:status icon eventually freezes.

I've also changed log levels to INFO for the JSF packages - they were set to DEBUG which generates tons of messages.

Has anybody encountered this situation?

Cheers,
GB

[ilya_shaikovsky]

difference between parsers described in our guide.

I'm still confounded by the time it takes to process a single Ajax request. It seems that the entire component tree is being walked through for different phases (decode? process? encode?) when only the region from which the request originated should be considered.

No all the tree should not be processed in the case you describes.. So if you'll provide concrete case - it will be recognized as a bug for sure.

[gbilodeau]

Privet Ilya and thank you for your attention.

I have read the section on parsers in the guide but I fail to understand why it's necessary to do such a step. It's written that the Tidy filter "[...] is recommended for applications with complicated or non-standard markup [...]". What exactly qualifies as complicated or non-standard markup? Our application is a single-page application so for sure it's complex, but we're only using RichFaces components so I assume generated markup is standard. Why would Ajax requests stop working when using no filtering? Are there any steps we could take to identify the source of this problem?

As for the entire tree being processed, it's mostly an impression for now - I don't quite understand the whole request cycle yet.

Spasibo bolshoye!
GB

[gbilodeau]

Hi guys,

I compared the HTTP responses coming from all 3 parsers (tidy, neko and none) and one striking difference is that the "none" response has no ... section surrounding the actual HTML body, while the other two do.

The rest seems to be pretty much identical. Comments have been stripped off from "neko" and "tidy" responses, tags have been added to "neko" and "tidy" responses, and tabs in the "none" response have been substituted by spaces in the "neko" and "tidy" responses. Removing all comments from XHTML files makes no difference.

Could these missing ... tags explain why Ajax responses are not processed correctly? How could we generate these tags manually?

Cheers,
GB

[gbilodeau]

Previous message contained HTML tags, starting over...

Hi guys,

I compared the HTTP responses coming from all 3 parsers (tidy, neko and none) and one striking difference is that the "none" response has no {body}...{/body} section surrounding the actual HTML body, while the other two do.

The rest seems to be pretty much identical. Comments have been stripped off from "neko" and "tidy" responses, {tbody} tags have been added to "neko" and "tidy" responses, and tabs in the "none" response have been substituted by spaces in the "neko" and "tidy" responses. Removing all comments from XHTML files makes no difference.

Could these missing {body}...{/body} tags explain why Ajax responses are not processed correctly? How could we generate these tags manually?

Cheers,
GB

[gbilodeau]

Hi all,

Using the HttpFox extension for Firefox, I discovered that HTTP responses that hadn't been parsed by Tidy or Neko contained entities (such as eacute, nbsp, etc.) that weren't recognized by the browser. It seems that such entities are valid inside an HTML document but not an XLM document, and the response was declared as being XML. After removing these entities, HTTP responses are processed correctly and the web page is correctly updated. The fact that the body tags are missing seems to have no effect, at least in Firefox.

After this change, response time for our particular use cases has decreased by ~15% to sit at ~1.5s. It's still not where we want it to be, but it's getting there. For one, we need to figure a better way to handle multiple checkboxes with a "select all" checkbox - making an Ajax request to the server to update the JSF tree instead of using simple JavaScript seems overkill but we didn't find any better. Ideas are welcome :)

Cheers,
GB