ve you over things. But I
> also believe there is a sweet spot for activities with relatively simple
> flow (filling out a wizard form, for example) that are tedious to write
> using just Actions, and we can make Struts-based development of such
> applications much simpler by abstracting away the navigation machinery.
>
> > - Do you think browser issues can be handled properly? Caching
> > has caused us problems in the areas of handling back, forward,
> > refresh buttons... for example, the previous page displays
> > correctly but the actual state of the workflow has not been
> > updated due to the page being cached and the context state is
> > incorrect.
> >
>
> The current Struts approach to this (setting or not setting the cache
> control headers) is pretty crude, but having a workflow gives us the
> opportunity to be more fine-grained about those decisions. Coupled with
> aggressive use of transaction tokens, I *think* we can handle most of
> these concerns, but we'll always need to keep this in mind.
Our specific problem may be a worse case scenario but the area we have
many problems is when displaying the centralized state of the workflow
(as breadcrumbs, etc). Our implementation happens to show that
information in a different frame from the page displaying info in a step
and disabling caching doesn't always seem to work properly - so
sometimes the breadcrumb state isn't properly updated. Just wanted to
raise it as a possible issue.
> > thanks,
> > john sigler
> >
>
> Craig
john
handling back, forward,
refresh buttons... for example, the previous page displays
correctly but the actual state of the workflow has not been
updated due to the page being cached and the context state is
incorrect.
thanks,
john sigler
