Colin Chalmers schrieb: > 1. The browser Back-button > when the user clicks on the browser back-button he should be taken > back a page without loss of data . > I've seen comments about client/side state saving in connection with > cache expiry settings > I've also seen solutions based on seam & shale. > Can someone comment on this as to what works for them? >
Myfaces has an integrated state history you can enable/disable I do not have the exact infos on it, but it has been working well for almost a year now. The back button is indeed not a problem anymore not even in server side state saving, in client side one the state is pushed into the html code anyway. > 2. Bookmarking pages > I've seen workarounds with servlet-filters. Does MyFaces have a > solution or should I be looking at Jsf_sping? > Bookmarking is not possible in post situations, restfulness can be achieved via outputlink and dedicated params. Commandlink enforces a form post which is not restful. Http get is ommitted from jsf. (but can be simulated via outputlink) There might be other solutions but that is what you get out of the box. (Some systems can provide dedicated nav handlers which push you to a generic entry page if you bookmark inside of a form) > 3. Google findable > Is anyone able to tweak faces to allow Google to crawl and index? > see above, to my knowledge you have to plan ahead and make the crawlabel data restful which means you need a page hierarchy being able to be crawlable. Which means, make commandlinks for the pages you need to be crawled. > 4. Initializing data-sources > We had an ugly workaround to init/destroy data in backing-beans. I > see that Shale has methods for this (aptly called init/destroy) > How do others do this with *basic* myfaces to ensure that data is > retrieved once during the life-cycle? > For now Shale is probably the best option you can get currently, besides seam. If you are in an orm context, there will be another option soon, the new myfaces fusion project addresses this issue very similar to Seam (Currently it is in development, but something usable will be there soon) Which means you work in conversation contexts and you have an open connection/entity manager per conversation, the objects are kept in ram as long as the conversation is open, and you can synchronize them back to the db via flush() once the conversation is done, everything is dropped. Seam does it that way, fusion also, but fusion is not quite there yet to be easily usable (will be soon however) The restfulness of those systems and the bookmarking ability is another issue. If you bookmark a conversation system, under best circumstances it should push you to a dedicated page outside or at the begin of the conversation, which lets you start anew.
