Kotlin and Playframework

I agree, there won't be much backporting to do, and yes, play1 is a mature and stable project, with a considerable amount of apps in productions, so it's natural that play developers were hesitans to mess with it.

In case jetbrains dev decide not to go with play2 because of scala dependencies, they might fork play1. But I would take it just as a starting point, and then gradually rewrite it in kotlin. I think they should study both project’s source code, and talk to play developers, before maing a choice.

I think it would be good if we can start building a Kotlin framework anew, without any deplendeny on Play 1/2.

Since Kotlin has very low entry barrier for Java devs, if the  framework is in Kotlin, it would help to building community around and  attract good contributions to all modules (Core, templates, routes,  websockets etc.)

As others already mentioned, a module to Play 2 will incur  additional runtimes and overhead and I don’t think it will help Kotlin  altogether in long run and to really mark its presence.

Yes, it involves lot of works, but not impossible; they did it twice.
Last few weeks of tinkering with Kotlin finds really refreshing for me,  it is a natual transition from Java, I’m definitly willing to help.

As it happens Kotlin already has a kind of template already included for Strings. e.g.

``

fun foo(customer: Customer) = “”"
<html>
<body>
<h1>Hello ${customer.name}</h1>
<p>How are you? Its ${new Date().day}
lets do some kool stuff</p>
</body>
“”"

You can create single line or multi line strings with the $foo or ${someExpression} form.

Though this currently does not support things like HTML / JSON / URL / JDBC escaping yet.

We’re looking at extending the template expressions in Kotlin to support this though. Feel free to follow http://youtrack.jetbrains.com/issue/KT-1565 feedback appreciated!

Nice! But with this kind of string evaluation you can't do things like loops, right? e.g :

#{list items:products, as:'product'}
    <li>${product.name}. Price : ${product.price.format('## ###,00')} €</li>
#{/list}

and how about creating you own tags?

It wouldn't support all of the power and expressiveness of a custom template engine like Scalate / Velocity / Jade but you'd be able to use functions to decompose the template into regular Kotlin code though...

fun foo(customer: Customer) = """ <html> <body> <h1>Hello ${customer.name}</h1> <ul>   ${products.map{productSnippet(it)}.join("n")} </ul> <p>How are you? Its ${new Date().day} lets do some kool stuff</p> </body> """

