Zk framework là gì

Có nhiều web framework. Để nắm bắt được cần phân loại. Có nhiều cách phân loại.

Phân loại theo thứ tự các phần M, V, C xử lí request, thì có thể chia làm 2 loại:

1. Controller first, ví dụ Rails, Nitrogen
2. View first, ví dụ ZK, JSF

Phân loại theo độ phức tạp của UI, thì có thể chia làm 2 loại [theo dòng chảy của thread này, thì chúng ta đang chú trọng vào cách phân loại này]:

1. Noncomponent-based, ví dụ Rails
2. Component-based, ví dụ ZK, JSF, Nitrogen

v.v.

Bài này sẽ bàn về Ajax component-based framework, hi vọng giúp bạn hình dung được bức tranh tổng thể về cơ chế hoạt động của chúng. Những framework loại này tuy cùng loại, nhưng mỗi framework loại này đương nhiên hơi khác nhau một chút. Điểm cốt lõi mà bài viết này muốn đề cập là cơ chế hoạt động chung của chúng.

Chúng phân biệt 2 loại request:

1. First GET request: Đây là khi user gõ URL vào browser, rồi ấn ENTER để mở page [do đó luôn là GET]. Nếu là view first framework, thường URL sẽ ứng 1-1 với file view template nào đó, ví dụ file .zul của ZK, file .xhtml của JSF.
2. POST back request: Đây là khi đang ở page mở bằng first GET request ở trên, user ấn nút gì đó gây ra Ajax request.

Từ page vừa mở ở trên, khi click vào link nào đó để chuyển sang page khác [URL thay đổi], thì lại chuyển sang first GET request khác, kết thúc vòng đời của page cũ.

Ví dụ xem file web.xml của ZK, thường bạn sẽ thấy:

1. Có dòng cấu hình các first GET request sẽ do DHtmlLayoutServlet xử lí
2. Có dòng cấu hình các POST back request sẽ do DHtmlUpdateServlet xử lí

Nói chung vì search engine chỉ tạo index cho kết quả của GET request [và là những trang public ai cũng truy cập được, không cần login], nên mấu chốt để framework có thân thiện với search engine hay không nằm ở kết quả trả về của first GET request. Nếu kết quả trả về chỉ chứa toàn mã JavaScript như của GWT, của XUL template của ZK thì rất khó SEO. Search engine không quan tâm đến POST request, nên kết quả của POST back request thế nào cũng được.

POST back request được xử lí trên tinh thần RPC, nên về bản chất có thể chỉ dùng duy nhất 1 URL. Tuy nhiên thường các framework dùng URL ứng luôn với URL của first GET request để lập trình viên dễ debug: khi server văng lỗi khi xử lí POST back request thì lập trình viên có thể xem log, mò ra URL, suy ra lỗi xảy ra khi xử lí cho page nào. Vì là RPC nên client side luôn sử dụng thư viện JavaScript gì đó đi kèm với framework ví dụ ZK Client Engine trong hình trên, thư viện này có tính năng làm gateway để truyền/nhận data lên/từ server. Data format có thể là JSON ví dụ ZK, có thể là XML ví dụ JSF, có thể là loại gì đó khác ví dụ BERT. Data từ server có thể chỉ là data thuần túy, cũng có thể chứa cả code JavaScript [code on demand].

Thường server muốn update vùng nào đó trên màn hình. Tùy framework mà update có thể là partial update [chỉ render lại chỗ cần thiết], hoặc full update [render nguyên cả cục]. Partial update tốt hơn vì lượng data server phải truyền cho client sẽ nhỏ hơn, tốn ít băng thông hơn, server support được nhiều user đồng thời hơn.

Page có trạng thái. Ví dụ user mở 2 tab cùng URL, nhưng sau khi thao tác ấn nút, kéo thả, gõ v.v. trên 2 page khác nhau, thì trạng thái trên mỗi page sẽ khác nhau, nhìn trông khác nhau. Trạng thái page chủ yếu là về component, ví dụ user đã gõ cái gì vào text box, đã chọn item nào từ dropdown box v.v.

