I suppose we should deprecate it eventually, but for now it seems like it would be better to make it clearly a convenience function for modifying the URL, because it seems worse to make it side-effect this params key-value table, in a way which is HTTP-specific, and it doesn't even actually cause that query string to appear in the URL for a POST request, which I think it what is confusing people.
On Jan 22, 2008 3:29 PM, P T Withington <[EMAIL PROTECTED]> wrote: > I'm not sure _what_ the pre-4.x behaviour was. I know it was > confusing and the source of many bugs. I think the best we could tell > was that the intent was that both API's manipulate the same thing, > although the implementation was perfect. > > I _don't_ think you should make setQueryString touch the URL. If > people want to manipulate the URL they should use the LzURL interface > to do so. The query interface should be for manipulating the query > that the dataset is going to make. It seems klunky to me to have the > setQueryString API, but I don't think you can change its contract. > The most we could do is deprecate it, because it is too implementation- > specific -- it makes it seem like the dataprovider has to be HTTP. > > On 2008-01-22, at 14:56 EST, Henry Minsky wrote: > > > One thing I am thinking as I look at the code is that the > > 'setQueryString' > > method is very confusing right now, since it really doesn't directly > > set the > > query string. It is really just acting as a synonym for > > setQueryParam[s], > > which manipulates this 'params' table of key value pairs. > > > > Maybe we should make setQueryString actually overwrite the src URL > > query > > string. I think that would be more along the > > lines of what people expect, and actually fits our existing > > documentation > > more closely. > > > > > > Then setQueryParam[s] would be the only official way > > to manipulate the 'params' table, and the params data will either be > > www-form-encoded as the body of POST requests, or > > merged in with the query string for GET requests. If there are query > > string > > args that shadow params table args, it is undefined which one has > > priority. Or we could make a rule that the params table entries get > > priority. Note, we are still limited by Flash 8 to having no > > duplicate query > > args in a > > SOLO GET request. > > > > So setQueryString would have slightly different behavior than what > > we have > > now, although for GET requests, it would actually be more like the > > pre-4.x behavior. For POST requests though, the query string set by > > setQueryString would really show up in the URL, and the params > > would show up in the post body. > > > > > > > > > > > > > > > > > > > > > > On Jan 21, 2008 8:18 PM, P T Withington <[EMAIL PROTECTED]> wrote: > > > >> What I was imaginging was in dataprovider API, you get: > >> > >> + URL (as an LzURL, which may have a non-null query component) > >> + queryparams (which may have been set with setQueryString or > >> setQueryParams on the dataset, but not via setSrc) > >> > >> At that API, the query component of the URL and the queryparams > >> object > >> have no relation to each other. There should be no need for > >> querystring, since it should be the same as queryparams. The URL > >> should come as an LzURL because, as I noted, you ought to be able to > >> have a #fragment component of the URL that gets passed on too. If > >> you > >> send it as a string, you will just have to re-parse it anyways (at > >> least for the HTTP/GET case). > >> > >> It should be only in the HTTP/GET transport that the queryparams are > >> squeezed into the query component of the URL. For any other protocol, > >> and for HTTP/POST, the queryparams are sent along a 'control > >> channel' (the POST body, for instance). > >> > >> > >> On 2008-01-21, at 20:00 EST, Henry Minsky wrote: > >> > >>> I'm looking at how we can preserve the query string so it can remain > >>> attached to the URL when making a POST request. > >>> > >>> This requires some hacking at several levels, because while we can > >>> (and do) > >>> keep the query string and query params separate in the LzDataset, > >>> we're mushing them together into a single url in LZHTTPDataProvider, > >>> and all > >>> the levels below that expect a single URL with all the data in it. > >>> Unfortunately that extends to the proxy server as well, it expects > >>> to see a > >>> single query string. > >>> > >>> The reason we're in trouble here is that a decision early on was > >>> made to > >>> try to abstract data transport away from > >>> HTTP and URLs, etc, and just treat it as key-value pairs, and that > >>> has come > >>> back to bite us. > >>> > >>> It extends to our protocol for proxy requests; the protocol we have > >>> with the > >>> server is to expect a single URL containing all data and query args > >>> mixed > >>> together. > >>> > >>> We should probably change the protocol we're using for proxy data > >>> requests, > >>> to explicitly pass the data params > >>> separately from the URL. We might be able to get away with reusing > >>> the magic > >>> "lzpostbody" arg as we do now, but making the > >>> policy that the client does not have to send that as the *only > >>> *query arg. > >>> The client can instead send the URL with querystring > >>> and the server will pluck out the lzpostbody arg if there is one, > >>> and use it > >>> for the post body, while keeping the rest > >>> of the args as the query string. > >>> > >>> For SOLO requests, we can also use the lzpostbody for the query > >>> params; > >>> internally in the LFC, the code path for > >>> raw SOLO posts actually keeps the raw post data in a separate var > >>> all the > >>> way down to where the HTTP request is sent, > >>> so we can stick the query params data as a URL-encoded query string > >>> in > >>> there. > >>> > >>> I'm going to try making a patch to do this, for wafflecone. I don't > >>> know if > >>> it's worth trying to make a back compatibility flag for > >>> this now, or just say that we're changing the things work again; > >>> people were > >>> getting unexpected results when we > >>> changed things for 4.x to have setQueryString null out the query > >>> params and > >>> vice versa, so maybe just backing out > >>> of that behavior is best. Introducing this new behavior which keeps > >>> the > >>> query string args confined to the URL even > >>> in POST requests seems like a more HTTP/HTML compatible API, > >>> considering > >>> that XMLHTTPRequest behaves that way; > >>> In XMLHTTPRequest, you open a request to a URL, which can have query > >>> string, > >>> and then you call send(data) with > >>> any POST data you want to stuff in the request body. I feel like we > >>> ought > >>> to be trying to emulate that model, I don't see > >>> the point in trying to abstract away from it, we've just caused > >>> trouble by > >>> doing so, so far. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Henry Minsky > >>> Software Architect > >>> [EMAIL PROTECTED] > >> > >> > > > > > > -- > > Henry Minsky > > Software Architect > > [EMAIL PROTECTED] > > -- Henry Minsky Software Architect [EMAIL PROTECTED]
