Introducing YOKE a middleware framework for Vert.x

[Paulo Lopes]

Yoke

Yoke is a project that I've been working on for the last couple of weeks.

The purpose of Yoke is to provide a easy way to build web applications or web frameworks on top of Vert.x with a simple API.

Yoke has no external dependencies, however it is meant to be extended.

Yoke is a chain executor framework for Vert.x, it was modeled after Connect (see http://www.senchalabs.org/connect/) and right now is bundled with 12 middleware components and if you are interested you can write 3rd party middlewares to be added to the project.

Usage

The usage at the moment is Java only and I am planning to create bindings for other languages that run on Vert.x.

import com.jetdrone.vertx.yoke.middleware.*;

import org.vertx.java.core.Handler;

import org.vertx.java.core.http.HttpServerRequest;

import org.vertx.java.platform.Verticle;

public class Tester extends Verticle {

    @Override

    public void start() {

        Yoke yoke = new Yoke(vertx);

        yoke.use(new Static("public"));

        yoke.use(new Router() {{

            all("/hello", new Handler<HttpServerRequest>() {

                @Override

                public void handle(HttpServerRequest request) {

                    request.response().end("Hello World!");

                }

            });

        }});

        yoke.listen(3000);

    }

}

The API is quite simple, you start a chain (Yoke) with the Vertx instance. This Vertx instance is the shared by all middleware (Yoke will make sure of this) you you don't need to pass it to all middleware constructors.

Then you chain Middleware with the method use(), in this case I chain the static file server and a the custom router middleware (which works in a similar way to the RouteMatcher).

When running this verticle all requests will first try to find a matching file on the file system under the "public" directory if that fails the router will try to match the request path to "/hello" and run that handler, if that fails and error is raised.

Installation

Just pull the jar to your module lib. I am in the process of uploading the artifact to maven central.

Bundled Middleware

• BasicAuth - basic http authentication
• BodyParser - extensible request body parser, internally it will parse the request body and populate the field body on the HttpServerRequest object with either:
• JsonObject if content-type was application/json
• Map<String, Object> if content-type was application/x-www-form-urlencoded
• Map<String, Object> plus field files (Map<String, UploadFile>) if content-type was multipart/form-data
• CookieParser - populates the field cookies on the request and verifies if they are signed
• ErrorHandler - Pretty error messages either in html/json/text
• Favicon - generate a proper favicon.ico for your app
• Limit - Limit the request body to a specific amount of bytes
• MethodOverride - faux HTTP method support
• ResponseTime - calculates response-time and exposes via X-Response-Time
• Router - Route Matcher like Vertx one but allows also responses to be chainable
• Static - static file server (with proper caching headers) and optional directory listing
• Timeout - request timeouts do not allow long running requests
• Vhosts - virtual host sub-domain mapping middleware

Links

• github - https://github.com/pmlopes/yoke
• lib - http://pmlopes.github.io/yoke

[spriet2000]

Nice implementation of the connect like api!

[Paulo Lopes]

Yes that was my main goal. I am still creating the documentation site, it will take some time.

For now I am stabilizing the API. I have it reduced to 4 classes:

• Yoke - The main class
  
• Middleware - abstract class that all middleware extends
• Engine - abstract class for template engines
• MimeType - mime type identifier

After that I have 2 extra helper classes:

• YokeHttpServerRequest - implements the HttpServerRequest and extends Map<String, Object> so we can add properties to the request like on node.js plus some helper accessors to cookies, uploaded files etc...
• YokeHttpServerResponse - implements HttpServerResponse and adds methods for the rendering engines to allow response.render(template_file)

[Tim Fox]

Nice.

Is this Java only? Any plans to support other langs?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Paulo Lopes]

I plan to support other languages too. I will implement a groovy extension using closures to make it more productive to groovy developers but unfortunately I've no experience with writing bindings for other languages such as jython, jruby and javascript. If someone can share some help it would be appreciated.

But this project is done on my spare time, so i cannot promise any time-frame for this.

The planning now is to complete the API site which is has lots of incomplete links, and then start with the groovy bindings.

[Daryl Teo]

Nice work.

I've been working on mine for a long time but unfortunately work has kept me occupied :(

No point doubling effort. I do not believe I can continue working on mine in the long term so will possibly contribute to yours.

Daryl

[Sebastien Blanc]

