TiltJ (or jTilt)

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

TiltJ (or jTilt)

mojavelinux
Administrator
Among the most valuable assets in the Ruby ecosystem are the numerous template and preprocessor language implementations. This list includes Haml and Slim for creating HTML and XML documents, Sass for creating CSS, ERB and Liquid for arbitrary output and, of course, lightweight markup languages like AsciiDoc and Markdown.

A common entry point into this world is provided by Tilt [1]. While AsciidoctorJ already uses Tilt under the covers, I think adding a top-level Java API for it would open up a world of possibilities to Java applications like jBake. With a single interface, you could allow use of any Ruby template or preprocessor language to be used from Java, eliminating the need to create an API and package for each one.

The API would be very simple. Something like:

[source,java]
--
public interface Template {
  String render();
  String render(Object scope, Map<String,Object> locals);
}

public interface Tilt {
  Template get(String path);
  Template get(String path, Map<String,String> options);
  Template get(String path, int line, Map<String,String> options);
}

Tilt tilt = Tilt.instance();
tilt.get('index.haml').render();
--

I predict that a TiltJ (or jTilt) library will become immensely popular, considering tilt is about to exceed 20 million downloads! [1] The first place I'd like to see it used is jBake*.

-Dan

[1] http://rubygems.org/gems/tilt

* I can't go back to Velocity or Freemarker after using Slim and Haml :) No way.
Reply | Threaded
Open this post in threaded view
|

Re: TiltJ (or jTilt)

asotobu
Are you thinking doing something like Asciidoctor-Java-Integration but for Tilt (calling Gems from Java) or creating a native solution written 100% in Java? If it is the first case, count with me :D.

Alex.
Reply | Threaded
Open this post in threaded view
|

Re: TiltJ (or jTilt)

asotobu
If it is the second option I can also help, but meanwhile the first option is relatively fast so I can find a space on my time, the second one would require lot of work and I find difficult I can be involved at 100%.

Alex
Reply | Threaded
Open this post in threaded view
|

Re: TiltJ (or jTilt)

mojavelinux
Administrator
I was definitely thinking about the first option, similar to the Asciidoctor integration. As you mentioned, it's a relatively quick win, it opens up possibilities for extension writers, it will give jBake a nice boost and, to top it off, it provides another good example to demonstrate the Java to Ruby bridge.

It's your call whether you want to make it part of the AsciidoctorJ jar or whether you want to create a separate jTilt jar. The key, of course, will be to have a way to use the same Ruby runtime if you are using both APIs in your application (like jBake).

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

Re: TiltJ (or jTilt)

asotobu
Cool, first of all I am going to start studying Tilt API and then start coding the integration. I would like to avoid using the same project as AsciidoctotJ because don't let users use TiltJ without AsciidoctorJ as dependency, so I am going to start thinking on alternatives to share same JRuby runtime. I will keep you informed through this post :) 
So here we go!!!

El dijous 24 d’octubre de 2013, mojavelinux [via Asciidoctor :: Discussion] ha escrit:
I was definitely thinking about the first option, similar to the Asciidoctor integration. As you mentioned, it's a relatively quick win, it opens up possibilities for extension writers, it will give jBake a nice boost and, to top it off, it provides another good example to demonstrate the Java to Ruby bridge.

It's your call whether you want to make it part of the AsciidoctorJ jar or whether you want to create a separate jTilt jar. The key, of course, will be to have a way to use the same Ruby runtime if you are using both APIs in your application (like jBake).

-Dan


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/TiltJ-or-jTilt-tp845p858.html
To unsubscribe from TiltJ (or jTilt), click here.
NAML


--
Enviat amb Gmail Mobile
Reply | Threaded
Open this post in threaded view
|

Re: TiltJ (or jTilt)

LightGuardjp
Administrator
Start looking at the Tilt 2.0 api. I think we'll get more for our money by using Tilt 2.0. Unless it's not close, but I believe they are.


On Wed, Oct 23, 2013 at 11:32 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Cool, first of all I am going to start studying Tilt API and then start coding the integration. I would like to avoid using the same project as AsciidoctotJ because don't let users use TiltJ without AsciidoctorJ as dependency, so I am going to start thinking on alternatives to share same JRuby runtime. I will keep you informed through this post :) 
So here we go!!!

El dijous 24 d’octubre de 2013, mojavelinux [via Asciidoctor :: Discussion] ha escrit:
I was definitely thinking about the first option, similar to the Asciidoctor integration. As you mentioned, it's a relatively quick win, it opens up possibilities for extension writers, it will give jBake a nice boost and, to top it off, it provides another good example to demonstrate the Java to Ruby bridge.

It's your call whether you want to make it part of the AsciidoctorJ jar or whether you want to create a separate jTilt jar. The key, of course, will be to have a way to use the same Ruby runtime if you are using both APIs in your application (like jBake).

-Dan


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/TiltJ-or-jTilt-tp845p858.html
To unsubscribe from TiltJ (or jTilt), click here.
NAML


--
Enviat amb Gmail Mobile



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/TiltJ-or-jTilt-tp845p860.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: TiltJ (or jTilt)

asotobu
Thank Jason for your advice, much appreciate it :) I will try to start this weekend.

Alex
Reply | Threaded
Open this post in threaded view
|

Re: TiltJ (or jTilt)

mojavelinux
Administrator
In reply to this post by LightGuardjp

+1 for Tilt 2.0.

Reply | Threaded
Open this post in threaded view
|

Re: TiltJ (or jTilt)

jonbullock
In reply to this post by asotobu
Happy to offer my help as supporting more template options is something I've wanted to add to JBake and this sounds like a great way to do it.
Reply | Threaded
Open this post in threaded view
|

Re: TiltJ (or jTilt)

asotobu
This weekend I will start looking Tilt 2.0 and then start the project of TiltJ, I will keep you informed about public interface so you can start to see if the interface is enough for you or you need something more.

Alex.


2013/10/25 jonbullock [via Asciidoctor :: Discussion] <[hidden email]>
Happy to offer my help as supporting more template options is something I've wanted to add to JBake and this sounds like a great way to do it.


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/TiltJ-or-jTilt-tp845p878.html
To unsubscribe from TiltJ (or jTilt), click here.
NAML



--
+----------------------------------------------------------+
  Alex Soto Bueno - Computer Engineer
  www.lordofthejars.com
+----------------------------------------------------------+
Reply | Threaded
Open this post in threaded view
|

Re: TiltJ (or jTilt)

asotobu
I have been reading documentation of Tilt 2.0 this weekend, and I have one question:

For each supported template we must do two things, the first one is load it inside Ruby with require keyword, and this is not a problem because I am going to implement a similar strategy of Asciidoctor, that is that depending on the extension we are going to preload the library, only and only if is has not been previously preloaded.

But I see a problem and is that for each template one or more gems are required. And here there are two options, the first one is like Asciidoctor and embed all of them inside the jar, which I think it is not the best solution because the jar will grow and at the end maybe users will only use one or two templates in their applications. The second approach, which is differs from Asciidoctor is using gemjars which let you add gems as external jars dependencies, so it will be the end user who is responsible of adding the gems (jars) inside classpath. I think that this second approach for TiltJ is the best one.

WDYT?

Alex.