The escaping should be done in order to help the browser correctly interpret things.
There is an order to follow in escapings.
If you want to produce _javascript_ literal strings, you have to escape some characters (the classic ones, quotes, simple quotes, newlines, ...).
And you must be vigilant because if you write those in java String literals in your code, you of course have to then double escape things.
That escaping will be needed by the _javascript_ interpreter.
And second, you must html escape the result of the previous step.
That escaping is needed by the html browser.
On 11/24/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
do all browser just work if the _javascript_ is escaped in side the attributes value?
On 11/24/05, Laurent PETIT < [EMAIL PROTECTED] > wrote:I don't see any harm in html escaping the content of an *attribute* ? It is the same as what can be done by default XML APIs when using some attribute.setValue(someText), and I think it should be ensured at the ComponentTag level in order to produce correct XHTML.But maybe it's too late, and I'm not good for anything at this point of time, so I'll check it again with my eclipse & wicket-head in front of me and return to the list later.cu,--laurent
On 11/24/05, Johan Compagner <[EMAIL PROTECTED] > wrote:if you do it in ComponentTag.writeOutput()
then it is always escaped. But that can't happen. what about _javascript_ events? _javascript_"
And escape the value or not is something the component desides with a property.
johan
On 11/24/05, Laurent PETIT <[EMAIL PROTECTED] > wrote:Hello,When diving into the core of Wicket in order to help solve an issue with form components, I was surprised by 2 things :- The Component.getModelObjectAsString() returns an html escaped version of the model value. I'm not sure that this is a desired behaviour in some circumstances. For example, if a Component creator wants to override the onRenderTag() method of component (not sure of the name, but you see the point), and wants to write some _javascript_ in an attribute, and the _javascript_ is composed of static text & getValue() / getModelValue() method call, then the _javascript_ will embed an already html escaped version of the model ... not that good ?- The ComponentTag.writeOutput..(..) method writes at the end of the method the content of attributes in a loop. For each attribute, it does not html escape the value of the attribute. This is consistent with the behaviour of getModelObjectAsString() as seen above, but is not very secure.Indeed, the responsibility of giving a well formed (understand html escaped) string as the value of an attribute has be moved to the component developer ...There is also something weird in the ComponentTag.writeOutput...(...) method with attribute value handling : double quotes are replaced with backslashed double quotes ( " are replaced by \").It sounds to me like a result of some hack when at some point in the past a bug when embedding _javascript_ in the tag values was discovered.But I don't think it's the right way to do things.The two above points are closely related, but don't solve the problems once and forever.Here is what i would suggest :remove the html escaping from the Component.getModelObjectAsString() method.Add the html escaping to the ComponentTag.writeOutput() method, in the attributes loop.Remove the weird replacement of double quotes by backslashed double quotes in the attributes loop.I can't test it by myself now, but I'm pretty sure this would be good, for all the points I've mentioned above: more centralized, more secure, and more powerfull (because getModelAsString() will return a usable value to be included in _javascript_ literal strings ...)HTH,--Laurent
