aspose file tools*
The moose likes JSF and the fly likes Browser navigation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Browser navigation" Watch "Browser navigation" New topic
Author

Browser navigation

Kevin Galligan
Ranch Hand

Joined: Aug 10, 2005
Posts: 70
Today a "client" of ours, which is technically our parent company, absoluetly insisted that the browser back button and refresh button function as expected in our application. This app is not JSF
Kevin Galligan
Ranch Hand

Joined: Aug 10, 2005
Posts: 70
Hmm, I think we need a confirm on that form submit. Anyway...

This app is not JSF, but does not play well with refresh because its multi-frame, and has a dubious relationship with the back button. I was not at this meeting, and I told the person to get me next time they demanded that because, basically, they can demand whatever they want. We're not doing anything about it.

However, any thoughts on this in relation to JSF? I've been on the fence about introducing JSF at my "day job". One of the major reasons has to do with the premeditated abandonment of browser navigation. I've been told that the back button issue will be fixed in 1.2, but I'm 99% sure "fixed" means better error reporting after somebody has used the back button rather than making the app function at expected in a browser.

I think telling people that our current app, with multiple frames, legacy code, etc., can't use the back or reload buttons is ok. Telling them that a brand new, simple application can't use browser navigation might not be so "ok". Anybody run into trouble like this? Am I wrong about the browser navigation?
Bagwan Mehrat
Ranch Hand

Joined: Jan 26, 2002
Posts: 119
I'm just starting to use JSF, so I don't think that I can be technically helpful, but I share your concerns, if it's the case that JSF has that effect. The web design and usability book, "Don't Make Me Think!" cites a study that said that about 40% of web site user navigation is pressing the browser's Back button.

But I thought that there was a setting in the faces-config file that makes the browser re-retrieve each page for navigation, so that the URL does reflect what JSP you're looking at. Is there some other aspects of JSF that makes Back and Refresh hard to use?

So far, my impression of JSF is that it's over-engineered due to the dubious requirement of having to support non-JSP views.
Kevin Galligan
Ranch Hand

Joined: Aug 10, 2005
Posts: 70

I'm just starting to use JSF, so I don't think that I can be technically helpful, but I share your concerns, if it's the case that JSF has that effect. The web design and usability book, "Don't Make Me Think!" cites a study that said that about 40% of web site user navigation is pressing the browser's Back button.


Exactly. Now, to be honest, I got my impression from working with it a little and forum conversations. However, I really don't see how you could use the back button. A lot of stuff is stored in the session as you go along.

Now, most web sites are content based. Web applications are somewhat different, and there is often some leniency with regards to navigation. However, I'm not sure I'm ready to ditch "Back" altogether. In particular, navigating entities in a system (a database for example).


But I thought that there was a setting in the faces-config file that makes the browser re-retrieve each page for navigation, so that the URL does reflect what JSP you're looking at. Is there some other aspects of JSF that makes Back and Refresh hard to use?


You can set <redirect/> in the navigation case. In my struts stuff I wound up doing that any place I could.

I think the issue with the back button stems from the way the user interface components are created, rendered, then values are pulled in from the request. You have to postback to an existing UI component structure. You can't just "drop into a page" with values and expect the input components to pick them up.

My understanding of the sequence is still a little hazy, though, so you might have more flexibility than I currently believe.


So far, my impression of JSF is that it's over-engineered due to the dubious requirement of having to support non-JSP views.


(Psst, buddy. This is a pro-JSF crowd. Ix-nay the over-gineered-enay)

I tend to agree with the non-JSP thing. In my experience you're better off doing a good job with the business code and data access and leaving the front end to its own devices. If you need a second screen doing a similar thing, build it with the same base code.

Reuse and "genericity" is a tricky balance.

I think the display agnostic thing in JSF is reaching a bit too far with the reuse concept. What format are you going to use JSF for besides HTML? As I remember when jsp was new, there was a big deal about jsp's with scriptlets in languages other than java. I've never even heard of anybody doing that, much less seen it. JSF might wind up with some practical front end alternatives that are actually being used, but I'd be surprised.

