You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Kito Mann <ki...@virtua.com> on 2010/06/29 01:40:35 UTC

ANNOUNCE: Using the RichFaces Queue

Hello,



This article shows you how to control traffic to the server using the
RichFaces queue. Here is an excerpt:



When building an Ajax application in JSF, one of the things you need to
consider is how to control traffic to the server. Although Ajax applications
make the application richer, quicker, and more interactive, in many
instances the end user is not aware that the client (browser) is sending
Ajax requests to the server. For example, if an input field fires an Ajax
event on the onkeyup event, the user can easily flood the server with to
many requests without even knowing it. This is also true of a regular button
that fires an Ajax request. In a traditional (non-Ajax) application, the
user is more aware that a request was sent. In such an application, the
browser window could go blank for a fraction of a second while the next page
is loaded. In other words, there is visual clue that page was submitted. But
if the button fires an Ajax request, the page is not reloaded. The user
could be clicking the button every second and not realizing that he or she
is firing new requests each time. If multiple requests are fired almost at
the same time, there is no guarantee they will be processed in the same
order without any additional work on the server.





Read the full article  here:
http://www.jsfcentral.com/articles/richfaces_queue.html



Kito D. Mann -- Author, JavaServer Faces in Action

http://twitter.com/kito99  http://twitter.com/jsfcentral

http://www.virtua.com - JSF/Java EE consulting, training, and mentoring

http://www.JSFCentral.com <http://www.jsfcentral.com/> - JavaServer Faces
FAQ, news, and info

+1 203-404-4848 x3

Re: Queue control (Undocumented MyFaces features) was: Re: ANNOUNCE: Using the RichFaces Queue

Posted by Werner Punz <we...@gmail.com>.
Hello Kito

first, I made a mistake global paramters are defined as

  <script type="text/javascript">
	     myfaces.config = myfaces.config || {};		
              myfaces.config.<param> = <fill your number in here>; 
</script>

the important thing is the config namespace is reserved for global 
myfaced javascript config parameters.

Secondly as for exposing at as a tag, yes this was discussed a while ago.

The original idea was to provide a myfaces:ajax tag with the additional 
functionality.

The reason why we have not exposed it was that no one has written the 
code yet. I am also not a big fan of providing core page functionality 
out of the spec within the impl all this stuff should be part of f:ajax, 
the users should not be bound to one impl but I definitely would not 
oppose such a tag also, if someone wants to write it.




Werner




Am 29.06.10 16:47, schrieb Kito Mann:
> Hello Werner,
>
> I'm really happy to hear about these features in MyFaces 2. How about
> exposing the queue and the partial page parameters via tags like
> RichFaces to make things a bit easier for developers?
> ---
> Kito D. Mann | twitter: kito99 | Author, JSF in Action
> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
> twitter: jsfcentral
> +1 203-404-4848 x3
>
> Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17
>
>
>
> On Tue, Jun 29, 2010 at 3:00 AM, Werner Punz <werner.punz@gmail.com
> <ma...@gmail.com>> wrote:
>
>     Sorry to add a MyFaces related sidenote to that original RichFaces
>     announcement post by Kito.
>
>     Queue control and timeouts are a huge gap in the JSF 2.0 Ajax specs.
>     The good side is, one of the reasons why our codebase is bigger than
>     Mojarras is, we have such a thing in our codebase (as well as
>     partial page submit) - (another reason is the OO Layer and the
>     faster ll parser based body and head stripping which outperforms
>     native html/xhtml browser parsing via iframs and xml parsing, for now)
>
>     The main issue is, while we have it in our codebase, you cannot
>     really expose it to the end users because it is not part of the spec.
>
>     you can use it following way:
>
>     <script type="text/javascript">
>             myfaces.queuesize = <fill your number in here>;
>     </script>
>
>     or
>     if you want to alter it dynamically on the fly
>     jsf.ajax.request(this, event, {myfaces:{queuesize:<fill in your
>     number here>}, render="bla", execute:"bla2"}
>
>
>     As I said the reason why this is not exposed is, because it is not
>     part of the spec and hence I am waiting for the official API after
>     that I can expose the code.
>
>     If we already are at it, we have other features as well, here is an
>     example:
>     <h:commandButton id = "button1" value = "Increment left" action =
>     "#{count.increment}" onclick = "jsf.ajax.request(this, event,
>     {render: 'out1', execute: 'out1 button1',
>                                      myfaces:{errorlevel:'ERROR',
>     pps:true, queuesize:1}}); return false;" />
>
>
>     PPS is especially interesting because with it you can issue a
>     partial page submit, instead of sending down the full form always
>     you can limit the number of parameters sent (per default afair, the
>     execute chain).
>     The spec clearly states the entire issuing form must be encoded and
>     sent down, but with PPS you can limit that which gives an additional
>     extra on performance. We all got those features thanks to the j4fry
>     ajax code we integrated which already had it in.
>
>     Also an interesting feature is the timeout feature, with it you can
>     enable timeout control for the ajax part, so that after a given time
>     the issued Ajax request is dropped and the next one in the chain is
>     processed.
>
>     the config parameter is myfaces.timeout, you can apply it like the
>     queue control.
>
>     Werner
>
>     Am 29.06.10 01:40, schrieb Kito Mann:
>
>         Hello,
>
>         This article shows you how to control traffic to the server
>         using the
>         RichFaces queue. Here is an excerpt:
>
>         When building an Ajax application in JSF, one of the things you
>         need to
>         consider is how to control traffic to the server. Although Ajax
>         applications make the application richer, quicker, and more
>         interactive,
>         in many instances the end user is not aware that the client
>         (browser) is
>         sending Ajax requests to the server. For example, if an input field
>         fires an Ajax event on the onkeyup event, the user can easily
>         flood the
>         server with to many requests without even knowing it. This is
>         also true
>         of a regular button that fires an Ajax request. In a traditional
>         (non-Ajax) application, the user is more aware that a request
>         was sent.
>         In such an application, the browser window could go blank for a
>         fraction
>         of a second while the next page is loaded. In other words, there is
>         visual clue that page was submitted. But if the button fires an Ajax
>         request, the page is not reloaded. The user could be clicking
>         the button
>         every second and not realizing that he or she is firing new requests
>         each time. If multiple requests are fired almost at the same
>         time, there
>         is no guarantee they will be processed in the same order without any
>         additional work on the server.
>
>         Read the full article here:
>         http://www.jsfcentral.com/articles/richfaces_queue.html
>
>         Kito D. Mann -- Author, JavaServer Faces in Action
>
>         http://twitter.com/kito99 http://twitter.com/jsfcentral
>
>         http://www.virtua.com <http://www.virtua.com/> - JSF/Java EE
>         consulting,
>         training, and mentoring
>
>         http://www.JSFCentral.com <http://www.jsfcentral.com/> - JavaServer
>         Faces FAQ, news, and info
>
>         +1 203-404-4848 x3
>
>
>
>
>
>



