JCR试图定义一组内容管理的标准接口,以便标准化内容管理器模块。如果所有的内容管理器都以同样的API提供服务,那么各种内容管理器产品之间将具有可互换性。JCR规范分为两个level。level 1定义了一组基本的内容仓库操作,包括内容的读、写、删除、搜索、内容元素的序列化等等;level 2提供了高级的功能,例如事务管理、版本控制、内容观察、访问控制、内容锁定等。
JCR定义的内容仓库模型是一个树状结构,树上的元素(Item)分为两类:节点(node)和属性(property)。整棵树具有单根结构。从根开始,内容元素的定位采用UNIX文件系统风格,例如“/A/B/ccc”(根下面A节点的B子节点的ccc属性),相对定位符(“.”和“..”)也是可用的。每个属性有且仅有一个父节点,不能有子元素。每个节点可以有一个或多个父节点(根节点无父节点),也可以有任意多个子节点或属性。注意,节点可以有多个父节点,也就是说可以从不同的路径导航获得同一内容,这是网站常见的一个需求(来自不同栏目的两个链接指向同一篇文章)。
除了Node和Property之外,API中还有几个重要的对象。Repository代表整个内容仓库,Credentials代表一个用户身份,Ticket代表进入该内容仓库的门票。获得内容根节点的代码大致如下:
Repository repository = (Repository)java.rmi.Naming.lookup("MyRepo");
Credentials credentials = new SimpleCredentials("MyName", "MyPassword".toCharArray());
Ticket myTicket = repository.login(credentials, "MyWorkspace");
Credentials credentials = new SimpleCredentials("MyName", "MyPassword".toCharArray());
Ticket myTicket = repository.login(credentials, "MyWorkspace");
Node root = myTicket.getRootNode();
从root节点就可以遍历访问整课内容树。Ticket对象也支持通过绝对路径或者UUID直接获得某一内容元素(节点或属性)。
照我的理解,现在我们的内容管理器产品已经具备了兼容level 1的功能。但是这个标准API对于我们设计内容管理器有多大程度的帮助?这个问题要去问魔之眼。