> 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 ************************************************************************