Speaking about reinventing the wheel ... I'm also working on a Web Framework, based on the Rails and Grails concepts, for now based based on Groovy with a lot of configuration over Configuration, Keep it simple and don't repeat yourself : KISS DRY COC

Hope to publish a first version into 2 weeks ...

Seb

[froz3n]

Nice work Paulo!

I did not know "Connect" but does seem to have a nice API. Will definitely git it a try.

Is this for 1.3 or 2.0? Or supporting both?

[Paulo Lopes]

Hi Daryl,

Indeed I tried to check your github project but all I saw as a Promisses library. As I stated, my goal is not to build a full web framework but a modular component library to easy the build of such a project.

The reason behind this, is that in my opinion building a full web framework is a complex task for just one person, there are just to many things to implement. So I decided to use the old approach of divide and conquer, by first creating a chain executor (Yoke) and the implement common tasks, e.g.: server static files, generate error pages, parse request bodies, parse cookies, handle file uploads, serve favicons, delegate to other server if the host header matches a regular expression, timeout a request if it takes too long...

Although these are tasks that a web framework should have, there are tons of others missing (this is where you could help :))

I've a interface for rendering engines, but no rendering engine, say you want to generate JSPs then you register the JSP engine with Yoke and in your response object you can call request.response().render("path to jsp file"), maybe JSP is crap, maybe something like jade? or mustache, or whatever...

As you can imagine there is lots of things that can be done, here are some more examples:

• session management
  
• response compression
• logging (say something like apache logs....)
• Cross Site Request Forgery security
• OAuth implementation...

My goal is to have as many middleware as possible but each one of them as simple as possible.

Once there is a decent amount of middleware it is possible to make a selection and tag it as a basic web framework, in the same way expressjs is a webframework on top of connect.

[Paulo Lopes]

At the moment it is Vert.x 2.x only because of the API changes but i think it could be backported to 1.3x series without much of an hassle.

I am planning to support 2.x for now since I only work on it on my free time, If there is a need I can port it to the 1.3.

Cheers,

Paulo

[Finn Bock]

It look very nice.

I tried it and found a small problem on windows where the code
   Favicon.class.getResource("favicon.ico").getPath()
does not return an actual filesystem path but instead a value like.

/D:/vertx/test-yoke/mods/com.jetdrone~yoke~1.0.0-SNAPSHOT/com/jetdrone/vertx/yoke/middleware/favicon.ico

where the initial "/" char means the path can not by opened with the fileSystem() classes.

[Paulo Lopes]

Thanks for noting that, i've created a issue on github and will look into it.

[Paulo Lopes]

Hi everyone,

In the latest git push I added an example of a CMS application build with Yoke.

https://github.com/pmlopes/yoke/tree/master/example/kitcms

The example is based on kitcms (http://kitcms.com/). In fact the admin panel is a shame copy paste from that project, however the server backend is done with Yoke and Vert.x and as you can see you can have a CMS backed by Redis written in less than 500 lines of code (including a template engine for Mustache, Config handling and Redis communication).

The core code lives in the file:

https://github.com/pmlopes/yoke/blob/master/example/kitcms/src/main/java/com/jetdrone/vertx/kitcms/KitCMS.java

And is less than 250 lines.

Also, I've introduced some initial support for Groovy but this hasn't been tested at all yet.

Feel free to comment and report issues on github:

https://github.com/pmlopes/yoke

Thanks!

[Bastian]

Hey Paulo, very nice work.

Seems as if there are several people working on a Connect like framework for vertx - including me. But as Daryl says there is no point doubling efforts, so I'll see what I can contribute to Yoke.

On Tuesday, April 23, 2013 11:44:10 AM UTC+2, Paulo Lopes wrote:

[Paulo Lopes]

All contributions are welcome :)

I've put the code available on github and clarified the license as Apache Software License 2.0 (like Vert.x).

Cheers,

Paulo

[Paulo Lopes]

Some very basic support for Groovy is included now with one example:

https://github.com/pmlopes/yoke/tree/master/example/groovy

So basically it uses the groovy lang module and Closures instead of Handlers:

import com.jetdrone.vertx.yoke.*
import com.jetdrone.vertx.yoke.middleware.*

def yoke = new GYoke(vertx)

yoke.use(new ErrorHandler(true))

