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