cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: [cocoon-2.2] Deprecation
Date Wed, 14 Nov 2007 20:35:22 GMT
Vadim Gritsenko pisze:
> Grzegorz Kossakowski wrote:
>> Vadim Gritsenko pisze:
>>
>> servlet: + map:mount combo is bad idea either because contexts would
>> not be resolved correctly. I
>> mean: if use URL like "servlet:/something" in mounted sitemap Cocoon
>> resolve it using base sitemap.
> 
> Ok but what about "servlet://something"? In other words, are there any
> differences between "cocoon://" (note double slash) and "servlet:/"?

None apart from the fact that the environment is not shared when servlet:/ is used. Note that
there
is no servlet://, at least as far as I know.

>> Of course we could fix that quite easily but the question is why to do
>> that?
> 
> Personally I can live without "cocoon:/" (single slash), so I'm fine if
> it goes away.
> 
> 
>> Instead of using servlet: protocol + map:mount you should just create
>> several separate
>> SitemapServlet beans mounted at different paths
> 
> But this would not provide same functionality as <map:mount>. It would
> not give same sitemap procession logic, would not give same error
> handling capabilities, and would not have same container hierarchy.

What do you mean by "sitemap procession logic" exactly?
When it comes to error handling capabilities - agreed, this is a serious functionality loss.
On the
other hand, I would like to have sitemap more self-contained not relying on their position
in
sitemap hierarchy. In order to avoid bloating sitemaps by the same error-handling constructs
you
could use a shared block that would handle errors. Other sitemaps would delegate error handling
by
using postable source.

Why do you need a container hierarchy? I'm just wondering if there is a really, really good
use case
for container hierarchy. Could you give examples?

>> or split your application into a few blocks if it makes sense.
> 
> This is not really feasible, not for another 2-3 years...

Why?

>> Anyway, general thought that servlet: protocol + creation of several
>> SitemapServlet beans offer
>> similar functionality to cocoon: protocol + map:mount is right.
> 
> Hm I don't think I agree.

Not a problem for now as I'm happy to continue discussion as long as there are a new arguments
being
revealed. Anyway, I really think we should not stop the evolution.
I wonder how many people share my feelings that we badly need to cut some of the crappy code
of our
core if we want to move on. The first step to do this is deprecate, the second is to provide
good
replacements and Servlet Service Framework is a good *candidate* IMHO. The third step would
to
remove that code in the end but it's not going to happen in the month.

-- 
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/

Mime
View raw message