I think the best method of implementing changes is to propose on this
list and get votes from developers.  If you don't hear from developers
in 48 hours, consider it a null vote and reduce the amount of possible
votes.

Matt

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Paulsen, Jay
> Sent: Friday, March 28, 2003 1:31 PM
> To: displayTag
> Subject: RE: [displaytag-devel] Whither Future Development 
> after 0.8.5?
> 
> 
> I think there were performance issues when implementing the 
> display tag as an iterating tag,  At least that's what sticks 
> in my mind, but I reserve the right to be wrong ;-) 
> 
> In addition to Table Decorators, Column Decorators can be 
> created and reused for more common "decorating" tasks such as 
> formatting dates, timestamps, phone numbers ....
> 
> As long as were discussing future development, is there a 
> definitive post or string of posts that lays out some of the 
> major features/improvements that people are planning?  Now 
> that 0.8.5 is released, I'd like to start integrating some 
> things that I have in my own version of 0.8 that I've been 
> using for quite some time.  What's the protocol for this?  
> Should I describe them in some detail and take a vote on what 
> everyone wants included?  I'm hesitant to just start making 
> changes if they don't fit with the direction future 
> development is going.
> 
> -Jay
>  
> 
> 
> > -----Original Message-----
> > From: John York [mailto:[EMAIL PROTECTED]
> > Sent: Friday, March 28, 2003 2:04 PM
> > To: Benjamin Simpson
> > Cc: displayTag
> > Subject: Re: [displaytag-devel] Whither Future Development
> > after 0.8.5?
> > 
> > 
> > If I remember correctly, Ed's documentation says that they
> > adopted the 
> > 'decorator' pattern because they were unable to get the tag 
> > working like a 
> > standard iterate tag. I belive with whichever design we 
> > choose, we can 
> > remove this obstacle and deprecate the 'decorator' behavior 
> > within the 
> > display tag. 
> > 
> > However, it might still be useful to provide another tag that can do
> > simple formatting of strings/numbers/etc if a good one 
> > doesn't already 
> > exist. I've got a couple simple ones I've written for 
> > formatting numbers 
> > with commas and dollar signs and stuff. I agree with Benjamin 
> > that this 
> > should not be the focus of our development.
> > 
> > Does anyone have any good example of taglib-type designs?
> > Anyone have any 
> > good diagrams we could use as a reference for creating new 
> > diagrams for 
> > our new proposed design? I've used ArgoUML in the past and it 
> > works out 
> > well for class diagrams, so I could try something like this 
> > if there isn't 
> > a better tool available. I'm using linux, so I'd prefer a 
> > java or linux 
> > based tool.
> > 
> > John
> > 
> > 
> > 
> > On Fri, 28 Mar 2003, Benjamin Simpson wrote:
> > 
> > > Jay,
> > > 
> > > I should have been more clear.  You were correct in asking
> > for and further
> > > providing more clarity to the statement.  I agree whole
> > heartedly with your
> > > statement.
> > > <u>
> > > 
> > > It is a mistake to tie this little tag to struts, tapestry
> > or any other
> > > framework.
> > > 
> > > </u>
> > > 
> > > The only dependency I agree with to date is the usage of 
> > > commons-beanutils.jar.
> > > 
> > > While we are on the topic of "dos and don'ts", I would also
> > like to state
> > > another flaw in the tag library.  The use of decorators is
> > not consistent
> > > with the reason a user would want to use our tag.  The user
> > is trying to
> > > avoid custom coding display logic.  If we wanted to provide
> > the user with a
> > > consistent model, it should be a nestable tag interface
> > that would be looked
> > > for in the body of a column tag.  Coding a decorator for
> > every little thing
> > > is tedious.  There should be generic tags that could be
> > nested within the
> > > larger context of table or column.
> > > 
> > > One final note as I have had enough coffee this morning,
> > > 
> > > If you are proud of your statement, it should not be
> > diminished with a
> > > signature line like that is just my 2 cents worth.  I liked
> > what you had to
> > > say.  I would have enjoyed the statement more if you 
> would have said 
> > > something like "eat these words" or "fix your misuse of
> > indefinite articles
> > > when doing spell check and I won't have to do it for you
> > next time..."
> > > 
> > > Thanks for your input Jay, keep it coming :)
> > > 
> > > Ben
> > > 
> > > 
> > > ----- Original Message -----
> > > From: "Paulsen, Jay" <[EMAIL PROTECTED]>
> > > To: "displayTag" <[EMAIL PROTECTED]>
> > > Sent: Friday, March 28, 2003 10:02 AM
> > > Subject: RE: [displaytag-devel] Whither Future Development
> > after 0.8.5?
> > > 
> > > 
> > > >
> > > >
> > > > >
> > > > > This might correct that the way we are progressing with "one 
> > > > > off" bug fixes and a tendency towards struts as an assumed 
> > > > > underlying framework
> > > > >
> > > >
> > > > Is display tag development heading in the direction of
> > coupling it with
> > > > struts?
> > > > I think it would be a mistake to tie the display tag to
> > struts (or any
> > > > underlying
> > > > framework for that matter).  If this is not what you
> > meant, I apologize.
> > > >
> > > > Just my 2 cents worth,
> > > > -Jay
> > > >
> > > > > -----Original Message-----
> > > > > From: Benjamin Simpson [mailto:[EMAIL PROTECTED]
> > > > > Sent: Friday, March 28, 2003 8:14 AM
> > > > > To: displayTag
> > > > > Subject: Re: [displaytag-devel] Whither Future 
> Development after 
> > > > > 0.8.5?
> > > > >
> > > > >
> > > > > Well put John.  I am +1 for this approach.   What permissions
> > > > > in SourceForge
> > > > > are necessary to make the modules appear ("directed to any 
> > > > > seasoned Source Forge Admin")?  If I have sufficient 
> permissions 
> > > > > and group consent, I will
> > > > > go ahead and make modules for John, Myself and any 
> > others who want to
> > > > > participate.
> > > > >
> > > > > I further propose that if you are willing to put your
> > refactorings out
> > > > > there, they should only be considered if sufficient
> > documentation and
> > > > > examples accompany them.  A readme, buildme, seeme 
> and whyme set 
> > > > > of files? Get me?
> > > > >
> > > > > This might correct that the way we are progressing with "one 
> > > > > off" bug fixes and a tendency towards struts as an assumed 
> > > > > underlying framework
> > > > >
> > > > > Ben
> > > > >
> > > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by:
> > > > The Definitive IT and Networking Event. Be There!
> > > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > > _______________________________________________
> > > > displaytag-devel mailing list 
> > > > [EMAIL PROTECTED]
> > > > https://lists.sourceforge.net/lists/listinfo/displaytag-devel
> > > >
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by:
> > > The Definitive IT and Networking Event. Be There!
> > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > _______________________________________________
> > > displaytag-devel mailing list 
> [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/displaytag-devel
> > > 
> > 
> > --
> > John York
> > Software Engineer
> > CareerSite Corporation
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by:
> > The Definitive IT and Networking Event. Be There!
> > NetWorld+Interop Las Vegas 2003 -- Register today!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > _______________________________________________
> > displaytag-devel mailing list [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/displaytag-devel
> > 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> displaytag-devel mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/displaytag-devel
> 




-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
displaytag-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/displaytag-devel

Reply via email to