UCenter (三) 目录结构之二
index.php、admin.php两入口，和control、model、view这个目录的构成了MVC结构。再加上lib目录上的功能类库，形成了UCenter的核心。
除了核心之外，UCenter也写接口：
/api 即Application Programming Interface，应用程序编程接口
/api/dbbak.php 这是一个可以独立运行的文件。Ucenter在/control/admin/db.php中通过调用这个接口来实现数据库备份的相关功能。
个人觉得，UCenter的这个接口没有什么实际意义。也许应该直接写了/control/admin/db.php 的control 类里也行的样子。
配置文件、头像文件、缓存文件和备份文件等：
/data 存放数据。根目下三个文件在安装时说过用处了。
/data/config.inc.php 是配置文件，安装时自动生成的，里面定义了一些常量，和用于连接数据库的参数。
另外两个.lock文件是空文件，做为安装升级时的判断依据。
/data/avatar 存放用户头像。是jpg文件。一般是由根目录下的avatar.php文件根据传递的参数Location到本目录下，读取其中一个图片。里面有个index.html的空文件，是为了防止在浏览器里列出清单用的，其他地方的index.html也是一样的用处。
/data/backup 存放数据库的备份文件。
/data/cache 存放缓存文件。对数据库中一些不常更改的表(比如badword、application等)中的数据进行缓存，减少连接数据库的损耗。
/data/logs 存放日志文件。以文件的方式记录了后台的操作，比如登录、退出、添加应用等等。这些文个件不能会读取和运行，只能自己用编辑器打开查看。
/data/tmp 存放临时文件。一般是上传图片时，会先临时存放在这里。
/data/view 显示文件。URL上看到的内容，实际上就是这里。这里的内容是根据View层的内容，再加上Model的数据处理得到的结果。个人觉得，这个目录没有任何存在的必要，直接把生成的内容 echo 出来就好了吧。为什么还要写入文件呢？感觉多了一步I/O操作。
使View层有更良好的表现，需要image、css、js等：
/images 主要存入网站所需的图片，之外也含有字体、CSS、SWF等文件。
/js javascript文件。
/js/commom.js 常用的js文件，几乎所有的模板都引入了。
/js/calendar.js 日期，让一些input可以在点击后弹出一个日期选择框。
/js/ajax.js ajax类库，实现ajax功能。
/js/pm_editor.js 应该是用于辅助编辑短消息用的，在pm_editorbar.htm里调用了这个js，但是admin_pm_send.htm假乎并没有调用pm_deitorbar.htm。所以可以初步认为这个js并没有用上（个人推测）。
安装或升级残余：
/install 安装相关的文件，官方建议安装成功之后删除这个目录
/upgrade 用于旧版本升级到当前版本用，如果正常安装的，或升级过后，似乎也没有什么存在的价值了。
扩展机制：
/plugin 插件目录。对UCenter制作的插件会被存放在这个目录下。由/control/admin/plugin.php调用。
/plugin/filecheck 这是UCenter预装的一个插件，用于文件修改验证的。如果想要写其他的插件，可以模仿这个插件的写法。一般这个文件夹下面会至少有三个文件(在没修改过pluginbase类的情况下)。
/plugin/filecheck/plugin.php Control层文件。里面定入了一个control类，让这个control继承于pluginbase(不继承可能在某些时候也可以用，但至少我知道所有人都是这么做的)。里面的功能方法用on开头，私有方法用_开头，这个写法和UCenter自己的control类是一样的规则的。
/plugin/filecheck/plugin_filecheck.htm 这个就是View层文件了。不一定这么命名，这个名字由上面的Control层决定。且位置也是可以改动的，比如说改到根目录的/view下面，只要对pluginbase类作些微微修改就可以了。
/plugin/plugin.xml 这个文件就是数据了。估且就当成Model层了。因为一般写插件的人不能或不会直接修改数据库，那么插件所必须的数据就是以XML文件的格式存储下来了。当然版本号是多少，作者是谁等等信息也是可以写在这里的，不管在不在显示层里显示。
PS：UCenter插件扩展还是很简单明朗的，相信大部分人都可以自己写插件。当然简单的东西一般都存在功能性不够强大的问题。制作读写数据量比较大的插件时，自己是必须要重新建数据表的（这个要求自己对数据库要有操作权限），XML存储少量信息或数据倒是可以，但绝对不是一种可以代替数据库的可行方案。
/release 扩展control、model和lib的。默认情况下应该有个20080429的子目录。这个子目录可以看成是一个例子，它告诉了我们release是怎么用的。在两个单点入口(admin.php和index.php)都有定义了一个叫RELEASE_ROOT的常量，可以通过这个常量的定义来使用哪个扩展。比如
defined(‘RELEASE_ROOT’,’release/20080429′)；//定义RELEASE_ROOT
那么在调用/control,/lib和/model里的文件的时候，会优先考虑RELEASE_ROOT下面定义的，如果这个下面没有定义过，之后继续去原来定义过的地方找。
听起来很不错的扩展机制。比如我对UCenter默认返回的xml格式不满意，我想换成json格式的，只要：
1.修改index.php文件，定义RELEASE_ROOT为’mystyle’。原来默认是定义为”空字符串的。
2.只要在/release下建一个命名为mystyle的子目录，再在mystyle里建一个命名为lib的子目录。
3.把/lib 下的 xml.class.php 复制到 /release/mystyle/lib 目录下，之后就可能打开编辑了。当然,mystyle只是我举的例子。
这样做的好处是显而易见的，这样可以保证了原有系统的完整性。当UCenter升级时，我只要备份下我的mystyle目录，在升级完成后，再还原即可了，也可以通过GET参数release让整个系统有不同的表现。
但是，我很奇怪UCenter的“半糖主义”。这个扩展功能并不完全，不是所有的control、model和lib都会被 RELEASE_ROOT 下同名的文件优先。
1./control/admin 整个目录都无法用此方法扩展，可以修改admin.php满足目的。
2./model/base.class.php 无法扩展。可以修改admin.php和index.php。
3./model/admin.class.php 无法扩展。可以修改admin.php
4./lib 整个目录除了xml.class.php可以扩展外，其他的均不可扩展。哪里调用到修改哪里。对Model层的扩展还是成功的，可能是因为对Model的调用，统一是在base类里完成的吧。
