[opencms-dev] JSP2 issue escaping EL expressionsincms:contentload

Stefan Uldum Grinsted stefan at e-nation.dk
Tue Sep 26 09:26:48 CEST 2006


Hi Alex and Sebastian

When I created my custom taglib, I was looking a bit at the JSR168 Portlet
spec, where there is a tag <portlet:defineObjects />.
This tag (and its tag-TEI) defines protletRequest and portletResponse as
pageContext attributes and as variables available in JSP. So I created a
custom tag <vt:defineObjects /> which instantiates two objects and makes
them available to the pageContext and the JSP.
One which I called CmsJstlActionElement (extending CmsJspActionElement)
where I actually made the lazy-map Sebastian talked about, like so:

	public Map getProperty() {
		return new MapAdapter() {
			public Object get(Object key) {
				return property((String) key);
			}
		};
	}

(MapAdapter implements all from Map, but the get-method.)
I also created lazy maps for the methods:
 - label(String)
 - link(String)
 - template(String)
 - info(String)
 - user(String)

Then I also created a Jstl-friendly delegate-class for CmsRequestContext
(since it is declared as final, so I couldn't extend it), where I added some
extra methods, like proper getters for user and project:
 - getCurrentProject() and
 - getCurrentUser()


To use EL in the cms-tags, I followed Harald Brabenetz's advice and created
a copy of the opencms.tld where I changed the uri to .../cms_rt and enabled
rtexprvalue on all the attributes. (And that solved my original problem with
the strange character that came out when I tried to escape the EL in a non-
rtexprvalue attribute.)


The custom tag defineObjects, is compatible with JSP 1.2, but Sebastian is
right about having to manually evaluate the EL in JSP 1.2 if the _rt
solution is to be implemented in a JSP 1.2 environment. I believe that the
Spring framework contain some code to evaluate EL expressions from tags,
without knowing if it is used in JSP 1.2 or 2.0. This could definitely be
useful here.

Attached you'll find my Jstl-friendly classes, along with my defineObjects
tag and TEI. Please find the TLD for the tag below.

I hope this proves useful. I, as much as you, would like to see a nice
solution to this.

Regards Stefan Grinsted

    <tag>
        <name>defineObjects</name>
        <tag-class>dk.valtech.opencms.jsp.CmsJspTagDefineObjects</tag-class>
 
<tei-class>dk.valtech.opencms.jsp.CmsJspTagDefineObjectsTEI</tei-class>
        <body-content>empty</body-content>
        <description>
            This tag defines the objects cms (CmsJstlActionElement) and
cmsRequest (CmsJstlRequestContext)
        </description>
        <attribute>
            <name>cms</name>
            <rtexprvalue>true</rtexprvalue>
            <type>java.lang.String</type>
            <description>Allows you to override the default variable-name
for cms</description>
        </attribute>
        <attribute>
            <name>cmsRequest</name>
            <rtexprvalue>true</rtexprvalue>
            <type>java.lang.String</type>
            <description>Allows you to override the default variable-name
for cmsRequest</description>
        </attribute>
        <attribute>
            <name>scope</name>
            <rtexprvalue>true</rtexprvalue>
            <type>java.lang.String</type>
            <description>Defines in which scope the attributes should be
set.</description>
        </attribute>
    </tag>
	

-----Oprindelig meddelelse-----
Fra: opencms-dev-bounces at opencms.org
[mailto:opencms-dev-bounces at opencms.org] På vegne af Sebastian Himberger
Sendt: 25. september 2006 11:24
Til: The OpenCms mailing list
Emne: Re: SV: [opencms-dev] JSP2 issue escapingEL
expressionsincms:contentload

Hi Alex,

in my understanding the big thing regarding the EL in JSP 2.0 (JSTL 1.1)
is the responsibility of evaluation. In an 2.3 webapp the responsibility
is (because of JSP 1.2 and JSTL 1.0) at the tag level. while the
expressions in JSP 2.0 (Webapp 2.4) is at the container level. So making
a bean available in the page context automatically is, in my
understanding, not bound to the webapp version and still the JSTL 1.0
tags would benefit from this bean. Although we would have to make sure
that the tags (cms:xxx) evaluates the expression by himself. This indeed
could be quite difficult because of the OpenCms macro expressions and
backwards compatability. Certainly this is an issue that can not be
changed ad hoc.

I thought about this issue some time ago when i was developing a custom
taglib for use inside OpenCms and thought of changing the CmsJspLoader
to inject a bean inside the request object which then would be carried
around to the jsp page. The page can then use this bean to access OpeCms
values (either via jsp:getProperty or EL). But since i haven't looked
too deeply into the OpenCms JSP mechanism i don't know if this is good
idea and/or if the loader is the right place. But at this time it was an
option (especially because the loader can be changed via xml configuration).
  
It would be really great if we can find a nice solution!

best regards
Sebastian


Alexander Kandzior schrieb:
> I also agree the suggestions are good.
>
> However, OpenCms currently is flagged as a 2.3 webapp:
>
> <!DOCTYPE web-app
>     PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
>         "http://java.sun.com/dtd/web-app_2_3.dtd">
>
> IIRC most of these features are only available in a 2.4 webapp. It will
> require some time to ensure that changing the OpenCms webapp version from
> 2.3 to 2.4 has no side effects.
>
> Kind Regards,
> Alex.
>
> -------------------
> Alexander Kandzior
>                                                                
> Alkacon Software GmbH  - The OpenCms Experts                  
> http://www.alkacon.com - http://www.opencms.org                 
>
>   
>> -----Original Message-----
>> From: opencms-dev-bounces at opencms.org 
>> [mailto:opencms-dev-bounces at opencms.org] On Behalf Of 
>> Sebastian Himberger
>> Sent: Sunday, September 24, 2006 5:26 PM
>> To: The OpenCms mailing list
>> Subject: Re: SV: [opencms-dev] JSP2 issue escaping EL 
>> expressionsincms:contentload
>>
>> Hi,
>>
>> i think Stefans suggestion this would be a good solution and 
>> would make 
>> binding of OpenCms values to custom tags much easier. Maybe it would 
>> make sense to make the name somehow configurable (through a 
>> property or 
>> something). Even things like properties could be accessed through a 
>> lazyly initialized Map. So you can use something like this:
>>
>> <c:out value="${cms.currFile.properties['template']}"/>
>> <c:out value="${cms.currFile.uri"/>
>>
>> best regards
>> Sebastian
>>
>> Stefan Uldum Grinsted schrieb:
>>     
>>> Hi Alex
>>>
>>> Why not make use of the built-in EL instead? By making all the 
>>> accessible macro-objects available in the pageContext, like 
>>>       
>> an opencms 
>>     
>>> object with the name “opencms”, the current macroform can still be 
>>> used. It will then use the EL, resolve to the opencms object in the 
>>> page context and call getUri() from there.
>>>
>>> Or is there a particular reason rtexprvalue is disabled for most 
>>> opencms tag attributes?
>>>
>>> / Stefan
>>>
>>>
>>>       
>> --------------------------------------------------------------
>> ----------
>>     
>>> *Fra:* opencms-dev-bounces at opencms.org 
>>> [mailto:opencms-dev-bounces at opencms.org] *På vegne af 
>>>       
>> *Alexander Kandzior
>>     
>>> *Sendt:* 20. september 2006 17:38
>>> *Til:* 'The OpenCms mailing list'
>>> *Emne:* RE: [opencms-dev] JSP2 issue escaping EL expressions 
>>> incms:contentload
>>>
>>> Stefan,
>>>
>>> I do not have an immediate solution to the issue now, but 
>>>       
>> for future 
>>     
>>> OpenCms releases there will be an alternative form of 
>>>       
>> OpenCms macros 
>>     
>>> to avoid the confilct with the JSP EL.
>>>
>>> Currently, the idea is to allow the follwoing alternate 
>>>       
>> macro syntax:
>>     
>>> **%(VALUE)**
>>>
>>> as opposed to the current
>>>
>>> **${VALUE}**
>>>
>>> The old syntax will still work, so the new one will only be an 
>>> alternative.
>>>
>>> I am open to suggenstions regarding the alternate macro 
>>>       
>> form. I want 
>>     
>>> to make sure that we do not conflict with other macro languages.
>>>
>>> Kind Regards,
>>> Alex.
>>>
>>> -------------------
>>> Alexander Kandzior
>>>
>>> Alkacon Software GmbH - The OpenCms Experts
>>> http://www.alkacon.com <http://www.alkacon.com/> - 
>>> http://www.opencms.org <http://www.opencms.org/>
>>>
>>>     
>>>       
>> --------------------------------------------------------------
>> ----------
>>     
>>>     *From:* opencms-dev-bounces at opencms.org
>>>     [mailto:opencms-dev-bounces at opencms.org] *On Behalf Of *Stefan
>>>     Uldum Grinsted
>>>     *Sent:* Wednesday, September 20, 2006 2:26 PM
>>>     *To:* 'The OpenCms mailing list'
>>>     *Subject:* [opencms-dev] JSP2 issue escaping EL expressions in
>>>     cms:contentload
>>>
>>>     Hi all
>>>
>>>     Last year, 30 November 2005 17:36, Scott Shealy asked the list
>>>     about an issue with using the “${opencms.uri}” parameter for
>>>     <cms:contentload /> in a JSP2 environment. And I have the same
>>>     issue. Did anyone ever find a resolution for this?
>>>
>>>     The default way to escape the EL resolver is to use 
>>>       
>> \${
} and that
>>     
>>>     work great in all other tag libs, even in my own. But 
>>>       
>> when I pass
>>     
>>>     “\${opencms.uri} to the param attribute of cms:contentload, the
>>>     generated java-code contains a strange character (char 27) in
>>>     front of {opencms.uri} rather than the $. The char 27 
>>>       
>> is the ASCII
>>     
>>>     escape character, but how does that end up there?
>>>
>>>     I know the directives of the jsp’s are treated by 
>>>       
>> opencms, before
>>     
>>>     they are written to the rfs (where it still looks as expected),
>>>     but does opencms do something during java-code generation of the
>>>     jsp’s? - Because that’s where it seems to go wrong.
>>>
>>>     If I have the following two lines next to each other in a jsp:
>>>
>>>     <c:out value="\${opencms.uri}" />
>>>
>>>     <cms:contentload collector="singleFile" param="\${opencms.uri}"
>>>     editable="true">
>>>
>>>     The java-generated code for the two lines looks like this:
>>>
>>>     // c:out
>>>
>>>     org.apache.taglibs.standard.tag.rt.core.OutTag 
>>>       
>> _jspx_th_c_out_0 =
>>     
>>>     (org.apache.taglibs.standard.tag.rt.core.OutTag)
>>>     
>>>       
>> _jspx_tagPool_c_out_value_nobody.get(org.apache.taglibs.standa
>> rd.tag.rt.core.OutTag.class);
>>     
>>>     _jspx_th_c_out_0.setPageContext(_jspx_page_context);
>>>
>>>     _jspx_th_c_out_0.setParent(null);
>>>
>>>     _jspx_th_c_out_0.setValue(new String("${opencms.uri}"));
>>>
>>>     /* snip */
>>>
>>>     // cms:contentload
>>>
>>>     org.opencms.jsp.CmsJspTagContentLoad 
>>>       
>> _jspx_th_cms_contentload_0 =
>>     
>>>     (org.opencms.jsp.CmsJspTagContentLoad)
>>>     
>>>       
>> _jspx_tagPool_cms_contentload_param_editable_collector.get(org
>> .opencms.jsp.CmsJspTagContentLoad.class);
>>     
>>>     _jspx_th_cms_contentload_0.setPageContext(_jspx_page_context);
>>>
>>>     
>>>       
>> _jspx_th_cms_contentload_0.setParent((javax.servlet.jsp.tagext.Tag)
>>     
>>>     _jspx_th_c_catch_0);
>>>
>>>     _jspx_th_cms_contentload_0.setCollector("singleFile");
>>>
>>>     _jspx_th_cms_contentload_0.setParam("{opencms.uri}");
>>>
>>>     _jspx_th_cms_contentload_0.setEditable("true");
>>>
>>>     Here you see the strange non-readable ASCII escape char in front
>>>     of the opencms.uri for cms:contentload but not for c:out, which
>>>     really puzzles me.
>>>
>>>     Does anyone have any resolutions or suggestions? any 
>>>       
>> leads? Anything?
>>     
>>>     Thanx in advance.
>>>
>>>     / Stefan
>>>
>>>
>>>       
>> --------------------------------------------------------------
>> ----------
>>     
>>> _______________________________________________
>>> This mail is sent to you from the opencms-dev mailing list
>>> To change your list options, or to unsubscribe from the 
>>>       
>> list, please visit
>>     
>>> http://lists.opencms.org/mailman/listinfo/opencms-dev
>>>       
>> _______________________________________________
>> This mail is sent to you from the opencms-dev mailing list
>> To change your list options, or to unsubscribe from the list, 
>> please visit
>> http://lists.opencms.org/mailman/listinfo/opencms-dev
>>
>>
>>     
>
>
> _______________________________________________
> This mail is sent to you from the opencms-dev mailing list
> To change your list options, or to unsubscribe from the list, please visit
> http://lists.opencms.org/mailman/listinfo/opencms-dev
>   


_______________________________________________
This mail is sent to you from the opencms-dev mailing list
To change your list options, or to unsubscribe from the list, please visit
http://lists.opencms.org/mailman/listinfo/opencms-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CmsJspTagDefineObjects.java
Type: application/octet-stream
Size: 1412 bytes
Desc: not available
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20060926/342f6e20/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CmsJspTagDefineObjectsTEI.java
Type: application/octet-stream
Size: 944 bytes
Desc: not available
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20060926/342f6e20/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CmsJstlActionElement.java
Type: application/octet-stream
Size: 4634 bytes
Desc: not available
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20060926/342f6e20/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CmsJstlRequestContext.java
Type: application/octet-stream
Size: 4696 bytes
Desc: not available
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20060926/342f6e20/attachment-0003.obj>


More information about the opencms-dev mailing list