Vì sao EzyArticle cho phép tuỳ biến mọi giao diện của website sử dụng EzyPlatform?
EzyArticle được thiết kế theo một hướng khác với mô hình website truyền thống. Thay vì coi giao diện là một tập file theme cố định phải chỉnh sửa trong source code, EzyArticle coi giao diện là một tổ hợp gồm theme, page, page fragment, dữ liệu động và cơ chế render có thể cấu hình ngay trong hệ thống.
Chính vì vậy, EzyArticle không chỉ hỗ trợ thay đổi một vài block hiển thị, mà cho phép can thiệp gần như toàn bộ bề mặt giao diện của website: từ khung trang, header, footer, meta tag, script, vùng nội dung, cho tới khả năng đổi giao diện theo request, theo route và theo domain mà người dùng đang truy cập.

Kiến trúc tổng quát

Về mặt kiến trúc, EzyArticle tách giao diện thành nhiều lớp:
  • Theme nền của website
  • Page hoàn chỉnh
  • Page fragment có thể tái sử dụng
  • Các vùng head, content, foot
  • Dữ liệu động được inject vào view trong lúc render
  • Tập hàm backend để template tự truy xuất dữ liệu an toàn
Nhờ cách chia này, giao diện không bị đóng cứng trong một file template duy nhất. HTML cuối cùng là kết quả của quá trình ghép nhiều mảnh giao diện, bổ sung dữ liệu ngữ cảnh, rồi render động tại runtime. 
flowchart TD
    A[HTTP Request] --> B[Controller trả về View]
    B --> C[View Decorator của EzyArticle]
    C --> D[Bơm biến vào view]
    D --> E[commonFragments]
    D --> F[pageFragments]
    D --> G[ezyfunctions]
    D --> H[requestURI / requestUriTemplate / userRequestedDomain]
    D --> I[site settings / categories / page metas]
    E --> J[Template Engine]
    F --> J
    G --> J
    H --> J
    I --> J
    J --> K[HTML cuối cùng]

Thành phần chính

Theme là lớp nền, không phải giới hạn cuối cùng

Theme trong EzyPlatform vẫn giữ vai trò nền tảng vì nó định nghĩa layout tổng thể, stylesheet, fragment chung và cấu trúc hiển thị cơ bản.
Tuy nhiên, trong EzyArticle, theme không phải nơi duy nhất quyết định giao diện. Trên lớp nền đó, EzyArticle có thể:
  • chèn thêm fragment
  • thay nội dung trang
  • bổ sung head
  • bổ sung foot
  • thay template bao ngoài của một view nếu cần
Điều đó có nghĩa là theme chỉ là điểm bắt đầu. Giao diện thực tế người dùng nhìn thấy vẫn được quyết định động ở runtime.

Page là đơn vị trang hoàn chỉnh

EzyArticle có khái niệm page như một đơn vị giao diện hoàn chỉnh. Một page không chỉ có nội dung thân trang, mà có thể có đầy đủ:
  • content.html
  • head.html
  • foot.html
  • meta.json
Cách tổ chức này cho phép mỗi trang kiểm soát cả:
  • phần hiển thị trong <body>
  • metadata trong <head>
  • CSS hoặc script cục bộ
  • các thông tin cấu hình riêng của trang

Page fragment là mảnh giao diện có thể tái sử dụng

Page fragment là nền tảng quan trọng nhất giúp EzyArticle tuỳ biến giao diện sâu.
Một fragment có thể đại diện cho:
  • header
  • footer
  • block danh sách bài viết
  • banner trang chủ
  • vùng SEO riêng
  • block script hoặc style cục bộ
  • widget hiển thị theo ngữ cảnh
Mỗi fragment không chỉ có content, mà còn có thể có thêm:
  • additionalHead
  • additionalFoot
Điều này rất quan trọng vì fragment không chỉ là một mẩu HTML hiển thị giữa trang, mà còn có thể tác động vào phần đầu và cuối của tài liệu HTML. 
flowchart LR
    A[Page] --> B[Header Fragment]
    A --> C[Content Fragment]
    A --> D[Footer Fragment]
    B --> E[head/content/foot]
    C --> E
    D --> E
    E --> F[HTML hoàn chỉnh]

Cơ chế render làm nên khả năng tuỳ biến

Giao diện được ghép trong lúc chạy

