Khóa luận Xây dựng CMS module cho hệ thống intranet của công ty TMA

các thẻ Portlet Thư việc các thẻ Portlet dùng để hỗ trợ cho các trang JSP khi được gọi từ Portlet có thể truy nhập vào các thành phần của Portlet như là : RenderRequest, RenderResponse…Các thư viện này cũng giúp cho các trang JSP có thể truy cập vào các chức năng của Portlet như việc tạo ra các Portlet URL. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 60 Đặng Đình Vương Các trang JSP khi sử dụng các thư viện này cần phải khai báo chúng trong thẻ thư viện theo như mẫu sau: 14.1 Thẻ actionURL Thẻ actionURL tạo ra một URL tham chiếu đến Portlet hiện tại và thực thi một số yêu cầu với các tham số khởi tạo. Các tham số này có thể được thêm vào URL bằng cách nhập thẻ param giữa thẻ đóng và thẻ mở actionURL như trong ví dụ sau : 14.2 Thẻ renderURL Thẻ renderURL tạo ra một URL tham chiếu đến Portlet hiện tại và thực thi một số yêu cầu render với các tham số khởi tạo. Các tham số này có thể được thêm vào URL bằng cách nhập thẻ param giữa thẻ đóng và thẻ mở renderURL. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 61 Đặng Đình Vương Chương 6 Chuẩn JSR 170 Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 62 Đặng Đình Vương 1. Giới thiệu về chuẩn JSR 170 Chuẩn JSR 170 dùng để định nghĩa cách thức lưu trữ và truy xuất dữ liệu. Có nhiều loại dữ liệu được hỗ trợ như: hệ quản trị cơ sở dữ liệu, hệ thống tập tin của hệ điều hành, tập tin XML…Ngoài ra, chuẩn này còn cung cấp các API và các cơ chế để chuyển đổi giữa các cơ sở dữ liệu cũng như hỗ trợ cho việc truy xuất cơ sở dữ liệu, như: lưu trữ dữ liệu theo cấu trúc cây, quản lý phiên bản dữ liệu, lắng nghe sự kiện xảy ra trên cấu trúc lưu trữ dữ liệu, không cho truy cập vào dữ liệu… Phiên bản hiện tại của chuẩn JSR 170 là 0.16.2 được đưa ra bởi Day Management AG vào ngày 25/01/2005. ( Hình vẽ sau mô tả cách thức giao tiếp của JSR 170 với các hệ cơ sở dữ liệu. Hình 18: Chuẩn JSR 170 giao tiếp với cơ sở dữ liệu Repository DBMS Repository File System Repository XML Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 63 Đặng Đình Vương 2. Mô hình repository Một JCR (Java Content Repository) bao gồm một hay nhiều workspace, mỗi workspace là một cấu trúc cây gồm nhiều item, một item có thể là một node hay một property, mỗi node có thể không có con hay có nhiều con và không có property hay có nhiều property. Có duy nhất một node không có cha gọi là root. Tất cả các node ngoại trừ root có ít nhất một cha. Property có một cha và không có con, được gọi là lá của cây. Property là một đơn vị nội dung nhỏ nhất bao gồm tên và giá trị tương ứng . Dữ liệu thực sự được chứa đựng trong giá trị của property. Hình 19: Mô hình một workspace của một repository Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 64 Đặng Đình Vương Trong biểu đồ trên, root có 3 node con là a,b và c. Mỗi node con có nhiều node con hay nhiều Property, chẳng hạn node a có 2 con là d và e, node e có 2 property là j và k, Property j chứa một hình ảnh và Property k chứa một số thực. Bất kỳ item nào trong cấu trúc trên đều có thể được xác định bằng một đường dẫn tuyệt đối. Ví dụ đường dẫn / chỉ đến root, đường dẫn /a/d/i chỉ đến 1 Property có giá trị là true. Đường dẫn tuyệt đối luôn bắt đầu với / . Đường dẫn tương đối chỉ ra một node hay một property từ một node đã được xác định trước. Ví dụ : với node /a trong biểu đồ trên thì đường dẫn tương đối đến property với giá trị true là d/i, đến property có giá trị -25 là ../c/h. 3. Một số API cơ bản Toàn bộ Repository được đại diện bởi một đối tượng Repository. Một Client kết nối tới một Repository bằng cách cung cấp một đối tượng Credentials và xác định một Workspace cụ thể bên trong một Repository. Nếu Credentials được thông qua thì Client có thể truy cập đến một Workspace đã xác định, sau đó Client sẽ nhận một Ticket. Ví dụ : // Lấy đối tượng Repository Repository repository = (Repository)java.rmi.Naming.lookup("MyRepo"); // Lấy đối tượng Credentials Credentials credentials = new SimpleCredentials("MyName", "MyPassword".toCharArray()); Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 65 Đặng Đình Vương // Lấy một Ticket Ticket myTicket = repository.login(credentials, "MyWorkspace"); Với đối tượng Ticket, Client có thể truy cập đến bất kỳ một Node hay Property nào trong cây của Workspace đang truy cập : // Lấy Node Root Node root = myTicket.getRootNode(); // Lấy một Node bất kỳ với đường dẫn tuyệt đối Node myNode = root.getNode("a/e"); // Lấy một Property của myNode Property myProperty = myNode.getProperty("k"); // Lấy ra giá trị của một Property Value myValue = mỷPoperty.getValue(); // Chuyển đổi một Value về một kiểu nào đó double myDouble = myValue.getDouble(); Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 66 Đặng Đình Vương 3.1 Thao tác trên repository Sau khi có một Ticket, Client có thể thao tác vào Repository bằng cách thêm hay xoá các node, property và thay đổi các giá trị của các Property Ví dụ : Sau khi có một node, Client có thể thêm vào một node con và thêm một Property vào node con đó. //Thêm một Node con Node newNode = myNode.addNode(“n”); //Thêm một Property newNode.setProperty(“x”,”Hello”); Sự thay đổi bởi các phương thức của Node và Property không tác động ngay vào Workspace của Repository. Các sự thay đổi đó được lưu giữ tạm thời cùng với đối tượng Ticket cho đến khi phương thức Ticket.save hoặc Node.save được gọi Ticket.save sẽ cập nhật tất cả sự thay đổi từ lần save trước đó. Phương thức Node.save(boolean shallow) lưu toàn bộ cây con của đối tượng node (khi shallow = false) hoặc chỉ lưu các property của node đó (khi shallow = true) Về mặt tổng quát, Ticket là một kho lưu trữ tạm thời, tất cả những sự thay đổi được thực hiện thông qua những phương thức của Ticket hoặc gián tiếp thông qua các phương thức của Node và Property. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 67 Đặng Đình Vương 4. Sự liên hệ giữa Node, Property và Item Do các Node và các Property có một số chức năng chung nên các phương thức chung được định nghĩa trong Interface Item. Hình 20: Mối liên hệ giữa Node, Property và Item Biểu đồ UML trên chỉ ra Property và Node là các SubInterface của Item. Một Property có một và chỉ một Node cha, một Node có thể có một hay nhiều Node cha và có nhiều Item con. 5. Sự sắp xếp các Item con Một node được hỗ trợ sắp thứ tự nghĩa là sẽ tồn tại 2 danh sách, một cho các node con và một cho các property. các node con và các property sẽ không chung thứ tự với nhau. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 68 Đặng Đình Vương Khi một item con có thỉ mục là n bị xoá khỏi một node có hỗ trợ sắp thứ tự thì tất cả các item có chỉ mục lớn hơn n sẽ bị giảm đi 1 đơn vị. Khi một item được thêm vào mà không chỉ rõ chỉ mục, nó sẽ tự động được thêm vào cuối danh sách. 6. Namespace Giống như XML, JCR cũng đưa ra khái niệm Namespaces định nghĩa các tiền tố tham chiếu đến các URI.Các tiền tố này dùng cho việc đặt tên các Item trong Repository đồng thời tránh sự trùng tên giữa các Node hay các Property trong các mã nguồn khác nhau. Mỗi JCR Repository đều có một đối tượng NamespaceRegistry dùng để thực hiện các thao tác liên quan đến đăng ký các Namespace. Trong khi đăng ký Namespace, một số tiền tố được tự động tạo ra và không thể xóa bỏ được. Các tiền tố đó là : • jcr -> : Dùng cho việc đặt tên các loại Node có sẵn. Ví dụ: jcr: content. • nt -> : Dùng cho việc đặt tên các loại Node chính (primary node types). • mix -> : Dùng cho việc đặt tên các loại Node phụ (mixin node types). • pt -> : Dùng cho việc đặt tên các Property và sử dụng trong việc chuyển nội dung của Repository sang dạng thức XML. • sv -> : Dùng trong khung nhìn System View khi chuyển nội dung của Repository sang dạng thức XML. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 69 Đặng Đình Vương 7. Property 7.1 Property đa trị Trong một số trường hợp, một property có thể chứa nhiều giá trị. Điều này tùy thuộc vào kiểu của node cha. Để truy xuất các giá trị của một property, ta sử dụng phương thức Property.getValues(), phương thức này trả về một mảng các đối tượng Value chứa các giá trị của Property. Các giá trị chứa trong property đa trị đều có chung một kiểu. 7.2 Các kiểu dữ liệu của Property Có 9 kiểu dữ liệu của Property được định nghĩa bằng các hằng số trong lớp PropertyType. Bao gồm : PropertyType.STRING PropertyType.BINARY PropertyType.DATE PropertyType.LONG PropertyType.DOUBLE PropertyType.BOOLEAN PropertyType.NAME PropertyType.PATH PropertyType.REFERENCE Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 70 Đặng Đình Vương Các kiểu STRING, BINARY, LONG, DOUBLE, BOOLEAN của Property tương tự như các kiểu string, binary, long, double, boolean được định nghĩa trong package java.lang của Java. 7.2.1 Kiểu Date Định dạng của dữ liệu có kiểu Date phải theo chuẩn ISO 8601 : YYYY - MM - DDThh:mm:ss.sssTZD. Trong đó : YYYY 4 chữ số biểu diễn năm MM 2 chữ số biểu diễn tháng ( từ 01 đến 12 ) DD 2 chữ số biểu diễn ngày ( từ 01 đến 31 ) hh 2 chữ số biểu diễn giờ ( từ 00 đến 23 ) (không cho phép biểu diễn dạng am/pm) mm 2 chữ số biểu diễn phút ( từ 00 đến 59 ) ss.sss 5 chữ số biểu diễn giờ với sai số lấy 3 chữ số thập phân ( từ 00.000 đến 59.999 ) TZD Time Zone Designator 7.2.2 Kiểu Reference, Path và Name Property có kiểu Name dùng để chứa các thuộc tính сủa namespace, nó là một giá trị kiểu string chứa một phần của namespace. Property có kiểu Path đại diện cho một đường dẫn trong một workspace bao gồm cả đường dẫn tuyệt đối và tương đối. Path không phải là kiểu tham chiếu, nó có thể chứa một đường dẫn chỉ đến một Item không tồn tại trong workspace. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 71 Đặng Đình Vương Property có kiểu Reference dùng để tham chiếu đến một node trong workspace. Giá trị của property này là một UUID của node mà nó tham chiếu. Nó không cho phép xóa bất kỳ một node nào có trong đích đến của nó. Nếu muốn xoá node, trước tiên phải xoá các tham chiếu đến node đó. 8. Node 8.1 Quan hệ giữa các node cùng tên và cùng cha ( Same-Name Siblings ) Một node có thể chấp nhận các node khác có cùng cha và cùng tên với nó. Trong trường hợp này, một đường dẫn không xác định duy nhất một node mà là một mảng các node. Chỉ mục của các node trong mảng các node này có thể bị thay đổi khi ta xóa hay thêm một node mới vào. Phương thức chuẩn để lấy về tập hợp các Node là Node.getNodes(String namePattern). Phương thức này trả về một mảng các node con của đối tượng Node. Khác với node, một property có thể có nhiều giá trị chứ không tồn tạiquan hệ này. 8.2 Các kiểu của Node Nét đặc biệt của JCR là khả năng hỗ trợ kiểu cho node. Kiểu node quy định các Node con hay các Property mà Node đó có thể có hoặc bắt buộc phải có. Một kiểu node bao gồm các thành phần sau : Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 72 Đặng Đình Vương • Name: tên của kiểu . JCR quy định sẵn một số kiểu bao gồm các kiểu node chính có tên bắt đầu với “nt:” và các kiểu node phụ có tên bắt đầu với “mix:”. • Supertype: mỗi kiểu node có thể là mở rộng của một hay nhiều kiểu node khác và kiểu node được mở rộng là Supertype của kiểu node mở rộng. • Property Definitions: mỗi kiểu node quy định một tập các thuộc tính mà Node có kiểu này có thể có hay bắt buộc phải có. Đồng thời kiểu node cũng quy định những đặc điểm mà các thuộc tính này phải có, những đặc điểm này gọi là Property Definition. • Child Node Definitions: mỗi kiểu node quy định một tập các Node con mà Node có kiểu này có thể có hay bắt buộc phải có. Đồng thời kiểu node cũng quy định những đặc điểm mà các Node con của Node này phải có, những đặc điểm này gọi là Node Definition. • Mixin Status: JCR quy định mỗi kiểu node chỉ có thể là kiểu node chính hay kiểu node phụ.. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 73 Đặng Đình Vương 8.2.1 Kiểu node chính và kiểu node phụ JCR quy định mỗi Node bắt buộc phải có một và chỉ một kiểu node chính và kiểu node chính này sẽ quy định những đặc điểm của các Node con và các thuộc tính mà Node có kiểu này có thể có. Ngoài một kiểu node chính duy nhất, JCR còn cho phép mỗi Node có thể có nhiều kiểu node phụ dùng để định nghĩa thêm những đặt tính mà Node có thể có. Kiểu node chính được lưu trong giá trị của thuộc tính jcr:primaryType và kiểu Node phụ được lưu trong giá trị của thuộc tính jcr:mixinTypes. Do mỗi Node có thể có nhiều kiểu node phụ nên thuộc tính jcr:mixinTypes là thuộc tính đa trị Kiểu node nt:base là Supertype cuả mọi kiểu node chính trong Repository 8.2.2 Property definitions Mỗi Property Definition của kiểu node chứa các thông tin sau: • Name: tên của thuộc tính. • Type: kiểu thuộc tính. • Value constraints: miền giá trị được giới hạn cho thuộc tính. • Default value: gíá trị mặc định của thuộc tính khi thuộc tính được tạo ra mà không xác định rõ giá trị. • Auto-created: cho biết thuộc tính có tự động được tạo ra khi Node sỏ hữu loại Node được tạo ra hay không. • Mandatory: cho biết thuộc tính là bắt buộc phải có trong Node hay không. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 74 Đặng Đình Vương • On-parent-version: trạng thái của thuộc tính dùng để cho biết những gì sẽ được thực hiện khi một phiên bản mới của Node chứa thuộc tính được tạo ra. • Read-only: cho biết thuộc tính là chỉ đọc hay không • Primary-Item: cho biết thuộc tính này có phải là thành phần chính của Node sở hữu thuộc tính hay không • Multiple Values: cho biết thuộc tính có thể đa trị hay không. 8.2.3 Child Node Definitions Mỗi Child Node Definition của loại Node chứa các thông tin sau: • Name: tên Node con. • Required Primary Node Types: các kiểu node chính mà Node con này phải có (chỉ có một và chỉ một trong các kiểu node chính này).. • Default Primary Node Type: Nếu trong quá trình tạo ra Node con mà không xác định kiểu node chính cho nó thì kiểu node chính này sẽ tự động được gán cho Node con. • Required Mixin Node Types: các kiểu node phụ mà Node con này phải có. • Default Mixin Node Types: các kiểu node phụ sẽ tự động được gán cho Node con nếu đến lúc lưu nội dụng Node con mà vẫn chưa được xác định kiểu node phụ. • Auto-created: cho biết Node con có tự động được tạo ra khi Node cha được tạo ra hay không. • Mandatory: cho biết Node con này có bắt buộc phải có hay không. • On-parent-version: trạng thái của Node con dùng để cho biết những gì sẽ được thực hiện khi một phiên bản mới của Node cha được tạo ra. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 75 Đặng Đình Vương • Read-only: cho biết thuộc tính là chỉ đọc hay không. • Primary-Item: cho biết Node con này có phải là thành phần chính của Node cha hay không. • Same-name siblings: cho biết có thể cho phép nhiều Node con khác có cùng tên với Node con này hay không. 8.2.4 Các kiểu node được định nghĩa sẵn JCR quy định mỗi Repository đều phải hỗ trợ ít nhất kiểu node chính nt:base và các kiểu node chính khác nếu có đều phải là kiểu con của nt:base. Ngoài ra, JCR còn định nghĩa sẵn các kiểu node thường được sử dụng trong các Repository, các kiểu node này được định nghĩa sẵn theo định dạng sau: NodeTypeName ... Supertypes ... IsMixin ... ChildNodeDef Name ... RequiredPrimaryTypes ... DefaultPrimaryType ... RequiredMixinTypes ... DefaultMixinTypes ... AutoCreate ... Mandatory ... OnParentVersion ... Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 76 Đặng Đình Vương ReadOnly ... PrimaryItem ... SameNameSibs ... ... . (more ChildNodeDefs) . .. PropertyDef Name ... Type ... ValueConstraint ... DefaultValue ... AutoCreate ... Mandatory ... OnParentVersion ... ReadOnly ... PrimaryItem ... Multiple ... . .. . (more PropertyDefs) … 8.2.4.1 Các kiểu node phụ được định nghĩa sẵn Có 2 kiểu node phụ được định nghĩa sẵn là mix:referenceable và mix:versionable trong đó mix:versionable là kiểu node con của mix:referenceable mix:referenceable | |-- mix:versionable Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 77 Đặng Đình Vương Một Node có kiểu là mixin: referenceable được sử dụng cho mục đích : • Nó là đích của thuộc tính có kiểu REFERENCE • Có nhiều hơn một Node cha Một Node có kiểu là mix: versionable dùng cho các Repository có hỗ trợ việc lưu các phiên bản của Node (versioning system). các thuộc tính được quy định bởi kiểu node này đều là các thuộc tính chỉ đọc 8.2.4.2 Các kiểu node chính được định nghĩa sẵn Mọi kiểu node chính đều được bắt nguồn từ kiểu nt:base. Do đó, một Node trên Reporitory ít nhất phải có kiểu node chính nt:base. Kiểu node chính nt:version và nt:versionHistory là cần thiết nếu có sử dụng phiên bản. Cây sau mô tả cấu trúc thừa kế của các kiểu node chính dược định nghĩa sẵn nt:base | |-- nt:default | |-- nt:hierarchyElement | | | |-- nt:file | | | |-- nt:folder |-- nt:nodeType | |-- nt:propertyDef | |-- nt:childNodeDef | |-- nt:versionHistory Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 78 Đặng Đình Vương | |-- nt:version | |-- nt:query 8.3 Node tham chiếu (Referenceable Nodes) Nét đặc biệt của Node tham chiếu là nó được sử dụng trong trường hợp repository có nhiều workspace và việc tạo các phiên bản của node. Một repository có thề có nhiều node tham chiếu, để làm được điều này, nó phải hỗ trợ kiểu mix:refrenceable. Node có kiểu mix:referenceable có một property mang tên jcr:uuid, property này được tạo ra và quản lý bởi hệ thống, client chỉ có thể đọc chứ không thể thay đối hay xóa property này. UUID của một node tham chiếu được ấn định bởi hệ thống trong lúc nó được tạo. Trong một workspace xác định, không tồn tại nhiều hơn một node có chung một UUID. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 79 Đặng Đình Vương 9. Workspace Như ta đã biết, một repository bao gồm một hay nhiều workspace, mỗi workspace chứa duy nhất một node root. Repository có thể đơn giản, chứa một workspace hay phức tạp, chứa một số lượng lớn workspace. Sau đây là một số mô hình của repository. 9.1 Repository có một workspace Trong trường hợp này repository là một cây gồm các node và property.. Hình 21: Repository có một workspace Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 80 Đặng Đình Vương 9.2 Repository có nhiều Workspace và sự tương ứng các node Trong trường hợp này, một node trong một workspace có thể có các node tương ứng ( corresponding nodes ) trong các workspace khác và chúng cùng chia sẻ một UUID. Các node tương ứng này có thể được xem như là thể hiện của cùng một node trên nhiều workspace khác nhau. Tuy nhiên trong một workspace, không tồn tại 2 node có cùng chung một UUID. Chỉ có các node với kiểu mix:refereneable mới có thể có các node tương ứng trên các workspace khác nhau. Các node tương ứng này chỉ cần có chung một UUID. Do đó chúng có thể có các đường dẫn khác nhau cũng như các property và các node con khác nhau. Khi một node tham chiếu mới (referenceable node) được tạo ra trong workspace bởi hàm Node.addNode thì nó sẽ được ấn định một UUID mới bởi hệ thống. Muốn một node có một node tương ứng trong một workspace khác, nó phải được nhân bản ("cloned") từ workspace nguồn đến workspace đích bằng cách sử dụng phương thức : Workspace.clone( String srcAbsPath, String destAbsPath, String destWorkspace, boolean shallow) Phương thức này thực hiện nhân bản cây con từ đường dẫn srcAbsPath trong workspace nguồn đến đường dẫn destAbsPath trong workspace đích destWorkspace nếu shallow = false, hoặc chỉ nhân bản một node và property của nó nếu shallow= rue. Phương thức clone thực nhân bản cả những node tham chiếu và những node không tham chiếu ( nonreferenceable node ), nhưng chỉ những node tham chiếu mới duy trì mối quan hệ tương ứng của nó giữa các workspace. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 81 Đặng Đình Vương Trong trường hợp các root node trong các workspace có kiểu là mix:referenceable thì chúng phải có chung một UUID. Root node của một workspace sẽ tự động được tạo ra khi workspace đó được tạo. Biểu đồ sau mô tả một repository có 2 workspace Hình 22: Repository có nhiều workspace Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 82 Đặng Đình Vương Trong biểu đồ trên, repository có 2 workspace là WS1 và WS2. Đường đứt khúc chỉ ra các node có mối quan hệ tương ứng. Trong mỗi workspace có các node không xuất hiện trên workspace còn lại, các node này có thể là các node tham chiếu nhưng không được nhân bản hay các node không tham chiếu. 10. Tạo phiên bản ( Versioning ) Hệ thống tạo phiên bản được xây dựng dựa trên node tham chiếu đã trình bày ở trên. Trong một repository hỗ trợ tạo phiên bản , workspace có thể chứa cả versionable node và nonversionable node. Versionable node có kiểu là mix:versionable. Kiểu mix:versionable là kiểu con thừa kế từ kiểu mix:referenceable, do đó một node cho phép tạo phiên bản thì nó là node tham chiếu và có một UUID. Khả năng có thể tạo phiên bản của node có nghĩa là tại bất kỳ một thời điểm cho trước nào đó, trạng thái của node có thể được lưu giữ để phục vụ cho việc phục hồi trong tương lai. Trạng thái lưu lại này được gọi là một version và hành động lưu lại được gọi là checking in. Version là một phần của version history. Trong một version history, các version hình thành một biểu đồ miêu tả mối quan hệ giữa các versionable node. Các version history lưu trong version storage. Có một version storage trong một repository, nó là một cây con bên dưới node /jcr:versionStorage và được lưu trong mỗi workspace. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 83 Đặng Đình Vương 10.1 Version History Version History được lưu trong Repository như là một Node có kiểu Node là nt:versionHistory và một Node có kiểu là nt:version sẽ được thêm vào Version History khi một trong những thể hiện của Node trên các Workspace thực hiện thao tác lưu phiên bản (check-in). Khi đó phiên bản mới của Node sẽ được lưu như là thành phần tiếp theo của một hay nhiều phiên bản trước đó (successor). Do đó, Version History sẽ được lưu như là một đồ thị. Hình 23: Đồ thị mô tả một Version History Trong đồ thị dùng để lưu Version History trên thì Node VH có kiểu là nt:versionHistory và Vroot, Va, Vb và Vc có kiểu là nt:version. VH là Node cha của các Node Vroot, Va, Vb và Vc; trong khi Va, Vb là phiên bản kế tiếp của Vroot, tương tự Vc là phiên bản kế tiếp của Va và Vb. Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 84 Đặng Đình Vương Trên Version History luôn có một Node đóng vai trò như là phiên bản ban đầu (Root Version Node). Node này được tạo ra tự động khi Version History mới được tạo ra và đóng vai trò là điểm khởi đầu dùng để duyệt qua hết tất cả các phiên bản khác nằm trên đồ thị biểu diễn Version History. Trong ví dụ trên thì phiên bản ban đầu của Version History VH là Vroot. 10.2 Mối quan hệ giữa các versionable node và version history Mối quan hệ giữa các node và version history được xây dựng trên sự tương ứng thông qua UUID. Các node có chung một UUID sẽ có cùng chung một version history. Trong một workspace chỉ có một versionable node trong một version history Trong một workspace có thể có các version history rỗng. Và các node không có khả năng tạo phiên bản ( nonversionable node ) hiển nhiên không có version history. Khi một versionable node được tạo ra, một version history cho node đó sẽ được tự động tạo ra trong version storage Một versionable node khi được nhân bản sang một workspace khác, node được nhân bản sẽ có chung UUID và chung version history với node gốc. 10.3 Đồ Thị Biểu Diễn Các Phiên Bản Trên Repository Đồ thị dùng để biểu diễn các phiên bản khác nhau của cùng một đối tượng Node trên Repository có cấu trúc cơ bản như sau : • Đồ thị có thể một hay nhiều phiên bản • Đồ thị chỉ có một và chỉ một phiên bản ban đầu (Root Version Node) Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA Bùi Vĩnh Phú 85 Đặng Đình Vương