You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2007/03/14 14:18:23 UTC

[PROPOSAL] Block conventions

Hi,

I would like to propose some conventions in block's structure. I mean here a structure that matters on sitemap level not
on the lower levels (servlet-fw, packaging, etc.). I think we should advise some guidelines when it comes to the
exposing resources and services to the outside world.

That said I propose to have following URI spaces:
* resource/external/** - resources in this space are meant to be accessible from the outside of Cocoon. It would be
mainly a CSS/JS, etc content.
* resource/internal/** - this resources would be only accessible from other blocks/servlets mounted in Cocoon's
instance. They would mainly consist of XSLT, XML, JX files that one block likes to expose to the others.
* service/** - pipelines in this URI space would be only those which can consume POSTable requests. In short, here would
all block's servlet services services be exposed.

Accordingly, following directory structure would be advised:
<block's context>
  * resource
      * external
      * internal

Also we should reflect this in sitemap created by archetype:
<map:pipeline id="internal-resource" internal-only="true">
  <map:match pattern="resource/internal/**">
    <map:read src="resource/internal/{1}"/>
  </map:match>
</map:pipeline>

<map:pipeline id="external-resource">
  <map:match pattern="resource/external/javascript/**">
    <!-- Usage of this reader guarantees that all possible links in JS are properly handled -->
    <map:read src="resource/external/javascript/{1}" type="servletLinkRewriter">
  </map:match>
  <map:match pattern="resource/external/**">
    <map:read src="resource/external/{1}"/>
  </map:match>
</map:pipeline>

<map:pipeline id="service">
  <!-- put your service pipelines here -->
</map:pipeline>

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?

-- 
Grzegorz Kossakowski

Re: [PROPOSAL] Block conventions

Posted by Grzegorz Kossakowski <gk...@apache.org>.

Felix Knecht napisał(a):
>
> > 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.
>
> I don't see such a big benefit. E.g. If a user has an application
> using some forms he still needs to take care in the sitemap which
> matchers shall be exposed externally and which not (think e.g. about a
> multi-page formular and you only want to expose the starting page).
I agree that my proposal does not cover such case you have given as an
example. The point is that it shouldn't. I think that most blocks that
user is going to create will expose some resources and/or services to
the outside world and I think all blocks should do this in similar way.

When you create block's specific functionality (forms, pages) it's
obvious that you have to create block's specific pipelines. I do not
call this into question. My proposal is only skeleton (archetype) for
further tweaking (extending, stripping).
> IMO it will be more confusing (and therefore it may by dangerous)
> having some resources exposed/not exposed by default.The developer
> must decide anyway how the pipeline shall be (internal/external). It's
> not only a design but also a question of security.
Actually, until you put something in resource/external directory nothing
is really exposed. By default you have only provided a directory
structure which can be filled according to your needs. I don't see this
confusing as I cannot think about something more obvious than that
resources under "resource/external"are accessible externally.

To provide an example, I'm refactoring now Ajax and Forms blocks. They
both have some resources that should be exposed to the browser (css and
js files) and they both would be exposing some services. I'm going also
to make as a service samples styling so cocoon-samples-style is going to
expose some css files and actual service. I can give you more examples
if you need...

-- 
Grzegorz Kossakowski

Re: [PROPOSAL] Block conventions

Posted by Felix Knecht <fe...@otego.com>.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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

I don't see such a big benefit. E.g. If a user has an application
using some forms he still needs to take care in the sitemap which
matchers shall be exposed externally and which not (think e.g. about a
multi-page formular and you only want to expose the starting page).

IMO it will be more confusing (and therefore it may by dangerous)
having some resources exposed/not exposed by default.The developer
must decide anyway how the pipeline shall be (internal/external). It's
not only a design but also a question of security.


Felix
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF9/og2lZVCB08qHERAlipAKDWeWhrLktrlSKdbWa2fw9LGsbG+QCbB3OB
/AIuPX5kYwEfDfjQWFd2yl8=
=1i3d
-----END PGP SIGNATURE-----