Sao Grails ít được thảo luận thế nhỉ

bởi vì ở VN dùng PHP nhiều, Java va .NET cũng phổ biến.

Hỏi tại sao ko dùng nhiều thì nên hỏi mấy ông quyết định công nghệ được sử dụng trong dự án, chứ hỏi mấy thợ code để làm gì. Hỏi không đúng đối tượng

Dùng Spica đơn giản và thông minh hơn Grails

http://code.google.com/p/spica/wiki/...nHelloWorld_vi

Bạn Grail chơi POJO thì tớ cũng chơi POPO

Có vài điểm tớ ko thích ở Grails:

+ cấu trúc của Grails bị flat quá: domain.com/hello -> /controller/HelloController.groovy nó làm giảm tính module của URL
+ kiến trúc MVC push: kiến trúc này cổ như trái đất từ thời Struts 1.0 rồi. Chúng ta ko cần đến một thứ kiến trúc củ chuối như JSF nơi POST tự xưng là chúa trong cái thế giới mà GET mới là vua. Tuy nhiên phải nói là JSF giúp reuse view cực dễ. Nó khá thân thiện với các ứng dụng mashup. Nhưng ngay cả khi ko có mashup đi nữa thì việc reuse view cũng rất bức thiết. MVC push hay action-based của Struts, Spring MVC hay Grail không xử lý được vấn đề này một cách có hiệu quả vì nó đặt View vào một vị trí quá stupid. Thậm chí trong kiến trúc đó model object bị lạm dụng thay vì nhiều khi chỉ cần Fast Lane là đủ.

Chết, không biết đừng nói bậy thế bạn. Grails có cái gọi là URL Mappings, nó cũng giống như URL Rewriting của mấy ông PHP ấy. Có thể config URL Pattern như thế này thì dc map vào controller nào. Rất linh hoạt.


+++++ kiến trúc MVC push: kiến trúc này cổ như trái đất từ thời Struts 1.0 rồi. Chúng ta ko cần đến một thứ kiến trúc củ chuối như JSF nơi POST tự xưng là chúa trong cái thế giới mà GET mới là vua. Tuy nhiên phải nói là JSF giúp reuse view cực dễ. Nó khá thân thiện với các ứng dụng mashup. Nhưng ngay cả khi ko có mashup đi nữa thì việc reuse view cũng rất bức thiết. MVC push hay action-based của Struts, Spring MVC hay Grail không xử lý được vấn đề này một cách có hiệu quả vì nó đặt View vào một vị trí quá stupid. Thậm chí trong kiến trúc đó model object bị lạm dụng thay vì nhiều khi chỉ cần Fast Lane là đủ.++++++


Lại nói lung tung nữa, tất cả Grails requests là GET hết. Chỉ khi nào bạn trực tiếp yêu cầu POST thì nó mới làm POST.

Còn về việc VIEW CODE REUSE thì một phần skill của coder là quan trọng. Coder trong đầu luôn luôn phải có tư tưởng muốn tổ chức, quản lý code của mình thật hiệu quả thì mới làm đc, chứ không phải bạ chỗ nào cần là lại Copy n Paste ở chỗ khác vào.
Ở đây bạn lại một lần nữa nói lung tung. Grails hỗ 3 cách khác nhau để reuse view code.

- Có SiteMesh hỗ trợ Decoration Pattern (Nếu bạn chưa biết Decoration Pattern là cái gì thì đi tìm hiểu thêm nhé). Nó như một cái khung base layout cho tất cả các trang, bạn không cần trên mỗi trang lại phải render lại cái khung.

- Hỗ trợ Tag. Một doạn view code + logics (severside logic + clientside logic) có thể đóng gói thành một cái tag, tùy bạn đặt tên. Sau đó có thể gọi lại ở bất kì chỗ nào khác. JSF cũng hỗ trợ Tag, và bạn cũng đã tự nhận code reuse của JSF là tốt đúng không?

- Ngoài ra còn có Template, kiểu cổ điển nhất để reuse lại view code. Chác không cần nói thêm nhiều.

Chào thân ái.

