struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <dgraham1...@hotmail.com>
Subject RE: The <display:*> tag library
Date Fri, 24 Jan 2003 21:12:31 GMT
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" <jerome.jacobsen@gentootech.com>
>Reply-To: <jerome.jacobsen@gentootech.com>
>To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
>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:dgraham1980@hotmail.com]
> > Sent: Friday, January 24, 2003 3:56 PM
> > To: jerome.jacobsen@gentootech.com; struts-user@jakarta.apache.org
> > 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" <jerome.jacobsen@gentootech.com>
> > >Reply-To: <jerome.jacobsen@gentootech.com>
> > >To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> > >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:ka-wai_chan@transcanada.com]
> > > > 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: dave@messagecast.net
> > > > >http://www.messagecast.net
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >>-----Original Message-----
> > > > >>From: Jerome Jacobsen [mailto:jerome.jacobsen@gentootech.com]
> > > > >>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:chaz@brault.com]
> > > > >>>Sent: Thursday, January 23, 2003 10:09 AM
> > > > >>>To: struts-user@jakarta.apache.org
> > > > >>>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
> > > > >>>chaz@brault.com
> > > > >>>"Where are we going, and why am I in this handbasket?"
> > > > >>>
> > > > >>>
> > > > >>>--
> > > > >>>To unsubscribe, e-mail:
> > > > >>><mailto:struts-user-unsubscribe@jakarta.apache.org>
> > > > >>>For additional commands, e-mail:
> > > > >>><mailto:struts-user-help@jakarta.apache.org>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>--
> > > > >>To unsubscribe, e-mail:
> > > > >><mailto:struts-user-unsubscribe@jakarta.apache.org>
> > > > >>For additional commands, e-mail:
> > > > >><mailto:struts-user-help@jakarta.apache.org>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >--
> > > > >To unsubscribe, e-mail:
> > ><mailto:struts-user-unsubscribe@jakarta.apache.org>
> > > >For additional commands, e-mail:
> > ><mailto:struts-user-help@jakarta.apache.org>
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >--
> > >To unsubscribe, e-mail:
> > ><mailto:struts-user-unsubscribe@jakarta.apache.org>
> > >For additional commands, e-mail:
> > ><mailto:struts-user-help@jakarta.apache.org>
> > >
> > >
> > >
> > >
> > >--
> > >To unsubscribe, e-mail:
> > ><mailto:struts-user-unsubscribe@jakarta.apache.org>
> > >For additional commands, e-mail:
> > ><mailto:struts-user-help@jakarta.apache.org>
> >
> >
> > _________________________________________________________________
> > MSN 8 with e-mail virus protection service: 2 months FREE*
> > http://join.msn.com/?page=features/virus
> >
> >
> > --
> > To unsubscribe, e-mail:
><mailto:struts-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail:
><mailto:struts-user-help@jakarta.apache.org>
>
>
>
>
>--
>To unsubscribe, e-mail:   
><mailto:struts-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: 
><mailto:struts-user-help@jakarta.apache.org>


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


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message