• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

GET request generated by <h:link> in JSF is not updating Bean properties

 
Jay Josh
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all

I am just checking out how GET request is generated in JSF. For that I am using <h:link> tag but with that bean properties are not getting updated. But if I use <h:commandLink> its works fine.

Here is the code.

login.xhtml


welcome.xhtml


UserBean.java


web.xml


When I clicked on link then address field changes to

http://localhost:8080/GETReqPjt/faces/welcome.xhtml;jsessionid=2f86aaea178fc9ed1d964f327fd0?name=JayJosh

I am using netbeans IDE and it supports both JSF managed beans and CDI beans. Its working with <h:commandLink> i.e. POST request.

Thanks
Jay
 
Jay Josh
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Reminding again, when I replace <h:link> with <h:commandLink> as shown below

 
Jay Josh
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
cont from post 2...

Then its working fine.

Thanks
 
Tim Holloway
Saloon Keeper
Posts: 18359
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's because bean properties are only updated when a command is executed. The difference between commandLink and link are that commandLink submits a command request (via HTTP FORM SUBMIT), but link simply generates an <a href=...> hyperlink, although it's more civilized than the "a" tag in that the output href path is enhanced to include the webapp's context URL path.

The construct:


Isn't really proper. The path "/welcome.xhtml" is a resource path, and although resource paths look a lot like URL paths, they are not URL paths. A better form is simply:


Which allows the flexibility of setting JSF navigation rules instead of raw paths. Note that this syntax does not work for the h:link tag, because the h:link tag isn't a command, it's a true URL and doesn't go through JSF's navigation system, as you've already discovered.

Also, parameters on commandLinks aren't really recommended either. The parameters should be coming in as form control values via the backing bean posting process. If you need a value that's not in a user input control, simply stash it in an inputHidden control.
 
Jay Josh
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think my question is still unanswered. My second reply got posted without preview hence there could be some mistakes about <h:commandLink>. I know how to use <h:commandLink> property.

But my question was about <h:link> tag. I know bean properties wont get updated with this. This is the reason why I am using following code in login.xhtml file.




which appends name=JayJosh to the address field. And then



in top of login.xhtml file which should take the 'name' parameter's value and should update UserBean class. But its not happening.

My question is about that. How should I do it ? i.e. by using <h:link> how can I update my bean properties.

Thanks
Jay

 
Jay Josh
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think I got the answer. The code



should be present in welcome.xhtml and not in login.xhtml.

Thanks for your reply Tim. For me its resolved now.

Thanks
Jay
 
Tim Holloway
Saloon Keeper
Posts: 18359
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK. I have to apologize for getting the h:link and h:outputLink tags confused.

The h:outputLink tag is what I was actually describing, and that renders general HTML a/href link tags, relative to the application URL context.

The h:link tag works with JSF navigation targets, but is otherwise similar. So the proper form for your link tag would be this:


Or, if you prefer a common convention:


As you discovered, viewParam defines the connection between a URL parameter name and a JSF-injected backing bean property on the destination View, not on the source. This facilitates bookmarkable JSF URLs, which were not available (except via workarounds) in JSF version 1.

In the case of a JSF-to-JSF jump where you want to pass a bean property, generally, you'd be better off using a commandLink than a link element. The commandLink has a more complete passageway through the JSF lifecycle, at the expense of not being bookmarkable.

Then again, a bookmarkable link from a login page to any other page smells like a security exploit waiting to happen. Of course not using the J2EE standard login framework already implied that. Something like 95% of all Do-it-Yourself login/security systems I've seen over the years were about as secure as a wet Kleenex, and that includes the ones in banking and military webapps. Unless you have someone on staff whose full-time job is security, you're playing with fire. The Internet would be a much safer place if it had fewer security frameworks designed either as a "and get this done while you're at it" loaded on to the application developer or from some corporate-designated genius. The security framework that J2EE provides can handle most common webapps and can be extended safely to make it more fine-grained. It was designed, debugged, and tested by full-time security experts and has proven secure for 15 years give or take.
 
Jay Josh
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have just started learning JSF so just a beginner. Surely will keep your advice in mind.

Thanks for your time.

Jayant
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic