cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Cording <Dean.Cord...@kaz-group.com>
Subject RE: [RT] Rethinking the SourceResolver concept
Date Mon, 20 Oct 2003 01:29:26 GMT

> Carsten Ziegeler wrote:
> 
> >The recent discussions about migrating to fortress lead me
> >to think about our SourceResolver concept again.
> >
> >First the current state:
> >- The SourceResolver is an Avalon component that can be 
> >  looked up everywhere you have a component manager
> >  (service manager).
> >- The SourceResolver resolves any URI, including the
> >  cocoon: protocol. 
> >- Relative URIs are resolved to the current sitemap.
> >- Sitemap components get a cocoon source resolver
> >  in the setup() (or act() ...) method.
> >- The cocoon source resolver is an interface that
> >  is obsolete and is there only for compatibility.
> >  It extends the Avalon SourceResolver interface.
> >
> >So, a sitemap component always resolves URIs relative
> >to it's sitemap.
> >But in addition - if you have a usual avalon component,
> >e.g. a ThreadSafe one that uses SourceResolver - this
> >component resolves URIs relative to the current sitemap
> >as well. So the current sitemap acts like a context
> >for this component.
> >
> >This behaviour led to some more hacky implementations
> >to make it work and we had to extend the ECM for this.
> >The main problem is to determine the current sitemap.
> >We have some thread local variables for this and
> >a rather ugly handling for internal requests.
> >
> >Now, I think we can make it simpler :)
> >a) A sitemap component gets a Cocoon source resolver anyway.
> >  We can provide in the setup() method a wrapper for
> >  the Avalon SourceResolver that knows it's sitemap. This
> >  is simply and doesn't need thread locals etc. anymore.
> >b) The only problem lies in all this nice little thread
> >  safe components that resolve URIs relative to the
> >  current sitemap. 
> >One solution for b) is to say, relative paths are always
> >resolved to the context directory of cocoon than we can
> >remove a lot of the hacky things. But I fear this might
> >break some things.
> >
> >So, what do you think?
> >  
>


The inability of a sitemap to resolve relative references outside of itself
is the biggest bugbear I have with Cocoon.  The ability the have a hierarchy
of sitemaps allows me to modularise my applications very nicely but not
being able to refer to a pipeline in another sitemap, except by an absolute
reference, completely destroys the advantage of doing so.

Here is an example from my current Cocoon application:

The application consists of a number of different areas of functionality and
each area is being developed by separate developers.  It makes sense take a
modular approach and use separate directories and sitemaps for each
functional area so that each developer can work independantly from the
others and so that all files for a particular function are easily
identifiable.  By having a directory hierarchy and automounting sitemaps,
everything is sweet.

However, a number of screens contain a particular collection of list boxes
that require some complex processing to produce.  Rather that have each
developer reimplement this, a common module has been developed and each
developer uses cinclude to incorporate the XML to implement the listboxes in
the appropriate place in their screen code.  The problem is that because the
common code is in a separate sitemap it cannot be referenced to using a
relative cocoon: reference, only an absolute reference from the Cocoon root.

This becomes a problem when I need to run a second copy of the application
on the same server, say as a training or testing system.  Ideally I should
just be able to make a copy of my original application and give it a
different root directory name.  The problem is that this copy now contains
absolute references to pipelines in the original.

Their are a number of workarounds (separate copies of Cocoon for instance)
but they all lead to design ugliness.


Cheers,

Dean


************************************************************************
MIMESweeper has been used to check this email for security
************************************************************************


Mime
View raw message