Re: [Chiba-users] Chiba-Web session: is it save now ...
Creators discontinued Chiba & founded betterFORM http://betterform.de
Brought to you by:
chibaxforms,
windauer
Menu
▾
▴
Re: [Chiba-users] Chiba-Web session: is it save now ...
|
From: Martin W. <mwe...@pl...> - 2007-03-27 09:27:51
|
On Tuesday 27 March 2007 01:51, Klotz, Leigh wrote:
> If the user agent itself implemented XForms, then you could
> navigate off (with a hyperlink, or an xf:load), press the back
> button, and come back. With Chiba operating as a split agent, often
> state is lost when the user navigates off, so Chiba must protect
> the user against such actions. So, I contributed code to chiba to
> use onunload and onbeforeunload to catch these cases and shut down
> the session, to alert the user and to prevent memory leaks. As an
> extension, I also use attribute
> chiba:inhibitUnloadConfirmation=3D'true' on the <html> element as a
> hint to inhibit the onbeforeunload query.
Leigh,
both features - session closing and the 'confirm leaving ...' - are=20
very much appreciated over here. The servlet now runs happily for a=20
number of weeks when before I restarted quite frequently (yes, I only=20
got a hammer ;-)
You seem to have answered my next question: I just hang=20
the 'inhibitUnloadConfirmation' on the html element to prevent the=20
confirmation box on forms where users *feel* not to have changed=20
anything (they opt for a submission mode and do not regard that as a=20
change to the form), right?
Thanks, Martin
> However, XForms 1.0 offers no mechanism for querying the user about
> navigating off the page. HTML4 with JavaScript offers onunload and
> onbeforeunload.
> We had a proposal in XForms 1.1 for an xforms-close event, which
> was to be something like Javascript window.close. But it did not
> have any xforms-on-close and xforms-on-before-close functionality
> at all. So we removed it from the XForms 1.1 draft.
> Unfortunately, it remains in the XForms 1.1 requirements document
> ;-(.
>
> Clearly, more features are needed this area, both to fix the
> problems inherent in a Chiba-style implementation and to give new
> (or old) capabilities to form authors. I would be quite pleased to
> see Chiba as an incubator for an event-based mechanism for the
> xforms-on-close and xforms-on-before-close events and implement
> them using the HTML4+JavaScript browser's onload and onbeforeunload
> handlers.
>
> Leigh.
>
> > The load action on the other
> >
> > > hand is a way the page author has to intentionally allow to
> > > navigate away and it should be the authors' responsibility to
> > > make sure that a load only occurs in situations that are
> > > defined and allowed and leave an inconsistent state.
> > >
> > > But the more i think the less convincing this argument feels to
> > > me. This should be reviewed. What's your opinion here?
> >
> > I read with great interest your reply to one of Adam Flintons
> > mails:
>
> -----Original Message-----
> From: chi...@li...
> [mailto:chi...@li...] On Behalf Of
> Martin Weinelt Sent: Thursday, March 15, 2007 2:19 AM
> To: Joern Turner
> Cc: chi...@li...
> Subject: Re: [Chiba-users] Chiba-Web session: is it save now ...
>
> On Wednesday 14 March 2007 23:46, Joern Turner wrote:
> > Martin Weinelt wrote:
> > > ... to use (html) <a href=3D ..>, or even browser back-button,
> > > for navigation, without messing up the session (we discussed
> > > memory leak effects due to this before).
> >
> > right. We now have one XFormsSession for every form a user opens.
> > Several XFormsSessions may exist within the users' http session.
> > If the user 'backs out' of a form the current XFormsSession will
> > be terminated. If the Url you're 'backing to' happens to be a
> > XForms too it will be requested with a GET.
> >
> > Additionally there's a simple XFormsSessionManager will will
> > check for expired sessions regularily and wipe them if necessary.
> > You can have your own pluggable implementation of that.
> >
> > > Looking at Fluxinterface.js, there seems to be some session
> > > management 'on unload' now. Am I right? In this case the
> > > session would be properly terminated, no matter how I leave the
> > > form, no?
> >
> > right again. The XFormsSession will be shut down and removed.
>
> J=F6rn,
>
> this whole session topic has always been *very* important to me.
> Cant't say how happy I am with what you say above. This is really
> great, thanks a lot.
>
> > > I also love the 'confirming message' for changed form content
> > > onunload ('isDirty' var). But obviously this is circumvented
> > > (or not registered?) for <xf:load>-triggers. Again my question:
> > > is that true or am I missing s/th.
> >
> > Think you're talking about load/@show=3D"replace" ...
> >
> > well, yes you're right. This seems to need another look.
> >
> > Think we had a reason doing so but i'm not sure any more what is
> > was ;) but it sort of was like this:
> >
> > the page exit handling is mainly for preventing the user from
> > unintended navigation that would lead to data-loss and that's out
> > of the reach of the XForms processor. The load action on the
> > other hand is a way the page author has to intentionally allow to
> > navigate away and it should be the authors' responsibility to
> > make sure that a load only occurs in situations that are defined
> > and allowed and leave an inconsistent state.
> >
> > But the more i think the less convincing this argument feels to
> > me. This should be reviewed. What's your opinion here?
>
> I read with great interest your reply to one of Adam Flintons=20
mails:
> > " ...Serving up the xhtml/xforms page would give the user a much
> > better experience through the quick response and allows to
> > 'entertain the user' a bit while waiting. A common trick in AJAX
> > apps...")
>
> the situation here ('confirm' xf:load) is comparable: we are
> entering the field of 'users psychology' when asking wether to
> include the leaving message also for <xf:load show=3D"replace"> or
> not.
>
> >From the forms authors view you are absolutely right: the load
> > action
>
> is to load another form, so that is what is does, period. But
> frankly: there are users who click on anything without any
> intentions. Scenario: user changed data and clicks load-trigger.
> You cannot simply submit the changes silently, because that might
> not be what the user wants. But it may exactly be what the user
> wants, so the author got to give her a chance to save.
>
> So if you ask me, I would say yes, we should have the
> 'confirm-leave'- msg also for xf:load *if the form isDirty*.
>
> Ok, one can always register a js-confirm to the load trigger, if
> you must. But I would prefer to have that included in Flux, as for
> any other navigation. As I said: I guess forms authors will ask for
> it, and having it build-in is convenient and elegant.
>
> 2c,
>
> Martin
>
> > > Thanks for any insights,
> > >
> > > Martin
>
> -------------------------------------------------------------------
>------ Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your opinions on IT & business topics through brief
> surveys-and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D
>DEVDEV _______________________________________________
> Chiba-users mailing list
> Chi...@li...
> https://lists.sourceforge.net/lists/listinfo/chiba-users
=2D-=20
--- Martin Weinelt=20
--- kk+w - digital cartography=20
--- Kiel, Germany
--- Tel: +49.431.5791165
--- http://www.planiglobe.com=20
|