Phiên Bản Cơ Bản (Base Version)

10. Tạo phiên bản (Versionin g)

10.4 Phiên Bản Cơ Bản (Base Version)

Các Node có cùng một UUID trên các Workspace khác nhau được xem như là các phiên bản khác nhau của cùng một đối tượng Node trên Repository và các thể hiện này có cùng một Version History. Tuy nhiên, trên Version History có thể có nhiều phiên bản khác nhau và mỗi thể hiện của đối tượng Node có thể chọn cho riêng mình một phiên bản cơ bản khác nhau.

Phiên bản cơ bản của một thể hiện dùng để làm phiên bản trước mặc định của một phiên bản mới của thể hiện đó được tạo ra trên Version History.

10.5 Khởi Tạo Một Version History

Khi một Node có thể tạo ra phiên bản (Versionable Node) được tạo ra trên Repository thì khi đó một Version History cũng được tạo ra cho Node. Lúc mới tạo ra thì Version History chỉ có một Node có kiểu nt:versionHistory và một Node

con có kiểu nt:version đóng vai trò là Root Version.

Ví dụ : xét trường hợp một Node N được tạo ra như sau.

• Node M là Node cha của Node N và tạo ra Node N bằng cách gọi phương thức M.addNode(“N”).

Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA

• Trước khi được lưu lại (gọi đến phương thức save) thì Node N được gán thêm loại Node phụ mixin:versionable bằng cách gọi phương thúc N.addMixin(“mix:versionable”).

• Khi gọi đến phương thức save của N thì một Version History mới sẽ được tự động tạo ra cho Node N. Điều đó có nghĩa là một Node mới có kiểu nt:versionHistory VH sẽ được tạo ra trên Repository và Node VH này có một Node con có kiểu nt:version V0 gọi là jcr:rootVersion và Node con này chính là Root Version.

• Root Version này không chứa trạng thái nào của Node mà nó chỉ chứa thông tin về loại Node và UUID thông qua các thuộc tính jcr:frozenPrimaryType, jcr:frozenMixinType, jcr:frozenUUID của nó.

• Giá trị của thuộc tính jcr:versionHistory (thuộc tính này có kiểu REFERENCE) của N được gán bằng với UUID của VH. Điều này cho phép N có thể giữ tham chiếu đến Version History của nó.

• Giá trị của thuộc tính jcr:baseVersion (thuộc tính này có kiểu REFERENCE) của N được gán bằng với UUID của V0. Điều này cho. phép N có thể giữ tham chiếu đến Base Version của nó.

• Thuộc tính jcr:isCheckedOut của N được gán giá trị true.

10.6 Tạo Phiên Bản Mới Của Một Node

Để tạo ra một phiên bản mới của Node lưu trong Version History, cần gọi đến phương thức N.checkin, khi đó sẽ phát sinh một loạt các sự kiện sau.

• Một Node mới V có kiểu nt:version sẽđược tạo ra và thêm vào làm Node con của Node VH (Node đại diện cho Version History của N trên Repository và được tham chiếu đến bởi thuộc tính jcr:versionHistory của N).

Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA

• Base Version B của N (Node được tham chiếu đến bởi thuộc tính jcr:baseVersion của N) được thay đổi bằng cách thêm vào thuộc tính jcr:successor và thuộc tính này giữ tham chiếu đến V vừa mới được thêm vào.

• Thuộc tính jcr:baseVersion của N được thay đổi để tham chiếu đến V.

• Thuộc tính jcr:isCheckedOut của N được gán giá trị false.

• Trạng thái của N được lưu lại trong V bằng cách lưu lại những thông tin của các Node con và thuộc tính của N tuỳ thuộc vào thuộc tính OnParentVersion của các Node con và thuộc tính con này.

• Các thuộc tính jcr:primaryType, jcr:mixinTypes và jcr:uuid của N được lưu lại trong V nhưng được đổi tên thành jcr:frozenPrimaryType, jcr:frozenMixinTypes và jcr:frozenUUID để tránh sự trùng tên với những thuộc tính jcr:primaryType, jcr:mixinTypes và jcr:uuid của V.

• V được gán một tên, thông thường tên này dựa trên tên của Node trước

đó của V.

• Nếu nhãn của phiên bản (Version Label) được hỗ trợ khi check-in thì nhãn này sẽ được thêm vào như là một giá trị của thuộc tính đa trị

jcr:versionLabels.

10.7 Phục Hồi Lại Trạng Thái Trước Đó Của Node

