On 3/14/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote:
Peter Hunsberger napisał(a):
<snip/>
What I think is little funny that we discuss so extensively so little, small change that is not going to harm anyone experienced with Cocoon...
Small changes have a way of becoming institutionalized; the next thing you know two years from know someone will be saying this is the proper/only way to do things, or someone will build some kind of complex functionality that would be generally useful if only it didn't have hard coded built in assumptions... <snip/>
> > Which raises the question; what do you plan to do if two or more > blocks have a resource with the same name in their "external" > directory? Really nothing... If blockA has external/foo.js and blockB has external/foo.js there is no trouble in such a case. From the blockC perspective, first resource is available under servlet:blockA:/external/foo.js and the second under servlet:blockB:/external/foo.js. This are two absolutely different paths. No option for name clashes...
What's the relative path for each? What happens if I started out with only blockA and had coded dependencies on the relative path for it and then later I add blockB (perhaps not even realizing it contains a foo.js)?
(I'm really running out of ideas how to explain this)
Maybe I'm missing something about how these both would be made available in the site map?
> > Sure, and I don't think it's a bad idea. I'm just not sure it's > useful enough to try and define it formally. No point in defining a > convention if no one is going to use it.... > I agree. Most Cocoon developers won't use it, but there are (hopefully) folks using Cocoon who are not Cocoon developers/hardcore hackers...
That's actually an open question from what I can tell; some people are undoubtedly attracted to Cocoon because they think it won't take much work to configure or customized but it seems to me that it rarely works out that this is true... -- Peter Hunsberger
