Apache MyFaces jsf.js queue control

Introduction

As some people might have noticed our javascripts are bigger than Mojarras. There is a reason for it, besides our internal structures completely different we have a set of extensions which yet have to make it into the official spec (all of it has been donated to the EG)

I already wrote about the fileupload via ajax, and again, I have to warn, if you use that stuff you are bound to MyFaces.

But nevertheless, partial page submit and queue control are two important features which have been enabled since 2.0.1:

Queue Control, what is it?

The official spec enforces following behavior: if you submit an Ajax post it is either sent directly if no other submit is running or enqueued until the running ajax submit has terminated and then the submit is issued.

Now this causes following problems

The typical fast typing Ajax input.

Here typing happens on the fly and a load of submits are issued, they are either queued or simply sent to the server causing constant loads.

The long running Request

Here a request hangs for a longer period of time, filling the client queue.

For those two szenarios we introduced (thanks to the j4fryguys Ganesh and Alax who donated the code), advanced queue control.

Here is the deal on how to use it (and again the obligatory you bind yourself to myfaces warning)

First a short introduction to our configuration system: We are very modular all layers are bound late via configuration and also vital parts of the system can be replaced without digging into the code internals that way, this configuration system also can be used to override certain default behavior.
Now there are to ways to override the configuration, you can do it globally under the myfaces.config namespace or locally by pushing another additional set of parameters in the options map under myfaces (example below)

An example for a global configuration for instance is:


an example for a local configuration override for a single request is:


Now we have following possibilities in our codebase:

timeout: describes a value of miliseconds upon the current request should be terminated for good and the next one be issued

delay: describes a delay period where the system waits for the next input before issuing the submitted. If an input is sent before the delay period is over the old request is canceled upfront and the new one is enqueued delayed.

queuesize: This limits the queue size of the request queue to the specified number of elements, if the queue is bigger than what is provided older elements are dropped until the queue size is fulfilled. If issued locally the reduction is only done temporarily.

For a typical ajax scenario following might be a viable approach:

Second Part, PPS

This solves following scenario, per spec definition the entire form passed down must be submitted at each Ajax scenario. Often this is unnecessary, especially if you only execute parts of the subtree. Unnecessary data is passed down and if you have something like a textfield in the form then it is even heavy on the server.

There pps helps. With pps you will just pass what is needed to be executed, you also can put the execute on a parent node and it determines which childs have to be passed down the execution chain and it only submits the parameters it really needs to pass down.

(note this does not work in the ajax fileupload case)

Here is an example on how to use it:


again this also can be set globally via
myfaces.config.pps = true