cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: HttpServletRequest vs o.a.c.e.Request saga continues
Date Mon, 30 Jul 2007 20:55:43 GMT
Daniel Fagerstrom pisze:
>>
>> Good point. I agree that we should keep these methods available but, 
>> AFAIK, they are used only to handle cocoon: source and sitemap mounts.
> 
> They might be used by users in JXTemplate and flowscripts as well.
> 
>> This functionality should be replaced by cocoon-servlet-service-fw and 
>> cocoon: source plus map:mount should be deprecated in the near future, 
>> right?
> 
> I think we should recommend people using servlet services instead of 
> cocoon: and map:mount. But deprecating cocoon: source and map:mount 
> would probably affect tons of existing webapps. I don't think it would 
> be worth it.

I would like to deprecate them in 2.3.x version of cocoon's core so they would be removed
in 2.4.x.
I hardly can imagine application developed with Cocoon 2.1.x that anyone could want to run
with 2.4.x.

What about Marc's opinion[1] on dragging our history with us? I really agree with his opinion.

Thanks to your work we can let cocoon: and map:mount rest in peace and remove a decent amount
of code handling cocoon: calls.

>>> Four options with the one I described above.
>>
>> Where exactly? Do I miss something?
> 
> What I mean (above) is that in CocoonEntryObjectModelProvider you are 
> filling the request and response fields with HttpSevletRequest and 
> HttpServletResponse objects. This is in contrast with the previous floW 
> and template object models who used Request and Response objects for 
> these fields. And as you have seen your change is backward incompatible.
> 
> You could easily fix the problem by using the Request and Response 
> objects from the processInfoProvider.getObjectModel().
> 
> Actually this should be enough. While I would love to let our 
> environment abstractions extend the http servlet ones and phase out the 
> use of them where ever possible this would be orthogonal to your GSoC 
> needs. So it could be done later.

Eureka! ;) Thanks Daniel for your suggestion. I cannot wait to try it out.

[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74314

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Mime
View raw message