struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Mitchell" <jmitc...@telocity.com>
Subject RE: "deferring" an action
Date Thu, 14 Nov 2002 18:08:10 GMT
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@towers.com]
> Sent: Thursday, November 14, 2002 12:26 PM
> To: struts-user@jakarta.apache.org
> 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@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message