• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Living without a controller?

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I�m slowly, but surely, digging into all the nooks and crannies of the world of JSF. But, coming from the Struts way of life I have some questions about properly designing navigation in JSF.

First, these questions are prompted by the design idea that directly typing a URL into the browser of a web application should always result in something useful to the user. I.e. A user should never see an �Internal Error� or anything similar. Also, the user should never be presented with a page that doesn�t match the internal state of the application.

I�ll start with the struts example and move forward.

Let�s assume we have two JSP pages in a struts application:

/WEB-INF/pages/widgetSearch.jsp
/WEB-INF/pages/widgetView.jsp

First, the user typing in any URL cannot directly access these JSP pages. So I don�t have to worry about pages themselves being executed with a bad application state.

The general flow of execution for these pages would be as follows:

--> SearchAction --> widgetSearch.jsp

If the user wishes to continue searching the SearchAction gets called again and the process loops.

If from the widgetSearch.jsp page the user selects a view link, the following is executed:

--> ViewAction --> widgetView.jsp

ViewAction is responsible to validating that the selected widget is available and can be viewed. If the user forged up the URL and selected a widget ID that is not valid then ViewAction will simply return to widgetSearch.jsp and no harm is done. In this last case the search page would include a message indicating the widget could not be found.

This execution path guarantees the user can�t get to widgetView.jsp without a valid widget selected. The widget may get deleted while the user is looking at it, but this will be handled by whatever action the user selects next.

It�s when I move this to JSF that things are not as obvious. In JSF I would still have two pages, plus a backing bean:

/pages/jsfWidgetSearch.jsp
/pages/jsfWidgetView.jsp

com.widgetco.WidgetBean

The searching part is straight forward, when the user enters http://mysite/pages/jsfWidgetSearch.faces the search bean gets created, the form displays and all is well. When a user clicks on a view link an action is called, for example �WidgetBean.viewWidget()�, the same validity checks are made, the widget is loaded, and things progress to jsfWidgetView.jsp and all is well.

But, here is where things get sticky, if the user types in �http://mysite/pages/jsfWidgetView.faces� there is no controller that can easily catch this and determine that a widget is not presently selected. I�m wondering how most folks are handling this? I�ve tried a couple of different solutions but none of them seem very clean. My not so clean solutions include the following:

1) Hacking in some phase listeners to catch these situations. This isn�t very clean as it scatters navigation logic across many different places.

2) Wrapping everything in jsfWidgetView.jsp with conditional code utilizing the rendered attribute. This sort of works, but the user still ends up on the page. As opposed to being back to the search page with a message saying �Widget was not found.�

I would more than welcome suggestions on how to properly handle this issue. Maybe, being influenced by Struts, I�m just attacking the problem incorrectly. From an architectural perspective I�m concerned because most of the JSF books and tutorials suffer from this particular problem.

Thanks much,
Michael
 
Saloon Keeper
Posts: 27764
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Don't get more clever than you need to. I don't know if what I'm doing is QUITE the same thing, but it may at least help.

I commonly have a pair of pages that present a table listing and a detail edit/view. In JSF, a single backing bean manages both of those.

Not infrequently, I want to narrow the table view down via a search. It sounded like you narrow down to a single item, but bear with me.

The search itself is done via a search backing bean. That is, the search parameters are stored in their own bean. When you click on "Search", the bean gets filled in from the JSP and JSF then injects that bean into the table/detail backing bean. This is done using the Managed Bean capabilities of JSF (set up fin faces-config.xml).

Now if you go directly to the "viewtable.jsf" page, that search won't have been injected. It's null. So when I prepare the table display, the first thing I do is see if there is a search bean. If not, I display everything, otherwise I use the search bean to refine the display. To clear a search, all I have to do is null out the search bean.

warning: make sure that the lifetime (scope) of the search bean is at least as long as the backing bean or you'll regret it!

On the detail view/edit page, it's trickier. Since the item in question is part of a wrapped collection, I ask the wrapper for the current item. If I don't get one, I can reroute to a "No object selected" display page.
 
Michael Gantz
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Tim Holloway:
Don't get more clever than you need to. I don't know if what I'm doing is QUITE the same thing, but it may at least help.

I commonly have a pair of pages that present a table listing and a detail edit/view. In JSF, a single backing bean manages both of those.

...

On the detail view/edit page, it's trickier. Since the item in question is part of a wrapped collection, I ask the wrapper for the current item. If I don't get one, I can reroute to a "No object selected" display page.



Yes, this is almost exactly what I'm currently doing. Including the injection of dependent beans to make everything play nice together.

One question though, how are you conditionally redirecting to a different page using JSF? I can't seem to find the correct combination of tags/components that play nice to do this. It gets frustrating when JSTL and JSF clash.

Thanks,
Michael.
 
Tim Holloway
Saloon Keeper
Posts: 27764
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't know if I'm doing quite what you want to do, but I've found that the easiest way to handle external or variable URLs is to make them properties in the backing bean.
 
BWA HA HA HA HA HA HA! Tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic