On Dec 18, 2016 7:32 AM, "Alex Harui" <[email protected]> wrote:
> > >> 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. Up above you mentioned that IDEs need DITA xml. So we definitely need this part, right? Last is a way to convert DITA to HTML via XSLT. Which I don't know how to do. This is the part that Chris, Justin and I can help with. In fact, there are enough tooling out there to make this easier. You won't have to do much here. 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. You are welcome to do this. As long as we don't stop generating the DITA xml to favor this approach. 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. My point was more about not requiring a lot of upkeep or maintenence. >> >> 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. Not so straightforward. I want my SEO to keep working long after I finish development on my machine. Also, the data can be changing every hour or every minute. As a developer, I can't afford to run these kind of cron jobs on my machine. This is exactly why solutions like Jenkins and Phantom.js etc were created. 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? I don't think we have to do much. As long as we are not compiling code in runtime and are just serving up html and js, phantom.js can handle it. The tricky part is the setup and maintenance of the server itself. Best would be to have a jenkins job spin up a phantom.js server and we load the flexjs app and ensure that all pages are loaded and the resultant html saved somewhere. We could also just throw up the flexjs app on a public site and see how well Google is able to index it. And then fine tune it from there. Thanks, Om -Alex
