[OT]关于点子 及 [IDEA]如何让web界面标准化
limodou
我想如果我有一些什么想法，哪怕是不成熟不正确的想法，有人交流是非常好的事情。
[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
> 其实许多人对于技术都有不同的想法，但有些时候是在心里默默去想，随着时间的推移，要么无力去实现，要么不再有兴趣。不过我认为某些想法可能是非常有用的。因此我倡议有兴趣的可以讨论一下"点子(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
它0.3版本的目标是包装第三方的js widgets库。
0.4版本的目标是开发一套 mock DOM library ，这样可以对python代码直接进行测试，而不用生成js后在浏览器里测试了。
另外一种方法是，类似pylons里的helper库，这种简单些。
--
http://codeplayer.blogspot.com/
gas...@gmail.com
(网页元件)就是这样的东西.
装好 TurboGears 后可以启动 TurboGears 网页介面工具箱:
$ tg-admin toolbox
工具箱里有 widgets browser (网页元件浏览器),
列出目前所支援的所有 widgets (网页元件)
还有这些元件如何使用的说明.
这些网页元件可以简单地自行订制,
包含有表单的订制(包含各种基础的表单元件),
语法高亮, TinyMCE 编辑器封装等等.
对于表单来说, 甚至还提供 validator (表单格式验证)
功能.
用 TurboGears widgets 封装 JS 库实在相当容易.
我自己封装过 scriptaculous, moo.fx 库, PlotKit (JS 的绘图库)
这些plugin,
可以在 cheeseshop 上找到.
开发中的版本 tgwidgets 可以独立在 TurboGears 外使用
limodou
> 我看从 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
不需要纯动态，可以通过工具组装生成中间结果
相应的静态文件可以自动拷贝
helper的做法是处理更细节的情况。我希望先有一个简单的生成器生成一个框架，然后才是具体的处理。而且我希望尽可能地使用js,ajax的方式来做这些，后台framework只是为了初始化进行必要的干预。
turbogears有时间我看一看，是否与我想象的一致。我想可能不同。因为这里我主要关心的是web前端界面的生成，而不是后端。我希望前后端是分离的。这样可以与后端无关，但又不希望完全手工去做界面，希望有一种相对标准化或简单的方式。
gas...@gmail.com
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
> 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
要用 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
你讲的东西已经有实做了, TurboGears 的 widgets
(网页元件)就是这样的东西.
装好 TurboGears 后可以启动 TurboGears 网页介面工具箱:
--
http://codeplayer.blogspot.com/
limodou
目前可以把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
都与有页面设计师参与的旧开发流程不同,需要深入体验和理解的,
MVC 的分离是一定的,但是是否将V和C 使用Python 整合在一起,实在不是一般程序员可以理解的,
因为至少涉及XHTML+CSS+JS 的多方面知识储备,
所以,这些标准化开发的思路/框架/平台, 都没有很好的回答易用和易学的问题.
只是我们一定要放开心态,多多体验,利用Py 的快捷开发,实现想法,实例验证!
俺是全部支持.
limodou
> > (网页元件)就是这样的东西.
> > 装好 TurboGears 后可以启动 TurboGears 网页介面工具箱:
> >
>
> 有人在开发不依赖 turbogears 的tgwidgets，没有研究过，貌似不错哦。
就是gasolin创建的呀。
limodou
html, images等，需要分别放置到不同的目录下。这一点就很麻烦。再加上没有很标准的web
ui，各自为政，使得在选择哪种框架，哪种风格上也是很麻烦的事。这些对于程序员来说，如我这样的，感觉麻烦。因为我的注意力要分散到不同的地方，而不是集中在一个地方。所以希望有种机制帮助我做一部分工作，这样减少工作量。可以考虑分别实现不同的模型，毕竟使用习惯不同，关注点不同。可能会有一些用处。
gas...@gmail.com
> > 创建一种构造工具，也许有自已的格式模板的处理，它不一定要生成最终的结果，但可以创建一个基本可以工作的基础框架，如生成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
> 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
> 改写成 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
yi huang
gas...@gmail.com
> 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
limodou
> > 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
>
> 这是一种方式，不过这样的话，手工的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
> >
> > 这是一种方式，不过这样的话，手工的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
>
> 知道了。但修改起来，还有不方便非程序员编写。
> >
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
> >
> > 知道了。但修改起来，还有不方便非程序员编写。
> > >
>
> 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。而且也不一定是放到一个文件中，可能一个页面一个就行了。先要预处理，然后在这个基础上开始我的工作。但这时框架已经基本有雏型了，也省了不少的工作。