Simple mode should work.
It should not be too hard to make Advanced mode work. The LFC compiler is
already doing a lot of the same stuff.
On 2011-12-14, at 19:30, Raju Bitter wrote:
> Thanks, Tucker. The use of the Closure compiler introduces several
> rules which you have to follow within your JS code:
>
> SIMPLE MODE
> "with" is not allowed:
> When you use with the Compiler can't distinguish between a local
> variable and an object property of the same name, and so it renames
> all instances of the name.
> Furthermore, the with statement makes your code harder for humans to
> read. The with statement changes the normal rules for name resolution,
> and can make it difficult even for the programmer who wrote the code
> to identify what a name refers to.
>
> String representations of function or parameter names:
> The Compiler renames functions and function parameters but does not
> change any strings in your code that refer to functions or parameters
> by name. You should thus avoid representing function or parameter
> names as strings in your code. For example, the Prototype library
> function argumentNames() uses Function.toString() to retrieve the
> names of a function's parameters. But while argumentNames() might
> tempt you to use the names of arguments in your code, Simple mode
> compilation breaks this kind of reference.
>
> ADVANCED MODE
> External references
> In order to rename global variables, functions, and properties
> correctly, the Compiler must know about all references to those
> globals. You must tell the Compiler about symbols that are defined
> outside of the code being compiled. Advanced Compilation and Externs
> describes how to declare external symbols.
>
>
> Using string names to refer to object properties:
> The Compiler renames properties in Advanced mode, but it never renames
> strings. If you need to refer to a property with a quoted string,
> always use a quoted string
>
> In Advanced mode the Compiler collapses object properties to prepare
> for name shortening.
> var foo = {};
> foo.bar = function (a) { alert(a) };
> foo.bar("hello");
> will become
> var foo$bar = function (a) { alert(a) };
> foo$bar("hello");
>
> Full list of limitations can be found here:
> http://code.google.com/closure/compiler/docs/limitations.html
>
> I guess it would be quite a lot of work to modify the LFC and the JS
> generator to conform to the Clojure rules.
>
> - Raju
>
>
> On Wed, Dec 14, 2011 at 5:20 PM, P T Withington <[email protected]> wrote:
>> Presumably you could run OL with the -S option to get the JS 'assembley' and
>> then run it through the closure compiler and compare that with the
>> 'assembled' js code the OL compiler generates.
>>
>> On 2011-12-13, at 18:43, Raju Bitter wrote:
>>
>>> The simple Flex app without Closure optimizations is 5mb in size, the
>>> optimized version 2.5 mb. Wow! How much better off would OpenLaszlo be
>>> with the Closure optimization...
>>>
>>> On Wed, Dec 14, 2011 at 12:40 AM, Raju Bitter
>>> <[email protected]> wrote:
>>>> Here's a video recording of the presentation:
>>>> https://my.adobeconnect.com/_a295153/p7ysfeovw33/?launcher=false&fcsContent=true&pbMode=normal
>>>>
>>>> On Tue, Dec 13, 2011 at 5:29 PM, Raju Bitter
>>>> <[email protected]> wrote:
>>>>> The Spoon project team has posted some information in their blog on
>>>>> the Flex Summit demos of FalconJS. Here are some interesting facts:
>>>>> http://www.spoon.as/2011/flex-summit-live-updates/
>>>>>
>>>>> + FalconJS will be donated as open source to Apache
>>>>>
>>>>> + FalconJS AS3 compilation:
>>>>> AS code -> falcon front end / falcon js code gen -> google closure
>>>>> compiler -> faster JS Code
>>>>> Standards used: HTML, JS, SVG
>>>>>
>>>>> + “Falcon JS” refers to two experimental utilities:
>>>>> – AS-> JS
>>>>> – MXML -> HTML/CSS/JS
>>>>>
>>>>> + "Seeing example apps running. They look really good."
>>>>>
>>>>> That actually sounds promising. The DHTML code should be much more
>>>>> optimized with Google Closure support, assuming that FalconJS supports
>>>>> the advanced compilation mode.
>>>>>
>>>>> There will be some changes regarding tooling
>>>>> – Flash Builder
>>>>> — will release support for apache flex
>>>>> — removing unpopular and expensive to maintain features: Design View,
>>>>> DCD, and Catalyst workflows
>>>>> – flash catalyst discontinued (with catalyst cs5.5 support for flex 4.5)
>>>>> – monocle continues as a priority
>>>>>
>>>>> It sounds like the latest components are optimized for FalconJS
>>>>> already, that means Adobe has done most of the work to have complex
>>>>> apps running in JavaScript.
>>>
>>
