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:16:47 GMT
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@telocity.com]
> 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@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>



--
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