struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jerome Jacobsen" <jerome.jacob...@gentootech.com>
Subject RE: The <display:*> tag library
Date Fri, 24 Jan 2003 21:09:34 GMT
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>


Mime
View raw message