[
https://issues.apache.org/jira/browse/THRIFT-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Lerman updated THRIFT-518:
-------------------------------
Attachment: thrift_as3.diff
A couple notes on the patch:
* The format I'm using for asynchronous calls is slightly awkward. If you have
a thrift function:
{code}
string ping(1:string message) throws (1:MyException e)
{code}
it will generate the following AS3 interface:
{code}
//function onError(Error):void;
//function onSuccess(String):void;
function ping(message:String, onError:Function, onSuccess:Function):void;
{code}
which you'd call using as:
{code}
impl.ping("hello", function(error:Error) { trace("error");},
function(response:String) {trace(response);});
{code}
It should probably be cleaned up and made more strongly typed by generating
some kind of listener interface per method, but this works for now.
* To use the generated objects, you need to include the library classes, either
by including lib/as3/src in your classpath, or by generating libthrift.swc
using ant and the build.xml in lib/as3. Generating the SWC requires the free
Flex SDK, and doesn't currently get built automatically as part of the main
Thrift build process since I didn't want to mess with the build scripts yet.
* There's a bindable flag in the compiler which will add [Bindable] Flex
metadata tags to all the objects. The implementation is a little odd - it
currently generates the following code per setter:
{code}
[Bindable(event="thriftPropertyChangeN")]
public function set foo(foo:type):void {
this._foo = foo;
this.__isset_foo = true;
dispatchEvent(new Event("thriftPropertyChangeN"));
dispatchEvent(new PropertyChangeEvent(PropertyChangeEvent.PROPERTY_CHANGE));
}
{code}
We have to use a custom event per member rather than the default class level
[Bindable], because if you use the default, the setter only gets called if the
value has changed. This means calling foo.setIntValue(0) will not cause
foo.isIntValueSet() to return true since the value of foo._intValue wasn't
changed so the setter was never called. However, if you just use a custom
event, then collections won't be able to detect when Thrift elements in the
collections have changed since they listen for PropertyChangeEvents. So, we
dispatch both and that seems to work. If anyone has a better suggestion, let
me know.
* AS3 doesn't have a 64-bit int type so I left it out - I'm not sure what will
happen if you attempt to compile a Thrift definition containing long integers.
* Some of the code is pretty ugly and there are no test cases defined. If
Thrift decides to officially support AS3 at some point, we should invest some
time in cleanup and testing.
> as3/flash/flex generator
> ------------------------
>
> Key: THRIFT-518
> URL: https://issues.apache.org/jira/browse/THRIFT-518
> Project: Thrift
> Issue Type: New Feature
> Reporter: Dave Lerman
> Attachments: thrift_as3.diff, thrift_as3.diff
>
>
> There's been various mailing list discussions about ActionScript 3 support,
> but I didn't see an associated JIRA so I thought I'd create one.
> The goal would be to allow a Flash or Flex project to call a Thrift service
> as an alternative to Flash's built-in web services and RPC implementations.
> A developer might want to use Thrift instead of SOAP, REST or AMF for it's
> code generation, strong typing, or for interoperability with existing
> Thrift-based services.
> The Flash code would look something like:
> {code}
> public function testFunction() {
> var client:Service = new ServiceImpl(new TBinaryProtocol(
> new THttpClient(new URLRequest("http://service.com";)));
> client.ping("hello world", handlePingResponse);
> }
> private function handlePingResponse(response:String):void {
> trace("RESPONSE: " + response);
> }
> {code}
> where Service is the generated Flash interface, ServiceImpl is the generated
> client which implements Service, and THttpClient is an implementation of
> TTransport.
> Note that Flash is a single-threaded environment so the call is necessarily
> asynchronous.
> The attached patch is a first-pass at an implementation. It's basically a
> line-for-line partial port of the java lib and generator. The lib contains a
> single protocol (TBinaryProtocol) and a single transport (THttpClient), along
> with a generator which generates the interface and client implementation
> (server implementation is skipped since this seems unlikely to be useful).
> It still needs some work -- it's untested except for the specific thrift
> services we use internally, and needs documentation and cleanup. I'm happy
> to do this work if there's general interest in adding as3 support - let me
> know.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
