On Fri, 12 Apr 2002 16:11:25 +0200, Stefano Mazzocchi <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
