We can't prompt the users to save when they leave the page. We used to
(back when life was simpler!) but it's too annoying -- they've got a huge
set of data covering a huge number of screens, and do lots of moving
around. 99% of the time they'd say yes anyway. We now have a rollback
feature; much more pleasant for the users. (Read Alan Cooper if you want to
know more about why minimal bothering of users is a good thing.)
Incidentally, we don't do any page validation either. Users can enter any
damn thing they please until such time as they choose a Validate feature,
either for a page or the entire data set. Sounds strange, I know, but it
makes sense for this application.
And yeah, frames suck, but there they are anyway. Our navigation tree has
the potential to be huge. We can't download it with every page hit.
So all that aside...it sounds like your suggestion is quite like my
original example. Would you agree?
> > 1) user fills out form, call it currentPage
> > 1) user clicks to go to somePage.do
> > 2) javascript puts "somePage.do" in hidden field on currentPage, and
> > then initiates a submit of currentPage
> > 3) submit to currentPageSave.do
> > 3) action forwards to jsp with hidden form -- 'somePage.do' is the
form
> > action (also, javascript puts confirmation message in header frame)
> > 4) immediately submit that form using javascript
Maybe there isn't a better way. How sad that would be.
From: "James Mitchell" <[EMAIL PROTECTED]>
Date: Thu Nov 14, 2002 1:16 pm
Subject: RE: "deferring" an action
I'm typing too fast today.....
> So, the only difference between hitting save and clicking to go
somewhere
> else is the location.href='somepage.do' somewhere
that appears after the 'changes saved' or 'error' page is rendered.
> Of course, if there were errors, then you need to handle that as well.
Meaning that they would need to fix them or hit cancel.
> I'm guessing that hitting cancel at this point will let them escape
> the forced workflow/validation.
So a cancel will take them to the link they clicked on before they were
prompted to save changes.
Sorry, hope I got it right this time.
James Mitchell
Software Engineer/Struts Evangelist
http://www.open-tools.org
"If you were plowing a field, which would you rather use? Two strong oxen
or
1024 chickens?"
- Seymour Cray (1925-1996), father of supercomputing
> -----Original Message-----
> From: James Mitchell [mailto:jmitchtx@;t...]
> Sent: Thursday, November 14, 2002 1:08 PM
> To: Struts Users Mailing List
> Subject: RE: "deferring" an action
>
>
> I would enforce the workflow.
>
> When the user wants to leave an editable form, if any fields were
changed
> (dirty), then prompt to save changes. If no, then proceed as normal. But
> if yes, then call the normal save action (with either 'changes
successful'
> page or 'error' page, however you are doing it) which keeps them in the
> workflow (e.g. validation of fields) and then provide some
> JavaScript to go
> to the originally selected URL (you'll need to store this prior to
> submitting the original form.
>
> So, the only difference between hitting save and clicking to go
somewhere
> else is the location.href='somepage.do' somewhere. Of course, if
> there were
> errors, then you need to handle that as well. I'm guessing that hitting
> cancel at this point will let them escape the forced
workflow/validation.
>
> This is also one good example of the reasons I don't like (or use)
frames.
> If you are using a tree view script that displays something
> equivalent to an
> open folder (to visually show the user where they are in the
> app). Then, in
> cases like the above, you are constantly sending script back in the
moving
> (target) frame to update the static (menu) one. Ack!!!
>
>
> James Mitchell
> Software Engineer/Struts Evangelist
> http://www.open-tools.org
>
> "If you were plowing a field, which would you rather use? Two
> strong oxen or
> 1024 chickens?"
> - Seymour Cray (1925-1996), father of supercomputing
>
>
> > -----Original Message-----
> > From: Alayne Wartell [mailto:alayne.wartell@;t...]
> > Sent: Thursday, November 14, 2002 12:26 PM
> > To: [EMAIL PROTECTED]
> > Subject: "deferring" an action
> >
> >
> > This is something I haven't seen discussed before. Our web
> application has
> > a large, dynamically built tree in its own frame by which users
> > navigate to
> > input screens. ( They can also click on menu options --
> slightly different
> > but raises the same issue for us.) Data entry is freeform -- users can
> > navigate anywhere at any time. So far, no big deal. The unusual part
is,
> > when a user finishes entering data on a screen, then clicks to go to
> > another screen, we automatically save the screen they're leaving. In a
> > sense, we have to defer the page load action to do a save action on
the
> > prior page. So we're trying to come up with a clean way to fit this
into
> > Struts.
> >
> > The sequence is:
> > Click link -> save current page -> respond with reassuring message in
> > another frame (i.e. "screen has been saved") -> go to clicked link
> >
> > We haven't come up with any designs we like yet. One example of
> something
> > we don't like:
> >
> > 1) user fills out form, call it currentPage
> > 1) user clicks to go to somePage.do
> > 2) javascript puts "somePage.do" in hidden field on currentPage, and
> > then initiates a submit of currentPage
> > 3) submit to currentPageSave.do
> > 3) action forwards to jsp with hidden form -- 'somePage.do' is the
form
> > action (also, javascript puts confirmation message in header frame)
> > 4) immediately submit that form using javascript
> >
> > Ideas, anyone? (Sure, we could do away with the auto-save to
> make our app
> > more webbish -- if it weren't a business requirement. Besides, it
> > really is
> > nice for the users.)
> >
> > Thanks,
> > Alayne
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@;j...>
> For additional commands, e-mail:
> <mailto:struts-user-help@;j...>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@;j...>
For additional commands, e-mail:
<mailto:struts-user-help@;j...>
--
To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;j...>
For additional commands, e-mail: <mailto:struts-user-help@;j...>
-- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
