Actually, all of those examples on the web wherein the common content/file type like "js", "css", "img", etc is been used as library name are misleading.
Real world examples
To start, let's look at how existing JSF implementations like Mojarra and MyFaces and JSF component libraries like PrimeFaces and OmniFaces use it. No one of them use resource libraries this way. They use it (under the covers, by @ResourceDependency
or UIViewRoot#addComponentResource()
) the following way:
<h:outputScript library="javax.faces" name="jsf.js" />
<h:outputScript library="primefaces" name="jquery/jquery.js" />
<h:outputScript library="omnifaces" name="omnifaces.js" />
<h:outputScript library="omnifaces" name="fixviewstate.js" />
<h:outputScript library="omnifaces.combined" name="[dynamicname].js" />
<h:outputStylesheet library="primefaces" name="primefaces.css" />
<h:outputStylesheet library="primefaces-aristo" name="theme.css" />
<h:outputStylesheet library="primefaces-vader" name="theme.css" />
It should become clear that it basically represents the common library/module/theme name where all of those resources commonly belong to.
Easier identifying
This way it's so much easier to specify and distinguish where those resources belong to and/or are coming from. Imagine that you happen to have a primefaces.css
resource in your own webapp wherein you're overriding/finetuning some default CSS of PrimeFaces; if PrimeFaces didn't use a library name for its own primefaces.css
, then the PrimeFaces own one wouldn't be loaded, but instead the webapp-supplied one, which would break the look'n'feel.
Also, when you're using a custom ResourceHandler
, you can also apply more finer grained control over resources coming from a specific library when library
is used the right way. If all component libraries would have used "js" for all their JS files, how would the ResourceHandler
ever distinguish if it's coming from a specific component library? Examples are OmniFaces CombinedResourceHandler
and GraphicResourceHandler
; check the createResource()
method wherein the library is checked before delegating to next resource handler in chain. This way they know when to create CombinedResource
or GraphicResource
for the purpose.
Noted should be that RichFaces did it wrong. It didn't use any library
at all and homebrewed another resource handling layer over it and it's therefore impossible to programmatically identify RichFaces resources. That's exactly the reason why OmniFaces CombinedResourceHander
had to introduce a reflection-based hack in order to get it to work anyway with RichFaces resources.
Your own webapp
Your own webapp does not necessarily need a resource library. You'd best just omit it.
<h:outputStylesheet name="css/style.css" />
<h:outputScript name="js/script.js" />
<h:graphicImage name="img/logo.png" />
Or, if you really need to have one, you can just give it a more sensible common name, like "default" or some company name.
<h:outputStylesheet library="default" name="css/style.css" />
<h:outputScript library="default" name="js/script.js" />
<h:graphicImage library="default" name="img/logo.png" />
Or, when the resources are specific to some master Facelets template, you could also give it the name of the template, so that it's easier to relate each other. In other words, it's more for self-documentary purposes. E.g. in a /WEB-INF/templates/layout.xhtml
template file:
<h:outputStylesheet library="layout" name="css/style.css" />
<h:outputScript library="layout" name="js/script.js" />
And a /WEB-INF/templates/admin.xhtml
template file:
<h:outputStylesheet library="admin" name="css/style.css" />
<h:outputScript library="admin" name="js/script.js" />
For a real world example, check the OmniFaces showcase source code.
Or, when you'd like to share the same resources over multiple webapps and have created a "common" project for that based on the same example as in this answer which is in turn embedded as JAR in webapp's /WEB-INF/lib
, then also reference it as library (name is free to your choice; component libraries like OmniFaces and PrimeFaces also work that way):
<h:outputStylesheet library="common" name="css/style.css" />
<h:outputScript library="common" name="js/script.js" />
<h:graphicImage library="common" name="img/logo.png" />
Library versioning
Another main advantage is that you can apply resource library versioning the right way on resources provided by your own webapp (this doesn't work for resources embedded in a JAR). You can create a direct child subfolder in the library folder with a name in the \d+(_\d+)*
pattern to denote the resource library version.
WebContent
|-- resources
| `-- default
| `-- 1_0
| |-- css
| | `-- style.css
| |-- img
| | `-- logo.png
| `-- js
| `-- script.js
:
When using this markup:
<h:outputStylesheet library="default" name="css/style.css" />
<h:outputScript library="default" name="js/script.js" />
<h:graphicImage library="default" name="img/logo.png" />
This will generate the following HTML with the library version as v
parameter:
<link rel="stylesheet" type="text/css" href="/contextname/javax.faces.resource/css/style.css.xhtml?ln=default&v=1_0" />
<script type="text/javascript" src="/contextname/javax.faces.resource/js/script.js.xhtml?ln=default&v=1_0"></script>
<img src="/contextname/javax.faces.resource/img/logo.png.xhtml?ln=default&v=1_0" alt="" />
So, if you have edited/updated some resource, then all you need to do is to copy or rename the version folder into a new value. If you have multiple version folders, then the JSF ResourceHandler
will automatically serve the resource from the highest version number, according to numerical ordering rules.
So, when copying/renaming resources/default/1_0/*
folder into resources/default/1_1/*
like follows:
WebContent
|-- resources
| `-- default
| |-- 1_0
| | :
| |
| `-- 1_1
| |-- css
| | `-- style.css
| |-- img
| | `-- logo.png
| `-- js
| `-- script.js
:
Then the last markup example would generate the following HTML:
<link rel="stylesheet" type="text/css" href="/contextname/javax.faces.resource/css/style.css.xhtml?ln=default&v=1_1" />
<script type="text/javascript" src="/contextname/javax.faces.resource/js/script.js.xhtml?ln=default&v=1_1"></script>
<img src="/contextname/javax.faces.resource/img/logo.png.xhtml?ln=default&v=1_1" alt="" />
This will force the webbrowser to request the resource straight from the server instead of showing the one with the same name from the cache, when the URL with the changed parameter is been requested for the first time. This way the endusers aren't required to do a hard refresh (Ctrl+F5 and so on) when they need to retrieve the updated CSS/JS resource.
Please note that library versioning is not possible for resources enclosed in a JAR file. You'd need a custom ResourceHandler
. See also How to use JSF versioning for resources in jar.
See also:
Best Answer
<p:commandXxx process>
<p:ajax process>
<f:ajax execute>
The
process
attribute is server side and can only affectUIComponent
s implementingEditableValueHolder
(input fields) orActionSource
(command fields). Theprocess
attribute tells JSF, using a space-separated list of client IDs, which components exactly must be processed through the entire JSF lifecycle upon (partial) form submit.JSF will then apply the request values (finding HTTP request parameter based on component's own client ID and then either setting it as submitted value in case of
EditableValueHolder
components or queueing a newActionEvent
in case ofActionSource
components), perform conversion, validation and updating the model values (EditableValueHolder
components only) and finally invoke the queuedActionEvent
(ActionSource
components only). JSF will skip processing of all other components which are not covered byprocess
attribute. Also, components whoserendered
attribute evaluates tofalse
during apply request values phase will also be skipped as part of safeguard against tampered requests.Note that it's in case of
ActionSource
components (such as<p:commandButton>
) very important that you also include the component itself in theprocess
attribute, particularly if you intend to invoke the action associated with the component. So the below example which intends to process only certain input component(s) when a certain command component is invoked ain't gonna work:It would only process the
#{bean.foo}
and not the#{bean.action}
. You'd need to include the command component itself as well:Or, as you apparently found out, using
@parent
if they happen to be the only components having a common parent:Or, if they both happen to be the only components of the parent
UIForm
component, then you can also use@form
:This is sometimes undesirable if the form contains more input components which you'd like to skip in processing, more than often in cases when you'd like to update another input component(s) or some UI section based on the current input component in an ajax listener method. You namely don't want that validation errors on other input components are preventing the ajax listener method from being executed.
Then there's the
@all
. This has no special effect inprocess
attribute, but only inupdate
attribute. Aprocess="@all"
behaves exactly the same asprocess="@form"
. HTML doesn't support submitting multiple forms at once anyway.There's by the way also a
@none
which may be useful in case you absolutely don't need to process anything, but only want to update some specific parts viaupdate
, particularly those sections whose content doesn't depend on submitted values or action listeners.Noted should be that the
process
attribute has no influence on the HTTP request payload (the amount of request parameters). Meaning, the default HTML behavior of sending "everything" contained within the HTML representation of the<h:form>
will be not be affected. In case you have a large form, and want to reduce the HTTP request payload to only these absolutely necessary in processing, i.e. only these covered byprocess
attribute, then you can set thepartialSubmit
attribute in PrimeFaces Ajax components as in<p:commandXxx ... partialSubmit="true">
or<p:ajax ... partialSubmit="true">
. You can also configure this 'globally' by editingweb.xml
and addAlternatively, you can also use
<o:form>
of OmniFaces 3.0+ which defaults to this behavior.The standard JSF equivalent to the PrimeFaces specific
process
isexecute
from<f:ajax execute>
. It behaves exactly the same except that it doesn't support a comma-separated string while the PrimeFaces one does (although I personally recommend to just stick to space-separated convention), nor the@parent
keyword. Also, it may be useful to know that<p:commandXxx process>
defaults to@form
while<p:ajax process>
and<f:ajax execute>
defaults to@this
. Finally, it's also useful to know thatprocess
supports the so-called "PrimeFaces Selectors", see also How do PrimeFaces Selectors as in update="@(.myClass)" work?<p:commandXxx update>
<p:ajax update>
<f:ajax render>
The
update
attribute is client side and can affect the HTML representation of allUIComponent
s. Theupdate
attribute tells JavaScript (the one responsible for handling the ajax request/response), using a space-separated list of client IDs, which parts in the HTML DOM tree need to be updated as response to the form submit.JSF will then prepare the right ajax response for that, containing only the requested parts to update. JSF will skip all other components which are not covered by
update
attribute in the ajax response, hereby keeping the response payload small. Also, components whoserendered
attribute evaluates tofalse
during render response phase will be skipped. Note that even though it would returntrue
, JavaScript cannot update it in the HTML DOM tree if it was initiallyfalse
. You'd need to wrap it or update its parent instead. See also Ajax update/render does not work on a component which has rendered attribute.Usually, you'd like to update only the components which really need to be "refreshed" in the client side upon (partial) form submit. The example below updates the entire parent form via
@form
:(note that
process
attribute is omitted as that defaults to@form
already)Whilst that may work fine, the update of input and command components is in this particular example unnecessary. Unless you change the model values
foo
andbar
insideaction
method (which would in turn be unintuitive in UX perspective), there's no point of updating them. The message components are the only which really need to be updated:However, that gets tedious when you have many of them. That's one of the reasons why PrimeFaces Selectors exist. Those message components have in the generated HTML output a common style class of
ui-message
, so the following should also do:(note that you should keep the IDs on message components, otherwise
@(...)
won't work! Again, see How do PrimeFaces Selectors as in update="@(.myClass)" work? for detail)The
@parent
updates only the parent component, which thus covers the current component and all siblings and their children. This is more useful if you have separated the form in sane groups with each its own responsibility. The@this
updates, obviously, only the current component. Normally, this is only necessary when you need to change one of the component's own HTML attributes in the action method. E.g.Imagine that the
oncomplete
needs to work with thevalue
which is changed inaction
, then this construct wouldn't have worked if the component isn't updated, for the simple reason thatoncomplete
is part of generated HTML output (and thus all EL expressions in there are evaluated during render response).The
@all
updates the entire document, which should be used with care. Normally, you'd like to use a true GET request for this instead by either a plain link (<a>
or<h:link>
) or a redirect-after-POST by?faces-redirect=true
orExternalContext#redirect()
. In effects,process="@form" update="@all"
has exactly the same effect as a non-ajax (non-partial) submit. In my entire JSF career, the only sensible use case I encountered for@all
is to display an error page in its entirety in case an exception occurs during an ajax request. See also What is the correct way to deal with JSF 2.0 exceptions for AJAXified components?The standard JSF equivalent to the PrimeFaces specific
update
isrender
from<f:ajax render>
. It behaves exactly the same except that it doesn't support a comma-separated string while the PrimeFaces one does (although I personally recommend to just stick to space-separated convention), nor the@parent
keyword. Bothupdate
andrender
defaults to@none
(which is, "nothing").See also: