对内容的访问控制可以抽象为全局权限；contenttype权限和行记录权限
对内容的访问控制可以抽象为全局权限；contenttype权限和行记录权限<
p>昨晚睡得很好，今天加快进度，把事情做完它，装进LINUX，更新到网上去。上午效率不算太高，到博客上的时间偏多了一点。12：04分，完成
了从
XML到解释的步骤，过去，在应用程序中调用时工作量最大，不过现在由于程序都是现成的，只是扩展方法而已，因此估计速度会快得多。按昨天的设想，是把
action增加一个空的doAuthorize()方法，这样不会影响已有的程序的调用，而在需要时可以添加这个方法实施代码，特殊情况下可以覆盖这个
方法的代码实施特别的控制。在版面显示的涉及到内容采集的tag模块中也可以采用这个方法。
昨天对设计出来的结构：
<privileges>
<privilege name="ownerid" fld="id" vname="id" scope="visitor"/>
<privilege name="ownername" fld="name" vname="name" scope="visitor"/>
<roles>rolesadmin</roles>
</privileges>
<privileges>
<privilege name="owner" fld="author" vname="name" scope="visitor"/>
<display>ALL</display>
<roles>bbsadmin</roles>
</privileges>
理 解仍不充分，实际上，privileges意味着是对contenttype的访问权限；而privilege意味着是行级权限。这样，authrize ()中就不会处理到privilege这一层，这一层是由拥有dao实例的处理层进行处理的，违反这个原则必然带来代码的冗长和性能的代效。< /p>
这个问题似乎进一步想清楚了，其中，行权限的前题是拥有者，这对于modify型，包括delete都有效，但对于添加没有效果。在这 个问题上最容 易犯的是不能明确使用的是黑名单方式还是白名单方式。毫无疑问，在这里我采取的是白名单方式，因此，即使是对于display权限，也必须明确授予才有 效，毕竞象个人资料是不可以让其他人看的。更新文档如下：
六.实体的访问权限设置真正需要设置的是privileges和privilege;
基表系统中的multitree仍然没有完成，不过就完成的部分而言，仍然是没有写一个足够详备的文档参考，在调用时仍然是觉得生疏，今天仍然需要 一个个看到代码才有一点印象，尽管代码是我写的。当初做dao.xml时，para的hbase是通过xxxbase提示，这看来是多余的，实际上，所有 的base都是统一通过getBase()得到。对于treebase来说，尽管已经在admin中广泛调用，但作为 一个类似下拉表的应用来说，我还没有印象，即使是那个loadRecords我也没有印象曾经调用过，这里需要重新整理一下。对于权限检验这一条来说，其 中涉及到根据某一个基表名称的某一个基对象的名称进行验证，显然，这更象是当成一个simplebase进行访问，所以，需要修改这几个类统一下方法。实 际上，尽管象treebase已经提供了几乎全部的parent/son链表关系，以及leafs/records，但却没有真正进行过调用，原因在于 tree/contentsmanager的内容浏览器中是通过lister调定列表条件进行访问的，完全没有使用treebase的功能。不过，由于那 个的修改是实时进行的，而treebase 是一次性读入内存中周期刷新的，所以，目前这样处理也不是一件坏事，以后，可以扩展lister使 用这个treenodes，相信是完全可以做到的，这时侯，适用于是只读的操作，最合适不过。从性能上看，lister是高效的查表程序，而lister 读入的基类，当需要找children时，却是必须通过递归实现的，效率上看，换成treenodes形式倒不见得是一个划算的选择。
回过头来再看看base部分，这是很早以前完成的基本功能的，在调用时问题不小，特别是没有使用反射，所以在类判断上显得比较的笨拙。收改了这个地方，另外，包括是xxxbase:basename的形式也同时更改过来了。
全天仍没有完成最后权限控制部分对action的所有修改，更不用谈提交linux服务测试。这件事仍需要再有半天到一天才能完成
|