That depends on the complexity of the query (number of joins, etc.) and the size of the result set. I'll bet the JVM can sort a ten item List faster than a database call. It also depends on how your application is tiered.
> -----Original Message----- > From: David Graham [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 24, 2003 3:56 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: The <display:*> tag library > > > Your database should *always* sort a result faster than any code > you write. > So there is usually no reason to sort it yourself unless your db > connection > is terribly slow. > > David > > > > > > > >From: "Jerome Jacobsen" <[EMAIL PROTECTED]> > >Reply-To: <[EMAIL PROTECTED]> > >To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > >Subject: RE: The <display:*> tag library > >Date: Fri, 24 Jan 2003 15:50:01 -0500 > > > >To be clear I was just outlining what I thought would be an improved > >display-like taglib. I wish I actually had the time to > implement it, but I > >don't. The behavior of the current taglib's sorting feature is > >non-intuitive when there are multiple pages. Also, there is no > need to go > >to the database every time if you implement the first > alternative I listed. > >That is, the user links the sortable column(s) to an Action > which sorts the > >Collection stored in the session. > > > >I did consider the sorting plus paging problem and thought that maybe if > >there were multiple pages and the user clicked a sortable column while on > >page 5 they would just be taken back to page 1 after the Collection was > >sorted. However once you add the sorting capability then I'd > bet there'd > >be > >an expectation that you should be able to provide a Comparator > class name > >to > >the display2:column tag. I don't like having Java classnames in JSP > >attributes (another reason to get rid of the Decorator). And it > is fairly > >simple to let the Action do the sorting of the Collection and it can use > >whatever Comparator it wants. > > > >-Jerome > > > > > -----Original Message----- > > > From: Ka-Wai Chan [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, January 24, 2003 3:14 PM > > > To: Struts Users Mailing List > > > Subject: Re: The <display:*> tag library > > > > > > > > > Please keep the sorting feature! It is used lots and helps > performance > > > as there isn't a need to hit the database everytime > > > > > > Ka-Wai > > > > > > Dave Hodson wrote: > > > > > > >I disagree on the sorting feature -- I'd vote to keep it, as we > > > use it heavily > > > > > > > >Dave > > > > > > > >-- > > > >Dave Hodson > > > >MessageCast, inc. > > > >Email: [EMAIL PROTECTED] > > > >http://www.messagecast.net > > > > > > > > > > > > > > > > > > > > > > > >>-----Original Message----- > > > >>From: Jerome Jacobsen [mailto:[EMAIL PROTECTED]] > > > >>Sent: Thursday, January 23, 2003 8:07 AM > > > >>To: Struts Users Mailing List > > > >>Subject: RE: The <display:*> tag library > > > >> > > > >> > > > >>I think a complete rewrite is needed AND a new API (same tags > > > >>but different > > > >>tag attributes). Thus I would say an entirely new tag > > > >>library. I'll call > > > >>the new version display2 and the current one display1 for > > > >>clarity below. > > > >> > > > >>- Follow JSTL conventions for attribute names and support JSTL-EL. > > > >>(Actually make use of the JSTL Tag support classes). This > > > >>means JSP 1.2 is > > > >>baseline. Assuming JSTL-EL capable attributes allows us to > > > >>make a simpler > > > >>tag API. Less attributes are needed. For example we don't need the > > > >>Struts-like bean-name and bean-property attributes. > > > >> > > > >>- Drop the sorting feature. The user can provide this > > > >>functionality by > > > >>making their column names links to actions which resort their > > > >>list. Or > > > >>their query form can have order by criteria. The display1 > taglib only > > > >>provides resort of contents in current page which I think is > > > >>confusing to > > > >>users if there are multiple pages. > > > >> > > > >>- The display2:table tag should work as an IterationTag. > The display1 > > > >>doesn't therefore you cannot access a scripting variable for > > > >>the current row > > > >>of the iteration. You are forced to use Decorators. This is > > > >>non-standard > > > >>as per Struts or JSTL. I vote for removing the Decorator > > > >>functionality. > > > >> > > > >>- The display2:column should allow optional body content. If > > > >>present its > > > >>output is used in the table cell. > > > >> > > > >>A first stab at the API might look like this. > > > >> > > > >>Table > > > >>----- > > > >><display2:table [var="varName"] items="collection" > > > >> [varStatus="varStatusName"] > > > >> [begin="begin"] [end="end"] [step="step"] > > > >> [pageSize="pageSize"] [pageUrl="pageUrl"] > > > >> [cssClassPrefix="cssClassPrefix"]> > > > >> body content > > > >></display2:table> > > > >> > > > >>Where var, items, varStatus, begin, end, and step have the > > > >>same meaning as > > > >>JSTL's c:forEach tag. > > > >>And pageSize and pageUrl have same meaning as in display1 taglib. > > > >>The display1 taglib generates HTML tags using CSS class > > > >>names. You can't > > > >>define what these names will be so in display2 the > > > >>cssClassPrefix can be > > > >>used to prefix the auto generated CSS names. A div tag > > > >>around the entire > > > >>table works too so maybe this attribute isn't necessary? > > > >> > > > >>Column > > > >>------ > > > >><display2:column title="title" [value="value"]> > > > >> body content > > > >></display2:column> > > > >> > > > >>Title has the same meaning as in display1, except that it is > > > >>mandatory. > > > >>Value is optional, but must be present if there is no body > > > >>content. The > > > >>evaluation of value goes in the contents of the cell. The > > > >>optional body > > > >>content is used in the cell if there is no value attribute or > > > >>if the value > > > >>attribute results in null. > > > >> > > > >>That's a first stab and it probably is missing stuff. Maybe > > > >>an escapeXml > > > >>attribute should be added to both tags? > > > >> > > > >>Any thoughts on this? > > > >> > > > >> > > > >> > > > >>>-----Original Message----- > > > >>>From: Charles Brault [mailto:[EMAIL PROTECTED]] > > > >>>Sent: Thursday, January 23, 2003 10:09 AM > > > >>>To: [EMAIL PROTECTED] > > > >>>Subject: Re: The <display:*> tag library > > > >>> > > > >>> > > > >>>+1 > > > >>> > > > >>>I've added support for Struts messages in column titles, glad to > > > >>>contribute it. Since I really depend on this library for a > > > >>> > > > >>> > > > >>product I've > > > >> > > > >> > > > >>>developed, and need to fix some problems, make some > > > >>> > > > >>> > > > >>additions, I'd be > > > >> > > > >> > > > >>>pleased to work with others on improving this great piece of code, > > > >>>perhaps be the "pumpkin keeper" if no one else will do it > > > >>> > > > >>> > > > >>(although I'm > > > >> > > > >> > > > >>>reluctant to volunteer, as I haven't performed that role > > > >>> > > > >>> > > > >>before, except > > > >> > > > >> > > > >>>as a gardner ;-) > > > >>> > > > >>>chaz > > > >>>-- > > > >>>Charles E Brault > > > >>>[EMAIL PROTECTED] > > > >>>"Where are we going, and why am I in this handbasket?" > > > >>> > > > >>> > > > >>>-- > > > >>>To unsubscribe, e-mail: > > > >>><mailto:[EMAIL PROTECTED]> > > > >>>For additional commands, e-mail: > > > >>><mailto:[EMAIL PROTECTED]> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>-- > > > >>To unsubscribe, e-mail: > > > >><mailto:[EMAIL PROTECTED]> > > > >>For additional commands, e-mail: > > > >><mailto:[EMAIL PROTECTED]> > > > >> > > > >> > > > >> > > > >> > > > > > > > >-- > > > >To unsubscribe, e-mail: > ><mailto:[EMAIL PROTECTED]> > > >For additional commands, e-mail: > ><mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > >-- > >To unsubscribe, e-mail: > ><mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: > ><mailto:[EMAIL PROTECTED]> > > > > > > > > > >-- > >To unsubscribe, e-mail: > ><mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: > ><mailto:[EMAIL PROTECTED]> > > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>