Randal L. Schwartz wrote:
"Mihai" == Mihai Bazon <[EMAIL PROTECTED]> writes:
If we want a uri escape that is that aggressive, can it be put under a
different name, and the existing uri be modded back to allow : and /
characters through untouched...
Mihai> $votes++
You clearly don't understand the problem then, or what uri-escaping is about.
This isn't about "voting". This is about *doing the right thing*.
You *cannot* uri-escape a string that already has a path to it.
You can only uri-escape the path steps.
I'm finding it hard to take a side on this issue. I believe not breaking
existing code is the ultimate right thing to do. (Unless the problem absolutely
calls for it.) In this case, we probably should've used a separate filter name
to do the correct functionality.
Now that the release has already been put out, however, I'm not sure whether it
is wise to switch it back to the old method. (Also 2.15b has been available for
quite some time.) Switching back might break someone else's code now.
If staying with this method, then perhaps it would be reasonable to add the
functionality of the old uri filter into a new filter? (Or maybe add a param
for it?)
Neutrally,
-- Josh
_______________________________________________
templates mailing list
[email protected]
http://lists.template-toolkit.org/mailman/listinfo/templates