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