Practical implications of Facelets ui:remove tag - jsf

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

Related

Bootsfaces vs Bootstrap

I have used Bootstrap while development of Web Application. Now I have started learning of BootsFaces. While learning very first question pop up in my mind is
What is Exactly difference between Bootstrap and BootsFaces? and
what are their pros and cons over each other?
I searched for these answers but there wasn't any answer which make my doubt clear. Please help me for these questions.
BootsFaces is a JSF component library which generates HTML that uses Bootstrap. BootsFaces allows you to easily work with Bootstrap in a JSF application. Comparing them would be more or less the same as comparing red paint to a red painted board.
Some info from the BootsFaces showcase on this subject, specifically on layouting:
Why BootsFaces? Why not using Bootstrap natively?
BootsFaces takes full advantage of Bootstrap's Grid system while maintaining the benefits of being a JSF framework. Actually, we believe it's more concise and more expressive than programming Bootstrap natively. Convince yourself: inspect the source code of the demo in your browser's source code view. After reformatting, the form is 81 lines. The JSF source is is 45 lines.
BootsFaces being a JSF framework means that you can leverage Bootstrap's layout feature using - for example - the JSF templating system and JSF's conditional rendering to achieve and maintain very complex layouts without much effort.
This website is an example itself: it uses a page template with ui:insert and ui:include and the pages are ui:compositions.
See also:
What is the need of JSF, when UI can be achieved with JavaScript libraries such as jQuery and AngularJS

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

What are the benefits of using JSF2 resources?

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.

Are there “server-side comments” in JSF / Seam / RichFaces?

With the JSF/Seam/RichFaces stack, is there a way to mark up comments (on XHTML pages) so that they will not be included in the HTML output? I.e., something like JSP's <%-- comments --%>, as opposed to normal <!-- comments -->.
I heard that facelets.SKIP_COMMENTS context-param migth do this for normal HTML comments, but is there any other option? (After all, there might be some comments that you want included in the page output and some that you don't.)
Found an answer in a thread on the JSF for nonbelievers forum of IBM developerWorks:
<ui:remove><!--
<tags you want to remove/>
--></ui:remove>
See the official Facelets documentation of ui:remove for more information.
Use the facelets.SKIP_COMMENTS context-param. You won't need comments in the generated pages. They are not meant to be human-readable anyway.

Resources