Mapping thì ai chẳng biết. Nó có từ thời Struts cơ mà. Nhưng flat vẫn là flat: cấu trúc single controller directory. Cái mà Rails làm người ta thích hơn Struts chính là ở chỗ Configuration Over Convention. Grails không đi xa hơn cấu trúc flat của rails là mấy. Phần còn lại vẫn là routing.

Đọc kĩ chưa mà đã phát biểu nhanh thế . Người ta đang nói JSF cơ mà.


Bạn lại nhầm hàng nữa rồi. Cái mà bạn gọi là View thực chất là bạn mới chỉ ám chỉ template. Với MVC push, rõ ràng bạn không thể dùng template nếu bạn yêu cầu Controller lấy dữ liệu từ các service hay DAO hay Repos gì đó để populate cho nó. Cái logic đó bạn không thể dùng lại được đúng ko? Ko ai gọi đó là Reuse lại View cả mà chỉ là reuse lại template thôi. Hay ý của bạn là dùng cơ chế JSTL để gom cả Model logic vào đó luôn? Tất nhiên là bạn có thể dùng custom component để làm việc đó.

SiteMesh hay Tile thì cũng chỉ là layout engine mà thôi. Nói Decorator là một design pattern cơ bản cho nó sang trọng. Bản chất vẫn là include 1 file template Mà cái đó thì quá cơ bản. Chẳng lẽ một framework ko thể hỗ trợ multiple layout thì ê quá.

Mặc dù JSF chưa hoàn thiện về mặt tổ chức những rõ ràng là nó là công nghệ của các building block ở tầng View tốt hơn nhiều. Grails không tạo được các building block cho View 1 cách dễ dàng. Hay là tớ chưa đọc kĩ tài liệu nhỉ

Bạn đã xem cách tiếp cận của Tapestry và Seam chưa

+++
... cấu trúc single controller directory ...
+++

Từ version nào đấy (xin lỗi không nhớ) thì đã có thể nhét 1 controller vào bất kỳ cầu trúc package nào tùy thik, chú không nhất định bắt buộc tất cả controller nằm trong một thư mục duy nhất. Với Grails 1.2 (chuẩn bị ra) thì có thể lấy bất kỳ CLASS nào làm controller cũng đ,c chỉ cần thêm vài cái Annotation cho nó là đc.

+++
Cái mà bạn gọi là View thực chất là bạn mới chỉ ám chỉ template. Với MVC push, rõ ràng bạn không thể dùng template nếu bạn yêu cầu Controller lấy dữ liệu từ các service hay DAO hay Repos gì đó để populate cho nó. Cái logic đó bạn không thể dùng lại được đúng ko? Ko ai gọi đó là Reuse lại View cả mà chỉ là reuse lại template thôi. Hay ý của bạn là dùng cơ chế JSTL để gom cả Model logic vào đó luôn? Tất nhiên là bạn có thể dùng custom component để làm việc đó.
+++

Với Template thì dĩ nhiên là chỉ reuse lại đc code view (html + css + js) thôi. Còn code để chuẩn bị model data cho cái template thì làm sao mà dùng lại dc. Mà ng ta nghỉ ra MVC cũng chính là vì thế.

Còn nếu muốn dùng lại cả serverside logic (code chuẩn bị model data cho view) thì phải dùng tag. Nếu đứng trong code context cua Tag bạn có quyền truy cập vào tất cả Services cũng như DAOs, muốn làm gì cũng đc. Dĩ nhiên có khác biệt với JSF Tag, tí nữa tôi sẽ nói nó khác thế nào.

+++
SiteMesh hay Tile thì cũng chỉ là layout engine mà thôi. Nói Decorator là một design pattern cơ bản cho nó sang trọng. Bản chất vẫn là include 1 file template Mà cái đó thì quá cơ bản.
+++

1 Cái layout engine thì khác template engine chứ. SiteMesh, Tiles, Facets (chuyên cho JSF) là layout engine. Velocity, Freemaker la template engine. Nó không chỉ đơn giản include một cái template. Trên các Platform khác, PHP hay Ruby làm thế nào thì tôi ko biết, nhưng trên Java mà cụ thể là với Servlet Specification thì ng ta phải có thêm một cái Filter. Tất cẩ Response nào cần dùng layout thí Filter nó sẽ tự đọng lấy tùng phần cảu response đó ra và lắp vào cái base layout rồi mới chả về phía client. Layout nhìn cơ bản thì đúng là no cũng giống Template thật nhưng cách hoạt động thực sự thì ko.

