Stefano Mazzocchi wrote: > +---------------------------------------------+ > | I propose the adoption of the Avalon Block | > | design pattern to modularize Cocoon's user | > | level and avoid the increase of disorder. | > +---------------------------------------------+ > Cool !
>This, in short means: > > 1) Cocoon will be seen as an empty container. Provides basic framework >functionalities and block containment, but no feature on its own. This >explicitly resurrect the IoC pattern used in servlet engines, where the >functionality is packaged in servlets or webapps and the servlet engine >only provides services around that, with inverted control. > > 2) User functionality will be encapsulated in Cocoon Blocks. Using >Cocoon will mean to deploy one or more Cocoon Blocks on top of Cocoon. >These blocks will be *mounted* on a specific URI point and will be >called by Cocoon when they need to act (follows the IoC pattern). > Sounds good. - Does this mounting also apply to "non-URI-visual" blocks in your vision ? Some blocks expose themselves as web applications, some provide features for others, but are not useful seperately, like skins or "webapp language/i18n packages" or the like. - Does mouting on a specific URI point speak of the public/web URI space ? As we can have pipelines that are internal-only, a similar feature to a block might extend that thought. > 3) These Cocoon Blocks contain file resources (raw or precompiled) and >compiled bytecode (as individual classes or JAR libraries). > Each block brings it's own Jar's along ? Would something like a "library" Cocoon Block containing JARs, generators and the like make sense ? <snip/> > d) a URI-based protocol will allow polymorphic access to cocoon blocks >and inter-block sharing of resources. The proposed syntax is > > block(role):/path/file > >and > > block(role):component > >for example > > block(skin):/stylesheet/document2html.xslt > block(calendar):date-generator > >NOTE: the above is compatile with the URI syntax as described in RFC >http://www.ietf.org/rfc/rfc2396.txt. > Oh, good to know; thanks for the link. >In case the block role is ambiguous, it will be used as a namespace >prefix, as in > > <map:match ...> > <map:generate src="block(role):/path/file" >xmlns:role="http://www.role.com"/> > <map:transform src="block(role):/path/file" >xmlns:role="http://www.myrole.org"/> > </map:match> > >if the block-based URI is used in non-namespaced syntax (for example, in >the flowmap), an API-based solution will be provided. > Declaring a namespace prefix for resolving role ambiguities looks a bit like a hack; if there is only one ambigious block role per map:generate/map:transform, we might as well use an attribute called role which would allow this "role override" feature. A thought, when there is a role ambiguity, it will happen across the whole sitemap/flowmap, right ? So anyone developing in this situation will start to add xmlns:role/role to resolve block role name clashes at map:generate/map:transform-level, which does not sound right to me as it is too late. If we somehow added a block role resolution like <xmlns:some="thing"> does it for <some:test/> (perhaps in a section to the sitemap/flowmap or a seperate file), developers can have role names in their Cocoon Blocks resolved as they need in a consistent manner, and I guess we could handle block(role)-type URLs more easily in the SourceResolver than with the xmlns:role/role-attribute approach. Best regards, Michael Hartle, Hartle & Klug GbR --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
