cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: [PROPOSAL] Block conventions
Date Wed, 14 Mar 2007 15:28:35 GMT
Peter Hunsberger napisaƂ(a):
> The question is whether this convention is generally usable?  For me,
> I can tell you that I would probably not use it, I already have other
> conventions in place for naming and finding resources that I don't
> want to change.  No point in having a convention if it isn't generally
> usable.  Guess I need to hear if other people would find this
> generally usable...

I think that you and me are not good examples of the person for whom
this functionality is going to be useful as we are really experienced
Cocoon-hackers. You have your own convention, I can have my own and we
can live it that happily. I think that you would agree that some
convention is really needed.
What I want to do is to help Cocoon newbies to start actual playing with
Cocoon (instead of reading poor documentation) as quickly as possible.

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

> I get all that, and that's the point: you already have to configure
> the block when you create it and you have to know the name of the
> resource at the time you use it.  So for a resource that now falls
> into the general "external" URI name space you still have to know what
> it is named.  What _really_ is the difference whether the user of a
> resource has to specify:
>    external/foo.js
> or something like:
>   servlet:bar:/foo.js

The first one is actually equal to the:
So first path is relative, the second absolute.

> If I'm a front end developer I just consider "servlet:bar" part of the
> way I name foo and go on with my business.
> 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...

(I'm really running out of ideas how to explain this)

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

Grzegorz Kossakowski

View raw message