We use JSF 2.1, Glassfish 3.1.
We have a similar file upload solution to the one explained here: http://balusc.blogspot.hu/2009/12/uploading-files-with-jsf-20-and-servlet.html
The problem is that when the form is set to multipart/form-data, a new conversation is started on post, which breaks our app. Of course we could store information in SessionScoped beans instead, but we would like stick to ConversationScope if possible. We didn't try it with omnifaces ViewScoped.
Did anyone faced this issue? thx
We tried BalusC's answer and it works fine. Attaching the 'cid' to the rendered form's action works. In fact, if there is an input field named 'cid', JSF can return to the conversation. This latter solution is simpler.
<input type="hidden" name="cid" value="#{conversation.id}" />
Thanks!
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 am using PrimeFaces and JSF - I need to be able to set a component on the page as mandatory in response to an AJAX event. Is the best way to accomplish this using the following code or is there also a way to accomplish it using JQuery ?
Thanks
UIInput componentToChange = (UIInput) facesContext.getViewRoot().findComponent("ComponentId");
componentToChange.setRequired(true);
Thanks
Just set the component's required attribute with the desired EL expression.
E.g.
<h:inputText ... required="#{bean.required}" />
There are even EL ways without needing an additional bean property, but it's impossible to propose one based on the sparse information provided so far.
Use findComponent() with care. Think twice if it really can't be done just in the view (XHTML) side.
Simple question:
Is there any way of rendering a html <button>-element using JSF or any other framework (RichFaces, Tomahawk etc.)? Or would I have resort to writing a custom component for this?
No, there isn't. Since a <button> is usually only used in GET requests, you can also just put it plain vanilla in the JSF template. You don't need to bind any action to a JSF managed bean anyway.
In JSF 2.0, there's by the way the <h:button> which renders a GET button and offers the option to include view parameters and/or to perform implicit navigation. Both features aren't available in JSF 1.2, so there's not really a point of having similar component in JSF 1.2 anyway.
On the other hand, if you actually intend to use a <button> to invoke a POST managed bean action method, then you should really be using a <h:commandButton> instead. If you're having a specific problem with it for which you thought that using <button> was the solution, then you'd need to reframe your question to elaborate in more detail about that specific problem so that we can answer how to achieve the same with <h:commandButton>.
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'm new to this JSF world, please bear with me if I'm asking some silly thing
i'm using UI tags for my application and I have a scenario that I need to generate a calendar control to make the user to select the date I followed the ui tags documentation and wrote the code like this:
<table width="100%">
<tr>
<td>
<ui:calendar binding="#{booking.calDate}"
id="calDate"
dateFormatPattern="dd/MM/yyyy"
label="Date ::"/>
</td>
</tr>
</table>
and my backing bean contains
private Calendar calDate = new Calendar();
with appropriate getters and setters
when I tried to load the page I'm getting the calendar component disorted.
I'm getting cross marks and nonsense things with some javascript errors.
please help me in resolving this issue
Thanks in anticipation
I got the solution by myself - the issue is with the javascript code. it reads the javascript from themes.jar, which i placed in web-inf/lib folder still it was unable to access that. so I extracted the same and placed it in web-inf and it's working fine
The component is coming from which JSF library?
In others words, what do you have at the beginning of your XHTML file?
The only library I know is coming from Facelets, and it does not provide any component!
In addition, if calDate is a **java.util.**Calendar class, then you cannot bind this class to a JSF component!
Maybe you can have a look to Tomahawk, or Richfaces, that provide good calendar component...
Are you using MyFaces? If so, you may need to configure the MyFaces filter. This loads up the JavaScript and images etc. and may be the cause of your JavaScript and image loading problems.
Obviously if you're not using MyFaces this wont be an issue!