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
