On Oct 11, 2006, at 1:12 PM, David H. DeWolf wrote:
I'd like to implement the ability to load tiles definitions from
the classpath in addition to from the servlet/portlet context. I'm
curious about implementation choices:
1) Add the support to the current ServletTilesContext and
PortletTilesContext through a standard base class and/or
ResourceLoader. This is probably the way to go if class loader
loading of definitions will be considered a standard feature. It
would be my first choice.
I like the idea but I think you're on the wrong track to look at
TilesContext. TilesContext is just a generic interface for storing
information about the context in which Tiles is running. Some type
of web context is assumed.
The primary interfaces for creating Tiles definitions are
org.apache.tiles.DefinitionsFactory and
org.apache.tiles.DefinitionsReader. The DefinitionsFactory is
responsible for storing the sources where definitions come from and
storing definitions. DefinitionsReader is responsible for reading
definition data in a specific format from each source and returning
them as ComponentDefinition objects.
So, for example, we have an UrlDefinitionsFactory that stores a list
of URLs as the sources for definitions. We also have the
DigesterDefinitionsReader that expects the sources to point to XML
files and can read XML definitions.
If you wanted to store your definitions in a database you might write
a JDBCDefinitionsReader that would read definitions from a database.
If you want to store XML files on the classpath you might write a
ClassloaderDefinitionsFactory that works with the classloader to load
definitions files. Or... you might find that you can do it with
existing code by using the UrlDefinitionsFactory and getting the URLs
from the classloader instead of from servlet context. In this case
you might have to create a new TilesListener that reads a classloader
instead of or in addition to the servlet context. These things
should work interchangeably. The Reader shouldn't care how
definitions were loaded. It only works with definitions stored in a
particular format. Likewise, the Factory shouldn't care what format
the definitions are in. It simply knows where to get them. No
specific reader implementation or factory implementation should have
any dependency on the other. If they do, then we haven't implemented
it correctly.
Additionally, what are people's thoughts about wildcard handling
for the resource definitions files. Is this a feature others are
interested in?
This sounds like a good idea also.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
