>To be precise, you're actually talking about making a particular
>*implementation* of the resource APIs dependent on Digester, right?  We're
>not saying that they all have to.

I have a 
class, called ResourceManager, that represents an easy way to manage
multiple resources in a web app.  It uses another class, called
ConfigurationReader, to read in resource metadata from a file and create
resources based upon that.  I was talking about using Digester in
conjunction with the SetPropertyRule stuff to parse the configuration
file.  The reason for this is that I feel it would be easier on everyone
if there was a single file format to describe resources.

This would also make Resources bean-like creatures, that have attributes
that are populated by Digester from the XML file with set-property tags:

<resource name="messages"
factory="org.apache.commons.resources.MessageResourcesFactory">
        <set-property property="returnNull" value="false" />
</resource>

I could make the method that reads from an InputStream in
ConfigurationReader
abstract, and make a subclass called DigesterConfigurationReader which
uses digester when it implements the read method if locking people into
a specific file format for describing resources is undesirable.

>If we want
>to make the build process for resources a little easier, you can even
>teach Ant to compile these implementation classes only if Digester and
>Beanutils are available on the classpath, although anyone who's building
>Resources from scratch is probably going to have all the other sources
>available as well.

If I go about making ConfigurationReader an abstract class and have a
specific
Digester subclass, then this will become very useful.

Thoughts?

 - Mike

Reply via email to