cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Hunsberger" <peter.hunsber...@gmail.com>
Subject Re: [PROPOSAL] Block conventions
Date Wed, 14 Mar 2007 14:57:15 GMT
On 3/14/07, Grzegorz Kossakowski <gkossakowski@apache.org> wrote:
> Peter Hunsberger napisaƂ(a):
> > On 3/14/07, Grzegorz Kossakowski <grek@tuffmail.com> wrote:
> >>
> >> I think that following "convention over configuration" here is really
> >> good idea and most users will take this advice. It
> >> help newcomers to focus on actual work, and it will help block's
> >> ecosystem because standardized URI spaces facilitate
> >> block's cooperation.
> >>
> >> Comments? Thoughts? Anyone objecting?
> >
> > Almost makes sense at a theoretical level, but I don't think it's
> > practical. Theres ths eimple concerns:  what does someone who is
> > already using Cocoon do when they want to migrate to 2.2 and their
> > existing URI space doesn't match up?  Do we force them to change their
> > URI space?  What if someone is integrating with a CMS or some other
> > system that has other URI requirements?
>
> In both cases nothing bad happens. Their block is just little bit more
> difficult to use from other blocks (that follow conventions) but no more
> difficult than in situation that there is no convention at all. Proposed
> URI spaces are only good practices, you can ignore (and even remove from
> the sitemap) all proposed matchers and do everything the way you like.

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

> > However, more importantly, with blocks you want to have the equivalent
> > of name spaces for the blocks: plug in some component and have it
> > handle the resources in it's URI space without conflicting with the
> > URI space for some other block (eg. two blocks migh each have a
> > "main.js" or some such thing), so for this to work you'd need to
> > either prefix or suffix the URI space for each block with some unique
> > block identifier which sort of defeats the point of doing this in the
> > first place or am I missing something?
>
> Ahh, I think that it's right time for you to have a look on the
> servlet-service framework ;-)
> Block's URIs are already prefixed by servlet-service framework. The prefix is defined
in mount-path property, like here:
> [1]. What's really important, block's author should not bother about this prefixes. Take
a look at this[2]:
>    dojo.registerModulePath("cocoon.ajax", "servlet:ajax:/resources/ajax/js"); // cocoon.forms
has a dependency on the
> cocoon.ajax module libraries
>

<snip/>

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

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?

>
> >
> > We may be able to support a default convention, but I think you're
> > going to always need configuration for a URI space...
> >
>
> Maybe I'm repeating myself but I want it to be clear: what I have shown is only proposition
of sitemap's skeleton.
> Sitemap where the default pipelines are defined is still yours and you are free can tweak
it (by overriding default
> rules e.g.).
>

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

-- 
Peter Hunsberger
Mime
View raw message