cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <>
Subject Re: [2.2] Servlet service: polymorphism and connections
Date Mon, 23 Feb 2009 08:51:43 GMT
Grzegorz Kossakowski wrote:
> Andreas Hartmann pisze:
>> Hi Cocoon devs,
> Hi Andreas,
>> I wonder if the servlet service framework can be used to implement
>> the following scenario:
>> There is an "abstract" block called "document-type" (think of a
>> document type for a CMS, actually it's about Lenya). This block
>> declares (in the sense of a convention) particular services,
>> without actually implementing them, e.g.
>> /services/schema.rng (provide Relax NG schema for validation)
>> Other generic blocks operate on arbitrary document types. E.g., the
>>  "editor" block could invoke a validation step before a document is
>>  saved. Now I imagine something like this in the editor block
>> sitemap:
>> <!-- {1} is the block name of the actual document type --> 
>> <map:match pattern="schema/{*}"> <map:read
>> src="servlet:{1}:/services/schema.rng"/> </map:match>
>> I guess this works if the block servlet declaration of the editor
>> block contains connections to all actual document type blocks
>> (extending the "document-type" block) that exist in the
>> application. But since the CMS should be easily extensible with new
>> document types, I think we can't require to register each document
>> type with each generic block that operates on document types.
>> Does it make sense at all to implement such a scenario using the
>> servlet service framework? If yes, is there a way to achieve this
>> behaviour using the current implementation? Could I just register
>> the service connections programmatically (e.g., using a standard
>> init-method of a bean in the actual document type blocks)?
>> Thanks a lot in advance for any comments!
> In my opinion SSF does not suit your job. I see blocks + SSF as a
> powerful way to structure your application. SSF's capabilities allow
> you to extend application's logic.
> What you want here is not really enriching your application logic as
> it seems to be very well defined. You want to simply enrich the data
> it operates on. For this purpose I guess your own protocol fetching
> resources from CMS's database would be better. Of course inside your
> protocol's implementation you can use servlet: protocol for default
> values.
>> BTW, sorry for posting this to the dev list, but actually I'm
>> afraid the current SSF doesn't support this, and I'd be interested
>> in your opinions if this concept should be supported at all.
> I don't think this kind of use-cases should be handled by SSF which
> have already well-defined purpose that I would like to keep
> untouched.

I agree with Grzegorz, this use case shouldn't be covered by the SSF.

Andreas, have a look at "bean-maps" which are provided by the Spring
Configurator. You could have your validators implement a particular
interface and then you can collect them by using a bean-map. The you can
implement a validator servlet-service that uses this bean-map and does
the validation. Of course the last step is only necessary if you need to
get access to the validator services by using the servlet protocol.

Reinhard Pötz                           Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member        

View raw message