Uliweb 的进展及计划

• 事项的录入，大概分为四大类。
• 权限的管理，主要为：超级用户，管理员，主管和一般用户。
• 报表展示，这块会用到免费的Flash报表，后面会返回xml的格式数据。
• 前端是集成了html5, css3, yaml的form.css,jquery等东西

因此从功能上还是比较多的，可以比较全面的来完善Uliweb。为什么说完善？因为的确没有人真正在使用Uliweb，所以对于的最大的好处就是，因为没有用户，我想怎么改就怎么改。但是在开发上面的项目过程中也发现一些问题：

• 比如orm中某些条件的处理不完善
• 启动时导入app不是按INSTALLED_APPS的顺序

问题不再一一列举，目前上面的问题都已经修复。

同时在扩展的app上增加了不少的内容，比如jquery相关的插件支持，象jqgrid，不过后来我自已用table实现了一个简单的，所以jqgrid就没再使用了。同时为了解决常见的CRUD功能，开发了与django类似的generic.py模块，可以简单地实现象：list, add, delete, edit, view等功能。不过有些内容，如list还需要与模板相配合，这块还不是很完善，但是已经是一个不错的开始了。同时会整理出一个相对可用的入口app，我暂时叫它Protal，它主要是提供基本的布局和菜单结构，这样可以通过简单的定制来就可以生一个简单的页面结构，然后再开始你的工作会简单一些。用户管理这块我还会继续完善，希望可以结合Portal生成一个实用的功能，这样一上来只要通过settings.ini的配置就可以比较方便地加入用户的支持。

总之，想做的事情还有很多。也多亏有项目上的需要，让我可以继续推动uliweb的发展。我做的项目计划是在年底完成，当然别人希望我能够在12月上线，但是目前主要就我一个人在做，并且每天事情很多，所以一个星期能投入的时间并不多，更多时间都是下了班才开始做的，所以我个人不认为有这个可能。不过大部分基础工作已经在我创建的一个测试项目 weflow 中做了一些（还有一些还没有在weflow中实现）。这个项目不是我未来要上线的项目，但是有些功能已经用在了我做的项目中。

有一些我认为uliweb不错的地方，仍然希望向大家推荐（想到什么说什么）：

template app 它可以让你使用{{use "jquery"}}这样的语法。那么jquery是定义在template_plugins下的同名的模块。它会按template app的要求返回一些js, css的链接，这些链接将会自动与模板合并。这样会解决一个我认为非常大的问题，那就是如何动态添加一些链接，而不是手工去修改模板中的

标签。使用{{use}}会自动搜集相应模块返回的链接，然后去掉重复的（对的，去掉重复的，因此你不用担心会有重复的链接出现），然后在生成模板之后再将链接合并。这样，就有可能让你在某个局部定义新的链接，而不是想办法的修改模板中的

中的信息。

核心中的template(不是上面的template app)现在可以支持一个叫{{embed}}的标签，它的作用就是可以把从view中传入的变量的值视为一个模板文件内容，就好象你执行了{{include}}一样，但是，{{include}}是使用文件名，而{{embed}}是使用变量，这是区别。这样，利用上面的{{use}}，你就可以在view中返回代码封装的widget代码，其中有所要使用的链接信息等，而不必还要去预先在模板中定义相关的资源信息。

再有就有uliweb的orm，我认为还是封装得可以。它就是基于sqlalchemy做的，因此最差情况，你可以直接使用sqlalchemy。但是uliweb orm可以自动建表，同时提供了象django一样的sql, reset, dump, load之类的功能，可以用来实现简单的结构的变化，数据的备分与复制。并且结合最新提供的generic.py，你还可以象django的orm一样，在Model中定义象AddForm, EditForm, DetailView, Table之类的属性（就是一个class），它们将用来控制相关的view的生成。这样就把一个Model的CRUD处理转为可配置化的方式，同时你还可以进行相应的扩展。当然，因为时间还不长，可能有些功能不是封装得很方便，或灵活性还不够。但是已经有可能生成类似django admin一样的简单的维护界面的可能了。不过uliweb orm只是使用基本的select的方式，连session都没有用。并且它可以脱离web环境来单独使用的。

还有一点关于uliweb orm我认为不错的就是Model的配置化。这是在uliweb中重点关注的，为什么呢？因为象django，Model是在模块中定义的(当然uliweb也不例外)，因此你使用它时会通过正常的导入语句来操作。这样有问题吗？有，因为导入语法本身就相当于写死在程序了。比如，你认为原来框架中的某个表结构不满足你的要求，可能希望增加几个字段，那么你怎么办？如果直接在原代码上改，那么会造成与官方的版本不一致，一旦有更新可能会造成麻烦。重新写是一个办法，但是原来的app无法使用它，因为导入语句已经写死了，别的直接导入Model的代码也需要修改，并且依赖于原app的某些代码可能也要修改。因此一样有不少麻烦。而在uliweb中，可以把model信息配置在app的settings.ini中，这样在settings.ini中就可能导入这个模块。在orm中提供了一个get_model()方法，它可以根据一个名字，如'user'得到一个真正的Model类。因此通过get_model()你可以根本不用关心这个Model是在哪里定义的，是谁定义的，只要使用它就以了。因此就有可能编写出一个app，即使它的Model发生了变化，但是只要不是影响核心的变化，它可以继续使用，而不用太关心表结构的变化。

说到这里，其实配置化是uliweb中的一个重点，这一点也是我在多次和其它人讨论uliweb时提到的。其实就是通过settings.ini，因为有app级的settings.ini还有项目级的，因此有许多的花样可以玩。其目的还是为了实现接口和具体的实现的分离，更好地进行复用和组件的替换。同时也可以减少一些不必要的加载。

至于说到计划，只是希望当我做的项目上线后，一旦认为比较稳定会再发布一个更接近实用的版本来。

---

原文：http://hi.baidu.com/limodou/blog/item/8576902349b2ac54ac34de45.html