Forums Register Login

Update action does not update bean attribute

+Pie Number of slices to send: Send
I have a strange behaviour when trying to update a bean. Here is the edit page:


Here is the bean class:


postToUpdatet is always NULL. Why the title property is not binded ? What is wrong here ?
Thank you
+Pie Number of slices to send: Send
The object "post" is never initialized and just has a null reference.

initialize post in the bean's constructor or in an @PostConstruct method and you should be good to go.
+Pie Number of slices to send: Send
I always believed that setPost(Post post) method should be called automatically and set all the bean attributes from the view. Isn't it ? If not, what the aim to have a setter defined in the bean ?
+Pie Number of slices to send: Send
Tim will probably correct me in the morning if I am wrong, but JSF should use the getter to get a copy of your objects that are used by the JSF components. Then it will use the setter on submit or partial submit to put those to set your object as the copy it got from the getter.

Since the object is never initialized it is given a null reference by default. It will pass that null to JSF. I am also surprised it let's you print, as I got attribute is unreachable and stopped when i mimicked your code.
+Pie Number of slices to send: Send
Well, first I've got to be all pedantic and note that JSF backing beans are not Controllers and that in fact, in JSF, you never write Controllers, since they're pre-written as part of JSF. You only code Models (backing beans) and View Templates (xhtml). At least unless you're meddling around with custom tags at the binary level (which is a whole different can of maggots).

I couldn't actually understand the error that was stated, but Controller or not, Request Scope is almost 100% worthless in JSF. The Request Scope objects are destroyed as soon as the response is passed back to the client and a new, uninitialized object will be created when the next request is submitted. Repeated over and over.

It's always worth remembering that JSF has an all-or-nothing approach to how its Controllers work. The JSF Controllers will only post updates to the backing bean if ALL of the input control values on the submitted form are valid. Otherwise they all remain unchanged.

Also, I have doubts that @Autowired works in JSF backing beans, since they're not constructed by Spring, but by JSF. With the ongoing convergence of bean management systems, it's possible that this will work, but the closest that my (antiquated) environment will allow me is to use the @ManagedProperty annotation and an EL reference to the Spring-constructed persistence resource.

Finally, the ViewId should be a JSF relative URL, and not a file reference. Thus, this is how I would code it:


I don't care for the "/faces" syntax, so while the example code may be OK, it's not something I can be certain of.
+Pie Number of slices to send: Send
Thank you, guys, for your responses.
First, I forgot to precise that I used PrettyFaces to have 'pretty' URLs and to create a very basic RESTful CRUD web app like I did with Ruby on Rails.
Thats's why I named my bean as PostsController hoping that it would do all the stuff with my Post model (à la RoR).
So, now I'am a little bit lost how to proceed, because as far as I understood, there is no way to bind a Post model from the bean to a specified view, right or not ?
Unfortunately, I can't find any working examples that would use JSF, Spring in a RESTful way. However, I think it to be pretty basic task that would be required by every one who would like to start with JSF.

As for 'Autowired', it works for me, you can get a full copy of the project from my Github repo at: https://github.com/Javix/blog-jsf.

One more weird think I can't find a solution, - how JSF(or at least PrettyFaces) manages PUT/PATCH/DELETE requests ?

Spring MVC, for example, lets you precise that directly in the controller's action with the annotation (@RequestMapping(value = "/{id}/edit", method = RequestMethod.GET)).

Could you give me some guidelines to follow to achieve that ?
Thank you.
+Pie Number of slices to send: Send
JSF is different. In fact, the original concept for JSF was that the web was only 1 possible underpinning for JSF, as was HTML. So JSF has no direct connection to HTTP requests (GET/PUT/POST, etc.) and HTML was only 1 possible rendering option (although JSF2's Facelets backs away from that a bit). JSF was intended, in fact, to be a fairly pure implementation of the Model/View/Controller paradigm irrespective of transport mechanism or low-level form encoding.

In practice, JSF is about displaying a form, accepting and validating input, redisplaying the form with error messages and repeating until all form data is valid and a JSF action (business logic) method can be fired. Only the HTTP POST method is used, and the actual submitted data forms contain JSF context information - they're not simple data like you get in raw HTML. You wouldn't want to attempt a client-constructed POST on your own.

So if you want RESTful operation, JSF isn't what you should be using. Although Apache CXF and JSF play nicely together in the same webapp, as I can personally attest.

PrettyFaces was designed to provide bookmarkable GET URL support, not for RESTful action. It does that quite well, however. Basically, it replaces the normal POST request in order to jump into a form edit session without requiring awkward fumbling around in the FacesContext to obtain the original user-supplied data.
+Pie Number of slices to send: Send
Thank you for your time, Tim.
Yes, that's what I was afraid of, - REST is not JSF's way to go :(.
'I'll continue to 'dig' deeper:
- passing parameters from a view action (had to use JBoss EL library)
- redirect after creation does not work properly.

Thanks again.
+Pie Number of slices to send: Send
JSF works really well for what it was designed for, but there are other tools better suited for other tasks. Fortunately, JSF isn't one of those greedy frameworks where EVERYTHING has to be JSF. If you need an Excel spreadsheet or PDF generated, a traditional servlet can be used for that part of the app. Likewise, CXF is really good for ReST and SOAP. I generate XML files for AJAX clients using JSP templates. But when I want validated form data, JSF is my "go to" subsystem.

It all ties together quite nicely.
+Pie Number of slices to send: Send
Yep, finally I've already managed to make work the create/update actions.
I have just à little bit frustrated by the level of complexity to pass just to get work such simple things like CRUD actions.

Kind regards
+Pie Number of slices to send: Send
Yep. The bad news is that JSF doesn't itself provide any sort of CRUD functionality.

The good news is that that means it doesn't get in the way of whatever CRUD system you want to use.

You might want to check out SEAM, though. It may be closer to what you're hoping for.
PI day is 3.14 (march 14th) and is also einstein's birthday. And this is merely a tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 3857 times.
Similar Threads
Multipart request problem
JSF form POSTed data not stored in the bean (sometimes)
JSF : commandButton in dynamically loaded <ui:include> page doesn't work
JSF action doesn't call bean method
JEE example with EJB, JSF is not working
Why should you try IntelliJ IDEA ?
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 12:31:54.