Игра против очков боли в пояснице

ИЗМЕНИТЬ
Медленное время компиляции в настоящее время в значительной степени смягчается подпроектом, поддерживающим сборку, огромную победу.

Отключились от встроенных генераторов активов (т.е. для Coffeescript и LESS) и перешли на сторонний Grunt JS; теперь изменения кода во время инкрементных сборок ограничены только временем сборки компилятора, а также не накладными расходами на воспроизведение относительно медленных активов.

ОРИГИНАЛ
В целом очень доволен Play 2.1 Scala (выпуск 9/14/2012, только до перехода на Scala 2.10); однако есть некоторые моменты боли в развитии:

1) маршрутизация: при изменении маршрута одна целая структура контроллера маршрута can перекомпилировать: не хорошо.

2) REST не поддерживается напрямую, поскольку маршрут POST /foo/bar/:idконфликты с DELETE /foo/bar/:id; то есть пути маршрута должны быть уникальными, предположительно для обратной маршрутизации.

3): с файлом scala.html за действие foo количество файлов растет быстро, что означает более медленное время сборки, больше для компиляции; дженерики не поддерживается и слепое кодирование из-за отсутствия поддержки IDE (конечно нет Механизм шаблона Scala имеет поддержку IDE на сегодняшний день, AFAIK) - особенно жесткие области.

4) инкрементная сборка работает, но ничего в этом процессе не может быть вызвано "snappy", даже простое изменение в файле scala.html на самом деле возьмите @2 секунды, что долгое время, когда вы хотите, чтобы это мгновение код обратной связи с обновлением кода.

Я знаю, что некоторые из вышеперечисленных проблем разрабатываются разработчиками Play, а также медленное время сборки также напрямую связано с версией sbt, Scala и одной собственной структурой кода. Опять же, в целом, игра была приятным опытом в области развития. Это касается боли, однако, и я хочу знать, что Поднимает к столу в этом отношении...

Лифт, похоже, использует другой подход. У лифтеров страдают от вышеуказанных предметов? Предположим, что с MVC, Lift нет, и подход к фрагментам в стиле xml не может нести то же самое время компиляции, что и некоторые из механизмов сборки за кулисами.

Каковы боли в лифте?

ОТВЕТЫ

Ответ 1

Моя собственная личная точка зрения, как кто-то, кто использовал лифт около 2 лет:

1) маршрутизация: при изменении маршрута одна целая структура контроллера маршрута может быть скомпилирован: не хорошо

С лифтом нет маршрутизации. Я думаю, что ближайшая связанная концепция будет SiteMap, и лично у меня никогда не было проблем, связанных с ее компиляцией.

2) REST, по-видимому, не поддерживается напрямую, так как маршрут POST /foo/bar/: id конфликтует с DELETE/foo/bar/: id; то есть пути маршрута должны быть уникальным, предположительно для обратной маршрутизации.

Сделав довольно много REST с помощью Lift, я могу сказать вам, что это определенно не проблема. Поддержка REST для REST действительно хороша и основана на <шаблоне шаблонов Scala, который дает вам действительно мощный безопасный способ создания веб-сервисов.

3): с файлом scala.html за действие foo количество файлов растет быстро, что означает более медленное время сборки, больше для компиляции; дженерики не поддерживается и слепое кодирование из-за отсутствия поддержки IDE (конечно нет Scala механизм шаблона имеет поддержку IDE на сегодняшний день, AFAIK), в частности жесткие области.

С Lift, HTML-код - это просто HTML (никаких специальных символов), поэтому он не учитывает время компиляции. HTML, известный как Шаблоны, обрабатывается фрагментами, которые преобразуют NodeSeq = > NodeSeq. Это может показаться сложным, но Lift имеет DSL, чтобы сделать его очень легким. Хотите добавить имя пользователя в диапазон? Если бы это выглядело так:

<span id="user-name">User name goes here</span>

В вашем фрагменте кода будет такой код:

"#user-name *" #> user.name

Вы также можете повторять элементы в своем шаблоне, например таблицу или список:


<table id="table"><tr><td class="name"></td><td class="value"></td></tr></table>

Применительно к этому:

val tuples = List(("Lift", "Is great"), ("Other web frameworks", "Eh"))
"#table" #> {
  "tr" #> {
     tuples map { case(name, value) =>
       ".name" #> name &
       ".value" #> value
     }
  }
}

Появится таблица с двумя строками, каждая из которых представит имя/значение элемента в списке.

Это, я думаю, действительно является одним из самых сильных ливрей. Шаблоны - это просто HTML, никаких символов или разметки. Вы можете работать с тем, что ваш дизайнер ставит вместе как есть, и даже дать им прямой доступ к обновлениям (в некоторых случаях так или иначе).

