On 12/1/05, Greg Reddin <[EMAIL PROTECTED]> wrote: > > I have just checked in a sweeping refactoring of the Standalone Tiles > codebase. Many may see it and immediately hurl cruise missiles in my > general direction :-) Please do, I can take it. First and foremost > however, I ask that you remember this is the sandbox. I'm just > experimenting and if people seem to think I'm drifting too far from > the original intent I am willing to unfactor what I've refactored. I > mostly did this because actual code trumps theory and I'm looking for > feedback. So please read my intent below along with a summary of > what I've done and what's left to do and let me know what you think. > > My main purpose was to compress and clean up the Tiles internal API. > Every time I've looked at Tiles I've been overwhelmed by the number > of classes and interdependencies. I constantly found myself thinking > "Surely it doesn't have to be this hard".
This was pretty much my reaction too, on the occasions I've delved into the code. But I didn't have the perseverence and singlemindedness to actually take it on and get anywhere, as you have done. Great stuff, Greg! -- Martin Cooper There are so many classes > and codepaths to do the same thing that there's almost certain to be > hidden features I didn't know about. Plus, the existing > documentation is terse as is the test coverage. I decided that I > either need to improve the doc and test coverage and/or take on a > major simplification effort. So I took a stab at making it simpler. > I may very well find that it does have to be that hard and be forced > to undo my changes. Here's a summary of my changes: > > The object graph supporting Tiles definitions and attributes was > spread across several classes in the org/apache/tiles package. The > default implementation included what I see as a lot of core > functionality of Tiles and was contained in the org/apache/tiles/ > xmlDefinition package. I compressed all of that code into the > following classes in org/apache/tiles: > > ComponentDefinition > ComponentDefinitions > ComponentAttribute > ComponentListAttribute > > Some of those are classes and others are implementations. There's > also a org/apache/tiles/definitions package with some > implementations. In doing this compression I was able to completely > get rid of the xmlDefinition package. I realize that xmlDefinition > represented a default xml-based implementation of the > DefinitionsFactory API So how can I justify making the default > implementation essentially part of the interface? Well, the > DefinitionsFactory interface did not inherently support some of tiles > core features like inheritance without relying on the xmlDefinition > package. I figured that if someone wants to support a different > factory, say backed by an RDBMS, they would still have to use some of > the classes in the xmlDefinition package to provide support for some > core features of Tiles. > > So I moved all that functionality up to the top level. I also wrote > a default reader component that can load that object graph from XML > using Digester. To implement a database-backed factory now one > should only need to write a new reader component and the core pieces > will behave the same way. > > Of course, this completely broke the taglib. So, to save time, I > simply did the poke, delete, compile, and quickly test method to make > the taglib compatible with the new core components. This works on my > simple web applications, but I'm sure the taglib is still broken in a > lot of ways. > > So, what's next? > > 1. Taglib Refactoring. > I need to closely review the taglib, extract the core functionality, > write tests and do some of the same refactoring to the tags as I've > done to the core. However, this will not change the public interface > - only simplify the internals. > > 2. Test, test, test. > I've written several test cases already and need a bunch more. I'm > trying to build each feature as a test case, pretty close to the test- > first pattern. I plan to continue that approach. In fact, I'd love > it if we could just point newbies at the test cases to show Tiles' > features and how they work. > > 3. Refactoring Wave 3: Remove dependencies on Servlet API. > This was the original goal 3 months ago when we started down this > path. We want Ties to work in a portlet environment. Doing so will > require that we get rid of all the dependencies on Servlet components > and replace them with some sort of context object that has > implementations for both servlet and portlet APIs. > > Along the way, we'll need to examine what features may have been > removed and try to figure out if and how to reimplement those. And > fix the stuff that I've broken. There's a bunch of FIXME's in the > code now that will need to be addressed. > > I think this project is a pretty good candidate for Don's milestone > proposal. I can already see 2 or 3. So there. I did it. Let me > know what you think. > > Thanks, > Greg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
