Greg:
A big +1 from me for simplifying Tiles; my hunch is that there are
very few people who have actually written code that depends on the
implementation details of Tiles besides writing Controllers, and I
have frequently shared your sense of puzzlement. Tiles also suffers
from merging from a few code bases and preserving alternative ways of
doing things for longer than is probably necessary.
I encourage you to do what you can to make things easier to follow,
especially seeing as the new package namespace means that everyone
will be aware that a transition has occurred. I think maintaining
backwards compatibility is commendable, but I think there may be
places where you could justify breakage -- at least I'd suggest
remaining open to the possibility.
Joe
At 10:27 AM -0500 10/6/05, Greg Reddin wrote:
I hope no one who has worked on Tiles in the past - especially
Cedric - takes offense to this because none is intended. But here
goes...
Every time I dig into Tiles I'm overwhelmed by the complexity of the
API. IMHO, it seems like Tiles employs way too many classes to do
it's job. I wanted to do the work required to extract the Servlet
API dependencies, but I'm finding my brain is not able to think
about all the pieces at one time. So, my proposal is to further
refine the API to simplify it as much as possible. Ideally, I'd
like to pare the internal API back to just the bare essentials. I'd
like developers who are new to Tiles to be able to follow the code
path easily to solve problems and figure out what's going on. Just
like the last refactoring I did, this work will not change the way
users configure or use Tiles from a JSP perspective at all. I hope
the end result will be a simplified Tiles that makes a lot more
sense when you dive into the code. So here's some questions for the
list:
1. Is this worthwhile? If it ain't broke should I avoid fixing it?
On one hand it's worth it to me simply because enhancements to Tiles
are not easy right now. OTOH, I don't know how many enhancements
Tiles really needs. It pretty much does what it needs to do and it
seems like most enhancements are related to porting it to other
architectures.
2. Will this step on someone's toes? I really don't want to divide
the community by doing this. This is not a case of "your code sucks
so I'm going to fix it", but just a case of me wanting to simplify
things so it's easier to keep up with. I'd be happy to work with
anyone who was involved in creating Tiles initially to understand
why the complexity is necessary or whatever. Honestly, I haven't
seen a post from Cedric in quite a while so I wonder if he's moved
on to other things. I fully expect to be flogged if I do something
stupid :-)
3. Please be patient. It's taking me a while to walk through the
code paths and figure out what can be factored out or simplified.
If anyone else wants to help, feel free to email me and maybe we can
figure out a collaboration method if the dev list doesn't work. I
have no idea how long this will take so I hope there's not a huge
demand for the integration of standalone Tiles (or that there's
other willing hands).
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
