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

> [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

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

> $ tg-admin toolbox

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

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

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

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

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

> 除了布局处理外 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
> 中撰写, 开发的结果則直接观察浏览器.
> 这种作法理论上可行,
> 不过这样的开发法也需要时间习惯,
> 对生产力有没有帮助则见仁见智了,

> 要用 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-contai...

> 實際使用實是這樣定義

> <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>

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

> > 除了布局处理外 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中的话，是不是只能运行时才看得到，而且每次都是动态的？

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

> > > 除了布局处理外 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中的话，是不是只能运行时才看得到，而且每次都是动态的？

> 已经是非常深入的讨论了,现在TG,DJ 都在使用自个儿的思路重新对WEB应用开发进行定义,
> 都与有页面设计师参与的旧开发流程不同,需要深入体验和理解的,
> MVC 的分离是一定的,但是是否将V和C 使用Python 整合在一起,实在不是一般程序员可以理解的,
> 因为至少涉及XHTML+CSS+JS 的多方面知识储备,

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

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

> 俺是全部支持.

> > tg widgets 都可以做到

> 需要例子看一下啊。

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

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

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

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

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

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

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

> 就是gasolin创建的呀。

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

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

> class Grids(Widget):
>     css = [reset_css, fonts_css, grid_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>

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

> > On 11/17/06, yi huang <yi.codepla...@gmail.com> wrote:
> > > > 你讲的东西已经有实做了, TurboGears 的 widgets
> > > > (网页元件)就是这样的东西.
> > > > 装好 TurboGears  后可以启动 TurboGears 网页介面工具箱:

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

> > 就是gasolin创建的呀。

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

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

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

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

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

> 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一样，将py thon代码转为js代码是一条路，但并不容易。

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

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

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

> 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一样，将py thon代码转为js代码是一条路，但并不容易。

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

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

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

> 这是一种方式，不过这样的话，手工的js代码要写在哪里。还有不知道tg是如何处理plugin目录下的js,

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

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

> > 这是一种方式，不过这样的话，手工的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一样，将py thon代码转为js代码是一条路，但并不容易。

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

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

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

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

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