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