Khi một request đi vào, EzyArticle không chỉ render template gốc. Trước khi render, nó bổ sung vào view nhiều biến quan trọng như:
  • commonFragments
  • pageFragments
  • languageCode
  • categories
  • pageMetas
  • tên site, tagline, copyright
  • ezyfunctions
Nhờ đó template có đủ dữ liệu và ngữ cảnh để tự dựng lại giao diện phù hợp với trang hiện tại.
HTML cuối cùng vì vậy không chỉ phụ thuộc vào file template, mà phụ thuộc vào cả:
  • theme đang dùng
  • fragment tương ứng với page
  • ngôn ngữ hiện tại
  • dữ liệu nội dung
  • dữ liệu hệ thống
  • các hàm backend có thể gọi từ view

Fragment không chỉ được include, mà còn được render tiếp

EzyArticle bổ sung dialect riêng cho Thymeleaf với thẻ ezy:block. Hai khả năng quan trọng nhất là:
  • ezy:replace: nhúng fragment vào đúng vùng cần thiết
  • ezy:utext: render tiếp HTML hoặc Thymeleaf lấy động từ hệ thống
Điểm mạnh ở đây là fragment sau khi được lấy ra không bị chèn thô vào tài liệu. Nếu nội dung fragment còn chứa biểu thức Thymeleaf, hệ thống sẽ tiếp tục render cho tới khi tạo thành HTML cuối cùng.
Nhờ vậy có thể tạo ra giao diện lồng nhiều lớp:
  • page gọi fragment
  • fragment gọi fragment khác
  • fragment sinh thêm head và foot
  • nội dung lưu trong hệ thống vẫn có thể là nội dung động
sequenceDiagram
    participant U as User
    participant V as View
    participant D as Decorator
    participant P as Page Fragment Manager
    participant T as Template Engine

    U->>V: Yêu cầu mở trang
    V->>D: Chuẩn bị render
    D->>P: Lấy commonFragments/pageFragments
    P-->>D: Trả fragment theo page + language
    D-->>V: Bơm biến vào view
    V->>T: Render template
    T->>T: Xử lý ezy:replace
    T->>T: Xử lý ezy:utext
    T-->>U: HTML hoàn chỉnh

Tự động đăng ký fragment container

Một chi tiết rất quan trọng trong EzyArticle là người dùng không nhất thiết phải tự viết code backend để đăng ký fragment container cho từng view.
Thông qua lớp WebEzyArticleFinalViewDecorator, EzyArticle tự xử lý phần này:
  • nếu view chưa có pageFragments
  • hệ thống tự suy ra viewName từ template hiện tại
  • tự đăng ký fragment tên container
  • tự lấy fragment map tương ứng và đưa vào view
Điều này làm cho cơ chế gắn fragment vào giao diện trở nên gần như tự động. Người làm giao diện không phải bổ sung thêm mã Java chỉ để khai báo “view này có fragment container”. Nhờ đó, EzyArticle giảm đáng kể độ ma sát giữa backend và frontend, biến việc tuỳ biến giao diện thành một khả năng sẵn có của runtime, thay vì một phần việc thủ công phải lập trình riêng cho từng màn hình.
Nói ngắn gọn, EzyArticle không chỉ hỗ trợ page fragment, mà còn chủ động chuẩn bị môi trường để page fragment hoạt động ngay cả khi người dùng chưa tự đăng ký gì.

Tuỳ biến giao diện theo request và domain

Một ưu điểm rất mạnh nhưng dễ bị bỏ qua là EzyArticle không chỉ render giao diện theo nội dung, mà còn render theo ngữ cảnh truy cập thực tế.
Trong WebEzyArticleFinalViewDecorator, hệ thống bổ sung thêm các biến:
  • requestURI
  • requestUriTemplate
  • userRequestedDomain
  • ezyfunctions
Điều này mở ra khả năng tuỳ biến giao diện theo:
  • URL thực tế người dùng đang truy cập
  • route pattern đã match
  • domain mà request đi vào
Ví dụ cùng một hệ EzyPlatform có thể phục vụ:
  • nhiều website con
  • nhiều domain thương hiệu
  • nhiều route đặc thù cho từng nhóm nội dung
  • nhiều landing page chạy chung một backend
