Intermixed.
On 2/25/07, Colin Chalmers <[EMAIL PROTECTED]> wrote:
Hi all,
I'm evaluating different frameworks to enhance our use of Myfaces and
address the following questions.
After reading through the Shale docs it's still unclear to me if/how
shale tackles these problems, I'd appreciate some input from those
more familiar with shale/faces with respect to the following:
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 when in a particular
flow, how is this tackled in shale?
For non-dialog pages, Shale offers a mechanism to detect that a
duplicate form submit, via use of the "token" component that will
create a validation error in such cases. This can be used to avoid
things like double charging to a credit card if the user tries to
check out with a shopping cart twice.
If you are using the "basic" dialog manager feature, you have a couple
of choices that can be configured at runtime with a context init
parameter:
* "none" -- ignore the fact that the user might be using the back arrow
instead of your "previous page" button. This is perfectly reasonable in
use cases like a wizard dialog when you're just collecting a bunch of
data on multiple pages, and it does not matter if values get re-entered.
* "top" -- ask the dialog manager to save and restore state information
so that, if the user presses the back arrow, anything previously entered
on that page is undone. This does *not* support crossing into subdialogs
because it only saves state for the topmost subdialog (if there is
more than one).
* "stack" -- like "top", but allows you to cross subdialog boundaries as well.
The tradeoff is it takes more space/time to save and restore the
state information,
because the entire stack is processed.
The SCXML version of the dialog manager operates in a manner similar
to the "stack" option by default, since it does not have the same
concept of subdialogs as the "basic" implementation.
2. Bookmarking pages
I've seen workarounds with servlet-filters. Does Shale solve this and
if so how?
The most reasonable approach to this (for all Java based web
frameworks, not just JSF or Shale) is to do the following:
* Use the "redirect after post" pattern, so that when you navigate to
a different page,
this is done with an HTTP redirect instead of a
RequestDispatcher.forward(). This
causes the browser's URL to show the new page as expected, but costs you the
extra network round trip.
* Make your application support both GET and POST requests. With Shale, this
is particularly easy because you can grab request parameters in the
init() method
(if you are using the Shale view controller facility) in order to
react differently.
3. Google findable
Is Shale able to help in getting the pages Google findable?
What features or capabilities do you believe are necessary to make
pages "Google findable"? For the most part, using techniques that
create bookmarkable URLs will deal with most such issues (although
expecting a search engine to index a dynamic application doesn't seem
very likely to yield useful results), but it sounds like you have
something else in mind as well.
thx in advance
Colin
Craig
