I'm new to JSF (just started learning about it 4 days ago) and I'm a bit confused about the usage of h:outputText. I know that is a simple tag, but in most examples I've seen, it's used to output very simple (no need to escape), non-i18n text. For example (taken from here)
<h:outputText value="Transport" />
which could be replaced by
Transport
So, I'm wondering if I'm missing something or if most of the examples I've seen are overcomplicated to the point of insanity.
If you're using JSF 2.x with Facelets 2.x instead of JSP, then both are equally valid. Even more, Facelets implicitly wraps inline content in a component as represented by <h:outputText> (in other words, it will be escaped!).
Only whenever you'd like to disable escaping using escape="false", or would like to assign id, style, onclick, etc programmatically, or would like to use a converter (either explicit via converter or implicit via forClass), then you need <h:outputText>.
I myself don't use <h:outputText> whenever it is not necessary. Without it, the source code becomes better readable. You can just inline EL in template text like so #{bean.text} instead of doing <h:outputText value="#{bean.text}">. Before JSF 2.0, in JSP and Facelets 1.x, this was not possible and thus the <h:outputText> is mandatory. If your IDE gives warnings on this, it's most likely JSF 1.x configured/minded.
The example you quote is written in XHTML - which is XML. A standalone 'Transport' may not be allowed at the position you want to put it in, so that you need to "transform" it into valid xml.
IIrc this what is called facelets and the default in JSF2, while in JSF1, the presentation code could be done with JSP tags as default and facelets was an alternative that many developers were using).
h:outputText tag is required only if you are rendering the text based on some render condition.
eg: <h:outputText value="Transport" rendered="#{myBean.displayText}"/>.
If its a simple output statement then there is no need of using the tag; you could just use: Transport
Related
I have a question about the idea behind the fact, that only UIForm got the attribute prependId. Why is the attribute not specified in the NamingContainer interface? You will now probably say that's because of backward compability but I would preferre breaking the compability and let users which implement that interface, also implement methods for the prependId thing.
The main problem from my perspective about the prependId in the UIForm component is, that it will break findComponent()
I would expect that if I use prependId, then the NamingContainer behaviour would change, not only related to rendering but also when wanting to search for components in the component tree.
Here a simple example:
<h:form id="test" prependId="false">
<h:panelGroup id="group"/>
</h:form>
Now when i want to get the panelGroup component I would expect to pass the string "group" to the method findComponent(), but it won't find anything, I have to use "test:group" instead.
The concrete problem with that is, when using ajax with prependId="false". The ajax tag expects in the attributes update and process, that the values care of naming containers. It's a bit strange that when I use prependId="false" that I have to specify the full id or path, but okay.
<h:form id="test" prependId="false">
<h:panelGroup id="group"/>
</h:form>
<h:form id="test1" prependId="false">
<h:commandButton value="go">
<f:ajax render="test:group"/>
</h:commandButton>
</h:form>
Well this code will render without problems but it won't update the panelGroup because it cannot find it. The PartialViewContext will contain only the id "group" as element of the renderIds. I don't know if this is expected, probably it is but I don't know the code. Now we come to the point where the method findComponent() can not find the component because the expression passed as parameter is "group" where the method would expect "test:group" to find the component.
One solution is to write your own findComponent() which is the way I chose to deal with this problem. In this method i handle a component which is a NamingContainer and has the property prependId set to false like a normal UIComponent. I will have to do that for every UIComponent which offers a prependId attribute and that is bad. Reflection will help to get around the static definition of types but it's still not a really clean solution.
The other way would be introducing the prependId attribute in the NamingContainer interface and change the behaviour of findComponent() to work like described above.
The last proposed solution would be changing the behaviour of the ajax tag to pass the whole id, but this would only solve the ajax issue and not the programmatic issues behind the findComponent() implementation.
What do you think about that and why the hell is it implemented like that? I can't be the first having this problem, but I wasn't able to find related topics?!
Indeed, UIComponent#findComponent() as done by <f:ajax render> fails when using <h:form prependId="false">. This problem is known and is a "Won't fix": JSF spec issue 573.
In my humble opinion, they should never have added the prependId attribute to the UIForm during the JSF 1.2 ages. It was merely done to keep j_security_check users happy who would like to use a JSF form with JSF input components for that (j_security_check requires exact input field names j_username and j_password which couldn't be modified by configuration). But they didn't exactly realize that during JSF 1.2 another improvement was introduced which enables you to just keep using <form> for that instead of sticking to <h:form>. And then CSS/jQuery purists start abusing prependId="false" to avoid escaping the separator character : in their poorly chosen CSS selectors.
Just don't use prependId="false", ever.
For j_security_check, just use <form> or the new Servlet 3.0 HttpServletRequest#login(). See also Performing user authentication in Java EE / JSF using j_security_check.
For CSS selectors, in case you absolutely need an ID selector (and thus not a more reusable class selector), simply wrap the component of interest in a plain HTML <div> or <span>.
See also:
How to select JSF components using jQuery?
How to use JSF generated HTML element ID with colon ":" in CSS selectors?
By default, JSF generates unusable ids, which are incompatible with css part of web standards
I need to complete a xhtml page with some JSF code (with p:panel and p:datatables, etc.) from a managed bean, but I'm not sure that is possible.
My attemps:
1º
<h:outputText escape="true" value="#{controller.jsfString}"/>
It's not be able to understand "p:" components, only simple html.
2º
<ui:include src="#{controller.jsfString}">
It expects a xhtml path, not a String.
I don't know what else try... Is it even possible?
It's not be able to understand "p:" components, only simple html.
Of course it is not!
The h:outputText value is evaluated at view render time, so if you render JSF tags, they won't be evaluated again since rendering is done.
In principle, it could have been possible to add JSF tags this way using the JSTL <c:out>, but it is not available in JSF facelets.
Anyway, just tell yourself that it prevents you from making bad design.
We'll need more information regarding what the controller is supposed to output in order to help you.
Here p means prime-faces u need to include prime-faces dependency in pom and enable tag lib for prime-faces in XHTML then u can use the all the prime-faces components.
I'm trying to convert a JSP Page to JSF (no JSP code allowed), but have stumbled upon an issue.
Note: This is academic, so no "dirty" solution will do.
I have jsp code that sets the image source and alt text of an image depending on various conditions. There are concatenations and switch conditions. This is inside a loop.
Now, I can reproduce the loop that goes through all the values, like this:
<ui:repeat value="#{gameapi.game.fieldsList}" var="field">
<h:graphicImage id="field#{field.fieldNr}" styleClass="field#{field.fieldNr}"
url="..." alt="" title=""/>
</ui:repeat>
However, there's a total of over 20 combinations for the image url and alt text. Obviously, I doubt writing a conditionally rendered or chosen graphicImage Tag for every possibility is an elegant solution, since this would only get uglier with every additional combination.
I also cannot create those strings in the underlying java code, since that would violate the idea of separating view, model and controller.
So what is the best solution to do this? It seems like a huge weakness of JSF.
Consider using a variation on the MVVM pattern. You can have managed beans that are dedicated to view logic separate from the business logic managed beans.
<ui:repeat value="#{bizBean.list}" var="_row">
<h:graphicImage
url="#{viewModelBean.images[_row.outcome]}"
alt="#{viewModelBean.alts[_row.outcome]}"
title="#{viewModelBean.titles[_row.outcome]}" />
</ui:repeat>
viewModelBean could be an application-scoped type with a bunch of map properties. This assumes a relatively simple case, but the pattern is suited to more sophisticated requirements.
Note: the repeating control should be a NamingContainer, so trying to set the client identifier in the VDL is redundant. See here for more.
What is or could be a best practice?
Using standard JSF components and combine them by PrimeFaces components when needed (for example when DHTML or AJAX components are needed)
Forget all JSF Components and try to use all PrimeFaces components as much as possible
Please explain it and tell me about your experiences.
Thanks in advance...
PrimeFaces is your AJAX framework, so if you need to send ajaxical request, then use PrimeFaces components.
Even though, you dont need to send ajax request, but you can still use PF component, if u need to provide a consistency look for your web page. For example, h:commandButton and p:commandButton. Use p:commandButton if u need to send ajax request, but u can also do this
<p:commandButton ajax="false" action="Your Action here"/>
This will provide the same result as:
<h:commandButton action="Your Action here"/>
but this way, you can provide the same consistent look for your button throughout the page.
PrimeFaces does not have replacements for h:panelGrid, h:panelGroup, h:inputText, h:outputText ...
Depends on the sole functional requirement. If you're already using PrimeFaces and whatever you want to achieve can better/easier be achieved using a PrimeFaces component, use it.
Option 1 comes close, but option 2 goes overboard. PrimeFaces for example doesn't have a <p:form>, <p:panelGroup>, <p:outputText> or something.
With Primefaces it's very easy to get a consistent look for your application since it comes with Themeroller CSS framework. And you can easily switch designs. Although it is not difficult to let plain jsf components look like primefaces components if you apply the right css classes.
I think primefaces is a great component library. However some components are still buggy (e.g. date picker). So if you get some unexpected behavior with a primefaces component, it is alway good to have a jsf fallback (or an alternative from another component library or from jquery).
I have no experience with mixing different component libraries. Would be interesting to know, how they interact. But that would be subject of another question ...
I know what prependId="false" does. It set the flag so that the id of the form does not prepend the id of the form child, but why? any particular reason why you do or dont want to prepend id?
In my experience, I never use this attribute. However, in some cases it can be useful.
When you use Facelets, you can create templates or include pages inside another page. So you can imagine that a page could be included in several different pages. Take the example where the parent pages contain a form, with different id:
Page 1:
<h:form id="form1">
<ui:include src="pages/my-page.xhtml"/>
...
</h:form>
Page 2:
<h:form id="form2">
<ui:include src="pages/my-page.xhtml"/>
...
</h:form>
Now, in the my-page.xhtml, you have a <h:inputText id="foo"/>. In the first case, the real ID of the input will be form1:foo, while in the second case, it will be form2:foo. This could create complex situations if you need a direct access to this component in Javascript or in Java (using findComponent("...") method).
If you use prependId="false" (or on some components forceId="true"), the real ID will be simply foo, and then your code will be simpler as you will not have to care about the container of the input field.
However, you will have to use this attribute carefully, as you may get a duplicate ID error if you use this prepend attribute too often...
In modern jsf versions it might also break ajax, see UIForm with prependId="false" breaks <f:ajax render>
A situation where prependId=false is useful is in the login form, if you are using Spring Security, because the ids of the inputtexts have to be exactly "j_username" and "j_password". So you shouldn't put the form id before them, and using prependId=false is a good choice to acheive this.
I prefer to add prependId occasionally to make styling elements via their ID classes easier. For example, a form:
<h:form id="myform" ... >
<h:inputText id="mytext" ... />
</h:form>
Would give you an ID of myform:mytext. As the colon is reserved in CSS, you have to escape the CSS to read something like #myform\:mytext { ... } which I prefer not to do. With prependId="false" I get to use just #mytext { ... } which is much simpler & nicer to read. It also plays nicer with CSS preprocessors like LESS or Sass.
One scenario where we have to set this flag is in case of Autocomplete control of primefaces library.
I had to set this flag to false when I was trying AutoComplete control of primefaces library. I was not able to get autocomplete working but after setting this flag it worked fine. You can see this link to my question regarding this problem
WARN [Parameters] Parameters: Invalid chunk ignored. warning coming in primefaces application
In addition to making for CSS selectors easier, using prependId=false makes it easier to use JavaScript and jQuery to access specific elements.
Otherwise, without using RichFaces, to get at an elmement by id using jQuery you'll have to use an ugly escape sequence like:
jQuery("form-id\\:element-id")