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 18:32:13 GMT
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/

Mime
View raw message