■full-stack？ framework
Being ‘full-stack’ is not just a question of functionality, which may already
exist as a collection of open-source libraries. After all, what’s the point of a
framework if these libraries already exist and already provide everything you need
to build an application? The difference is that a full-stack framework also provides
a documented pattern for using separate libraries together in a certain way, and
therefore confidence that a developer can make the separate components work
together. Without this, you never know whether you are going to end up with two
incompatible libraries, or a badly-designed architecture.
the common tasks are directly supported in a simple way, which saves you
time.
■J2EE and Play Framework?J2EEの設計思想
階層が多く、開発の効率は悪い。でもアキの方が楽
・The Servlet API was originally intended to be an end-user API for web
developers, using Servlets (the name for controller Java classes), and JavaServer
Pages (JSP) view templates. When new technologies eventually superceded JSP,
they were layered on top, instead of eventually being folded back into Java EE,
either as updates to the Servlet API or as a new API. With this approach, the
Servlet API becomes an additional layer that makes it harder to debug HTTP
requests. This may keep the architects happy, but at the cost of developer
productivity.
・JSF focuses on components and server-side state, which also seemed like a good
idea, and gave developers powerful tools for building web applications
it turned out that the resulting complexity and the mismatch with HTTP
itself made JSF hard to use productively.
Play provides a redesigned web stack that
doesn’t use the Servlet API and works better with HTTP and the web
■ここは違う？まだ実感出来ていないが。。。
Web frameworks for web developers are different. They embrace HTTP and
provide APIs that use HTTP’s features instead of trying to hide HTTP, in the same
way that web developers build expertise in the standard web technologies —
HTTP, HTML, CSS and JavaScript — instead of avoiding them.
In the past, none of these web frameworks were written in Java, because the
Java platform’s web technologies failed to emphasise simplicity, productivity and
usability. This is the world that started with Perl (not Lisp as some might assume),
was largely taken over by PHP, and in more recent years has seen the rise of Ruby
on Rails.
■ほしい物
・simplicity comes from making it easy to do simple things in a
few lines of code
・Productivity starts with being able to make a code change, reload the web page
in the browser, and see the result
■HelloWorld
play new "HelloWorld"
cd HelloWord
play run
=>http://localhost:9000/.
app/controllers/Application.java
==>エラーがあれば、You get a friendly compilation error。エラー表示画面
conf/application.con
＝＝＞DB接続
conf/routes.
＝＝＞GET /hello controllers.Application.hello(name:String)
template
==>app/views/hello.scala.html 言語
＝＝＞
return ok(views.html.hello.render("hello "+name +"! do you need something?"));
■ORM
JPA has more or less become the default persistence API in the Java ecosystem,
particularly in the JEE world. However, while Play doesn’t prevent you from using
JPA and/or Hibernate (or any other persistence solution, for that matter), it isn’t the
default solution. This is because a big part of the JPA spec is based on managing
entity state across e.g. requests, which is something Play has no use for, due to its
stateless nature
sessionless API.
‘refresh an entity’, or what the difference between and ‘attached’ entities and
‘detached’ entities.
Play is a rails inspired MVC framework built on the JVM. It has APIs for both Scala and Java and uses class reloading to quickly surface changes in the browser. A nice feature is the templating system that uses Scala to generate html. A template gets compiled to a Scala object and can be called from controllers, with the input type checked.