Hi Derrell, >> The important point is that including ".qxrpc" fills in some internal >> qooxdoo structure with the settings of the current server (i.e. >> the server >> where the HTML page came from). > > Ok, I think I see how you're using this, but I wonder if it belongs > in qooxdoo > at all, or could what you're calling > qx.io.ServerUtils.makeLocalServerURL() > instead be a local function in your application? Your application > knows it's > talking to a server which fills in the structure, and the > application's > makeLocalServerURL() function knows what's been filled in and how > to create > the URL?
I don't really like this approach because many (if not all) Java applications need (or at least can make good use of) this functionality. Why implement it separately in every application? >> To achieve this "location independence", the Java servlet >> containing the RPC >> implementation sends out a little script that stores the path to the >> application (and a session id if there is one) in >> qx.core.ServerSettings.serverPathPrefix and >> qx.core.ServerSettings.serverPathSuffix. > > So given my supposition that this needn't actually be in qooxdoo, the > application could instead declare variables > 'qxrpc_serverPathPrefix' and > 'qxrpc_serverPathSuffix', and .qxrpc would send a little script > that stores > the path to the application in these variables. Where's the difference between qx.core.ServerSettings.serverPathPrefix and qxrpc_serverPathPrefix (apart from the global namespace pollution of the latter)? > Local function > makeLocalServerURL() would know to pull parts of the generated URL > from > 'qxrpc_serverPathPrefix' and 'qxrpc_serverPathPrefix'. > > In fact, since you're not going to call makeLocalServerURL() until > after that > little script has set the variables anyway, the little script could > even > *declare* the variables (not just set them) and also declare a > qxrpc_makeLocalServerURL() function, so each application needn't > even worry > about declaring these things. It all Just Works(tm). > > Does this sound reasonable, or am I missing some key concept here? It's a bit wasteful. The utility method I'd like to see lives in the (cached) qooxdoo.js.gz while the local function you propose would be transferred each time a page/application is loaded. It's only a few bytes, so I doesn't _really_ matter - I just don't understand why you insist on all this local stuff (variables, function)? IMHO, every Java application based on qooxdoo RPC gains from the "location independence" - and that's probably the same for other backends. Who says that a PHP application always has to live under the same server path? You can easily fill in the server settings from the PHP backend as well (similar to the Java backend), and you can then move around the application on the server more freely (without changing any JavaScript code). If there's really no use for this functionality in some backend, then simply don't implement it, and don't call the makeServerURL() utility method on the client (or call it anyway, and it can just return the URL that is passed in if no server settings are found). To summarize: - IMHO, "location indepence" with regard to server paths is good, and it should not be necessary to re-implement it in every application. This is the reason why I think it belongs in qooxdoo. - Of course the RPC servlet could send both the structure and a function. But as I said, this would be a (tiny) waste of bandwidth, and it means more JavaScript code in string form on the server side (which can't be good, although the current implementation already has too much - I will cut that down). I just don't see what we would gain from your proposed changes: - They would move code from qooxdoo.js(.gz) to the server side. Why? - They would introduce (a little) more global namespace pollution (since the returned function isn't really "local" - it's automatically attached to the window object). Why not a "proper" qooxdoo method? >> Sounds good, but I'd like to check first if it's easy to implement >> in Java >> (the problem I see is getting an additional query parameter from >> the URL >> when the request method is POST and the body is not form- >> encoded). It would >> be great if you could wait until monday (when I'm at my work >> machine again), >> so that I can confirm the URL-based approach doesn't cause >> problems in the >> Java implementation. It'll probably work just fine, but I want to >> make sure. > > Andreas, I've been thinking about this. Although the specific case > you > require, an instance id, is more specific than I feel belongs in > the RPC > protocol, I can foresee a desire in various applications for being > able to > send some generic "out of band" data from the client to the > server. Here's an > alternative to passing the out-of-band data in the query string as > we had > discussed doing with the instance id. Let me know what you think > of this. Looks like a nice addition. However, I still think we should treat an instanceId as a special case. At least in the Java implementation, the id of a server-side object is an integral part of object lookup (at least it was before your patch ;-)). To get the same functionality without support for it in the qooxdoo core would mean subclassing the RPC servlet in your application (since you have to modify the internal object lookup). Why make it harder for developers than it has to be? I just tested moving the instanceId to the URL, and it works fine, so I don't have a problem with that. To support this model, the makeServerURL function discussed above would get an additional optional parameter for the instance id. This looks like a good solution to me, and I can contribute the necessary code (both on the client and the Java side). However, I'd rather not hide this id inside a generic server_data attribute (which is nice idea on its own). Even if several other backends have no notion of objects, instances and the like, why make it harder for the Java case (and possibly PHP - doesn't PHP have sessions and objects that can live inside these)? If it's really not applicable for a particular backend, you can simply ignore the instanceId. And I think it _does_ belong in the core as it's really a core RPC concept. Regards, Andreas -- Dipl.-Inform.(FH), M.Sc. Andreas Junghans STZ-IDA an der Hochschule Karlsruhe email [EMAIL PROTECTED] internet http://stz-ida.de telefon ++49-721-920-3302 fax ++49-721-160-890-56 Moltkestrasse 30, D-76133 Karlsruhe/Germany _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
