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: [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@;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>