yoke.use() { request, next ->
    if (request.path() == '/hello') {
        request.response().end('Hi there!')
    } else {
        next.handle('You did not say hello! go to /hello')
    }
}

yoke.listen(8080)

closures can have one or 2 parameters, the first one is the request object and the second the handler for the next in chain middleware.

[Tim Yates]

Just from an ideomatic groovy POV, it might be better if instead of path() and response() you supply getPath and getResponse methods, then you can write:

import com.jetdrone.vertx.yoke.*
import com.jetdrone.vertx.yoke.middleware.*


def yoke = new GYoke(vertx)


yoke.use( new ErrorHandler(true) )

yoke.use { request, next ->

    if (request.path == '/hello') {

        request.response.end( 'Hi there!' )

[Tim Yates]

Ahhh...just looked a the code, and I see you do this already...

Ignore me ;-)

[Tim Fox]

Great! I think it would be great to have good Groovy support.

Btw, have you seen https://github.com/ratpack/ratpack ?

[Paulo Lopes]

I didn't know about ratpack.

Well it looks like the API is somehow close.

I am not planning to build something like ratpack, however if someone invests some time building say:

• render engines
• session middleware
• more stuff missing...

The current middleware list can do most of the tasks ratpack can.

One feature that RatPack has is template engine, to demonstrate how Yoke can be extended in that area, I implemented a simple render engine that does property placeholder replacement.

Given the template: "Hello ${name}!" and a map {name: "world"} it renders to "Hello world!"

It is even smart to do interpolation such as: "Hello ${na${me}}!" and {name: "world", me: "me"} it renders "Hello world!"

The render engine is also used in the example application (KitCMS) for everyone interested in knowing how to use it.

About groovy support i cannot guarantee that it is good enough since I do not have much experience with the language, I created the basic bindings but if there is someone with better knowledge of the language, feel free to refactor the whole thing :)

[Bruno Santos]

Talking about templates, it would be a nicety to have a template engine similar to what Play2 has, either as a vertx module or as part of yoke (or any other vertx based midware).

http://www.playframework.com/documentation/2.0/ScalaTemplates

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/2DrXx-E8Zso/unsubscribe?hl=en-GB.
To unsubscribe from this group and all of its topics, send an email to vertx+un...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Bruno Santos
mailto:bmros...@gmail.com
 
"Treat people as they ought to be, and you will help them
become what they are capable of being." - Goethe

[Paulo Lopes]

So I've been working on the groovy side of Yoke, it now has proper dot notation for accessing fields and a TEMPLATE ENGINE!!! :)

So the new example is like this:

import com.jetdrone.vertx.yoke.middleware.*
import com.jetdrone.vertx.yoke.GYoke
import com.jetdrone.vertx.yoke.engine.GroovyTemplateEngine

def yoke = new GYoke(vertx)

yoke.engine('html', new GroovyTemplateEngine())

yoke.chain(new ErrorHandler(true))

yoke.chain {request ->
    request.put('session', [id: '1'])
    request.response.render 'template.html'
}

yoke.listen(8080)

Note that instead of "use" the method is called "chain". Why? because for some reason my Groovy classes get some static method called use, which is kind of annoying but unless someone knows how to override those the api signature will be different.

The closure can have 1 or 2 arguments, one as illustrated above, two when there is a next if you want to chain to the next middleware.

You can add any property to the request with the method put(String, Object) this is the context for your render engine. If you are on Groovy I've created a render engine based on the Groovy template engine API. Here is the template the example is calling:

<!DOCTYPE html>
<html>
<body>
  <% 3.times { %>
    Hello World!
  <% } %>
  <br>
  <% if (session != null) { %>
    My session id is ${session.id}
  <% } else println "No session created." %>
</body>
</html>

And Tada there you go! :)

[Paulo Lopes]

Another feature for Groovy that i did not mentioned was, that you can now define routes with closure syntax instead of handlers:

import com.jetdrone.vertx.yoke.middleware.*
import com.jetdrone.vertx.yoke.GYoke
import com.jetdrone.vertx.yoke.engine.GroovyTemplateEngine

def yoke = new GYoke(vertx)

yoke.engine('html', new GroovyTemplateEngine())

yoke.chain(new ErrorHandler(true))

yoke.chain(new GRouter() {{
    get("/hello") { request ->
        request.response.end "Hello World!"
    }
    get("/template") { request ->

        request.put('session', [id: '1'])
        request.response.render 'template.html'
    }

}})