Re: Queue control (Undocumented MyFaces features) was: Re: ANNOUNCE: Using the RichFaces Queue

Posted by Kito Mann <ki...@virtua.com>.
Hello Werner,

I'm really happy to hear about these features in MyFaces 2. How about
exposing the queue and the partial page parameters via tags like RichFaces
to make things a bit easier for developers?
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
jsfcentral
+1 203-404-4848 x3

Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17



On Tue, Jun 29, 2010 at 3:00 AM, Werner Punz <we...@gmail.com> wrote:

> Sorry to add a MyFaces related sidenote to that original RichFaces
> announcement post by Kito.
>
> Queue control and timeouts are a huge gap in the JSF 2.0 Ajax specs.
> The good side is, one of the reasons why our codebase is bigger than
> Mojarras is, we have such a thing in our codebase (as well as partial page
> submit) - (another reason is the OO Layer and the faster ll parser based
> body and head stripping which outperforms native html/xhtml browser parsing
> via iframs and xml parsing, for now)
>
> The main issue is, while we have it in our codebase, you cannot really
> expose it to the end users because it is not part of the spec.
>
> you can use it following way:
>
> <script type="text/javascript">
>        myfaces.queuesize = <fill your number in here>;
> </script>
>
> or
> if you want to alter it dynamically on the fly
> jsf.ajax.request(this, event, {myfaces:{queuesize:<fill in your number
> here>}, render="bla", execute:"bla2"}
>
>
> As I said the reason why this is not exposed is, because it is not part of
> the spec and hence I am waiting for the official API after that I can expose
> the code.
>
> If we already are at it, we have other features as well, here is an
> example:
>     <h:commandButton id = "button1" value = "Increment left" action =
> "#{count.increment}" onclick = "jsf.ajax.request(this, event, {render:
> 'out1', execute: 'out1 button1',
>                                 myfaces:{errorlevel:'ERROR', pps:true,
> queuesize:1}}); return false;" />
>
>
> PPS is especially interesting because with it you can issue a partial page
> submit, instead of sending down the full form always you can limit the
> number of parameters sent (per default afair, the execute chain).
> The spec clearly states the entire issuing form must be encoded and sent
> down, but with PPS you can limit that which gives an additional extra on
> performance. We all got those features thanks to the j4fry ajax code we
> integrated which already had it in.
>
> Also an interesting feature is the timeout feature, with it you can
> enable timeout control for the ajax part, so that after a given time the
> issued Ajax request is dropped and the next one in the chain is processed.
>
> the config parameter is myfaces.timeout, you can apply it like the queue
> control.
>
> Werner
>
> Am 29.06.10 01:40, schrieb Kito Mann:
>
>> Hello,
>>
>> This article shows you how to control traffic to the server using the
>> RichFaces queue. Here is an excerpt:
>>
>> When building an Ajax application in JSF, one of the things you need to
>> consider is how to control traffic to the server. Although Ajax
>> applications make the application richer, quicker, and more interactive,
>> in many instances the end user is not aware that the client (browser) is
>> sending Ajax requests to the server. For example, if an input field
>> fires an Ajax event on the onkeyup event, the user can easily flood the
>> server with to many requests without even knowing it. This is also true
>> of a regular button that fires an Ajax request. In a traditional
>> (non-Ajax) application, the user is more aware that a request was sent.
>> In such an application, the browser window could go blank for a fraction
>> of a second while the next page is loaded. In other words, there is
>> visual clue that page was submitted. But if the button fires an Ajax
>> request, the page is not reloaded. The user could be clicking the button
>> every second and not realizing that he or she is firing new requests
>> each time. If multiple requests are fired almost at the same time, there
>> is no guarantee they will be processed in the same order without any
>> additional work on the server.
>>
>> Read the full article here:
>> http://www.jsfcentral.com/articles/richfaces_queue.html
>>
>> Kito D. Mann -- Author, JavaServer Faces in Action
>>
>> http://twitter.com/kito99 http://twitter.com/jsfcentral
>>
>> http://www.virtua.com <http://www.virtua.com/> - JSF/Java EE consulting,
>> training, and mentoring
>>
>> http://www.JSFCentral.com <http://www.jsfcentral.com/> - JavaServer
>> Faces FAQ, news, and info
>>
>> +1 203-404-4848 x3
>>
>>
>>
>>
>
>

