Re: Struts Design Issue - Search Functionality - Best Practices
I prefer to use nested form bean properties to contain search results, instead of a bunch of form beans stored in the http session/request object. The nested form bean properties could be String[], List, Map, or compound properties containing other simple or compound properties. In our project Wheels, if we want to release the search results in nested properties, just do it on the root form bean with a method call bean.releaseProperty(). When a form bean is fairly complicated, it is better to store the form bean in user's http session. In the past, people do not have enough memories on their hardware, now this is not a problem in most cases. On the other hand, request scoped form beans demand the following operations on every http request: - CPU time to allocate memories. - CPU time to do GC (in an asynchronous way, but could have severe impact to overall system performance) Even a JVM could implement the operations using C++/C, the CPU time could still be greater than, in magnitudes, the time to find an existing form bean. Jing Netspread Carrier http://www.netspread.com - Original Message - From: "Chawla, Yogesh" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Sent: Friday, September 26, 2003 9:13 AM Subject: RE: Struts Design Issue - Search Functionality - Best Practices > Some more comments required from Struts Gurus ! > > I also needed to know if you would be sending a Collection/Vector of Form > Beans which are populated with the fields for display or you would be > sending one Form Bean which contains String[]/Vector of fields returned from > the DB. > > This seems to be a good option mentioned below but I would also appreciate > more feedbacks from other Struts Users > > Thanks. > > -Original Message- > From: Paul McCulloch [mailto:[EMAIL PROTECTED] > Sent: Friday, September 26, 2003 3:30 PM > To: 'Struts Users Mailing List' > Subject: RE: Struts Design Issue - Search Functionality - Best Practices > > > My aproach is as follows: > > Each form bean property which can be searched is a descendant of > SearchableProperty. A SearchableProperty consists of: > > *A String value representing the user's input > *The selected business entity (if the user has selected one) > *An object descended from Lookup, which implements the associated search > functionality > > I have a base form & dispatch action. > > The base action contains methods which are called to show the search screen; > do a search ;use a searched value etc. > > The base form contains hidden fields, populated via javascript, which tell > the dispatch action which property the search function is being invoked for, > and other 'paramaters' such as the id of a selected record. > > The view of my application uses the struts nested tags, and JSP includes to > provide reuseable components to render a SearchableProperty and it's > associated search view. The search view is part of the same page - the app > only ever uses one browser window, with no frames. > > The upside of this approach is that I can place, with little effort, > sophisticated searching functions anywhere is the app. Due to the inclusion > of the user selected business entity behind the scenes, my view can display > any properties of the selected entity, without a change to the form bean. > > The downside of this is that the form bean must be stored in session scope. > I have done a bit of load testing and it didn't seem to be a problem, but I > didn't have much to compare with - this is my first Struts app. > > So, that's the approach I use. I've no idea how that compares to the best > practices out there, nut I'm eager to find out! > > Paul > > -Original Message- > From: Chawla, Yogesh [mailto:[EMAIL PROTECTED] > Sent: 26 September 2003 08:19 > To: 'Struts Users Mailing List' > Subject: Struts Design Issue - Search Functionality - Best Practices > Importance: High > > > Hi, > > Design Requirement - Show a list of Search records. The screen will have > buttons for Previous/Next Month. On clicking these records would be shown. > > Issues - > > a) How to store data and best practices to be followed in Struts. Return > back a Collection of Form Beans and iterate over these. However certain > other fields are required to be stored also which are not displayable. i.e. > Current Date which is a hidden parameter. Any comments ? > > b) Use a single Form Bean which has variables like String[] to store the > array of Displayable Fields. However, this seems to be a less than perfect > solution. Any comments ??? > > c) Use Generic Search - Search on differen
RE: Struts Design Issue - Search Functionality - Best Practices
Some more comments required from Struts Gurus ! I also needed to know if you would be sending a Collection/Vector of Form Beans which are populated with the fields for display or you would be sending one Form Bean which contains String[]/Vector of fields returned from the DB. This seems to be a good option mentioned below but I would also appreciate more feedbacks from other Struts Users Thanks. -Original Message- From: Paul McCulloch [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2003 3:30 PM To: 'Struts Users Mailing List' Subject: RE: Struts Design Issue - Search Functionality - Best Practices My aproach is as follows: Each form bean property which can be searched is a descendant of SearchableProperty. A SearchableProperty consists of: *A String value representing the user's input *The selected business entity (if the user has selected one) *An object descended from Lookup, which implements the associated search functionality I have a base form & dispatch action. The base action contains methods which are called to show the search screen; do a search ;use a searched value etc. The base form contains hidden fields, populated via javascript, which tell the dispatch action which property the search function is being invoked for, and other 'paramaters' such as the id of a selected record. The view of my application uses the struts nested tags, and JSP includes to provide reuseable components to render a SearchableProperty and it's associated search view. The search view is part of the same page - the app only ever uses one browser window, with no frames. The upside of this approach is that I can place, with little effort, sophisticated searching functions anywhere is the app. Due to the inclusion of the user selected business entity behind the scenes, my view can display any properties of the selected entity, without a change to the form bean. The downside of this is that the form bean must be stored in session scope. I have done a bit of load testing and it didn't seem to be a problem, but I didn't have much to compare with - this is my first Struts app. So, that's the approach I use. I've no idea how that compares to the best practices out there, nut I'm eager to find out! Paul -Original Message- From: Chawla, Yogesh [mailto:[EMAIL PROTECTED] Sent: 26 September 2003 08:19 To: 'Struts Users Mailing List' Subject: Struts Design Issue - Search Functionality - Best Practices Importance: High Hi, Design Requirement - Show a list of Search records. The screen will have buttons for Previous/Next Month. On clicking these records would be shown. Issues - a) How to store data and best practices to be followed in Struts. Return back a Collection of Form Beans and iterate over these. However certain other fields are required to be stored also which are not displayable. i.e. Current Date which is a hidden parameter. Any comments ? b) Use a single Form Bean which has variables like String[] to store the array of Displayable Fields. However, this seems to be a less than perfect solution. Any comments ??? c) Use Generic Search - Search on different modules, with different fields ? Any Brilliant Guru contributions for this one..Sure need some wizard out here... Pls. advise on the best approach for the Search functionality. We need to design an application which has Search on each and every page. Thanks for your time , Regards, Yogesh DISCLAIMER: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** Axios Email Confidentiality Footer Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message, and notify us immediately. If you or your employer does not consent to Internet email messages of this kind, please advise us immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by my Company or employer unless otherwise indicated by an authorised representative independent of this message. WARNING: While Axios Systems Ltd takes steps to prevent computer viruses from being transmitted via electronic mail attachments we cannot gu
RE: Struts Design Issue - Search Functionality - Best Practices
I believe this feature is implemented in struts-layout http://struts.application-servers.com/ Edgar > -Original Message- > From: Chawla, Yogesh [mailto:[EMAIL PROTECTED] > Sent: Friday, September 26, 2003 2:19 AM > To: 'Struts Users Mailing List' > Subject: Struts Design Issue - Search Functionality - Best Practices > > > Hi, > > Design Requirement - Show a list of Search records. The > screen will have buttons for Previous/Next Month. On clicking > these records would be shown. > > Issues - > > a) How to store data and best practices to be followed in > Struts. Return back a Collection of Form Beans and iterate > over these. However certain other fields are required to be > stored also which are not displayable. i.e. Current Date > which is a hidden parameter. Any comments ? > > b) Use a single Form Bean which has variables like String[] > to store the array of Displayable Fields. However, this seems > to be a less than perfect solution. Any comments ??? > > c) Use Generic Search - Search on different modules, with > different fields ? Any Brilliant Guru contributions for this > one..Sure need some wizard out here... > > Pls. advise on the best approach for the Search > functionality. We need to design an application which has > Search on each and every page. > > Thanks for your time , > > Regards, > > Yogesh > DISCLAIMER: The information in this message is confidential > and may be legally privileged. It is intended solely for the > addressee. Access to this message by anyone else is > unauthorised. If you are not the intended recipient, any > disclosure, copying, or distribution of the message, or any > action or omission taken by you in reliance on it, is > prohibited and may be unlawful. Please immediately contact > the sender if you have received this message in error. Thank you. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Design Issue - Search Functionality - Best Practices
My aproach is as follows: Each form bean property which can be searched is a descendant of SearchableProperty. A SearchableProperty consists of: *A String value representing the user's input *The selected business entity (if the user has selected one) *An object descended from Lookup, which implements the associated search functionality I have a base form & dispatch action. The base action contains methods which are called to show the search screen; do a search ;use a searched value etc. The base form contains hidden fields, populated via javascript, which tell the dispatch action which property the search function is being invoked for, and other 'paramaters' such as the id of a selected record. The view of my application uses the struts nested tags, and JSP includes to provide reuseable components to render a SearchableProperty and it's associated search view. The search view is part of the same page - the app only ever uses one browser window, with no frames. The upside of this approach is that I can place, with little effort, sophisticated searching functions anywhere is the app. Due to the inclusion of the user selected business entity behind the scenes, my view can display any properties of the selected entity, without a change to the form bean. The downside of this is that the form bean must be stored in session scope. I have done a bit of load testing and it didn't seem to be a problem, but I didn't have much to compare with - this is my first Struts app. So, that's the approach I use. I've no idea how that compares to the best practices out there, nut I'm eager to find out! Paul -Original Message- From: Chawla, Yogesh [mailto:[EMAIL PROTECTED] Sent: 26 September 2003 08:19 To: 'Struts Users Mailing List' Subject: Struts Design Issue - Search Functionality - Best Practices Importance: High Hi, Design Requirement - Show a list of Search records. The screen will have buttons for Previous/Next Month. On clicking these records would be shown. Issues - a) How to store data and best practices to be followed in Struts. Return back a Collection of Form Beans and iterate over these. However certain other fields are required to be stored also which are not displayable. i.e. Current Date which is a hidden parameter. Any comments ? b) Use a single Form Bean which has variables like String[] to store the array of Displayable Fields. However, this seems to be a less than perfect solution. Any comments ??? c) Use Generic Search - Search on different modules, with different fields ? Any Brilliant Guru contributions for this one..Sure need some wizard out here... Pls. advise on the best approach for the Search functionality. We need to design an application which has Search on each and every page. Thanks for your time , Regards, Yogesh DISCLAIMER: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** Axios Email Confidentiality Footer Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message, and notify us immediately. If you or your employer does not consent to Internet email messages of this kind, please advise us immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by my Company or employer unless otherwise indicated by an authorised representative independent of this message. WARNING: While Axios Systems Ltd takes steps to prevent computer viruses from being transmitted via electronic mail attachments we cannot guarantee that attachments do not contain computer virus code. You are therefore strongly advised to undertake anti virus checks prior to accessing the attachment to this electronic mail. Axios Systems Ltd grants no warranties regarding performance use or quality of any attachment and undertakes no liability for loss or damage howsoever caused. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
