Подтвердить что ты не робот

Scala PlayFramework и Angular JS - слишком много усилий с точки зрения дублирования и микширования

Я попытался написать приложение на playframework + scala + Angular JS. Целью было создать веб-приложение, которое будет работать либо хорошо, когда JavaScript выключен или включен в браузере. Это обычное требование, когда вы пишете Public Site (что должно быть хорошо для людей и для Google, которые индексируют его)

Итак, я закончил с ~ 50% кодом, написанным в JavaScript, имеющим две (2) папки с именем "controller" - один для кода scala один для кода JS (поскольку AngularJS также использует концепцию контроллера).

Кроме того, поскольку JS -код должен использовать вызовы Ajax, мне пришлось создать еще один scala -контроллер, который возвращает json, но не html назад клиентский запрос. И.. это все, что мне не нравится. Это кажется слишком большим усилием.

В playframework стороне шаблона я должен подумать, как объединить scala с JavaScript, передавая параметры с одного языка на другой. Используя некоторые трюки, например, показывая, что, когда JS будет обработан, показывается, что когда он должен быть выключен.

Все это делает мой шаблон менее неустойчивым, и однажды, когда у меня будет огромная база кода, я могу придумать решение для дублирования моих шаблонов (шаблоны js templates + scala ) - использовать правильный шаблон, когда JS выключен/включен. Тогда количество JS-кода может вырасти до 60%..

И потом кажется, что я буду дублировать все, например, два разных приложения - для Google и для люди. То, что было бы общим (только), это мои данные сами в моей базе данных, я не должен дублировать данные. Но.. у нас может быть другая проблема с форматом этих данных (и, скорее всего, будет json-based [потому что я не трачу время процессора на преобразование табличного объекта), но не на основе таблицы - NoSQL.. тогда снова мы приходим к JS, например DB - как к MongoDB), а JS отлично работает с Json, изначально.

Затем задайте вопрос, почему бы не использовать 100% JS для простых вещей, таких как: запрос-ответ, формирование страницы, < сильные > макеты. Контроллер сервера JS может сформировать мои шаблоны - тогда мне не нужно переключаться с одного языка на другой и быть еще более продуктивным в этом смысле.

Вопрос: Есть ли у вас какие-либо предложения? Лучшие практики по этому поводу? Я не тот парень, который хочет использовать NodeJS для использования JavaScript в качестве ОДНОГО языков для всего - для сервера и клиента. Но позвольте говорить о производительности и потребностях бизнеса.

Есть пример (не мой) контроллеров AnjularJS, сколько JS мне нужно написать: https://github.com/tastejs/todomvc/tree/gh-pages/architecture-examples/angularjs/js

и просто представьте, что я должен держать контроллеры PlayFramework вместе с ними - для вызовов HTML и AJAX, смешивая вещи в шаблонах scala/playframework с JavaScript.

4b9b3361

ОТВЕТЫ

Ответ 1

Я только что сделал пример проекта, показывающий, как написать приложение AngularJS/Play с помощью Scala.js:

https://github.com/greencatsoft/scalajs-angular-todomvc

Должны быть какие-то грубые грани, но я считаю, что возможность писать все (включая части AngularJS) в Scala может понравиться некоторым людям.

Ответ 2

