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.
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.
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.
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.
This functionality should be replaced by cocoon-servlet-service-fw and cocoon: source plus map:mount should be deprecated in the near
future, right?
Four options with the one I described above.
Where exactly? Do I miss something?
3. Forget about back compatibility and clean up the mess, start
switching to HttpServletRequest *right away*. In most cases the
changes would be trivial (changing imports in various classes). Of
course I don't want to get rid of Cocoon's Request interface
everywhere at once because it's not in scope of my GSoC work. I only
want to get rid of it where it's needed.
"Cleaning up the mess" sounds like a rather vague plan to me ;) I would
prefer some suggestions about how it could be done and what consequences
it would have. You still need to handle the sub sitemap path stuff that
is part of Request but not HttpServletRequest.
Ok, let's forget about it. I just wanted to get rid of our interface Request by any means because it was a pain for me. No insightful
proposal supported this option. ;)
My proposal would be to combine my option in the beginning with option
2, and follow option 3 in the sense that Request can be switched to
HttpServletRequest everywhere in the code where the sub sitemap path
methods not are used.
Agreed!
I agree. As you see there is some reason that only a few dare to touch
it. But it is nothing unique for Cocoon, most projects that has been
around for many years suffers from the same problems. Continuous
refactoring and rearchetecturing is needed to keep the code manageable.
While it might be hard to believe, it has been even worse, we have
considerably simplified the code in several areas (the setup sequence
i.e. was complicated beyond belief before). And now you are working to
simplify another significant area. Still it is from time to time a
deeply frustrating experience to clean up the mess.
Yes, and I'm not used to such situation. I'm learning a lot, though!
* We have at least four different object models!
a) objectModel map that is passed to components
I think we should deprecate (or at least discourage) the use of the
object model. With a sitemap scoped beans for the environment objects
(as described in
http://marc.info/?l=xml-cocoon-dev&m=118578691800176&w=2) we have a
mechanism for getting environment objects with DI, which is much
preferable IMO.
+100
b) FlowscriptObjectModel
c) TemplateObjectModel (if template was called by flowscript)
d) TemplateObjectModel (if template wasn't called by flowscript)
That is part of the scope of your GSoC to clean up isn't it?
Yes, but it turned out to be more complicated than I thought so I'm not saying that I don't want to do this but I'm saying that current
situation is horrible. I shared my feeling in a hope that we can avoid such situations in the future.
Items c) and d) do not differ only in data user puts while
calling sendPage, it would be too obvious. It differs in some
internal, obscure areas so some functionality working in template
called from flowscript (like constructing new objects) will not work
if you just call it out of flow execution scope.
Is the differences intentional or are they bugs?
I would say that they are limitation of current architecture. Some initialization takes place when flowscript is called and has impact of
further calls of template. When template is used outside flowscript scope not all methods of these plenty Helper classes are called.
I cannot give you details because in the rush of debugging I forgot which methods are called and which are not in both cases. I'll try to
sort out it just after resolving current issues.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
