forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
Subject Re: Locationmap - because we can doesn't mean we should
Date Wed, 07 Dec 2005 17:58:00 GMT
On 12/7/05, Thorsten Scherler <thorsten@apache.org> wrote:
> El mié, 07-12-2005 a las 08:55 -0500, Tim Williams escribió:
> > On 12/7/05, Thorsten Scherler <thorsten@apache.org> 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.

I reckon I'd have to see an example.  If there are multiple cocoon://
locations in an exists selector in the locationmap, then I'm thinking
that the resources themselves should be made more efficient (e.g. an
exists selector in the generator).


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

I'm not suggesting programatically limiting, only some best practice
guidelines. As I say, I'm not convinced of any good need to have
multiple cocoon:// resources in an exists selector in a lm but I'll
not belabor the point.  I'm content for now if we can agree that a
location reference to a single cocoon:// resource is, generally, not
desirable.  If I see a concrete example of the multiple cocoon://
selector, then I'll highlight, but I don't want to waste folks time
with a debate on it now.

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

I'm not sure how that's different between two plugin locationmaps. 
Orchestration between plugins in general isn't very sort of manual and
requires knowledge of both ends right?

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

Thanks, I think we're generally in agreement, if you want to provide a
good example of the multiple cocoon://'s in a selector great,
otherwise, I'll just bring it up when I see a concrete example.
Thanks again,
--tim

Mime
View raw message