Hi Derrell, Am 30.01.2007 um 22:07 schrieb [EMAIL PROTECTED]:
> Andreas Junghans <[EMAIL PROTECTED]> writes: > >>> 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. >> >> It shouldn't be hard to change that. As long as no file upload is >> involved >> (which isn't possible with XMLHttpRequest anyway), the encoding to >> use is >> "application/x-www-form-urlencoded". Basically, the body looks >> just like the >> parameters in a GET request: >> >> param1=value1¶m2=value2 > > The low-level transport code will then need to depend on the user > setting the > correct content type correctly. Otherwise, it has no way to know > if the > content is in that format, or for example the case of JSON-RPC, an > entirely > different format. I think we could easily check for invalid combinations. As soon as a user adds parameters to the body (via the proposed addBodyParameter method), we can throw an exception in case he sets the content type to anything else than application/x-www-form-urlencoded. If there's no user-specified content type, we can default to application/x-www- form-urlencoded. If a user sets raw body data (like in the Rpc class), we can throw an exception when he tries to add body parameters later. In the opposite case (body parameters first, then setData to set the whole content), we can do the same. Likewise, we can throw an exception when cross-domain is requested and addBodyParameter is called. > It starts becoming a lot of onus on the user to set things up > correctly, with > no easy checking that can be done to ensure that they did. But there _are_ easy ways to check (see above). Yes, the user can still mess up, but then there's an error message that tells him what he did wrong. > We'd likely > instead want a separate class, a class which is a user of > qx.io.remote.Request > similar to what's in Rpc.js, to isolate the user from that > headache. As long > as there's to be a separate class to provide the interface, it > should probably > be written to interface with generic widgets so that the form could > be built > (semi-)automatically... IMHO we don't need yet another class for this (the io.remote namespace is already complicated enough). Like outlined above, a few strategic checks and meaningful error messages can make the whole process pretty easy. > Now what to do about Tables where the data is in a model rather > than stored > in the widget? It'll need a data model conversion capability... Now that's a completely different topic. This whole thread has to do with sending things to the server, not with interpreting the results. You can create a remote table model on any basis, no matter whether you're using Rpc, qx.io.remote.Request, or even XMLHttpRequest manually or via another framework. Regards, Andreas ------------------------------------------------------------------------- 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
