Introducing Play 2.0
Guillaume Bort
Since 2007, we have been working on making Java web application
development easier. Play started as an internal project at Zenexity
and was heavily influenced by our way of doing Web projects: focusing
on developer productivity, respecting Web architecture, and using from
the start a fresh approach to packaging conventions - breaking where
it made sense the so-called JEE best practices.
In 2009, we decided to share these ideas with the community as an open
source project. The immediate feedback was extremely positive and the
project gained a lot of traction. Today - after two years of active
development - Play has several versions, an animated community of
3,000 people, with a growing number of applications running in
production all over the globe.
Opening a project to the world certainly means more feedback, but it
also means discovering and learning about new use cases, requiring
features and un-earthing bugs that we were not specifically considered
in the original design and assumptions. During the two years of work
on Play as an open source project we have worked to fix all of these
kind of issues, as well as to integrate new features to support a
wider range of scenarios. As the project has grown, we have learned a
lot from our community and from our own experience - using Play in
more and more complex and varied projects.
In the meantime, technology and the Web have continued to evolve. The
Web has become the central point of all applications. HTML, CSS and
Javascript technologies have evolved quickly - making it almost
impossible for a server side framework to follow. The whole Web
architecture is fast moving towards real-time, and the emerging
requirements of today's project profiles means SQL no longer works as
the exclusive datastore technology. At the programming languages level
we've witnessed some monumental changes with several JVM languages,
including Scala, gaining popularity.
That's why we think it's now time to move on, and to consider the next
major version of Play. Welcome Play 2.0!
Native support for Java and Scala
---------------------------------
In Play 1.1, we started exploring the possibility of using the Scala
programming language for writing Play applications. We initially
introduced this work as an external module to be able to experiment
freely without impacting the framework itself.
Properly integrating Scala into a Java-based framework is not trivial.
Considering Scala’s compatibility with Java, one can quickly achieve a
first naive integration that simply uses Scala’s syntax instead of
Java’s. This, however, is certainly not the optimal way of using the
language. Scala is a mix of true object orientation with functional
programming. Leveraging the full power of Scala requires rethinking
most of the framework’s APIs. After several versions we now have a
clean Scala module that allows the use of most of Play's features from
Scala, in a Scala-ish manner.
Now, we are reaching the limits of what we can do with Scala support
as a separate module. Initial design choices we made in Play 1.x,
relying heavily on Java reflection API and byte code manipulation,
have made it harder to progress without completely rethinking some
essential parts of Play’s internals. Meanwhile, we have created
several awesome components for the Scala module, like the new
type-safe template engine and the brand new SQL access component
Anorm. So we have decided that, to fully unleash the power of Scala
with Play, we are moving Scala support from a separate module to the
core of Play 2.0, which will be designed from the beginning to
natively support Scala as a programming language.
Java, on the other hand, is certainly not getting any less support
from Play 2.0; quite the contrary. The Play 2.0 build provides us with
an opportunity to enhance the development experience for Java
developers. Backed by our experience throughout the project we have a
clear idea of what we need to achieve and what mistakes we have to
avoid.
Powerful build system
---------------------
From the beginning we have chosen a fresh way to run, compile and
deploy Play applications. At the time it may have looked like an
esoteric design - but it was crucial to providing an asynchronous HTTP
API instead of the standard Servlet API, short feedback cycles through
live compilation and reloading of source code during development, and
promoting a fresh packaging approach. Consequently, It was difficult
to make Play follow the standard JEE conventions.
Today, this idea of container-less deployment is more and more
accepted in the Java world. It's a design choice that has allowed the
Play framework to run natively on platforms like Heroku, which
introduced a model that we consider the future of Java applications
deployment on elastic PaaS platforms.
Existing Java build systems, however, were not flexible enough to
support this new approach. Since we wanted to provide straightforward
tools to run and deploy Play applications, in Play 1.x we created a
collection of Python scripts to handle all build and deployment
related tasks.
But developers using Play for more enterprise-scale projects, which
require build process customization and integration with their
existing company build systems, were a bit lost. The Python scripts we
provide with Play 1.x are in no way a fully featured build system and
are not easily customizable. That's why we've decided to go for a more
powerful build system for Play 2.0.
As we need a modern build tool, flexible enough to support Play
original conventions and able to build Java and Scala projects, we
have chosen to integrate SBT in Play 2.0. This, however, should not
scare existing Play users who are happy with the simplicity of Play
build. We are leveraging the same simple play new, run, start
experience on top of an extensible model: Play 2.0 will come with a
preconfigured build script that will just work for most users. On the
other hand, if you need to change the way your application is built,
deployed, etc., a Play project being a standard SBT project will hand
you all the power to customize and adapt it to your special needs.
This also mean better integration with Maven projects out of the box,
the ability to package and publish your project as a simple set of jar
files to any repository, and especially live compiling and reloading
at development time of any depended project even for standard Java or
Scala libraries projects.
Focused on type safety
----------------------
One benefit of using Java as programming language for writing Play
applications is that the Java compiler can check certain parts of your
code. This is not only useful for detecting mistakes early in the
development process, but it also makes it a lot easier to work on
large projects with a lot developers involved.
Adding Scala to the mix for Play 2.0, we will clearly benefit from
even stronger compiler guarantees - but that’s not enough. In Play
1.x, the template system is dynamic, based on the Groovy language, and
the compiler can’t do much for you. As a result, errors in templates
can only be detected at runtime. The same goes for verification of
glue code with controllers.
We really want to push further this idea of having Play check most of
your code at compilation time in the 2.0 version. Accordingly, we have
decided to use the Scala based template engine as the default for Play
applications - even for developers using Java as the main programming
language. This doesn't mean that you have to become a Scala expert to
write templates in Play 2.0, just like you were not really required to
know Groovy to write templates in Play 1.x. Scala will be mainly used
to navigate your object graph in order to display relevant information
with a syntax that is very close to the Java one. However if you want
to unleash the power of Scala to write advanced templates
abstractions, you will quickly discover how Scala, being expression
oriented and functional, is a perfect fit for a template engine.
And that's not only true for the template engine: the routing system
will also be fully type-checked. Play 2.0 will check all your routes'
descriptions, and verify that the everything is coherent, including
the reverse routing part.
As a nice side effect, being fully compiled, the templates and route
files will be easier to package and reuse and you can expect high
performance gain on these parts at runtime.
Built for asynchronism
----------------------
Today's web applications are integrating more concurrent realtime
data, so web frameworks need to support a full asynchronous HTTP
programming model. Play 1.x was initially designed to handle classic
Web applications with many short lived requests. But now, the event
model is the way to go for persistent connections - though comet,
long-polling and WebSockets.
Play 1.2 already provides great asynchronous HTTP support and
WebScokets using continuations. Play 2.0 will be architected from the
start under the assumption that every request is potentially long
living. We want, for instance, to generalize Controller and
WebsocketController concepts into one single simple model that fits
all needs.
But that’s not all: we also need a powerful way to schedule and run
long running tasks. Although the original Play 1.0 Jobs model was
introduced for this, we really need something more powerful and
robust. The Actor based model is unquestionably the best model today
to handle highly concurrent systems, and the best implementation of
that model available for both Java and Scala is Akka - so it's going
in. We will be introducing native Akka support for Play applications,
making it possible to write highly distributed systems.
Datastore and Model integration
-------------------------------
Datastore is no longer synonymous with "SQL database", and it probably
never was. A lot of interesting models of datastores are becoming
popular, providing different properties for different scenarios. For
this reason it has become difficult for a Web framework like Play to
make bold assumptions regarding the kind of datastore that will be
used by developers. A generic play.db.Model concept in Play no longer
makes sense, since it is almost impossible to abstract over all these
kinds of technology with a single API.
We want to make it really easy in Play 2.0 to use any datastore
driver, ORM, or any another database access library without any
special integration with the Web framework. We simply want to offer a
minimal set of helpers to handle common technical issues, like
managing the connection bounds. We also want, however, to maintain the
full-stack aspect of Play framework by bundling default tools to
access classical databases for users that don't have specialized
needs.
Today, the preferred way for a Play Java application to access an SQL
database is the Play Model library that is powered by Hibernate. But
since it's annoying in a stateless Web framework like Play to manage
stateful entities such as the ones defined in the official JPA
specification, we have provided a special flavor of JPA keeping things
as stateless as possible. This forced us to hack Hibernate in a way
that is probably not sustainable in the long term. To address this, we
plan to move to an existing implementation of stateless JPA called
EBean. If you don't care too much about what is used under the hood
then it will change almost nothing for you, but if you really want to
use Hibernate or even another official JPA implementation you will be
able to do it without any special integration with Play. And if you
are using Scala we will continue to bundle Anorm.
Changes for current Play users
------------------------------
Play 2.0 will be a major release so it is unlikely that it will be
compatible at the API level with previous versions. Of course at the
architecture level you will find the same set of components, organized
in the same way, and most importantly, you will live the same 'Play
experience'.
What about my existing Play applications? How difficult will it be to migrate?
Don't worry, we don't expect you to migrate your existing applications
to Play 2.0. The Play 1.x versions will continue to be maintained and
you don't need to move to Play 2.0. We ourselves have many Play 1.x
web applications running and we will of course continue to support
them.
Remember: Play 1.2.3 is still the best way to write Web applications
in Java while Play 2.0 is still under development, and will continue
to be maintained and developed by the core team and contributors. Play
2.0 is an opportunity to move to for your next project, or the next
major rewrite of your application.
Getting started
---------------
Play 2.0 is still under heavy development and APIs are likely to
change, but you can already have a look to our preview versions. We
have set up a new GitHub repository to host the development, and we
have released a first preview version.
On the dedicated page at http://www.playframework.org/2.0, you can
track progress on this exiting project.
Have fun!
--
Guillaume Bort, http://guillaume.bort.fr
GrailsDeveloper
that sound like a good new direction for play. Would be great to have
the possibility to use the Scala-Template right now in a java-play-
project. Perhaps someone can show how this is possible. This enables
to avoid a migration of the templates.
2 question are still open to me:
1. Will the new framework mainly developed in Scala? I think this is
an important issue, because at the moment it's really easy for an
experienced java developer to analyze the code and create patches. How
will it be in the future? In other words, will you try to write as
much code as possible in Java and use only Scala where necessary or
the other way around?
2. CRUD based at the moment bold on JPA. Will there be a CRUD-Module
in the future?
Wish you great luck and a quick progress on Play 2.0. A beta at the
end of the year sounds great to me.
Niels
Pascal Voitot Dev
I have the same questions as Niels.
Moreover, when you foresee to integrate EBean, please also think about other frameworks (mine is siena as you may know) which will need to be integrated and do not wire everything too much tightly. In an ideal world, I would like to be able to remove completely EBean if I don't want it and replace it by Siena!
Anyway, I'm eager to see next steps and if you need help, don't hesitate to ask!
regards
Pascal
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
Bing Ran
Bing
Guillaume Bort
> an important issue, because at the moment it's really easy for an
> experienced java developer to analyze the code and create patches. How
> will it be in the future? In other words, will you try to write as
> much code as possible in Java and use only Scala where necessary or
> the other way around?
Most part of the core (HTTP and asynchronous invocation handling) will
be written in Scala, because it is really easier and more robust
(avoiding mutable states in this part will just make it easier to
debug and maintain).
But all the Java related API will be written in Java. Because we want
to provide an idiomatic API for Java and not force Java developers to
deal with Scala types. Also we want to have a clean Javadoc for the
Java API.
> 2. CRUD based at the moment bold on JPA. Will there be a CRUD-Module
> in the future?
I don't think so, or perhaps as an external module for particular ORM.
But trying to provide an unified CRUD module for all persistence
engines we can imagine is way too difficult. Anyway I think that the
current CRUD module is not flexible enough. It mainly solve the need
of writing a lot of repetitive screens, but It think it can be solved
with a better form/paginated list, tag components instead. But nothing
is decided yet.
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>
--
Guillaume Bort, http://guillaume.bort.fr
Guillaume Bort
> frameworks (mine is siena as you may know) which will need to be integrated
> and do not wire everything too much tightly. In an ideal world, I would like
> to be able to remove completely EBean if I don't want it and replace it by
> Siena!
It exactly what we count on. That's why, even if we provide a default
ORM for Java to keep the fullstack aspect of Play, allowing users to
create quickly web applications, we won't integrate it too much with
the other parts of the framework. It is really important for us that
we can use whatever persistence engine you want with Play 2.0, without
need to hack it.
Please track the progress, and if you think that we make choice that
could limit integration with other persistence engine, in particular
Siena, tell us!
Pascal Voitot Dev
> Moreover, when you foresee to integrate EBean, please also think about otherIt exactly what we count on. That's why, even if we provide a default
> frameworks (mine is siena as you may know) which will need to be integrated
> and do not wire everything too much tightly. In an ideal world, I would like
> to be able to remove completely EBean if I don't want it and replace it by
> Siena!
ORM for Java to keep the fullstack aspect of Play, allowing users to
create quickly web applications, we won't integrate it too much with
the other parts of the framework. It is really important for us that
we can use whatever persistence engine you want with Play 2.0, without
need to hack it.
great :)
Please track the progress, and if you think that we make choice that
could limit integration with other persistence engine, in particular
Siena, tell us!
Yes now that Siena is near its final version 1.0.0 (just need mongoDB impl to definitely prove the design works), I will look at play2.0 a bit nearer and will tell you if I see any problems... Your scala evolution will certainly help me to develop the Siena4Scala also!
Pascal
Guillaume Bort
2 different versions would be terribly difficult. It's already the
case currently with the Scala module that is always behind the main
framework.
We prefer to merge efforts to provide a single perfect framework that
will support Scala and Java independently.
Pascal Voitot Dev
Now that I know better Scala (and love it more and more), I know that you can write the core in Scala and make it fully available to any Java application and provide some external full-Java APIs without any problem.
The only drawback is for people who liked to modify the code and now they will need to know Scala. But anyway, I agree with you, maintaining 2 frameworks would be crazy!
pascal
Hristo Deshev
Guillaume Bort
> guess nobody likes the idea of having a completely different Play framework.
> I hope you guys are able to define a clear migration path for 1.2.3. users
> that want to move to 2.0. Especially the ones like me that use the Scala
> plugin.
If you are using the Scala module currently, the migration path to
Play 2.0 will be easy. The most important change that will make
migration to Play 2.0 difficult is the new type safe template engine.
But if you are already using it it will be easy.
> One question - will play-scala 1.x eventually move to Scala 2.9.1? I hope
> that feature isn't planned for the 2.0 version only.
Problem is that Scala 2.9.0 breaks the Java reflection API (they done
it for good reasons however). So migrating the Scala module to 2.9.x
breaks almost everywhere it uses Java reflection API(binding,
fixtures, etc.). It's almost impossible to migrate without rewriting
these parts.
Ivan Meredith
I see anorm hasn't bean ported yet... btw, I take it you meant ebean
for java, anorm still preferred for scala?
Dave Cheong
Michael Boyd
Play 2! I'm sure it will be great.
However, can I make one suggestion? Don't re-invent the wheel with
type-safe declarations in the Scala templates.
Instead, I think you should use the declarations used in a popular JS
templating library -- preferably Closure Templates/Library.
I do this right now in tags and views, and it makes converting to
Closure Templates much easier:
*{
@param {String} _title
@param {Collection} _items
@param {play.mvc.Router.Route?} _pageLoadUrl (the ? indicates
optional)
}*
...the actual template here...
<h1>${_title}</h1>
Rakesh Waghela
Ivan Meredith
https://github.com/playframework/Play20/blob/master/play
On 8 September 2011 00:02, Rakesh Waghela <java...@gmail.com> wrote:
> Windows is not supported yet ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/4WHeNxHSXCAJ.
Daryl
I am going to disagree with some people here, and make a plea to go
the extra mile to make upgrades from old versions as painless as
possible.
You are obviously trying to move things forward, but don't annoy
existing users. We have been using play for live client projects since
version 1.0.1, we are currently running all live applications
(currently about 20) on 1.0.3.3. We have already struggled to upgrade
to 1.2.3 due to fairly large API changes, which in many cases could
have been minimised by keeping some backwards compatible methods while
still adding the new functionality. But the changes have been quite
ruthless and constantly having to revisit old code to upgrade play
versions is a pain many commercial developers could do without. Yes we
can leave applications on the old version, but by deprecating methods
and having them point to newer versions is much nicer for developers
than ruthlessly dumping them. We often want to utilise some of the
fixes & new features, but don't because of the pain to upgrade an
application to support a newer version.
We are not all playing at this (excuse the pun), we are trying to run
commercial development businesses, and don't want to be penalised for
being an early adopter by people taking theoretical high ground on
backwards compatibility. Backwards compatibility is price that
successful and stable projects have to live with. I appreciate this is
major version we are talking about here, but the more consideration
for this the better.
So having said that, and with all the talking of making things modular
and plug and play etc. Can things such as the database/storage plugin,
and template languages all be managed as modules. If you could do
this, it would make an upgrade easier, by selecting the JPA/hibernate
module and Groovy template modules as default (per application, not in
Play itself), then the upgrade path will be simpler. Then if you could
specify the database and template settings in an annotation per
controller, it would allow existing code to run, while gradually
converting and creating new functionality on the new modules.
I guess this was rather long and rambling, but essentially, please be
very careful with this. Many of us live in the real world, not fantasy
play land, we need to keep up with latest versions, so make the
upgrade path as simple as possible. I don't always think this happened
with Play. To continue its success, I think it is needed.
Also any ETA on this? It is on my schedule to put the leg work in to
upgrade to Play 1.2.3 over the next couple of months. Is it even worth
doing this? If there is going to be no more substantial development on
the Play 1 branch, I will stick with 1.0.3.2, and only consider the
move to Play 2.
thanks
Daryl.
Guillaume Bort
>
> I see anorm hasn't bean ported yet... btw, I take it you meant ebean
> for java, anorm still preferred for scala?
It is what will be provided out of the box in the fullstack approach.
But nothing will prevent you to use anything else, either Java or
Scala based.
Guillaume Bort
> type-safe declarations in the Scala templates.
We don't want to reinvent the wheel. The whole approach and syntax is
borrowed from ASP.net Razor template engine. And signature declaration
are just plain Scala declaration.
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>
--
Guillaume Bort, http://guillaume.bort.fr
Guillaume Bort
compatibility without adding a lot of complexity to the project.
What's matter for us is to continue to support and maintain the
previous versions that are already running so many applications. And
we will do it. As you know, when we had the security alert lately, we
fixed all versions, including the 1.0.3.x. And we will continue to do
it, even after the 2.0 release. We have also a lot of applications
running on Play 1.x and we will surely not rewrite them all, or
abandon them.
If you have already several applications running on Play 1.0.3.3 for
your customers, it's fine, there is no need to migrate them. Just
consider 2.0 for you next project, or if it's worse it for a
particular application.
On the other hand, I'm sure than once the 2.0 version will be ready,
the community will help to port the current Groovy template engine or
JPA based Model API as Play 2.0 modules to ease migration of old
projects. It should be fairly easy, just for now we want to focus on
developing the core of the next major version.
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>
--
Guillaume Bort, http://guillaume.bort.fr
zka
it sounds great.
I already download the preview, for some reason i prefer java, so
with the new scala template engine, it is possible to place view in
folders ?
views/
my_folder_as_controller_name/
index.scala.html
another_controller_name/
index.scala.html
?
Daryl
I think the point I was hoping to make, is that the work on making
storage/template functionality pluggable is the key here, then having
modules for Play 1 compatibility is the obvious stepping stone for
upgrades. I would expect the compatibility modules to come later,
ensuring this support and ease of use/configuration is my biggest
concern.
The added bonus of being able to configure this on a controller basis
would also help, allowing the changes to be made over time, while
still supporting the newer options. Is selection of storage/templates
using an annotation per controller an option? If this could be built
in at this early stage, then it gives much more flexibility for
applications to be gradually upgraded? I have seen previous requests/
questions on here, that would have been possible by selecting module/
plugin options per controller, so I think any consideration for this
would be appreciated.
thanks
Daryl.
T.J. Crowder
Sounds very exciting! Don't let either of the following detract from
the main point that this sounds cool, and it's fantastic to see Play
moving forward, unlike so many projects that get a couple of years in
and just...stop. Clearly not the case here!
I'm sorry to hear you're rewriting a lot of the core in Scala because
it's not a language I know and I have an irrational bias toward
languages that are syntactically derived from B (so C, C++, Java,
JavaScript, C#, etc.). I realize I don't have to know Scala to create
Play apps, but I liked the idea of being able to get my hands dirty on
the internals as necessary (and hopefully contribute back). But I
guess either I'll have to not do that, or I'll have to bite the bullet
and learn a new language. (I've been doing this for well over 20
years, it won't be that much of a problem.)
Since you're going to be doing a lot of work in the source, could I
put in a request for *ALL* public API methods and fields to be fully
Javadoc'd? With more than one-liners (or one-liners linking to the
appropriate further documentation), ideally, but in many cases the
current API docs have no descriptions in the Javadoc at all, or such
minimal ones that they may as well not be there (the annotations in
particular suffer here).
I'm not complaining. Play is clearly a great framework and there is a
fair bit of documentation, but if you're going to be kicking around in
the source *anyway*, improving the Javadoc as you go could be a big
win.
Cheers -- and best of luck with Play 2!
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com
Guillaume Bort
> would also help, allowing the changes to be made over time, while
> still supporting the newer options. Is selection of storage/templates
> using an annotation per controller an option? If this could be built
> in at this early stage, then it gives much more flexibility for
> applications to be gradually upgraded? I have seen previous requests/
> questions on here, that would have been possible by selecting module/
> plugin options per controller, so I think any consideration for this
> would be appreciated.
No need annotation for that. It will clearly be different API, so if
you use a statically compiled template it will just be a standard
method call, but if you want to evaluate a Groovy template (if a port
if available in 2.0) you will just have to call render()
Arthur
I've just been looking through the kiki sample code; not downloaded it
yet as I'm currently at work. In the views, the controllers package
is being imported using the line
@import controllers._
Couldn't the controllers always be imported by default; so that this
piece of boilerplate isn't needed at the beginning of every view.
See https://github.com/playframework/Play20/blob/master/samples/kiki/app/views/hello.scala.html
for example.
>
> read more »
Guillaume Bort
> piece of boilerplate isn't needed at the beginning of every view.
Probably, nothing is final yet. But in 2.0 we will not block users to
use another namespace for controllers anyway.
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>
--
Guillaume Bort, http://guillaume.bort.fr
jgeiger
Pascal Voitot Dev
> Couldn't the controllers always be imported by default; so that thisProbably, nothing is final yet. But in 2.0 we will not block users to
> piece of boilerplate isn't needed at the beginning of every view.
use another namespace for controllers anyway.
the most boring IMO are the implicits also... quite verbose
Guillaume Bort
> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/H7nsQLwGxQkJ.
will
This is a fantastic release, especially with the native support for
Akka and async request.
Slightly off topic, does anyone know the comparison between Akka and
Node.js in term of memory consumption per connection, max connections
supported, and message latency? I'm investigating using Node.js for a
project with large number of connections but small message data set
(e.g. 100K idle connections per node but hundreds of bytes messages
occasionally to 1K connections). Thanks.
Sylvain Wallez
That's why we think it's now time to move on, and to consider the next major version of Play. Welcome Play 2.0!
The 2.0 website says " To get involved, please follow the development mailing list". Where is this list? I'm really interested in lurking there and possibly contribute once I feel comfortable enough with the new code base (and can stand the development pace).
Thanks,
Sylvain
-- Sylvain Wallez - http://bluxte.net
Rakesh Waghela
But it should not be enforced. Play ! is a revolution of Java world. Hopefully Java elements of Play ! prevails.
Especially in Template creation. why couldn't we have a template system with Java ? If it already exists as a module(Japid) in 1.x why not promote and make it better in 2.x ?
My request to Experienced Play Developers / Authors
Don't miss the big business world heavily invested in Java **Language** .
Play ! has just taken the baby steps in the real business shops.. let it grow !
durre
javaprogramming with play. I'm a bit afraid to look at the Scala
module and loose the momentum I'm in right now. This will change once
2.0 makes the first real release, then I'll make the plunge for new
webapps.
I'm just thrilled to see such a focused and productive core developers
that keep the framework I love on the cutting edge. Hope to join you
there soon :)
Thanks!
> major version of Play. Welcome Play 2.0!
>
Manh Do
It looks like you are planning to integrate Akka Actors. This is
definitely good news and it's definitely a step forward in providing
better concurrency.
Have you try looking into the Disruptor framework? I've ran several
tests and its performance is quite good. Configuring an asynchronous
ordered event processing is quite easy as well. I am planning to use
the Disruptor in my application in conjunction with Play.
Here's a link if you're interested: http://code.google.com/p/disruptor/
I am thinking that utilizing the Disruptor for request dispatching
would be quite beneficial.
In either case, I can't wait to for the release of Play 2.0. When do
you expect Play 2.0 to be release? I am in the midst of creating a
high performance / scalability application and am anxious to
intergrate with the next version of Play 2.0 for its Akka support.
>
> read more »
si
Guillaume Bort
> would be quite beneficial.
We are using Akka internally for requests dispatching, and performance
are awesome. You can test the sample application.
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
Keith Swallow
The newer Rails stacks are less useful when it comes to getting a new app up and running. I would like to caution all the Play maintainers against too much modularity. If the seams show a lot then the barrier to entry rises and a main benefit (and appeal) of the framework is lost.
Best,
Keith
Sadache Aldrobi
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
Manh Do
>
> read more »
descsuit
started using the Scala plugin one thing lit up a warning sign for me
and that was Anorm.
I'm using Squeryl on my current project and I like it a lot. I looked
at Scala-Query and my Scala chops were just not up to it (barely are
with Squeryl). There are about 3 other database integration packages
for Scala now. So I was wondering, why Anorm? Is it really just an
in-house project?
I could see the same argument being made for the templating engine,
but that is much more tightly integrated with the rest of the project.
Anyway, in general sounds good..
Oh one other question.. you mention having good Java idiomatic APIs,
will there be Scala idiomatic API's as well? Seems like a lot of work
to maintain them both and keep them in sync. Currently the Scala
plugin is lagging and it has a very partial API retool.
Alan
Sadache Aldrobi
There has been some mention of reinventing the wheel and when I
started using the Scala plugin one thing lit up a warning sign for me
and that was Anorm.
I'm using Squeryl on my current project and I like it a lot. I looked
at Scala-Query and my Scala chops were just not up to it (barely are
with Squeryl). There are about 3 other database integration packages
for Scala now. So I was wondering, why Anorm? Is it really just an
in-house project?
I could see the same argument being made for the templating engine,
but that is much more tightly integrated with the rest of the project.
Anyway, in general sounds good..
Oh one other question.. you mention having good Java idiomatic APIs,
will there be Scala idiomatic API's as well? Seems like a lot of work
to maintain them both and keep them in sync. Currently the Scala
plugin is lagging and it has a very partial API retool.
def list(page:Int, sort:String) = {
val p = if(page > 0) page else 1
Secured(p != 42) {
Cached(p, sort) {
Action {
println("Listing page " + p + " using " + sort)
Html(views.html.list(p, sort).toString)
}
}
}
public class JavaApplication extends Controller {
@Cached
public static Result index() {
System.out.println("REQUEST -> " + request());
String url = routes.JavaApplication().hello(5, "World").url();
return Html(javaIndex.apply(url));
}Alan
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
www.sadekdrobi.com
ʎdoɹʇuǝ
Alison Winters
thinking long and hard about the right way forward for Play.
Like some other group members, I also feel some trepidation about
moving so much toward Scala. Although I know it is gaining acceptance
in the real world, Java, Python and even Groovy feel like more
widespread technologies. Also they are all easy to understand, being
standard object-oriented/procedural languages. Scala is a big paradigm
shift for most developers, and I think that will definitely discourage
community contributions. I know you guys will write a good Java API to
access the front end, but I hope module developers and other
"hardcore" contributors will still be able to add features and
functionality without having to delve too deeply into Scala.
I do like the direction overall, though. Although I've never used SBT,
it does seem much tidier to use it for build and deployment (vs custom
Python scripts). I think this is going to be the most important
rationale for upgrading current apps in production. Everyone wants
nicer deployment :) I also like the conciseness of the ASP.NET/Razor-
style template syntax, even if it does mean having to use weird Scala
for loops and closures to do things. I am very familiar with the
quirks of Hibernate, but I think using EBean by default will be a
great advantage for developers new to Java, and it will probably
perform well enough for most projects anyway. It all looks very
exciting.
As a user with Play running in production, I am very interested in how
you will be continuing to support the 1.x branch. I don't expect any
new features now that you are focused on 2.0, and I know you will
probably only be working on bugs that actually break things (rather
than those that are simply annoying), but can we see some kind of
roadmap for those? It would be good to know what is planned to be
addressed for "1.4" and what is just going to be abandoned in the 1.x
tree and targeted for 2.0.
Also the announcement page on the web site looks really cool, nice
coding :)
Alison
Ivan Meredith
make them independant libs were possible. A good example is the WS
library, its brillant, I wish I could use it in legacy java apps when
I have to talk to new rest end points. Another is anorm, if I had
anorm as a jar today, it would simplify a migration of a app I
maintain to play. :)
> --
> Guillaume Bort, http://guillaume.bort.fr
>
Xuefeng Wu
Is there possible that the typesafe team will contribute or support play!2 and let things happen early?
Christian Koch
v6ak
%someUglyChars0, ...)
On Sep 7, 2:05 pm, Ivan Meredith <i...@ivan.net.nz> wrote:
> I imagine you just need to make a windows version ofhttps://github.com/playframework/Play20/blob/master/play
>
> On 8 September 2011 00:02, Rakesh Waghela <javain...@gmail.com> wrote:
>
>
>
> > Windows is not supported yet ?
> > --
> > You received this message because you are subscribed to the Google Groups
> > "play-framework" group.
Aishwarya Singhal
and keep up the good work!
Is there any place I could post some of my wish list (apart from
what's already included in 2.0) ?
PS: Developing with the play-scala support seems to be slower than the
Java one because, if I remember correctly, sbt holds on to a bit of
memory as the code is compiled on the fly. With sbt coming in
mainstream play, is something being done to ease that too (say run sbt
in a separate process and may be have inter process communication) ?
Best regards
Aishwarya
v6ak
I've one question. I've currently a Play!-Scala project with some
Maven-Scala modules. Now, I've to call mvn install on the parent Maven
project, clean a part of Ivy cache (provided that the version has not
been changed), call play modules --sync in the Play! project directory
and restart the Play! app.
If I switch to SBT, how much would it simplify these steps?
* The Play app would probably be able to be moved to a SBT module.
* Since SBT is based on Ivy, there would be no need for cleaning Ivy
cache. (OK, I can do this also in 1.2.* branch.)
* Would I have to restart the Play! app?
* I probably would not need to sync dependencies.
* When downloaded the app from source, would there be a simple command
that would compile everything, test everythingg and run the Play app?
Regards,
Vít Šesták 'v6ak'
On Sep 8, 3:11 am, Ivan Meredith <i...@ivan.net.nz> wrote:
> One request I have is that as you port parts over to play2, please
> make them independant libs were possible. A good example is the WS
> library, its brillant, I wish I could use it in legacy java apps when
> I have to talk to new rest end points. Another is anorm, if I had
> anorm as a jar today, it would simplify a migration of a app I
> maintain to play. :)
>
>
> read more »
Guillaume Bort
> you will be continuing to support the 1.x branch. I don't expect any
> new features now that you are focused on 2.0, and I know you will
> probably only be working on bugs that actually break things (rather
> than those that are simply annoying), but can we see some kind of
> roadmap for those? It would be good to know what is planned to be
> addressed for "1.4" and what is just going to be abandoned in the 1.x
> tree and targeted for 2.0.
Nothing is decided yet, but we will surely not backport important
changes like the new build system, scala support or the type safe
routing and template engine to the 1.x serie.
However it is likely than we will try to port the existing Groovy
template or the Hibernate based Model engine to the 2.x serie (after
the 2.0 release) to ease the migration. But not as standard default
components.
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>
--
Guillaume Bort, http://guillaume.bort.fr
grandfatha
Scala module and the consequence of having to build to separate APIs,
which essentially means having to maintain two different web
frameworks.
I think it is a good idea to unify both in a 2.0 release, because it
is unhealthy to create two different frameworks under the same name.
I hope that while building 2.0, Play#s core developers will remember
that ...
(1) simplicity
(2) developer usability
(3) general feeling of enjoying the use of the tool / APIs
is what brought Play to where it is right now. We dont need another
Lift just for the sake of jumping on the Scala bandwagon. Play has
become big, because it is essentially Django/Rails for the Java world.
If Play 2.0 does not support (1), (2) and (3) in the same way Play 1.0
supported it, I think it would mean its downfall and its usage only
among Scala enthusiasts, which would be a pity since it is making its
move right now into more conservative development shops and becoming
mainstream since it is just plain Java.
tl;dr : Dont fuck up the developer usability of Play by switchting so
much to Scala, please!
Rakesh Waghela
much to Scala, please!
Daryl
> I would like to caution all the Play maintainers against too much modularity. If the seams
> show a lot then the barrier to entry rises and a main benefit (and appeal) of the framework is lost.
needs to have the modularity to swap modules/plugins in and out. This
has become an increasingly common request on Play 1.0, and it has to
be considered important for this functionality to be included in such
a major rewrite. The trick will be to select the best defaults and
make the ability to create a new app and run straight away without any
configuration as in the current version. Swapping out modules to meet
particular needs will be a conscious decision on the part of a more
experienced developer.
Selecting the best defaults will also be an interesting decision. The
current JPA/groovy templates have a fairly easy learning curve,
allowing beginners to just dive in. If the something more complicated
is bundled as default, it could put beginners off. Maybe there should
be different bundled versions that allow you to get up and running
quickly with different options. Its a fine line between introducing
beginners/ease of use and allowing more experienced users to configure
things as needed.
Interesting times ahead :)
Xuefeng Wu
As the rails which bring new developer into Ruby world.
stefaan luckermans
Owner of Thaste IT
Gasthuisvest 30
If play!2 is easy and productivity enough, It may could interest developer who don't know scala or even java.
As the rails which bring new developer into Ruby world.
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/GVHW1bbtw1sJ.
Pascal Voitot Dev
Following what stefaan said, I think people need to be reassured about the easiness of the Java Api layer to accept play2.0 based on a Scala core... They will come naturally to Scala if they need but basic java developers won't switch to Scala for sure... Some big companies are still stuck on Struts1 and to convince them to try something else, complete technology switch is generally not the best argument...
The short learning curve and the easiness are certainly the best arguments of play in the java world.
Thanks
Pascal
Ivan Meredith
Guillaume Bort
homerdoe
1-Speed of reloading(Python scripts)
2-Java
3-JPA
Although i like Scala, i just cannot understand how can someone make
some big business apps without a proper IDE for it.
Seems to me that all the advantages that made me use Play, will be
gone because the scala template and sbt are going to be slower than
the ones java have today. It wont be that easy to use a ORM(JPA)
(millions still do and will for the foreseeable future). And java will
almost be a second citizen.
To conclude, i think all the things that made me go to play will be
gone!
I just dont understand the problem people have with groovy.
Im sorry guys but play may be gone for me, just hope you reconsider
those decisions.
> >> *Owner of Thaste IT
>
> >> *Gasthuisvest 30
> >> 2500 Lier
>
> >> *Cell phone: **+32 472 103 204*
> >> *mailto: <stefaan.luckerm...@thaste.org>stefaan.luckerm...@thaste.org*
> 44KViewDownload
>
> PastedGraphic-2.tiff
> 125KViewDownload
Ike
- Concerns about Scala as a language choice for new development.
- Concerns about adding complexity and moving away from "Rails-like" simplicity for new users.
Sadache Aldrobi
#2 is a different story and one which I think the Play developers should consider very carefully. Developer productivity and ease of use are crucial values that should not be sacrificed. It is natural for project members to grow more sophisticated as their engagements expose them to more large and complex projects (I'm looking at you Spring Framework). But, ultimately, it is the 5 or 10 minute video demo that sells the framework to the masses.As long as developers are able to easily download the framework, create a new project with a single command and create a database-driven website with just a handful of files and easy-to-understand syntax, all with fast modify-deploy cycles then we should be OK.If we start seeing things like handle(_, _, _, _, _) as common method signatures then I think we'll be in trouble :)
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/mWn_1896EwsJ.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
www.sadekdrobi.com
ʎdoɹʇuǝ
Erwan Loisant
On Thu, Sep 8, 2011 at 17:46, homerdoe <ozie...@gmail.com> wrote:
> What attracted me for Play was the folowing things:
>
> 1-Speed of reloading(Python scripts)
> 2-Java
> 3-JPA
1. The speed of reloading is not linked to the use of python. We used
Python because we didn't want to launch a JVM for each command; this
issue is fixed with the use of the sbt console: you can open a
console, run several commands and it will be in the same. Reloading of
Java code will NOT be slower. Compiling Scala code is slower than Java
code, but if you choose to code in Java it won't be a problem
2. Java will not be a second citizen. We understand nobody likes
Scala, and Java has its own advantages. Both languages will be equally
supported. What language is used to write the core doesn't matter,
it's just an implementation detail.
3. While Hibernate will not be included, we will include Ebean
(http://www.avaje.org/) which has an API very close to JPA: it uses a
lot of annotations from the javax.persistence.* namespace. It's
actually more in the spirit of Play because it natively support the
explicit save. In Play 1.0, we had to patch Hibernate to get this
behavior. Of course, if you really want to use Hibernate, nothing will
prevent you from importing it to your project.
> Although i like Scala, i just cannot understand how can someone make
> some big business apps without a proper IDE for it.
It's a matter of taste, but if you're an IDE guy you should check out
Typesafe's Scala plugin for Eclipse: http://www.scala-ide.org/
They're throwing a lot of ressources to the project, it's already
pretty good and we can expect it to get better in the future.
> Im sorry guys but play may be gone for me, just hope you reconsider
> those decisions.
You're free to use whatever framework you like, but I'm confident Play
2.0 will appeal to the same Java developers who liked Play 1, and not
just people interested in Scala.
--
Erwan Loisant
v6ak
> Although i like Scala, i just cannot understand how can someone make
> some big business apps without a proper IDE for it.
as Java support, it is good.
BTW: I'll probably do also something in Java (a Java project
contribution, I can't do it in Scala) and I probably will not go back
to Eclipse...
Brian Nesbitt
Ike
2. Java will not be a second citizen. We understand nobody likes
Scala, and Java has its own advantages. Both languages will be equally
supported. What language is used to write the core doesn't matter,
it's just an implementation detail.
Ike
That's one of the reasons for which we wanted to announce with a preview: To reassure users regarding our intentions. Download the preview and simply use the plain old "play new"
Guillaume Bort
> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/kEQVD7D-uzYJ.
homerdoe
play wont be as near as interesting as it is today for the average
java crowd(i dont consider myself one but hope to sell play to people
who are).
Regarding the python scripts, ive used grails and glassfish and think
that the reloading time could improve, so i have a natural fear of jvm
things that need to be fast.
I dont know scala that much, so i will be watching closely the
development of the new version, im sure the development team is aware
of those things and lets see what the future unfolds...
Pascal Voitot Dev
I prefer your version ;)
Steven Elliott Jr
Steven Elliott Jr
> I wouldn't say that "nobody likes Scala" :) I'm not surprised that not many are willing to learn a new language, but that's hardly and excuse for dismissing it.
I happen to love Scala but where I work it's hard to introduce a new language; I am waiting to make my pitch for a Scala app when 2.0 becomes an official release. In the meantime I have been diligently trying to port some Java apps over to Scala because I find it to be extremely powerful and showing people a working app is the best marketing tool. Despite the Scala resistance in my organization, the good news is that even though most engineers are not ready to switch to Scala, at least they are using the Play! Framework which is a pleasure to work in. So, it is definitely important to keep the Java support baked in for the old school peeps. Great job to all the devs that make Play! a reality!
Erem Boto
made but also the way they've chosen to present their choices to the
community. In fact, Play! is the best-run open source project I've
ever had the pleasure of working with.
I have two issues to bring up.
====
(1) How can we access the developer's mailing list, or an IRC channel
if it exists? I would like to contribute to the project by writing
scaladocs, but doing so will require asking the right people the right
questions and I don't want to flood the users' forum.
(2) I love Scala, but Scala library developers tend towards the
readability-destructive habit of creating punctuation-based DSLs for
each of their libraries. Not every library needs a DSL, and not every
DSL needs to use punctuation. If you ever consider putting operators
like '**', '<#', '<<?', '>>?', etc into the code base _please_
reconsider.
I wouldn't feel the need to bring it up, but Scala's semi-mindfuck
parser combinator syntax that unfortunately features prominently in
Anorm suffers from this syndrome and I would hate to see it spread
into other areas of the developer-facing APIs.
There's a pretty good conversation of it on Proggit. Odersky even
weighed in on the topic.
http://www.reddit.com/r/programming/comments/k5d4v/yes_virginia_scala_is_learnable/
====
Thanks for all the hard work, Playboys. You've made an amazing
product.
Erem
Ike
Thanks for all the hard work, Playboys. You've made an amazing
product.
Ivan Gallo
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/ZMaYCShefbsJ.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
Ivan Gallo P
SCJP
cel 3008165846
Ian Lawrence
> Play has
> become big, because it is essentially Django/Rails for the Java world.
+1
Exactly why we got into Play (along with the simplicity of the python
commands and the fact that we do not need to use an IDE to develop the
java projects we seem to inherit constantly).
My personal opinion is try to make 1.2.2/3 even simpler for non Java
developers to use and more Django/Rails like rather than move to
another programming language and build system. What advantages exactly
does this increased complexity bring to Play?
Regards
Ivan Meredith
doesn't automatically make it complex), but the apis for a framework
are the important thing. Play 1.x core is pretty complex too btw.
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
Ivan Meredith
to learn scala. I'm sure Japid will be ported at the very least, so
you wont even have to learn how to do the scala templates (which are
very simple, much easier than learning scala)
Ivan Meredith
far out of the standard to create a platform that is awesome for end
user developers to use. Do you really think they want this to change?
In play 1.1 -> 1.2 its got easier to manage, with evolutions and
dependancies.
Obviously I personally like where this is going, however even if you
have doubts, I suggest looking at the sample app (yes this is a java
controller https://github.com/playframework/Play20/blob/master/samples/kiki/app/controllers/JavaApplication.java
), and then just wait awhile and see where it goes.
Hristo Deshev
(2) I love Scala, but Scala library developers tend towards the
readability-destructive habit of creating punctuation-based DSLs for
each of their libraries. Not every library needs a DSL, and not every
DSL needs to use punctuation. If you ever consider putting operators
like '**', '<#', '<<?', '>>?', etc into the code base _please_
reconsider.
Turar
using Play (just finished going through the tutorial and sample app).
Prior to that, I went through a process of choosing between Play,
other Java frameworks, Django, and Rails, and Play came out on top.
So now I'm a bit confused and would like some advice. Do I proceed
with Play 1.2.3 for this brand new project, and then hope to migrate
to 2.0 early next year, or just forget the whole idea, and go with,
say, Rails for this project, and re-evaluate Play once 2.0 release is
out and has traction? From what I understood so far, the current
recommendation is to not even bother with migrating from 1.x to 2.x,
and just keep developing in 1.x, as it still will be supported. Is
that right? While that makes sense, it's not the most exciting thing
if starting a new project today and knowing there's a whole new
direction already in the works.
Thanks!
Dirk
I'm excited to see what comes next..
felipeko
Play 2.0 will be easy. The most important change that will make
migration to Play 2.0 difficult is the new type safe template engine.
But if you are already using it it will be easy.
Everson Alves da Silva
Rakesh Waghela
grandfatha
> we even got Unicode art!) DSL's people come up with. Casting another vote
> for "please don't go there."
For me, even some of the Anorm code is not really aesthetically
pleasing:
def prevNext = {
SQL("""...some..sql...."""
).on("date" -> postedAt).as(
opt('pos.is("prev")~>Post.on("")) ~
opt('pos.is("next")~>Post.on("")) ^^ flatten
)
} (taken from scala-module/samples-and-tests/yabe/app/models.scala)
This is not the API of a Rails/Django inspired framework IMO and I
dont want that to happen to the rest of Play, that is all I am saying.
T.J. Crowder
> For me, even some of the Anorm code is not really aesthetically
> pleasing:
>
> def prevNext = {
> SQL("""...some..sql...."""
> ).on("date" -> postedAt).as(
> opt('pos.is("prev")~>Post.on("")) ~
> opt('pos.is("next")~>Post.on("")) ^^ flatten
> )
>
> } (taken from scala-module/samples-and-tests/yabe/app/models.scala)
https://github.com/playframework/play-scala/blob/master/samples-and-tests/yabe/app/models.scala#L31-49
I realize I don't yet "speak" Scala, but PLEASE don't make Play's core
like that. Remotely. At. All. 20+ years of professional experience
_scream_ "maintenance nightmare" at me. (And I'm not just -- or even
primarily -- a Java-head, in my time I've done paid professional work
in 80x86 assembly, C, C++, VB/VB.Net/VBScript, Pascal, Java,
JavaScript, C#, and probably a dozen others.)
Again, I don't "speak" Scala yet -- but that's part of the point, and
that syntax is clearly a huge barrier to entry. There are hundreds of
thousands, if not millions, of people au fait with Java who can read
and understand and contribute to Play. There are currently very few au
fait with Scala, and if David Pollak is right[1][2] (even if he comes
off a bit elitist about it, particularly in [2]), there will continue
to be very few for many years to come.
Contrast the above with:
public Post previous() {
return Post.find("postedAt < ? order by postedAt desc",
postedAt).first();
}
public Post next() {
return Post.find("postedAt > ? order by postedAt asc",
postedAt).first();
}
From:
https://github.com/playframework/play/blob/master/samples-and-tests/yabe/app/models/Post.java#L50-56
[1] http://goodstuff.im/yes-virginia-scala-is-hard
[2] http://goodstuff.im/scala-use-is-less-good-than-java-use-for-at-l
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com
Jonas
Thanks for this and Congratulations to a great framework.
I have used Play with both Java and mostly Scala for some months now.
I really like the framework.
The things that attracted me was:
+ Netty as server and the performance
+ Type safety of Java and Scala
+ Simplicity of MVC and Ruby on Rails like
+ Good tutorials and documentation
+ Support for WebSockets
After some experience with both Java and Scala:
+ I really liked the type safe and easy to use Scala templates
- I wanted to use WebSockets with the Scala module
- Anorm, I started to use it, it looked good, but it didn't have good
support for PostgreSQL
- Anorm, I need transactions for Order+multiple OrderItems, so I used
JDBC for this.
- This is minor problem, but it takes some time for a bigger Scala app
to compile.
- Not a play issue, but the Scala support in Eclipse wans't good. I
could change to IntelliJ, but it's a big step to switch many projects
to another IDE that I don't know yet.
Play 2:
+ It sounds like a dream with type safe routing
+ It sounds like a dream with Akka, I have used it in a Java project
and I have used Erlang before
+ Sounds like you are designing for WebSocket support for Scala,
great!
+ Better integration with Scala and keeping good support for Java
Thanks a lot for a great framework
Guillaume Bort
> commands and the fact that we do not need to use an IDE to develop the
> java projects we seem to inherit constantly).
If will not change in Play 2.0. You will use the same
new,run,start,test commands to manage your application. The fact that
we use SBT under the hood instead of python scripts will not change
anything on the final UI.
And like in Play 1.x you will be able to work without IDE. Play will
just recompile and reload any change when you hit reload.
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>
--
Guillaume Bort, http://guillaume.bort.fr
Guillaume Bort
https://gist.github.com/1203802
Really no one can say that a Java developer will be lost reading or
writing this stuff.
--
Guillaume Bort, http://guillaume.bort.fr
Pascal Voitot Dev
2.0 will arrive progressively and you will be able to prepare your migration in the same way...
The only doubt I would have is against the Groovy templating which won't be kept in 2.0.
So I would advise going directly to Scala template or Scalate or Japid or Cambridge.
Regards
Pascal
Rakesh Waghela
ogregras
T.J. Crowder
> Here is a type safe template as seen by a Java developer:
>
> https://gist.github.com/1203802
>
> Really no one can say that a Java developer will be lost reading or
> writing this stuff.
relate to the _framework code_ and whether people can readily
understand and contribute to it (and samples, etc.). I don't see any
issue with the _templates_ you're citing, regardless of one's
linguistic leanings. You have to learn any templating system, that one
looks just as comprehensible as any other. Not so much that code from
the Scala yabe sample quoted by grandfatha (yikes!), and the "ASCII
art DSL" concerns raised by Hristo Deshev. I would hate to see Play's
framework code look like that.
grandfatha
Guillaume Bort wrote:
> Here is a type safe template as seen by a Java developer:
>
> https://gist.github.com/1203802
>
> Really no one can say that a Java developer will be lost reading or
> writing this stuff.
regarding your hard work and effort. It is just that some of the Scala
code out there (even part of anorm) can be a real threat to the
popularity of the framework. And I would hate to see such a
masterpiece go down in flames because of stupid things like e.g. the
overuse of symbolism within the scala world.
Sadache Aldrobi
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
www.sadekdrobi.com
ʎdoɹʇuǝ
Pascal Voitot Dev
Scala has a powerful syntax... but as all the powerful things, if you aren't reasonable and self-disciplined, you can become incomprehensible... But I know coders who write weird Java also :)
Ike
Erem Boto
library is a scala standard lib, therefore all Scala developers will/
should be familiar with its syntax." But I hope the continued
controversy around Anorm's syntax has communicated to you that this
assumption may not be sound or reasonable.
For example (and I think I'm typical here). Only in researching how to
use Anorm did I discover _what_ a Parser Combinator is, which took me
down a deep hole learning about parsers, parser-generators and context-
free grammars. When I was feeling more comfortable, I searched for the
Parser Combinator scaladoc and found a perfect example of an
inscrutable API. For example, look at the three adjacent methods ^?,
^^, and ^^^. Or the methods ~ and ~!, none of which at their face give
any contextual information about the method's purpose. That lack of
contextual information in the method name butchers readability and
makes any code that uses the library heavily look frustrating and
undecipherable. Which is why the Anorm code stands in jarring contrast
to the rest of the Play! APIs and docs which are dead-simple for
anybody familiar with the relevant domains (HTTP, HTML, SQL, etc).
At any rate, I'm not complaining about the learning process; it was
all useful knowledge. But should this level of research really be
necessary just to understand the options for extracting data from a
result set? I think most of us Play! developers would argue otherwise.
To reiterate and bring this back to the topic, I love the move to
Scala but would hate to see more Play! APIs seduced into employing
punctuation operators and thereby murdering readability.
Erem
On Sep 9, 5:43 am, Sadache Aldrobi <sadek.dr...@gmail.com> wrote:
> Just to clarify here, Anorm did NOT invent a syntax, a DSL or operators. It
> implements standard Scala Parsers Combinators and it is targeted for Scala
Sadache Aldrobi
> Just to clarify here, Anorm did NOT invent a syntax, a DSL or operators. It implements standard Scala Parsers Combinators
Granted, and I understand your rationale: "The Parser Combinator
library is a scala standard lib, therefore all Scala developers will/
should be familiar with its syntax." But I hope the continued
controversy around Anorm's syntax has communicated to you that this
assumption may not be sound or reasonable.
To reiterate and bring this back to the topic, I love the move to
Scala but would hate to see more Play! APIs seduced into employing
punctuation operators and thereby murdering readability.
punctuation operators and thereby murdering readability.
www.sadekdrobi.com
ʎdoɹʇuǝ
Erem Boto
frustration and way too harsh.
I also do not wish to deride what you've done with Anorm, because
after doing the homework I described in my previous post I can
definitely appreciate the library's versatility.
Point is that change is both awesome and scary, and I'd love to see
Play! come out of this great change as the undisputed king of JVM web
frameworks, if it isn't there already =)
Erem
Sadache Aldrobi
>> I wouldn't call it "murdering readability" anyway.
>
> Apologies! Looking back on it, that wording was chosen out of
> frustration and way too harsh.
>
> I also do not wish to deride what you've done with Anorm, because
> after doing the homework I described in my previous post I can
> definitely appreciate the library's versatility.
>
No problem.
> Point is that change is both awesome and scary, and I'd love to see
> Play! come out of this great change as the undisputed king of JVM web
> frameworks, if it isn't there already =)
Perfect )