На этой неделе я нахожусь в Jfokus в Стокгольме, Швеция. Вчера вечером, после веселого разговора с оратором, я встал сегодня утром и выполнил свои презентации и демонстрацию перед посещением конференции. Первая сессия, на которой я присутствовал, была презентация Play Framework 2.0 Питера Хилтона Ниже приведены мои заметки из этого выступления.
Питер — старший веб- разработчик, а не Java-разработчик. Его первый слайд гласит следующее:
«Play приносит в JVM высокопроизводительную веб-разработку с безопасными типами».
Новые функции в Play 2.0: безопасность типов, синтаксис шаблонов, проверка во время компиляции и асинхронное программирование HTTP. Java, Scala — используемый вами язык менее важен, чем тот факт, что Play является веб- фреймворком. Это полнофункциональный фреймворк, в котором есть все необходимое для создания веб-приложения. Игра фокусируется на HTTP и не пытается его скрыть. Он создан с помощью веб — разработчиков для веб — разработчиков.
С Play, кнопка Назад просто работает. Ваш веб-фреймворк не должен ломать первую кнопку на панели инструментов вашего браузера. Кнопка «Перезагрузить» также работает: внесите изменения, нажмите «Перезагрузить», и ваши изменения (даже в классах Scala) будут показаны. Вы разрабатываете URL-адреса и можете использовать «чистые» URL-адреса. DX (Developer eXperience) — новый термин Питера. Юзабилити имеет значение: как разработчик, вы заслуживаете структуру, которая обеспечивает хороший опыт.
Игра не борется с HTTP или браузером. Это без сохранения состояния и HTTP-ориентированных. Несколько лет назад казалось хорошей идеей попытаться сохранить состояние на сервере. Это звучало как хорошая идея, но на практике это действительно плохая идея — особенно для таких вещей, как кнопка «назад». Play соответствует веб-архитектуре HTTP без сохранения состояния.
Как разработчик Java EE, разработчики PHP и Rails издевались над нами годами. Как и Дед Мороз, Питер слышал о перезагрузке класса, но на самом деле он этого не видел. Перезагрузка кода является наиболее важной частью DX и связана с достижением высокой производительности в веб-разработке.
URL тоже хотят быть любимыми. Архитектура REST предназначена не только для API веб-служб. Когда у вас есть чистые URL-адреса, вы можете твитнуть их, публиковать и отправлять по электронной почте.
«Вы должны быть супер-героем, чтобы успешно использовать некоторые веб-фреймворки». Они показывают вам пустой экран в браузере, и вы должны посмотреть на трассировку стека вашей консоли, чтобы понять это. С Play, ошибка отображается в вашем браузере, и вы можете увидеть точную строку, на которой это происходит.
В Play 1.x было много волшебства и много улучшений байт-кода во время выполнения. Это позволило API быть намного лучше, чем традиционные API Java. Тем не менее, это вызывало проблемы, когда пользователи просматривали расширенный источник, а также вызывало проблемы в IDE. В Play 2.0 сам фреймворк реализован в Scala. Scala устраняет необходимость в значительном улучшении байт-кода. В API меньше «волшебства» и странностей. Код, который вы видите в IDE, — это код, который выполняется. Исходный код Scala не обязательно сложнее для чтения. 1.x имел довольно волосатый Java-код, и вы могли сказать, когда копались в нем. Особенно, когда вы были глубоко в исходном коде и увидели, что многие комментарии были на французском языке.
Play 2.0’s template system is based on Scala. It’s similar to the lightweight template syntax in Play 1.x. Templates are compiled into class files for run-time speed. For example:
@(products: Seq[Product])
<ul>
@for(product <- products) {
<li>@product.name</li>
}
</ul>
@summary(products)
We used to think XML-based templates were great, but it turns out it’s a terrible idea. Mostly because you end up having to invent an expression language to create valid XML (to avoid putting XML in your HTML attributes). With Play 2.0’s templates, you can define tags in your templates as regular Scala methods.
@display(product: models.Product) ={
<a href="@routes.Product.details(product.id)">@product.name</a>
}
@for(product <- products) {
@display(product)
}
The compile-time checking in Play 2.0 is not just for Java and Scala classes. It also compiles your HTTP routes file (which maps requests to controller actions). Furthermore, it compiles your templates, JavaScript files (using Google Closure Compiler), CoffeeScript files and LESS stylesheets.
Play supports modern web development. It’s designed to work with HTML5, but there’s no constraints on HTML output. It’s front-end developer friendly and has great DX. UI components belong in the client, e.g. jQuery UI. It also has built-in support for improvements to CSS (LESS) and JavaScript (CoffeeScript).
A few years ago, it seemed like a really good idea to hide JavaScript from the web developer. Web frameworks used to say «You don’t need to see the JavaScript or the HTML, we’ll handle generating your components for you.» Now, if you’re building a web application and you don’t know any jQuery, you doing it the hard way. You should learn how to work with front-end developers or learn how to do it yourself. And make sure your web framework allows this sort of development.
The future of web programming is asynchronous. You’ll perform simultaneous web service requests. You’ll process streams of data, instead of filling up memory or disk. You’ll publish real-time data and have predictable and minimal resource consumption. In the long term, this changes everything. The future of the web is real-time and asynchronous. With Play 2.0, it’s not just another feature, it’s a fundamental aspect of the architecture. Play’s internal architecture uses a reactive model based on Iteratee IO.
In summary, use Play 2, use HTML5, deploy to the Cloud. There’s two forthcoming books on Play (both from Manning) and Play 2.0 RC1 will be released today.
Я думаю, что Питер хорошо суммировал новые функции в Play 2.0, особенно то, как работают шаблоны. Мне понравился его акцент на HTTP и то, как Play использует браузер (обратно, перезагрузка и консоль). Мне понравился его юмористический стиль речи, и я согласен с его акцентом на том, что навыки разработки на стороне клиента важны для современных веб-приложений. Я думаю, что Play 2.0 делает большую ставку на Scala и асинхронное программирование, но если они оправдают обман, это должна быть очень приятная веб-инфраструктура для разработки.
От http://raibledesigns.com/rd/entry/play_framework_2_0_with