On Tue, Jun 2, 2015 at 2:15 PM, Alex Harui <aha...@adobe.com> wrote:
>
>
> On 6/2/15, 10:38 AM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote:
>
> >A couple questions;
>
> >
> >2. Running into problems with interfaces, if we use DOM,
> >HTMLElementWrapper.element needs to be Element not Object correct? If not,
> >you don't key code completion in the IDE.
>
> There are probably lots of places where the jsdoc annotation is Object
> when it can be something more specific. A lot of the jsdoc I did was
> early when I just needed to get the tools to stop complaining. So feel
> free to tighten up the jsdoc and/or use a more specific type than Object.
>
> >
> >3. flexjs_wrapper can't exist on Element, it's not dynamic, does it nee to
> >be dynamic or do we just use array access?
> >
> >this.element['flexjs_wrapper'] = this;
>
> Ah yes, there are some places where we hack JS “classes”. I’m open to
> ideas on what to do. Can we subclass Element and add flexjs_wrapper?
>
>
I don't think we want to do this, Element is on the DOM so when and Element
is used it will need to be of type Element when it gets compiled.
I was just thinking of a getting in the super class;
protected function get wrapper():Object {
return element['flexjs_wrapper'];
}
What type is the wrapper, an Element? Still learning here.
> >
>
> >4. For DOM elements and the closure compiler, does it expect type Element,
> >for instance is below correct?
> >
> >/**
> > * @expose
> > * @type {Element}
> > */
> >org_apache_flex_core_UIBase.prototype.positioner;
>
> Not sure what you mean by “expect”, but the code snippet should work.
>
Well I am trying to keep my bearings straight, gcc "knows about" Element in
the DOM so it needs to be Element.
>
> >
> >5. The API now needs to be yanked out of Core/as/src into another
> >directory
> >like Core/api/src, so the as Flash and as HTML ActionScript can share the
> >same interfaces, correct? What would be the plan?
>
> You know, I went and moved everything into up to 3 folders (as, js, asjs),
> then found out that FB only supports one folder path per source attachment
> for a SWC. So now, when debugging you sometimes have to switch source
> attachments from as to asjs. So, I’m totally up for another folder
> restructuring.
>
> So, not sure what files need to be yanked out and shared, but seems like
> we have 3 different classes of source files;
>
> 1) AS for Flash
> 2) AS for JS
> 3) AS for both Flash and JS
>
> I wonder if we need to plan ahead for any JS source for something we need
> to hack in that can’t be described in AS.
>
We did this in Randori;
[JavaScript(source='my.js")]
public function someJsFunction():void {}
In the emitter I checked for that tag, if found I loaded the .js file and
stuck it inside the function's curly braces, viola, pure js that doesn't
get crapped on in the compiler.
>
> Anyway, do you happen to know how IJ associates source with SWCs for
> debugging? FB would rather we put #1 and #3 in the same source folder,
> but that makes describing what gets cross-compiled to JS more difficult.
> We could make COMPJSC smarter and ignore files with some directive in it
> so folks don’t need to keep adding to a list of files when adding new
> files.
>
No, this would be a good question for Fred, don't forget to ask him.
>
>
> >
> >Lots more but I thought I would start with this.
> >
> >So from my sketchy tests we have:
>
> Freakin’ cool! FWIW, I implemented a custom asdoc @ keyword that
> suppresses casting functions in the JS output. Search for @flexjsignore.
> Kinda hacky but saves on some output code that doesn’t matter in the JS
> world.
>
Ok, I will have to look at it to see what you are talking about.
I am going to leave it up to you to figure out how to restructure the
source files when you have time, I don't have time to do that. As it is I
am going to need to draw up some UML sketches so I know exactly what is
going on.
Mike
>
> -Alex
>
>