Queue control (Undocumented MyFaces features) was: Re: ANNOUNCE: Using the RichFaces Queue

Posted by Werner Punz <we...@gmail.com>.
Sorry to add a MyFaces related sidenote to that original RichFaces 
announcement post by Kito.

Queue control and timeouts are a huge gap in the JSF 2.0 Ajax specs.
The good side is, one of the reasons why our codebase is bigger than 
Mojarras is, we have such a thing in our codebase (as well as partial 
page submit) - (another reason is the OO Layer and the faster ll parser 
based body and head stripping which outperforms native html/xhtml 
browser parsing via iframs and xml parsing, for now)

The main issue is, while we have it in our codebase, you cannot really 
expose it to the end users because it is not part of the spec.

you can use it following way:

<script type="text/javascript">
	myfaces.queuesize = <fill your number in here>;
</script>

or
if you want to alter it dynamically on the fly
jsf.ajax.request(this, event, {myfaces:{queuesize:<fill in your number 
here>}, render="bla", execute:"bla2"}


As I said the reason why this is not exposed is, because it is not part 
of the spec and hence I am waiting for the official API after that I can 
expose the code.

If we already are at it, we have other features as well, here is an example:
      <h:commandButton id = "button1" value = "Increment left" action = 
"#{count.increment}" onclick = "jsf.ajax.request(this, event, {render: 
'out1', execute: 'out1 button1',
                                  myfaces:{errorlevel:'ERROR', pps:true, 
queuesize:1}}); return false;" />


PPS is especially interesting because with it you can issue a partial 
page submit, instead of sending down the full form always you can limit 
the number of parameters sent (per default afair, the execute chain).
The spec clearly states the entire issuing form must be encoded and sent 
down, but with PPS you can limit that which gives an additional extra on 
performance. We all got those features thanks to the j4fry ajax code we 
integrated which already had it in.

Also an interesting feature is the timeout feature, with it you can
enable timeout control for the ajax part, so that after a given time the 
issued Ajax request is dropped and the next one in the chain is processed.

the config parameter is myfaces.timeout, you can apply it like the queue 
control.

Werner

Am 29.06.10 01:40, schrieb Kito Mann:
> Hello,
>
> This article shows you how to control traffic to the server using the
> RichFaces queue. Here is an excerpt:
>
> When building an Ajax application in JSF, one of the things you need to
> consider is how to control traffic to the server. Although Ajax
> applications make the application richer, quicker, and more interactive,
> in many instances the end user is not aware that the client (browser) is
> sending Ajax requests to the server. For example, if an input field
> fires an Ajax event on the onkeyup event, the user can easily flood the
> server with to many requests without even knowing it. This is also true
> of a regular button that fires an Ajax request. In a traditional
> (non-Ajax) application, the user is more aware that a request was sent.
> In such an application, the browser window could go blank for a fraction
> of a second while the next page is loaded. In other words, there is
> visual clue that page was submitted. But if the button fires an Ajax
> request, the page is not reloaded. The user could be clicking the button
> every second and not realizing that he or she is firing new requests
> each time. If multiple requests are fired almost at the same time, there
> is no guarantee they will be processed in the same order without any
> additional work on the server.
>
> Read the full article here:
> http://www.jsfcentral.com/articles/richfaces_queue.html
>
> Kito D. Mann -- Author, JavaServer Faces in Action
>
> http://twitter.com/kito99 http://twitter.com/jsfcentral
>
> http://www.virtua.com <http://www.virtua.com/> - JSF/Java EE consulting,
> training, and mentoring
>
> http://www.JSFCentral.com <http://www.jsfcentral.com/> - JavaServer
> Faces FAQ, news, and info
>
> +1 203-404-4848 x3
>
>
>