incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <apa...@teotigraphix.com>
Subject Re: [ASJS] Some information on "templates"
Date Thu, 06 Dec 2012 19:39:42 GMT
Erik,

I'm trying to get clear on something.

What exact classes or interfaces get translated from .as to .js from  
the framework directories?

What files are going to be maintained by hand and tests? I'm still a  
bit confused to the flow.

You have FlexObject.js, FlexGlobals.js which obviously has no  
correlation in .as. What about that?


Mike




Quoting Erik de Bruin <erik@ixsoftware.nl>:

> That looks very promising! Some tweaking is needed, and some of the
> output (the bottom part mostly, I guess that is for some kind of
> introspection that is in my template provided by other methods) isn't
> needed, at least not from what I understand.
>
> I'll look into the details of the new output tomorrow and indicate if
> and what changes would be nice ;-)
>
> EdB
>
>
> On Thu, Dec 6, 2012 at 7:01 PM, Michael Schmalle
> <apache@teotigraphix.com> wrote:
>> Hi,
>>
>> Right now after about 5 hours of researching and messing around I can get
>> the following using the closure compiler flag;
>>
>> //=================================================================
>> AS CODE
>>
>>
>> package com.example.components
>> {
>>
>> import flash.display.Sprite;
>>
>> public class MyTextButton extends Sprite
>> {
>>     public function MyTextButton()
>>
>>     {
>>         super();
>>      }
>>
>>     private var _privateVar:String = "do ";
>>
>>     public var publicProperty:Number = 100;
>>
>>     public function myFunction(value: String): String
>>     {
>>         return "Don't " + _privateVar + value;
>>     }
>> }
>> }
>>
>>
>> //=================================================================
>> JS CODE
>>
>> /** @preserve CROSS-COMPILED BY MXMLJSC (329449.1) ON 2012-12-06 12:55:52
>>  */
>> /**
>>  * CROSS-COMPILED BY MXMLJSC (329449.1) ON 2012-12-06 12:52:19
>>  *
>>  * Class: com.example.components.MyTextButton
>>  * @constructor
>>  * @extends flash.display.Sprite
>>  */
>>
>> // Constructor
>>
>>
>> /**
>>  * Constructor: com.example.components.MyTextButton()
>>  * @constructor
>>  * @this {com.example.components}
>>  */
>> com.example.components.MyTextButton = function()
>> {
>>         var self = this;
>>                 self.publicProperty /* : Number */ = 100;
>>                 goog.base(this);
>>                 return self;
>> }
>>
>>
>> goog.inherits(com.example.components.MyTextButton, flash.display.Sprite);
>>
>> /**
>>  * Member: com.example.components.MyTextButton.prototype._CLASS
>>  * @const
>>  * @type {com.example.components.MyTextButton}
>>  */
>> com.example.components.MyTextButton.prototype._CLASS =
>> com.example.components.MyTextButton;
>> ;
>>
>> /**
>>  * Member: com.example.components.MyTextButton._privateVar
>>
>>  * @private
>>  * @type {string}
>>  */
>> com.example.components.MyTextButton.prototype._privateVar /* : String */ =
>> "do ";
>> ;
>>
>> /**
>>  * Member: com.example.components.MyTextButton.publicProperty
>>  * @type {number}
>>  */
>> com.example.components.MyTextButton.prototype.publicProperty /* : Number */
>> = 100;
>> ;
>>
>>
>> /**
>>  * Method: com.example.components.MyTextButton.myFunction()
>>  * @this {com.example.components.MyTextButton}
>>  * @param {string} value
>>  * @return {string}
>>  */
>> com.example.components.MyTextButton.prototype.myFunction = function(value /*
>> : String */) /* : String */
>> {
>>                 /** @type {com.example.components.MyTextButton} */
>>                 var self = this;
>>                 return (("Don't " + self._privateVar) + value);
>> }
>>
>> /**
>>  * Member: com.example.components.MyTextButton._PACKAGE
>>  * @const
>>  * @type {com.example.components}
>>  */
>> com.example.components.MyTextButton._PACKAGE = com.example.components;
>>
>>
>> /**
>>  * Member: com.example.components.MyTextButton._NAME
>>  * @const
>>  * @type {string}
>>  */
>> com.example.components.MyTextButton._NAME = "MyTextButton";
>>
>> /**
>>  * Member: com.example.components.MyTextButton._FULLNAME
>>  * @const
>>  * @type {string}
>>  */
>> com.example.components.MyTextButton._FULLNAME =
>> "com.example.components.MyTextButton";
>>
>> /**
>>  * Member: com.example.components.MyTextButton._SUPER
>>  * @const
>>  * @type {flash.display.Sprite}
>>  */
>> com.example.components.MyTextButton._SUPER = flash.display.Sprite;
>>
>> /**
>>  * Member: com.example.components.MyTextButton._NAMESPACES
>>  * @const
>>  * @type {Object}
>>  */
>> com.example.components.MyTextButton._NAMESPACES = {
>>         "_privateVar::7:com.example.components.MyTextButton" : true,
>>         "publicProperty::2" : true,
>>         "myFunction::2" : true
>> }
>>
>> adobe.classes["com.example.components.MyTextButton"]  =
>> com.example.components.MyTextButton;
>>
>> /CODE
>> //=================================================================
>>
>>
>> Is this a base we can work off of Erik?
>>
>> Let me know what you would want changed within that scope.
>>
>> I know how I can get the imports (IE require()) in. There is some funky
>> business going on with the constructor that will need to be sorted out.
>>
>> JSDoc comments are not hard to add/remove either with tags etc..
>>
>>
>> Mike
>>
>>
>>
>>
>>
>>
>> Quoting Erik de Bruin <erik@ixsoftware.nl>:
>>
>>> Correct.
>>>
>>> I have created 'tests' directories on both the AS and JS frameworks,
>>> and plan to use FlexUnit for AS and Jasmine for JS unit testing. That
>>> covers the frameworks. I imagine we build pre- and postcompile tests
>>> for the project code as well.
>>>
>>> And leaving out the intermediate step (i.e. have FalconJS directly
>>> output minified JS, or have FalconJS call the Closure Compiler
>>> directly as a post compile step) will only increase the difficulty in
>>> testing for and more importantly, debugging any issues in the output
>>> JS.
>>>
>>> Finally, not having intermediate (annotated) JS files will make it
>>> impossible to let the Closure Builder do it's magic. That magic is an
>>> important part of having a highly optimised final output. The Builder
>>> calculates the dependencies between the project code, the FlexJS JS
>>> framework and the Closure Library, allowing it to remove unused code
>>> (no penalty for using a large library of which you only use one
>>> method) and to minify all internal references, while the annotation
>>> prevents the renaming or even deletion of public interfaces.
>>>
>>> All in all, the "intermediate" step, at least for the first few
>>> versions looks to me like a valuable tool and a way to allow for
>>> speedy development of both projects as well as the frameworks.
>>>
>>> EdB
>>>
>>>
>>>
>>> On Thu, Dec 6, 2012 at 4:56 PM, Michael Schmalle
>>> <apache@teotigraphix.com> wrote:
>>>>
>>>>
>>>> Quoting Carol Frampton <cframpto@adobe.com>:
>>>>
>>>>>
>>>>>
>>>>> On 12/6/12 7 :49AM, "Erik de Bruin" <erik@ixsoftware.nl> wrote:
>>>>>
>>>>>> Mike,
>>>>>>
>>>>>> After I'm done fixing the mess I made in SVN, I'll start work on
the
>>>>>> 'template', but here is the basic idea to get you started: I would
>>>>>> like the compiler to output "intermediate" JS, by which I mean "human
>>>>>> readable". My Publisher then takes this intermediate code and puts
it
>>>>>> through the Google Closure Builder, which optimises and minifies
it.
>>>>>> The advantage of having the "intermediate" step is that it makes
>>>>>> debugging much (MUCH) easier. It will allow us to write tests,
>>>>>> something that minified code won't. And it will let us run the code
in
>>>>>> the various browser based tooling and have the output make sense.
>>>>>
>>>>>
>>>>>
>>>>> If you use an intermediate form to test how to you know there aren't
>>>>> bugs
>>>>> introduced by the publishing process?
>>>>>
>>>>> Carol
>>>>
>>>>
>>>>
>>>> Isn't the publishing process the closure compiler which google has tests
>>>> for
>>>> when it compiles out the minified optimized js?
>>>>
>>>> I probably have more time into investigating the corss compile code In
>>>> FalconJS and I have to say as it stands we don't even know if our
>>>> compiler
>>>> is creating bugs in the output js. It seems Adobe was unit testing the js
>>>> but we don't have any of those tests.
>>>>
>>>> So its reasonable to think we need to have tests for js that is compiled
>>>> by
>>>> FalconJS in the intermediate stage.
>>>>
>>>>
>>>>
>>>>
>>>> Mike
>>>>
>>>> --
>>>> Michael Schmalle - Teoti Graphix, LLC
>>>> http://www.teotigraphix.com
>>>> http://blog.teotigraphix.com
>>>>
>>>
>>>
>>>
>>> --
>>> Ix Multimedia Software
>>>
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>>
>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com


Mime
View raw message