Recently I started a project using JSF 2.0 with Richfaces 4 with JPA 2.0.
My problem is very simple:
Just created a form which binds with entity through mbean and calling my service layer to update in DB. Once I submit my form data, am rendering back to the same page, the form is not clearing at all. Even I have create a new instance of my bean and refreshed the form.
JSF 1.2 it works fine. some time's we use to clear the form by clearing the component tree for that, no hope with JSF 2.0, any early help on this is appreciated.
Below code works for JSF 1.2 but not works for JSF 2.0.
Mucking around with the component tree is not good practice, whether it's JSF1 or JSF2. About the only time you should do that is if you are actively adding/removing major elements from the View. And that's a practice best kept to a minumum, since excessively changing the appearance of the View can confuse users.
The proper way to update the display is to simply clear the values on the model. When the view is next requested, the updated values with automatically be displayed.
#1 rule for JSF: The more JSF-specific code you have, the more likely you're doing it wrong.
An IDE is no substitute for an Intelligent Developer.
Rudra Narayan Garnaik
Joined: May 05, 2006
Thank Tim for your quick response.
I am not working on a complex form. Just a simple form am submitting. While response coming back am just clearing the model(By creating a new Instance of my Model). that is not working at all. What I am suspecting :
1- this might the scope issue as JSF 2 has many new scopes introduced.
2- Seems it stores in session- but am not using any session scope at all.
2- I was getting the injection error of my model(am using the entity itself as model).
3- I have created a custom view scope and used so injection started working. as JSF view Scoped not works properly.
4- I tried writing separate model bean still same issue.(using the same custom view scope)
When I want to clear a model, I add a POJO method named init() to the model bean class and have the init method reset the properties by doing simple assignment statements (or calling the property-set methods). Generally, my constructor also invokes init(), thus ensuring that freshly-minted beans and cleared beans are both set to the same predictable set of values.
There is absolutely no need to invoke any class or method beginning with "javax.faces" (including the FacesContext) nor is there a need to use the javax.faces code to access the JSF component tree. It's all done in vanilla Java and the resulting bean can be compiled and tested stand-alone without the presence of an appserver or JSF.
Aside from the sheer unnecessary complexity involved, accessing JSF internals is not a good idea for reasons of maintainability. Anyone can read and maintain POJO code, but specialized code requires specialized knowledge. Yes, it's job security, but it also means you get stuck with it long after it isn't any fun anymore.
Another reason not to use JSF-specific coding for simple tasks like this is that JSF's internals are still young and mutable. The EL subsystem changed radically between JSF 1 and JSF2, as did some of the stuff that saves and restores component trees. Generic code was unaffected, but specialized code broke.
If you absolutely, positively MUST destroy a model instead of simply resetting its property values, get the model from its context dictionary (HttpSession, usually) and do a removeAttribute on the dictionary. There's no need whatsoever to act directly on the component tree.
Like I said. The more JSF-specific your code is, the more likely it's not done correctly. JSF is designed to do things for you, not make you do things for it.
Rudra Narayan Garnaik
Joined: May 05, 2006
Hello Mr. Tim Holloway,
No value for your post responded as you have written in this post. Be honest If you not worked with latest JSF 2.0 With Spring 3 and Richfaces 4. You are really disappointing me by your post response and wasted my time to read. Sorry If am hurting you. I was expecting help not this kind of comments having no value at end. This is a real-time issue I have posted and people posting this issue in many places.
- JSF is meant for customization... not what they have give and we will use.
- There are issues in the integration process of JSF 2 and Spring 3 injections what am experience.
- We have to write the custom scope and avoid that as I have written above.
Use the following annotations:
just removed the @Named annotations of JSF. works fine..
You're not going to hurt my feelings. I've worked with JSF since 2006 on pretty much a daily basis, continually refining my techniques. I've managed to fool my peers into thinking I'm competent at it, so they keep my bloated ego pretty well stroked.
I have maintained for years that the beauty of JSF is that it allows you to do so much without actually "programming JSF". JSF was designed by Sun to take as much advantage of POJOs as possible, having learned from previous efforts such as Struts and EJBs how expensive and unstable framework-specific components can be.
Which is why I often state that the #1 mistake that JSF n00bs make is trying to code complex JSF-specific logic to do things that JSF can do much more simply without the JSF-specific code and that therefore the First Law of JSF is:
With the exception of the JSF model classes, the more javax.faces objects you're using, the more likely you're doing it wrong.