FYI: the old behavior was basically that setQueryString and
setQueryParams were two ways to do the same thing. Only really made
sense in the context of HTTP GET requests, but that is the way it worked
in LPS v1-3 at least
I agree with Tucker that setQueryString should be deprecated -- why have
so many ways to do the same thing? let's try to make the future dataset
not quite so HTTP-centric if we can. I don't know how many apps would
use setQueryString for a POST, but leaving it alone will certainly break
the fewest. FWIW, I think it is a common pattern to have all your code
working with GET and then change it later to do POST without really
thinking about how the params were set.
Sarah
On Tue, Jan 22, 2008 at 12:41 PM, Henry Minsky wrote:
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]
<mailto:[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]
<mailto:[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]
<mailto:[EMAIL PROTECTED]>
--
Henry Minsky Software Architect [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]>
--
Henry Minsky
Software Architect
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
