2011/6/22 mck <[email protected]> > 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> >
Initially I wanted to manage these projects separately. However, on a second thought, managing them separately means a nightmare when releasing. Also "tiles-sandbox" will need to be renamed, but to what? > "tiles-reactor"? > I'm not good at names :-) tiles-parent was good when on Tiles needed to be built. I don't know what's best here. Probably "tiles-reactor" is good, or move "tiles-parent" to the main build, or "tiles-main". I really don't know what to say. > 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. > Good question. Tiles 3 is still in the sandbox, so probably Spring team is not interested in including your patch. Creating a tiles-spring module would be interesting. Remember, if you are including Spring's code, to include a brief line on NOTICE.txt file (about the license, there is no problem since it is AL 2.0 too). > *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. > IIRC I did it to reduce code. > *TilesContextELResolver* > > Constructor now requires a beanElResolver. Haven't looked further into > this either. Should i use the TilesContextBeanELResolver or > BeanELResolver? > They are two different things. TilesContextELResolver resolves objects like "request", "session", "application" and "page". TilesContextBeanELResolver resolves beans inside the above scopes. So If I write "whateverBean", it is searched, in order, from "page", "request", "session" and "application", until it finds one. BeanELResolver is the standard bean resolver of JSP EL. > > *AbstractTilesContainerFactory.registerRequestContextFactory(..)* > > Is gone. It (TilesRequestContextFactory) is also removed as a parameter > from many of the methods in AbstractTilesContainerFactory. > Nice. > Yes because now the "Request" is a first class citizen. > *TilesIOException* > > gone as well. I've also noticed that PreparerException is now unchecked. > What was the reasoning to this? > It was needed because in Java 1.5 there was no IOException constructor that takes a cause (introduced in Java 6). Since I think that we will use Java 6, it is now unnecessary. PreparerException was already unchecked, since it extends TilesException (unchecked). > 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), Exactly. But not only for this reason. I noticed that writing a "model" for autotag is much simpler than writing a TLD descriptor plus tag objects when working on JSP only. > 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". Yeah, it was an idea that I had too. > 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. > Well thank you for your appreciation :-) Ciao Antonio
