What are the benefits of using JSF2 resources? - jsf

Should I use JSF2 resources instead of plain html like <link href... or url(image.png)? What are the benefits? For me this is a bit annoying when web-designer creates layout with XHTML, CSS and all that stuff and I need to spend time to replace plain HTML paths and tags to JSF resource tags like#{resource[...]}.
Is there any other way? Like to put all CSS/image files in web root and use normal links?

Your choice.
The major benefit is that you can declare them on a per-component basis. If you need to include them on every single page anyway, then the benefit is little. But if you need to include component-specific CSS/JS code in for example a composite component which is reused more than once in a single view, then for example an <h:outputScript> in a composite component would end up in it being included only once instead of that many times as the composite component is been used as would happen with <script>. The same applies to the #ResourceDependency annotation on real UIComponent classes.
Please note that you are not required to use JSF2 resources only. Just plain vanilla <img>, <link>, <script>, etc is also perfectly fine. It can even point to the JSF resources folder.

Related

How behaves f:view with many defined resource library contracts?

We're trying to use the <f:view contracts="xxx" /> feature from JSF 2.2, with many simultaneous contracts, as "contract1,contract2".
In our contract1, we have a file style1.css, and in our contract2, a style2.css. We include both in our views through <h:outputStylesheet /> tags.
If I only use contracts="contract1" in the view, JSF logs than style2.css is missing, which is logical.
If I use contracts="contract1,contract2", JSF imports both style1.css and style2.css, but with a faulty url (it uses &con=contract1 instead of &con=contract2 to get the resource).
Is it a bug? Is it normal? I can't find any documentation about the use of many simultaneous contracts.
That's normal behaviour, as I've found in the Apress Pro JSF and HTML 5 text book. An excerpt:
It's possible to map multiple contracts to a single mapping. In that case, it will go through each contract sequentially to look for the required templates. Once a template has been found, it will stop processing other templates.
As to why it's allowed, if all it's going to do is pick the first suitable option, I'm with you on the fact that it may be pointless after all.
Reference:
Apress Pro JSF and HTML 5

How to render a block in JSF, similar to Tapestry <delegate to="xxx"> tag

I am trying to convert a Tapestry application to JSF.
Tapestry has a useful feature, block.
You can have many blocks (typically html snippets) on a page,
and then, using the <delegate to="block"> component, choose one block
and render it dynamically at runtime.
Here is the Tapestry block documentation:
http://tapestry.apache.org/5.3.7/apidocs/org/apache/tapestry5/corelib/components/Delegate.html
The closest thing I could find is <ui:include src="#{sampleBean.block}"/>
where sampleBean.getBlock() returns something like "/templates/block1.xhtml"
at runtime.
This solution forces me to have many small block files, which I don't think is efficient
or the best way to go.
Does nyone have a better solution? Thanks.
I solved this <ui:include>ing template that contains series of blocks, and using a parameter, only one would be rendered at a time

Practical implications of Facelets ui:remove tag

I want to understand the basic mechanism of <ui:remove>. As per my knowledge, <ui:remove> is basically used in conjunction when basic HTML stuff is part of your Facelets page. When you want, when rendering of the Facelets page happen, it should ignore this part of HTML code, we can use the <ui:remove> tag.
Still I am confused about practical implications of <ui:remove>. How often we need to use this Facelets tag? Additionally, the Facelets page is not compiled everytime when the page is hit.
It's useful to remove content which is required during design time, but not during run time, such as comments, some stubbed content (e.g. "lorem ipsum") which aids in filling up the page content to fit the layout in visual designers such as Dreamweaver, etc.
If you're not a page designer, but already retrieve designs as PSD/AI/etc, it's indeed useless to you.
See also:
Is there a way to run a JSF page without building the whole project?
Outcommented Facelets code still invokes EL expressions like #{bean.action()} and causes javax.el.PropertyNotFoundException on #{bean.action}
JSF display HTML comment

JSF to set style in stylesheets?

So I'm trying to create a webpage with customizable style for each user. You can save style options as strings in a JSF bean property and access them in inline style attributes, or <style> tags within a webpage very easily, but who uses inline/onpage styling anymore?
Is there any way to forward these properties from a JSF (2.0) bean to my stylesheet or am I required to simply add <style> blocks to the pages I wish to be customizable?
EDIT: I guess I could make a function to write these properties to a stylesheet, making one for each user, but this is obviously not preferred.
For full customization, you could save stylesheets for all the changeable elements and their style options and reference these with your bean properties.
Since that is quite a bit of stylesheets though, you could just define your own style schemes and give the users a choice between these pre-defined stylesheets. This doesn't exactly answer your question but would save a lot of work
I'm not sure exactly what your functionality is, but one option would be ->
<h:outputStylesheet library="css" name="#{userBean.styleSheetName}" />
Where the "UserBean" had names of sheets.
Alternatively you could just output the stylesheet (as you said) inbetween the style tags. If you wanted to go nuts you could write a servlet that read the user's session and generated a cached stylesheet.
I would definitely go the servlet route for the functionality you're suggesting, but if it is just a "set" of stylesheets the users have access to, I would probably use a simple dynamic property as per the first example.

How to generate and handle dynamic layouts and symbols in JSF/Richfaces?

My objective is to generate a graphic layout (made of Richfaces components) based on some input configuration (like an XML file) and display it in my web app. The layout is composed of graphic symbols representing various entities in the system: each symbol should be mapped to an entity in the system, in order to display its state. The XML configuration file is used to define the symbol connections and positions within the layout, and their mapping rules to an entity. How can I achieve this?
I was thinking to create a symbol library in a technology such as SVG, where you can define both the aspect and the behaviour, and then simply "wrap" each SVG symbol in a dynamically created richfaces component, which would allow me to handle both the user interactions and the mapping rules defined in the symbol. Unfortunately JSF/Richfaces don't support SVG images, therefore I would have to use plain HTML without Richfaces features.
Another way to achieve that would be to simply define generic symbols in the XML file, each one of them with an attribute specifying the related image, the mapping rule, etc., and then generate the corresponding richfaces component from within the web-app. By doing so, would I be able to then display all the symbols in the right position and therefore generate the complete dynamic layout?
Could you suggest a better approach? Thank you very much.
I believe that HTML5 has direct support for SVG images, however it is still an embedded object in regular HTML after all. This too is something I have been waiting for however I don't believe any of the current JSF2 component libraries have an offerring for this yet.
Here is a good explanation of a possible workaround:
Getting started with SVG graphics objects in JSF 2.0 pages
Potentially you could build a custom facelet component utilizing this workaround?
My thought though is that when your only tool is a hammer, everything looks like a nail. I would try to utilize an RIA (Rich Internet Application) technology better suited for display and manipulation of vector graphics like HTML5, Flash+Flex, Silverlight, etc..

Resources