Spica under refactoring
pcdinh
sau:
- Less function, more class and static methods
Mã Spica đang được refactored. Các function dùng để diễn tả request và
response sẽ được đưa vào các lớp tương ứng SpicaRequest và
SpicaResponse. Các functions theo phong cách underscore sẽ được đổi về
camelCase khi đưa vào lớp
- Less clustered, more thoughtful sharing
Cơ chế xử lý package cũng đang được xem xét lại. Thông tin sẽ được
post lên trong 1 vài ngày tới.
Less feature-specific, more abstractions
Cơ chế template sẽ hướng event-driven nhiều hơn nhằm tạo ra giao diện
trừu tượng hơn cho các event. Thông tin sẽ được post sau
pcdinh
pcdinh
về mô hình class cho thấy throughtput giảm từ 100 - 200 req/m với load
test 20 concurrent reqs Tạm chấp nhận thế đã.
Nguyen Duc Phu
Hiện tại em cũng đang tìm hiểu và viết (theo kiểu thực hành thôi) một module trong này. Quá trình thay đổi tổ chức mã có ảnh hưởng gì đến tư tưởng thiết kế ban đầu không?
Và bao giờ thì hoàn thành ạ?
pcdinh
Thay đổi trên dispatcher là để developer có thể thay thế dispatcher
vào thời gian thực bằng một user-defined object. Cho nên Dispatcher
được thiết kế như là một lớp non-static. Anh đã viết docs cho phần
này.
Thay đổi trên Response và Request là để better namespacing. Vì Req và
Resp thao tác trên HTTP cho nên các phương thức của nó đều là static.
Ví dụ:
Trước đây
spica_response_send()
Bây giờ
SpicaResponse::send()
Trước đây
spica_response_set_header()
Bây giờ
SpicaResponse::setHeader() (hoặc sau này \spica\Response:setHeader()
hoặc đơn giản chỉ là Response:setHeader() do namespace spica được
import mặc định
Trước đây
spica_response_set_body()
Bây giờ
SpicaResponse::setBody()
Trước đây
spica_request_get($param)
Bây giờ
SpicaRequest::get($param)
Ở PONE, req và resp là 2 object được khởi tạo trên context và truyền
vào front controller như là các tham số. Vì thế chúng có thể thay thế
ở thời gian thực. Tuy nhiên, nhu cầu này chưa bao giờ xảy ra.
Dispatcher thì có thể developer sẽ muốn customize quá trình lookup
Controller trong 1 số trường hợp đặc biệt. Vì thế anh để nó hỗ trợ
Inversion of Control
Nhìn chung, các thay đổi này mang tính cục bộ mà ko thay đổi triết lý
ban đầu của hệ thống
+ Performance-driven: nhanh hơn, ít bộ nhớ hơn
+ PHP style: gọn gàng, dễ dùng, ko abstraction quá nhiều
Các thay đổi sắp tới
+ Tầng View hướng event nhiều hơn. Thay đổi này là nội bộ thiết kế
lớp, không ảnh hưởng đến API
+ Cải tiến kiến trúc package: có thể có một số thay đổi nhỏ về thư
mục. Cấu trúc /packages như ban đầu của bản 0.1 đã bị obsolete từ bản
2. Bản 0.2 có chủ ý phân tách controller theo package và dùng
namespace để tách các thành phần còn lại. Sẽ chia sẻ thiết kế sau.
pcdinh
+ Xung đột về khái niệm controller package
+ Thay đổi khó khăn hơn dự kiến
+ Cần có cơ chế mới cho cấu hình và nạp cấu hình
+ Dự kiến mô hình workspace sẽ thay thế cho cơ chế package hiện thời.
On Jul 15, 7:27 am, Nguyen Duc Phu <nduc...@gmail.com> wrote:
pcdinh
như sau
+ Spica được tổ chức thành các app nằm trong /apps
+ Mỗi app đặt trong một thư mục nằm trong /apps> Các thư mục con của
app này bao gồm service/, controller/, theme/, config/ ...
+ Các app này được activate qua một file có tên là init.php nằm cạnh
index.php. Mục đích của init.php là trả lại 1 giá trị là tên của
application sẽ phục vụ request hiện thời. init.php có chứa các logic
xử lý phức tạp để trả về tên của app cho Spica context.
+ Mỗi mỗi app khi đã được xác định sẽ tạo nên cái gọi là context trong
Spica
+ Giao diên xử lý request của từng application sẽ được tổ chức thành
các profile (tạm thời lúc này có tên là package, ảnh hưởng đến cách
load controller và cấu hình), module (tổ chức cao hơn của Controller
nên có thể gọi là controller module, khác với khai niệm module của
nhiều framework khác), controller (nhóm các action có liên quan) và
action là nơi diễn ra quá trình xử lý chính để trả về response cho
request
Mục đích của k/niệm application trong Spica là
+ Application isolation
+ Distribution
+ Deployment và undeployment
Cấu trúc application tiện lợi khi
1. Triển khai mỗi domain 1 application nhưng chỉ cần 1 code base. Ví
dụ http://vietnamnet.vn chạy trên app có tên là default, http://beta.vietnamnet.vn
chạy trên app có tên là beta1. Nhờ việc routing qua init.php mà toàn
bộ 2 ứng dụng này có thể triển khai trên cùng 1 code base. Nhờ đó dễ
dàng chia sẻ tài nguyên tĩnh (image, media file, files ...).
2. Chia tách code về phần logic và không chung đụng về application lib
mà chỉ dùng chung Spica và các thư viện khác trong lib để dễ phân phối
và gỡ bỏ
Yêu cầu 1 có thể dễ dàng thực hiện qua cơ chế profile của Spica nhưng
cơ chế profile đòi hỏi dùng chung cấu trúc. Cơ chế profile có thể tiện
khi triển khai nhiều sub-application cùng active 1 lúc.
Vấn đề
----------------------------
Sự thay đổi này làm cho 1 số test case ko chạy đúng.
Định
pcdinh
phải xem lại tất cả những gì thay đổi vừa rồi và viết docs đã.