Quoting Roland Zwaga <rol...@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?
Mike
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
