El jue, 19-01-2006 a las 11:33 +0100, Andreas Hartmann escribió: > Thorsten Scherler wrote: > > [...] > > > The locationmap provides a matching mechanism that is fully configurable > > were the fallback:// is expecting the files in a fixed defined path > > (e.g. lenya/xslt/some.xsl) forcing the dev/user to imitate/adopt this > > structure. Meaning *lenya* defines the location (I hate to be forced to > > do something). ;-) > > Hmmmm ... I have to admit that I consider the location contract > appropriate in this context. Configuring this would IMO be too > much flexibility.
Why? The contract is *forcing* to extend the sitemap if you do want to override the matching. see below when it becomes really bad. > > [...] > > > Now to why I think > > "Fallback provides an implicit mapping, which IMO is > > > >>sufficient for publication templating. " > > > > is not true. Imagine images or design resources in general in a > > multi-pub environment, here I do want to have full control over the > > mapping. > > Why would it not be sufficient? > If you use e.g. an external asset management system, which has its own mapping for images. You will end up to either not use the fallback:// for that and implement customized matching in the sitemap. Then you loose the fallback mechanism and need to implement your own one mostly by adding source.exist actions into the sitemap till it becomes unreadable. Or you use the fallback and copy all stuff to the fallback:// conform structure. Either way far too much work when it could be as easy as extending the locationmap with (e.g.): <location src="http://assetManagementSystem/images/imageXY.jpg"/> or <location src="http://assetManagementSystem/images/{1}.{2}"/> ...and one thing what I really do not like is to duplicate resources or doing extra work if I do not have to. *copyless* should be our philosophy like in forrest. > > > Further I activated actions in the locationmap when I wrote an implicit > > mapping action > > http://svn.apache.org/viewcvs.cgi/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/src/java/org/apache/forrest/structurer/acting/RecursiveDirectoryTraversalAction.java?rev=320710&view=markup > > > > This is a fallback mechanism that we have in the dispatcher to match > > view definition files. > > > > > >>Why do we need more flexibility? > > > > > > To keep the site structurer open and not forcing to use the lenya > > default one. IMO this adds to the entry barrier understanding lenya. > > When I started I never really understand why some files *have to* go > > into dir a and others in dir b. Let the user/dev decide this mappings. > > I still disagree. If I'm familiar with a publication, I'd expect the > corresponding files in instances in the same locations. > Hmm, yeah *if* you are but not for the new user! I can tell the new user: Dude look in locationmap.xml and you find all the places where you put stuff into. ...and I can tell you the same and both have the same knowledge. Like you stated your condition is that you have to fully understood a pub, the locationmap is independent from the understanding of a pub which makes it highly reusable in any cocoon based app besides a lenya pub. I prefer to understand something globally workable then something that is limited to one project. > > >>The major point to convince me would be to switch to an established > >>solution instead of using our own implementation. > > > > > > That is another point, what do we gain with the fallback:// what the > > locationmap cannot gives us? If the answer is: nothing. Then I say we > > are having the "luxury" of duplicate code, which is bad for maintenance. > > Our committer base is still quite small and should focus on stuff that > > we do not duplicate. Let forrest worry about locationmap maintenance and > > if we find a bug we can fix it in their rep right away since we all have > > write access there. I say pretty good deal. ;-) > > I agree to this statement. But I'm not convinced that we should allow > to configure the locations. ¿Why not?, like stated above you always can look up the matching mechanism. salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
![http://assetManagementSystem/images/imageXY.jpg"/](http://assetManagementSystem/images/imageXY.jpg"/){kind=link}