Re: still wondering Re: Where to repopulate dynamic lists ?
On Wed, Feb 12,'03 (07:45 AM GMT-0500), Robert wrote: > Rick, I usually define the setUpForm action URI as the input attribute > of the processForm action element. That way if a validation error > occurs the request is forwarded to the setUpForm action which > repopulates the list and forwards to the page where my list is > displayed along with the error message and the users input. That seems like an excellent idea! I'll have to try that. Thanks! -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: still wondering Re: Where to repopulate dynamic lists ?
I'd like to hear Craig and/or Ted respond to this topic. I think the
solutions presented this far are interesting, but would like to hear what
the "Struts masters" say. I haven't seen anything about this very common
problem in the two Struts books I have or in the online docs.
Come on Craig or Ted we await your pearls of wisdom.
> -Original Message-
> From: Theodas, Jacques [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 12, 2003 11:30 AM
> To: [EMAIL PROTECTED]
> Subject: RE: still wondering Re: Where to repopulate dynamic lists ?
>
>
> Rick,
> I just read your post on this question and wanted to share how I
> handle this.
> Whenever I have a page with a dynamic dropdown list, I set
> validate to false for the action that I am submitting to in
> struts-config.xml.
> Then in my action, I call the validate method on the ActionForm
> that I get.
>
> AddEmployeeForm myForm = (AddEmployeeForm)form;
> ActionErrors errors = myForm.validate(mapping, request);
> if (errors.empty()) {
> //work with the submitted data
> } else {
>
> //recreate dynamic lists as collections and put
> them in the request.
> saveErrors(request,errors); // so
> can display them
> return new ActionForward(mapping.getInput());
> //forward back to the submitting jsp page
> }
> Jacques
>
> > -Original Message-
> > From: Rick Reumann [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, February 11, 2003 10:48 AM
> > To: Struts Users Mailing List
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: still wondering Re: Where to repopulate dynamic lists ?
> >
> >
> > Sorry Craig to e-mail you directly but this topic has been up for a
> > while and I'd really be curious on your take on this. (I'm working on
> > struts demo and I don't mislead others by doing something 'wrong').
> >
> > To recap I'm wondering what is the best practice for repopulating a
> > dynamic list that a user would need on a form. For example possibly it's
> > a form where a user has to select from a list of"Order Numbers"(which
> > could frequently change and could be based on the user logged in). The
> > way I currently tackle this is in the setUpForm type of action a
> > business object is called which returns to me this list and puts the
> > list into request scope to be used on the form. The problem is when the
> > user submits the form and validation returns false. Somewhere this list
> > needs to be repopulated. I could of course put this list (or even the
> > form bean) into session scope, but I thought that was to be avoided
> > since the only thing this list is used for is this one page. To solve
> > this problem I've been calling this business object to get my list in
> > the reset() method and putting it back into scope. I've heard others say
> > this is a bad idea(although I'm not sure why) and yet I haven't really
> > heard any other'much better' solutions.
> >
> > Some comments below on Mitchell's last post..
> >
> > On Tue, 11 Feb 2003 10:20:52 -0500
> > "Mitchell Morris" <[EMAIL PROTECTED]> wrote:
> >
> > > > > #1) Create a custom tag library to share an application-wide
> > > > > cached value of the order list, and populate the list into scope:
> > > [snip]
> > > >
> > > > This is probably a pretty good solution, although doesn't this go
> > > > against the thought of all the objects to display should be set
> > > > up before you even reach the JSP page? Basically now your JSP
> > > > page is doing business logic.
> > >
> > > Ooooh ... philosophical purity! I seen some of that once! I'm not
> > > entirely sure where the objection lies here, because the view object
> > > (JSP) isn't directly manipulating the model object (order list), but
> > > rather is intermediated by a controller object (tag library). Seems to
> > > me the MVC purity is being maintained. On the other hand, I might be
> > > wrong. At least it isn't a scriptlet.
> >
> > Trust me I'm not against using a tag to do it in the JSP page, I'm just
> > wondering how this is any "more pure/better" than just setting the list
> > back up in the reset method?
> >
> > > > One solution I thought might work is every time the list was
> > > > updated to
> > > > the db I'd make sure to get a new cached copy and put that into
> > > &g
RE: still wondering Re: Where to repopulate dynamic lists ?
Rick,
I just read your post on this question and wanted to share how I handle this.
Whenever I have a page with a dynamic dropdown list, I set validate to false for the
action that I am submitting to in struts-config.xml.
Then in my action, I call the validate method on the ActionForm that I get.
AddEmployeeForm myForm = (AddEmployeeForm)form;
ActionErrors errors = myForm.validate(mapping, request);
if (errors.empty()) {
//work with the submitted data
} else {
//recreate dynamic lists as collections and put them in the request.
saveErrors(request,errors); // so can display them
return new ActionForward(mapping.getInput()); //forward back to the
submitting jsp page
}
Jacques
> -Original Message-
> From: Rick Reumann [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 11, 2003 10:48 AM
> To: Struts Users Mailing List
> Cc: [EMAIL PROTECTED]
> Subject: Re: still wondering Re: Where to repopulate dynamic lists ?
>
>
> Sorry Craig to e-mail you directly but this topic has been up for a
> while and I'd really be curious on your take on this. (I'm working on
> struts demo and I don't mislead others by doing something 'wrong').
>
> To recap I'm wondering what is the best practice for repopulating a
> dynamic list that a user would need on a form. For example possibly it's
> a form where a user has to select from a list of"Order Numbers"(which
> could frequently change and could be based on the user logged in). The
> way I currently tackle this is in the setUpForm type of action a
> business object is called which returns to me this list and puts the
> list into request scope to be used on the form. The problem is when the
> user submits the form and validation returns false. Somewhere this list
> needs to be repopulated. I could of course put this list (or even the
> form bean) into session scope, but I thought that was to be avoided
> since the only thing this list is used for is this one page. To solve
> this problem I've been calling this business object to get my list in
> the reset() method and putting it back into scope. I've heard others say
> this is a bad idea(although I'm not sure why) and yet I haven't really
> heard any other'much better' solutions.
>
> Some comments below on Mitchell's last post..
>
> On Tue, 11 Feb 2003 10:20:52 -0500
> "Mitchell Morris" <[EMAIL PROTECTED]> wrote:
>
> > > > #1) Create a custom tag library to share an application-wide
> > > > cached value of the order list, and populate the list into scope:
> > [snip]
> > >
> > > This is probably a pretty good solution, although doesn't this go
> > > against the thought of all the objects to display should be set
> > > up before you even reach the JSP page? Basically now your JSP
> > > page is doing business logic.
> >
> > Ooooh ... philosophical purity! I seen some of that once! I'm not
> > entirely sure where the objection lies here, because the view object
> > (JSP) isn't directly manipulating the model object (order list), but
> > rather is intermediated by a controller object (tag library). Seems to
> > me the MVC purity is being maintained. On the other hand, I might be
> > wrong. At least it isn't a scriptlet.
>
> Trust me I'm not against using a tag to do it in the JSP page, I'm just
> wondering how this is any "more pure/better" than just setting the list
> back up in the reset method?
>
> > > One solution I thought might work is every time the list was
> > > updated to
> > > the db I'd make sure to get a new cached copy and put that into
> > > application scope which all the user's cold have. This would
> > > be a great
> > > option except this list could be very specific to a
> > > particular user- it
> > > wouldn't work well in application scope because of this since
> > > the lists
> > > could vary depending on the user logged in.
> >
> > Well, you could certainly go with this scheme even in a user-specific
> > case. The tag library would need to interact with the other model
> > objects in session scope to coordinate the user's identity and thus to
> > extract/cache the correct order list. It's starting to look icky,
> > though, so you might now like choice #2 better.
>
> Yes, very icky I think. Better would be for each user's session to hold
> this list data or repopulate this list (where/when?) before getting
> back to the form upon validation errors.
>
RE: still wondering Re: Where to repopulate dynamic lists ?
Rick, I usually define the setUpForm action URI as the input attribute of the processForm action element. That way if a validation error occurs the request is forwarded to the setUpForm action which repopulates the list and forwards to the page where my list is displayed along with the error message and the users input. Works for me and I don't have to place anything in the session. robert > -Original Message- > From: Rick Reumann [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 11, 2003 10:48 AM > To: Struts Users Mailing List > Cc: [EMAIL PROTECTED] > Subject: Re: still wondering Re: Where to repopulate dynamic lists ? > > > Sorry Craig to e-mail you directly but this topic has been up for a > while and I'd really be curious on your take on this. (I'm working on > struts demo and I don't mislead others by doing something 'wrong'). > > To recap I'm wondering what is the best practice for repopulating a > dynamic list that a user would need on a form. For example possibly it's > a form where a user has to select from a list of"Order Numbers"(which > could frequently change and could be based on the user logged in). The > way I currently tackle this is in the setUpForm type of action a > business object is called which returns to me this list and puts the > list into request scope to be used on the form. The problem is when the > user submits the form and validation returns false. Somewhere this list > needs to be repopulated. I could of course put this list (or even the > form bean) into session scope, but I thought that was to be avoided > since the only thing this list is used for is this one page. To solve > this problem I've been calling this business object to get my list in > the reset() method and putting it back into scope. I've heard others say > this is a bad idea(although I'm not sure why) and yet I haven't really > heard any other'much better' solutions. > > Some comments below on Mitchell's last post.. > > On Tue, 11 Feb 2003 10:20:52 -0500 > "Mitchell Morris" <[EMAIL PROTECTED]> wrote: > > > > > #1) Create a custom tag library to share an application-wide > > > > cached value of the order list, and populate the list into scope: > > [snip] > > > > > > This is probably a pretty good solution, although doesn't this go > > > against the thought of all the objects to display should be set > > > up before you even reach the JSP page? Basically now your JSP > > > page is doing business logic. > > > > Ooooh ... philosophical purity! I seen some of that once! I'm not > > entirely sure where the objection lies here, because the view object > > (JSP) isn't directly manipulating the model object (order list), but > > rather is intermediated by a controller object (tag library). Seems to > > me the MVC purity is being maintained. On the other hand, I might be > > wrong. At least it isn't a scriptlet. > > Trust me I'm not against using a tag to do it in the JSP page, I'm just > wondering how this is any "more pure/better" than just setting the list > back up in the reset method? > > > > One solution I thought might work is every time the list was > > > updated to > > > the db I'd make sure to get a new cached copy and put that into > > > application scope which all the user's cold have. This would > > > be a great > > > option except this list could be very specific to a > > > particular user- it > > > wouldn't work well in application scope because of this since > > > the lists > > > could vary depending on the user logged in. > > > > Well, you could certainly go with this scheme even in a user-specific > > case. The tag library would need to interact with the other model > > objects in session scope to coordinate the user's identity and thus to > > extract/cache the correct order list. It's starting to look icky, > > though, so you might now like choice #2 better. > > Yes, very icky I think. Better would be for each user's session to hold > this list data or repopulate this list (where/when?) before getting > back to the form upon validation errors. > > > > > #2) Have an Action populate the list into the Form before > > > > forwarding to the display page. The chain starts with your action, > > > > which can implement your desired caching scheme for the list of > > > > orders, then displays the JSP. The JSP submits back to an action, > > > > which > > > can restart >
RE: still wondering Re: Where to repopulate dynamic lists ?
What? You're going over my head? Fine. Be that way. I'm now going to charge you double for my free advice and unsolicited opinion :) [snip-and-rearrange] > Yes, actually I never did put the list into the form bean but had > initially put the list in request scope. Now we've come full circle:) > We're back to the beginning where it seems the choices seem > to come down > to: > > 1) putting the list into session scope (the list will reset when the > user hits the setUpAction on another request to do this type > of action). > > or > > 2) put the list into request scope and repopulate this list when reset > is called. Now I'm confused ... if you don't have the property in the form, then what kind of "reset()" are we talking about? If you're suggesting having "ActionForm.reset()" do anything besides release its own resources, then I'm agin' it. My sneakiest suggestion was to presume that there will continue to be only one instance of your form bean instantiated and you could get away with not releasing the list reference in the reset() method so it would still be there when the form validation failed. If your objection is having the reference in the session scope after the action chain is finished, then have action #2 remove it [via pageContext.removeAttribute()]. If other people have objections, then let them stand up and state them. [snip-and-rearrange] > To recap I'm wondering what is the best practice for repopulating a > dynamic list that a user would need on a form. For example > possibly it's > a form where a user has to select from a list of"Order Numbers"(which > could frequently change and could be based on the user logged in). The > way I currently tackle this is in the setUpForm type of action a > business object is called which returns to me this list and puts the > list into request scope to be used on the form. The problem > is when the > user submits the form and validation returns false. Somewhere > this list > needs to be repopulated. I could of course put this list (or even the > form bean) into session scope, but I thought that was to be avoided > since the only thing this list is used for is this one page. To solve > this problem I've been calling this business object to get my list in > the reset() method and putting it back into scope. I've heard > others say > this is a bad idea(although I'm not sure why) and yet I haven't really > heard any other'much better' solutions. I'll go out on a limb and say there aren't any "a-Ha!" solutions of staggering brilliance and philosophical purity. If there were, then somebody else would have already written about them (Hi, Ted!) I'll throw out my guidelines: (1) hidden fields are evil, and allow those bastard users to screw me over (2) things for this user belong in session scope (3) things for all users belong in application scope (4) the machinery (Struts et al.) uses whichever scope it likes (often request) #1 means I hardly ever think putting things in request scope is a good idea. I'm certainly not going to trust whatever comes back once the user touches it, so if I need to know it later then I'd better save it where the user can't touch it. That means that I keep all manner of things in session scope, like the aforementioned order list as well as all the model objects. Global object caches and their ilk live in application scope because database calls are too damned expensive to make unless it's really really necessary. paranoia-is-its-own-reward-ly y'rs, +Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: still wondering Re: Where to repopulate dynamic lists ?
Sorry Craig to e-mail you directly but this topic has been up for a while and I'd really be curious on your take on this. (I'm working on struts demo and I don't mislead others by doing something 'wrong'). To recap I'm wondering what is the best practice for repopulating a dynamic list that a user would need on a form. For example possibly it's a form where a user has to select from a list of"Order Numbers"(which could frequently change and could be based on the user logged in). The way I currently tackle this is in the setUpForm type of action a business object is called which returns to me this list and puts the list into request scope to be used on the form. The problem is when the user submits the form and validation returns false. Somewhere this list needs to be repopulated. I could of course put this list (or even the form bean) into session scope, but I thought that was to be avoided since the only thing this list is used for is this one page. To solve this problem I've been calling this business object to get my list in the reset() method and putting it back into scope. I've heard others say this is a bad idea(although I'm not sure why) and yet I haven't really heard any other'much better' solutions. Some comments below on Mitchell's last post.. On Tue, 11 Feb 2003 10:20:52 -0500 "Mitchell Morris" <[EMAIL PROTECTED]> wrote: > > > #1) Create a custom tag library to share an application-wide > > > cached value of the order list, and populate the list into scope: > [snip] > > > > This is probably a pretty good solution, although doesn't this go > > against the thought of all the objects to display should be set > > up before you even reach the JSP page? Basically now your JSP > > page is doing business logic. > > Ooooh ... philosophical purity! I seen some of that once! I'm not > entirely sure where the objection lies here, because the view object > (JSP) isn't directly manipulating the model object (order list), but > rather is intermediated by a controller object (tag library). Seems to > me the MVC purity is being maintained. On the other hand, I might be > wrong. At least it isn't a scriptlet. Trust me I'm not against using a tag to do it in the JSP page, I'm just wondering how this is any "more pure/better" than just setting the list back up in the reset method? > > One solution I thought might work is every time the list was > > updated to > > the db I'd make sure to get a new cached copy and put that into > > application scope which all the user's cold have. This would > > be a great > > option except this list could be very specific to a > > particular user- it > > wouldn't work well in application scope because of this since > > the lists > > could vary depending on the user logged in. > > Well, you could certainly go with this scheme even in a user-specific > case. The tag library would need to interact with the other model > objects in session scope to coordinate the user's identity and thus to > extract/cache the correct order list. It's starting to look icky, > though, so you might now like choice #2 better. Yes, very icky I think. Better would be for each user's session to hold this list data or repopulate this list (where/when?) before getting back to the form upon validation errors. > > > #2) Have an Action populate the list into the Form before > > > forwarding to the display page. The chain starts with your action, > > > which can implement your desired caching scheme for the list of > > > orders, then displays the JSP. The JSP submits back to an action, > > > which > > can restart > > > the cycle. > > > > That's currently what I do but the problem I'm running into is when > > validation returns false. How/where is the list going to be > > repopulated > > before it returns back to the jsp form page? The reset method > > seems like > > the best place but maybe I'm wrong? > This means that I've been wrong all along, and the options collection > shouldn't have been in the form at all, but should be in session > scope. I'd still have the action->jsp->action chain, but the first > action should make sure the correct list object is in session scope > instead of putting it into the form. Yes, actually I never did put the list into the form bean but had initially put the list in request scope. Now we've come full circle:) We're back to the beginning where it seems the choices seem to come down to: 1) putting the list into session scope (the list will reset when the user hits the setUpAction on another request to do this type of action). or 2) put the list into request scope and repopulate this list when reset is called. -- Rick Reumann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: still wondering Re: Where to repopulate dynamic lists ?
> > #1) Create a custom tag library to share an application-wide cached > > value of the order list, and populate the list into scope: [snip] > > This is probably a pretty good solution, although doesn't this go > against the thought of all the objects to display should be set > up before you even reach the JSP page? Basically now your JSP > page is doing business logic. Ooooh ... philosophical purity! I seen some of that once! I'm not entirely sure where the objection lies here, because the view object (JSP) isn't directly manipulating the model object (order list), but rather is intermediated by a controller object (tag library). Seems to me the MVC purity is being maintained. On the other hand, I might be wrong. At least it isn't a scriptlet. > One solution I thought might work is every time the list was > updated to > the db I'd make sure to get a new cached copy and put that into > application scope which all the user's cold have. This would > be a great > option except this list could be very specific to a > particular user- it > wouldn't work well in application scope because of this since > the lists > could vary depending on the user logged in. Well, you could certainly go with this scheme even in a user-specific case. The tag library would need to interact with the other model objects in session scope to coordinate the user's identity and thus to extract/cache the correct order list. It's starting to look icky, though, so you might now like choice #2 better. > > #2) Have an Action populate the list into the Form before forwarding > > to the display page. The chain starts with your action, which can > > implement your desired caching scheme for the list of orders, then > > displays the JSP. The JSP submits back to an action, which > can restart > > the cycle. > > That's currently what I do but the problem I'm running into is when > validation returns false. How/where is the list going to be > repopulated > before it returns back to the jsp form page? The reset method > seems like > the best place but maybe I'm wrong? Previously, when doing these kinds of things, I'd cheat by not clearing the order list in the form.reset() method. In trying to make sure I wasn't misleading you, I just verified (by reading the source: RequestProcessor.java) when form.reset() gets called, and it's just before the parameters are populated into the form bean from the current request, which is just before validation takes place. This means if there were more than one form bean, there's no guarantee that you'd get the same one for both views of the input page (before and after failing validation). I don't see any way to get more than one right now, but that doesn't mean that there won't be "form bean pooling" in the next iteration. This means that I've been wrong all along, and the options collection shouldn't have been in the form at all, but should be in session scope. I'd still have the action->jsp->action chain, but the first action should make sure the correct list object is in session scope instead of putting it into the form. maybe-no-progress-but-the-running's-worth-something-ly y'rs, +Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
