cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@cup.hp.com>
Subject Re: [summary] Cocoon Blocks
Date Fri, 12 Apr 2002 19:02:16 GMT
On Fri, 12 Apr 2002 16:11:25 +0200, Stefano Mazzocchi <stefano@apache.org> wrote:

> I thought about postponing the design of Cocoon Blocks after Cocoon 2.1
> was released, but since many people seem to expect better user-level
> componentization of Cocoon sooner rather than later, I want to write a
> short summary describing the status of its design so that we can decide
> what to do.

Yes, I also think we need to proceed sooner on this.

<skip portions I agree with/>

>                                    - o -
> 
> Here is a temptative schema for the CB contract (CBC)
> 
>  <contract xmlns="http://apache.org/cocoon/block/contract/1.0">
>   <info>
>    <name>MyContract</name>
>    <description>This contract does this and that</description>
>    <version>3.2</version>
>   </info>
>   <resources catalog="catalogs/mycatalog.catalog">
>    <pipelines>
>     <pipeline href="news" type="text/xml" actions="GET"/>
>    </pipelines>
>    <views>
>     <view name="content" actions="GET"/>
>     <view name="links" actions="GET"/>
>     <view name="edit" actions="GET,POST"/>
>    </views>
>    <files>
>     <file src="hello.xml" type="text/xml"/>
>     <file src="stylesheets/whatever2html.xslt" type="text/xml"/>
>     <file src="images/logo.gif" type="images/gif"/>
>     <file src="stylesheets/default.css" type="text/css"/>
>    </resources>
>    <components>
>     <role name="org.mysite.mycomponent.DoThisComponent"
> shorthand="dothis">
>       <hint shorthand="white"/>
>       <hint shorthand="black"/>
>     </role>
>    </components>
>   </resources>
>  </contract>
> 
>                              - o -
> 
> Issues:
> 
>  1) MIME types are not enough to describe an XML file in full detail. A
> better way would be to indicate the namespace of the root element, this
> is equivalent of weak typing, but might be enough for a brief validation
> check of the contract.
> 
>  2) pipelines and views are very hard to describe in a meaningful way.
> The above is just a wide guess, any comment is very appreciated in this
> area.

Why do we need to have pipelines and views described in a block? If
the block has a visible interface, then it should provide its own
sitemap, to be mounted in the system. Should this sitemap make use of
other resources and views from sitemaps in other blocks? I don't think
this is a good idea, a sitemap should be self-contained. It should be
able to make use of components from other blocks, but not views and
resources.

Also why do we need to have the roles section in the contract?  IMO
this could be outside of the contract, specified in a separate file,
so that we can reuse the existing Avalon support for user roles.

The <files> section should perhaps be renamed to <exports>, to convey
the meaning of it.

>  3) even if contracts are very likely to become verbose, we should not
> be using wildcards or the contract will become instantly weaker.

I'm afraid I don't understand this. Are you talking about wildcard
URIs in the matchers?

>  4) components don't need to provide versioning for their interfaces
> since that goes along with the contract version.
> 
> All right, might not be totally complete, but I'd like to proceed
> incrementally and have your feedback before going on.

I haven't seen anything on the block execution context. Is a block
going to be loaded inside the same class loader as Cocoon? Are we
going to use separate class loaders to run protected blocks?

Also how about having blocks act as servlets? This way we can make use
of the existing infrastructure of many app servers to manage the
blocks. Security might also come with it, I don't know.

Regards,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message