Of course all of those factors affect the speed. Database's main job in life is storing and manipulating data so they are far better at sorting than application code.

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 16:09:34 -0500

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]>

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to