struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Hodson" <d...@messagecast.net>
Subject RE: The <display:*> tag library
Date Fri, 24 Jan 2003 16:34:38 GMT
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>


Mime
View raw message