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.
