Hi Hue, again thank you for the bundle of links. It's quite amusing. Reading the howto from Cedric Dumoulin about TilesDefinitionsFactory - everthing sounds quite easy. But then after the first steps - Puh, it's hot.
What Cedric did not mention at all, is the fact, that with replacing the TilesDefinitionsFactory you have to do all the big work at your own: module-switching, I18n-support, xml-parsing, definition-handling, ... So I had a look at the sources and found several ways on how to proceed. I would like to discuss the solutions, before any coding - cause I don't know nothing about the current development. [OT] with the whole discussion about JSF/JSTL ... - is it worth, to spend time in tiles-development? [/OT] The actual DefinitionsFactory is really a DefinitionsFactorySet, which at module-switching and/or locale-switching creates a new DefinitionsFactory. This "inner" DefinitionsFactory would be nice to replace. How about creating a new key for the tiles-plugin like "definitions-sub-factory-class-name". This way, the current DefinitionFactorySet could create different Factories and stil do the job of switching, parsing .... Doing so, you'll get a possibility to manipulate config-entries without the need to care about xml-parsing. Similar to ActionConfig. I think, most wishes could be solved with this. The disadvantage of this approach: The parts of main interest have private access only. So the TilesDefintionsFactorySet class has to be patched some way, as no small and clean inheriance is possible. The other way is the harder, cleaner way. Creating a new Factory with a new XML-parser, module-switcher and a plugin for the inner Factory too. May be some guys (Cedric ?) are already working on this approach? Any comment is welcome! cheers Reinhard --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
