Hi,
Am 02.12.2005 00:53, Chris Ricks schrieb:
Hmm....one of my goals was plugable encoding and decoding methods, so
I'm trying to avoid rolling methods such as this into the class.
Alternatively, I propose that our class has a few symbolic constants:
Class.encodings.URL
Class.encodings.JSON
Class.encodings.XML
Class.encodings.RAW
Class.encodings.CUSTOM
And an associated static method (and, of course, an instance method that
does the same thing):
Class.setDefaultEncodingMethod(encoding_type)
The custom type would be realised through setting encoding and decoding
event handlers. What do you think?
Custom encoding classes should probably be an option as well (to assist
in maintaining state and the like should the user require such
functionality). Perhaps we'd define a class defined like:
with (EncodingClass.prototype) {
getEncodingMethodName = function() { ... }
encode = function() { ... }
decode = function() { ... }
getRequiredSendHeaders = function() { ... }
}
One someone defines a class along these lines, they could simply pass an
instance of that class as a custom encoder. It needs more discussion,
but I think it's a set of discussions worth having.
Looks good! This would also go well with the usual Qooxdoo-Way (TM),
like it's the case in QxBorder, where the most common cases are
available as a predefined set.
* functioncall - This will become clearer below, but the idea is
that, when performing RPC, this event would be fired between the user
requesting the RPC function call and the call actually being
initiated. This could be used for determining the URL the request
should point to, for instance.
I don't understand the use for this one.
My verbosity should have been a bit higher. I'm not sure as to whether
this should be factored out or not, but ideally, sending an RPC call
should be acheivable with code such as:
req = new Class();
// For unnamed, by-order arguments:
req.addArgument(arg1);
// For named arguments:
req.addArgument("argument_1", arg1);
By RPC you probably mean XML-RPC?! JSON-RPC?
How else than by tying yourself to a specific RPC "schema" would you how
to encode arguments in the request body.
I think this is something that's not imminently necessary inside a
transport class (is it that what we are discussing here?).
IMOH this should be factored out of the core class, and maybe rolled
into some kind of encoder/decoder.
How do you choose which HTTP method to use?
This was something that was discussed in a previous thread. The general
feeling seemed to be that there wasn't much use for the GET method. That
said, HEAD-only requests could be useful. In response, how about we add
a static method:
Class.setDefaultHTTPMethod(method)
Where, once again, method is one of a few class-level constants:
Class.methods.GET
Class.methods.POST
Class.methods.HEAD
<gasp>
Oh, I must have missed that discussion.
<rant>
No, use for GET? I'm close to crying. Who can say such a thing?
I think GET is very, very, and let me say this again, VERY important.
In fact it's the most common operation in the HTTP. So how come there's
no use for GET?
I'm developing an application that makes heavy use of qooxdoo and AJAX
related stuff, and I'm _constantly_ using GET (in the sense of reading
data) operations.
Omitting GET or restricting to POST would be like ignoring HTTP
altogether. This *is* the foundation of the internet/world wide web
</rant>
Sorry, for that.
But why not simply define the method via a string property? HTTP method
names are defined outside qooxdoo and can be considered common sense, so
why bother wrapping it in objects?
There are a few other things I'd like to look at once a good, solid (and
tested) implementation of this is done. Ideally, I'd want to build
something that makes Atlas look weak.
Looking forward to that :)
Thanks. :-) Whilst I was completing my SE degree, felt that a lot people
didn't appreciate that design work was "real" software engineering and
were a bit too eager to start coding. As is commonly know, the later one
starts coding, the earlier one finishes (assuming that the spent time on
requirements modelling and design as opposed to drinking alcohol and
playing games...)
As it's always the problem with common sense: Too few people follow it!
Cheers
Benjamin
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Qooxdoo-devel mailing list
Qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
