cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Hunsberger" <>
Subject Re: [PROPOSAL] Block conventions
Date Wed, 14 Mar 2007 18:04:41 GMT
On 3/14/07, Grzegorz Kossakowski <> wrote:
> Peter Hunsberger napisaƂ(a):


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


> >
> > 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
View raw message