forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <>
Subject Re: Locationmap - because we can doesn't mean we should
Date Wed, 07 Dec 2005 13:55:53 GMT
On 12/7/05, 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 (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.

I think if it needs to be "generated," then it belongs in the
project-level sitemap.  I see no added value in referencing the
locationmap only to point back to the sitemap.  If you give a couple
snippets of an example of the "prepared contract", maybe I'll see the
value better.  If it's a part of a multi-location exists selector, I
may get it -- I'll have to think more, but if it's just like this:
    <match pattern="structurer-properties.*.**">
      <select type="exists">
        <location src="cocoon://prepare.structurer-properties.{1}.{2}" />
Then I don't see the value of bouncing to the lm just to go back to
the sitemap.

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

I don't know.  That's what I'm hoping we can figure out with this
discussion;)  I think readability becomes compromised when
locationmaps have cocoon:// references.  Beyond that, I suppose other
protocols are fine.

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

Yeah, was afraid that my meaning wouldn't come across very well.  I
don't know how to phrase it by I see them as different, simple vs
generated I suppose (I do recognize that this is illogical at some
level because all resources are ultimately pieced together).  I reckon
if we've got a sitemap that has two cocoon://locations in it, one
referencing the other, I don't see the value added in consulting the
locationmap to resolve a resource that the sitemap already knows
perfectly well how to deal with.  Beyond that, even if there is a
small benefit, I'd suggest that the impact to readability is not a
worthwhile tradeoff -- in other words, I value the ability to easily
read the processing over the benefit received.


View raw message