Hi Alex, I understand and agree with all that you said.
To sum up, I will spend time on the current asdoc compiler only to fix bugs, or add very easy tweaks, because I already know the code, so it shouldn't be too difficult. I will not go into anything complex. Regarding Falcon, it may be too early for me too dive into its code (time, time, time,...) But later, I will do that with pleasure, and will try to contribute to it, in my domains of knowledge. Maurice -----Message d'origine----- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : vendredi 4 octobre 2013 19:13 À : dev@flex.apache.org Objet : Re: Thoughts about ApacheFlex ASDOC On 10/4/13 12:46 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >Hi Alex, > >> 1) The Falcon compiler code base may be easier to work with. > >I don't know anything about the Falcon compiler, so excuse if my >questions are dumb: >- Does the Falcon compiler include ASDOC compiler ? or is it limited to >AS/MMXL compiler ? I don't think anyone has tested its ASDoc capabilities, but there is an ASDoc folder of source code. Falcon was designed for more than just ABC output. I would rather have you contribute to getting Falcon's ASDoc up to speed than making modifications to the MXMLC code base, but it is entirely up to you. >- Is it already operational ? Pretty much. It isn't production ready yet, but the parsing phase is working pretty well these days. > >- Also, current ASDOC build uses asdoc ant task, which is a wrapper on >the asdoc compiler. Will that change in the future? There is a similar wrapper for Falcon. > >> 2) I've been wondering if an AIR app would easier to maintain as the >>ASDoc generator. I don't know how XSLT at all. >Basically asdoc generation is done in two passes: >- first, java-based classes >(flex2.compiler.asdoc.TopLevelClassesGenerator and co) will parse the >source code for asdoc comments, and generate high-level xml files with >all the asdoc data. That makes the XLST job much easier. The result is >in asdoc-ouput/tempdita/ >- then the XSLT in asdoc/templates will parse these xml files and >generate the final html structure. Yeah, it is that last part that means that only the few of you who know or want to learn XSLT can contribute to the quality of our doc. IMO, e4x is also pretty good as XML manipulation and more folks understand it. I think it might also allow us to do fancier things and handle exceptions that XSLT may not. > >> 4) I think another feature we need ASDoc is to have links to the >>Adobe ASDoc for flash.*.* packages. >Fully agree that the flash.*.* ASDOC should be added. >So of course having the flash API seamlessly embedded in the ApacheFlex >doc (that is inherited props, shared UI, etc...) is out of reach, but >providing a link would be acceptable, and shouldn't be that difficult >:-) > >Regarding the asdoc as an AIR app: >I understand the concerns but that's a lot of work. >I was more on the idea of "tweaking" the existing tools, than rewriting >everything... >So if someone else is interested in doing it, "pourquoi pas ?" :-) Agreed. Just wanted to put that out there. It would potentially be an excellent showcase app. My main point here was to caution you about spending too much time and effort on MXMLC and HTML presentation. As long as you can achieve your goals with tweaks that fine, but if you run into something hard, it may be better to work with Falcon and AIR instead. -Alex