flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From flex capacitor <flexcapaci...@gmail.com>
Subject Re: MXML Azzurro
Date Mon, 13 Feb 2017 22:18:06 GMT
For drawing to a FlexJS *swf* it would be much simpler than a partial or
all JS method. The way it works now is it loads an embedded application.swf
via loader.loadBytes(). The application.swf is an empty compiled Spark
Application. Once that's loaded the MXMLDocumentImporter class parses the
MXML and using a class map creates the elements and adds them to the
Application instance. Each time the editor is updated all the elements are
removed and then added again.

I didn't go the agent route for a few reasons. The LocalConnection would
sometimes hang and at first I couldn't figure it out. I tracked it down to
if previous connections were not closed correctly. So if someone reloaded
the browser not all of the connections would be closed. I got around this
by creating new connections each time. The second reason is I already had a
lot of work in the existing method using a parser and loading elements onto
an empty application swf. The reason for loading a separate swf was so that
the design view application could have it's own system manager, style
manager, sandbox and so on. It currently inherits the styles from the
container application but it in the future it could be sandboxed so styles,
classes and so on are not inherited. For my purposes at the time it made

For a FlexJS Importer class it could use local connections. The code from
the MXMLLiveEditAgent that you made a while back sends the changes through
the local connection. But it doesn't rebuild the swf from scratch or maybe
it does? Here is the MXMLLiveEditPlugin class
<https://gist.github.com/monkeypunch3/3044426aaaed2e66d4a4399814b68959> and
the main MXMLLiveAgent class

Here's the current MXMLDocumentImporter class
and the decoupled one I started to work on here
(untested). Here is the main online editor application
A FlexJS Importer would roughly follow the MXMLDocumentImport class at
least. Here is the project view source
There are areas that need refactored and performance would probably
increase 10 fold.

On Mon, Feb 13, 2017 at 10:47 AM, Alex Harui <aharui@adobe.com> wrote:

> On 2/13/17, 5:20 AM, "flex capacitor" <flexcapacitor@gmail.com> wrote:
> >Thanks. I'm not sure but it would probably take around a week to a month
> >depending on what route you go and if you want JS output or Flash output.
> >If you wanted to use the existing application you would create a
> >FlexJSImporter and have it write to a div or iframe. It could reuse all
> >the
> >classes but it would require the Flash Player plugin. The second route
> >would be to create it all in FlexJS. That would be more work since you
> >would have to update any code that uses Flash specific APIs and you would
> >have to update the classes for any changes in the FlexJS reflection API
> Doesn't this work via an agent in the running application?  Seems like
> we'd only need to supply a FlexJS-knowledgable agent in order to see it
> work for FlexJS SWFs.  Does it use LocalConnection?  If so, then to get it
> to work for JS, we'd either need to rewrite the communications to use
> sockets, or require a special Flash-based agent that talks to the JS Agent.
> Of course I could be completely wrong...
> -Alex

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message