cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: [2.2] Servlet service: polymorphism and connections
Date Fri, 20 Feb 2009 19:07:18 GMT
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.

-- 
Best regards,
Grzegorz Kossakowski

Mime
View raw message