Vì page có trạng thái, nên luận về scope thì ngoài 4 scope thường gặp, còn có thêm cái thứ 5:

1. Application scope
2. Session scope
3. Request scope
4. Flash scope
5. Page scope

Nếu như tùy framework mà trạng thái session có thể lưu ở client side hoặc server side, rồi theo đó phát sinh những vấn đề như security, scalibility, thì trạng thái page cũng vậy. Page có vòng đời ngắn hơn session [ví dụ user mở page1, thao tác gì đó, rồi đóng tab chứa page1 thì lúc này vòng đời của page1 đã kết thúc, nhưng session của user này vẫn chưa kết thúc, user vẫn ở trạng thái đang login chẳng hạn], nên nếu framework lưu trạng thái page ở server side, thì để tiết kiệm bộ nhớ cho server [vì server thường lưu trong bộ nhớ để truy xuất cho nhanh] thường framework dùng chiêu thức keep alive để kiểm tra xem data trạng thái của page nào đó có còn được sử dụng không, nếu không thì framework sẽ giải phóng. Nghĩa là khi user close tab, thì lúc này trở đi server có thể giải phóng bộ nhớ chứa data trạng thái cho page này. Chiêu thức keep alive hoạt động bằng cách client cứ định kì 1 phút chẳng hạn gửi request đặc biệt lên server để đánh dấu là đừng giải phóng bộ nhớ, nên khi server sau 1 phút không nhận được request này nữa, thì nó biết có thể an tâm giải phóng bộ nhớ.

Trên client, trạng thái của page lưu ở DOM và các biến JavaScript. Xem hình ở trên, thường các framework được thiết kế theo kiểu khi server nhận được POST back request, nó phải dựa vào trạng thái page để phục hồi lại cây component, rồi mới gọi hàm xử lí do lập trình viên viết. Khi lập trình viên muốn update gì đó, thì thực ra là update cái cây component này. Framework khi biết lập trình viên đã update gì đó, tùy framework mà sẽ chỉ gửi lệnh partial update đến client, hoặc chơi kiểu trâu bò gửi toàn bộ cây component đến client để client render lại toàn bộ page.

Theo phân tích trên, cây component có 2 phiên bản, 1 trên server và 1 trên client. Khi trả server trả về response ứng với first GET request, thì về nguyên tắc nó đã có thể tạo ra cây component. Khi client và server RPC với nhau, chính là cái này ra lệnh cái kia phải update, synchronize với cây component mình giữ.

Vì client lúc nào cũng giữ 1 phiên bản, nên có 2 cách thiết kế phần server [cách lưu trạng thái page]:

1. Cách stateless server: Server không cần tốn bộ nhớ để lưu cây component. Mỗi khi client truyền POST back request lên server, thì nó truyền nguyên cả cái cây lên. Lợi: sever không tốn bộ nhớ. Hại: tốn bandwidth vì đa số trường hợp chỉ cần update một phần nhỏ, mà client lại phải truyền toàn bộ cả cây. Xử lí cần CPU và bộ nhớ, nên có thể coi đây là đánh đổi CPU lấy bộ nhớ.
2. Cách stateful server: Server maintain cây component suốt vòng đời của page. Lợi và hại ngược lại ở trên.

Có cách cải tiến, là dùng cách stateless server, nhưng chỉ truyền vừa đủ thông tin, không truyền toàn bộ cả cây. Ví dụ bắt lập trình viên khi xuất response cho first GET request, phải chỉ định khi POST back mình muốn truyền cái gì đi lên server chẳng hạn. Nhưng đây lại là đánh đổi sự tiện lợi khi lập trình [tốc độ develop] lấy bộ nhớ.

Trên đời chẳng có gì hoàn mỹ. Mọi lựa chọn đều có tradeoff của nó, tùy hoàn cảnh mà liệu cơm gắp mắm chọn cái thích hợp nhất ứng vớo hoàn cảnh là tốt nhất.