+++
Mặc dù JSF chưa hoàn thiện về mặt tổ chức những rõ ràng là nó là công nghệ của các building block ở tầng View tốt hơn nhiều. Grails không tạo được các building block cho View 1 cách dễ dàng.
+++

Cái mà bạn gọi là 'building block' chính là JSF Tag hay JSF Component. Chắc bạn thấy nó hay vì JST Tag có code view + state management logic ? JSF là một Component Based Framework thì nó làm đc điều này. Công nhận dùng cũng tiện thật. Nhưng rất nhiều Java Web Developer (nhất là nhứng ng muốn làm trang high scalable) không thíc cái kiến trúc này. Mỗi Component bạn sử dụng, thì phía serverside JSF sẽ tạo Component Model Instances để quản lý state cho cái component đó. Rất nặng nề và tốn RAM. Grails là Action Based Framework thì không thể làm đc điều này nhưng bù lại thì rất nhẹ nhàng. State Management là việc của Developer, họ phải tự quyết định.

+++
Bạn đã xem cách tiếp cận của Tapestry và Seam chưa
+++

Tapestry thì chưa, Seam (chỉ đùng Richfaces) thì rồi, và vẫn dang phải kiếm ăn bằng nó đây. Như đã nói ở trên, kiến trúc component based, fullstate management của JSF rất năng nề. Debug qua cái component tree của nó nhìn thì muốn oải luôn. Và phò nhất là nó cho cả cái cây này vào http session. Một lúc náo đó muốn cluster http session thì ôi thôi là chậm. Ngoài cái JSF ra thì tôi cũng dã dùng qua mấy cái component based frameworks khác, ECHO2 và GWT. Tapestry và Wicket (nghe nói cũng hay lắm) thì chưa có cơ hội thử vì lúc nhìn thấy Grails thì thấy hay quá rồi :-D.

Và một lời cuối cùng là Grails hay không chỉ vì những thứ mà tôi và bạn đang cãi nhau ở đây mà nó hay trước tiên với JAVA Developer vì những điểm mà tôi viết ở trên cùng.

Khiếp, các bác này typing khủng thật, mà sao toàn thấy có hai bác này lời qua tiếng lại ấy nhỉ, em nghe bác nào nói cũng thấy hay hay, bác nào nói cũng thấy đung đúng - túm lại là cũng biết mơ màng biết thêm một số thứ dời ơi đất hỡi ở trên đời nữa .

Nhưng mà giá như các bác tổng hợp lại kiến thức của mình rồi present cho anh em trong box về từng thứ một thì có phải là hay hơn không nhỉ....

Post đầu tiên là tổng hợp rồi còn gì hả bạn. Tôi không thích grails ở cái tốc độ cũng được list trong post đầu tiên và cái mệnh đề where thì thằng web2py làm ngon hơn. Tuy nhiên, tôi vẫn phải chọn PHP vì thuê người cheap hơn

Cãi nhau không đâu đến đâu! 1 coder giỏi không phải là người đi bới móc các khuyết điểm của các ngôn ngữ khác mà mình không học, mà phải là người khắc phục được các yếu điểm của ngôn ngữ mình học để có thể code ít mà hiệu quả công việc vẫn cao!!!

Đồng ý, hoàn toàn đồng ý!. Bài viết của tôi ở trên mang tính so sánh giúp các bạn không biết có thêm chút mở rộng, không mang tính bởi móc ai hết.

Tôi kiếm ăn bằng Java nhưng cũng rất phục các bác PHP (mà ở trên tôi gọi là dirty, đùa thôi). Ngôn ngữ nào cũng có điểm mạnh điểm yếu. Tôi quyết tâm khoảng 1 năm phải làm quen với 1 ngôn ngữ mới, chắc năm tới học PHP. Sau khi đã học theo chiều dọc, chuyên sâu 1 ngôn ngứ rồi thì học theo chiều ngang làm quen nhiều ngôn ngữ là rất hay vì ngôn ngứ nào cũng có những ultimative weapons của nó.