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
