flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <apa...@teotigraphix.com>
Subject Re: Design View AIR App (Was: Re: Apache Flex GUI Designer tools)
Date Wed, 03 Oct 2012 11:33:25 GMT
Quoting Roland Zwaga <roland@stackandheap.com>:

>>> Well Roland, I looked at the code again. I need to take it down a notch,
>> there are about 3 different things I am looking at.
>> 1. Direct communication from an IDE to Browser over a socket.
>> 2. How we could use existing code, IE SWFBridge.
>> 3. If writing a plugin using this framework is relevant.
>> When I first looked at it I was more looking at how they were
>> communicating with the FlashPlayer not the actual use of ActionScript to
>> extend Eclipse.
>> They are just sending commands from a parsed ActionScript/MXML file,
>> creating an AST tree in Eclipse using the parser, sending that AST back to
>> the Player and loading it into there ActionScript AST tree that then is
>> used to send real commands back to Eclipse.
>> This is crazy, but I actually understand what they are doing, hmm this
>> looks like something I would have tried if I had the time. :
> Ok, I'm kind of of following, but I'm not sure I understand what the AST
> represents, is that the AST of a source file? So basically you create an
> alternative view for an actionscript file?
> So, in the case of MXML, you woudl basically receieve an AST that
> represents the MXML file in question, and the Actionscript view is just
> supposed to interpret that AST and render a visual representation?
> Would that more or less describe what is going on?
> (Just trying to grasp the patterns here...)

Don't quote me on this since I only looked at the code for about 10  
minutes but...

What I think they are doing is translating and ActionScript API and  
mapping it to extensions of Eclipse. So this means;

A "ActionScript Plugin" is mapped to and AS class, which is loaded by  
an Eclipse View wrapper (holds the FlashPlayer). When the plugin is  
activated in Eclipse, the actual AS class file is loaded from the View  
wrapper bridge. The AS plugin source code is parsed by the codemodel  
in Eclipse, XML is sent back to the Plugin view.

Now that the SWFBridge has an XML AST tree(in the FlashPlayer), it  
loads itself and uses a vistor to traverse nodes where it finds  
specific implementations of Eclipse from the documented AS Plugin API  
they have.

When it finds implementations, it sends the commands translated from  
AS back to Eclipse's plugin API to say add menu items, do any other  
things that the AS plugin has implemented.

It's a pretty ingenious abstraction, I wonder how it performs.

So to answer your question,

- Eclipse Parses AS plugin source code
- FlashPlayer loads parsed XML AST Tree
- FlashPlayer interprets the AST using a DOM
- FlashPlayer then inspects the DOM for mapped implementations of the  
Eclipse Plugin API
- FlashPlayer then sends commands back to Eclipse's Java API
- Eclipse Java then executes the mapped message from FlashPlayer

Does this make sense?


Michael Schmalle - Teoti Graphix, LLC

View raw message