El mié, 07-12-2005 a las 08:55 -0500, Tim Williams escribió:
> On 12/7/05, Thorsten Scherler <[EMAIL PROTECTED]> 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 "...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. ;-)
>
> 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.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
