The Tiles implementation has become complex because of the numerous
backward compatibilities. I think that it is possible to simplify the
code by removing some of them. For example it should be possible to
simplify the way tiles initialize by removing struts 1.0 compatibility
(if it still there). Also, it should be possible to remove all the
"alternative names" like component, tiles, ... and use the more up to
date. This will also simplify the documentation and the learning of
tiles by new users.
But be care, there is some not so often used API that are used by some
companies. I hope these APIs will remain. I think of :
- the possibility to provide another implementation for tiles factory
(use of a DB ...)
- the i18n mechanism to load alternative definition files
- ... (I need to dig into the code to remember :-) )
I keep an eye on the struts dev list, and I try to follow all threads
about Tiles. So, feel free to ask me more specific questions if you
need, either on the list or directly.
Cedric
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
