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 20:55:55 GMT
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>


Mime
View raw message