AMFConnection with Haxe 4

Haxe
#1

I am trying to port a Flash application to OpenFL. The applicaiton is coded using Haxe 3, and I am trying first to port this to Haxe 4. One of the main issues I am encountering is getting AMFConnection compiling.

Initially I encountered the error message: "haxe.remoting.AMFConnection has no field … ". I have found this forum post about the issue, but the actual changes I need to make to the code to make it compile is not clear to me.

Here is the definition of the service:

class PDFBuilder
{	
	public static var service = AMFConnection.urlConnect('amfphp-1.2/gateway.php');

And in another class it is referenced like this:

PDFBuilder.service.FormBuilder.buildPDF.call([generateXSL()], function ( d : Dynamic )
        {
         ...
        });

I tried following what was mentioned in the post mentioned above and made the following changes to my code:

import haxe.remoting.AsyncProxy;
class Api extends AsyncProxy { }

class PDFBuilder
{
    public static var service_ctx = AMFConnection.urlConnect('amfphp-1.2/gateway.php');
    public static var service =  new Api(PDFBuilder.service_ctx.resolve("Api"));

But now I get the following error: “Invalid number of type parameters for haxe.remoting.AsyncProxy”. I am not sure what type needs to be added AsyncProxy to get this to compile.

#2

Hi @Bruce_Hill. Unfortunately I’m not familiar with the method of remoting you’re working on here, it would appear to have been shelved as far as maintenance goes though, existing now only in hx3compat library.

I offer some thoughts, which you’re free to discard of course.

  • Rather than using Haxe (and OpenFL?) to maintain a status quo in continuing a Flash/AIR application, perhaps consider stepping away into a true cross-platform approach, exploiting one of Haxe’s key strengths. Continuing to use AMF is one such example of maintaining the legacy of Flash.
  • OpenFL offers Socket or URLRequest as potential alternatives for communicating with the PHP server. Some changes would be needed on that server of course (just be mindful that the Socket class is a TCP Socket, unless you’re targetting HTML5 in which case it’s exported as a WebSocket).
  • Consider exploiting Haxe to build native, or web-apps, instead of Flash/AIR.
#3

Thanks, @Bink for the thoughts. At the moment I am just trying to port this Flash application to OpenFL so that the application can continue to be used in 2021. I have never worked in Haxe before as this application was developed by another developer over 10 years ago, so I am try at this stage to get the application to compile with as few changes as possible. I will look at replacing AMF with URLRequest if I cannot get, AMFConnection to AMFPHP working correctly.

#4

This might help:

http://old.haxe.org/doc/remoting/proxy

“Type parameters” are included in angle brackets, for example the Haxe array type requires a type parameter to disclose what kind of items are stored in the array (Array<String>, Array<Bool>, etc)

The example above uses the remoting Proxy type like this (where Api is a custom type created by the user):

class ApiProxy extends haxe.remoting.Proxy<Api> { }
#5

Thanks, that is helpful. So I guess this was changed to build type safety in? So, could I define an interface that describes what is being returned by AMFPHP, and then put that interface in the angle brackets?

#6

It looks like this example uses a class type and compiles that for both the server (which I think is when it actually executes?) and for the client (using its signature). It may work using an interface or you could try using a class with empty methods.

#7

Yeah, interface does not seem to work, you are right. Thanks, @singmajesty. I will try with a class with empty methods.