I inherited this app and I'm still getting familiar with all of the
functionality and where all the data is coming from. Many of the ajax
calls went through a central function and I recently updated that
function to use $.ajax instead of the previous custom method. The
problem is that data from all over the place is coming into this
function. Some is encoded and some isn't. Eventually I'll go through
all of these places and make things more consistent. But in the short
term, I needed to prevent double encoding and keep the app working
while I sorted things out.
But that's beside the point though. My original inquiry was about
whether it made sense to give users the ability to tell $.ajax not to
encode params because it's already been done. It sounds like there's
not much interest. Thanks to everyone who helped.
:Marco
On Nov 24, 10:12 am, "\"Cowboy\" Ben Alman" <cow...@rj3.net> wrote:
> Marco, why not just sanitize your data, as you use it, to guarantee
> that it's not url-encoded?
>
> - Ben
>
> On Nov 23, 10:19 am, Marco Rogers <marco.rog...@gmail.com> wrote:
>
>
>
> > Sure that's always an option. But the point of the toolkit is to take
> > advantage of functions that have been tried tested and improved by
> > many people. For instance, I'm sure my version wouldn't include the
> > nice recursive array handling that seems to be baked in to $.param for
> > 1.4.
>
> > :Marco
>
> > On Nov 20, 7:05 pm, Markw65 <mark...@gmail.com> wrote:
>
> > > You can encode the data yourself, and pass it in as a string (rather
> > > than as key/value pairs).
>
> > > Then its just used as is...
>
> > > Mark
>
> > > On Nov 20, 2:36 pm, Marco Rogers <marco.rog...@gmail.com> wrote:
>
> > > > I just realized that while this is a compatible change for $.ajax,
> > > > it's not for $.param. If encodeData isn't passed in, it'll stop
> > > > encoding by default. Gonna put some more thought into it. I'm open
> > > > to suggestions.
>
> > > > :Marco
>
> > > > On Nov 20, 5:22 pm, Marco Rogers <marco.rog...@gmail.com> wrote:
>
> > > > > This is essentially a proposal for an enhancement to the two named
> > > > > functions:
>
> > > > > I ran into an issue today when sending parameters with the ajax
> > > > > function. If the data option is set, $.param is used to encode and
> > > > > format the keys and values into a query string. But some of the
> > > > > values in my data were already encoded and hence got double encoded.
> > > > > It was not easy to determine which params had been pre-encoded and
> > > > > which hadn't. And there's no way to tell $.ajax not to encode the
> > > > > data because it's already been done.
>
> > > > > I got around the issue by explicitly decoding all the params before
> > > > > passing to $.ajax to be re-encoded. This is obviously ugly and has
> > > > > the potential for other hidden issues.
>
> > > > > I don't know if this happens often enough to do something about it.
> > > > > But if so, I'm thinking it could be addressed in one of 2 ways. Sorry
> > > > > for using words instead of code, don't have much time.
>
> > > > > 1) Add an "encodeData" option to $.ajax and $.param that defaults to
> > > > > true. $.ajax would pass it through to $.param and If it's false,
> > > > > it'll skip the encoding step.
>
> > > > > $.ajax has plenty of options already and this one wouldn't be used
> > > > > often I'm sure. But it's trivial to add and backwards compatible.
>
> > > > > 2) Add an option to pass in a data processing function.
>
> > > > > It looks like $.param uses an inner "add" function that does the
> > > > > simple formatting and encoding. $.ajax could allow passing in a
> > > > > replacement for that function. It would take the current key and value
> > > > > being processed and skip encoding or add some special logic based on
> > > > > the key name.
>
> > > > > function newAdd(key, value) {
> > > > > return key + '=' + value;
> > > > > }
>
> > > > > The only problem with this is that the current add function doesn't
> > > > > return the formatted string. It accesses an array through a closure
> > > > > and adds the string explicitly. This could be refactored to use a
> > > > > binding or something, but it may not be trivial because the
> > > > > buildParams function also uses this closure to facilitate the
> > > > > recursion on array values.
>
> > > > > Any input is appreciated. If this seems worthwhile I may tackle it
> > > > > and submit a pull request.
>
> > > > > :Marco
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
