reopened , thanks
On Tue, Nov 17, 2009 at 12:30 PM, Dale Newfield wrote:
> Musachy Barroso wrote:
>>
>> that sounds good, can someone open a jira ticket so we don't depend
>> on my short term memory :)?
>
> I modified https://issues.apache.org/struts/browse/WW-3332 (although there
> didn't appea
Musachy Barroso wrote:
that sounds good, can someone open a jira ticket so we don't depend
on my short term memory :)?
I modified https://issues.apache.org/struts/browse/WW-3332 (although
there didn't appear to be a way for me to change the resolution, so
maybe this was a mistake...
-Dale
that sounds good, can someone open a jira ticket so we don't depend
on my short term memory :)?
musachy
On Tue, Nov 17, 2009 at 10:08 AM, Dale Newfield wrote:
> Chris Pratt wrote:
>>
>> Or even better, add an escape attribute that takes as it's values "html",
>> "xml", or "javascript". It woul
On Tuesday 17. November 2009 19.08.08 Dale Newfield wrote:
> Chris Pratt wrote:
> > Or even better, add an escape attribute that takes as it's values "html",
> > "xml", or "javascript". It would be very nice to have it be able to
> > properly encode at least single and double quotes in JavaScript
Chris Pratt wrote:
Or even better, add an escape attribute that takes as it's values "html",
"xml", or "javascript". It would be very nice to have it be able to
properly encode at least single and double quotes in JavaScript as well as
HTML and XML, and using a more generic and extensible attrib
You can maintain backward compatibility by ensuring that escape="true" is
equivalent to escape="xml".
(*Chris*)
On Mon, Nov 16, 2009 at 10:48 AM, Musachy Barroso wrote:
> I agree, but you know we are obsessed about backward compatibility :),
> that change would break a lot of stuff.
>
> On Mon
Or even better, add an escape attribute that takes as it's values "html",
"xml", or "javascript". It would be very nice to have it be able to
properly encode at least single and double quotes in JavaScript as well as
HTML and XML, and using a more generic and extensible attribute name is
always a
On Monday 16. November 2009 19.56.25 Ronny Løvtangen wrote:
> 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-esc
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:
I agree, but you know we are obsessed about backward compatibility :),
that change would break a lot of stuff.
On Mon, Nov 16, 2009 at 10:43 AM, Matt Raible wrote:
> I would advocate that "escape" means escape everything (Csv, Xml and HTML).
> No need to differentiate IMO.
>
> On Mon, Nov 16, 200
I would advocate that "escape" means escape everything (Csv, Xml and HTML).
No need to differentiate IMO.
On Mon, Nov 16, 2009 at 1: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:
>
>
>
> hum, I wonder if w
it is in trunk now. Please note that "escape" is true by default, so
to escape some xml you should do:
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 wrote:
> working on it, it will be in trunk soon.
>
> On M
working on it, it will be in trunk soon.
On Mon, Nov 16, 2009 at 10:11 AM, Ronny Løvtangen 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 wrot
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
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
When using escape="true" (which is default) on I can see
that 2.1.6 and 2.1.8.1 behaves differently.
E.g. the norwegian letter ø is escaped as ø in 2.1.6, but now in 2.1.8.1
it is escaped as ø
I looked at the source. The change is that
org.apache.struts2.components.Property now do a
org.apac
16 matches
Mail list logo