Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <49A2639F.3030209@apache.org>
Date: Mon, 23 Feb 2009 09:51:43 +0100
From: =?ISO-8859-15?Q?Reinhard_P=F6tz?= <reinhard@apache.org>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [2.2] Servlet service: polymorphism and connections
References: <gnmlk3$hit$1@ger.gmane.org> <499EFF66.3030906@tuffmail.com>
In-Reply-To: <499EFF66.3030906@tuffmail.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

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
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________