> > >> So my line of thinking is: folks have limited time to contribute, so >> spending that limited resource on static site generation of data is a >>bit >> contradictory. > > >Don't we already generate HTML from asdocs? What more do you think we >need >to do on this. Other than maintenance? How often did the code for >building HTML ASDocs for the Flex project change? >
Currently, we use the flex-sdk's MXMLC to generate the HTML. No third-party can take the FlexJS SDK, build a custom library and generate the ASDocs for it without also getting the regular Flex SDK. I have already written enough code in Falcon and FlexJS to produce this ASDoc app. Next step would be DITA files to do ASDoc in code hinting for FB and FDT and maybe other IDEs. Last is a way to convert DITA to HTML via XSLT. Which I don't know how to do. For me, it would be faster to modify the ASDoc app to generate the HTML. Then more folks could modify it since more folks know AS. IMO, it doesn't matter how often the regular Flex ASDoc changed. I think we need a more sophisticated ASDoc for FlexJS because we have lots more classes that only can be used in certain contexts. Better filtering is needed. That smells like a RIA to me. Sure you can put a pile of HTML somewhere, but it won't be nearly as usable as a RIA with filtering. >> >> Sort of. This is a totally new idea to me, so I haven't spent too much >> time thinking about it, but last night I had the idea of using AIR. >>Maybe >> we can build an AIR app that loads the output from FlexJS, and basically >> crawls it, but saves out the DOM tree as HTML. Of course, I could just >>be >> dreaming... >> > >You described the easy part. IMO the harder questions are: > >1. How do we serve the HTML to search engines? >2. Do we generate it on someone's local machine and upload to a >webserver? Or do we do it as a cron job on some server? >3. If it is a cron job, we need to do it on a windows machine (much like >our Mustella server) In that case, how often do we generate the HTML >files? What about the CPU, bandwidth utilizations? >4. Or do we run a parallel server that loads the content on demand (like >phantom.js) >5. Is our solution going to be turnkey? i.e. can a user reuse our >solution to their web application? Would that mean forcing AIR on them? >That would be a hard sell, especially since it cannot be run on a >non-Windows server. >6. Very few people use Windows servers to serve web content. Most of >them >are variations of Linux. There is no way any AIR app can run reliably on >a >given variation of Linux. No servers needed. We have a tool chain. You write code, then run a set of tools on it. Most of our developers are using Windows or Mac for development already. AIR runs there as well. So a tool runs post-compile that generates HTML. You decide in your build script how often to run it. The result is a pile of HTML to deploy with your app. You would serve it maybe via the port redirect discussed in the Angular SEO article. The solution might be pretty close to turnkey. I think it would be enabled by adding beads. Those beads could include hints to the HTML export tool. > >Thinking more about this problem if anything I would say lets make FlexJS >work seamlessly with phantom.js as others are already using it. This >makes >switching frameworks easier. Just my 2 cents. Sounds good as well. What do we have to do to enable that? -Alex
