Automated process to render example files on change

[LoveAndCoding]

Would be nice to have an automated process that automatically renders and converts example .mucow files checked in to the example folders. Can use (and possibly be a part of?) the compiler tool.

Easiest way is probably with a webhook that just pings a server to check out the files, render them and push them back up. Really, there isn't reason we can't do that with all of the components between FruitJS and the example compiler.

[clabland]

Agreed. I could set this up internally (and then check into the public repo), but that doesn't seem very transparent/collaborative.

Any ideas?

[JeffryBooher]

I know it's archaic but we could do this with an XSLT seeing as how the mucow is xml based. I've never written one but I think it could be rendered on the client side then any mucow could be rendered in the browser by referencing it and letting the browser transform the mucow using the XSLT to do the code coloring and other stuff. It would also need some client side JS to push it along but we wouldn't need to make it part of the "build" process if we did it that way and it would be somewhat transparent.

[LoveAndCoding]

Actually, the scripts I used for the example tool are all JS tools, so it could be done client side. It might be a little slow depending on the .mucow file, but it's entirely possible. No need for XSLT (which likely wouldn't have support on github pages and may not have access to comments?).

The main issues are speed and portability. We'd need to parse the XML differently. There is native browser support for XML documents, but I think it eats the comments in parsing so I don't think we'd be able to get to those without having our own processor. And the one I use is built pretty heavily in NodeJS (it uses streams which aren't really browser-y) so I don't know if it can be ported over using browserfy.

But a client side solution is certainly an option.

[LoveAndCoding]

Actually, I take that back. It doesn't seem to eat the comment nodes, so it can likely be done through the native XML parser. But, that's only IE 9+. So that would probably have to be a call on your end. Also, it would change the logic there as it would have to parse the hierarchy looking for the comments, rather than doing it through the string. Still, something to consider

[JeffryBooher]

Yeah it looks like chrome is either not supporting XSLT due to security concerns or lack of usage which is something I was afraid of (which is why I said it was an archaic technology to begin with).

@clabland by transparent do you mean that changes made to the mucow samples would need to trigger a build event?

[clabland]

@JeffryBooher yeah that's all I meant. Obviously I could set this up internally, but it'd probably be better to have it here somehow.

[LoveAndCoding]

Well I could host it on Widgets.Mu, but that won't really do much good since I don't have write access to the repo, and it isn't controlled by you guys at all. But my server has NodeJS support and it wouldn't take me long to get up and running.

If we do it client side, we don't have to worry about webhooks and the like, but we might have browser issues or issues with speed on slows clients.

If we do a server side thing, we can do it with webhooks but whatever system does it also has to have access to check-in changes to the repo.

Personally, in terms of simplicity, it might be better to go with a client side rendering. But that's going to be a lot more initial overhead to get up and running because someone is gonna have to code that sucker.

[JeffryBooher]

if we just made it all HTML rather than a mix of HTML GH-MD then we wouldn't need to check anything in. You could use node-markdown to render the GH-MD as HTML (or https://github.com/chjj/marked to do it in browser or without using node, etc...) Then we wouldn't need to checkin anything -- everything is on the server.