Experiences building and using Tiles-3 (sandbox)
Builds easy enough. There is no top level "one command build". There any
objection if I add the following to the top level "tiles-sandbox"
pom.xml so to make it so?
<modules>
<module>tiles-request</module>
<module>tiles-autotag</module>
<module>tiles-eval</module>
<module>tiles3</module>
</modules>
Also "tiles-sandbox" will need to be renamed, but to what?
"tiles-reactor"?
Moving on...
I had some troubles initially building complicated by the fact the
snapshots in the apache repository were out of date.
The problem was the maven-autotag-plugin wasn't working when trying to
build tiles3. The underlying fault was that tiles-request-jsp only
transitively included tiles-request-api and this failed. Making it a
explicit dependency worked (r1137557).
The application i had to test against was spring based and so required
TilesConfigurer. This is old code still using configuration properties
for tiles-2.1 and reflection to detect tiles-2.2
I've done a rewrite of it. Should i put it in a patch to Spring or as an
extra module here (eg tiles3/tiles-spring)?
It still is rough, just rough enough to work for me, but i intend to
polish it up.
After that...
migrating a tiles application involved very little.
I've put together point-form some of the things i can into. Some of
these that are questions might be really easy/stupid but i'll ask them
anyway to put them "on the record".
*ServletUtil reduced*
A simple migration but a popular refactoring required i reckon.
Instead of calling
ServletUtil.getContainer(servletContext)
one must now call
TilesAccess.getContainer(ServletUtil.getApplicationContext(servletContext))
*TilesApplicationContext*
Has been renamed to ApplicationContext. Nice, and easy enough to
refactor, but again a popular refactoring required i reckon. Other
Context classes has been renamed so.
*CachingTilesContainer*
Not too sure yet on how to use this. It had a default constructor before
but now requires a container to delegate to. Haven't looked further into
it.
*TilesContextELResolver*
Constructor now requires a beanElResolver. Haven't looked further into
this either. Should i use the TilesContextBeanELResolver or
BeanELResolver?
*AbstractTilesContainerFactory.registerRequestContextFactory(..)*
Is gone. It (TilesRequestContextFactory) is also removed as a parameter
from many of the methods in AbstractTilesContainerFactory.
Nice.
*tiles:useAttribute tag*
This now belongs to a different tld called tiles-extras-jsp.tld
Replaced all occurrences to tilesx:useAttribute
*TilesIOException*
gone as well. I've also noticed that PreparerException is now unchecked.
What was the reasoning to this?
Summary
We a little migration effort my application works now without hick-up
now. Having stepped through the new code while going through the points
above I'm blown away by just how much cleaner it all feels now. Just one
example contexts and the request stack are a lot more implicit and
obvious now. The architecture to the project comes across now as
elegant. While I don't quite fully comprehend the possibilities to
autotag yet (i think you need to be involved in projects where multiple
templating languages are used), the tiles-request is a godsend and i
wonder why it should be hidden as part of the tiles project at all. I
think it deserves to be moved out to its own project, for example
"web-request" or even "commons-request". Indeed call me the fool for not
taking advantage of this code in other applications last year. A brief
introduction from Antonio already exists at
https://blogs.apache.org/tiles/entry/abstracting_requests_and_templates
In short, having seen the cleanliness of the code underneath, despite
there being no features here that we need, i very much after upgrading
any tiles application as soon as possible to use it.
~mck
--
“Don’t worry about people stealing your ideas. If your ideas are any
good, you’ll have to ram them down people’s throats.” - Howard Aiken |
www.semb.wever.org | www.sesat.no | tech.finn.no |
http://xss-http-filter.sf.net
signature.asc
Description: This is a digitally signed message part
