Load TemplateConverter in Javascript

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Load TemplateConverter in Javascript

ggrossetie
Hi,

I'm currently trying to load the Reveal.js backend[1] into the Chrome Extension.
There are many challenges (to say the least) and I don't know if a rewrite in Ruby (like the Html5Converter) is not a better option ?

What do you think ?

[1] https://github.com/asciidoctor/asciidoctor-reveal.js
Ted
Reply | Threaded
Open this post in threaded view
|

Re: Load TemplateConverter in Javascript

Ted
I don't know about the technical hurdles but what a brilliant idea!!!

So you're thinking you would just open an AsciiDoc file and it would convert that into a reveal.js slide show? That would be so cool.
- Ted @TedAtCIS
Reply | Threaded
Open this post in threaded view
|

Re: Load TemplateConverter in Javascript

mojavelinux
Administrator
In reply to this post by ggrossetie
I think the best option here is to create a template converter in JavaScript that uses Jade or Slim.js to handle the templates. The problem with cross-compilation of the TemplateConverter is that it uses file system scanning to find templates, which I don't think is going to work in the browser.

I suppose there are two paths forward:

1. Create a native TemplateConverter and try to reuse as many templates as possible using Jade or Slim.js
2. Add an option to the TemplateConverter to pass an explicit map of template files to load so we can skip the file scanning stuff

We were discussing #1 in the following issue: https://github.com/asciidoctor/asciidoctor.js/issues/108

I do think we should stick with templates rather than writing the converter in Ruby. However, if we get stuck, we always have that option.

Cheers,

-Dan

On Mon, Jun 1, 2015 at 6:38 AM, ggrossetie [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Hi,

I'm currently trying to load the Reveal.js backend[1] into the Chrome Extension.
There are many challenges (to say the least) and I don't know if a rewrite in Ruby (like the Html5Converter) is not a better option ?

What do you think ?

[1] https://github.com/asciidoctor/asciidoctor-reveal.js


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Load-TemplateConverter-in-Javascript-tp3291.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



--
Reply | Threaded
Open this post in threaded view
|

Re: Load TemplateConverter in Javascript

ggrossetie
ted wrote
So you're thinking you would just open an AsciiDoc file and it would convert that into a reveal.js slide show? That would be so cool.
Yes that's the plan !

mojavelinux wrote
I think the best option here is to create a template converter in
JavaScript that uses Jade or Slim.js to handle the templates. The problem
with cross-compilation of the TemplateConverter is that it uses file system
scanning to find templates, which I don't think is going to work in the
browser.

I suppose there are two paths forward:

1. Create a native TemplateConverter and try to reuse as many templates as
possible using Jade or Slim.js
2. Add an option to the TemplateConverter to pass an explicit map of
template files to load so we can skip the file scanning stuff

We were discussing #1 in the following issue:
https://github.com/asciidoctor/asciidoctor.js/issues/108

I do think we should stick with templates rather than writing the converter
in Ruby. However, if we get stuck, we always have that option.
Ok, I don't think that #2 is an option because TemplateConverter is too specific.

One of the issue with #1 is that writing a class in JavaScript with Opal is not an easy task (the syntax is terrible!). Plus we can have issue to override the TemplateConverter with the native version.
So I was thinking maybe I can the structure of the class in Ruby in opal_ext and then implement the method in JavaScript ?
Reply | Threaded
Open this post in threaded view
|

Re: Load TemplateConverter in Javascript

mojavelinux
Administrator
In order to get the reveal.js converter working in JavaScript sooner, rather than later, I'm reconsidering my recommendation about how to get there. Perhaps doing a pure Ruby converter is a better option (at the cost of duplicating the effort).

There's no question that to get the template converter working in JavaScript we'll need changes to core. We have to work from both sides.

When I suggested “native JavaScript”, what I meant was that it would be rewritten with JavaScript in mind but still cross-compiled from Ruby using Opal. But it probably should live in opal_ext. The idea of opal_ext is more of a TODO list for what to fix in Opal so that we don't need any changes to get core compiling to JavaScript. Add-ons / extras for the Asciidoctor.js should really live in asciidoctor.js itself. (There's even a question about whether file.rb should live in asciidoctor.js).

Perhaps we can move forward on two fronts. The first is...can we get any any template converter working in Asciidoctor.js, cross-compiled from Ruby. The second is...write reveal.js in pure Ruby if the first front is taking too long.

Cheers,

-Dan

On Sat, Jun 6, 2015 at 3:08 AM, ggrossetie [via Asciidoctor :: Discussion] <[hidden email]> wrote:
ted wrote
So you're thinking you would just open an AsciiDoc file and it would convert that into a reveal.js slide show? That would be so cool.
Yes that's the plan !

mojavelinux wrote
I think the best option here is to create a template converter in
JavaScript that uses Jade or Slim.js to handle the templates. The problem
with cross-compilation of the TemplateConverter is that it uses file system
scanning to find templates, which I don't think is going to work in the
browser.

I suppose there are two paths forward:

1. Create a native TemplateConverter and try to reuse as many templates as
possible using Jade or Slim.js
2. Add an option to the TemplateConverter to pass an explicit map of
template files to load so we can skip the file scanning stuff

