Hi, I'm just going to give my opinion here because I've been thinking about this lately too. First, I agree that being able to bookmark a page is something important for a web site. But here's the thing (at least for me, others may disagree): it does not make that much sense for a web application. I do now make a distinction between the two having had to develop part of a web application.
In the context of a web application, I have yet to see the use of a "bookmarking" system, and because of that the use of URLs is not that relevant either IMHO. For instance, if you want a user to be able to quickly go back to a certain page (like an item's details etc...) then you have to provide your own way of saving the state of what the user is seeing that they can go back there when they start a new session the next day etc... Just like in any other type of application (by that I mean a typical Win32 application for example. We've done it when it made sense and users needed it but in many cases it never bothered them that much). >From a user's point of view (I mean a guy at a terminal in a warehouse >etc...), customization is not always an option anyway because of admin >restrictions (to create bookmarks or even see the URL), lack of knowledge, and >simply because that user may be using 5 different terminals depending on the >day. That's why a good implementation of such "state saving" is impossible to >accomplish generically IMHO and a custom one will do *much* more to fit users' >needs. Bookmarking and URL make a lot of sense for web browsing, but not that much for using a web application, at least not in the way client browsers implement them. So for me, as much as it could be convenient, trying to get to point B without going through point A first is like trying to foul the system in a way and would break any flow you have spent time designing to validate proper user access etc for example... Otherwise you end up having to validate such access each time instead of knowing that prior steps have been completed so you can expect a certain state at this point. Anyways it's late and that's only my 2 cents but this is an interesting subject. Don't get me wrong, I love being able to go to a page directly and I'd love to be able to do it with our web application, but from a design/development/testing point of view, it simply would not work in most cases I think. Greg ________________________________________ From: Yee CN [mailto:[EMAIL PROTECTED] Sent: Thursday, October 27, 2005 10:42 PM To: 'MyFaces Discussion' Subject: FW: How to pass parameters between pages.. Graig, I think that JSF is perhaps forgetting too much about URL. Bookmarking from client browser is almost impossible at present. Firstly with JSF the URL shown in the client browser usually trail one step behind the actual page being shown, and secondly we no longer have a URL of the form http://..../viewProduct.jsf?id=234. I actually think URL parameter is very meaningful for both the web client and the server. It is a way to request a service from the server in a way that both the web client and the server can understand. I like to hear what you have to say on this. Regards, Yee ________________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Friday, 28 October 2005 9:42 AM To: MyFaces Discussion Cc: [EMAIL PROTECTED] Subject: Re: How to pass parameters between pages.. On 10/27/05, Lucio Piccoli <[EMAIL PROTECTED]> wrote: if u are going from page A - page B using a commandlink then u the <f:param> <h:commandLink immediate="true" action="#{BForm.detail}"> <f:param name="username" value="#{ summary.id}"/> <h:outputText value="#{summary.id}"/> </h:commandLink> While this solution is technically feasible, it has some problems, too: * It restricts you to using hyperlinks instead of submit buttons. * It requires the view tier to be aware of implementation details that properly belong in the model and controller tiers, so it makes your application more fragile when you change things later. I'm somewhat of a radical on this topic, but I believe that developers of web *applications* should forget that URLs even exist, and focus on passing information on the server side (via request or session scoped attributes, as appropriate). Then, if you really really really find you need to get the view tier involved, use a hidden variable instead of explicit query string parameters. That way you can still leverage the standard form processing capabilities JSF provides. Craig McClanahan