Снимки, с другой стороны, являются чистыми Scala, а не некоторыми языками шаблонов. Что бы вы ни делали с Scala, вы можете сделать это в фрагменте, и все это проверяется компилятором.

Также возможно (и рекомендуется) использовать фрагмент на нескольких страницах, поэтому вам необязательно нужен фрагмент на странице. Вы даже можете настроить Sitemap для использования одного и того же шаблона для нескольких страниц и передать безопасные параметры типа для фрагментов, которые страница содержит на основе запроса.

4) инкрементная сборка работает, но ничего в этом процессе не может быть вызвано "snappy", даже простое изменение файла scala.html на самом деле возьмите @2 секунды, что долгое время, когда вы хотите, чтобы это мгновение код обратной связи с обновлением кода.

Я не думаю, что Лифтинг болит в этом отношении, но, к сожалению, это тоже мало помогает. Приятно слышать, что Scala 2.10 будет включать некоторые улучшения в этой области, потому что я думаю, что они должны будут поступать от компилятора.

Чтобы ответить на некоторые критические замечания Лифт...

Требуется ли высокий уровень Scala? Нет, я не верю, что это так. Это довольно субъективно, но вы можете видеть из того, что я опубликовал, что создание шаблона и применение фрагмента к нему довольно прямолинейно. Вы должны быть знакомы с такими понятиями, как "карта", но какая польза от веб-фреймворка Scala, если вы этого не сделали? Док Scala по некоторым из методов, которые вы будете использовать, может выглядеть немного привлекательным для первоклассников, но, как и коллекции Scala, сложность заключается в том, чтобы сделать библиотеку более простой в использовании. Для людей, которые новичок в Scala, они, вероятно, лучше следуют примерам в Wiki Cookbook и Просто поднять, а не API doc, но я думаю, что Scala идиома, а не лифтинг.

Нужно ли смешивать разметку в "контроллерах"? Точно нет. Я рассмотрю факт, что Lift не является средой MVC и предполагает, что плакат говорит о фрагментах. Вывод HTML из фрагмента никоим образом не требуется, и в большинстве случаев это полный анти-шаблон. Селекторы CSS, подобные тем, которые я опубликовал, позволяют хранить весь ваш HTML в файлах шаблонов и всю вашу логику в ваших фрагментах.

Требуется ли подъем слишком многого состояния? Это жалоба номер один, с которой я сталкиваюсь, и ни разу я не видел ее в сопровождении реальной проблемы. Дело в том, что с Лифтом у вас есть выбор, хотите ли вы быть сдержанным или нет. Если вы используете Lift для написания веб-службы и не хотите, чтобы сеанс был создан при обращении к вашим URL-адресам, вы регистрируете службу с помощью LiftRules.statelessDispatchTable. Это согласуется с философией Лифт, что состояние не является ни хорошим, ни плохим, но необходимо выполнить некоторые потребности, а не необходимость для других. Важно четко указать, когда оно используется, и позволить разработчику решить. Если вас интересует более подробная информация об этом, Дэвид Поллак имеет лучшее объяснение.

Ответ 2

Сначала я верю, что справедливо рассмотреть некоторые из ваших моментов:

  • В 1 и 4: Scala 2.10 имеет соответствующие преимущества в скорости компиляции, это больше не должно быть проблемой
  • Вкл 2: Никогда не видел конфликта с GET/POST, но я не пробовал DELETE. Может быть ошибка в Play или в вашем коде (откройте новый вопрос, включая определение полного маршрута, включая метод)
  • В 3: IntelliJ 12 поддерживает Play 2. И генерические файлы поддерживаются в шаблонах AFAIK (если по умолчанию вы имеете в виду прохождение общего параметра типа X [A] или A)

Мой опыт работы с лифтом - это несколько лет назад, поэтому некоторые из пунктов могут не применяться:

  • Кодовая база и синтаксис (источника Lift) были действительно высокоуровневыми Scala. Это помогло кому-то начать с Scala, чтобы понять, что делает код при просмотре кода рамки.
  • Первый подход к представлению был беспорядочным, смешивая код в "контроллерах" (возвращающий HTML), он нарушил разделение проблем и сделал следующий код немного сложнее

Но самое главное:

  • Stateful. Поскольку я вышел из мира Java EE и начал работать с серверами без гражданства, количество проблем, которые ушли, поразительно. Не нужно беспокоиться о сеансах и других беспорядках, кажется, не имеет значения, но это имеет значение. Специально в эпоху облачных вычислений:)