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 ?
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 ofOrder 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? snip 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
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 html:errors/ 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 ofOrder 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?
snip
This means that I've been wrong all along, and the options
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 html:errors/
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 ofOrder 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
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 ofOrder 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 ?
#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]
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 ofOrder 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? snip 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: Where to repopulate dynamic lists ?
This topic seems to keep coming up, and with no real good solutions
(IMHO). One point that seems to be made frequently though, is that the
logic to repopulate the lists really doesn't belong in the ActionForm,
yet that seems to be the most convenient place to put it. I know I would
really like this logic to go in the Action. My solution currently
consists of setting validate to false in struts-config.xml, and
validating manually in my action:
ActionErrors errors = myForm.validate();
if (hasErrors(errors)) {
populateLists();
saveErrors(errors);
return getInputForward(mapping);
}
Although I don't particularly like this approach either, it's the one I
like the best (so far).
One idea I had (and tried to implement) was to put a callback in the
Action that was invoked after validation failure, but before forwarding
to the input view? What do others think of this approach? What other
solutions are there?
Joe
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 10, 2003 3:58 AM
To: Struts Users Mailing List
Subject: Where to repopulate dynamic lists ?
Sorry to repost this question but it still has me wondering...
Say you have a form where a user is to select An Order To
Update from an options list. Now also assume that these
orders to choose from change very frequently. You also will
need to validate the form when it's submitted.
* Where is it best to repopulate this type of dynamic list
(example above: 'orders')? The list of orders that make up
the options list needs to be repopulated somewhere in case
validation returns false and returns the user to the form
page again.
It seems like you have three choices:
1) In the reset method repopulate the list by making a call
to business layer to get back your list and put in scope (or
maybe even directly into FormBean).
2) Use session scope so the list is available at all times
until repopulated by some setUp type of action.
3) Possibly set this list in application scope upon container
start up and maybe have a thread running that periodically
updates the list and put the new list back into application scope.
Are there any other options available? I happen to like #1
the best but I'm wondering what others think. I don't really
like option 2 as it requires a form to be put into session
scope that really doesn't need to be there (apart from the
re-population of lists). Also a pain to monitor cleaning the
form out of session when it is no longer needed. Option 3
would be ok if the information in the list rarely changed,
but if it's data that changes very frequently I wouldn't want
to rely on some time interval to have to go by before getting
fresh data.
Curious what other's thoughts are on this situation.
Thanks,
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to repopulate dynamic lists ?
On Mon, 10 Feb 2003 10:16:26 -0500
Joseph Fifield [EMAIL PROTECTED] wrote:
This topic seems to keep coming up, and with no real good solutions
(IMHO). One point that seems to be made frequently though, is that the
logic to repopulate the lists really doesn't belong in the ActionForm,
yet that seems to be the most convenient place to put it. I know I
would really like this logic to go in the Action. My solution
currently consists of setting validate to false in struts-config.xml,
and validating manually in my action:
ActionErrors errors = myForm.validate();
if (hasErrors(errors)) {
populateLists();
saveErrors(errors);
return getInputForward(mapping);
}
I'm not sure how all of this would work using DynaValidatorForm and
DispatchAction which I'm using. It seems so simple to just have the
method BusinessLayer.populateLists() in the reset method of a form bean
that your DynaValidatorForm extends. I'll have to look into using your
approach using the built in validation and see if I could get it to
work.
Although I don't particularly like this approach either, it's the one
I like the best (so far).
One idea I had (and tried to implement) was to put a callback in the
Action that was invoked after validation failure, but before
forwarding to the input view? What do others think of this approach?
What other solutions are there?
Joe
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 10, 2003 3:58 AM
To: Struts Users Mailing List
Subject: Where to repopulate dynamic lists ?
Sorry to repost this question but it still has me wondering...
Say you have a form where a user is to select An Order To
Update from an options list. Now also assume that these
orders to choose from change very frequently. You also will
need to validate the form when it's submitted.
* Where is it best to repopulate this type of dynamic list
(example above: 'orders')? The list of orders that make up
the options list needs to be repopulated somewhere in case
validation returns false and returns the user to the form
page again.
It seems like you have three choices:
1) In the reset method repopulate the list by making a call
to business layer to get back your list and put in scope (or
maybe even directly into FormBean).
2) Use session scope so the list is available at all times
until repopulated by some setUp type of action.
3) Possibly set this list in application scope upon container
start up and maybe have a thread running that periodically
updates the list and put the new list back into application scope.
Are there any other options available? I happen to like #1
the best but I'm wondering what others think. I don't really
like option 2 as it requires a form to be put into session
scope that really doesn't need to be there (apart from the
re-population of lists). Also a pain to monitor cleaning the
form out of session when it is no longer needed. Option 3
would be ok if the information in the list rarely changed,
but if it's data that changes very frequently I wouldn't want
to rely on some time interval to have to go by before getting
fresh data.
Curious what other's thoughts are on this situation.
Thanks,
--
Rick
--
Rick Reumann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where to repopulate dynamic lists ?
I don't know if the manual approach will work in that case or not. It
will be interesting to find out though.
For my callback approach, I tried extending from RequestProcessor, which
should have the advantage of working with the built in struts validation
schemes. I was not successful at finding a good hook point to make the
callback though. I needed the hook between the validation itself, and
the forward to the input view, both of which are handled in the
processValidate method.
If someone else sees a way to hook into the RequestProcessor to handle
this, I'd love to hear how!
Joe
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 10, 2003 5:51 PM
To: Struts Users Mailing List
Subject: Re: Where to repopulate dynamic lists ?
On Mon, 10 Feb 2003 10:16:26 -0500
Joseph Fifield [EMAIL PROTECTED] wrote:
This topic seems to keep coming up, and with no real good solutions
(IMHO). One point that seems to be made frequently though,
is that the
logic to repopulate the lists really doesn't belong in the
ActionForm,
yet that seems to be the most convenient place to put it. I know I
would really like this logic to go in the Action. My solution
currently consists of setting validate to false in
struts-config.xml,
and validating manually in my action:
ActionErrors errors = myForm.validate();
if (hasErrors(errors)) {
populateLists();
saveErrors(errors);
return getInputForward(mapping);
}
I'm not sure how all of this would work using
DynaValidatorForm and DispatchAction which I'm using. It
seems so simple to just have the method
BusinessLayer.populateLists() in the reset method of a form
bean that your DynaValidatorForm extends. I'll have to look
into using your approach using the built in validation and
see if I could get it to work.
Although I don't particularly like this approach either,
it's the one
I like the best (so far).
One idea I had (and tried to implement) was to put a
callback in the
Action that was invoked after validation failure, but before
forwarding to the input view? What do others think of this
approach?
What other solutions are there?
Joe
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 10, 2003 3:58 AM
To: Struts Users Mailing List
Subject: Where to repopulate dynamic lists ?
Sorry to repost this question but it still has me wondering...
Say you have a form where a user is to select An Order To
Update from an options list. Now also assume that these
orders to choose from change very frequently. You also will
need to validate the form when it's submitted.
* Where is it best to repopulate this type of dynamic list
(example above: 'orders')? The list of orders that make up
the options list needs to be repopulated somewhere in case
validation returns false and returns the user to the form
page again.
It seems like you have three choices:
1) In the reset method repopulate the list by making a call
to business layer to get back your list and put in scope (or
maybe even directly into FormBean).
2) Use session scope so the list is available at all times
until repopulated by some setUp type of action.
3) Possibly set this list in application scope upon container
start up and maybe have a thread running that periodically
updates the list and put the new list back into application scope.
Are there any other options available? I happen to like #1
the best but I'm wondering what others think. I don't really
like option 2 as it requires a form to be put into session
scope that really doesn't need to be there (apart from the
re-population of lists). Also a pain to monitor cleaning the
form out of session when it is no longer needed. Option 3
would be ok if the information in the list rarely changed,
but if it's data that changes very frequently I wouldn't want
to rely on some time interval to have to go by before getting
fresh data.
Curious what other's thoughts are on this situation.
Thanks,
--
Rick
--
Rick Reumann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where to repopulate dynamic lists ?
Just to show there's more than one way to skin a cat:
#1) Create a custom tag library to share an application-wide cached value of
the order list, and populate the list into scope:
### in your custom tag handler
public int doStart() {
if(cacheNeedsRebuilding()) {
List orderList = buildCache();
pageContext.setAttribute(net.reumann.appl.cache.orderList,
orderList,
pageContext.APPLICATION_SCOPE);
}
return Tag.SKIP_BODY;
}
### in your JSP
myTagLib:checkCache/
html:select property=order
html:optionsCollection name=net.reumann.appl.cache.orderList/
/html:select
#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.
### in struts-config.xml
action path=/prepareForm
type=net.reumann.appl.MyAction
name=formBean
input=/display.jsp
validate=false
parameter=prepare
forward name=next path=/display.jsp/
/action
action path=/handleForm
type=net.reumann.appl.MyAction
name=formBean
input=/display.jsp
validate=true
parameter=handle
forward name=next path=/do/prepareForm/
/action
### in net.reumann.appl.MyAction.java
public ActionForward execute(ActionMapping mapping, ActionForm theForm,
...) {
String param = mapping.getParameter();
if(param.equals(prepare)) {
return doPrepare(mapping, theForm, ...);
} else if(param.equals(handle)) {
return doHandle(mapping, theForm, ...);
} else {
throw new ServletException(bad param [ + param + ]:
struts-config.xml is b0rken);
}
}
public ActionForward doPrepare(ActionMapping mapping, ActionForm theForm,
...) {
FormBean form = (FormBean)theForm;
form.setOrderChoices(getCachedOrders());
return mapping.findForward(next);
}
public ActionForward doHandle(ActionMapping mapping, ActionForm theForm,
...) {
FormBean form = (FormBean)theForm;
// Do all the heavy lifting here
return mapping.findForward(next);
}
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 10, 2003 3:58 AM
To: Struts Users Mailing List
Subject: Where to repopulate dynamic lists ?
Sorry to repost this question but it still has me wondering...
Say you have a form where a user is to select An Order To
Update from
an options list. Now also assume that these orders to choose
from change
very frequently. You also will need to validate the form when it's
submitted.
* Where is it best to repopulate this type of dynamic list
(example above: 'orders')? The list of orders that make up the
options list needs to be repopulated somewhere in case validation
returns false and returns the user to the form page again.
It seems like you have three choices:
1) In the reset method repopulate the list by making a call
to business
layer to get back your list and put in scope (or maybe even directly
into FormBean).
2) Use session scope so the list is available at all times until
repopulated by some setUp type of action.
3) Possibly set this list in application scope upon container start up
and maybe have a thread running that periodically updates the list and
put the new list back into application scope.
Are there any other options available? I happen to like #1
the best but
I'm wondering what others think. I don't really like option 2 as it
requires a form to be put into session scope that really
doesn't need to
be there (apart from the re-population of lists). Also a pain
to monitor
cleaning the form out of session when it is no longer needed. Option 3
would be ok if the information in the list rarely changed, but if it's
data that changes very frequently I wouldn't want to rely on some time
interval to have to go by before getting fresh data.
Curious what other's thoughts are on this situation.
Thanks,
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
still wondering Re: Where to repopulate dynamic lists ?
Thanks for the feedback. Some comments below. Remember the problem isn't with setting up the list into scope from an Action, it's what to do when validation takes place and the validation returns false returning you back to the initial jsp page. On Mon, Feb 10,'03 (10:38 PM GMT-0500), Mitchell wrote: Just to show there's more than one way to skin a cat: #1) Create a custom tag library to share an application-wide cached value of the order list, and populate the list into scope: snip ### in your JSP myTagLib:checkCache/ html:select property=order html:optionsCollection name=net.reumann.appl.cache.orderList/ /html:select 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. 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. #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? Thanks for the help, -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
