a4j:region implementation proposal in 4.x

[ilya_shaikovsky]

My first proposal from wiki was:

1) Region The developer should have a possibility to define zones to be processed at server side without using execute definitions to be defined at every component.Proposed to leave our current mechanism as default opposite to JSF 2 which has execute and render defined as @this if not redefined.

Currently this functionlity not implemented and execute should be used instead.

For this we could

1. add new @region keywords available for RichFaces core Ajax components and define it as default.
1. This will be available only for RF ajax components. Probably we should fill proposal to Mojara in order not to rewrite their mechanism to provide support of regions in f:ajax.
2. consider viewRoot as root region as it was done before.

There was reasonable comment from Jay

# Not sure about overriding JSF default behavior for the regions. I like the comment regarding discussing this with mojarra instead of overwriting their default.

So currently let's revise slightly changed proposal:

Regions should has the same processing limitation functionality as for 3.3.x except one point - the component should be defined with execute="@region" to use them.

It's eliminates cool feature of 3.3.x that users didn't carried about additional attribute definition and regions just worked for them.
BUT if we will take into consideration real applications with deep template's level - the developer will still gain benefits from not carrying about name of the region (of the wrapper component to be processed) but just using this shortcut. Example:

<a4j:region>
 <h:inputText value="#{userBean.name}">
 <a4j:ajax event="onkeyup" render="outname" execute="@region"/>
 </h:inputText>
</a4j:region>

and

<h:panelGrid id="grid">
 <h:inputText value="#{userBean.name}">
 <a4j:ajax event="onkeyup" render="outname" execute="grid"/>
 </h:inputText>
</h:panelGrid>

The snippets looks very similar. But the first one looks much more easier to maintain if the region component and the Ajax components placed in different templates levels.

[jbalunas]

+1 - I like this idea and the fact that is is more maintainable especially with templates in mind.

[luxspes]

It's eliminates cool feature of 3.3.x that users didn't carried about additional attribute definition and regions just worked for them.


One thing I do not like about 3.3.x is that regions are a hierarchical containers, and therefore there is no way to say that intertwined controls are in different regions. By what you say here about JSF 2.0, it is now possible to do it thanks to this "execute" attribute where you can specify the region for a particular control. I think that will make building complex UIs a lot easier.

Of course, sometimes you might want to "just use the current region", for those cases I like the @region idea.

[ilya_shaikovsky]

Wiki page http://community.jboss.org/wiki/A4jCoreComponentsRequirements was updated.

Two minor questions still there:

• do we need selfRendered for the component
• do we need limit ajax status request processing to enclosing region component. - Think that no. Developer could widelly use regions for optimization but in 3.3.x status component defined in main template stoped working for the requests from region and additional definitions was reuired.

[ilya_shaikovsky]

From the beggining - previous questions was already answered as "no" for A2.

Now we also want to rise the last key question(this should not be changed in future ideally). In the core wiki page comments me and Jay agreed that defaults for the execute and render for our components and ajax behavior should be the same as for jsf f:ajax in order the tags to be fully consistent.

But according to current region implementation - maybe we wil change execute default for new "@region" value? It will allow the people not to write it each time them need region and would be usual for developers which was used richfaces in the past.

WDYT? I'm really not sure what is more common case to limit processing to some subtree or to use @this.

For sure if we would use JSF @this default - it would be still usefull as described above ok.. But that question should be risen in order we all to agreed with some point before release and be on the same page.

P.S.

It's eliminates cool feature of 3.3.x that users didn't carried about additional attribute definition and regions just worked for them.

We do not have really active polls for now.. In other case I would proposed the customers to say what them think more usefull.

https://jira.jboss.org/jira/browse/RF-8617 issue which should be reopened if we will decide to change default,

[jbalunas]

I agree it would be easier to have the default be @region, the problem is that if we change the default behavior from the one defined in spec:

• We may likely break interop with other libraries
  • What if another library made this change too?
  • what if others made assumtions based the default behavior?
• We also need to consider how this might effect templates, and composite components
  • How will the scope passed/captured
  • Will it create a situation where users are not sure what scope might be.

Is there a good way to toggle this at the region level?  So default could be left as is, but if usered wanted to override for the whole region they could?

If we need to discuss more at a team meeting lets do that.

[ilya_shaikovsky]

According to 05.05.10 meeting we decided that we have next ways. Way one seems preferrable for now. Any objections or we starting implementation?

1)

region component added to the page changing behavior of all nested RichFaces ajaxified controls :

• if such components has no execute defined - @region used by default
• if execute defined - it doesn't changed

if there is no region - components works according to JSF standard behavior - using @this as default.

So seems using this way - region component not reducing the processing area as in 3.3.x but enlarging it. From one point of view it adds some confusion but in general developer is fully responsible for regions addition to the page and from this point of view this looks normally.

2)

in order to avoid confusion with historical fact that region component was designed to reduce execute are to some subtree - we could change the execute default for all RichFaces components in any case to @region and if no regions it will became interpretted as @all. But in this case our components will have execute default opposite to JSF ajax.

[jbalunas]

2)

in order to avoid confusion with historical fact that region component was designed to reduce execute are to some subtree - we could change the execute default for all RichFaces components in any case to @region and if no regions it will became interpretted as @all. But in this case our components will have execute default opposite to JSF ajax.

I do not like this - RichFaces components should have the same default behavior as standard JSF.  If a user chooses to use region to modify that is fine, but out of the box our components should behave as others do.

Also - is there anyway to get other jsf components ( standard, or perhaps 3rd party ) to also use @region if in the region?

[alexsmirnov]

Option 1) seems more simple and logical for development, yet it is not clear for me: does region affects default behavior for "execute" or we propose to change "update" areas in the same way ?

[nbelaevski]

Also - is there anyway to get other jsf components ( standard, or perhaps 3rd party ) to also use @region if in the region?

I think it's not possible to do this in 100% interoperable manner.

does region affects default behavior for "execute" or we propose to change "update" areas in the same way ?

No, only "execute", and not "render" (unless limitRenderToRegion="true").