Hi Mike, An approach I've used in Tiles2 is to create a DefinitionsFactory that applies logic to the selection the correct tiles Definition. Instead of complex conventions in tiles configuration, include some logic in the lookup instead, falling back to (for example) blank tiles/alternative tiles.
A DefinitionsFactory includes the method that loads the Definition based on name. Definition getDefinition(String name, TilesRequestContext context); In can be set up via a context param for tiles (http://tiles.apache.org/config-reference.html): <context-param> <param-name>org.apache.tiles.definition.DefinitionsFactory</param-name> <param-value>fully qualified class name to MyCustomDefinitionsFactory</param-value> </context-param> The default DefinitionsFactory is UrlDefinitionsFactory. You won't want to rewrite that, so you can just wrap an instance and delegate to it to access standard functionality. public class MyCustomDefinitionsFactory implements DefinitionsFactory { DefinitionsFactory delegate; public MyCustomDefinitionsFactory() { delegate = new UrlDefinitionsFactory(); } // implement other methods required for the interface, delegating to the delegate // getDefinition should override the name when necessary though: public Definition getDefinition(String name, TilesRequestContext context) { if (need to change tile/exclode tile based on context) { String alternativeName = (calculate appropriate tile to use) return delegate.getDefinition(alternativeName, context) { } else { return delegate.getDefinition(name, context); } } Hope that helps. Regards, Jeromy Evans On 16/07/2013, at 11:26 AM, Mike Hepple <[email protected]> wrote: > > So. I'm stumped! Can anyone think of an intelligent way to handle the > non-existence of features in a meaningful manner? Basically all I want is > the ability to do (in pseudo-code) >