Trong mô hình đó, template có thể dựa vào userRequestedDomain hoặc requestURI để:
  • hiển thị header khác nhau
  • đổi footer theo domain
  • đổi meta tag hoặc canonical
  • chọn fragment khác nhau cho từng site
  • thay layout theo route
  • bật hoặc tắt block nội dung theo ngữ cảnh truy cập
flowchart TD
    A[Request vào EzyPlatform] --> B{Domain nào?}
    B -->|site-a.com| C[Header A / Footer A / Meta A]
    B -->|site-b.com| D[Header B / Footer B / Meta B]
    C --> E[Render cùng backend]
    D --> E[Render cùng backend]
Điểm quan trọng là khả năng multi-domain này không đòi hỏi phải tách riêng nhiều codebase hay nhiều hệ thống render khác nhau. Một runtime EzyPlatform vẫn có thể phục vụ nhiều bề mặt giao diện khác nhau, miễn là template và fragment biết tận dụng các biến ngữ cảnh mà EzyArticle cung cấp.
Vì vậy, EzyArticle không chỉ giúp tuỳ biến theo dữ liệu, mà còn giúp tuỳ biến theo môi trường truy cập thực tế của người dùng cuối.

Vì sao điều này cho phép tuỳ biến gần như mọi giao diện

Giao diện được mô hình hoá thành dữ liệu

Trong EzyArticle, fragment không chỉ là file trong theme. Nó còn được lưu và quản lý như dữ liệu nội dung trong hệ thống.
Khi giao diện được mô hình hoá thành dữ liệu, hệ thống có thể:
  • lưu trữ
  • đồng bộ
  • preview
  • publish
  • version hóa
  • quốc tế hoá theo ngôn ngữ
Đây là khác biệt rất lớn so với mô hình website truyền thống, nơi thay đổi giao diện thường đồng nghĩa với sửa source code, commit và deploy lại ứng dụng.
Trong EzyArticle, nhiều thay đổi giao diện trở thành thao tác nội dung và vận hành, thay vì chỉ là công việc của backend developer.

Mỗi vùng của trang đều có thể bị thay thế

Nhiều CMS chỉ cho chỉnh phần thân nội dung. EzyArticle đi xa hơn vì cho phép can thiệp vào cả ba vùng:
  • head
  • content
  • foot
Tác động của điều này là rất lớn. Bạn có thể:
  • thay đổi title, meta SEO, Open Graph theo ngữ cảnh
  • chèn CSS riêng cho từng trang hoặc từng khối
  • chèn script tracking cục bộ
  • thay đổi hoàn toàn cấu trúc nội dung hiển thị
  • thêm widget động chỉ xuất hiện ở một số route hoặc domain
Khi cả ba vùng này đều mở cho composition, gần như toàn bộ giao diện HTML đều trở thành thứ có thể tuỳ biến.

Template có thể tự lấy dữ liệu backend

EzyArticle cung cấp ezyfunctions để template và fragment có thể gọi các hàm backend đã được expose một cách có kiểm soát.
Nhờ đó, template có thể:
  • lấy request parameter
  • lấy request URI
  • lấy route hiện tại
  • lấy bài viết theo slug
  • lấy term đang active
  • lấy menu
  • lấy thông tin tác giả
  • lấy dữ liệu backend phục vụ block giao diện
Khi giao diện vừa có fragment động, vừa có quyền truy cập dữ liệu backend theo mô hình an toàn, nó không còn là giao diện tĩnh nữa mà trở thành một lớp hiển thị có logic rõ ràng.

Mối quan hệ giữa theme, page và fragment

Có thể hình dung cấu trúc này như sau:
  • Theme định nghĩa phong cách nền
  • Page định nghĩa cấu trúc của từng trang
  • Fragment cung cấp các khối giao diện tái sử dụng
  • Runtime quyết định cách ghép chúng theo ngữ cảnh thực tế
graph TD
    A[Theme] --> D[Layout nền]
    B[Page] --> E[Cấu trúc trang]
    C[Page Fragment] --> F[Khối tái sử dụng]
    D --> G[Runtime Render]
    E --> G
    F --> G
    G --> H[HTML cuối]
Điều này lý giải vì sao EzyArticle không chỉ “hỗ trợ theme”, mà thực sự hỗ trợ một kiến trúc giao diện đa lớp.

Không chỉ cho developer, mà còn cho vận hành nội dung

