Пожалуй, самая поразительная вещь о Play! Фреймворк состоит в том, что его самое большое преимущество перед другими фреймворками для разработки веб-приложений на Java не вписывается в аккуратный список возможностей и становится очевидным только после того, как вы его использовали для создания чего-либо. Это преимущество юзабилити.
Обратите внимание, что удобство использования отличается от функциональности. В дальнейшем я не говорю, что вы не можете сделать это в каких-то других рамках: я просто заявляю, что в Play это проще и приятнее! Я должен подчеркнуть это, потому что гики часто имеют полное слепое пятно для удобства использования, потому что им нравится находить сложные вещи и недооценивать ценность вещей, которые просто работают.
Автор веб-разработчиков для веб-разработчиков
Первый намек на то, что здесь происходит что-то другое, это когда вы впервые услышите, что Play! фреймворк «написан веб-разработчиками для веб-разработчиков», нетрадиционное позиционирование, которое ставит принципы и соглашения в Интернете на первое место, а на второе — на Java. Именно это означает, что Play! Фреймворк в большей степени соответствует архитектуре Всемирной паутины W3C, чем соглашениям Java Enterprise Edition (Java EE).
URL для перфекционистов
Например, Play! Фреймворк, как и другие современные веб-фреймворки, обеспечивает первоклассную поддержку произвольных «чистых» URL-адресов, чего всегда не хватало в Servlet API. Не случайно, что на момент написания URL-адреса Struts для перфекционистов , набор обходных путей для веб-инфраструктуры Struts 1.x на основе API Servlet, остается третьей по популярности из 160 статей на www.lunatech- research.com несмотря на то 2005 статьи о предыдущем поколении веб — технологии Java.
В основанных на сервлетах инфраструктурах Servlet API не предоставляет полезной поддержки маршрутизации URL; Основанные на сервлетах инфраструктуры настраивают web.xml для пересылки всех запросов сервлету с одним контроллером, а затем реализуют маршрутизацию URL-адресов в структуре с дополнительной настройкой. На этом этапе не имеет значения, был ли API сервлета когда-либо предназначен для решения проблемы маршрутизации URL-адресов и потерпел неудачу из-за недостаточной мощности, или же он был предназначен для API более низкого уровня, в котором вы не создаете веб-приложения. непосредственно. В любом случае, результат один и тот же: веб-фреймворки добавляют дополнительный слой поверх Servlet API, сам по себе слой поверх HTTP.
Играть в! объединяет веб-инфраструктуру, HTTP API и HTTP-сервер, что позволяет ему реализовывать одно и то же напрямую, с меньшим количеством уровней и конфигурацией маршрутизации с одним URL. Эта конфигурация, как и в Groovy и Cake PHP, отражает структуру HTTP-запроса — HTTP-метод, URL-путь, а затем отображение:
# Play! 'routes' configuration file…
# Method URL path Controller
GET / Application.index
GET /about Application.about
POST /item Item.addItem
GET /item/{id} Item.getItem
GET /item/{id}.pdf Item.getItemPdf
В этом примере имеется более одного контроллера. Мы также видим использование параметра URL URL в последних двух URL.
HttpServletRequest
Другим примером является класс Play! Http.Request , который намного проще, чем интерфейс HttpServletRequest API Servlet . Кроме того, Play! использует класс, в котором Java EE 6 использует соглашение Java EE об использовании интерфейса. Этот интерфейс также разделен между HttpServletRequest и более универсальным интерфейсом ServletRequest . Это разделение может быть полезно, если вы хотите использовать сервлеты для других целей, кроме веб-приложений, или если вы хотите разрешить маловероятную возможность изменения веб-протокола, но для большинства из нас это просто несущественная сложность. Другими словами, в настоящее время Servlet API всегда используется с фреймворком, потому что он неоптимизирован для создания веб-приложений, для чего все мы на самом деле его используем. Играть в! исправляет это.
Лучшее удобство использования не только для нормальных людей
Еще один взгляд на идею Play! Для веб-разработчиков стоит подумать, как веб-разработчик может по-разному подходить к разработке программного обеспечения по сравнению с разработчиком на Java EE. Когда вы пишете программное обеспечение, что является основным интерфейсом? Если вы веб-разработчик, основной интерфейс — это пользовательский веб-интерфейс, построенный на HTML, CSS и (все чаще) JavaScript. Разработчик Java EE, с другой стороны, может рассматривать свой первичный интерфейс как API Java или, возможно, API веб-служб, для использования другими уровнями в системе.
Это различие имеет большое значение, потому что интерфейс Java предназначен для использования другими программистами, в то время как интерфейс веб-интерфейса пользователя предназначен для использования непрограммистами. В обоих случаях хороший дизайн включает в себя удобство использования, но удобство для обычных людей — это не то же самое, что удобство для программистов. В каком-то смысле юзабилити для всех является более высоким стандартом, чем юзабилити для программистов, когда речь идет о программном обеспечении, потому что программисты могут лучше справляться с плохой юзабилити. Это немного похоже на кухонную утварь Good Grips : хотя изначально она была разработана для удобства использования пожилыми людьми с артритом, оказывается, что удобство хранения инструментов удобнее для всех пользователей.
Игра! Фреймворк отличается тем, что удобство использования, которого вы хотите достичь в своем веб-приложении, присутствует в самой фреймворке. Например, веб-интерфейс для таких вещей, как документация фреймворка и сообщения об ошибках, отображаемые в браузере, более удобен в использовании. Аналогичным образом, вывод на консоль сервера позволяет избежать страниц, полных неактуальной регистрации и страниц следов стека при возникновении ошибки, оставляя более целенаправленную и более полезную информацию для веб-разработчика.
$ play run phase
~ _ _
~ _ __ | | __ _ _ _| |
~ | '_ \| |/ _' | || |_|
~ | __/|_|\____|\__ (_)
~ |_| |__/
~
~ play! 1.0, http://www.playframework.org
~
~ Ctrl+C to stop
~
Listening for transport dt_socket at address: 8000
10:15:58,629 INFO ~ Starting /Users/peter/Documents/work/workspace/phase
10:16:00,007 WARN ~ You're running Play! in DEV mode
10:16:00,424 INFO ~ Listening for HTTP on port 9000 (Waiting a first request to start) ...
10:16:11,847 INFO ~ Connected to jdbc:hsqldb:mem:playembed
10:16:13,448 INFO ~ Application 'phase' is now started !
10:16:14,825 INFO ~ starting DispatcherThread
10:16:48,168 ERROR ~
@61lagcl6i
Internal Server Error (500) for request GET /application/startprocess?account=x
Java exception (In /app/controllers/Application.java around line 41)
IllegalArgumentException occured : Person not found for account x
play.exceptions.JavaExecutionException: Person not found for account x
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:200)
at Invocation.HTTP Request(Play!)
Caused by: java.lang.IllegalArgumentException: Person not found for account x
at controllers.Application.startProcess(Application.java:41)
at play.utils.Java.invokeStatic(Java.java:129)
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:127)
... 1 more
Попробуйте представить себе веб-приложение JSF, создающее трассировку стека. На самом деле, играть! идет дальше: вместо отображения трассировки стека, веб-приложение показывает последнюю строку кода в приложении, которая появляется в трассировке стека. В конце концов, что вы действительно хотите знать, так это то, где что-то пошло не так в вашем собственном коде .
Этот вид юзабилити не происходит сам по себе; игра! Фреймворк прилагает значительные усилия, чтобы отфильтровать дублирующуюся и нерелевантную информацию и сосредоточиться на том, что необходимо.
Качество в деталях
В игре! В основе структуры оказывается, что большая часть качества заключается в деталях: они могут быть мелочами по отдельности, а не крупными важными функциями, но в целом они дают более удобный и продуктивный опыт разработки. Теплое чувство, которое вы получаете при создании чего-либо с Play! это отсутствие разочарования, которое обычно возникает в результате борьбы с рамками.
Мы рекомендуем вам зайти на сайт http://www.playframework.org/ , загрузить последний бинарный выпуск и потратить полчаса на обучение .
— старший разработчик программного обеспечения в Lunatech Research .