We were discussing #1 in the following issue:
https://github.com/asciidoctor/asciidoctor.js/issues/108

I do think we should stick with templates rather than writing the converter
in Ruby. However, if we get stuck, we always have that option.
Ok, I don't think that #2 is an option because TemplateConverter is too specific.

One of the issue with #1 is that writing a class in JavaScript with Opal is not an easy task (the syntax is terrible!). Plus we can have issue to override the TemplateConverter with the native version.
So I was thinking maybe I can the structure of the class in Ruby in opal_ext and then implement the method in JavaScript ?


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Load-TemplateConverter-in-Javascript-tp3291p3322.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



--
Reply | Threaded
Open this post in threaded view
|

Re: Load TemplateConverter in Javascript

ggrossetie
mojavelinux wrote
But it probably should live in opal_ext. The idea of opal_ext is more of a TODO list for what to fix in Opal so that we don't need any changes to get core compiling to JavaScript. Add-ons / extras for the Asciidoctor.js should really live in asciidoctor.js itself.
You mean "But it probably should NOT live in opal_ext" ?

mojavelinux wrote
Perhaps we can move forward on two fronts. The first is...can we get any any template converter working in Asciidoctor.js, cross-compiled from Ruby. The second is...write reveal.js in pure Ruby if the first front is taking too long.
Ok I will see what I can do with the first option.

Thanks for your recommendation :)
Reply | Threaded
Open this post in threaded view
|

Re: Load TemplateConverter in Javascript

mojavelinux
Administrator
On Tue, Jun 9, 2015 at 11:21 AM, ggrossetie [via Asciidoctor :: Discussion] <[hidden email]> wrote:
mojavelinux wrote
But it probably should live in opal_ext. The idea of opal_ext is more of a TODO list for what to fix in Opal so that we don't need any changes to get core compiling to JavaScript. Add-ons / extras for the Asciidoctor.js should really live in asciidoctor.js itself.
You mean "But it probably should NOT live in opal_ext" ?

Doh! My fingers and brain were not agreeing. Correct, I think it should live in the Asciidoctor.js repo. 

mojavelinux wrote
Perhaps we can move forward on two fronts. The first is...can we get any any template converter working in Asciidoctor.js, cross-compiled from Ruby. The second is...write reveal.js in pure Ruby if the first front is taking too long.
Ok I will see what I can do with the first option.

I'm very interested to see how it that plays out because it's going to tell us a lot about how viable programming for Asciidoctor.js is. Thanks for looking into this!

I'm also curious about slim.js. If that works out, that's really going to help with code reuse.

Cheers, 

-Dan 



--
Reply | Threaded
Open this post in threaded view
|

Re: Load TemplateConverter in Javascript

ggrossetie
I made some progress here: https://github.com/mogztter/slm-browser

Slm is working fine in Node and in the browser BUT the syntax is not compatible with Reveal.js Slim templates, so basically we have to edit every single files.
I don't know really well the Slim or Slm syntax but the following are not working:

 * "@" is an invalid token
 * Conditional blocks need to be rewritten in Javascript (for example: "(has_role? 'aside')" or "title? title"...)
 * I don't see how the following will work inside a template "=Asciidoctor::HTML5::DocumentTemplate.outline(@document, toc_levels)"

I doubt that the effort required to adapt/rewrite all the Reveal.js templates are worth it because even if the syntax is close it will be hard to maintain both.
Also loading files (templates) from the disk is something we want to avoid to easily "port" a converter to another platform (load a file in Node, Ruby, Java or in the browser can vary significantly).
Another issue is that if we want to load 20+ templates in the browser we will have to use 20+ blocking XHttpRequest. I guess that this will be rather slow ?

In short, the Reveal.js Ruby converter looks like paradise in comparison with nothing to worry about ! We "just" have to cross-compile it with Opal and we're done :)

Reply | Threaded
Open this post in threaded view
|

Re: Load TemplateConverter in Javascript

mojavelinux
Administrator

On Sat, Jun 27, 2015 at 3:54 AM, ggrossetie [via Asciidoctor :: Discussion] <[hidden email]> wrote:
In short, the Reveal.js Ruby converter looks like paradise in comparison with nothing to worry about ! We "just" have to cross-compile it with Opal and we're done :)

It seems like we found the justification for which we were seeking :)

Sometimes, we have to look at what the research is trying to tell us and just say "now we understand".

It's very odd that the Slim port isn't actually a port :/ We can fix some of this issues (such as dropping the @), but you are right that we might get stuck playing whack-a-mole instead of getting anywhere. (To get a more accurate implementation of the template engine, we could just try to transpile Slim itself).

I still think that the templates can be eventually useful, but we need to chip away at it while making progress on other fronts. 

One idea for saving requests is to group the templates together and then split them apart inside the JavaScript. To avoid any XHR, we could wrap the templates in a String and add them to the page using the script tag. So there are some options there.

I'd say proceed with the Ruby-based implementation (the reveal.js backend needs grooming anyway, so it's a good chance to rethink it a bit where needed). In a background thread, let's start to see if we can get Slim to transpile with Opal. I was able to get it to transpile by putting an empty escape_utils.rb and temple/templates/tilt.rb on the load path. But I'm not sure yet if it runs.

Cheers,