[Seaside] WAUrl class>>#decodePercent:

[jtuchel at objektfabrik.de]

I think I am getting closer to answering my own question, which started 
as a bug report ;-)

I think I've just learned something new about encodeURI() and 
encodeURIComponent(). It seems like I should not use encodeURI(), but 
encodeURIComponent() instead, because that even encodes a few more 
characters, like question marks, for example.

So if somebody enters one of the characters $: $, $/ $; $? and you 
expect them to appear correctly in an Ajax callback, you should use the 
javascript function encodeURIComponent() on the client side before 
adding the string as an Ajax parameter.

Since the results of encodeURI and encodeURIComponent look different, I 
come to the conclusion that the Ajax handling code in Seaside better 
leaves its hands off the URL parameters, because it cannot really know 
which of these functions had been used. And, of course, the client might 
not have encoded at all. So unless anybody (who knows Seaside much 
better than me) tells me differently, I tend to think my only remaining 
question is:

How do I decodeURI and/or decodeURIComponent on the server side in 
Seaside / Smalltalk? Does Seaside ship with such methods?

Here's what I've found so far:

IN Pharo 2.0, it seems like the only place where such encoding/decoding 
happens is in ZnPercentEncoder (see String urlDecoded). #urlDecoded has 
no senders other than Zinc tests. Which seems to answer my question 
about Seaside not doing anything in that respect.


Hmm. What do I make of all this now for my use case?

Joachim





Am 30.08.13 10:43, schrieb jtuchel at objektfabrik.de:
> Hi Philippe,
>
>
>
> Am 29.08.13 17:18, schrieb Philippe Marschall:
>> Ok, so the decoding of this URL fails 
>> /kontolino?_s=t0JuC1crW9NO2Bw5&_k=8qoE8Ph8YOUaO2a-&19=test% If this 
>> indeed the raw URL and not already decoded then it is invalid and can 
>> therefore not be decoded. 
>
> Agreed. It is invalid. I know. And therefor, decodePercent: cannot 
> handle it. So you can either forget my initial bug report or simply 
> throw a better exception (stating the URL is invalid instead of Stream 
> access fail).
>
> My Problem is that I am unsure whether I am expecting more from 
> Seaside that it is intended to do.
>
> Because if I encodeURI() the input text before I send the Ajax 
> request, the callback on the server will get '19=test%25' (the encoded 
> url fragment) instead of 'test%' (a decoded url fragment). Do I really 
> have to decode the String in an Ajax callback block by hand? Or is 
> this failing on VAST only and there needs to be added something.
>
>>> encodeURI() would solve it as well, but that brings up a new problem,
>>> because the String received at the server side then is encoded and 
>>> has to be
>>> decoded before it can be processed. AFAIK, VAST cannot do that yet - 
>>> which
>>> is another story...
>> Decoding the URL is exactly what the code throwing the exception tries
>> to do. Are you sure VAST can't do this? If this is true that should
>> show up in other places as well like having % in a GET form.
>>
>> Can you to to /tests/functional/WAInputGetFunctionalTest and enter
>> 'test%' (without '') into "Text Input" and see if that works?
> Well, that works, of course. But I think it doesn't prove much. The 
> text input on form submit travels as contents of the POST request and 
> not as an URL fragment, like an Ajax request does. At least that is 
> how I interpret my Firebug output. The text input is transported as 
> 'text%' and is not encoded at all (Or Firebug is doing something on 
> the fly to display POST arguments).
>
> So what all this seems to boil down to is more a question than a bug 
> report:
>
> 1.) I think it is clear now that I should encodeURI() the contents of 
> my text input field before handing it to the server as a parameter in 
> an AJAX request.
>
> 2.) I haven't yet found a place in Seaside where the URL or its 
> parameters of an AJAX request are treated differently than "normal" 
> POST requests. So maybe I already found the answer to my question 
> which then is "I need to decode the String by hand". But maybe you 
> have a tip for me where I could look for such a place.
>
> 3.) How do others who wrote their jQuery plugins in plain JavaScript 
> handle the case? Do they encodeURI() on the client and do they need to 
> decode by hand on the server? I ask mainly to find out if I am seeing 
> a VAST specific problem or a general one. And to find out if I am 
> expecting too much from Seaside (or if I am probably breeding a new 
> feature request for Seaside).
>
> 4.) Maybe the right question to the wrong list: how can I decodeURI: 
> in VAST?
>
> Joachim
>
>
>


-- 
-- 
----------------------------------------------------------------------- 
Objektfabrik Joachim Tuchel          mailto:jtuchel at objektfabrik.de 
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg 		     http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1