yoke.chain {request ->
    request.response.end "maybe you should go to /hello or /template!"
}

yoke.listen(8080)

The first argument can also be a regular expression!!!

[Pid]

On 25/04/2013 17:34, Bruno Santos wrote:
> Talking about templates, it would be a nicety to have a template engine
> similar to what Play2 has, either as a vertx module or as part of yoke
> (or any other vertx based midware).
> http://www.playframework.com/documentation/2.0/ScalaTemplates

As another option for 2.0 I've put together a Thymeleaf based template
engine:

https://github.com/swilliams-vmw/mod-thymeleaf

Module name (currently in OSS Sonatype Maven Snapshot repo):

io.vertx~mod-thymeleaf~1.0.0-SNAPSHOT


p

> On Thu, Apr 25, 2013 at 10:54 AM, Paulo Lopes <pml...@gmail.com
> <mailto:pml...@gmail.com>> wrote:
>
> I didn't know about ratpack.
>
> Well it looks like the API is somehow close.
>
> I am not planning to build something like ratpack, however if
> someone invests some time building say:
>

> * render engines
> * session middleware
> * more stuff missing...

>
> The current middleware list can do most of the tasks ratpack can.
>
> One feature that RatPack has is template engine, to demonstrate how
> Yoke can be extended in that area, I implemented a simple render
> engine that does property placeholder replacement.
>

> Given the template: /"Hello ${name}!"/ and a map /{name: "world"}/
> it renders to /"Hello world!"/
>
> It is even smart to do interpolation such as: /"Hello ${na${me}}!"/
> and /{name: "world", me: "me"}/ it renders /"Hello world!"/

>
> The render engine is also used in the example application (KitCMS)
> for everyone interested in knowing how to use it.
>
> About groovy support i cannot guarantee that it is good enough since
> I do not have much experience with the language, I created the basic
> bindings but if there is someone with better knowledge of the
> language, feel free to refactor the whole thing :)
>
> On Thursday, April 25, 2013 11:50:37 AM UTC+2, Tim Fox wrote:
>
> Great! I think it would be great to have good Groovy support.
>

> Btw, have you seen https://github.com/ratpack/__ratpack

> <https://github.com/ratpack/ratpack> ?
>
> On 25/04/13 10:42, Paulo Lopes wrote:
>> Some very basic support for Groovy is included now with one
>> example:

>> https://github.com/pmlopes/__yoke/tree/master/example/__groovy

>> <https://github.com/pmlopes/yoke/tree/master/example/groovy>
>>
>> So basically it uses the groovy lang module and Closures
>> instead of Handlers:
>>
>> import com.jetdrone.vertx.yoke.*
>>

>> import com.jetdrone.vertx.yoke.__middleware.*

