On Mon, Jul 13, 2009 at 5:20 PM, Sebastian Wagner <[email protected]>wrote:
> I think you can separate those issues: > > 1) Loads SWFs into each other without breaking the container nor the > module. I think we have something that works for 1) , which is implemented for the <import> feature, and similarly for the debug evaluator. The mechanism is to create a .swf app which really is just an empty stub that allows it to be loaded via the Loader API (swf9), loadMovie (swf8), or script loader (DHTML). The app main class constructor does nothing except call back that it has loaded, but it's side effect is to install whatever classes are in the module. > > > 2) Problem of compiling modules without actual access to the base-code. Or > in other words: How to compile a method-call to a *core-module* while you > have actually only the module > => I think this is somehow an *advanced feature*, ideally you would need > something similar to what you described with those binary libraries that can > be used to resolve method calls and references. > > sebastian > > Right, the hard part is resolving against other libraries. I think we could implement 1) without too much work, by calling into the code that compiles <import> libraries. You could use the lzc command line compiler compile a 'loadable module' as a standalone .swf, as long as it doesn't need to resolve references to other modules. So it would really be limited to very 'self contained' libraries of code, since it would complain that any 'external' LZX tags were unknown. > > 2009/7/13 Henry Minsky <[email protected]> > > >> The problem right now is that it is difficult to resolve one library >> against another when compiling, because we don't have any persistent >> representation for the type signatures of classes (i.e., the schema). That >> is, we don't really have a supported library format like the ".swc", which >> would let the compiler know the methods and argument types of external >> classes that you refer to. >> >> In the flex compiler, each class maps to an identically named source file, >> so the compiler can resolve references that way from the source code, or >> else it can pull the class type signatures out of a .swc binary library >> file. >> >> In the Laszlo compiler, currently, we only build this class "schema" >> information in memory when compiling an app from source, and we don't write >> it out to a persistent disk file. (Actually, we do have a way to write >> schema files out, which is used in the "binary library" feature that Tucker >> wrote, but that is somewhat experimental right now) >> >> The way the swf9 debugger expression evaluator works now, it relies on >> having your LZX application's intermediate as3 files held in a temporary >> directory, so that the flex compiler can >> resolve any class references against that. So effectively, the whole >> source code of the application >> is available at that point. The debugger-compiler produces a little >> standalone application with just one class with a method that contains the >> expression that you wanted evaluated. That .swf is then loaded at runtime. >> >> We could make the LZX compiler emit a loadable .swf file , using the same >> format we use for loadable modules using the <import> tag now, >> as long as that code didn't have to resolve calls to other lzx code. So >> you could have standalone >> modules which were self contained. The issue is what to do when your >> module refers to a class in another module, and the compiler needs to know >> how to compile the arguments to a method call (is it a string or an >> expression, how many args does the method accept?). >> >> But what we really need is a library format so modules can be resolved >> against each other at compile time. >> >> >> >> >> >> >> On Mon, Jul 13, 2009 at 4:54 AM, Sebastian Wagner >> <[email protected]>wrote: >> >>> hi, >>> >>> a long term goal of many users is to embed their existing SWFs into an >>> OpenLaszlo Application. >>> Or the other way tound: To load a compiled OpenLaszlo SWF into ... >>> weather and existing SWF compiled with Flex or into another OpenLaszlo SWF. >>> >>> Do you have plans for that kind of extension? >>> It would be very useful in terms of Modularization to be able to compile >>> and load Modules at runtime into a Core without the need to have those >>> Modules all available while you are compiling the Core. So that you can load >>> and initiate new Classes dynamically at Runtime. >>> Or just compile a Core Product and ship Modules separated. >>> >>> I read some posts in the forums about loading a canvas into another but >>> it does not seem to me that it was a solution to the problem. Does anyone >>> work or have ideas of that kind of extension? >>> I think the main Issue here is just that you have to load two canvas tags >>> into another and have to register classes and assets at runtime. The >>> *import* tag does something similar. The problem is just => The import tag >>> still needs to code of the module to be available while you compile the >>> core. So there is no real advantage in using this Tag compared to an >>> *include* (if you ignore those Kbits that are loaded at runtime with >>> import.load() instead of an initial include). >>> >>> So my idea for a workaround was: Is there a way of cheating the compiler >>> by : >>> 1) having a tiny container-class that is linked with an *import* tag >>> 2) this gets compiled into the core >>> 3) replace this compiled container-SWF at runtime with the actual module? >>> the problem would be just that you still need the hole core to compile >>> the module ... and some mystery if the this is going to work. >>> >>> >>> Also the other way round is a bummer for users: They see a nice >>> OpenLaszlo Application and want to integrate it into their existing Flex, >>> Flash environment, but they can't as the canvas tag is not compatible for >>> loading it into another SWF. >>> >>> >>> thanks, >>> sebastian >>> >>> -- >>> Sebastian Wagner >>> http://www.webbase-design.de >>> http://openmeetings.googlecode.com >>> http://www.laszlo-forum.de >>> [email protected] >>> >> >> >> >> -- >> Henry Minsky >> Software Architect >> [email protected] >> >> >> > > > -- > Sebastian Wagner > http://www.webbase-design.de > http://openmeetings.googlecode.com > http://www.laszlo-forum.de > [email protected] > -- Henry Minsky Software Architect [email protected]
