[OT]关于点子 及 [IDEA]如何让web界面标准化

43 views
Skip to first unread message

limodou

unread,
Nov 16, 2006, 9:42:15 PM11/16/06
to Python.cn@google
其实许多人对于技术都有不同的想法,但有些时候是在心里默默去想,随着时间的推移,要么无力去实现,要么不再有兴趣。不过我认为某些想法可能是非常有用的。因此我倡议有兴趣的可以讨论一下"点子(idea)"。不管是否去实现,还是由别人实现,交流可以使我们开拓眼界。

我想如果我有一些什么想法,哪怕是不成熟不正确的想法,有人交流是非常好的事情。

[IDEA]如何让web界面标准化

为什么要标准化,为了快速开发。因为我不希望一个功能花上太多的时间去做。那么目前我感受web
UI与GUI的差别非常大。做GUI我基本不考虑控件的美观,只是实现功能,考虑控件的布局就可以了。而且控件本身有许多的方法让我来调用。但到了web很麻烦。

你要了解html, css, js等。而且在生成一个界面时,你要考虑如何使用css来布局,如何写html代码,如何使用js来与dom元素进行交互。ajax技术的出现,更搅乱了我们的视线。更多的ajax库,更多的效果让我们无法选择。对于个人来说,我可能更关心功能实现,界面能够美观最好,不够也关系不大,可以希望美化的工作留在以后来完成,最重要的功能先要实现。随着开发进行,我发现后台功能反而比前台容易控制。不知道大家的感受如何。因此我希望有一种简单可扩展的前端界面生成,最好可以通过简单的代码生成美观的界面。然后在此基础上再编写一些与后台交互,js代码出来。因此需要有足够可用的标准web
ui元素,而且需要可以方便地自动处理css,
image的链接,及有可能有内存的合并。还要可以处理布局。对于动态的处理,我不会拒绝使用js。而且我非常希望基于jQuery来做。

因此我的想法是:

1. 创建一套基本可用的web ui库,如:菜单,工具条,基本控件(checkbox, text, select, radio,
textarea),布局处理,表格等。
2. 创建一种构造工具,也许有自已的格式模板的处理,它不一定要生成最终的结果,但可以创建一个基本可以工作的基础框架,如生成html页面,正确拷贝css,
js,image等信息
3. 前端尽量与后端脱离

前几天看了pyjamas项目,它是一个类Google的gwt项目,可以用python来开发ajax应用,你看不到任何的js,
css之类的东西。不过它的js是gwt类似的,如果可以改为jQuery就更好了。不过他也更复杂。因为它可以把python程序转为js代码,有些情况下,使用js可能更简单。

--
I like python!
UliPad <<The Python Editor>>: http://wiki.woodpecker.org.cn/moin/UliPad
My Blog: http://www.donews.net/limodou

Zoom.Quiet

unread,
Nov 16, 2006, 10:09:06 PM11/16/06
to pyth...@googlegroups.com
On 11/17/06, limodou <lim...@gmail.com> wrote:
> 其实许多人对于技术都有不同的想法,但有些时候是在心里默默去想,随着时间的推移,要么无力去实现,要么不再有兴趣。不过我认为某些想法可能是非常有用的。因此我倡议有兴趣的可以讨论一下"点子(idea)"。不管是否去实现,还是由别人实现,交流可以使我们开拓眼界。
>
> 我想如果我有一些什么想法,哪怕是不成熟不正确的想法,有人交流是非常好的事情。
>
> [IDEA]如何让web界面标准化
好!号召大家分享知识和代码的同时,也可以分享点子的!
创立点子集:
http://wiki.woodpecker.org.cn/moin/PyWebIdeas

>
> 为什么要标准化,为了快速开发。因为我不希望一个功能花上太多的时间去做。那么目前我感受web
> UI与GUI的差别非常大。做GUI我基本不考虑控件的美观,只是实现功能,考虑控件的布局就可以了。而且控件本身有许多的方法让我来调用。但到了web很麻烦。
>
> 你要了解html, css, js等。而且在生成一个界面时,你要考虑如何使用css来布局,如何写html代码,如何使用js来与dom元素进行交互。ajax技术的出现,更搅乱了我们的视线。更多的ajax库,更多的效果让我们无法选择。对于个人来说,我可能更关心功能实现,界面能够美观最好,不够也关系不大,可以希望美化的工作留在以后来完成,最重要的功能先要实现。随着开发进行,我发现后台功能反而比前台容易控制。不知道大家的感受如何。因此我希望有一种简单可扩展的前端界面生成,最好可以通过简单的代码生成美观的界面。然后在此基础上再编写一些与后台交互,js代码出来。因此需要有足够可用的标准web
> ui元素,而且需要可以方便地自动处理css,
> image的链接,及有可能有内存的合并。还要可以处理布局。对于动态的处理,我不会拒绝使用js。而且我非常希望基于jQuery来做。
>
> 因此我的想法是:
>
> 1. 创建一套基本可用的web ui库,如:菜单,工具条,基本控件(checkbox, text, select, radio,
> textarea),布局处理,表格等。
> 2. 创建一种构造工具,也许有自已的格式模板的处理,它不一定要生成最终的结果,但可以创建一个基本可以工作的基础框架,如生成html页面,正确拷贝css,
> js,image等信息
> 3. 前端尽量与后端脱离
>
> 前几天看了pyjamas项目,它是一个类Google的gwt项目,可以用python来开发ajax应用,你看不到任何的js,
> css之类的东西。不过它的js是gwt类似的,如果可以改为jQuery就更好了。不过他也更复杂。因为它可以把python程序转为js代码,有些情况下,使用js可能更简单。
>
> --
> I like python!
> UliPad <<The Python Editor>>: http://wiki.woodpecker.org.cn/moin/UliPad
> My Blog: http://www.donews.net/limodou
>


