aspose file tools*
The moose likes JSF and the fly likes Living without a controller? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "Living without a controller?" Watch "Living without a controller?" New topic
Author

Living without a controller?

Michael Gantz
Greenhorn

Joined: Jul 25, 2006
Posts: 2
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
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16014
    
  20

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.


Customer surveys are for companies who didn't pay proper attention to begin with.
Michael Gantz
Greenhorn

Joined: Jul 25, 2006
Posts: 2
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

Joined: Jun 25, 2001
Posts: 16014
    
  20

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Living without a controller?