Wow, that was fast!

The problem you mention that you have to set escape to false to be able use 
escapeXml, is already a problem in 2.1.8.1 with escapeJavascript I guess? The 
string is first html-escaped and then javascript-escaped.
Could be fixed by guarding 'escape' with the other attributes:

    private String prepare(String value) {
        if (escapeXml) {
                return StringEscapeUtils.escapeXml(result);
        }
        if (escapeJavaScript) {
                return StringEscapeUtils.escapeJavaScript(result);
        }
        if (escape) {
                return StringEscapeUtils.escapeHtml(result);
        }
        return result;
    }

(or with 'else if' if there's a policy against multiple returns)


But.. What if you for some reason wants to escape both javascript and xml.. 
(would you ever?)


On Nov 16, 2009, at 7:37 PM, Musachy Barroso wrote:

> it is in trunk now. Please note that "escape" is true by default, so
> to escape some xml you should do:
> 
> <s:property value="%{whatever}" escape="false" escapeXml="true" />
> 
> hum, I wonder if we should deprecate "escape" and add a new "escapeHtml"?
> 
> musachy
> 
> On Mon, Nov 16, 2009 at 10:15 AM, Musachy Barroso <musa...@gmail.com> wrote:
>> working on it, it will be in trunk soon.
>> 
>> On Mon, Nov 16, 2009 at 10:11 AM, Ronny Løvtangen <li...@lovtangen.com> 
>> wrote:
>>> Thanks for creating the jira issue. An escapeXml property would be really 
>>> useful.
>>> Agree that "htmlEncode" was a misleading name.
>>> 
>>> Ronny
>>> 
>>> On Nov 16, 2009, at 6:48 PM, Musachy Barroso wrote:
>>> 
>>>> hum, that's interesting. This move was to remove custom code by code
>>>> in commons. The misleading part is that the method was called
>>>> "htmlEncode". We should add an attribute to to the "property" tag
>>>> "escapeXml" that calls
>>>> org.apache.commons.lang.xwork.StringEscapeUtils.escapeXml(..), and
>>>> while we are at it, a "escapeCsv" as well.
>>>> 
>>>> https://issues.apache.org/struts/browse/WW-3332
>>>> 
>>>> musachy
>>>> 
>>>> On Mon, Nov 16, 2009 at 2:08 AM, Ronny Løvtangen <li...@lovtangen.com> 
>>>> wrote:
>>>>> 
>>>>> When using escape="true" (which is default) on <s:property ... /> I can 
>>>>> see that 2.1.6 and 2.1.8.1 behaves differently.
>>>>> E.g. the norwegian letter ø is escaped as &#xF8; in 2.1.6, but now in 
>>>>> 2.1.8.1 it is escaped as &oslash;
>>>>> 
>>>>> I looked at the source. The change is that 
>>>>> org.apache.struts2.components.Property now do a
>>>>> 
>>>>> org.apache.commons.lang.xwork.StringEscapeUtils.escapeHtml(result)
>>>>> 
>>>>> while it earlier did a
>>>>> 
>>>>> com.opensymphony.xwork2.util.TextUtils.htmlEncode(result)
>>>>> 
>>>>> I didn't find the source to 
>>>>> org.apache.commons.lang.xwork.StringEscapeUtils. It is part of 
>>>>> xwork-core-2.1.6.jar, but the source is not included in 
>>>>> xwork-core-2.1.6-sources.jar (!)
>>>>> Is this the same class as org.apache.commons.lang.StringEscapeUtils in 
>>>>> commons-lang? If so, I can see that it uses a lookup table to escape html 
>>>>> entities, and fallbacks to #-escaping if not found.
>>>>> 
>>>>> 
>>>>> Is this change intentional? And is there a way to escape 'the old way'? 
>>>>> My ouput is not for use in HTML, but as xml input to a flash component, 
>>>>> so &oslash; won't work.
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> Ronny
>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>>>> 
>>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>> 
>>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org

Reply via email to