--
"""Time is unimportant, only life important!
blog@ http://blog.zoomquiet.org/pyblosxom/
wiki@ http://wiki.woodpecker.org.cn/moin/ZoomQuiet
douban@ http://www.douban.com/people/zoomq/
____________________________________
Please use OpenOffice.org to stand for M$ office.
Please use 7-zip to stand for WinRAR.
You can get realy freedom from software.
"""

yi huang

unread,
Nov 16, 2006, 10:48:36 PM11/16/06
to pyth...@googlegroups.com
我看从 pyjamas 出发挺不错的。
它0.3版本的目标是包装第三方的js widgets库。
0.4版本的目标是开发一套 mock DOM library ,这样可以对python代码直接进行测试,而不用生成js后在浏览器里测试了。

另外一种方法是,类似pylons里的helper库,这种简单些。

--
http://codeplayer.blogspot.com/

gas...@gmail.com

unread,
Nov 16, 2006, 11:30:52 PM11/16/06
to python.cn
你讲的东西已经有实做了, TurboGears 的 widgets
(网页元件)就是这样的东西.
装好 TurboGears 后可以启动 TurboGears 网页介面工具箱:

$ tg-admin toolbox

工具箱里有 widgets browser (网页元件浏览器),
列出目前所支援的所有 widgets (网页元件)
还有这些元件如何使用的说明.

这些网页元件可以简单地自行订制,
包含有表单的订制(包含各种基础的表单元件),
语法高亮, TinyMCE 编辑器封装等等.
对于表单来说, 甚至还提供 validator (表单格式验证)
功能.

用 TurboGears widgets 封装 JS 库实在相当容易.
我自己封装过 scriptaculous, moo.fx 库, PlotKit (JS 的绘图库)
这些plugin,
可以在 cheeseshop 上找到.

开发中的版本 tgwidgets 可以独立在 TurboGears 外使用

limodou

unread,
Nov 16, 2006, 11:32:07 PM11/16/06
to pyth...@googlegroups.com
On 11/17/06, yi huang <yi.cod...@gmail.com> wrote:
> 我看从 pyjamas 出发挺不错的。
> 它0.3版本的目标是包装第三方的js widgets库。

如果这样就是我所希望的了。

> 0.4版本的目标是开发一套 mock DOM library
> ,这样可以对python代码直接进行测试,而不用生成js后在浏览器里测试了。
>
> 另外一种方法是,类似pylons里的helper库,这种简单些。
>

不过helper我看过,它只解决了简单的html元素和简单的ajax的访问,无法实现富客户端的js功能。我想这块还是使用js来控制为好。另外我更关注于初始的创建处理。在通常情况下,搭架子,比修改要困难得多。如果更方便地搭出这个架子,我想最好有一套方式。比如写一个简单的配置,如:

<page>
<v_layout>
<usersignon align="right">
<banner>
<menu>
<two_column_layout>
<left><sidebar></left>
<right><content><right>
</two_column_layout>
<footer>
</h_layout>
</page>

上面有一些是预先定义好的,如page, v_layout,
two_column_layout,有一些是用户扩展的,如:usersignon, banner, menu

而这些tag可以包含css, html, js,
images等,因此需要在组装时自动地进行处理,如将tag替换为实际的html代码,自动拷贝css,
images到相应的目录下,或自动将css合并到一个文件中。然后用户可以在生成好的基础之上进行工作。我想这样可能开始更容易一些。

limodou

unread,
Nov 16, 2006, 11:39:19 PM11/16/06
to pyth...@googlegroups.com
我希望的是更为简单抽象的布局定义
不需要纯动态,可以通过工具组装生成中间结果
相应的静态文件可以自动拷贝
helper的做法是处理更细节的情况。我希望先有一个简单的生成器生成一个框架,然后才是具体的处理。而且我希望尽可能地使用js,ajax的方式来做这些,后台framework只是为了初始化进行必要的干预。

turbogears有时间我看一看,是否与我想象的一致。我想可能不同。因为这里我主要关心的是web前端界面的生成,而不是后端。我希望前后端是分离的。这样可以与后端无关,但又不希望完全手工去做界面,希望有一种相对标准化或简单的方式。

gas...@gmail.com

unread,
Nov 17, 2006, 12:31:15 AM11/17/06
to python.cn
妳的要求
1. 基本可用的web

ui库,如:菜单,工具条,基本控件(checkbox, text, select,
radio,
textarea),布局处理,表格等。