fun productSnippet(product: Product) = “<li>${product.name}. Price : ${product.price.format(‘## ###,00’)} €</li>”

There’s currently a few compiler bugs in Kotlin’s inferencer BTW that forces you to specify explicit type parameters on the call to map unfortunately such as in this test case. So the use of map() is temporarily a little more verbose than it should be

Here's a test case showing the above example in working code. If you've the latest IDEA plugin you can right click on the test case and Run as unit test

At first, the HTML builder of the demo seemed more powerfull to me. Plain kotlin mapping the html structure and allowing loops and ... everything.

No?

``

val result =
  html {
  head {
  title {+“XML encoding with Kotlin”}
  }
  body {
  h1 {+“XML encoding with Kotlin”}
  p {+“this format can be used as an alternative markup to XML”}
  // an element with attributes and text content
  a(href = “Kotlin Programming Language”) {+“Kotlin”}
  // mixed content
  p {
          +“This is some”
          b {+“mixed”}
          +“text. For more see the”
          a(href = “Kotlin Programming Language”) {+“Kotlin”}
          +“project”
  }
  p {+“some text”}
  // content generated from command-line arguments
  p {
          +“Command line arguments were:”
          ul {
           for (arg in args)
           li {+arg}
          }
  }
  }
  }

I think you're right It looks more simple

Yeah, they can both be mixed and matched too

I agree that HTML builder seems more powerful and clean than the templating option, but the main problem I see, in the real world is that this is not the way most people want to develop a web page.  Generally, you design a static file that you can preview in a browser, and then you modify it and insert some dynamic things into it.  You don't want to rewrite all the HTML in a new format.

That is how I do when working with wicket as the views are real html files. The workflow is very efficient : you start with big static html files and then add <wicket:panel> tags to cut them to extract the wicket components. At any time, your html templates files are html files so you can view them in firebug to adjust the css and code.

In all the other cases, when your templates are not real html files, you need to process them to see the rendering. So, as you need some processing, having templates written in another format is not such a problem. Having a testing framework that allows to render, modify, re-render without any delay is an issue to keep the productivity at a high level.

The tools might contain a html2kotlin generator to accelerate the startup. If we think of play as a production and development tool (showing the code and template errors) you can imagine that when started in dev mode you can drop somewhere your html file to generate the kotlin template.

I agree, the html builder approach seems more suitable for producing json or xml...

Right.  In dev mode, there has to be an efficient way to view the output of whatever builds the html.  Whether the builder is you, operating in your example Wicket mode, or some tool that has completed the view in a few milliseconds.

We could imagine the template built with the html builder with injection of classical http fields (the request, the params, ...) and the specific domain object (or models) needed for the content. The dev mode could inject mocked versions of those object to allow an immediate basic rendering of the content.

Having the refactoring features of Idea could bring some very high productivity on the view definition:

  1. Dropping of an html static page in the browser (in background task: generation of the template using jsoup or whatever).
  2. Back to idea for the edition of the generated html template :

body {            h1 {+"XML encoding with Kotlin"}            h2 {+"Heading of first paragraph"}            p {+"The First paragraph"}

with just CRL+ALT+M (introduce method) on 2 lines, the template becomes :

  body {            h1 {+"XML encoding with Kotlin"}

           firstParagraph(this)   

...
fun firstParagraph(body:Body):Unit{
  body.h2 {+"Heading of first paragraph"}
  body.p {+"The First paragraph"}
}

3. Back to the browser, reload to see the template working.

This way of coding could bring the usual facilties of refactoring code inside templates, which is not currently the case. We could imagine some code intentions for the html templates to extract just the desired component generation (a portlet for example) from the whole template. The enclosing code being pushed in the test class to see the result of the component  in a complete page. In my example, the firstParagraph() method would become a renderBodyComponent(body:Body).

And why not create a special section in templates, to write client side code in Kotlin, which can be compiled to JavaScript. Then we could be able (but not forced) to write all the application in Kotlin. (This special section could be something like coffeescript section in html pages)

So there is something started after 4 months? If yes, I will be happy to contribute. And if not, why don't we start something altogether? I saw a lot of people in this thread that is available to help...

FWIW I've created an internal HTML5 template DSL, Kool Templates, that generates DOM nodes which can now work either on the client side in JavaScript or on the server side on a JVM.

Its not been integrated into Play or anything though.

Hi James, kool news from your side! I already saw your kool.io web sites, I not yet tryed the framework, but I think you did an awesome work, for what I saw on the site.

I think that your builder-based template has to paired with a pure HTML one.
I personally prefer build my views using a builder-style template such as your, but I think
that an HTML based one will be more attractive for web designer.

For my 2 cents, I’ve developed a web framework (is just a proof a concept) in Kotlin, starting from zero.
I’ve not released it in any way, it’s just to experiment and to learn Kotlin features, however
I think I have some good ideas while doing it,
if you want I can help you integrating Kool stack with play framework,
and maybe we can improve and integrate some of my code too.

What I did till now:

  • persistence based on hibernate
  • reverse-route ala play to get controller url  
  • HTML template based on Kotlin multiline string, with integrated intellisense both for HTML and for Kotlin constructs  (in intellij using language injection)
  • view ui helpers for twitter bootstrap

All this it's at a very very early stage, but "at least it work on my machine"

Bye

Andrea

P.S. sorry for my english, it’s not my natural language

That all sounds very interesting :) I'm particularly interested in the HTML based template based on Kotlin multiline-string - that sounds awesome!

I’ve been hoping we can get Kotiln templates in the language (rather like Groovy Strings) so that we can use HTML / SQL / localisation escaping of multi-line strings. I’ve done most of the work in the standard library; we just need the compiler/language hooks to turn string templates into StringTemplate objects rather than Strings. e.g.

i.e. "foo $bar whatnot" should be equivalent to StringTemplate("foo ", bar, " whatnot") so that the dynamic values can be escaped/processed in different ways depending on context (localisation, html/xml/json encoding etc).

Having said all that I’d be very interested to see your work - fancy submitting it to a github project? Feel free to add it as a module in kool.io if you like? (Just fork it from github & submit a pull request?).