Я хотел бы поделиться квитанцией, используемой в конечном семени (https://github.com/angyjoe/eventual):

  • Напишите свой HTML. В этом случае, пожалуйста, не стесняйтесь использовать столько фреймворков и библиотек JavaScript, сколько хотите (семя является AngularJS, хотя).

  • Решите свои модели воспроизведения, с которых следуют контроллеры.

  • Решите операции (только те, которые вам нужны!) для каждого из контроллеров (list, create, show(id), update(id), delete(id)). Реализовать эти действия как действия Scala.

  • Вставьте маршрут воспроизведения, чтобы обслуживать каждое реализованное действие в клиентской среде.

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

  • Проведите остаток времени и усилий на стороне клиента...

Ответ 3

Теперь это может мне помочь:

https://github.com/nau/jscala

или это: https://github.com/lampepfl/scala-js

Но это не обязательно ответ.

UPDATE:

Единственный способ, который я вижу для разработчиков scala, которые не хотят слишком сильно перескакивать в JS, это:

Подождите, пока такие решения, как JScala или Scala-JS, станут готовы использовать (или внести вклад), чтобы заменить CoffeScript in Play2. До этого дня нам просто нужно жить с этим.

Здесь вы можете увидеть: https://github.com/typesafehub/angular-seed-play

Воспроизведение приложения без приложения/просмотра. В то же время файл "routes" почти пуст, потому что Angular заботится об этом на стороне клиента. Поэтому они нам не нужны.

Тип RIA. Поэтому, если в один прекрасный день мы решили сделать это приложение доступным для Google (чтобы он был доступен для Google), мы разместим представление и маршруты.

ОБНОВЛЕНИЕ 2:

Теперь я работаю над проектом PlayFramework. И я обнаружил, что не так уж плохо использовать простой запрос-ответ + немного JQuery или JScala.

Моя точка зрения (так общеизвестно, что я должен сказать, но так легко забыть): вы не знаете наверняка, будет ли ваше приложение популярным или нет. У вас будет 1K пользователей в секунду или нет. Если да, то у вас (УИЛЛ) возникают проблемы с производительностью, которые вы можете улучшить, переместив часть приложений на стороне клиента (или используйте купе с аккордами Акка Актеры на стороне сервера). Все люди (например, я) должны подумать о точке производительности разработки (это то, для чего первоначально был создан PlayFramework), когда ваши идеи могут быть на ваших шаблонах /html, чтобы сразу увидеть результат. Существует так много шума о AngualrJS, что люди (даже я:)) теряют сознание, прыгая туда, не задумываясь.

Имеет ли смысл/критический вопрос, загружаете ли вы только файл 200k of json или 200k + 5k html с другой стороны (сравнивая запрос-ответ vs rest-json)? Возможно нет. Для сайтов/приложений типа stackoverflow и многих других это не критично. Важна производительность разработки.

"Точка", это важно. "Следуйте яркой точке и продолжайте (C)":)

ОБНОВЛЕНИЕ 3: (эволюция, основанная на реальных потребностях)

Теперь у меня есть приложение, содержащее 2 модуля:

  • "web" - nodejs приложение с angularjs на стороне клиента
  • "сервер" play приложение без представлений и шаблонов на стороне сервера. Но я разочарован тем, что в идее IntelliJ с плагином scala и SBT он просто убивает мой ноутбук, стреляя по всем 8 ядрам без причины (может потребоваться некоторое время, когда люди изобретают квантовые компьютеры.. я не успели дождаться его).

Все, что мне нужно, это простой материал для отдыха. Поэтому у меня может быть сервер NODE JS (для работы с MongoDB) и Play 1.3 сервер (java)! (при необходимости подключая его к scala libs/logic). В конце концов, мне просто нужен слой REST - это не значит, что это ракетостроение. Поэтому для создания простого веб-сайта я буду использовать 10% для Play и 90% JS, пока не будет добавлена ​​дополнительная логика, которая имеет смысл создавать на scala, используя сильного ввода и функционального подхода и связанного с существующим java api, когда он мне нужен. Несмотря на то, что я java-парень (исторически), я нахожу, что вещи меня переполняют в java, а теперь scala мире.

Кажется, нужно сначала создать материал с html, css и node/js, а затем подумать о том, что ему нужно, когда он создает приложение на основе сайта. Использовать type-safety, когда это требует логика.

ОБНОВЛЕНИЕ 4:

Интересные биты

Ответ 4

Похоже, что angular слишком много для вашего дела. Вероятно, вы могли бы использовать более простой Ajax для js-стороны, например jQuery, и использовать конечные точки Rest в качестве игровых маршрутов для подачи json на вашу страницу.

Ответ 6

Вот хороший пример смешивания (angularjs play mongodb и scala) с большим учебником, он показывает, как создать современное веб-приложение, состоящее из клиентского JavaScript-приложения, созданного с помощью AngularJS, написанного в CoffeeScript, из Play Framework и использования сохранения документа с помощью Reactive Mongo неблокирующего клиента Scala для MongoDB:

https://github.com/lashford/modern-web-template#master

http://typesafe.com/activator/template/modern-web-template