>> def yoke = new GYoke(vertx)
>>
>> yoke.use(new ErrorHandler(true))
>>
>> yoke.use() { request, next ->
>>
>> if (request.path() == '/hello') {
>>

>> request.response().end__('Hi there!')

>> Favicon.class.getResource("__favicon.ico").getPath()

>>
>> does not return an actual filesystem path but
>> instead a value like.
>>

>> /D:/vertx/test-yoke/mods/com.__jetdrone~yoke~1.0.0-SNAPSHOT/__com/jetdrone/vertx/yoke/__middleware/favicon.ico

>>
>> where the initial "/" char means the path can
>> not by opened with the fileSystem() classes.
>>
>>
>>
>>
>>
>> Den fredag den 19. april 2013 11.26.49

>> <tel:2013%2011.26.49> UTC+2 skrev Paulo Lopes:
>>
>> *Yoke*

>>
>> Yoke is a project that I've been working
>> on for the last couple of weeks.
>>
>> The purpose of Yoke is to provide a easy
>> way to build web applications or web
>> frameworks on top of Vert.x with a simple API.
>>
>> Yoke has no external dependencies, however
>> it is meant to be extended.
>>
>> Yoke is a chain executor framework for
>> Vert.x, it was modeled after Connect (see

>> http://www.senchalabs.org/__connect/
>> <http://www.senchalabs.org/connect/>) and

>> right now is bundled with 12 middleware
>> components and if you are interested you
>> can write 3rd party middlewares to be
>> added to the project.
>>

>> *Usage*

>>
>> The usage at the moment is Java only and I
>> am planning to create bindings for other
>> languages that run on Vert.x.
>>

>> import com.jetdrone.vertx.yoke.__middleware.*;
>> import org.vertx.java.core.Handler;
>> import
>> org.vertx.java.core.http.__HttpServerRequest;
>> import org.vertx.java.platform.__Verticle;

>> *Installation*

>>
>> Just pull the jar to your module lib. I am
>> in the process of uploading the artifact
>> to maven central.
>>

>> *Bundled Middleware*
>>
>> * *BasicAuth* - basic http authentication
>> * *BodyParser* - extensible request body

>> parser, internally it will parse the
>> request body and populate the field
>> body on the HttpServerRequest object
>> with either:

>> o *JsonObject* if content-type was
>> application/json
>> o *Map<String, Object>* if
>> content-type was
>> application/x-www-form-__urlencoded
>> o *Map<String, Object>* plus field

>> files (Map<String, UploadFile>) if
>> content-type was multipart/form-data

>> * *CookieParser* - populates the field

>> cookies on the request and verifies if
>> they are signed

>> * *ErrorHandler* - Pretty error messages
>> either in html/json/text
>> * *Favicon* - generate a proper
>> favicon.ico for your app
>> * *Limit* - Limit the request body to a
>> specific amount of bytes
>> * *MethodOverride* - faux HTTP method
>> support
>> * *ResponseTime* - calculates

>> response-time and exposes via
>> X-Response-Time

>> * *Router* - Route Matcher like Vertx

>> one but allows also responses to be
>> chainable

>> * *Static* - static file server (with

>> proper caching headers) and optional
>> directory listing

>> * *Timeout* - request timeouts do not
>> allow long running requests
>> * *Vhosts* - virtual host sub-domain
>> mapping middleware
>>
>>
>> *Links*
>>
>> * github -
>> https://github.com/pmlopes/__yoke
>> <https://github.com/pmlopes/yoke>
>> * lib - http://pmlopes.github.io/yoke

>>
>>
>> --
>> You received this message because you are subscribed to the
>> Google Groups "vert.x" group.
>> To unsubscribe from this group and stop receiving emails from

>> it, send an email to vertx+un...@__googlegroups.com.
>>
>> For more options, visit
>> https://groups.google.com/__groups/opt_out
>> <https://groups.google.com/groups/opt_out>.

>>
>>
>
>
> --
> You received this message because you are subscribed to a topic in
> the Google Groups "vert.x" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/vertx/2DrXx-E8Zso/unsubscribe?hl=en-GB.
> To unsubscribe from this group and all of its topics, send an email
> to vertx+un...@googlegroups.com

> <mailto:vertx%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
>
> --
> Bruno Santos

> mailto:bmros...@gmail.com <mailto:bmros...@gmail.com>

>
> "Treat people as they ought to be, and you will help them
> become what they are capable of being." - Goethe
>

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to vertx+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>


--

[key:62590808]

[Tim Fox]

Nice. The more the merrier :)

>     <mailto:vertx%2Bu...@googlegroups.com>.

[Finn Bock]

Paulo Lopes:

 If you are on Groovy I've created a render engine based on the Groovy template engine API.

I assume the groovy  template engine can be used independent of yoke's groovy support.

In other web template frameworks there is commonly some predefined variables like: request, response, cookies, locale, cookies, session and whaterver else that makes sense for the framework.

It is also common that the template system support calling functions, either system or user defined.

Do you have any plans for defining a common set of variable and functionality that that template engines are expected to support?

regards,
finn

regards,
Finn

[Paulo Lopes]

Yes you could use the groovy template from java since the render api only cares about a map as the context. What i did not do was writing code with jsva handlers but with groovy closures. Adding those is a trivial task that takes a couple of minutes.

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/2DrXx-E8Zso/unsubscribe?hl=en-GB.

To unsubscribe from this group and all of its topics, send an email to vertx+un...@googlegroups.com.

[Paulo Lopes]

New small update:

• Yoke has now a simple Session middleware based on cookies.

As a not so small update there are TESTS :))

• I've created a simple mock for the whole framework so there is no need to create HttpServers all the time.

My next focus will be JavaScript support

To unsubscribe from this group and all of its topics, send an email to vertx+unsubscribe@googlegroups.com.