Để phục hồi lại trạng thái trước đó của Node N được lưu trong các phiên bản của nó, chằng hạn xét một phiên bản có tên “x.y” (ta gọi Node tương ứng với phiên bản này là V), cần phải gọi phương thức N.restore(“x.y”). Khi đó, các sự kiện sau sẽ

Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA

• Các Node con và thuộc tính của N sẽ thay đổi, bị xoá bỏ hay được thêm vào tùy thuộc vào bản sao của các Node con và thuộc tính con này trên V và tuỳ thuộc vào thuộc tính OnParentVersion của từng thành phần con này.

• Thuộc tính jcr:baseVersion của N được thay đổi để tham chiếu tới V.

• Thuộc tính jcr:isCheckedOut của N được thay đổi thành giá trị false.

10.8 Checkout

Thuộc tính jcr:isCheckedOut của một Node N được sử dụng để xác định trạng thái của Base Version hiện tại của Node N là có giống với trạng thái hiện tại của N trên Repository hay không. Sở dĩ có chuyện này do trong quá trình thao tác thì những thay

đổi trên Node chỉ có ý nghĩa là thay đổi tạm thời và những thay đổi tạm thời này sẽ được lưu vào Repository khi sự thay đổi đó được lưu thật sự xuống Repository(việc lưu này có thể thông qua nhiều cách khác nhau). Thuộc tính này có giá trị true có nghĩa là 2 trạng thái này không giống nhau và nếu có giá trị false thì có nghĩa là 2 trạng thái này giống nhau. Trạng thái này được xác định thông qua phương thức N.chekout.

10.9 Update

Phương thức Node.update(String srcWorkspace, boolean shallow ) sử dụng trong trường hợp repository không hỗ trợ versioning. Node gọi phương thức này sẽ ánh xạ trạng thái của nó sang các node tương ứng trong srcWorkspace.

Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA

10.10 Các Node Có Thể Tạo Phiên Bản Trên Repository

JCR quy định một Node có thể tạo ra phiên bản của nó trên Repository khi và chỉ khi nó sở hữu kiểu Node phụ mixin:versionable. Những mô tả về kiểu Node phụ

này được thể hiện dưới đây : NodeTypeName mix:versionable Supertypes mix:referenceable IsMixin true PropertyDef Name jcr:versionHistory Type REFERENCE ValueConstraint "nt:versionHistory" DefaultValue null AutoCreate true Mandatory true OnParentVersion COPY ReadOnly true PrimaryItem false Multiple false PropertyDef Name jcr:baseVersion Type REFERENCE ValueConstraint "nt:version" DefaultValue null

Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA AutoCreate true Mandatory true OnParentVersion IGNORE ReadOnly true PrimaryItem false Multiple false PropertyDef Name jcr:isCheckedOut Type BOOLEAN ValueConstraint null DefaultValue "true" AutoCreate true Mandatory true OnParentVersion IGNORE ReadOnly true PrimaryItem false Multiple false

Cũng cần lưu ý là kiểu Node phụ mixin:versionable là kiểu con của kiểu mix:referenceable do đó những Node có kiểu mixin:versionable cũng có UUID. Thêm vào đó, Node có kiểu mixin:versionable còn có thêm các thuộc tính jcr:versionHistory, jcr:baseVersion và jcr:isCheckedOut.

Thuộc tính jcr:versionHistory có kiểu thuộc tính là REFERENCE dùng để tham chiếu đến một Version History bằng cách lưu UUID của Version History Node như là giá trị của thuộc tính. Version History này dùng để lưu những phiên bản của Node.

Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA

jcr:baseVersion có kiểu thuộc tính là REFERENCE dùng để tham chiếu đến một phiên bản trên Version History (Version History này có tham chiếu được lưu trong thuộc tính jcr:versionHistory) bằng cách lưu UUID của Version Node. Version Node này chính là phiên bản cơ bản (Base Version) của Node.

jcr:isCheckedOut có kiểu thuộc tính là BOOLEAN dùng để lưu trạng thái của Node và phiên bản với giả trị false cho biết trạng thái hiện tại là check-in và true cho biết trạng thái hiện tại lả check-out.

10.11 Thuộc Tính OnParentVersion

Mỗi thành phần (bao gồm Node và các thuộc tính) của một Node có một trạng thái cho biết hành động tương ứng xảy ra đối với Node con hay thuộc tính khi Node cha của nó thực hiện việc tạo ra phiên bản trên Repository. Trạng thái này được xác

định bởi thuộc tính OnParentVersion trong PropertyDef hay trong ChildNodeDef được quy định bởi loại Node của Node cha.

Xét ví dụ trong đó có Node N là một Node có thể tạo ra phiên bản được (Versionable Node) trên một Workspace W của Repository R. Node N này có loại Node T với T là loại Node con của loại Node nt:versionable và T cho phép N có thuộc tính có tên P và Node con C.