Một tín hiệu rất rõ từ cách thiết kế EzyArticle là khả năng tuỳ biến giao diện đã được sản phẩm hoá thành quy trình làm việc hoàn chỉnh.
Hệ sinh thái này không dừng ở runtime render mà còn bao gồm:
  • màn hình admin để chỉnh sửa page và nội dung liên quan
  • cơ chế preview page và post
  • setting bật hoặc tắt khả năng thêm page fragment vào web view
  • preview template cho page và post
  • extension cho VS Code để sync page, sync fragment, preview và publish
Điều đó cho thấy mục tiêu của EzyArticle không phải chỉ là “cho dev sửa template”, mà là biến giao diện website thành một phần của quy trình quản trị nội dung chuyên nghiệp.
Nói cách khác, EzyArticle dịch chuyển việc tuỳ biến giao diện từ phạm vi code deployment sang phạm vi content operation.

Tại sao đây là lợi thế lớn trên EzyPlatform

Tăng tốc độ thay đổi giao diện

Khi giao diện được tổ chức thành page và fragment riêng biệt, đội ngũ có thể thay đổi từng phần mà không cần động vào toàn bộ theme. Điều này giúp giảm phạm vi ảnh hưởng và rút ngắn vòng lặp thử nghiệm.

Dễ tái sử dụng

Header, footer, block SEO, danh sách bài viết, banner chiến dịch hay widget landing page có thể xây một lần rồi dùng lại nhiều nơi. Hệ thống vì vậy nhất quán hơn và dễ bảo trì hơn.

Hỗ trợ i18n tự nhiên

Page và fragment có thể đi cùng ngôn ngữ, còn runtime tự xác định languageCode khi render. Điều này giúp cùng một cấu trúc giao diện có thể hiển thị khác nhau theo từng ngôn ngữ mà không cần tách riêng nhiều hệ thống.

Phù hợp cho multi-site và multi-domain

Nhờ các biến như userRequestedDomain, requestURI, requestUriTemplate, một hệ EzyPlatform có thể phục vụ nhiều domain với giao diện khác nhau trên cùng một nền backend. Đây là một lợi thế rất lớn cho hệ thống sản phẩm, hệ thống brand site hoặc hệ thống nội dung nhiều website con.

Giảm phụ thuộc vào backend release

Nhiều thay đổi giao diện có thể xử lý ở mức page, fragment hoặc template động mà không cần chờ phát hành lại ứng dụng. Đây là lợi thế đặc biệt lớn với site nội dung, site marketing, landing page và các chiến dịch cần thay đổi nhanh.

Giới hạn cần lưu ý

Khả năng tuỳ biến mạnh luôn đi kèm yêu cầu tổ chức tốt.
Nếu lạm dụng fragment hoặc chèn quá nhiều logic vào head, foot và template, giao diện có thể trở nên khó kiểm soát. Vì vậy khi triển khai thực tế, nên có quy ước rõ về:
  • fragment nào dùng chung
  • fragment nào chỉ dùng cho từng page
  • phần nào thuộc theme
  • phần nào thuộc page
  • phần nào thuộc fragment
  • function backend nào được phép expose cho template
EzyArticle mở rộng rất mạnh, nhưng để khai thác tốt thì cần thêm discipline ở tầng tổ chức dự án.

Kết luận

EzyArticle cho phép tuỳ biến gần như mọi giao diện của website dùng EzyPlatform vì nó không coi giao diện là một bộ file tĩnh gắn chặt với source code. Thay vào đó, nó biến giao diện thành một hệ composition gồm:
  • theme
  • page
  • page fragment
  • vùng head/content/foot
  • dữ liệu động
  • hàm backend được expose có kiểm soát
  • biến ngữ cảnh như URI, route template và domain thực tế
Nhờ kiến trúc này, website có thể:
  • thay đổi khung trang
  • thay đổi từng block giao diện
  • thay đổi meta và script theo ngữ cảnh
  • tự lấy dữ liệu backend trong template
  • tự động dùng fragment container mà không cần đăng ký thủ công
  • tuỳ biến theo domain và route trên cùng một EzyPlatform
  • preview và publish thay đổi giao diện như một phần của quy trình nội dung
Nói ngắn gọn, sức mạnh của EzyArticle không nằm ở việc “cho sửa theme”, mà ở việc đưa toàn bộ lớp view của website vào một mô hình CMS động, linh hoạt và phù hợp với vận hành thực tế.