cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: [PROPOSAL] Block conventions
Date Wed, 14 Mar 2007 14:29:23 GMT
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.

> 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

Mime
View raw message