However, and I'm aware that this is very "emporer's new clothes" of me, but I've made the assumption that there's something really valuable in there for so many heavyweights to be into it. You know? And there are certainly aspects which I think are great.

Navigating and linking a list of items, however, is not one of them. And I think I've borded hundreds to tears with my arguments about it.
[ September 01, 2005: Message edited by: Gregg Bolinger ]
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15292
    
    6

(Psst, buddy. This is a pro-JSF crowd. Ix-nay the over-gineered-enay)

There is a different between being pro-JSF and knowing enough to help people out every now and again.

There are 2 arguments that keep coming up over the back issue. Developers say just stop using the back button. Rely on the apps navigation. Users say, why can't I use the back button? I can on everything else. Why doesn't it work with your app. Sun needs this fixed and I hope it is in the next release. However, I am not 100% on all the details of why it currently doesn't work. I've never run into a problem using the back button personally.

In regards to the display agnostic stuff. Yea, maybe Sun over thought it a bit and wants JSF to do more than what really needs to be done with it. But I don't think that is the root of the problems. All the renderer is doing is converting data into HTML or whatever view you want. By the time it hits the renderer, everything else is basically done. So the problems are there already.

BTW - There are other frameworks that conceptually are similar to JSF. Meaning they are component based frameworks. Tapestry is the biggy. Wicket is a new one but has kind of a cult following. If JSF is causing you problems, you might consider looking into one of those before getting too far. I know that Tapestry specifically addresses the browser back button issue and their framework does not have a problem with it. I haven't looked into Wicket enough to know for sure.


GenRocket - Experts at Building Test Data
Kevin Galligan
Ranch Hand

Joined: Aug 10, 2005
Posts: 70
I have strange feelings about JSF. I think there are issues like those discussed here, and I also feel like you can do a lot with it.

Speaking of Tapestry...

http://www.theserverside.com/articles/article.tss?l=JSFTapestry

That'll take a while to go through. Its long.

Wicket. Whoa. That looks hairy. The fact that it ties directly to html is kind of cool (as opposed to the idea that I'll build multiple client types off one jsf screen, which I don't believe). However, the way it works is totally foreign to what I'm (and, more imporantly, the people I manage) are used to.

Crap. All I wanted was a good framework.

Anyway, I'm thinking JSF is the way to go, at least for now. The industry support is more significant.

I'm also thinking I'll wind up with my hybrid approach that I've been on about (all over the place. Gregg, after you mentioned the myfaces mailing list I wound up spaming that with my database linking ideas).

I also just bought exadel, so now I'm in.

I think I'm going to start with internal applications and see how that works out. I have more freedom to dictate how they work. If there's a bit of navigational nastiness I can get away with it. By the time we actually build, release, and "get used" to JSF implemented apps, 1.2 should be out and we'll have a look at the back button fixes.

I think at a higher level that any time you rely on session storage you're going to run into back button trouble. That's nothing new. The page itself needs to hold the context that you're in. I think storing the view in the page might take care of some of this, but I have to try that. I'm not sure serializing that on every request is great for performance, but then again it might not be that bad. Have to try it.

Now that I've typed that, storing the view on the client might wipe out some of my issues. If you go back and submit an old page, the server will still reconstruct the view as if you had just submitted the page (as opposed to pulling it from the session). Interesting...

Right now I've had trouble with the list of links/database navigation pages. Lets say you click a link, then click back and click a different link. Usual web page expectation would say that you should go to the next page, but JSF would just show the links again. I think this is because the view state of the list of links no longer existed in the session, so it just redisplayed the page. Were the state held on the clint, this would be different. Ahh, something to try tonight.

Ramble on...
Kevin Galligan
Ranch Hand

Joined: Aug 10, 2005
Posts: 70
PS. The 'psst buddy' thing was a joke. Obviously.
Kevin Galligan
Ranch Hand

Joined: Aug 10, 2005
Posts: 70
Yes, it seems client state does play "nicer" with the navigation (from the myfaces mailing list)...


Client-side state management also seems to be necessary if one's
application uses JSF pop-up windows. With client-side state management,
pop-ups and back buttons appear to work fairly well.

