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/