除了布局处理外 tg widgets 都内建了,
yahoo UI 的 grid 跟你上面讲的 syntax 很类似.
可以透過簡單封裝這功能到 tgwidgets 使用 (早有封裝了
http://sourceforge.net/projects/tgwidgets 只是没发布)

2.
创建一种构造工具,也许有自已的格式模板的处理,它不一定要生成最终的结果,但可以创建一个基本可以工作的基础框架,如生成html页面,正确拷贝css,
js,image等信息

tg widgets 都可以做到

3. 前端尽量与后端脱离

> turbogears有时间我看一看,是否与我想象的一致。我想可能不同。因为这里我主要关心的是web前端界面的生成,而不是后端。我希望前后端是分离的。这样可以与后端无关,但又不希望完全手工去做界面,希望有一种相对标准化或简单的方式。
>

> 我希望的是更为简单抽象的布局定义
> 不需要纯动态,可以通过工具组装生成中间结果
> 相应的静态文件可以自动拷贝

tgwidgets 已經做到與後端無關(不必一定得用cherrypy),
所以其他框架如 pylons 也可以利用.

不过就使用目的而言, tgwidgets
的目标是"网页元件重用", 也就是
1. 刚开发中使用网页元素简化表单等生成,
2.
开发到一阶段网页上的元素稳定了后也可以抽取出来成为自订元件,


我自己的想法是透过 tgwidgets 的JSLink, JSSource, CSSLink,
CSSSource 可以把 javascript/CSS 码全拉到 controllers 中撰写,
统一在 controllers 中配置管理.
因此前端样板上完全不用写到动态元素.
搭配上开发伺服器自动重载的机能,
只要簡單的樣板配置後, 其他的活都可以在 controllers
中撰写, 开发的结果則直接观察浏览器.
这种作法理论上可行,
不过这样的开发法也需要时间习惯,
对生产力有没有帮助则见仁见智了,

limodou

unread,
Nov 17, 2006, 12:48:55 AM11/17/06
to pyth...@googlegroups.com
On 11/17/06, gas...@gmail.com <gas...@gmail.com> wrote:
> 妳的要求
> 1. 基本可用的web
> ui库,如:菜单,工具条,基本控件(checkbox, text, select,
> radio,
> textarea),布局处理,表格等。
>
> 除了布局处理外 tg widgets 都内建了,
> yahoo UI 的 grid 跟你上面讲的 syntax 很类似.
> 可以透過簡單封裝這功能到 tgwidgets 使用 (早有封裝了
> http://sourceforge.net/projects/tgwidgets 只是没发布)

yahoo ui 没用过,只是知道,需要关注一下。你的项目没有介绍啊。

>
> 2.
> 创建一种构造工具,也许有自已的格式模板的处理,它不一定要生成最终的结果,但可以创建一个基本可以工作的基础框架,如生成html页面,正确拷贝css,
> js,image等信息
>
> tg widgets 都可以做到

需要例子看一下啊。


>
> 3. 前端尽量与后端脱离
>
> > turbogears有时间我看一看,是否与我想象的一致。我想可能不同。因为这里我主要关心的是web前端界面的生成,而不是后端。我希望前后端是分离的。这样可以与后端无关,但又不希望完全手工去做界面,希望有一种相对标准化或简单的方式。
> >
> > 我希望的是更为简单抽象的布局定义
> > 不需要纯动态,可以通过工具组装生成中间结果
> > 相应的静态文件可以自动拷贝
>
> tgwidgets 已經做到與後端無關(不必一定得用cherrypy),
> 所以其他框架如 pylons 也可以利用.

我所说的与后端无关是指它要处理是前端的界面展示,只是显示部分。


>
> 不过就使用目的而言, tgwidgets
> 的目标是"网页元件重用", 也就是
> 1. 刚开发中使用网页元素简化表单等生成,
> 2.
> 开发到一阶段网页上的元素稳定了后也可以抽取出来成为自订元件,
>

很合理的思路。网页控件的使用只是我希望的其中一个目标,我还希望对css, js有统一的管理,并且对整体页面有一个布局的管理。

>
> 我自己的想法是透过 tgwidgets 的JSLink, JSSource, CSSLink,
> CSSSource 可以把 javascript/CSS 码全拉到 controllers 中撰写,
> 统一在 controllers 中配置管理.
> 因此前端样板上完全不用写到动态元素.
> 搭配上开发伺服器自动重载的机能,
> 只要簡單的樣板配置後, 其他的活都可以在 controllers
> 中撰写, 开发的结果則直接观察浏览器.
> 这种作法理论上可行,
> 不过这样的开发法也需要时间习惯,
> 对生产力有没有帮助则见仁见智了,
>

可能与我不太一样。我不一定需要在运行时动态生成,至少不是每次都动成生成。因为在大多数情况下,页面一旦确定就很少改变了。然后在生成中间物的基础上,再开始开发。效果如果只有做的时候才知道了。因为感觉现在虽然有模板,有别人的项目可以参考,便还做不到非常方便的重用。还需要这copy一段,那copy一段,还要注意相应的css,
js代码要放到正确的地方。虽然你熟悉整个过程,但是还不够方便。还需要更简单一些的组装方式。至少希望在开始某个页面的时候不要改改这,改改那。

在controller中的话,是不是只能运行时才看得到,而且每次都是动态的?

gas...@gmail.com

unread,
Nov 17, 2006, 1:04:54 AM11/17/06
to python.cn
针对Yahoo UI用法回答:

要用 yahoo UI, 要先include以下三个css layout (我都拿 widgets
里的原始码来讲, 不是 javascript)

# Grids
reset_css = CSSLink("yui/reset", "reset.css")
fonts_css = CSSLink("yui/fonts", "fonts.css")
grid_css = CSSLink("yui/grids", "grids.css")

yahoo ui 里有以下几种预设配置 ((左宽度, 右宽度),
main表示放主要内容)

["yui-t1":(160,570main),
"yui-t2":(180,550main),
"yui-t3":(300,430main),
"yui-t4":(550main,180),
"yui-t5":(490main, 240),
"yui-t6":(430main, 300),
"yui-t7":(700center)]

可以互相嵌套產生需要的複雜頁面
http://developer.yahoo.com/yui/grids/docs/media/alternate-grid-containers.gif

實際使用實是這樣定義

<div id="doc" class="yui-t2">
<div id="hd">content header</div>
<div id="bd">
<div id="yui-main">
<div class="yui-b">
<div class="yui-g">
<div class="yui-u first"> first main
body</div>
<div class="yui-u"> main body </div>
</div>
</div>
</div>
<div class="yui-b">sidebar body</div>
</div>
<div id="ft">footer infomation</div>
</div>

当时这样学下来我想并没有比较省时间,
所以就暂时打消发布的念头了.

yi huang

unread,
Nov 17, 2006, 1:26:45 AM11/17/06
to pyth...@googlegroups.com
你讲的东西已经有实做了, TurboGears 的 widgets
(网页元件)就是这样的东西.
装好 TurboGears  后可以启动 TurboGears 网页介面工具箱:

有人在开发不依赖 turbogears 的tgwidgets,没有研究过,貌似不错哦。

--
http://codeplayer.blogspot.com/

limodou

unread,
Nov 17, 2006, 1:31:33 AM11/17/06
to pyth...@googlegroups.com
On 11/17/06, gas...@gmail.com <gas...@gmail.com> wrote:
谢谢解释。

目前可以把Yahoo UI的grid看成是具体的应用实例,但在使用时,你需要自已将这些代码手工加进去。我看到你使用了CSSLink,我想你的目的就是为了不要再手工在模板中加入这些css。我希望与你类似。而且如果有可能的话,具体的工作都在包装好的控件中完成,在初始创建时先不用关心具体的代码,只是一个布局。同时在页面布局中的tag是一个相对完整的对象表示。如<usersignin>表示用户登录代码。那么它可能包含自已的js,
css代码。而我希望,这些js,
css代码在使用工具来构建时,可以自动被挖掘出来,不再需要CSSLink之类的引入。而且对于小片段的css代码还可以考虑是否合并到某一个css文件中。因为有一些小的html片段也有样式的要求,如果都是使用独立的css文件,必须css文件就非常多。因此我想象的构造过程可能是这样的:

1. 首先有一个web ui的标准库
2. 准备一个layout的文件,里面有基本的布局和web控件代码,和其它的片段
3. 运行工具生成一个结果目录

output\
images\
css\
js\
html\

而images, css, js将转到静态目录中去。html作为我工作的起点。如果不考虑结构的大改动,这个工具可以就不用了。以后有一些新的内容的增加,就只在生成的结果上进行。正象我说的,我感觉在一个基础上工作,要比重新创建可能要容易一些。我的方式可能还是在手工为基础,只是希望把手工处理更简单化,特别是在开始的时候。

Zoom.Quiet

unread,
Nov 17, 2006, 1:32:11 AM11/17/06
to pyth...@googlegroups.com
On 11/17/06, limodou <lim...@gmail.com> wrote:
已经是非常深入的讨论了,现在TG,DJ 都在使用自个儿的思路重新对WEB应用开发进行定义,
都与有页面设计师参与的旧开发流程不同,需要深入体验和理解的,
MVC 的分离是一定的,但是是否将V和C 使用Python 整合在一起,实在不是一般程序员可以理解的,
因为至少涉及XHTML+CSS+JS 的多方面知识储备,

所以,这些标准化开发的思路/框架/平台, 都没有很好的回答易用和易学的问题.

只是我们一定要放开心态,多多体验,利用Py 的快捷开发,实现想法,实例验证!

俺是全部支持.

limodou

unread,
Nov 17, 2006, 1:32:24 AM11/17/06
to pyth...@googlegroups.com
On 11/17/06, yi huang <yi.cod...@gmail.com> wrote:
> > 你讲的东西已经有实做了, TurboGears 的 widgets
> > (网页元件)就是这样的东西.
> > 装好 TurboGears 后可以启动 TurboGears 网页介面工具箱:
> >
>
> 有人在开发不依赖 turbogears 的tgwidgets,没有研究过,貌似不错哦。

就是gasolin创建的呀。

limodou

unread,
Nov 17, 2006, 1:38:38 AM11/17/06
to pyth...@googlegroups.com
是的,就是因为web的东西不象一般的程序开发,它的资源信息过于分散,不便于管理。一般一个可重用的app或控件,包括了css, js,
html, images等,需要分别放置到不同的目录下。这一点就很麻烦。再加上没有很标准的web
ui,各自为政,使得在选择哪种框架,哪种风格上也是很麻烦的事。这些对于程序员来说,如我这样的,感觉麻烦。因为我的注意力要分散到不同的地方,而不是集中在一个地方。所以希望有种机制帮助我做一部分工作,这样减少工作量。可以考虑分别实现不同的模型,毕竟使用习惯不同,关注点不同。可能会有一些用处。

gas...@gmail.com

unread,
Nov 17, 2006, 1:39:17 AM11/17/06
to python.cn
> > 2.
> > 创建一种构造工具,也许有自已的格式模板的处理,它不一定要生成最终的结果,但可以创建一个基本可以工作的基础框架,如生成html页面,正确拷贝css,
> > js,image等信息
> >
> > tg widgets 都可以做到
>
> 需要例子看一下啊。

例如上面提到 yui 的封装, 原本要在页面读入三个 css,
改写成 widget 后如下

reset_css = CSSLink("yui/reset", "reset.css")

....

(封裝的是 <style type="text/css">....</style> 這樣的敘述)

class Grids(Widget):
css = [reset_css, fonts_css, grid_css]

要读入其他 javascript 或 template 也是类似写法

from turbogears import mochikit
class demo(Widget):
template =""" a silly demo"""
js = mochikit

要在controllers 中直接回传结果, 可以

def index(self):
demo = demo()
return demo.display()

(display 是直接產生字串, render則是用 generator
到真正用時才產生)

> > tgwidgets 已經做到與後端無關(不必一定得用cherrypy),
> > 所以其他框架如 pylons 也可以利用.
>
> 我所说的与后端无关是指它要处理是前端的界面展示,只是显示部分。
> >
> > 不过就使用目的而言, tgwidgets
> > 的目标是"网页元件重用", 也就是
> > 1. 刚开发中使用网页元素简化表单等生成,
> > 2.
> > 开发到一阶段网页上的元素稳定了后也可以抽取出来成为自订元件,
> >
>
> 很合理的思路。网页控件的使用只是我希望的其中一个目标,我还希望对css, js有统一的管理,并且对整体页面有一个布局的管理。
>
> >
> > 我自己的想法是透过 tgwidgets 的JSLink, JSSource, CSSLink,
> > CSSSource 可以把 javascript/CSS 码全拉到 controllers 中撰写,
> > 统一在 controllers 中配置管理.
> > 因此前端样板上完全不用写到动态元素.
> > 搭配上开发伺服器自动重载的机能,
> > 只要簡單的樣板配置後, 其他的活都可以在 controllers
> > 中撰写, 开发的结果則直接观察浏览器.
> > 这种作法理论上可行,
> > 不过这样的开发法也需要时间习惯,
> > 对生产力有没有帮助则见仁见智了,
> >
> 可能与我不太一样。我不一定需要在运行时动态生成,至少不是每次都动成生成。因为在大多数情况下,页面一旦确定就很少改变了。然后在生成中间物的基础上,再开始开发。效果如果只有做的时候才知道了。因为感觉现在虽然有模板,有别人的项目可以参考,便还做不到非常方便的重用。还需要这copy一段,那copy一段,还要注意相应的css,
> js代码要放到正确的地方。虽然你熟悉整个过程,但是还不够方便。还需要更简单一些的组装方式。至少希望在开始某个页面的时候不要改改这,改改那。
>
> 在controller中的话,是不是只能运行时才看得到,而且每次都是动态的?
>

這樣做確實在运行时才看得到,而且每次都是动态的.

由於 tgwidgets 可以包含js, css, template 各種元素,
所以每頁都寫成一個widgets也是可以的, 只是沒啥意義
XD

如果你擔心的是 template (樣板)的 Layout 問題,
花點時間看看 tg 一般用的 kid 或 genshi 模板,
他們都支持在 replace 塊裡插入任何可見的內容.

<div py:replace="widgets.render()">I'm the king of the world</div>


如果你擔心的是效能問題, 我想運行時 compile 過的
controller.py 速度應該不會比隨用抓取的
靜態檔慢吧(這點只是我的推論而已)

gas...@gmail.com

unread,
Nov 17, 2006, 1:47:14 AM11/17/06
to python.cn
limodou 寫道:

> On 11/17/06, yi huang <yi.cod...@gmail.com> wrote:
> > > 你讲的东西已经有实做了, TurboGears 的 widgets
> > > (网页元件)就是这样的东西.
> > > 装好 TurboGears 后可以启动 TurboGears 网页介面工具箱:
> > >
> >
> > 有人在开发不依赖 turbogears 的tgwidgets,没有研究过,貌似不错哦。
>
> 就是gasolin创建的呀。
>

這是誤會, sourceforge 上的 tgwidgets project 是我創建的,
放的是一些 widgets plugin, 產出都發佈在 cheeseshop.

而這個 tgwidgets 專案是 TurboGears 的一個開發者發起的,
目的是剝離 turbogears widgets 好讓其他 python framework
都可以使用. 原始碼可以在 TG 的 svn 上下載.

limodou

unread,
Nov 17, 2006, 1:48:48 AM11/17/06
to pyth...@googlegroups.com
> 例如上面提到 yui 的封装, 原本要在页面读入三个 css,
> 改写成 widget 后如下
>
> reset_css = CSSLink("yui/reset", "reset.css")
> ....
>
> (封裝的是 <style type="text/css">....</style> 這樣的敘述)
>
> class Grids(Widget):
> css = [reset_css, fonts_css, grid_css]

了解。我想象的Widget类可以包括css, js,
html之类的。而且很有可能每个widget是一个单独的目录,这样不同的内容放在不同的目录下。这样在widgets中不需要csslink这个东西。直接就是css路径就可以了。
>

> > 在controller中的话,是不是只能运行时才看得到,而且每次都是动态的?
> >
>
> 這樣做確實在运行时才看得到,而且每次都是动态的.
>
> 由於 tgwidgets 可以包含js, css, template 各種元素,
> 所以每頁都寫成一個widgets也是可以的, 只是沒啥意義
> XD
>
> 如果你擔心的是 template (樣板)的 Layout 問題,
> 花點時間看看 tg 一般用的 kid 或 genshi 模板,
> 他們都支持在 replace 塊裡插入任何可見的內容.
>
> <div py:replace="widgets.render()">I'm the king of the world</div>

我倒是不担心layout问题,我只是想对手工处理进行辅助,如果能看不到css, js最好,不行的话,就辅助一下。


>
>
> 如果你擔心的是效能問題, 我想運行時 compile 過的
> controller.py 速度應該不會比隨用抓取的
> 靜態檔慢吧(這點只是我的推論而已)
>

不是主要由于性能的考虑,主要是希望把分散的小片段(html,js,
css)有机地合成一个整体,然后在这个基础之上进行工作。如果全都在controller中做,如何处理js是一个大问题。也许象pyjamas一样,将python代码转为js代码是一条路,但并不容易。

limodou

unread,
Nov 17, 2006, 1:49:33 AM11/17/06
to pyth...@googlegroups.com
On 11/17/06, gas...@gmail.com <gas...@gmail.com> wrote:
哦。因为我看项目创建是你,以为就是你创建的呢。

yi huang

unread,
Nov 17, 2006, 3:05:14 AM11/17/06
to pyth...@googlegroups.com
哦。因为我看项目创建是你,以为就是你创建的呢。
tgwidgets 非彼 tgwidgets
呵呵



--
http://codeplayer.blogspot.com/

gas...@gmail.com

unread,
Nov 17, 2006, 3:33:58 AM11/17/06
to python.cn
> 了解。我想象的Widget类可以包括css, js,
> html之类的。而且很有可能每个widget是一个单独的目录,这样不同的内容放在不同的目录下。
这样在widgets中不需要csslink这个东西。直接就是css路径就可以了。
> >

Widget 类确实可以同時包括 css, js,html(叫做 template)
之类的, 不用各自再进行封装.
我將 css, js 包起来只是照着惯例.
你讲的每个 widget 是一个单独的目录当然也是可以的,
widget plugin 都是这么做的.

使用者要做的只是 import widget plugin,
然后在 template 里 render 它.
(或是更 MVC 一點: 在 controllers 裡 import, 設定參數,
然後傳給 template 顯示)

所以在 TurboGears 中網頁架構可以長成這樣:


class Root(...):
def index(self):
....
data = datacontroller()
edit = editcontroller()

訪問 http://localhost:8080/data, http://localhost:8080/edit
会分别带到两个页面.
这两个页面也可以全以 widget 写成 (这是你的自由,
不过这样就一点都不 MVC 了).

widget 对应到的是 V,C.
例如有了表单显示自然就会有验证的需求,
只生成前端介面还是有遗憾的.
因此创建 widget 表单元件时可以顺便加上 validator
验证(可选).


>
> 我倒是不担心layout问题,我只是想对手工处理进行辅助,如果能看不到css, js最好,不行的话,就辅助一下。
> >
> >
> > 如果你擔心的是效能問題, 我想運行時 compile 過的
> > controller.py 速度應該不會比隨用抓取的
> > 靜態檔慢吧(這點只是我的推論而已)
> >
>
> 不是主要由于性能的考虑,主要是希望把分散的小片段(html,js,
> css)有机地合成一个整体,然后在这个基础之上进行工作。如果全都在controller中做,如何处理js是一个大问题。也许象pyjamas一样,将python代码转为js代码是一条路,但并不容易。

你可以将 widget 想成是 web 的 OO.
这样可以在 widgets 里将基本的 css, js, template 元素组合,
经过嵌套成为功能较强的元件.

widget 到目前为止没有一份好的教程,
一方面是因为所有原始码都可以透过 widget browser 观看,

一方面也是 widget 的使用方式太多,
自由度非常高的原因吧.
(TurboGears 刚出版的书中有目前最详细的教程)

Zoom.Quiet

unread,
Nov 17, 2006, 4:04:09 AM11/17/06
to pyth...@googlegroups.com
On 11/17/06, gas...@gmail.com <gas...@gmail.com> wrote:
有专门的书了哪!!! 可是中文的不知道什么时候了,
有电子版本的下载!?

limodou

unread,
Nov 17, 2006, 4:15:09 AM11/17/06
to pyth...@googlegroups.com
On 11/17/06, gas...@gmail.com <gas...@gmail.com> wrote:
> > 了解。我想象的Widget类可以包括css, js,
> > html之类的。而且很有可能每个widget是一个单独的目录,这样不同的内容放在不同的目录下。
> 这样在widgets中不需要csslink这个东西。直接就是css路径就可以了。
> > >
>
> Widget 类确实可以同時包括 css, js,html(叫做 template)
> 之类的, 不用各自再进行封装.
> 我將 css, js 包起来只是照着惯例.
> 你讲的每个 widget 是一个单独的目录当然也是可以的,
> widget plugin 都是这么做的.
>
> 使用者要做的只是 import widget plugin,
> 然后在 template 里 render 它.
> (或是更 MVC 一點: 在 controllers 裡 import, 設定參數,
> 然後傳給 template 顯示)
>
> 所以在 TurboGears 中網頁架構可以長成這樣:
>
>
> class Root(...):
> def index(self):
> ....
> data = datacontroller()
> edit = editcontroller()
>
> 訪問 http://localhost:8080/data, http://localhost:8080/edit
> 会分别带到两个页面.
> 这两个页面也可以全以 widget 写成 (这是你的自由,
> 不过这样就一点都不 MVC 了).

这是一种方式,不过这样的话,手工的js代码要写在哪里。还有不知道tg是如何处理plugin目录下的js,
css文件的。是否会自动拷贝到静态目录下,还是就是放在哪里不动?可能对于django和tg这是两种不同的想法。对于django来说,静态文件与程序文件不是在一起的,所以我需要组装的方式,如果tg是放在一起的,可能就不怎么需要我所说的方式。


>
> widget 对应到的是 V,C.
> 例如有了表单显示自然就会有验证的需求,
> 只生成前端介面还是有遗憾的.
> 因此创建 widget 表单元件时可以顺便加上 validator
> 验证(可选).
>

验证不是太大问题。可以有js的验证,同时后台也有自已的验证。


>
> >
> > 我倒是不担心layout问题,我只是想对手工处理进行辅助,如果能看不到css, js最好,不行的话,就辅助一下。
> > >
> > >
> > > 如果你擔心的是效能問題, 我想運行時 compile 過的
> > > controller.py 速度應該不會比隨用抓取的
> > > 靜態檔慢吧(這點只是我的推論而已)
> > >
> >
> > 不是主要由于性能的考虑,主要是希望把分散的小片段(html,js,
> > css)有机地合成一个整体,然后在这个基础之上进行工作。如果全都在controller中做,如何处理js是一个大问题。也许象pyjamas一样,将python代码转为js代码是一条路,但并不容易。
>
> 你可以将 widget 想成是 web 的 OO.
> 这样可以在 widgets 里将基本的 css, js, template 元素组合,
> 经过嵌套成为功能较强的元件.

是的。不过你所说的这种组合是在运行时,而我所说的可能是静态的,不是运行时的组合。角度不太一样。


>
> widget 到目前为止没有一份好的教程,
> 一方面是因为所有原始码都可以透过 widget browser 观看,
>
> 一方面也是 widget 的使用方式太多,
> 自由度非常高的原因吧.
> (TurboGears 刚出版的书中有目前最详细的教程)
>

的确。这是一个问题。所以我想可能许多工作在没有很好解决的情况下,还是要靠手工来做,所以不需要全部由frameworks都给我解决。

gas...@gmail.com

unread,
Nov 17, 2006, 5:30:38 AM11/17/06
to python.cn
limodou 寫道:
>
> 这是一种方式,不过这样的话,手工的js代码要写在哪里。还有不知道tg是如何处理plugin目录下的js,

1. handcode = JSSource("手工的js代码") ....... :-D

2. plugin 目录下的 js 透过 pkg_resources.require("project")
要求, 基本上可以放在任何地方.
如果是只在自己的专案下用的话, 一般是连到预设的
static 目录: /static/css 下.


> css文件的。是否会自动拷贝到静态目录下,还是就是放在哪里不动?可能对于django和tg这是两种不同的想法。对于django来说,静态文件与程序文件不是在一起的,所以我需要组装的方式,如果tg是放在一起的,可能就不怎么需要我所说的方式。

不会, 放在静态目录 /static 下的资料不会变动. 如果是
plugin 的话一般使用上不用考虑 css 放置位置,
会自动以适当连结连结到网页上, 原始档案还是在
plugin 的资料夹里, 不会污染专案.


> > > 不是主要由于性能的考虑,主要是希望把分散的小片段(html,js,
> > > css)有机地合成一个整体,然后在这个基础之上进行工作。如果全都在controller中做,如何处理js是一个大问题。也许象pyjamas一样,将python代码转为js代码是一条路,但并不容易。

> >
> > 你可以将 widget 想成是 web 的 OO.
> > 这样可以在 widgets 里将基本的 css, js, template 元素组合,
> > 经过嵌套成为功能较强的元件.
>
> 是的。不过你所说的这种组合是在运行时,而我所说的可能是静态的,不是运行时的组合。角度不太一样。
> >

等於把 render 结果保存成静态页嗎?
做起来应该不是很困难,
但是要一般化到大家都适用就不容易了.

limodou

unread,
Nov 17, 2006, 8:11:47 AM11/17/06
to pyth...@googlegroups.com
On 11/17/06, gas...@gmail.com <gas...@gmail.com> wrote:
> limodou 寫道:
> >
> > 这是一种方式,不过这样的话,手工的js代码要写在哪里。还有不知道tg是如何处理plugin目录下的js,
>
> 1. handcode = JSSource("手工的js代码") ....... :-D

知道了。但修改起来,还有不方便非程序员编写。


>
> 2. plugin 目录下的 js 透过 pkg_resources.require("project")
> 要求, 基本上可以放在任何地方.
> 如果是只在自己的专案下用的话, 一般是连到预设的
> static 目录: /static/css 下.
>

这样的话,它是通过setuptools来找到相应的文件位置。如果是静态目录的话,还是需要手工拷贝。


>
> > css文件的。是否会自动拷贝到静态目录下,还是就是放在哪里不动?可能对于django和tg这是两种不同的想法。对于django来说,静态文件与程序文件不是在一起的,所以我需要组装的方式,如果tg是放在一起的,可能就不怎么需要我所说的方式。
>
> 不会, 放在静态目录 /static 下的资料不会变动. 如果是
> plugin 的话一般使用上不用考虑 css 放置位置,
> 会自动以适当连结连结到网页上, 原始档案还是在
> plugin 的资料夹里, 不会污染专案.
>

这一点可能与js相似。不过我还设置会有会有可能把控件的css合并到某个文件中呢?减少css文件的个数,只是一个想法。


>
> > > > 不是主要由于性能的考虑,主要是希望把分散的小片段(html,js,
> > > > css)有机地合成一个整体,然后在这个基础之上进行工作。如果全都在controller中做,如何处理js是一个大问题。也许象pyjamas一样,将python代码转为js代码是一条路,但并不容易。
>
> > >
> > > 你可以将 widget 想成是 web 的 OO.
> > > 这样可以在 widgets 里将基本的 css, js, template 元素组合,
> > > 经过嵌套成为功能较强的元件.
> >
> > 是的。不过你所说的这种组合是在运行时,而我所说的可能是静态的,不是运行时的组合。角度不太一样。
> > >
>
> 等於把 render 结果保存成静态页嗎?
> 做起来应该不是很困难,
> 但是要一般化到大家都适用就不容易了.
>

是的。所以我说咱俩的目的可能不同。我是在render之后的基础上开始工作。而不是完全依赖自动生成最终结果。在很多情况下,这是最理想的,但是很难实现。而我可能只需要有一个可以简单工作的开始,所以可以在生成的结果之上开始工作,它可能不是最终的结果。

这是两种思路。我还是以手工修改为主,而你的思路是创建一次,直接得到最终的结果,因此许多东西都要封装并处理。主要是感觉太理想化,工作量太大。至少django目前根本没有类似的web
ui的机制。

gas...@gmail.com

unread,
Nov 17, 2006, 9:23:59 AM11/17/06
to python.cn
> > 1. handcode = JSSource("手工的js代码") ....... :-D
>
> 知道了。但修改起来,还有不方便非程序员编写。
> >

widgets 给非程序员的感觉应该就是 widgets browser
上那些像 dreamweaver 网页编辑器的预设网页/表单元件,
再进一步深入则是 Delphi, VB 程序员习惯的 rad
工具控件.

自订义 widgets 的方式肯定是面对程序员的.


我在試功能的时候连 template 都不怎么喜欢用, 像
karringell 一样用 string 写在 controllers 里就好了,
不用管什么网页介面 , MVC, URL mapper 之类的.
反正你知道各种工具都在那里,
要照什么顺序开发怎么走可以随自己喜好决定.

> >
> 这样的话,它是通过setuptools来找到相应的文件位置。如果是静态目录的话,还是需要手工拷贝。

对那是 plugin的状况(比较复杂的情况),

如果是只在自己的专案下用的话, 把 JS 档放到预设的
static 目录: /static/javascript 下, 可以直接指定
/static/javascriptJS 档路径, 用不著手工拷贝.


> 这一点可能与js相似。不过我还设置会有会有可能把控件的css合并到某个文件中呢?减少css文件的个数,只是一个想法。
> >

有点懂你的意思, 你的想法是要有一个 spider
爬过全站用到的 css, js,
将用到的都先组织好成单一文件吗?听起来真的非预先编译效果才好.

limodou

unread,
Nov 17, 2006, 9:36:23 AM11/17/06
to pyth...@googlegroups.com
On 11/17/06, gas...@gmail.com <gas...@gmail.com> wrote:
> > > 1. handcode = JSSource("手工的js代码") ....... :-D
> >
> > 知道了。但修改起来,还有不方便非程序员编写。
> > >
>
> widgets 给非程序员的感觉应该就是 widgets browser
> 上那些像 dreamweaver 网页编辑器的预设网页/表单元件,
> 再进一步深入则是 Delphi, VB 程序员习惯的 rad
> 工具控件.
>
> 自订义 widgets 的方式肯定是面对程序员的.

其实我也喜欢纯程序的方式,但是感觉很麻烦,好象也不是很现实。主要是需要做许多封装的工作,这样对封装后的东西的维护也是一个大的问题。比如使用了一些ajax库的话,也许我更希望使用js来进行web
ui的展示。


>
>
> 我在試功能的时候连 template 都不怎么喜欢用, 像
> karringell 一样用 string 写在 controllers 里就好了,
> 不用管什么网页介面 , MVC, URL mapper 之类的.
> 反正你知道各种工具都在那里,
> 要照什么顺序开发怎么走可以随自己喜好决定.
>

我现在是希望尽量脱离后端。

> > >
> > 这样的话,它是通过setuptools来找到相应的文件位置。如果是静态目录的话,还是需要手工拷贝。
>
> 对那是 plugin的状况(比较复杂的情况),
>
> 如果是只在自己的专案下用的话, 把 JS 档放到预设的
> static 目录: /static/javascript 下, 可以直接指定
> /static/javascriptJS 档路径, 用不著手工拷贝.

因为在维护上plugin的目录不会直接在静态目录下,因此有一个拷贝的动作,我希望通过某种模板的定义,自动来完成。


>
>
> > 这一点可能与js相似。不过我还设置会有会有可能把控件的css合并到某个文件中呢?减少css文件的个数,只是一个想法。
> > >
>
> 有点懂你的意思, 你的想法是要有一个 spider
> 爬过全站用到的 css, js,
> 将用到的都先组织好成单一文件吗?听起来真的非预先编译效果才好.
>

我倒不是说把所有的文件弄成单一文件,目前还只是一个想法,特别是针对css和js。而且也不一定是放到一个文件中,可能一个页面一个就行了。先要预处理,然后在这个基础上开始我的工作。但这时框架已经基本有雏型了,也省了不少的工作。

Reply all
Reply to author
Forward
0 new messages