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". 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]
