You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Alayne Wartell <al...@towers.com> on 2002/11/14 18:25:33 UTC
"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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: "deferring" an action
Posted by Brian Hickey <bh...@r-effects.com>.
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" <al...@towers.com>
To: <st...@jakarta.apache.org>
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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: "deferring" an action
Posted by "V. Cekvenich" <vi...@users.sourceforge.net>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: "deferring" an action
Posted by James Mitchell <jm...@telocity.com>.
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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: "deferring" an action
Posted by James Mitchell <jm...@telocity.com>.
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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>