Обратный AJAX (Comet) и Spring MVC против Scala/LIFT?

Question

Существует demo by IBM, который показывает, как легко использовать обратный AJAX с DWR 2. С другой стороны, Scala/LIFT поставляется со встроенной функцией обратного AJAX.

1. Вопрос: Любой опыт, если это хорошо работает с Spring MVC?

2. Вопрос: Если бы вы начать с нуля, каковы плюсы и минусы для предпочитающих Scala/LIFT над DWR/Spring MVC

3. Вопрос: В Scala/LIFT, является обработка сложными, как безопасность в весенней безопасности?

Answer 1

Lift Комета архитектура, который был выбран Novell для питания их импульсного продукта после того, как они оценивали ряд различных технологий.

Внедрение Comet лифта использует одно HTTP-соединение для опроса для изменения произвольного количества компонентов на странице. Каждый компонент имеет номер версии. Длительный опрос включает номер версии и GUID компонента. На стороне сервера слушатель подключен ко всем GUID, указанным в запросах длительного опроса. Если какой-либо из компонентов имеет более высокий номер версии (или номер версии увеличивается в течение периода длительного опроса), дельта (набор JavaScript, описывающий изменение от каждой версии) отправляется клиенту. Дельты применяются, а номер версии на клиенте устанавливается на самый высокий номер версии для набора изменений.

Подъемник объединяет длительный опрос с управлением сеансом, так что если запрос попадает в один и тот же URL-адрес во время длительного опроса, вызвавшего голодание, длительный опрос прекращается, чтобы избежать голода в сети (некоторые браузеры имеют максимум 2 HTTP-соединения на один именованный сервер, другие - не более 6). Lift также поддерживает DNS-серверы с DNS-серверами для длительных запросов опроса, так что каждая вкладка в браузере может выполнять длительный опрос против другого сервера подстановочных DNS-серверов. Это позволяет избежать проблем, связанных с голоданием.

Подъемник динамически обнаруживает контейнер, в котором находится сервлет, и на Jetty 6 & 7 и (скоро) Glassfish, Lift будет использовать реализацию «продолжения» платформы, чтобы избежать использования нити во время длительного опроса.

Подъемник JavaScript может располагаться поверх jQuery и YUI (и может также сидеть поверх Prototype/Scriptaculous.) Фактический код опроса включает в себя откат при сбоях соединения и другие «изящные» способы работы с переходным соединением неудачи.

Я посмотрел на Атмосферу, CometD, Akka (все технологии Comet, ориентированные на JVM). Ни один из них (в то время, когда я их оценивал) поддерживал несколько компонентов на страницу или отказ от голода в соединении.

Novell начал с нуля и выбрал Lift to power Pulse по очень веским причинам.

С точки зрения безопасности, подъемный огонь весна + весна безопасности спускается вниз. См. http://www.mail-archive.com/liftweb@googlegroups.com/msg13020.html

В принципе, безопасность лифтов выпекается в вашем приложении. Приложения по умолчанию устойчивы к распространенным проблемам (межсайтовый скриптинг, повторные атаки, подделки с запросами на кросс-сайт). Приложения по умолчанию устойчивы к параметрированию. Карта сайта Lift определяет правила навигации по сайту и правила доступа. Это означает, что у вас никогда не было ссылки, на которую никто не может щелкнуть. Вам не нужно иметь внешний фильтр (например, Spring Security), который вам нужно настроить независимо от вашего приложения (whoops ... перемещал страницу, но забыл, чтобы файл XML Spring Security был обновлен.)

О ... и если вы не хотите использовать язык шаблонов, вот полный компонент Lift Comet чат:

class Chat extends CometActor with CometListener { 
    private var msgs: List[String] = Nil 

    def registerWith = ChatServer 

    override def lowPriority = { 
    case m: List[String] => msgs = m; reRender(false) 
    } 

    def render = { 
    <div> 
    <ul> 
    { 
     msgs.reverse.map(m => <li>{m}</li>) 
    } 
    </ul> 
    <lift:form> 
    { 
     SHtml.text("", s => ChatServer ! s) 
    } 
    <input type="submit" value="Chat"/> 
    </lift:form> 
    </div> 
    } 
} 

и вставить это в страницу: <lift:comet type="Chat"/>

Answer 2

1. С моей точки зрения, Spring MVC является очень плохим выбором для создания AJAXed/COMETed RIA. Компонент ModelAndView, предназначенный для работы с формами HTML и отображения всей страницы сразу, библиотек тегов, процедур проверки правильности, лучше всего подходит для старомодной разработки на основе JSP и шаблонов. Для меня включение AJAX/COMET в Spring MVC всегда будет своего рода взломом. Однако, если вы собираетесь создавать сервисы RESTful, используя @MVC (меняя JSON с вашим пользовательским интерфейсом javascript), это может сработать (хотя я бы предпочел Джерси/JAXB для этих вопросов).
2. LIFT был первоначально разработан для работы с COMET, поэтому это будет лучший выбор. Хотя я бы выбрал что-то гораздо более легкое и без шаблонов, чем LIFT (как для меня, он страдает от той же болезни, что и Spring MVC).

3. Обе системы безопасности охватывают только основные сценарии и требуют большой настройки, которые будут использоваться в реальных проектах.
   
   Вот что я хотел бы использовать для создания COMETed RIA в Scala:

   • Jersey (легкие RESTful услуги для связи с JS UI через HTTP/JSON) + Atmosphere (масштабируемое решение для создания приложений COMETed) + любой JS framework (jquery, YUI, ext js, ...). Вы также должны взглянуть на Akka Framework, который интегрирован с Джерси и атмосферой, и позволяет создавать веб-приложения RIA в идиоматической Scala. Вот pub-sub COMET example в Акке.
   • Vaadin + ICEPush. Это будет очень удобная комбинация для вас, если вы не хотите, чтобы ваша рука была грязной с JS (хотя ICEpush еще не является решением для предприятий).

Answer 3

Другая альтернатива, чистой Java (или с любым другим JVM-языком, включая Scala), является ItsNat Comet.