các hành động xảy đến cho P và C khi N tạo ra phiên bản trên Repository tùy thuộc vào thuộc tính OnParentVersion trong PropertyDef của P và trong ChildNodeDef của C được quy định bởi T.

Các giá trị có thể có của thuộc tính OnParentVersion là

• COPY

Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA

• INITIALIZE

• COMPUTE

• IGNORE

• ABORT

Các giá trị của thuộc tính OnParentVersion này được quy định như các hằng số

trong lớp OnParentVersionAction. javax.jcr.version. OnParentVersionAction int COPY int VERSION int INITIALIZE int COMPUTE int IGNORE int ABORT

Bảng 2: Các hằng số trong giao diện javax.jcr.version.OnParentVersionAction

10.11.1 COPY

Khi gọi phương thức chekin() của N, C và toàn bộ các thành phần con của nó (bao gồm Node con và các thuộc tính con) sẽ được sao chép vào vùng lưu phiên bản như là cây con của VN. C và các thành phần trong cây con của nó sẽ không có Version History của riêng nó, do đó, C không cần phải là Node có thể tạo phiên bản được (Versionable Node)

Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA

Khi gọi phương thức restore của N để phục hồi lại trạng thái VN, những bản sao chép của C và cây con của nó đã được lưu trước đó (khi gọi phương thức checkin) cũng sẽđược phục hồi để thay thế C và cây con của nó trên Workspace

10.11.2 VERSION

Khi gọi phương thức chekin() của N, VN sẽ thêm vào một tham chiếu đến Version History của C. Do đó, điều này cũng yêu cầu C là một Node có thể tạo ra phiên bản. Nếu C là Node không thể tạo ra phiên bản thì cách xử lý cũng giống như

trường hợp IGNORE.

Khi gọi phương thức restore của N để phục hồi lại trạng thái VN, nếu trên Workspace hiện thời có sẵn một Node tương ứng với Version History của C thì khi đó thể hiện của C này sẽ trở thành Node con của N. Nếu trên Workspace hiện thời không có Node nào (hay nói chính xác là thể hiện nào) tương ứng với Version History của C thì một phiên bản trên Version History của C sẽđược phục hồi lại như là một Node con của N. Workspace trên đó N được phục hồi sẽ quyết định xem phiên bản nào sẽđược phục hồi và sự quyết định này là do cấu hình của Workspace quy định.

10.11.3 INITIALIZE

Khi gọi phương thức chekin() của N, một Node mới của C sẽ được tạo ra và thêm vào vùng lưu phiên bản của Repository như là Node con của VN. Khi Node mới của C được tạo ra thì sự khởi tạo này cũng giống như việc khởi tạo khi C được tạo ra trên Workspace bằng cách thông thường. Node mới của C không có Version History, do đó C cũng không cần phải là một Node có thể tạo phiên bản.

Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA

Khi gọi phương thức restore của N để phục hồi lại trạng thái VN, Node con C của VN sẽ không được quan tâm, điều đó có nghĩa là Node C hiện tại có trên Workspace sẽ giữ nguyên trạng thái, không bị thay thế bởi Node con C của VN.

10.11.4 COMPUTE

Khi gọi phương thức chekin() của N, một Node mới của C sẽ được tạo ra và thêm vào vùng lưu phiên bản của Repository như là Node con của VN. Khi Node mới của C được tạo ra thì sự khởi tạo này được quy định bởi các hàm khởi tạo được định nghĩa bởi loại Node của C. Node mới của C không có Version History, do đó C cũng không cần phải là một Node có thể tạo phiên bản.

Khi gọi phương thức restore của N để phục hồi lại trạng thái VN, Node con C của VN sẽ không được quan tâm, điều đó có nghĩa là Node C hiện tại có trên Workspace sẽ giữ nguyên trạng thái, không bị thay thế bởi Node con C của VN.

10.11.5 IGNORE

Khi gọi phương thức chekin() của N, không có thông tin nào của C được lưu trong VN.

Khi gọi phương thức restore của N để phục hồi lại trạng thái VN, Node con C của N sẽ vẫn giữ nguyên trạng thái hiện tại.

10.11.6 ABORT

Khi gọi phương thức chek-in của N thì sẽ phát sinh lỗi (ngoại lệ). Điều này cho thấy khi một Node cha có Node con có thuộc tính OnParentVersion có giá trị

Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA

10.12 Ví dụ về một Repository có hỗ trợ tạo phiên bản

Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA

