Moving this discussion to qooxdoo-devel... Andreas Ecker <[EMAIL PROTECTED]> writes:
> * My only changes to your check-in: Sorry, I did misunderstand the scope of the changes you were making. It looked much larger than it was. > Removed two limiting if clauses, because attaching Parameters to the URL > used to be perfectly ok, even for POST requests. Unfortunately, your changes > would have broken existing apps that already use such a supported "mixed > mode" POST request. If such a mode is a serious problem for certain backends > as mentioned in bug #17, we need to find a way to support those without > (possibly) breaking existing apps. Ok, that's fine. IIRC, someone posted a reference yesterday that indicated that sending parameters on a POST was a violation off the spec. (Am I remembering that correctly?) If that's so, then I believe that the default behavior should be to conform to the spec. If it's not prohibited by the spec then you are right, there's no reason to limit sending parameters when the request is a POST. I'll confirm in the HTTP spec. > The existing solution of Parameter (URL) vs. Data (POST content) is the real > problem. We definitely need a better API there. A third alternative of > introducing formFields solely for the IframeTransport simply does not seem > to be sufficient. That's the reason I want to start discussion for a better > solution for the existing Parameter vs. Data stuff. Ultimately, it would be nice to have a generic "form" API that allows generating forms using qooxdoo widgets and having the submission of the form data be automated (or at least semi-automated). That's a bit more of a project than is required just to fix this bug. :-) Currently, if one wants to use XmlHttpTransport, one must provide the data blob to be sent in its entirety. With IframeTransport, we build a form and attach the user's data blob to that form. It is therefore easy to add additional form fields to the locally-built form. If we can come up with a reasonable way to do something similar with other transports, that'd be great. I think, though, that it's then getting into the larger task of the generic "form" API, and outside of this scope of work. Thoughts? Derrell ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
