sounds great! I also ran into the problem of sorting when column bodies are being used. The decorator solves that particular problem well.
John On Tue, 10 Jun 2003, Fabrizio Giustina wrote: > my SF id is fgiust > > I'll try to commit my code to the repository by tomorrow: as I said is not finished > but I'd like if you can take look at that. I'll also try to create a todo list for > uncomplete things and for other things I think should be fixed/changed. > > About the decorator approach: I also think most of the functionality in decorators > can be replaced with the iterator approach. The decorator part is the uglyest to > mantain in a refactorying like this... The decorator stuff is also very badly > integrated in the exporting functionality. > BUT I found it useful for one reason: sorting. If you define the content of the > column with a nested tag you have sorting on a formatted string, and this is not > what you want for example for dates and numbers () and parsing again the string > before sort is not exactly a good approach) > > I think for newer version the column decorator approach will still make sense, while > the table decorator one could maybe be totally replaced by nested tags. > Anyway, at the moment I'm trying to keep a complete compatibility (with some > difference only in the html output) with the previous version, this could be > evaluated for a totally new version. > > > ciao > fabrizio > > > > > -----Original Message----- > From: Matt Raible [mailto:[EMAIL PROTECTED] > Sent: Tue 6/10/2003 4:33 PM > To: John York; Fabrizio Giustina > Cc: [EMAIL PROTECTED] > Subject: Re: display taglibrary > > > > > Hi Fabrizio, > > > > That's great! I spent a ton of time getting things to match using > > the old examples pages. I had about 85% of old functionality > > working. I'm looking forward to seeing your code. > > > > I still would like to stress that being backward compatible with the > > existing tag only provides alot of extra stuff that really isn't > > needed in this tag IMHO. Decorators for one example aren't needed at > > all with an iterate structure. The current code and attributes are > > cluttered with this stuff and I think that it should be deprecated > > or removed altogether. > > > > Matt, should we give him cvs access to upload his code? Sounds good > > to me. > > > > I'm fine with giving Fabrizio access to CVS, we should probably choose a name > for the new module (i.e. display2). Fabrizio - what's your SF id? > > Matt > > > > -- John York Software Engineer CareerSite Corporation ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ displaytag-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/displaytag-devel
