forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Locationmap - because we can doesn't mean we should
Date Wed, 07 Dec 2005 16:33:54 GMT
Thorsten Scherler wrote:
> 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.

I don't understand your point, can you please give an example as an 
illustration.

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

No, the cocoon: protocol defines which pipeline to use, the locationmap 
defines the location of the source.

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

I don't think Tim is suggesting that we restrict the range of protocols 
in use. I think he is merely saying that we should not be creating an 
additional level of indirection between the sitemap (which defines what 
processing to apply) and the locationmap (which defines the location of 
resources used in that processing).

Ross


Mime
View raw message