For those of you who may have missed it:
https://twitter.com/#!/nmartignole/status/169858537323892737
I hope this is true. It would be cool.
Yes, we plan to support Play. If anyonw wants to help us, please feel free to.
I'd be interested in helping, but I'm not very familiar with play framework and I'm not sure what the learning curve will be. Would the task consist of writing a module for Play, like the scala module (http://www.playframework.org/modules/scala)?
Yes, the task is, basically, along these lines.
Providing a template engine based on Kotlin «Groovy styled» builder could also be great, no?
I was wondering about templating too. As far as I can tell, Play 1.x uses Groovy for templating and the new Play 2.0 uses a Scala-based templating. While I agree that a Kotlin template engine would be great, I also wonder what's the path of least resistance? Does it make sense to develop a new template engine right away, or use the groovy templating to begin with?
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 = "http://jetbrains.com/kotlin") {+"Kotlin"}
// mixed content
p {
+"This is some"
b {+"mixed"}
+"text. For more see the"
a(href = "http://jetbrains.com/kotlin") {+"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.
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"}
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).
I agree, the html builder approach seems more suitable for producing json or xml...
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)
The news that kotlin chose play framework for a web framework is really excellent.
Nevertheless I think that it could mean very different things, I'll try to clarify a bit the options I see and that have been discussed in this thread
go for a new framework developed with kotlin from scratch
- write from scratch a new type-safe, stateless, asynchronous framework
well, that's certainly a lot of work. and maintaining it and keeping it upto date adds some great burden too
stick with play 1
a couple of options
- develop a module (just like the scala module por play 1)
take into account that play developers found a couple of limitations to this approach. they had to modify the core framework to support scala (have a look at the source, you'll find many scala ad hoc modifications) they couldn't support latests versions of scala, and finally the chose to rewrite the framework in scala
- fork the project in java and then gradually adapt it for kotlin use
there has to be a good reason to fork a project, you'll have to deal with support, enhancements, backport new features from the original project, etc...
Take into account that, in general lines, even though, as play developers clearly stated, play 1 will certainly be supported for a long time, the community is heading to play2.
ride on play 2
I don't think you can provide play support with just a module, like in play1. I think you'll have to create a project like they did with java: https://github.com/playframework/Play20/tree/master/framework/src/play/src/main/java/play, providing a kotlin API to all the play2 functionality.
that would be a fine starting point
then you could add a module for a template system based on kotlin. Ideally this would be an independent project that could be used outside of play (I think the current play2 tempalte engine, written in scala) is designed that way). Then this kotlin template engine could be used by play2 scala, java and kotlin users, or even outside of play.
Then you could also develop another module to define the routes in kotlin.
--
I think that the play2 path is the way to go. Jetbrains could provide a whole kotlin type-safe, asynchronous, well supported, framework, without the user ever knowing the core is in scala.
The good news is that play2 already supports an additional language (that is, java), so this use case has been taking into account.
Java has certain limitations, and lot's of developers just don't feel quite comfortable with scala (ok, I think that kotlin devs know this better than me ;-) So a kotlin API for play framework 2, with the tools and support provided by Jetbrains, would be great.
I'd like to know what kotlin developers think on this subject.
saludos
sas
Sebastian, thanks for explaining of the different options. As someone not very familiar with Play, that was useful.
So to summarize the options you suggested:
1a) Develop module for Play 1, like the scala module (less work, but some limitations)
1b) Fork the project, and gradually adapt it and rewrite portions in Kotlin (more work and maintenance, but will overcome some limiations of option 1a)
2b) Ride on Play 2, and create a Kotlin API similar to the Java API. Since this is not a module per se, it would in a sense mean forking the repo and then hopefully Play maintainers would pull the Kotlin code into their repo... or otherwise it would require some manual process. Also, from what I understood, this option would mean pulling in both scala and kotlin libraries, so the runtime dependencies could become bloated and performance may suffer. Does that make sense?
I'm just laying out the options again as I understood them, how can we move the conversation forward and evaluate these options?
--
Yes, those are the options, as I see it...
If you have enough man-power to develop and maintain your own web framework it would be an excellent showcase of what you can do with kotlin as well as provide good practices. I'm sure you'll come out with an excellent and light-weight product. But you would loose play framework community and typesafe support.
And yes, if you use play2 (or any other scala library, like akka) from kotlin you would need both runtimes.
On the other hand, developing a kotlin API wrapper around play2 (that's what they did with java) shouln't be so difficult to achieve. Right now, when you create a new play2 application, you are being asked if you want to create a java or scala app. I guess that to achieve that level of integration you should have to work togeter with play developers.
About forking Play1, I don't think there will be a lot of new features to backport from Play 1.x branch (Play2 will be stable very soon).
On the other hand, if there is a need to add later new features in the original Play 1(without a fork), it may be difficult to do it on a such mature and (soon) frozen project (I don't know if Play team would agree)
About Play2, the only problem is that it would require to have all scala libs/runtime + kotlin libs/runtime in the same time
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.
Why not minicing play2 , developing a new type-safety & stateless framework ?
With kotlin's easier grammer , I think it will quickly attract a lot of java developers (who are reluctant migrating to play2's scala area )
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.
I think that I really know how does the Play! framework work, so in my opinion the main problem we should solve, if we speak about basic support of Kotlin in Play, is creating of cool kool templater and of course we also need annotations with parameter values support. I am very interested in this, so I will spend my free time on writing this Play! module.
Super Kool !!!
Awesome!
"If anyonw wants to help us, please feel free to."
I would love to do it
Is there anything started? Will the module be hosted on github?
Indeed I think it would be nice to have a Kotlin templating system, and a comprehensive API for controllers.
I guess it will be based on Play2.0. Do you know if the kotlin version will support JPA annotations (like java version) or someting like Anom (like in play2 scala version)?
Great news anyway!
Here is a problem with Play 2.0 - it is written on Scala (about 70% of code) and so we will have 2 additional runtime libraries and a lot of data conversion...
So you want to make a module for play1? It would still be cool but I'm afraid that all the community is moving to play2...
I think there will be some resistence for Java developers to adopt Play 2, and there will be some time for Play 2 to mature. So if it's minimum effort (because it's Kotlin interfacing with Java and not Scala) to support Play 1.x with groovy templates first, then later Kotlin templates, I wouldn't think that's a bad idea.
In Play 2, the core is built in scala but the scala api is wrapped by a java API. If the idea is to provide the possibility of using kotlin instead of java for web development the integration should not be so difficult.
Morevover, I don't completely share your views about the java community that would stay on play 1. I can't imagine someone starting a project on a version of a product knowing that the codebase will not be compatible with the next major version. If I have no visibility on the duration of the framework, I prefer using another framework.
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:
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?).
The template I've done so far did not HTML escape the string, but I saw that in Templates.kt
you did some work, so I thought just to wait for string escaping to be working (at least, I presume it's not working now, I didn't understand how to
convert a string to a string array to build a StringTemplate instance).
If I correctly understand how Kotlin string works, they are converted to a String[] at runtime, but how I can access this array?
I need some day to push my code to github, because it include a sample app that use a database from one of my customer, I have to remove sensible data and
create another db containing only the 2 tables I used in the sample.
I'll also add some comment to explain how I thought to put all my ideas together. Anyway I will be honoured to get your opinion...
Cheers
Andrea
Your framework looks really cool, I would be happy to see the code and to try it too ![]()
Thank you, but as I said it is just a proof of concepts by now, not really usable for real work.
Anyway, I think I can put it on github within some day, at least to discuss the concepts
and if possible to start together to develop a web framework as discussed in this thread.
I think that the best way to go is to develop a Kotlin layer around the Play Scala core, as they
do with Scala.I don't want to reinvent the wheel, and I really like Play.
BTW by intellisense did you mean the language injection support in IDEA? If so how did you get it work? ![]()
It works great for me in Java using the @Language annotation; though it doesn't seem to work for me in Kotlin though. Did you figure out a way?
I've raised http://youtrack.jetbrains.com/issue/KT-2428 to track it in the meantime.
Yes, I mean it. But you cannot inject HTML into Kotlin, at least for now, I hope Jetbrains guys will add support for the language soon.
However, what you can do is inject Kotlin into HTML. This is supported and work, except inside strings, but with come caveats.
Injection in HTML is done by HTML tag, so you have to choose which html tag will contain Kotlin code.
I've configured the <html> tag in Idea, and I get Kotlin completion and error reporting for all code put inside it.
But, if you look at [https://github.com/parroit/kweb/blob/master/sites/welcome/src/main/kweb-kotlin/views/layout.html.kt],
you'll see that the file is no more a valid Kotlin file, because it start with html tags.
So I have to change the file extension to something other than kt, and compile it by hand in [https://github.com/parroit/kweb/blob/master/src/main/kotlin/kw/server/compile/CompileView.kt].
I basically strip down from the file <doctype> <html> and </html> tags, compile the rest of the source (which is now valid kotlin).
<doctype> <html> and </html> are added by the htmlView fun when it render the output.
This process is a bit fragile by now, but I hope to improve it and make more solid.
A more standard approch like that of Play could be simpler to implement, but I love code completion
and error checking, I think that could be very useful...
Oh, I didn't remember to say I've also included LESS compiler from Asual
I've submitted my work to https://github.com/parroit/kweb.
It's really rough for now, I'm in the process of adding comments to explain my ideas
and difficult I've found (someone due to my Kotlin inexperience, some due to compiler bugs).
I've included Intellij project and modules files, but not all dependencies jar. I think you can deduce it from Intellij project libraries, and in the meantime
I create a pom.
Remember that templates are not escaped in any way, use at your own risk!
I look forward for your comments...
Feel free to contact me by email if you prefer
Really nice (and big) work! It looks pretty cool and comprehensive for a proof of concept.
It's really promising, if you need help to add new features on it, I would be happy to help.
Is there a simple way to run the sample app?
Loic
Thank you Loic, I'm happy you appreciate my work ![]()
To start the sample site, if you've managed to resolve all jar dependencies, there is
a main() function in sites\welcome\src\main\kweb-kotlin\App.kt.
It start the netty server and launch your browser on localhost:8080.
I need any kind of help to go on, your collaboration will be precious!
According to you what could be the best way to go on: continue with a new framework,
or to develop some kind of module to integrate in Play?
I think that the first option could attract developers that are not satisfied with Play 2
and its complete Scala rewrite, while the second option could attract all other
Play developers (the ones which like Play2...)
If you look at kw.views.Html.kt, it is all taken from the html builder sample, I think it's
better to replace that with kool.io templates from James.
I think both of them would be good ways to go on : continue with a play module would be cool because of the big play community (good way to bring people to use kotlin) and because of the number of avalaible play modules. But Play 2 already have dependency on Scala runtime APIs, so maybe adding Koltin runtime would be a bit heavy.
Building a new pure Kotlin framework may be really cool to bring new ideas and really make it in the "Koltin way".
By the way, I do not know if the Play-Kotlin project is progressing or if it was set aside...
Maybe Andrey Breslav could give us some hints on the status of play-kotlin?
I agree with you that building a new pure Kotlin framework will give us more space to develop new kool ideas...
But there is really a lot of work to be done this way, we have to get more people involved!
Yes it would be better to know the progress on Play before making a decision...
Sure. I'll write a post on a new thread explicitly asking for this. Could I speak of our project?
I've see on your Github account Play2-HTML5Tags and I think, if you agree, that it would be great to convert it to Kotlin and use it as part of the framework template.
I think If we take this way and also
that we could get a great template framework that we could we use both in a completely new web framework and in a Kotlin Play module.
Sure. I'll write a post on a new thread explicitly asking for this. Could I speak of our project?
Of course you can, it' your "child" ![]()
I've see on your Github account Play2-HTML5Tags and I think, if you agree, that it would be great to convert it to Kotlin and use it as part of the framework template.
I think If we take this way and also
that we could get a great template framework that we could we use both in a completely new web framework and in a Kotlin Play module.
Great idea, it looks exciting!
Another thing we could improve I think is the routes definition (App.kt). If we use a kind of template for this it would be more readable.
Yes the route definition, it's not really readable now. Just post an issue on Kweb project, I will comment on this issue there...