- Brendan

-----Original Message-----
From: Mike Kienenberger [mailto:mkienenb@gmail.com]
Sent: Thursday, September 01, 2005 11:02 AM
To: MyFaces Discussion
Subject: Re: using browser back button with MyFaces examples creates
problems..


The default server-side state management doesn't handle going back.
The upside is you can write your own StateManager to handle it

Client-side state management should work with care so long as you're
not depending on any server-side state management (session-scoped
backing beans and the like).

On 8/29/05, Rick Reumann <rick.reumann@gmail.com> wrote:

>> Example...
>>
>> Load up exmaples
>> http://localhost:8080/myfaces-examples/home.jsf , click on
>> examples --> components --> Master Detail example.
>>
>> click "Austria"
>>
>> use browser back button
>>
>> Select another menu option like "Selectboxes"
>>
>> use browser back button
>>
>> Click on Master Detail example ---> result ugly error
>>
>> --
>> Rick

Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15292
    
    6

Cool deal Kevin. Thanks for updating us.
Kevin Galligan
Ranch Hand

Joined: Aug 10, 2005
Posts: 70
I modified the app I'm working on to use client and it does work. You still need to be careful with what you're doing, but the back button does appear to be ok.

I'm not sure about performance. I thought it was really bad at first, but that turned out to be my code. I mean, I think it should be ok. Its doing some funky stuff, but it shouldn't be that bad.

With 1.2 it should be encrypting the data, so that should help with some security concerns.
Dave Wood
bronco
Ranch Hand

Joined: Aug 02, 2004
Posts: 161
I haven't posted on this board in ages, but just wanted to chime in on this...I too found that using client-side state fixed some back-button problems I was having.

The downside is that I have one screen that's over 200k (it's a bit of a mess...has a bunch of different forms on it and it seems the same state data gets serialized into each form on the page).

If this were an internet-application (i.e. modem speeds), this would never fly. I'm guessing client-side state in general is a bad idea if you're going over a slow pipe.


Co-Author of <a href="http://www.oreilly.com/catalog/jswing2" target="_blank" rel="nofollow">Java Swing</a><br />Co-Creator of <a href="http://www.sun.com/training/catalog/courses/CX-310-055.xml" target="_blank" rel="nofollow">SCJP 5.0</a> and <a href="http://www.sun.com/training/certification/java/associate_beta.xml" target="_blank" rel="nofollow">SCJA</a> exams
Kevin Galligan
Ranch Hand

Joined: Aug 10, 2005
Posts: 70
I think the client-side state does add significant heft to the page and certainly needs to be considered when building an app. I think it depends on what you're planning to build.

No offense to JSF, but if I were building a web app that was going out to a lot of clients and was supposed to be a high perforance type of thing, JSF would not be the way to go. I'd pick something that was both more mature and was closer to the actual protocol. Struts would be up there in my list of options, but depending on what the app was doing, even that would be debatable.

I think the strength of JSF is its RAD ability, so it'll shine in things like intranet apps and small audience situations. Where performance can be sacrificed for quicker development (and hopefully reduced bug load).

Now, as to the small pipe situation. I took some "readings" on the size of the serialized tree, and it looks to be about 2k for my not-so-huge form. Bigger forms will probably have bigger size. However, if you look at the code generated by JSF just for the form, its not exactly lightweight to begin with. If you've got a slow connection, I think JSF is going to be sluggish regardless. Adding the client state doesn't help, but its going to be crappy anyway.

Version 1.2 is supposed to do something with the back button, but I don't think it'll "fix" it as some have contended. I think its just going to do a better job detecting that the saved UI state came from a different screen.

Of course, I could be wrong.

In summary again, I wouldn't build a critical or high volume app with JSF. However, removing those types from the list, that leaves about 99% of the applications built as possible JSF targets*. That's a big market.

*Yes, that stat is out of my 'a'.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Browser navigation
 
Similar Threads
Actionevent
action form values not retaining on back button
Client-side printing in JasperReports
How to disable back button of browser after session invalidation?
how to diable browser back button