I think you can separate those issues: 1) Loads SWFs into each other without breaking the container nor 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 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]
