that is a good summary and yes it sounds like a massive amount of work.
I have never seen an open source MXML compiler but I have seen XAML open
source compilers.
extras/mxml.xsd seems to have disappeared but this project
(http://code.google.com/p/xsd4mxml/) seems to be useful.
James
On 13/03/2012 14:01, Arnoud Bos wrote:
On Mar 13, 2012, at 1:17 PM, James Cowan wrote:
MXML/AS3/Flex are conceptually identical to XAML/C#/WPF. They borrow a lot of
ideas from previous XML UI technologies.
MXML/haXe/Flex does sound quite viable.
Sure, it could be done. But i guess someone should be willing to port the
actionscript code.
A mapping on haxe-nme should be possible as it implements the flash displaylist.
some challenges here:
==================
- the code base is huge
- bindings. Could be solved with macro's i hope
- embed and other metadata. Could be solved with macro's i guess
- actionscript has 4 access modifiers, haxe only public and private
- namespaces are not present in Haxe, not sure how to solve that
- E4X, but i'm not sure how much this is used in the SDK.
- uint data type although i 99.9% of the cases it can be mapped on a
Haxe Int (i just ported a SHA256 from actionscript to haxe that used uints
and it works)
- AND Probably MANY issues that i forgot to mentio here...
But, if you want to do that it's probably best to extend the as3hx project (see
haxe trunk) which
does basic translation from as3 to haxe and try to solve those issues described
above in an automated way.
IF you could solve all those isuess in an automated way then you could every
time the flex
trunk changes generate an automated haxe port :-)
so if you got that all working, which would take a while then you could at
least test performance etc.
If that's ok then the fun part. Write a MXML (or Haxe Markup Language :-)
compiler front end for haxe...
It would be a massive amount of work and i didn't mention the hard things like
modules, resource bundles, runtime libs, swc's etc.
But indeed it would be very nice!
cheers,
arnoud
The issue is that both Silverlight and Flash are dieing and haXe represents a
future for Flex because it is clever cross compiler
technology that targets lots of platforms - native o/s including mobile via
nme/cpp, vm via neko, browser via js and swf and in time java/c#.
The problem with haXe is that a language/compiler is only a part of a
development environment - libraries/frameworks for persistence and GUI
are as important. If I could develop in haXe and use a haXe enabled Flex as my
GUI framework and a haXe enabled ORM (on the lines of
JPA/Hibernate) as my persistence framework and then could target
desktop/javascript/swf/mobile from the same code base, that would be awesome
I like haxe's own SPOD implementation
It may be a pipe dream if every library has to be rewritten at the source level
and I can understand anyone baulking at that. I will ask Nicolas
if there might be a way of interfacing Flex or say Hibernate (when the java
target is ready) without rewrite at source level. I imagine he will
point at the migration tools and say that once the migration from AS3 to haXe
is done, one would dump the AS3 code.
I live in the town where "Flash on the Beach" had its last year - there was a
big local Flash community but now it has moved on to Javascript (with canvas)
and to mobile and they are much more interested in
HaXe/Corona/Titanium/Marmalade than Flex/Air mobile.
Java/Swing failed on the desktop and the browser (applets) mainly because of
runtime issues (and competition from Microsoft/Apple) and I would be sorry to
see Flex die because the runtime (Flash) died under it.
I would certainly see a future for Flex on Flash/Air technology if Adobe
donated the defunct Air for Linux to Apache and Apple issued a statement
embracing it
on OSX but I do not see this happening soon.
Air and flash runs on osx / IOS, so why bother?
James
