On 3/14/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote:
Peter Hunsberger napisał(a):
> On 3/14/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> 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
