Kotlin and Vert.x

21

Sorry, it's still not working. Compiling with mvn I get this exception:

java.lang.UnsupportedClassVersionError: org/vertx/java/core/Vertx : Unsupported major.minor version 51.0

I've imported the pom into Idea, but then I get same error when I run  org.vertx.kotlin.examples#Main. I'm using M2, maybe the problem is due to that thing, but I'm guessing Maven compilation would have downloaded the right kotlin version (M1?)

22

Are you using Java 6? I think Vertx uses Java 7

23

Yes, Java 6. Ok. I'll setup 7 and retry... I really what to trythis project vertex , appears to be easy to use then Netty (which I used in kweb) but still powerful.

And I think we should team-up to concentrate our Kotlin web-framework efforts in a unique direction…

BTW, did you success injecting Kotlin languange in HTML to get autocompletion and error checking in views?

I understand the process is a bit fragile by now, so we thought
to port the sample views to kool.template… maybe I’ll stress you more in near future :stuck_out_tongue:

24

:) Agreed.

vert.x is looking like a great project & framework for the container/platform/runtime/controller stuff.

On the subject of templating; there are many approaches (we explored many of them in scalate BTW). With Kotlin specifically the options as I see them are:

  1. an internal typesafe DSL for Kotlin (e.g. Kool Templates) which can be used on the client in JS or on the server and generates some tree structure (e.g. W3C DOM so its easy to update the DOM in place)
  2. multi-line Strings with $ expressions in regular Kotlin files (once we can use StringTemplates to properly escape HTML and ideally when we can use IDEA Language Injection for Kotlin to perform HTML validation inside the template).
  3. external DSLs which are not valid Kotlin source files and need some compile step/cache/reload & IDEA plugins/configurations to allow decent editing

For (3), external DSLs there are various options. One is the Razor/Play style of template where expressions are embedded using some syntax (e.g. @). Another is things like Jade. Though its a pretty big amount of work doing all the compiler/IDE plugin/cache/reloading stuff - so getting (1) and (2) done first makes life much simpler (IDEA FTW!).

If I understand your approach correctly, you’ve kinda gone for an external DSL which is kinda like (2) and (3) combined. Though if you’re going to go to all the effort of having a separate kind of file thats not a regular Kotlin file, having to wire in IDEA support to be able to edit it & have a compile step and so forth you may as well go the whole hog and do a real external DSL (Razor/Play and Jade are my favourite).

I’m wondering if your approach of a new file format is worth all the effort? e.g. what about just using real Kotlin files (since really if you strip the <html> tags thats what you have). Then we’re using (2) - real kotlin files that IDEA edits and if we can use @Language(“HTML”) on a base trait we can get HTML language injection for free (when KT-2428 is fixed). e.g. this example: https://github.com/parroit/kweb/blob/master/sites/welcome/src/main/resources/views/layout.html.kt could be implemented something like this - not needing an external DSL at all & having immediate IDEA/maven/ant. support…

package templates


import kw.views.*




import sites.welcome.*







class MyTemplate(val someParams: Foo) : HtmlTemplate {


  fun html() = """<html>


...


${someParams.something}


...


</html>


"""


}


 


//then elsewhere we have this base trait to enable the language injection


 


trait HtmlTemplate {


  /** Generates the HTML output for this template */


  Language("HTML") fun html(): String


}
25

What I'm trying to do is really only 2), without any DSL option. I did the external compilation just as a workaround for the fact that we cannot inject html -> kotlin right now,but instead we can inject kotlin->html. Only that html it's obviously not directly compilable by Kotlin compiler!

But I agreed with you, it’s better to wait for the language injection to work in the correct way, and things will get far easier than they are now.

So, I’m porting the file you linked to kool template (also because of this other Kotlin bug, that make impossible to compile the view via mvn)

I would prefer to have both 1) and 2) option in my ideal framework.
My personal preferred choice is for a template system like 1), but I think many people (web designer) instead will feel more confortable with a
plain html syntax like 2)

Regarding your purposed syntax , I don’t fully understand the need of  a separate trait.
It’s not more concise if we directly decorate the fun in the main view class?


package templates
import kw.views.*
import sites.welcome.*

class MyTemplate(val someParams: Foo) : HtmlTemplate {

  Language(“HTML”) fun render() = “”"

…

${someParams.something}

…


“”"

}

or, without class at all:



package templates

import kw.views.*

import sites.welcome.*


Language(“HTML”)

fun MyTemplate(someParams: Foo) = HtmlTemplate {“”"


…

${someParams.something}

…


“”"

}


(HtmlTemplate here is a function that take a () -> String as parameter, and return an escaped String)

26

Yeah, a function works too; I just used a class as it avoids having to remember to add the @Language annotation

27

Ah ok i get it now. Yes, could be useful. But I think that we can then directly decorate the HtmlTemplate function (I'm not sure if caould be done this way). 


fun MyTemplate(someParams: Foo) = HtmlTemplate {"""

…

${someParams.something}

…


“”"

}



//declared in some library

Language(“HTML”)

fun HtmlTemplate(htmlContent:()->String){

  //escape htmlContent

  //set response content = htmlContent

  //set response type = html/text

}

28

Though I wonder if the function which returns the String would still need to be annotated with @Language("HTML") to ensure the language injection works?

29

Just whanted to check if anyone is still working on Kotlin-Vert.x integration.

Most of the links from this thread are pointing to projects with no recent activity. Are there some non-obvious obstacles in the integration? Any tooling related problems?

30

Creating a language integration with Vert.x is a non-trivial exercise that requires on the fly compilation and byte code injection if memory serves.  Setting up the test suite is likewise a bit of a bear.  I've tried a few times to get it working with some success but never went all the way for various reasons.  Mostly time.

Now there is talk about Vert.x 3.0 as a complete re-write.  So I would suggest if an effort is going to be made to integrate Kotlin to wait for 3.0.  Here is the latest:

https://groups.google.com/forum/#!searchin/vertx/3.0|sort:relevance|spell:true/vertx/DHL9cAg4SYo/FAqi1iBimOwJ

https://github.com/eclipse/vert.x/wiki/Vert.x-3.0-plan

31

Hi Nikita!

The work on vertx 3.0 has begun.  I will likely give a stab at Kotlin integration.  I’ll publish anything I do on github if you’d like.

-Steve

32

By the way Vert.x will introduce Kotlin support in v3.4.0. Currently Vert.x 3.4.0 is in beta with the first release already out.

1 Like