Assotiation of smart Queue and ajax Status with Ajax compone

[ilya_shaikovsky]

Points that we need to achieve in the result:

allow the user to define default statuses and queues for ajax components which covers most cases and not requires additional definitions on ajax components.

Allow the user to split his ajax components into logical groups (validators, submits, etc..) and define different common statuses/queues for them.

Move the options which actually belongs to queue/status into them and not to duplicate at ajax action components

To unify the association ways as much as possible.

Queue
Current queue definition way seems good enough to continue with it in further versions:

Common Queue defined for application globally.
Common Queue defined for view
Common Queue defined for form
separate Queue defined at component level

The main point of redesign there is to move the queue related options from ajax components attributes set.
So the best way of moving the parameters out of the components is to define the queue/attributes for common queue for separate component not with an attributes but with child behavior tag:
Declaration for placing the button request to common queue but redefining some parameters:

<a4j:commandButton..>
 <a4j:attachQueue requestDelay="1000" ignoreDupResponses="true">
<a4j:commandButton>

Declaration for placing the button request to some named queue also with redefining some parameters:

<a4j:commandButton..>
 <a4j:attachQueue requestDelay="1000" ignoreDupResponses="true" queueId="customQueue">
<a4j:commandButton>

Status
With the status component we had some different situation:

We have no attributes at Ajax components which related to status except the status to associate with.
Definition separate statuses for some logical groups of the components placed at one form is more often use-case than for queue. So we have to simplify the redefinition of a status for a number of components as much as possible.

Common statuses definition:
1) Common for view.
2) common for form
Both should be defined without id/name the same as for queue.

And for separate statuses definition we have next options:

Option 1
Taking into consideration the initial points - seems we have no need to define the status association with the behavior as we do it for queue. So leaving an attribute statusId at Ajax components should be enough and it will produce less page code for such redefinitions.

<h:inputText>
 <a4j:ajaxValidator.. statusId="validationStatus"/>
</h:inputText>
<a4j:commandButton.. statusId="storingStatus"/>
<a4j:commandButton.. statusId="revertStatus"/>

Option 2
To use the behavior as describe for queue association.

<h:inputText>
 <a4j:ajaxValidator.. >
 <a4j:attachStatus statusId="foo"...>
 </a4j:ajaxValidator>
</h:inputText>
<a4j:commandButton..>
 <a4j:attachStatus statusId="foo">
</a4j:commandButton>

Differences between two options looks simple:
In the second case all the code of association the status with a component moved to separate behavior but the end-developer code grows(to define only one property). But with the first approach which looks simpler for users our components still need to have mechanisms to register itself at the queue.

I prefer the way with an attribute in order to make declaration simpler.

[nbelaevski]

1. "grows a bit" - I think that's not excatly true - handwork increase required to type in this tags will be noticeable by the user

2. <a4j:attachStatus> has a single attribute - IMHO, it's not very useful to make this a separate tag that will have just a single attribute

3. My concern about behaviors - looks like they can't be nested one inside other.

[ilya_shaikovsky]

yes, our a4j:ajax and a4j:attachQueue was discussed as a behaviors.

So, Nick's 3) concern is seems main there (we looked and seems JSF behaviors not actually designed to be nested).. So now we not sure that we should deal with both appraches (status and queue) as a behaviors.

[jbalunas]

Ilya good write up of the discussion from the meeting!

For queue I think we can all agree on the <a4j:attachQueue/>. I also like the expanded definition including support for default queues that may be in place (i.e. no queueId defined in component).

For status I can see much clearer now that the <a4j:attachStatus/> approach requires more writing from the users. Although I still prefer this approach I agree it could be too cumbersome.

The only way I could see having <a4j:attachStatus/> is if there are more status related attributes or parameters needed. For now that is not the case.

As for Nicks concern over nesting behaviors - I don't think there is a need to nest behaviors. A component can have multiple behaviors, but behaviors don't really need other behaviors. (Although I would be curious why this is limited by the spec)

One use-case where I could see nesting behaviors is if you wanted to associate a specific queue with a specific <f:ajax request like:

<h:inputText>
 <f:ajax event="keyup"...>
 <a4j:attachQueue queueId="foo"/>
 </f:ajax>
 <f:ajax event="blur"...>
 <a4j:attachQueue queueId="bar".../>
 </f:ajax>
</h:inputText>

In this case perhaps something like this can be done:

<h:inputText>
 <f:ajax event="keyup".../>
 <f:ajax event="blur".../>
 <a4j:attachQueue queueId="foo" event="keyup"/>
 <a4j:attachQueue queueId="bar" event="blur".../>
</h:inputText>

This may actually make more sense because you have the ability to tie a queue to a specific event from the parent component.

Thoughts?

[ilya_shaikovsky]

Ok.. Then I will finalize the status points in wiki page.

And for you last snippet related to attachQueue behavior - it looks pretty good for me. Maybe not looks so clear as nested variant but seems the best one.. I just want Nick to look through to check if there are some troubles in implementation.

[nbelaevski]

What do you think about giving statuses a name and then address them by name and not by id? This will allow developer to add/remove statuses for the particular group of components easily.

[nbelaevski]

"ilya_shaikovsky" wrote:
I just want Nick to look through to check if there are some troubles in implementation.

This approach looks definitely easier for implementors.

[jbalunas]

"nbelaevski" wrote:
What do you think about giving statuses a name and then address them by name and not by id? This will allow developer to add/remove statuses for the particular group of components easily.

Can you provide a little example - just so it is clear?

[nbelaevski]

<a4j:status name="datascrollerStatusGroup" />
<rich:datascroller status="datascrollerStatusGroup"/>

<rich:dataTable>
 ... long block of data ...
</rich:dataTable>

<rich:datascroller status="datascrollerStatusGroup" />
<a4j:status name="datascrollerStatusGroup" />

Both statuses work simultaneuosly.

And, to compare, variant without names, with IDs only:

<a4j:status id="datascrollerStatusGroup1" />
<rich:datascroller status="datascrollerStatusGroup1, datascrollerStatusGroup2"/>

<rich:dataTable>
 ... long block of data ...
</rich:dataTable>

<rich:datascroller status="datascrollerStatusGroup1, datascrollerStatusGroup2" />
<a4j:status id="datascrollerStatusGroup2" />

[ilya_shaikovsky]

The only thing which prevent me to agree with that right now - I think the developers will think about name like about unique identifier. And it could be difficult for them to maitain statuses with the same names placed (by mistake or by design) in different templates at different templating levels and page parts.

[jbalunas]

I like the idea and think that you should create a jira with this feature request in it + the code sample to make it clear. Assign it to BETA1 and we'll revisit.

I'm torn regarding having this in 4.0. I want to limit new features beyond what we need/want for JSF 2.0. However I like the idea of groups for this.

IMO - If we do implement something like this it should support both id and group based assignments and I think it makes it clearer if you have "status=""", and "statusGroup=""". If this is the way we go we may want to revisit using "<a4j:attachStatus..." again.

[nbelaevski]

We've created a small draft diagram for this feature, please take a look.