Andreas Junghans <[EMAIL PROTECTED]> writes:
> Come on, it's not that hard! You simply have to treat the start and end of a
> date the same way you treat the quotes for strings.
>
> Attached is a patch to your JSON parser that does exactly that.
Yup, after a comment like mine, I deserved this. :-) Thanks, though!!!
> Please note that I didn't adjust the setUtcDateTimeFields() implementation
> (it now gets milliseconds instead of a fractional part).
I'll fix it up. I'd just assume maintain milliseconds vs fractional part
anyway. It's a lot cleaner, but didn't match well to the ISO-8601 date that
could have an arbitrary fractional part.
> do you still have objections to using the "new Date(Date.UTC(...))" syntax?
I do not. We are in total agreement.
>>> I have no problem with adding a call id, but please leave the original
>>> instanceId functionality in!
>>
>> I would propose to add this feature on top of RPC rather than being part of
>> the generic RPC mechanism, possibly by appending the instance number to the
>> URL. By doing it this way, if the client and server know about instances,
>> they'll be used. If the server doesn't support them, the URL will never
>> include an instance id, and it just won't be used.
>
> 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.
I can wait until Monday before checking this stuff in. No problem at all.
>> OTOH, I'm not wedded to the warning about sync calls. I believe it should
>> be there to discourage people from using it, but I'm willing to remove it
>> if the team believes it doesn't belong.
>
> Please remove it.
Wilco.
> It's a good idea to take this logic out of the Rpc class, but there has to be
> a replacement. IMHO, it should work something like this:
>
> <script type="text/javascript" src=".qxrpc">
> <script type="text/javascript" src="qooxdoo.js">
>
> ...
>
>
> function test() {
> var service = new qx.io.remote.Rpc(
> qx.io.ServerUtils.makeLocalServerURL(),
> "com.test.MyClass");
> var call = service.callAsync(...)
> }
>
> 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?
> 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. 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?
Cheers,
Derrell
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
