a4j:apply - render time attributes manipulation

[ilya_shaikovsky]

This thread risen to discuss possible ways to implement the tag which will be able to find some group of components by some basis defined and manipulate with some it's attribute determining defined value for them.

very approximate usage sample:

...
<h:inputText..>
 <a4j:validator id="firstValidator".../>
</h:inputText..>
<h:selectOneMenu..>
 <a4j:validator id="secondValidator".../>
</h:selectOneMenu..>
....
<a4j:apply forId="*Validator" attribute="statusId" value="validation"/>
<a4j:status name="validation" ... />

or

...
<h:inputText..>
 <a4j:validator id="firstValidator".../>
</h:inputText..>
<h:selectOneMenu..>
 <a4j:validator id="secondValidator".../>
</h:selectOneMenu..>
....
<a4j:apply type="validator" attribute="queueId" value="customQueue"/>
<a4j:queue name="customQueue" ... />

Possible affected components selection ways:
1) based on id.(some wildcards, selectors).
Performace problems were mentioned at meeting
2) based on some type of the component (inputs, buttons, links..etc..)
Problem was risen by Nick that we have troubles identifying the components by just component-type
do we need some predefined list? (seems not good idea)

3..) thoughts?

values applying:
attribute - tag attribute which defines which attribute should be given with value.
value - actual value to be set.

One more problem risen by Nick that we could have a problems with EL-definitions there.

In any way it not seems like one of the components for the first releases. So moved from requirements wiki page to forum for discussion.

[jbalunas]

In general I like the idea, in some ways this reminds me of cross-cutting concerns much like Aspect oriented programming (AOP) for JSF components. There might be something here, but we certainly need to flush it out.

Some questions/concerns/thoughts/comments :

How difficult will wild cards be for component selection ( coding, performance, etc...)

I think to be really useful it would need to support both id & component type filtering.

You will also need to define when this tag is triggered - I would assume render time only.

A predefined list to components maybe too redundant and defeat the purpose of this tag in the first place.

What happens with VDL templates and/or new components introduced in the tree via rerendering.

[ilya_shaikovsky]

I think to be really useful it would need to support both id & component type filtering.

Fully agree.. We should discuss all the possible selectors in order to have this component highly flexible.

You will also need to define when this tag is triggered - I would assume render time only.

Also think so. Just question of implementation which could be revealed after we will be able to start some prototyping.

What happens with VDL templates

There I want to duplicate Alex wiki comment in order all who interested but looks only this thread read about it:

"The using component type to clarify target was only first idea. But, because not only components can require bulk attribute settings, it makes sense to use tag name as target - therefore, that tag should work at PDL level and use tag name as target."

[nbelaevski]

As a developer I want only one entry point - method that can be evaluated against all components and decide whether attributes should be applied or not. This eliminates need in tags for defining complex filtering conditions.

BTW, what about composite components?

[nbelaevski]

Tracked as: https://jira.jboss.org/jira/browse/RF-8268