cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: svn commit: r154841 - in cocoon/trunk/src: blocks/template/java/org/apache/cocoon/components/expression/jexl/JexlExpression.java blocks/template/test/org/apache/cocoon/template/jxtg/JXTemplateGeneratorTestCase.java java/org/apache/cocoon/environment/TemplateObjectModelHelper.java
Date Tue, 22 Feb 2005 14:00:21 GMT
Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
> 
>> lgawron@apache.org wrote:
> 
> 
> <snip/>
> 
>> Right now every test case for new jxtg passes.
> 
> 
> Cool!
> 
>> The problem is: do we want our template object model messed up like this?
> 
> 
> No ;)
so I thought :)

> 
> What about breaking out the Java package stuff to an addJavaPackages(Map 
> objectModel) method in the TemplateObjectModelHelper class. Then one use 
> the getTemplateObjectModel method for geting a map without the "mess" 
> and use addJavaPackages on the returned map for adding Java package 
> functionality for back compability.
Good idea.

Still it is strange that this kind of functionality isn't somehow 
covered by JEXL itself. Maybe we are missing something.

> Then we should IMO try to deprecate the Java package functionality in 
> templates. But thats a later question, first we must see if there are 
> any important SOC preserving use cases for them and find cleaner ways to 
> solve them.

The only use cases I know for allowing to directly call java are:

* calls to static formatter methods:
${Packages.com.mycompany.DatePrettyPrinter.getMeNiceTextFormattedDate(
                                              dateVal )}
or
${Packages.com.mycompany.DatePrettyPrinter.getMeNiceColouredDate(
                                              dateVal, cocoon.consumer )}
both could be handled with convertors

* dynamic tag hacks:
> <root xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
> 
>   <jx:set var="tags" value="${java.util.HashMap()}"/>
> 
>   <jx:macro name="dynamic-tag">
>     <jx:parameter name="id"/>
>     <jx:set var="ignored" value="${tags.put(id, macro.body)}"/>
>   </jx:macro>
> 
>   <dynamic-tag id="example">
>     <em>This tag was invoked dynamically</em>
>   </dynamic-tag>
> 
>   <p>I'm about to invoke a dynamic tag:</p>
>   <jx:eval select="${tags.example}"/> 
> 
> </root>
we won't need that when I finally introduce jx:call macro="${macroName}">


* hacks with hash maps that deal with the fact that jx:set always 
defines a new property

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110631646816117&w=2
Could be easily fixed with introduction of jx:declare and jx:assign but 
I know we'll need to discuss that further as there are people oposing 
strongly.


> Leave the rest of the questions for the Rhino gurus.
Who is most experienced in rhino among us?

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

Mime
View raw message