I can see the use of the "resource:" protocol in Avalon, but how would the
"context:" protocol be interpreted? In Cocoon, this would load a resource
relative to the WAR context path (well, actually however the environment
implementation of Context.getResource was written.) How would the
"context:" protocol be implemented outside of Cocoon and the environment.*
interfaces?
Regards,
--mike
On Fri, 18 Jan 2002, Berin Loritsch wrote:
> I looked into the SourceResolver code in Excalibur as I wanted to incorporate
> its use into my Container abstraction code. I believe that these components are
>indicative
> of a greater issue in Cocoon. It is the fact that these components are so
>intertwined
> I have to have several support Components in my initial ComponentManager for the
>system.
> I find this is not optimal.
>
> Let's look for ways of optimizing its use, and out of this will come practical use
>tips
> and other such things.
>
> The Container abstraction code is designed to have a simple single point of entry for
> a Container. A Container has the concept of a context directory (so the "context:"
> protocol can be easily merged), and each Container manages its components. This
> can help in simplifying Cocoon's code, as there is really a container hierarchy.
> This is in practice as well as in theory. There is the root Container (Cocoon)
> that implements the Processor interface. Each Sitemap represents a new Container
> that implements the Processor interface. Each Container can have a unique mapping
> of Components, etc. This provides a mechanism to keep each context directory
> distinct for the sitmaps.
>
> The issues I see in SourceResolver are these:
>
> 1) SourceResolver and SourceFactory are full fledged Components. The SourceFactory
>is
> used strictly by the Resolver. Therefore, the SourceFactory should not be a full
> component. It is only a helper class to the SourceResolver.
>
> 2) The Source interface only permits one-way communication. In Excalibur, there is
>more
> than only reading the "Source". This is why the Resource object is better.
>
> The issues I see in Parser are these:
>
> 3) The Parser interface is fine, but the two implementations are not. They each
>implement
> the ErrorHandler interface directly. The actions of those ErrorHandlers are not
>only
> constant, the are essentially the same. It would be better to have an outside
> ErrorHandler object that both of those implementations used. The same instance
>of
> the ErrorHandler object can be used accross as many threads as is necessary.
>
> 4) There is no EntityResolver implementation available
>
>
> As a general comment, when I see Role names like this:
>
> org.apache.cocoon.components.hsqldb.Server, I immediately recoil. My friends, this
>is not
> a component.
>
> When you are writing a Component's interface, don't take the easy road and slap a
>wrapper
> on whatever code you want. Take some time and consider how a Component is meant to
>interact
> with other components in a system. As much as possible, write components that do
>not have
> to maintain conversational state. Sometimes this is not possible, but really try to
>think
> about it.
>
> BTW, Don't implement Configurable if you aren't going to use the Configuration
>object!
>
> Cocoon does need to inventory their components, and if Configurable is only being
>used as
> a wrapper for a Parameters object, implement Parameterizable. I don't like seeing
>this:
>
> public void configure(Configuration config)
> throws ConfigurationException
> {
> // set the base URL to the current directory
> try
> {
> this.userDirectory = new File(System.getProperty("user.dir")).toURL();
> if ( this.getLogger().isDebugEnabled() )
> {
> this.getLogger().debug("SourceResolver: Using base directory: " +
>this.userDirectory);
> }
> }
> catch (MalformedURLException mue)
> {
> throw new ConfigurationException("Malformed URL for user.dir", mue);
> }
> this.baseURL = this.userDirectory;
> }
>
> If you don't need a configuration object, but need to perform some initialization,
> use Initializable.
>
>
> If I am going to use the SourceResolver or JaxpParser in the managed Container code
>(which
> handles the management of config files and everything), I need to use ThreadSafe
>components.
> I am going to change these components even more to make them ThreadSafe. In the
>case of
> SourceResolver, that means changing it's interface, and removing ResourceFactory as
>a component.
> We also need a "context:" uri handler as it has meaning even outside the Servlet
>context.
>
> Avalon needs the "context:" and "resource:" uri handlers, so if there are any
>takers, lets
> get it implemented (I couldn't see where it was done already).
>
>
>
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
