昨天基本上已经有一个雏型放到svn中去的,如果你下载最新的代码已经是一个可以运行的版本了。目前因为只是在开发阶段,所以许多东西并不定型,很多东西可能会变化,因此你目前只能玩一玩。下面举些简单的例子,这些例子已经在svn中的。

1. 下载源码

svn co http://mymisc.googlecode.com/svn/trunk/kuaiboo

BTW,为什么叫Kuaiboo,因为我实在不擅长起名字,这个名字中英文混合,有些接近“快步”的意思,因此中文名字希望是开发web象快走一样方便(当然只是一个愿望)。当然如果你有好的名字可以贡献给我的话我会非常感谢。

2. 现在已经自带一个开发服务器,它是使用Werkzeug的,并且这个开发服务器自带reload功能,如果你做了任何怎改,它会自动装入,很方便,与django, GAE的差不多。在windows下的话,按Ctrl+C可以关闭。GAE的好象不行。不过按Ctrl+Break应该是都可以的。一旦你的程序出现语法错误,那么这个开发服务器有可能编译出错而退出,所以你要注意检查。这块回头看一看能不能改一下,不让它自动退出。

下载下来后,你的目录应该看上去象这样:

kuaiboo\
    apps\
        __init__.py
        Hello\
            __init__.py
            views.py
            templates\
            static\
    kuaiboo\

apps中将用来放置你的app的代码。要记住kuaiboo是象django一样以app为单位的。固定放在apps下。它是一个python的package,目前命令行工具还没有开发可以自动生成这种目录结构,不过很简单。

kuaiboo是库文件,放置各种各样的模块,现在有Werkzeug, webob,还有其它的一些东西,比如web2py的模板,我写的Form等。

在apps中已经有一个Hello的应用,它是一个测试程序,很简单。每个app都是一个package,因此有__init__.py。目前Hello中还没有数据库的处理,因此没有models模块。不过关于数据库这块我想不要绑得过死。比如GAE数据库与一般的关系数据库就不相同,因此这个框架可能更多的是在非数据库的地方吧,不过还没有想好。

views.py是放view代码的。templates是放模板的。而static是放静态文件的,不过目前还没有用到。为什么要static呢?这是我曾经在django中的想法的一个实现。一个app应该是功能完整的集合,所以静态文件也算其中之一,放在app中是为了方便复用,如拷贝。

OK。结构已经介绍完毕,下面开始写views了。

4. 第一个模板的例子

from frameworks.SimpleFrame import expose

@expose(‘/’)
def index():
    return {}

把上面的代码加到views.py中。让我一行行地解释。

from frameworks.SimpleFrame import expose 这里从frameworkds.SimpleFrame中导出expose将用于url的生成。在SimpleFrame中引入了一些常用的方法或对象可以直接使用。后面还会用到如url_for, redirect等。

@expose(‘/’) 这是一个decorator,它用来将下面的函数与某个URL相对应,这里是’/'。因此当你访问/时,就会调用index()函数。这里url的定义我是使用Werkzeug的,因此更详细的可以看它的文档。这种URL的映射可以支持参数定义,如’/blog/<int:year>/</int:month>/</int:day>,怎么样,再来一个’/user/<username>’,可以看到你可以使用<type:name>来定义或<name>来定义参数,其中type为类型。是不是比django的纯正则要简单?这个例子还没有使用参数例子。目前kuaiboo还不需要urls.py这样的东西,它会自动导入所有views函数,因此只要在你想要输出的函数前加上@expose就可以输出为一个可访问的view函数,没有这个修饰的将不会被访问到。这是一种分散方式url定义,在未来如果view文件非常多不知道会对性能有多大影响,因此以后还会实现一种集中方式的定义。

def index(): 这里定义了index函数,它目前接受一个req的参数(原来是需要req参数,但是现在已经不需要的,你可以在view函数中直接使用request, response对象,为什么?在另一篇Blog中我会仔细描述。)所以有view函数的第一个参数都是req。不过view是使用函数还是class好在我昨天的blog中也说了,不好选择,先用函数吧,至少decorator用着比较方便。这里req其实是webob的Request对象,因此详细信息要查看webob的Request文档。写到这真是有些象turbogears了,都是大杂烩,文档也都在别人哪里。看来用是一回事,写是另外一回事啊。

return {} 在kuaiboo中一个view可以返回三种东西:

  1. 字典,这样kuaiboo会自动查找对应的模板进行处理。目前kuaiboo的策略就是在所有app的templates目录下查找与函数名相匹配的模板文件,如index对应的模板文件名为index.html。因此要注意,如果你的app有重名的函数,在查找模板时可能会使用其它的app中的模板。不过kuaiboo在查找时会优先查找当前app的templates目录,因此一般你不需要担心。不过建议view函数名最好不一样。想一想如果不采用app的开发方式,将所有的view方法放在一起的话,它们会重名吗?不过我也在考虑是否可以自定义其它的模板,不过目前还不支持,有待于以后有需求或有机会去实现它。
  2. 字符串,可以是unicode。它将自动使用Response来封装。
  3. Response对象。使用它可以处理附件下件,cookie之类的设置。

因此上面的例子不是最简单的,因为我还没有定义一个模板。不过如果你把return {}改为return ‘Hello,kuaiboo’,你就已经可以测试了。先让我们把这个例子做完。

5. 进入Hello/templates目录,然后创建一个index.html文件,内容如下:

<html>
<head>
<title>Index Test</title>
</head>
<body>
<h1>Kuaiboo Framework</h1>
<p>This is a test page index.</p>
</body>
</html>

6. 好,下面就可以测试了。进入kuaiboo目录,进入命令行,执行:

python manage.py.py runserver或 manage.py runserver

7. 在浏览器输入: http://localhost:8000

看到结果了吗?


10条评论

  1. rev 9里没有发现run.py的踪影-_-!

  2. django 基于regex的urls多方便呀。

  3. 是我写错了,应该是运行:

    manage.py runserver

    命令和django一样。

  4. django的还是复杂了一点,对于初学者来说或使用者来说不方便。Werkzeug的更简单。好象你要定义复杂的url也是可以的,不过一般不需要。

  5. 最好可以自动映射

  6. 可以考虑扩展新的Frame实现新的框架功能,并不一定是唯一方式。

  7. 不过自动映射只能处理简单的情况,因为函数只是一层的,象实现/user/name这类的自动映射怎么生成。自动不如明确定义好,用户可控。

  8. 我上一个评论说明名字好, 不过中文的这么多的声母在一起, 老外较头痛。

    没有u, 不是更好吗Kaiboo, 开抱!

  9. Kaiboo在google上已经有这个名字了。

  10. I support author’s viewpoint, hoped that will have later also more better articles, wholesale will read the first time, thank!

发表评论

评论也有版权!