Re: Re: Browser back button solution?

Hello guys,

sorry for the delay - you brought up an important topic.

But please before going to solutions some remarks about XForms and the 
back-button.

In XForms a form is build around a purpose and uses a model to capture 
this purpose. The user will work with only one URI during the whole 
form-filling session. Sure this doesn't mean that you can't have 
multiple forms or pages but you should keep this in mind when designing 
XForms apps. One purpose should be caught with one form and not by 
chaining several forms together. XForms 1.0 does not deal with chained 
forms at all.

This said it should become clear that there's not much room for the 
back-button in this scenario. But nevertheless back to the scenario...

You have send your form1 - what does that mean with XForms? The user has 
either submitted with replace='all' or used a load action to jump to 
form2. Now, when the user clicks the backbutton on form2 what should 
actually happen? You you want to invalidate the decision just taken by 
the user by leaving form1 with mentioned actions and step back to the 
start of form1? Or do you want the state back where the user left 
form-processing (ignoring the last action of the user; the submit or 
load)? When keeping in mind that this very action may have changed the 
contents of some database or transactional system somewhere you may 
imagine that this can be difficult. XForms tries to establish a clean 
processing model with defined entry and exit points and the backbutton 
simply does not fit within here.

XForms is often thought of being a clientside technology so it's easy to 
imagine that a native implementation wouldn't allow you to leave your 
current page (form2 in this case) without confirmation and letting the 
user know of the consequences (eventually loosing data if not storing 
somehow) when she hits the backbutton.

For the serverside it's a bit more difficult. The actual detection is 
easy. Just store the referrer header when initializing a form and you're 
ready to detect if the user left the page with 'back'. The problem is to 
decide what to do with that - the user is already back on form1 when we 
get this information. It would be better to not allow the user to 
navigate away with confirmation. Maybe this can be achieved with 
Javascript in our upcoming ajaxed implementation. We'll keep this in 
mind and are surely open for your suggestions.


Martin Tilma wrote:
> Hello Michael,
>
> Thank you for your reply. I didn't know that there is a singleton for 
> the state.
>
> I'am willing to patch the source code of Chiba. In fact I already did 
> that. (see 
> http://sourceforge.net/mailarchive/forum.php?thread_id=8435850&forum_id=2467) 
>
>
> I use a Struts action instead of the ChibaServlet and SevletAdapter. My 
>   Struts action acts like the ServletAdapter. Writing a proper Adapter 
> is on my todo list.
>
> I want to fix these problems because of the simple fact that people use 
> the back button. With a normal form this will work, so why not with my 
> xforms form?
That's not right. The back-button won't work in most webapps when forms 
are using POST. You can often watch this in internet apps. You'll get a 
browser warning and most often the re-submittal of the form will fail. 
Especially when forms are statefull in some way and manage their values 
with hidden fields this will fail. There are frameworks that hack around 
this by implementing sophisticated state tracking but plain htmlforms 
just have a problem when using POST.

> Could you send me more information on your solution?
>
> Greatings,
>
> Martin
>
> Michael Bridgen wrote:
>
> > > The problem:
> > > Open a page with form1 (I place a ChibaBean in session). Open a page
> > > with another form: form2. (A new ChibaBean will be placed in session)
> > >
> > > Use te back button of the browser to get back to form1. When you post
> > > form1 you will get an error because the ChibaBean for form2 is in
> > > session instead of form1.
> > >
> > > Is this a common problem?
> >
> >
> >
> > I don't know how common it is.  It is something of a limitation to only
> > ever allow a single form state per user per servlet.
> >
> > There is another problem with the back button: you can't resubmit a
> > (HTML) form, even if it is the same XForms form.  The (singleton) XForms
> > state is mutated when you submit a form.
> >
> >
> > > My solution:
> > >
> > > Open a page with form1. Create a new ChibaBean and place it in session
> > > with a name and timestamp. Place the timestamp in the html form. Do so
> > > with every form (multiple windows, multiple forms). When you post a
> > > form, get the coresponding ChibaBean from session by the timestamp.
> > >
> > > Do not shutdown the ChibaBeans but keep them in session.
> > >
> > > Will this work?
This would be a way i think. And we're definitely consider such an 
option for the future. Not just for the back-button problem but simply 
to allow one user to use multiple forms at a time.
> > I think it will solve the first problem, if you can hack the
> > ChibaServlet to tag /new/ instances of ChibaBean, and arrange for the
> > tag to be passed back to it (another way to do this, for example, is to
> > append your tag to the form action URL).  You probably won't have
> > problems with storing them, since it will increase as the number of new
> > forms visited, and you know when a form is completed so you can remove 
> > them.
> >
> > However, it doesn't solve the second problem, which is that the state
> > for a particular instantiation of an XForms form is a singleton.  The
> > only way to solve that is to make a copy of the state for /each
> > request/.  Unfortunately, though the various relevant classes (ChibaBean
> > in particular) are marked as Cloneable or Serializable, they aren't
> > either in practice (both of these interfaces are markers only).  Worse,
> > most of the state in these classes is marked private and doesn't have
> > accessors let alone mutators, so you can't clone them from outside the
> > class either.  Apart from patching the source code, your only option is
> > to use reflection to pick out the bits you need and create new instances
> > with those values.  This is brittle in the extreme.
Can't follow you here with the 'singleton' XForms. As i tried to explain 
at the start of the mail you've to answer the question what a resubmit 
really *should* mean then.

XForms work on instance-data and there's a defined model how and when 
instance-data are changed. When submitting you intention is to persist 
(or mutate) this state. This change can also be seen as a user-confirmed 
change of the data.

Maybe i completely miss the point here ... if so, please explain what 
you're trying to accomplish (but cloning of ChibaBean won't hardly be 
the right way of doing it).

Joern
> > I'm just now trying to fix this precise problem myself.  I've found that
> > (so far) I've needed to subclass ChibaBean and Container (I use the DOM
> > API's cloneNode to clone the document) and use reflection to get at
> > ChibaBean's container field and Container's models field.  I also wrote
> > my own ServletAdapter.  If you want more details or you have another
> > solution let me know.
> >
> > mikeb.
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by the JBoss Inc.
> > Get Certified Today * Register for a JBoss Training Course
> > Free Certification Exam for All Training Attendees Through End of 2005
> > Visit http://www.jboss.com/services/certification for more information
> > _______________________________________________
> > Chiba-developer mailing list
> > Chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/chiba-developer



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php