cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: Block resources in 2.2 (Forms in particular case)
Date Sat, 27 Jan 2007 15:39:13 GMT
Daniel Fagerstrom napisaƂ(a):
> Grzegorz Kossakowski skrev:
>
> Yes, there is the blockcontext source. See
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=116326232408386&w=2
> for background and
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/blocks/sitemap.xmap
> and
> http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/META-INF/cocoon/spring/cocoon-forms-sample-blockServlet.xml
> for usage examples.
>
> But the blockcontext source is mainly intended for Cocoon internal
> use. Using it in applications for getting resources is somewhat
> analogous to accessing private methods in other classes in Java.
Ok, got it. So let's forget about this component, now.
>
>> If so, should I add sitemap to the cocon-forms-impl just for serving
>> resources? (personally I do not feel it like overkill)
>
> I don't understand the above sentence, does it feel like overkill or not?
I meant: Someone could see this as overkill but I, personally, would not
agree with him. I think using sitemap for this purpose is good choice
because:
1. Everyone who hack with Cocoon knows sitemaps, it's syntax, behavior etc.
2. Sitemaps give great deal of flexibility (think about compatibility
issues after some heavy refactoring, maintaining old solutions)
3. If we introduce another servlet, we have to introduce some amount of
configuration to it. It means /another/ syntax to learn, working-around
the limitations of config by ugly hacks and so on.
>
> Anyway, I would recommend adding a sitemap for serving resources. By
> doing that the power of the servlet service framework with
> polymorphism and configurability etc becomes available. Also it saves
> the user from having to write a couple of extra sitemap rules for
> serving cforms resources.
+1
>
> If it feels like overkill to use a sitemap servlet for serving
> resources, we could later write a special puropse resource serving
> servlet for doing that.
-100 (see reasoning above)
>
> It would probably also be a good idea to split out the resources and
> the servlet service from cocoon-forms-impl to an own block.
>
It I came with working prototype of Forms heavily exploiting new
features of servlet-service-fw, we could think about it later on.

-- 
Grzegorz Kossakowski

Mime
View raw message