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
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
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;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
Re: deferring an action
Alayne, Would a time requirement mess things up? If not, your actions could simply place the forms into session scope. Most of our clients don't spend all day at their machines, so 30 minutes or so is too much of a constraint... Just a wild thought :o) Brian - Original Message - From: Alayne Wartell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 12:25 PM 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
Re: deferring an action
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
Re: deferring an action
As a matter of fact, our users are chained to their desks. Ok, I'm lying. But your suggestion may have merit -- the form would be in session scope but not for very long -- just long enough to be put there when the user clicks a link, then saved, then it could go away. But would you mind explaining how putting the form in session scope would solve the issue at hand? In some nice clean struts-like way? The issue being 1) click for action #1 ; 2) perform action #2; 3) perform action #1 where actions 1 and 2 are arbitrary, not known ahead of time. Thanks, Alayne To: Struts Users Mailing List [EMAIL PROTECTED] Brian Hickey cc: (bcc: Alayne Wartell/Towers Perrin) bhickey@r-effectSubject: Re: deferring an action s.com 11/14/2002 01:21 PM Please respond to Struts Users Mailing List Alayne, Would a time requirement mess things up? If not, your actions could simply place the forms into session scope. Most of our clients don't spend all day at their machines, so 30 minutes or so is too much of a constraint... Just a wild thought :o) Brian - Original Message - From: Alayne Wartell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 12:25 PM 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
Re: deferring an action
You are not deferring an action, you are queuing a save. Most of the time a save is very quick, even with thousands of users, so I say just save. Else consider: Implement a queue mechanism in you DAO so you can say bean.getDAO().saveAsyc(); You could write a thread safe singleton collection to append your data to, such as rowset, not yet updated and go on with your process. This requires thread and collection experience, something like http://gee.cs.oswego.edu/dl/classes/collections Then spawn another process in container of low priority that remove things from the queue, save, sleeps and then remove another. This make a dirty read possible of course, so you might have to build a hashcode of your queue (or even add a cache to the queue). hth, .V Alayne Wartell wrote: 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
