I'm talking about a live preview that's created from the MXML markup. It doesn't pay attention to any of the AS. The components are created on the fly from the XML. There would be no interaction.
With your live coding example, you start coding and when you save you create a new swf. That swf is watched (or would be watched) and it's then reloaded when the date has changed. Now you reload it and you have a fully debug swf you can interact with. The difference between the two approaches is that the time it takes to get to see that first preview. Based on Flex MXL project compile times for me range from 1 - 20 seconds. I don't know what FlexJS compile times are. If you only need to preview one MXML page at a time and it doesn't have to be interactive, it might be much faster to parse the MXML of that page on the fly. Let me be clear, creating a compiled fully interactive SWF is preferable and what I'm talking about has clear disadvantages, but if we want to have something that someone can try in the browser, that doesn't require access to a compiler, it's possible to parse the FlexJS markup and create the layout. If someone can setup the FlexJS compiler on the server then you wouldn't need what I'm suggesting. On Sat, Jan 16, 2016 at 10:13 PM, Alex Harui <aha...@adobe.com> wrote: > I'm not sure I understood all of that, and it sounds interesting, but I'm > not clear how you can "assemble" the code that glues the UI together at > runtime without a compiler. For example, if I want to click on something > to change from state A to state B, that is usually done in ActionScript. > > -Alex > > On 1/16/16, 5:20 PM, "jude" <flexcapaci...@gmail.com> wrote: > > >If you do we can do some runtime live rendering without using a compiler. > >I'm doing that now for MXML using only metadata and doing it live for HTML > >markup. > > > >For MXML import there are two passes, one is to check for valid XML and if > >not valid return any errors, then if it is valid, we pass it to the > >MXMLDocumentImporter where it looks up definitions and builds the page > >dynamically from the source code. > > > >For HTML, each keypress, the new source is assembled (arranged) into a > >complete HTML page. It's then sent to the HTML Loader instance and it's > >able to render on the fly. Changes happen almost instantly for layout and > >few seconds if you use images. > > > >For MXML I haven't tried it for live editing. I'll run some tests but I > >think it may render / update in a few seconds. I imagine this would be the > >same for FlexJS. There are certainly things that could speed up rendering > >further. > > > >But, for it to work it needs metadata. Then, you would write an > >FlexJSDocumentImporter class and register the FlexJS components / > >definitions that you want to import. > > > >I'll put these classes in the public FC library and, if no one else gets > >to > >it before I do, they can assemble a (alternative) runtime FlexJS editor / > >viewer. The alternative is to support a in the browser renderer where the > >compiler is not available (client side only) that Om was talking about. It > >wouldn't support the AS3 though. > > > >On Fri, Jan 15, 2016 at 9:45 PM, Alex Harui <aha...@adobe.com> wrote: > > > >> > >> > >> On 1/15/16, 8:39 PM, "jude" <flexcapaci...@gmail.com> wrote: > >> > >> >Does FlexJS support a reflection like describeType method? Is there > >>Flex > >> >like metadata in it? > >> > >> We haven't implemented that yet. I was just about to start in on some > >>of > >> the framework-related code for some of it. It is needed to do a more > >> Spark-like component set. > >> > >> -Alex > >> > >> > >
