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]
