On 12/6/12 11:39 AM, "Michael Schmalle" <apa...@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 <e...@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
>> <apa...@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 <e...@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
>>>> <apa...@teotigraphix.com> wrote:
>>>>>
>>>>>
>>>>> Quoting Carol Frampton <cfram...@adobe.com>:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 12/6/12 7 :49AM, "Erik de Bruin" <e...@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
