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.
> 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
This javascript fragment comes from Forms block and refers to the ajax block.
We do not bother ourselves here about
actual prefix of ajax block (which is 'cocoon-ajax-impl'). For block's writers
and users the only important part of URI
is after that prefix. And you have a guarantee (from servlet-service-fw) that
if you create some URI under this space
it's going to be Cocoon-wide unique.
I would really suggest to take a look at my work in whiteboard because it shows
quite well implementation of most
servlet-service-fw ideas. It's enough to do svn switch, rebuild both blocks and
look at samples (under
/blocks-test/cocoon-forms-sample/).
>
> 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.).
Hope that it helps a little bit.
[1]
http://svn.apache.org/repos/asf/cocoon/whiteboard/ajax-forms-refactoring/cocoon-forms/cocoon-forms-impl/src/main/resources/META-INF/cocoon/spring/cocoon-forms-impl-blockServlet.xml
[2]
http://svn.apache.org/repos/asf/cocoon/whiteboard/ajax-forms-refactoring/cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/js/manifest.js
--
Grzegorz Kossakowski
