• Post Reply Bookmark Topic Watch Topic
  • New Topic

Update action does not update bean attribute  RSS feed

 
Serguei Cambour
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Jarrod Rackley
Ranch Hand
Posts: 30
Chrome Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Serguei Cambour
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ?
 
Jarrod Rackley
Ranch Hand
Posts: 30
Chrome Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Serguei Cambour
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Serguei Cambour
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Serguei Cambour
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!