Scott, I've also got a completely refactored version of it. I've been trying to make it backwards compatible, but it seems almost hopeless. With the way I've got my tag setup, many of the features of the existing tag aren't part of the tag anymore and can be done with simple JSP. I've got what seems to be a decent Model-View-Controller structure for the tag. The JSP part ends up being a simple iterate that allows any other JSP within it, which automatically lets things like 'autolinking' and 'decorating' happen without any support within the tag itself. I think we need to focus the features of the tag more and make it more easily customizable within the JSP rather than adding features in the code.
My structure simply iterates over a collection, fills in a table model with the data, then once it has the dataset, it renders it using one of the extendable view classes. This works very well in use and my company has been using it for close to a year now, so it's very stable. My design isn't perfect and I know could use some help in a few places. That being said, I'm sure many others have done similar things. In sourceforge, we can have multiple modules, so should some of us add our 'proposal' refactorings as a starting point? Regardless, we need to decide whether we will try to support backward compatability fully or only partially. I had planned to get full backward support done, but there are just too many features supported by this tag that in my opinion are outside the scope of it. John On Thu, 27 Mar 2003, Scott Smith wrote: > Everyone, > > Looks like 0.8.5 is "delivered". Congratulations to > all concerned! > > Now, what's next? > > I have one immediate agenda: I'd like (me and/or > anyone else) to quickly refactor the existing code > according to modern object-oriented/pattern practices > to achieve the following benefits: > > 1. Reusability. It is virtually useless to subclass > anything in the TableTag; its methods are excessively > "coarse". > > 2. Appropriate Coupling. There is no reason for the > same class to handle HTML output _AND_ XML _AND_ Excel > _AND_ etc. etc. These renderers should be in separate > classes. > > There are probably other reasons as well, but these > reasons are the driving forces for me. I have already > refactored TableTag for internal use and have added > several features I think the group would be interested > in; however there is no chance of folding them in > smoothly with the code implemented the way it is. > > When this is done, it will be much more likely that > people who are presently hacking away at copies of > this tag library will instead offer their enhancements > to the open source. > > Perhaps we could, as a group, play with a class > diagram; when we're close one of us could refactor the > actual code. Maybe test the code on a branch. > > Anyways, I'm in favor of moving now while the table > tag is not so complex that it can't be done quickly. > > Any other thoughts? > > -Scott Smith > > > ------------------------------------------------------- > 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