[bytor99999]

About Templating. It would be nice to have choices. There are so many Templating engines out there and opinions on them. For instance, Thymeleaf has been briought up and it is fantastic, but not everyone wants to use it, or subscribes to how they do their templating. For instance, I like ICanHaz.js built on top of Mustache. Groovy's templating is also just as amazing. So I was just hoping it would end up being a choose whichever templating engine you want.

Thanks

Mark

To unsubscribe from this group and all of its topics, send an email to vertx+un...@googlegroups.com.

[bytor99999]

I was also a little bummed we didn't call this Neil or Alex, since Node.js has Geddy. (Rush humor)

Mark

On Friday, April 19, 2013 2:26:49 AM UTC-7, Paulo Lopes wrote:

Yoke

Yoke is a project that I've been working on for the last couple of weeks.

The purpose of Yoke is to provide a easy way to build web applications or web frameworks on top of Vert.x with a simple API.

Yoke has no external dependencies, however it is meant to be extended.

Yoke is a chain executor framework for Vert.x, it was modeled after Connect (see http://www.senchalabs.org/connect/) and right now is bundled with 12 middleware components and if you are interested you can write 3rd party middlewares to be added to the project.

Usage

The usage at the moment is Java only and I am planning to create bindings for other languages that run on Vert.x.

import com.jetdrone.vertx.yoke.middleware.*;

import org.vertx.java.core.Handler;

import org.vertx.java.core.http.HttpServerRequest;

import org.vertx.java.platform.Verticle;

public class Tester extends Verticle {

    @Override

    public void start() {

        Yoke yoke = new Yoke(vertx);

        yoke.use(new Static("public"));

        yoke.use(new Router() {{

            all("/hello", new Handler<HttpServerRequest>() {

                @Override

                public void handle(HttpServerRequest request) {

                    request.response().end("Hello World!");

                }

            });

        }});

        yoke.listen(3000);

    }

}

The API is quite simple, you start a chain (Yoke) with the Vertx instance. This Vertx instance is the shared by all middleware (Yoke will make sure of this) you you don't need to pass it to all middleware constructors.

Then you chain Middleware with the method use(), in this case I chain the static file server and a the custom router middleware (which works in a similar way to the RouteMatcher).

When running this verticle all requests will first try to find a matching file on the file system under the "public" directory if that fails the router will try to match the request path to "/hello" and run that handler, if that fails and error is raised.

Installation

Just pull the jar to your module lib. I am in the process of uploading the artifact to maven central.

[Paulo Lopes]

On Wednesday, May 1, 2013 5:47:43 PM UTC+2, bytor99999 wrote:

About Templating. It would be nice to have choices. There are so many Templating engines out there and opinions on them. For instance, Thymeleaf has been briought up and it is fantastic, but not everyone wants to use it, or subscribes to how they do their templating. For instance, I like ICanHaz.js built on top of Mustache. Groovy's templating is also just as amazing. So I was just hoping it would end up being a choose whichever templating engine you want.

I've implemented a Groovy Templace interface and a simple Placeholder replacer, I would like someone to provide the other interfaces, as you can imagine i cannot implement all engines:

• Thymeleaf
• ICanHaz
• Mustache
• HandleBars
• etc...

Well i could do that but i am more interested now in getting everything properly tested and supporting Java/Groovy/JavaScript I also would like to have support for other languages:

• Python
• Ruby
• Scala
• Clojure
• ...

However you are more than welcome to provide a Thymeleaf engine, just implement the the class :) you only need to write 2 methods :) it is easy :)
 

[bytor99999]

I wouldn't implement Thymeleaf. I would look at implementing ICanHaz.js

I like my client side templating engines, not server side. ;)

[Paulo Lopes]

Another announcement a very pre pre alpha JavaScript support is in, you can do this:

var Yoke = require('com/jetdrone/vertx/yoke/Yoke');
var Router = require('com/jetdrone/vertx/yoke/middleware/Router');

var yoke = new Yoke();
var router = new Router();

yoke.use(router);
router.get('/hello', function (req) {
    req.response().end('Hello there!');
});
// all other resources are forbidden
yoke.use(function (req, next) {
    next(401);
});

// start server
yoke.listen(8080);

 And more tests have been added fixing a couple of bugs. Still need to implement template support in JS and tests for Groovy and JS