Grzegorz Kossakowski skrev:
Daniel Fagerstrom pisze:
Grzegorz Kossakowski skrev:
My response wasn't misleading when I wrote it, but the code has
changed since then:
http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java?r1=307119&r2=321148,
http://svn.apache.org/viewvc?view=rev&revision=416391.
I hope that you don't treat my statements as offending ones.
No problem.
I think that we are speaking about two different things. It does not
matter that signature of any method changed since your response. What
matters is that you said that one can access classes registered by
o.a.c.environment.TemplateObjectModelHelper.addJavaPackages. I'm not
sure about other expression languages, but when it comes to the JXPath
all classes are available by default thanks to GENERIC_FUNCTIONS static
instance. Take a look at
org.apache.commons.jxpath.JXPathContext#getFunctions() for details.
You are right, addJavaPackages is not used for function calling in JXPath.
Packages added by
o.a.c.environment.TemplateObjectModelHelper.addJavaPackages seems to be
used in JS expressions (but I'm not 100% sure). I have no clue about JEXL.
But the added packages are AFAICS used for JEXL and JS.
It expects o.a.c.e.Request but after applying[1] object model
contains HttpServletRequest thus JXPath's evaluation fails.
I'm not certain that it is such a good idea to use HttpServletRequest
instead of o.a.c.e.Request in your new object model. By doing that
you, except for breaking some code, miss info about the path of the
current sub sitemap which might be useful. Request contains the
following methods that not is part of HttpServletRequest:
String getSitemapURI();
String getSitemapURIPrefix();
String getSitemapPath();
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.
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.
/Daniel
