forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: Locationmap - because we can doesn't mean we should
Date Wed, 07 Dec 2005 17:31:42 GMT
El mié, 07-12-2005 a las 08:55 -0500, Tim Williams escribió:
> On 12/7/05, Thorsten Scherler <> wrote:
> > > 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}" />
>       </select>
>     </match>
> Then I don't see the value of bouncing to the lm just to go back to
> the sitemap.

Ok, the last point I agree: "bouncing to the lm just to go back...". I
disagree regarding the "generated" part. You are right the above example
do not add value it is just ping-pong (bouncing back). 

Anyway I am not sure whether the following would work but if you have x
locations (all cocoon://) then I think it makes sense, trying to say
"only" because it got generate is not an exclusion mechanism. I would
rather say not to use the location map if you have only one match.

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

See above I agree with the example you have provided but generally
speaking if you have different locations of cocoon:// then it would be
alright to use it in the lm. I do not think we should limit/forbid to
use cocoon in the lm.

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

Hmm, but what if the current sitemap does not have this information
(e.g. communication between two plugins, where plugin a do not know the
sitemap links of b)

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

Yeah, +1 

...but I would not say that in general you/we should not use cocoon: in
the lm

Thanks for explaining you better.


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

View raw message