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 <[email protected]
<mailto:[email protected]>> 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
