incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [ASJS] Some information on "templates"
Date Thu, 06 Dec 2012 19:45:47 GMT

On 12/6/12 11:39 AM, "Michael Schmalle" <apache@teotigraphix.com> wrote:

> Erik,
> 
> I'm trying to get clear on something.
> 
> What exact classes or interfaces get translated from .as to .js from
> the framework directories?
IMO, that's in flux.  I haven't looked at Erik's refactoring, but in my
version each component on the AS side was broken into MVC "beads".  I didn't
do that on the JS side, but right now I think we should, then the M & C
beads can just be cross-compiled.  The V beads are where all flash APIs will
be used, so equivalent JS V beads will be created by hand.


> 
> 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
>> 

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


Mime
View raw message