Reverse AJAX (Comet) và Spring MVC so với Scala/LIFT?

Question

Có demo by IBM cho biết cách dễ dàng Reverse AJAX có thể được sử dụng với DWR 2. Mặt khác, Scala/LIFT đi kèm với khả năng Reverse AJAX tích hợp sẵn.

1. Câu hỏi: Bất kỳ trải nghiệm nào có hiệu quả với Spring MVC không?

2. Câu hỏi: Nếu bạn muốn bắt đầu từ đầu, những ưu và khuyết điểm cho thích Scala/LIFT trên DWR/Spring MVC

3. Câu hỏi là gì: Trong Scala/LIFT, là xử lý phức tạp như an ninh trong Spring Security?

Answer 1

Lift của Comet Kiến trúc được lựa chọn bởi Novell để tăng sức mạnh sản phẩm Pulse của họ sau khi họ đánh giá một số công nghệ khác nhau.

Việc triển khai Comet của Lift sử dụng một kết nối HTTP duy nhất để thăm dò ý kiến ​​cho các thay đổi đối với một số thành phần tùy ý trên trang. Mỗi thành phần có một số phiên bản. Cuộc thăm dò dài bao gồm số phiên bản và GUID thành phần. Về phía máy chủ, một người nghe được gắn vào tất cả các GUID được liệt kê trong các yêu cầu thăm dò ý kiến ​​dài. Nếu bất kỳ thành phần nào có số phiên bản cao hơn (hoặc số phiên bản tăng trong khoảng thời gian của cuộc thăm dò ý kiến ​​dài), thì đồng bằng (một tập hợp JavaScript mô tả thay đổi từ mỗi phiên bản) được gửi đến máy khách. Các vùng đồng bằng được áp dụng và số phiên bản trên máy khách được đặt thành số phiên bản cao nhất cho tập hợp thay đổi.

Thang máy tích hợp cuộc thăm dò dài với quản lý phiên để nếu yêu cầu đi vào cùng một URL trong cuộc thăm dò dài sẽ gây mất kết nối, cuộc thăm dò dài được chấm dứt để tránh nạn đói kết nối (một số trình duyệt có tối đa 2 kết nối HTTP mỗi máy chủ được đặt tên, các máy chủ khác có tối đa 6). Lift cũng hỗ trợ các máy chủ có thẻ hoang dã DNS cho các yêu cầu thăm dò ý kiến ​​lâu dài sao cho mỗi tab trong trình duyệt có thể thực hiện cuộc thăm dò dài đối với một máy chủ ký tự đại diện DNS khác. Điều này tránh được các vấn đề liên quan đến nạn đói.

Nâng động phát hiện vùng chứa Servlet đang chạy trong và trên Jetty 6 & 7 và (ngay) Glassfish, Lift sẽ sử dụng triển khai "tiếp tục" của nền tảng để tránh sử dụng chuỗi trong cuộc thăm dò dài.

JavaScript của Lift có thể nằm trên đầu trang của jQuery và YUI (và có thể ngồi trên đầu trang của Prototype/Scriptaculous.) Mã phiếu thực tế bao gồm back-off về lỗi kết nối và các cách "duyên dáng" khác để xử lý kết nối tạm thời thất bại.

Tôi đã xem Atmosphere, CometD, Akka (tất cả các công nghệ Comet hướng JVM). Không có (tại thời điểm tôi đánh giá chúng) hỗ trợ cho nhiều thành phần trên mỗi trang hoặc tránh sự mất kết nối.

Novell bắt đầu từ đầu và chọn Nâng sức mạnh Pulse vì một số lý do rất tốt.

Về mặt bảo mật, Nhấc nhịp đập xuống Spring + Spring Security. Xem http://www.mail-archive.com/liftweb@googlegroups.com/msg13020.html

Về cơ bản, bảo mật của Lift được đưa vào ứng dụng của bạn. Ứng dụng Lift có khả năng chống lại các sự cố thường gặp (cross script scripting, replay attacks, cross request request forgeries) theo mặc định. Ứng dụng nâng có khả năng chống giả mạo thông số theo mặc định. Sơ đồ trang web của Lift định nghĩa quy tắc điều hướng truy cập và điều hướng truy cập trang web. Điều này có nghĩa là bạn không bao giờ có liên kết mà ai đó không thể nhấp vào. Bạn không cần phải có một bộ lọc bên ngoài (ví dụ, Spring Security) mà bạn phải cấu hình độc lập với ứng dụng của bạn (rất tiếc ... đã di chuyển một trang, nhưng quên đảm bảo tệp XML Spring Security đã được cập nhật.)

Oh ... và nếu bạn không muốn sử dụng một ngôn ngữ khuôn mẫu, đây là một thành phần hoàn toàn Lift Comet chat:

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> 
    } 
} 

và để chèn này vào một trang: <lift:comet type="Chat"/>

Answer 2

1. Từ quan điểm của tôi, Spring MVC là một lựa chọn rất xấu để xây dựng AJAXed/COMETed RIA. Thành phần ModelAndView nhằm làm việc với các biểu mẫu HTML và hiển thị toàn bộ trang cùng một lúc, các thư viện thẻ, các quy trình xác thực đều phù hợp hơn cho phát triển kiểu cũ, dựa trên các mẫu JSP và các mẫu. Đối với tôi, việc cắm AJAX/COMET vào Spring MVC sẽ luôn là một loại hack. Tuy nhiên, nếu bạn định xây dựng các dịch vụ RESTful bằng cách sử dụng @MVC (trao đổi JSON với giao diện người dùng javascript của bạn), nó có thể hoạt động (mặc dù tôi thích Jersey/JAXB cho những vấn đề đó).
2. LIFT ban đầu được thiết kế để hoạt động với COMET, do đó, nó sẽ là lựa chọn tốt hơn. Mặc dù tôi sẽ chọn một cái gì đó nhẹ hơn nhiều và mẫu ít hơn, hơn LIFT (như đối với tôi, nó bị cùng một bệnh Spring MVC).

3. Cả hai hệ thống bảo mật chỉ bao gồm các tình huống cơ bản và yêu cầu nhiều tùy chỉnh để được sử dụng trong các dự án trong thế giới thực.
   
   Đó là những gì tôi sẽ sử dụng để xây dựng COMETed RIA tại Scala:

   • Jersey (dịch vụ RESTful nhẹ để giao tiếp với JS UI qua HTTP/JSON) + Atmosphere (giải pháp mở rộng cho việc xây dựng các ứng dụng COMETed) + bất kỳ JS khung (jquery, YUI, ext js, ...). Bạn cũng nên có một cái nhìn tại Akka Framework, được tích hợp với cả Jersey và Atmosphere, và cho phép bạn xây dựng các ứng dụng web RIA trong Scala thành ngữ. Đây là số pub-sub COMET example ở Akka.
   • Vaadin + ICEPush. Nó sẽ là sự kết hợp thoải mái cho bạn, nếu bạn không muốn bị bẩn tay với JS (mặc dù ICEpush không phải là giải pháp sẵn sàng cho doanh nghiệp).

Answer 3

một lựa chọn khác, Java thuần túy (hoặc với bất kỳ ngôn ngữ JVM nào khác bao gồm Scala) là ItsNat Comet.