I just had this kind of conversations with one of my coworker and my boss last week. I think bookmarks are a bad idea in web applications even when not built with Ajax. After all, an application is stateful and need a *state* to run. Bookmarks in my mind are made for informational sites wich are staless and not applications. Do you expect to be able to return in a precise windows in a desktop application like Open Office for exemple? So we took the decision to use the same url everywhere in our web applications (like Gmail does). In the Jsf world it quite easy to do, thank to subviews. Of course, I am expecting some exceptions like when you want to access quickly some *stateless* datas in a read-only page (like in a forum application) . In those cases ,we will try to use some url parameters instead of changing the url path.
For the moment, it solves a lot of problem. The user is always brought back to the beginning of the application wich makes more sense in my opinion. Why would you go back in the middle of a previous transaction? Plus, this way you can have your menu component not saved in every different views (or any other components fitting more in an application-wide scope then in a view scope). Finally, you don't have to think about all the problems happening when the user type directly the Url. For instance, you don't have to initialize the selected item correctly in the navigation menu or to try to rebuild your breadcrumb navigation according to the url (stupid and complex tasks...). So, I think it's better to use a single url in a web application whenever it possible (especially with the coming of Ajax). There is no need for bookmarks in an application unless it has some informational parts. I don't remember needing this feature in gmail for example or while looking at my account on my local Bank web site. Just my cents but he saved us a lot of troubles :) On 12/21/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > On 12/21/05, Garner, Shawn <[EMAIL PROTECTED]> wrote: > > > > so I can enter something like > > > > http://www.mycompany.com/mycontext/mymanagedbean.mymethod > > > > in my browser > > > > and it will call the mymethod method in my managed bean named > > mymanagedbean? > > > Shale won't directly do this for you today, but it would indeed be very > easy > to set something like that up -- the existing remoting facility maps > context > relative paths to a command (in the Commons Chain sense). Any of the > following approaches would be fairly simple: > > * Map all the interesting cases of "/mymanagedbean.mymethod" to a common > Command instance (that you would have to write at the moment) that would > inspect the incoming servlet path + path info and calculate the correct > method > binding expression. > > * Modify the remoting support in Shale to do more generalized pattern > matching > (versus straight string matching) so that you wouldn't have to literally > configure > every possible managed bean method you want to call (presumably using > regular expressions or something). > > * Use an action oriented framework (Struts 1.x, WebWork, Spring MVC, etc.) > for this > portion of your application, while using standard JSF stuff for the > rest. > > On the first two points, you've piqued my interest enough to think that > this > sort of thing should be easier (in Shale) than it currently is. The use > cases for AJAX style requests (or, more generally, any sort of REST-style > interface towards your application's mode data) are pretty compelling. > > The third point represents a personal bias that I will happily claim -- if > you are writing an application that is interactive with a *human* rather > than with a *machine*, you shoud consider URLs to be an irrelevant > implementation detail, rather than a fundamental architectural principle > :-). Yes, requirements for thngs like bookmarks complicate this a little > -- > but application designers in an AJAX world are going to be faced with this > kind of problem no matter what frameworks they are using. What are you > going to do if you end up using an AJAX-style approach that migrates the > entire application into a singe page (which is an architectural style at > one > end of the extremes of what is reasonable with AJAX, but it's definitely > going to need consideration)? > > Craig > > -- Alexandre Poitras Québec, Canada
