[Templates] URI Filter Issues

[Josh Rosenbaum]

Robin Smidsr=C3=B8d wrote:
> Andy Wardley wrote:
>>
>> Does that sound like a good plan to make the least number of people
>> displeased for as little time as possible?
> Sounds good to me.
>=20
> My only concern is that by using two filters with almost similar names,=
=20
> but different behaviour might cause people to have weird problems=20
> because of old documentation, and they will revert to the mailinglist=20
> when things aren't working.
>=20
> Make sure this is documented very clearly in the docs and the FAQ, so w=
e=20
> don't have to answer this question again and again.
>=20
> Using another name as the "main" filter name for the old behaviour migh=
t=20
> help making it more clearer, and maybe only make the url filter name a=20
> synonym which is not used in the documentation. Maybe the filter name=20
> should be 'uri_param' or something similar, to show the intent of the=20
> (broken/old behaviour) filter more clearly.

Here's how javascript does it if that changes anything:
http://xkr.us/articles/javascript/encode-compare/
escape(), encodeURI(), encodeURIComponent()

I wouldn't be surprised if this was the basis for the old method.

encodeURI doesn't encode '/'s.
encodeURIComponent does.

I'd say this probably supports the old behavior of the filter.

I'm still neutral on this issue, though. Andy's solution for uri vs url s=
eems ok to me. Also the solution of making uri use the old method (for th=
ose that need it) sounds good too.

-- Josh