forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: Locationmap - because we can doesn't mean we should
Date Wed, 07 Dec 2005 13:27:05 GMT
El mar, 06-12-2005 a las 09:27 +0000, Ross Gardler escribió:
> Tim Williams wrote:
> > As the subject indicates, I'm thinking we might be using the
> > locationmap in some places where sticking to the sitemap would be much
> > more readable.  Some of the multiple levels of indirection that's
> > going on is down-right confusing.  I'm pretty comfortable reading both
> > sitemaps and locationmaps and it's confusing to me.
> 
> By "levels of indirection" do you mean the fact that there are a 
> wholeload of properties in forrest.properties (like project:content) 
> which are then used in the locationmap?
> 
> If so these will be removed (there is an issue for this). The idea is 
> that the Locationmap becomes *the* configuration file for location 
> relate config. The new, XML based config system I have introduced is 
> intended to be used for none location related configuration. However, 
> this is still to be approved by the community.
> 
> With respect to some other aspects you will see in the SVN log from the 
> last Forrest Friday that David raised this point and I agreed. What we 
> need is some clear guidelines as to when we use the locationmap and when 
> we don't.
> 
> My proposal for this is that we use the locationmap for any resource 
> that we want to expose to other parts of the system. For example, 
> transformations.
> 
> > I suggest that locationmap references from the sitemap should be one
> > way.  In other words, we should not see "cocoon://some.resource" in a
> > locationmap.
> 
> +1 - in principle
> 
> I can think of no need to do this since the locationmap can use "lm:" 
> within itself.

Hmm, what about locations that are needed to be generate and are not on
the file system (like a prepared contract)? If we do not allow
"cocoon://" in the locationmap the user will be forced to override this
locations in a custom sitemap, where else this is not needed if we allow
"cocoon://" or any other protocol.

In my definition the "cocoon:/" protocol is a source location as any
other.

> 
> >  It only leads to a tail-chasing sitemap.  I'm not sure
> > of a real clear way to explain it but the locationmap should be a
> > mapping to the physical resource, whereas, in some of our usage it has
> > become an extension of the sitemap processing.
> 
> +1 - can you give a few examples of where you feel that the locatinmap 
> should not be used (perhaps in the form of patches since we can always 
> revert those if others disagree).
> 
> > Is this is a reasonable guideline for locationmap usage?
> 
> Yes :-)

I do not know, where do we draw the line? 
Do you mean we only allow file system resource (that means only
file:///...) when referring to physical resource? If so what is with
e.g. zip://... or any other possible protocol?

...and last but not least "...an extension of the sitemap processing" -
yes that is what the locationmap is all about. It is an extension of the
sitemap for resource resolving. ;-)

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


Mime
View raw message