Portlets + ajax API
[JAVASERVERFACES_SPEC_PUBLIC-966] Make finding components involved by <f:ajax> more flexible Created: 07/Apr/11 Updated: 24/Aug/15 Resolved: 12/Aug/14
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
Specifying the components for execution and re-rendering is very limited. Identifying components outside of a naming container is restricted to absolute component id paths. This is not very flexible. In combination with composite components this leads to requiring knowledge about the tree structure outside of the composite component. This breaks encapsulation.
This simple example is not possible at the moment:
There should be a much more flexible solution.
Furthermore the concept of solely defining the components that take part in a partial (AJAX) request (execute and render) by parameters submitted by the client is very limited.
AJAX requests for example could have a logical name. Components could receive an event or register a listener at the view root that can in turn decide whether the component has to participate in the request or not. This could ease the initially described limitation and allows loosely coupled ajaxified parts of the view.
|Comment by Hanspeter Duennenberger [ 18/Apr/11 ]|
There are components that should be rendered on all AJAX requests - like e.g. the h:messages area showing all the messages. There must be a way to add id's of components to render during PartialViewContext processing (see also my related blog for this https://insights2jsf.wordpress.com/2010/10/17/wrapping-partialviewcontext-or-howto-automatically-add-clientids-to-render-on-ajax-requests/).
Having said that - there might even be components to execute always. I actually created a tag <my:always render="..." execute="..." /> that can be placed on pages to specify areas on the page to render/execute always.
|Comment by Ed Burns [ 01/Aug/14 ]|
Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.