Re: Where to build dropdown lists?
Because it depends on how dynamic the list is. I only have a few things which are so unchanging from user to user and screen to screen that they can go in application scope. But I use the same mechanism for the objects in request scope that are lists which depend on an ID or something and so change from request to request. One of the parameters to the method takes an int which could be any of PageContext.APPLICATION_SCOPE, SESSION_SCOPE or REQUEST_SCOPE. Adam Rick Reumann wrote: On Tue, Jul 15,'03 (04:04 PM GMT+0200), Adam wrote: Since it's in my action base class, I never have to worry about programming it manually. If you are always going to check that the List is there in your BaseAction class, why not just give the List application scope on start up and not have to worry about checking for it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to build dropdown lists?
I have not personally used scaffolding, but by separating your business logic from your display logic you gain advantages. Scaffolding's business beans automatically populate to certain scopes. You can have many of them per action-mapping. By going to a different mapping, but having the request scoped beans populated by the same business routines will solve this problem. sandeep --- Rick Reumann [EMAIL PROTECTED] wrote: On Tue, Jul 15,'03 (01:56 PM GMT-0100), Dichotomy wrote: My solution, which is perhaps not the most efficient memory-wise, is to simply put it in (and retrieve it from) the session rather than the request. I agree this is the best solution (using Session or Application scope). I brought this topic up a long time ago and ultimately you really have to use Session or Application scope if you plan to use Validation (or else settle for headaches getting it to work correctly with Request scope). If you use just Request scope you end up having to do some'crazier'(aka annoying) things to get the lists of beans for the drop downs to reset when validation fails. Search of the archives if you insist on using Request scope for the form lists and you'll find ways to do it, but none of them seemed worth the hassle(imo). If someone out there still has a nice clean way to get these request scope Lists back in scope after validation fails, I'd be interested in your solution. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Where to build dropdown lists?
Sorry if this is a stupid question, but any help is much appreciated! I have some drop down lists that I populate in my action class, which means I call myPage.do each time. This was working nicely, until I tried adding some validation. If this fails the action class is not called and then when the page tries to find the bean containing the list for the drop down it does not exist! Previously we built the lists in the reset function in the form class, but I was wanting to move all the code out of here with the idea of using the dyna forms. So I was wanting to know, is my only option to build my dropdowns as part of my reset functions? Thanks for any help IV - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where to build dropdown lists?
Need help here too. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 4:52 PM To: [EMAIL PROTECTED] Subject: Where to build dropdown lists? Sorry if this is a stupid question, but any help is much appreciated! I have some drop down lists that I populate in my action class, which means I call myPage.do each time. This was working nicely, until I tried adding some validation. If this fails the action class is not called and then when the page tries to find the bean containing the list for the drop down it does not exist! Previously we built the lists in the reset function in the form class, but I was wanting to move all the code out of here with the idea of using the dyna forms. So I was wanting to know, is my only option to build my dropdowns as part of my reset functions? Thanks for any help IV - 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 build dropdown lists?
hi, u can set the collection objectas the request attribute for the first time in the action class. so as long u use the same request , u will not need to repopulate the list again. reset is not the right place to populate ur dropdowns -- nagi ---Original Message--- From: Struts Users Mailing List Date: Tuesday, July 15, 2003 02:22:41 PM To: [EMAIL PROTECTED] Subject: Where to build dropdown lists? Sorry if this is a stupid question, but any help is much appreciated!I have some drop down lists that I populate in my action class, which means I call myPage.do each time. This was working nicely, until I tried adding some validation. If this fails the action class is not called and then when the page tries to find the bean containing the list for the drop down it does not exist! Previously we built the lists in the reset function in the form class, but I was wanting to move all the code out of here with the idea of using the dyna forms.So I was wanting to know, is my only option to build my dropdowns as part of my reset functions?Thanks for any helpIV-To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]. IncrediMail - Email has finally evolved - Click Here
Re: Where to build dropdown lists?
OK, another stupid question then! How do I ensure I use the same request? (Sorry my servlet programming isn't as good as it should be! Infact all my programming isn't!) Thanks IV from:Nagendra Kumar O V S [EMAIL PROTECTED] date:Tue, 15 Jul 2003 11:19:10 to: [EMAIL PROTECTED] subject: Re: Where to build dropdown lists? hi, u can set the collection object as the request attribute for the first time in the action class. so as long u use the same request , u will not need to repopulate the list again. reset is not the right place to populate ur dropdowns -- nagi ---Original Message--- From: Struts Users Mailing List Date: Tuesday, July 15, 2003 02:22:41 PM To: [EMAIL PROTECTED] Subject: Where to build dropdown lists? Sorry if this is a stupid question, but any help is much appreciated! I have some drop down lists that I populate in my action class, which means I call myPage.do each time. This was working nicely, until I tried adding some validation. If this fails the action class is not called and then when the page tries to find the bean containing the list for the drop down it does not exist! Previously we built the lists in the reset function in the form class, but I was wanting to move all the code out of here with the idea of using the dyna forms. So I was wanting to know, is my only option to build my dropdowns as part of my reset functions? Thanks for any help IV - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . http://www.amazon.co.uk/exec/obidos/redirect-home?tag=velloscouk-21placement=home_multi.gifsite=amazon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to build dropdown lists?
My solution, which is perhaps not the most efficient memory-wise, is to simply put it in (and retrieve it from) the session rather than the request. Then when I do go through the populating action, if this is a list that is liable to change often I reload it from the database. If it is a fairly static list I just check if it's already there and do nothing if it is. I guess an even better solution (for a general-usage list) would be to put it in the application-wide context, so you load it once for all users (if it's really very static). That solves the memory usage issue, and even if it's non-static you can work around the problem by making sure that you reload the list application-wide whenever it is changed. -- If education is too expensive, try ignorance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to build dropdown lists?
I designed a system where I can specify in my action which dropdown lists I require with a method call. I route my failed validate requests thro' the action (using the action mapping input tag) every time so the call is always made, and if I specified it should be in the request, the system looks in the request for the collection and if it doesn't find it, it makes it. Same applies to with session and application requirements. Having stuff in the session is not necessarily good, if the user decides to open more than one window. Adam Dichotomy wrote: My solution, which is perhaps not the most efficient memory-wise, is to simply put it in (and retrieve it from) the session rather than the request. Then when I do go through the populating action, if this is a list that is liable to change often I reload it from the database. If it is a fairly static list I just check if it's already there and do nothing if it is. I guess an even better solution (for a general-usage list) would be to put it in the application-wide context, so you load it once for all users (if it's really very static). That solves the memory usage issue, and even if it's non-static you can work around the problem by making sure that you reload the list application-wide whenever it is changed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to build dropdown lists?
On Tue, Jul 15,'03 (01:56 PM GMT-0100), Dichotomy wrote: My solution, which is perhaps not the most efficient memory-wise, is to simply put it in (and retrieve it from) the session rather than the request. I agree this is the best solution (using Session or Application scope). I brought this topic up a long time ago and ultimately you really have to use Session or Application scope if you plan to use Validation (or else settle for headaches getting it to work correctly with Request scope). If you use just Request scope you end up having to do some'crazier'(aka annoying) things to get the lists of beans for the drop downs to reset when validation fails. Search of the archives if you insist on using Request scope for the form lists and you'll find ways to do it, but none of them seemed worth the hassle(imo). If someone out there still has a nice clean way to get these request scope Lists back in scope after validation fails, I'd be interested in your solution. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to build dropdown lists?
On Tue, Jul 15,'03 (02:32 PM GMT+0200), Adam wrote: I designed a system where I can specify in my action which dropdown lists I require with a method call. I route my failed validate requests thro' the action (using the action mapping input tag) every time so the call is always made, and if I specified it should be in the request, the system looks in the request for the collection and if it doesn't find it, it makes it. Same applies to with session and application requirements. This did seem like the best solution if you insist on using request scope for your Lists on a form. It's still sort of a pain though because now don't you have to code for checking validation success in your Action class method(s) (execute or dispatch methods)? Seems like a lot of the power of the validation framework is you can control it all from config files and your Actions don't even have to worry about it. If insistence on request scope is mandatory, I think this above solution is the best one I've come across. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to build dropdown lists?
Rick Reumann [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Tue, Jul 15,'03 (01:56 PM GMT-0100), Dichotomy wrote: My solution, which is perhaps not the most efficient memory-wise, is to simply put it in (and retrieve it from) the session rather than the request. I agree this is the best solution (using Session or Application scope). I brought this topic up a long time ago and ultimately you really have to use Session or Application scope if you plan to use Validation (or else settle for headaches getting it to work correctly with Request scope). If you use just Request scope you end up having to do some'crazier'(aka annoying) things to get the lists of beans for the drop downs to reset when validation fails. Search of the archives if you insist on using Request scope for the form lists and you'll find ways to do it, but none of them seemed worth the hassle(imo). If someone out there still has a nice clean way to get these request scope Lists back in scope after validation fails, I'd be interested in your solution. -- Rick What about the client side validation feature in the validator framework. This way the you won't have to populate the list at all if validation happens to fail because the form will not post unless it's valid. Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to build dropdown lists?
When using the client side validation, there is always a javascript pop up box that says something along the lines of 'Your a thick b*stard, fill in xxx!' Our client requirement is that we produce a list of errors at the top of the page, (the red UL kinda thing), which rules out the use of these java script pop ups. Another thing that I noticed when playing with the JavaScript pop ups was that all the validator JavaScript, whether used or not is included in the JSP code. I ende up with hundreds of lines of JavaScript, including date, email and phone number validation, for a login for that had two elements? Is this the way it should work? Thanks again IV from:Dennis [EMAIL PROTECTED] date:Tue, 15 Jul 2003 13:42:34 to: [EMAIL PROTECTED] subject: Re: Where to build dropdown lists? Rick Reumann [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Tue, Jul 15,'03 (01:56 PM GMT-0100), Dichotomy wrote: My solution, which is perhaps not the most efficient memory-wise, is to simply put it in (and retrieve it from) the session rather than the request. I agree this is the best solution (using Session or Application scope). I brought this topic up a long time ago and ultimately you really have to use Session or Application scope if you plan to use Validation (or else settle for headaches getting it to work correctly with Request scope). If you use just Request scope you end up having to do some'crazier'(aka annoying) things to get the lists of beans for the drop downs to reset when validation fails. Search of the archives if you insist on using Request scope for the form lists and you'll find ways to do it, but none of them seemed worth the hassle(imo). If someone out there still has a nice clean way to get these request scope Lists back in scope after validation fails, I'd be interested in your solution. -- Rick What about the client side validation feature in the validator framework. This way the you won't have to populate the list at all if validation happens to fail because the form will not post unless it's valid. Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://www.amazon.co.uk/exec/obidos/redirect-home?tag=velloscouk-21placement=home_multi.gifsite=amazon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to build dropdown lists?
On 07/15/2003 08:47:14 AM Rick Reumann wrote: On Tue, Jul 15,'03 (02:32 PM GMT+0200), Adam wrote: I designed a system where I can specify in my action which dropdown lists I require with a method call. I route my failed validate requests thro' the action (using the action mapping input tag) every time so the call is always made, and if I specified it should be in the request, the system looks in the request for the collection and if it doesn't find it, it makes it. Same applies to with session and application requirements. This did seem like the best solution if you insist on using request scope for your Lists on a form. It's still sort of a pain though because now don't you have to code for checking validation success in your Action class method(s) (execute or dispatch methods)? Seems like a lot of the power of the validation framework is you can control it all from config files and your Actions don't even have to worry about it. If insistence on request scope is mandatory, I think this above solution is the best one I've come across. -- Rick I also use a method call to retrieve my dropdown lists, but I gave up using an action as the input mapping parameter. I didn't see how I could implement it without putting a returning from validation check in there somewhere, and those particular setup actions have become complex enough already. I resorted to calling validate() manually in the save actions. Good or bad, it works well for my application. Susan - 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 build dropdown lists?
On Tuesday 15 July 2003 12:52, [EMAIL PROTECTED] wrote: Hi, Another thing that I noticed when playing with the JavaScript pop ups was that all the validator JavaScript, whether used or not is included in the JSP code. I ende up with hundreds of lines of JavaScript, including date, email and phone number validation, for a login for that had two elements? Is this the way it should work? Look at the... html:javascript staticJavascript=false ..tag. Phil -- 1:11pm up 90 days, 2:03, 1 user, load average: 0.41, 0.14, 0.04 ICQ: 760757 AIM: pjshrimpton Y!: pjshrimpton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to build dropdown lists?
Client-side validation is a useful gimmick at best. I certainly would not trust it in any web application which will have more than one user (me). It is far too easy to get around (eg disable javascript?). -- If education is too expensive, try ignorance. On Tue, 15 Jul 2003 14:42:34 +0200 Dennis [EMAIL PROTECTED] wrote: What about the client side validation feature in the validator framework. This way the you won't have to populate the list at all if validation happens to fail because the form will not post unless it's valid. Dennis - 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 build dropdown lists?
Susan Bradeen wrote: I also use a method call to retrieve my dropdown lists, but I gave up using an action as the input mapping parameter. I didn't see how I could implement it without putting a returning from validation check in there somewhere, and those particular setup actions have become complex enough already. I resorted to calling validate() manually in the save actions. Good or bad, it works well for my application. I set up an action mapping called failedValidate and gave it a parameter finished - this would set an action token variable in the app's action base class. I programmed it so the action token is always one of display / insert / update / delete / other / finished. In the case of finished, nothing happens. In all cases though, the base class makes sure the dropdown collection is there. Since it's in my action base class, I never have to worry about programming it manually. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to build dropdown lists?
On 07/15/2003 10:04:13 AM Adam Hardy wrote: Susan Bradeen wrote: I also use a method call to retrieve my dropdown lists, but I gave up using an action as the input mapping parameter. I didn't see how I could implement it without putting a returning from validation check in there somewhere, and those particular setup actions have become complex enough already. I resorted to calling validate() manually in the save actions. Good or bad, it works well for my application. I set up an action mapping called failedValidate and gave it a parameter finished - this would set an action token variable in the app's action base class. I programmed it so the action token is always one of display / insert / update / delete / other / finished. In the case of finished, nothing happens. In all cases though, the base class makes sure the dropdown collection is there. Since it's in my action base class, I never have to worry about programming it manually. Ah ha. This sounds good. Thanks very much for the ideas, Adam. Susan - 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 build dropdown lists?
[EMAIL PROTECTED] wrote: When using the client side validation, there is always a javascript pop up box that says something along the lines of 'Your a thick b*stard, fill in xxx!' Our client requirement is that we produce a list of errors at the top of the page, (the red UL kinda thing), which rules out the use of these java script pop ups. You don't *have* to use popups. You can always manipulate the document using the DOM to present a less obnoxious warning. http://erikprice.com/clientvalidation.html Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to build dropdown lists?
On Tue, Jul 15,'03 (04:04 PM GMT+0200), Adam wrote: Since it's in my action base class, I never have to worry about programming it manually. If you are always going to check that the List is there in your BaseAction class, why not just give the List application scope on start up and not have to worry about checking for it? -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