Hình trên mô tả một repository có hỗ trợ versioning và gồm 2 workspace là WS1 và WS2. WS2 chứa node x không có một version history nào trong version storage, do đó nó là nonversionable node

Version storage mô tả các version history, mỗi verion history chứa 3 version của các node 01, 02, và 03.

11. Lắng Nghe Sự Kiện Trên Repository (Observation)

JCR quy định các Repository ở cấp độ 2 có thể cung cấp cơ chế để các ứng dụng sử dụng Repository có thể nhận biết và quản lý các sự kiện được tạo ra khi có sự

thay đổi xảy ra trên Repository.

Ứng dụng có thể đăng ký với Repository những sự kiện nào mà nó muốn quản lý cũng như những sự kiện nào nó không muốn xảy ra trên Repository thông qua việc

đăng ký một đối tượng để nhận các sự kiện này (Listener), những đối tượng này phải hiện thực hóa giao diện javax.jcr.observation.EventListener hay giao diện javax.jcr.observation.VetoableEventListener. Khi một sự kiện được tạo ra, Repository gọi đến phương thức onEvent của đối tượng nhận sự kiện đăng ký với Repository và

đối số của phương thức này là đối tượng có kiểu Event dùng để chứa những thông tin về sự kiện vừa được phát sinh.

11.1 Phát sinh sự kiện

Một sự kiện được phát sinh hay được kích hoạt (Fired) khi có sự thay đổi xảy ra và sự thay đổi này được cập nhật lên Repository. Cũng cần nhắc lại là có những thay

đổi chỉ xảy ra tạm thời và những thay đổi tạm thời này chỉ được cập nhật thực sự lên Repository khi gọi đến phương thức save của đối tượng thay đổi tạm thời.

Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA

Sự kiện sẽ không được phát sinh khi những thay đổi tạm thời xảy ra mà chữa

được lưu xuống Repository. Đối với những phương thức mà khi thực hiện phương thức

đó, nội dung của Repository bị thay đổi ngay lập tức (chẳng hạn những phương thức Workspace.copy hay Workspace.move) thì sự kiện sẽ được tạo ra. Thông tin về sự kiện được phát sinh có thể tìm thấy thông qua các phương thức được khai báo trong giao diện javax.jcr.observation.Event.

11.2 Các loại sự kiện

Mỗi loại sự kiện phát sinh có một giá trị kiểu long đại diện và các giá trị này là các hằng sốđược định nghĩa trước trong giao diện javax.jcr.observation.EventType

javax.jcr.observation.EventType long ITEM_ADDED long ITEM_CHANGED long ITEM_REMOVED long ITEM_VERSIONED long ITEM_RESTORED long LABEL_ADDED long LABEL_REMOVED long ITEM_LOCKED long ITEM_UNLOCKED long LOCK_EXPIRED

Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA

Các loại sự kiện này có thể phân thành các nhóm sau

• Nhóm sự kiện liên quan đến những thay đổi trên các Item của

Repository, bao gồm: ITEM_ADDED, ITEM_REMOVED,

ITEM_CHANGED.

• Nhóm sự kiện liên quan đến việc quản lý phiên bản trên Repository, bao

gồm: ITEM_VERSIONED, ITEM_RESTORED, LABEL_ADDED,

LABEL_REMOVED.

• Nhóm sự kiện liên quan đến việc quản lý khoá (Locking) trên Repository, bao gồm: ITEM_LOCKED, ITEM_UNLOCKED, LOCK_EXPIRED .

11.3 Đối tượng lắng nghe và xử lý sự kiện

Để có thể xử lý các sự kiện xảy ra trên Repository, ứng dụng cần phải đăng ký với Repository đối tượng dùng để lắng nghe sự kiện trên Repository. Các đối tượng lắng nghe sự kiện này phải hiện thực hóa giao diện EventListener hay giao diện VetoableEventListener.

javax.jcr.observation.EventListener

void onEvent(Event event)

Phương thức này được gọi khi sự kiện xảy ra.

javax.jcr.observation.VetoableEventListener

void onEvent(Event event)

Phát triển CMS module cho hệ thống Intranet cuả Công ty TMA

Đối tượng EventListener được thông báo sự kiện xảy ra trên Repository một cách bất đồng bộ (asynchoronous). Điều đó có nghĩa là khi sự kiện xảy ra trong một giao tác (transaction) và chỉ đến khi giao tác được ủy nhiệm thì đối tượng EventListener mới được thông báo sự kiện xảy ra.

Đối tượng VetoableEventListener được thông báo sự kiện xảy ra trên Repository một cách đồng bộ (synchoronous). Điều đó có nghĩa là khi sự kiện xảy ra