cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: [cocoon-2.2] Deprecation
Date Wed, 14 Nov 2007 21:15:52 GMT
Grzegorz Kossakowski wrote:
> 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.

Ok, good to know. What do you mean "not shared"? Does it mean request parameters 
of original response are not available?


> Note that there
> is no servlet://, at least as far as I know.

Yep


>>> 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?

Stuff which could be done before mount; "intercepting" request before they drop 
into sub sitemap; stuff which can be done after mount if sub-sitemap returns 
w/out response; providing "default" handlers.


> 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.

If it is more self-contained, it becomes less reusable. For example, same error 
handling can not be good for all situations. E.g., compare internal error 
handling vs external error handling.


> 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?

For example, to provide isolation between different parts of application(s)... I 
imagine portal block might be a heavy user of this. Is it?


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

Today's hardware is too slow for Cocoon + Maven 2... :(


>>> 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 first step IMHO should be to make sure core Cocoon 2.1 functionality is 
working. Take a look at "Core Samples". Once all of them are working I'd be more 
comfortable discussing all other steps.

Vadim


> 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.
> 


Mime
View raw message