[CPyUG] 鲁班 (luban) 1.0.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

[CPyUG] 鲁班 (luban) 1.0.0

linjiao
刚刚发布了:http://lubanui.org

本版本主要支持python 3.1+。 目前对 python 2.x 的支持还是实验性的。

请试试:

 $ pip install luban

理念:http://www.lubanui.org/current/philosophy.html
Tutorials: http://www.lubanui.org/current/user-tutorials.html

非常欢迎您的意见,建议,和指出任何问题。非常感谢!


相关链接:早期 0.2 版在python-cn的发布:
http://groups.google.com/group/python-cn/browse_thread/thread/f616875a80ba7810/bb903663197ee70b

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

Re: [CPyUG] 鲁班 (luban) 1.0.0

Zoom.Quiet
在 2011年12月30日 下午3:23,linjiao <[hidden email]> 写道:
> 刚刚发布了:http://lubanui.org
>
> 本版本主要支持python 3.1+。 目前对 python 2.x 的支持还是实验性的。
>

- 哗!! 这应该是第一个专注 py3 的应用框架了吧!
值得学习!

> 请试试:
>
>  $ pip install luban
>
> 理念:http://www.lubanui.org/current/philosophy.html
> Tutorials: http://www.lubanui.org/current/user-tutorials.html
>
> 非常欢迎您的意见,建议,和指出任何问题。非常感谢!
>
>
> 相关链接:早期 0.2 版在python-cn的发布:
> http://groups.google.com/group/python-cn/browse_thread/thread/f616875a80ba7810/bb903663197ee70b
>


--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
文字协议: http://creativecommons.org/licenses/by-sa/2.5/cn/

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

[CPyUG] Re: 鲁班 (luban) 1.0.0

linjiao
On Dec 29, 11:29 pm, "Zoom.Quiet" <[hidden email]> wrote:
> - 哗!! 这应该是第一个专注 py3 的应用框架了吧!

谢谢关注!

http://www.pylatte.org/ 有可能是第一个python3 specific web framework,是一个韩国人开发
的。

不过我觉得鲁班不是一个web framework。我一直希望能把它当作一种"语言"来看待。

--Jiao

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

Re: [CPyUG] Re: 鲁班 (luban) 1.0.0

sj l
 不太喜欢pylatte,鲁班倒看起来很好玩

2011/12/30 linjiao <[hidden email]>
On Dec 29, 11:29 pm, "Zoom.Quiet" <[hidden email]> wrote:
> - 哗!! 这应该是第一个专注 py3 的应用框架了吧!

谢谢关注!

http://www.pylatte.org/ 有可能是第一个python3 specific web framework,是一个韩国人开发
的。

不过我觉得鲁班不是一个web framework。我一直希望能把它当作一种"语言"来看待。

--Jiao

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

Re: [CPyUG] Re: 鲁班 (luban) 1.0.0

zw g
膜拜一下牛人先。

感谢你的探索和改进,请一定坚定、坚持!

我以为,一定是需要这种Think Different的动机的,这样才能促发伟大的事物的诞生。
请坚持。

Gui


2011/12/30 sj l <[hidden email]>
 不太喜欢pylatte,鲁班倒看起来很好玩


2011/12/30 linjiao <[hidden email]>
On Dec 29, 11:29 pm, "Zoom.Quiet" <[hidden email]> wrote:
> - 哗!! 这应该是第一个专注 py3 的应用框架了吧!

谢谢关注!

http://www.pylatte.org/ 有可能是第一个python3 specific web framework,是一个韩国人开发
的。

不过我觉得鲁班不是一个web framework。我一直希望能把它当作一种"语言"来看待。

--Jiao

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

Re: [CPyUG] Re: 鲁班 (luban) 1.0.0

sgra ekim
不需要去支持py2啊。兼容性代码看起来很讨厌啊。
 
在 2011年12月30日 下午5:17,zw g <[hidden email]>写道:
膜拜一下牛人先。

感谢你的探索和改进,请一定坚定、坚持!

我以为,一定是需要这种Think Different的动机的,这样才能促发伟大的事物的诞生。
请坚持。

Gui



2011/12/30 sj l <[hidden email]>
 不太喜欢pylatte,鲁班倒看起来很好玩


2011/12/30 linjiao <[hidden email]>
On Dec 29, 11:29 pm, "Zoom.Quiet" <[hidden email]> wrote:
> - 哗!! 这应该是第一个专注 py3 的应用框架了吧!

谢谢关注!

http://www.pylatte.org/ 有可能是第一个python3 specific web framework,是一个韩国人开发
的。

不过我觉得鲁班不是一个web framework。我一直希望能把它当作一种"语言"来看待。

--Jiao

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

Re: [CPyUG] Re: 鲁班 (luban) 1.0.0

Zoom.Quiet
mac 中通过 brew 安�b时, pip 本身出�e,看来要等等,,,

在 2011年12月30日 下午7:18,Sgra Ekim <[hidden email]> 写道:

> 不需要去支持py2啊。兼容性代码看起来很讨厌啊。
>
> 在 2011年12月30日 下午5:17,zw g <[hidden email]>写道:
>
>> 膜拜一下牛人先。
>>
>> 感谢你的探索和改进,请一定坚定、坚持!
>>
>> 我以为,一定是需要这种Think Different的动机的,这样才能促发伟大的事物的诞生。
>> 请坚持。
>>
>> Gui
>>
>>
>>
>> 2011/12/30 sj l <[hidden email]>
>>>
>>>  不太喜欢pylatte,鲁班倒看起来很好玩
>>>
>>>
>>> 2011/12/30 linjiao <[hidden email]>
>>>>
>>>> On Dec 29, 11:29 pm, "Zoom.Quiet" <[hidden email]> wrote:
>>>> > - 哗!! 这应该是第一个专注 py3 的应用框架了吧!
>>>>
>>>> 谢谢关注!
>>>>
>>>> http://www.pylatte.org/ 有可能是第一个python3 specific web framework,是一个韩国人开发
>>>> 的。
>>>>
>>>> 不过我觉得鲁班不是一个web framework。我一直希望能把它当作一种"语言"来看待。
>>>>
>>>> --Jiao
>>>>
>>>> --
>>>> 来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
>>>> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>>>> 发言: [hidden email]
>>>> 退订: [hidden email] (向此发空信即退!)
>>>> 详情: http://code.google.com/p/cpyug/wiki/PythonCn
>>>> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>>>> 强烈: 建议使用技巧: 如何有效地报告Bug
>>>> http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
>>>
>>>
>>> --
>>> 来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
>>> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>>> 发言: [hidden email]
>>> 退订: [hidden email] (向此发空信即退!)
>>> 详情: http://code.google.com/p/cpyug/wiki/PythonCn
>>> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>>> 强烈: 建议使用技巧: 如何有效地报告Bug
>>> http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
>>
>>
>> --
>> 来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
>> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>> 发言: [hidden email]
>> 退订: [hidden email] (向此发空信即退!)
>> 详情: http://code.google.com/p/cpyug/wiki/PythonCn
>> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>> 强烈: 建议使用技巧: 如何有效地报告Bug
>> http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
>
>
> --
> 来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
> 发言: [hidden email]
> 退订: [hidden email] (向此发空信即退!)
> 详情: http://code.google.com/p/cpyug/wiki/PythonCn
> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
> 强烈: 建议使用技巧: 如何有效地报告Bug
> http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html



--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
文字协议: http://creativecommons.org/licenses/by-sa/2.5/cn/

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

[CPyUG] Re: 鲁班 (luban) 1.0.0

tocer
In reply to this post by linjiao
很有意思的项目。想问几个问题

1 从 0.2 到 1.0 有那些重大变化
2 有那些实际的项目在用luban,给个网址看看

谢谢


On Dec 30, 3:23 pm, linjiao <[hidden email]> wrote:

> 刚刚发布了:http://lubanui.org
>
> 本版本主要支持python 3.1+。 目前对 python 2.x 的支持还是实验性的。
>
> 请试试:
>
>  $ pip install luban
>
> 理念:http://www.lubanui.org/current/philosophy.html
> Tutorials:http://www.lubanui.org/current/user-tutorials.html
>
> 非常欢迎您的意见,建议,和指出任何问题。非常感谢!
>
> 相关链接:早期 0.2 版在python-cn的发布:http://groups.google.com/group/python-cn/browse_thread/thread/f616875...

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

[CPyUG] Re: 鲁班 (luban) 1.0.0

linjiao
In reply to this post by sgra ekim
就我个人来说,我也不大觉得python2兼容性很重要。而且就像你所说的,写兼容性代码很讨厌,也很可能将来不好维护。但是我有一些合作者必须在
python2下工作。所以只好花了点时间做了这个。

我刚刚开了一个survey: http://www.surveymonkey.com/s/HSTM3TX
其中有问到python2的重要性。可否请你(和其他对鲁班有兴趣的朋友)在那儿回答一下几个小问题。

象这样的问题(支持python 2与否),其实我很难做出educated decision. 我需要你们的帮助。通过你们的回答,我才能知道那些
feature是你们真正需要的。你们的input可以帮我决定将来鲁班的发展方向。非常感谢!


On Dec 30, 3:18 am, Sgra Ekim <[hidden email]> wrote:

> 不需要去支持py2啊。兼容性代码看起来很讨厌啊。
>
> 在 2011年12月30日 下午5:17,zw g <[hidden email]>写道:
>
>
>
>
>
>
>
> > 膜拜一下牛人先。
>
> > 感谢你的探索和改进,请一定坚定、坚持!
>
> > 我以为,一定是需要这种Think Different的动机的,这样才能促发伟大的事物的诞生。
> > 请坚持。
>
> > Gui
>
> > 2011/12/30 sj l <[hidden email]>
>
> >>  不太喜欢pylatte,鲁班倒看起来很好玩
>
> >> 2011/12/30 linjiao <[hidden email]>
>
> >>> On Dec 29, 11:29 pm, "Zoom.Quiet" <[hidden email]> wrote:
> >>> > - 哗!! 这应该是第一个专注 py3 的应用框架了吧!
>
> >>> 谢谢关注!
>
> >>>http://www.pylatte.org/有可能是第一个python3 specific web framework,是一个韩国人开发
> >>> 的。
>
> >>> 不过我觉得鲁班不是一个web framework。我一直希望能把它当作一种"语言"来看待。
>
> >>> --Jiao
>
> >>> --
> >>> 来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
> >>> 规则:http://code.google.com/p/cpyug/wiki/PythonCn
> >>> 发言: [hidden email]
> >>> 退订: [hidden email] (向此发空信即退!)
> >>> 详情:http://code.google.com/p/cpyug/wiki/PythonCn
> >>> 严正: 理解列表! 智慧提问!http://wiki.woodpecker.org.cn/moin/AskForHelp
> >>> 强烈: 建议使用技巧: 如何有效地报告Bug
> >>>http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
>
> >>  --
> >> 来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
> >> 规则:http://code.google.com/p/cpyug/wiki/PythonCn
> >> 发言: [hidden email]
> >> 退订: [hidden email] (向此发空信即退!)
> >> 详情:http://code.google.com/p/cpyug/wiki/PythonCn
> >> 严正: 理解列表! 智慧提问!http://wiki.woodpecker.org.cn/moin/AskForHelp
> >> 强烈: 建议使用技巧: 如何有效地报告Bug
> >>http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
>
> >  --
> > 来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
> > 规则:http://code.google.com/p/cpyug/wiki/PythonCn
> > 发言: [hidden email]
> > 退订: [hidden email] (向此发空信即退!)
> > 详情:http://code.google.com/p/cpyug/wiki/PythonCn
> > 严正: 理解列表! 智慧提问!http://wiki.woodpecker.org.cn/moin/AskForHelp
> > 强烈: 建议使用技巧: 如何有效地报告Bug
> >http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

[CPyUG] Re: 鲁班 (luban) 1.0.0

linjiao
In reply to this post by Zoom.Quiet
On Dec 30, 4:08 am, "Zoom.Quiet" <[hidden email]> wrote:
> mac 中通过 brew 安�b时, pip 本身出�e,看来要等等,,,

谢谢测试!
不好意思我没有用过brew.我试过在mac (10.6.8)上用pip (for python3)直接装,是可以的。请问你是用的哪个
python版本?python2 我只测试过2.7。
有空请帮忙report this bug: https://bugs.launchpad.net/luban/+filebug
谢谢。

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

[CPyUG] Re: 鲁班 (luban) 1.0.0

CJ-19
In reply to this post by linjiao
我有一些想法和建议,可能和luban的发展方向有悖。根据我的前端开发经验,Web应用常常陷入这样的境地,即,一开始,后端开发人员不懂前端开发技
术,可能有一点JS、CSS技能,但还不够专业,为了生成UI方便,就使用了一些"通过后端代码生成前端代码"的库或框架,譬如用Python写一个
TabPage的类,addTabPage(title="XXX"),然后前端生成jQueryUI或ExtJS的Tab。典型的GWT是属于这一类
的东西。但后来,业务或Art上要求对Tab页的外观做一些定制,或加入一些复杂的交互逻辑,这时,后端开发人员就完全无从下手了,因为这些改动很多可
能是对CSS的改动甚至是对使用的JS框架的一些hack,这时他们就去找所谓的"专业前端工程师",然后F2E过来一看,哇,GWT创建了一个毫无作
用仅用于布局的Panel就嵌套了四五个div,然后F2E就吐血了。这时怎么办呢?只能对前端进行重构,不使用GWT创建UI。
所以,第一点,我对luban的理解,就是,它的应用范围是有很大的限制的。类似有人对django的评价,适合于中型项目,但不适合小型项目和大型项
目。(比如我们在使用django form时发现,as_p,as_table方法,不用为好,用form的原因只在于将表单验证逻辑和view分
开,绝不能指望django生成HTML或JS代码......我们甚至发现,因为django form的as_xxx方法,有程序员为了方便就将一大串
HTML写成字符串写到python代码中,这样在页面中生成一个input,前端开发人员想给它加个ID,都得去改python代码)
第二点,就是所说的通用UI描述语言。关于这一点,用python做这件事,有点类似于XML,像MS .NET的XAML,及QT中的QML,现在的
趋势是用XML描述UI,就像是WEB中的MVC,让描述语言去做描述的事,让编程语言做编程的事,各干各的,自得其乐。现在让python做描述语言
的事,我看了代码,发现也全是dict,无非是一个树形结构,真正在"写python"的又较少,所以,个人理解,描述UI,相比较python中的
dict,class,YAML,XML语法岂不是更好?另外,所谓MVC,用python写UI,又容易造成UI与业务逻辑混杂在一起的不好的结果,
一页Python代码,发现全是GUI,但不对,竟然其中还有JAVASCRIPT代码。。。。----"阻止程序员犯错"。从另一方面看,一种通用的描述
语言就意味着牺牲特定平台的功能(Swing啊)。我想没有前端开发经验的Python程序员不了解JS编程之道的----不了解UI交互、浏览器中异步编
程的错误处理,他们不会知道为何一个JSONP请求有时会说JS代码语法错误,为何一个click事件会被不断触发,何时需要将某个DOM操作排队异步
处理。(相比较而言,Native Destop GUI则要比浏览器中的编程要确定多了。)
所以呢,对于luban的定位,我想,即是以前论坛中一位评价luban所说,不是做一个"网站",而只是做一个站点,我觉得这样的定位很不错。但对
于"想用它做Web游戏开发"的,确实也不适合
另外,我的一点思考是,未来的趋势是,用XML家族的描述语言用描述GUI,通过id及行为绑定来关联业务逻辑(XAML,Qt QML,Flex
mxml),如果说有luban这样的创新,我想应该也是,发明一种语法类似Python的描述语言吧(YAML,JSON,???)
^O^ PDL? Python Descriptor Language?



On 12月30日, 下午3时23分, linjiao <[hidden email]> wrote:> 刚刚发布了:http://
lubanui.org> > 本版本主要支持python 3.1+。 目前对 python 2.x 的支持还是实验性的。> > 请试试:
> >  $ pip installluban> > 理念:http://www.lubanui.org/current/
philosophy.html> Tutorials:http://www.lubanui.org/current/user-
tutorials.html> > 非常欢迎您的意见,建议,和指出任何问题。非常感谢!> > 相关链接:早期 0.2 版在python-cn的
发布:http://groups.google.com/group/python-cn/browse_thread/thread/
f616875...

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

[CPyUG] Re: 鲁班 (luban) 1.0.0

CJ-19
In reply to this post by linjiao
我有一些想法和建议,可能和luban的发展方向有悖,就只管提啦。

根据我的前端开发经验,Web应用常常陷入这样的境地,即,一开始,后端开发人员不懂前端开发技 术,可能有一点JS、CSS技能,但还不够专业,为了
生成UI方便,就使用了一些"通过后端代码生成前端代码"的库或框架,譬如用Python写一个 TabPage的类,
addTabPage(title="XXX"),然后前端生成jQueryUI或ExtJS的Tab。典型的GWT是属于这一类 的东西。但后来,业
务或Art上要求对Tab页的外观做一些定制,或加入一些复杂的交互逻辑,这时,后端开发人员就完全无从下手了,因为这些改动很多可 能是对CSS的改
动甚至是对使用的JS框架的一些hack,这时他们就去找所谓的"专业前端工程师",然后F2E过来一看,哇,GWT创建了一个毫无作 用仅用于布局的
Panel就嵌套了四五个div,然后F2E就吐血了。这时怎么办呢?只能对前端进行重构,不使用GWT创建UI。



所以,第一点,我对luban的理解,就是,它的应用范围是有很大的限制的。类似有人对django的评价,适合于中型项目,但不适合小型项目和大型
项 目。(比如我们在使用django form时发现,as_p,as_table方法,不用为好,用form的原因只在于将表单验证逻辑和view
分 开,绝不能指望django生成HTML或JS代码......我们甚至发现,因为django form的as_xxx方法,有程序员为了方便就
将一大串 HTML写成字符串写到python代码中,这样在页面中生成一个input,前端开发人员想给它加个ID,都得去改python代码)


第二点,就是所说的通用UI描述语言。关于这一点,用python做这件事,有点类似于XML,像MS .NET的XAML,及QT中的QML,现在
的 趋势是用XML描述UI,就像是WEB中的MVC,让描述语言去做描述的事,让编程语言做编程的事,各干各的,自得其乐。现在让python做描述
语言 的事,我看了代码,发现也全是dict,无非是一个树形结构,真正在"写python"的又较少,所以,个人理解,描述UI,相比较python
中的 dict,class,YAML,XML语法岂不是更好?另外,所谓MVC,用python写UI,又容易造成UI与业务逻辑混杂在一起的不好的
结果, 一页Python代码,发现全是GUI,但不对,竟然其中还有JAVASCRIPT代码。。。。----"阻止程序员犯错"。从另一方面看,一
种通用的描述 语言就意味着牺牲特定平台的功能(Swing啊)。我想没有前端开发经验的Python程序员不了解JS编程之道的----不了解UI交
互、浏览器中异步编 程的错误处理,他们不会知道为何一个JSONP请求有时会说JS代码语法错误,为何一个click事件会被不断触发,何时需要将某
个DOM操作排队异步 处理。(相比较而言,Native Destop GUI则要比浏览器中的编程要确定多了。)



所以呢,对于luban的定位,我想,即是以前论坛中一位评价luban所说,不是做一个"网站",而只是做一个站点,我觉得这样的定位很不错。但
对 于"想用它做Web游戏开发"的,确实也不适合



另外,我的一点思考是,未来的趋势是,用XML家族的描述语言用描述GUI,通过id及行为绑定来关联业务逻辑(XAML,Qt QML,
Flex mxml),如果说有luban这样的创新,我想应该也是,发明一种语法类似Python的描述语言吧(YAML,
JSON,???) ^O^ PDL? Python Descriptor Language?
On 12月30日, 下午3时23分, linjiao <[hidden email]> wrote:

> 刚刚发布了:http://lubanui.org
>
> 本版本主要支持python 3.1+。 目前对 python 2.x 的支持还是实验性的。
>
> 请试试:
>
>  $ pip install luban
>
> 理念:http://www.lubanui.org/current/philosophy.html
> Tutorials:http://www.lubanui.org/current/user-tutorials.html
>
> 非常欢迎您的意见,建议,和指出任何问题。非常感谢!
>
> 相关链接:早期 0.2 版在python-cn的发布:http://groups.google.com/group/python-cn/browse_thread/thread/f616875...

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

Re: [CPyUG] Re: 鲁班 (luban) 1.0.0

lu_zi_2000
In reply to this post by CJ-19
说实话我觉得分工要明确才会让专业变得更专业,ui的人就应该搞ui,后端的人就
应该搞后端,这样才好

于 2011年12月31日 11:06, CJ 写道:

> 我有一些想法和建议,可能和luban的发展方向有悖。根据我的前端开发经验,Web应用常常陷入这样的境地,即,一开始,后端开发人员不懂前端开发技
> 术,可能有一点JS、CSS技能,但还不够专业,为了生成UI方便,就使用了一些"通过后端代码生成前端代码"的库或框架,譬如用Python写一个
> TabPage的类,addTabPage(title="XXX"),然后前端生成jQueryUI或ExtJS的Tab。典型的GWT是属于这一类
> 的东西。但后来,业务或Art上要求对Tab页的外观做一些定制,或加入一些复杂的交互逻辑,这时,后端开发人员就完全无从下手了,因为这些改动很多可
> 能是对CSS的改动甚至是对使用的JS框架的一些hack,这时他们就去找所谓的"专业前端工程师",然后F2E过来一看,哇,GWT创建了一个毫无作
> 用仅用于布局的Panel就嵌套了四五个div,然后F2E就吐血了。这时怎么办呢?只能对前端进行重构,不使用GWT创建UI。
> 所以,第一点,我对luban的理解,就是,它的应用范围是有很大的限制的。类似有人对django的评价,适合于中型项目,但不适合小型项目和大型项
> 目。(比如我们在使用django form时发现,as_p,as_table方法,不用为好,用form的原因只在于将表单验证逻辑和view分
> 开,绝不能指望django生成HTML或JS代码......我们甚至发现,因为django form的as_xxx方法,有程序员为了方便就将一大串
> HTML写成字符串写到python代码中,这样在页面中生成一个input,前端开发人员想给它加个ID,都得去改python代码)
> 第二点,就是所说的通用UI描述语言。关于这一点,用python做这件事,有点类似于XML,像MS .NET的XAML,及QT中的QML,现在的
> 趋势是用XML描述UI,就像是WEB中的MVC,让描述语言去做描述的事,让编程语言做编程的事,各干各的,自得其乐。现在让python做描述语言
> 的事,我看了代码,发现也全是dict,无非是一个树形结构,真正在"写python"的又较少,所以,个人理解,描述UI,相比较python中的
> dict,class,YAML,XML语法岂不是更好?另外,所谓MVC,用python写UI,又容易造成UI与业务逻辑混杂在一起的不好的结果,
> 一页Python代码,发现全是GUI,但不对,竟然其中还有JAVASCRIPT代码。。。。----"阻止程序员犯错"。从另一方面看,一种通用的描述
> 语言就意味着牺牲特定平台的功能(Swing啊)。我想没有前端开发经验的Python程序员不了解JS编程之道的----不了解UI交互、浏览器中异步编
> 程的错误处理,他们不会知道为何一个JSONP请求有时会说JS代码语法错误,为何一个click事件会被不断触发,何时需要将某个DOM操作排队异步
> 处理。(相比较而言,Native Destop GUI则要比浏览器中的编程要确定多了。)
> 所以呢,对于luban的定位,我想,即是以前论坛中一位评价luban所说,不是做一个"网站",而只是做一个站点,我觉得这样的定位很不错。但对
> 于"想用它做Web游戏开发"的,确实也不适合
> 另外,我的一点思考是,未来的趋势是,用XML家族的描述语言用描述GUI,通过id及行为绑定来关联业务逻辑(XAML,Qt QML,Flex
> mxml),如果说有luban这样的创新,我想应该也是,发明一种语法类似Python的描述语言吧(YAML,JSON,???)
> ^O^ PDL? Python Descriptor Language?
>
>
>
> On 12月30日, 下午3时23分, linjiao <[hidden email]> wrote:> 刚刚发布了:http://
> lubanui.org> > 本版本主要支持python 3.1+。 目前对 python 2.x 的支持还是实验性的。> > 请试试:
>>>  $ pip installluban> > 理念:http://www.lubanui.org/current/
> philosophy.html> Tutorials:http://www.lubanui.org/current/user-
> tutorials.html> > 非常欢迎您的意见,建议,和指出任何问题。非常感谢!> > 相关链接:早期 0.2 版在python-cn的
> 发布:http://groups.google.com/group/python-cn/browse_thread/thread/
> f616875...
>


--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

Re: [CPyUG] Re: 鲁班 (luban) 1.0.0

Zoom.Quiet
In reply to this post by CJ-19
在 2011年12月31日 上午11:06,CJ <[hidden email]> 写道:

> 我有一些想法和建议,可能和luban的发展方向有悖。根据我的前端开发经验,Web应用常常陷入这样的境地,即,一开始,后端开发人员不懂前端开发技
> 术,可能有一点JS、CSS技能,但还不够专业,为了生成UI方便,就使用了一些"通过后端代码生成前端代码"的库或框架,譬如用Python写一个
> TabPage的类,addTabPage(title="XXX"),然后前端生成jQueryUI或ExtJS的Tab。典型的GWT是属于这一类
> 的东西。但后来,业务或Art上要求对Tab页的外观做一些定制,或加入一些复杂的交互逻辑,这时,后端开发人员就完全无从下手了,因为这些改动很多可
> 能是对CSS的改动甚至是对使用的JS框架的一些hack,这时他们就去找所谓的"专业前端工程师",然后F2E过来一看,哇,GWT创建了一个毫无作
> 用仅用于布局的Panel就嵌套了四五个div,然后F2E就吐血了。这时怎么办呢?只能对前端进行重构,不使用GWT创建UI。
> 所以,第一点,我对luban的理解,就是,它的应用范围是有很大的限制的。类似有人对django的评价,适合于中型项目,但不适合小型项目和大型项
> 目。(比如我们在使用django form时发现,as_p,as_table方法,不用为好,用form的原因只在于将表单验证逻辑和view分
> 开,绝不能指望django生成HTML或JS代码......我们甚至发现,因为django form的as_xxx方法,有程序员为了方便就将一大串
> HTML写成字符串写到python代码中,这样在页面中生成一个input,前端开发人员想给它加个ID,都得去改python代码)
> 第二点,就是所说的通用UI描述语言。关于这一点,用python做这件事,有点类似于XML,像MS .NET的XAML,及QT中的QML,现在的
> 趋势是用XML描述UI,就像是WEB中的MVC,让描述语言去做描述的事,让编程语言做编程的事,各干各的,自得其乐。现在让python做描述语言
> 的事,我看了代码,发现也全是dict,无非是一个树形结构,真正在"写python"的又较少,所以,个人理解,描述UI,相比较python中的
> dict,class,YAML,XML语法岂不是更好?另外,所谓MVC,用python写UI,又容易造成UI与业务逻辑混杂在一起的不好的结果,
> 一页Python代码,发现全是GUI,但不对,竟然其中还有JAVASCRIPT代码。。。。----"阻止程序员犯错"。从另一方面看,一种通用的描述
> 语言就意味着牺牲特定平台的功能(Swing啊)。我想没有前端开发经验的Python程序员不了解JS编程之道的----不了解UI交互、浏览器中异步编
> 程的错误处理,他们不会知道为何一个JSONP请求有时会说JS代码语法错误,为何一个click事件会被不断触发,何时需要将某个DOM操作排队异步
> 处理。(相比较而言,Native Destop GUI则要比浏览器中的编程要确定多了。)
> 所以呢,对于luban的定位,我想,即是以前论坛中一位评价luban所说,不是做一个"网站",而只是做一个站点,我觉得这样的定位很不错。但对
> 于"想用它做Web游戏开发"的,确实也不适合
> 另外,我的一点思考是,未来的趋势是,用XML家族的描述语言用描述GUI,通过id及行为绑定来关联业务逻辑(XAML,Qt QML,Flex
> mxml),如果说有luban这样的创新,我想应该也是,发明一种语法类似Python的描述语言吧(YAML,JSON,???)
> ^O^ PDL? Python Descriptor Language?
>

- luban new UI language 这个概念是没有�e的
- 只是,我们担心的是,现在web应用早已不是简单的从 db 中吐数据�橐趁娴� client 而已
        - ajax
        - websocket
        - html5
        - node.js
        ...
        html页面代码越来越象一种 client 端嵌入式应用了
        所以,有种回归简单的 ui �Z言,可以将复杂的动态交互,纯化回服务端代码的组织就好
        那,的确是种幸福,
        不过, 目前没有看出来怎么真正可以完全应付功能的保证同时,
        也可以确保 ui 有充分的自由度,可以直觉的无限制的�O�出任意效果来,,,
       



--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
文字协议: http://creativecommons.org/licenses/by-sa/2.5/cn/

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

[CPyUG] Re: 鲁班 (luban) 1.0.0

linjiao
In reply to this post by zw g
On Dec 30, 1:17 am, zw g <[hidden email]> wrote:
> 我以为,一定是需要这种Think Different的动机的,这样才能促发伟大的事物的诞生。
> 请坚持。

谢谢支持。其实类似的想法已经出现了好几次了,所以鲁班的想法并不是毫无根基的。有很多xml-based技术有类似的想法,比如
gladeXML, OpenLaszlo, mozilla XUL, XForms, XAML。最学术化的是UIML。鲁班和他们不同的地方是

1 鲁班目前没用xml。有些人觉得xml文件更应该是由机器写出来的,我也有同感。python之所以很popular其中一个重要原因可能是因为它
很接近与自然语言。在鲁班的开发中,我希望能用同样的philosophy,希望也能做到语法简洁自然。
2 这些已有的技术都试图做很多的事情,实际上把事情搞复杂了。鲁班采用的是minimalist的方式,只专注于一件事:可否有一种方法能描述人机界
面的主要逻辑。

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

[CPyUG] Re: 鲁班 (luban) 1.0.0

linjiao
In reply to this post by CJ-19
On Dec 30, 7:10 pm, CJ <[hidden email]> wrote:
> 我有一些想法和建议,可能和luban的发展方向有悖,就只管提啦。
非常感谢!

>
> 根据我的前端开发经验,Web应用常常陷入这样的境地,即,一开始,后端开发人员不懂前端开发技 术,可能有一点JS、CSS技能,但还不够专业,为了
> 生成UI方便,就使用了一些"通过后端代码生成前端代码"的库或框架,譬如用Python写一个 TabPage的类,
> addTabPage(title="XXX"),然后前端生成jQueryUI或ExtJS的Tab。典型的GWT是属于这一类 的东西。但后来,业
> 务或Art上要求对Tab页的外观做一些定制,或加入一些复杂的交互逻辑,这时,后端开发人员就完全无从下手了,因为这些改动很多可 能是对CSS的改
> 动甚至是对使用的JS框架的一些hack,这时他们就去找所谓的"专业前端工程师",然后F2E过来一看,哇,GWT创建了一个毫无作 用仅用于布局的
> Panel就嵌套了四五个div,然后F2E就吐血了。这时怎么办呢?只能对前端进行重构,不使用GWT创建UI。
鲁班和GWT有很不一样的对前端技术的处理方式。在鲁班中,你完全可以掌控前端widget的javascript实现。这里有一个简单的例子:
http://www.lubanui.org/current/create-ext-tutorial.html#create-ext-tutorial.
鲁班只是试图在前端的具体实现和后端的描述之间架了一个桥梁。你可以相当自由的改造前端的实现。你甚至可以把鲁班的前端实现全部代替。

> > 所以,第一点,我对luban的理解,就是,它的应用范围是有很大的限制的。类似有人对django的评价,适合于中型项目,但不适合小型项目和大型
> 项 目。(比如我们在使用django form时发现,as_p,as_table方法,不用为好,用form的原因只在于将表单验证逻辑和view

> 分 开,绝不能指望django生成HTML或JS代码......我们甚至发现,因为django form的as_xxx方法,有程序员为了方便就
> 将一大串 HTML写成字符串写到python代码中,这样在页面中生成一个input,前端开发人员想给它加个ID,都得去改python代码)
我对django不熟。但是象上面我解释的那样,我想鲁班应该不会让你有这个困扰。

>
> 第二点,就是所说的通用UI描述语言。关于这一点,用python做这件事,有点类似于XML,像MS .NET的XAML,及QT中的QML,现在
> 的 趋势是用XML描述UI,就像是WEB中的MVC,让描述语言去做描述的事,让编程语言做编程的事,各干各的,自得其乐。现在让python做描述
> 语言 的事,我看了代码,发现也全是dict,无非是一个树形结构,真正在"写python"的又较少,所以,个人理解,描述UI,相比较python
> 中的 dict,class,YAML,XML语法岂不是更好?另外,所谓MVC,用python写UI,又容易造成UI与业务逻辑混杂在一起的不好的
> 结果, 一页Python代码,发现全是GUI,但不对,竟然其中还有JAVASCRIPT代码。。。。----"阻止程序员犯错"。从另一方面看,一
> 种通用的描述 语言就意味着牺牲特定平台的功能(Swing啊)。我想没有前端开发经验的Python程序员不了解JS编程之道的----不了解UI交
> 互、浏览器中异步编 程的错误处理,他们不会知道为何一个JSONP请求有时会说JS代码语法错误,为何一个click事件会被不断触发,何时需要将某
> 个DOM操作排队异步 处理。(相比较而言,Native Destop GUI则要比浏览器中的编程要确定多了。)
我觉得你说的很对。前端的js编程是有很多技巧的。我在这方面不是很强。很希望有象你这样的高手参与到鲁班中来。但是从理念上讲,鲁班其实正是想把这些
非常detailed的东西和比较coarse-grained的,主要的人机界面的逻辑给分开。这里我把我在google plus上的一段回应抄过
来:

@Paolo: I agree that certainly this kind of approach has limitations.
But in an organization or a project (like danse http://danse.us) where
a common infrastructure is needed for web UI development, a luban-like
common asset could be quite helpful. Regarding fine-tuning web UI for
better user experiences, Luban is not a thing that you cannot change.
You can customize the widgets, or replace widgets with your own
implementations, or add new widgets as fancy as you like. One benefit
of using luban is a clean separation of the (js/html5) code for visual
appeal from the real user interface logic. You can fine-tune the
visual appeal of your user interface in your implementation of the
widget, instead of touching the final page generated by luban. Luban
is not trying to take away all your capabilities of doing all the nice
js/html5 tricks, but rather it could help you better structure your
code. For example, let us say we want to implement the google circle
widget (the circle that when hovered shows a bunch of icons of
contacts) into which a user can drop a contact. In essence, we can say
that one important behavior of that circle widget is

when a user widget is dropped into a circle widget, add a user
representation (icon) into the circle widget

roughly in the spirit of luban, the code could look like

>>> circle_widget.ondrop = circle_widget.add(dropped.icon)

while on the javascript implementation of this circle widget, you will
have code for animations to make it look nice. Imagine in the future,
it could be possible the visual effect would be that the circle is a
3d scene of people standing in a circle moving and chatting, and the
implementation of 3d scene would be still all on the javascript/html5/
future-technology side, while the ui logic will remain unchanged. So
luban will essentially help/force you separate clearly the eye candy
part of your user interface and the real ui logic part, and give your
widget a clean, simple API.

鲁班的主要思想我觉得是,无论界面如何复杂,它总是可以被简化为一些简单物体的相互作用。这些相互作用是可以用一些简练的语言来描述的。就好像物理学的
基本原理没有几个,但是大千世界却很丰富多彩。当然你也可以把界面搞得无限复杂,无法用简单物体的相互作用来描述。但是那不一定是必要的。


> 所以呢,对于luban的定位,我想,即是以前论坛中一位评价luban所说,不是做一个"网站",而只是做一个站点,我觉得这样的定位很不错。但
> 对 于"想用它做Web游戏开发"的,确实也不适合
>
> 另外,我的一点思考是,未来的趋势是,用XML家族的描述语言用描述GUI,通过id及行为绑定来关联业务逻辑(XAML,Qt QML,
> Flex mxml),如果说有luban这样的创新,我想应该也是,发明一种语法类似Python的描述语言吧(YAML,
> JSON,???) ^O^ PDL? Python Descriptor Language?

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

Re: [CPyUG] Re: 鲁班 (luban) 1.0.0

Marlon Yao
我个人是反对在代码中写html的。这让我联想起ASP.NET,貌似写页面很容易,几个控件拖来拖去就可以了,但仅限制于控件所提供的功能,如果想做UI定制,麻烦就来了,绝对让你头疼死。UI应当向前端开发者公开,而不是封装起来。

我基本上同意CJ的观点,但我认为python并不适合做数据描述语言,python的缩进语法限制你"创建"一门新语言的可能性,除非你想代码中含有大量的"\",而ruby, scala就要容易得多。简言之,python不适合做DSL。


2011/12/31 linjiao <[hidden email]>
On Dec 30, 7:10 pm, CJ <[hidden email]> wrote:
> 我有一些想法和建议,可能和luban的发展方向有悖,就只管提啦。
非常感谢!

>
> 根据我的前端开发经验,Web应用常常陷入这样的境地,即,一开始,后端开发人员不懂前端开发技 术,可能有一点JS、CSS技能,但还不够专业,为了
> 生成UI方便,就使用了一些"通过后端代码生成前端代码"的库或框架,譬如用Python写一个 TabPage的类,
> addTabPage(title="XXX"),然后前端生成jQueryUI或ExtJS的Tab。典型的GWT是属于这一类 的东西。但后来,业
> 务或Art上要求对Tab页的外观做一些定制,或加入一些复杂的交互逻辑,这时,后端开发人员就完全无从下手了,因为这些改动很多可 能是对CSS的改
> 动甚至是对使用的JS框架的一些hack,这时他们就去找所谓的"专业前端工程师",然后F2E过来一看,哇,GWT创建了一个毫无作 用仅用于布局的
> Panel就嵌套了四五个div,然后F2E就吐血了。这时怎么办呢?只能对前端进行重构,不使用GWT创建UI。
鲁班和GWT有很不一样的对前端技术的处理方式。在鲁班中,你完全可以掌控前端widget的javascript实现。这里有一个简单的例子:
http://www.lubanui.org/current/create-ext-tutorial.html#create-ext-tutorial.
鲁班只是试图在前端的具体实现和后端的描述之间架了一个桥梁。你可以相当自由的改造前端的实现。你甚至可以把鲁班的前端实现全部代替。

> > 所以,第一点,我对luban的理解,就是,它的应用范围是有很大的限制的。类似有人对django的评价,适合于中型项目,但不适合小型项目和大型
> 项 目。(比如我们在使用django form时发现,as_p,as_table方法,不用为好,用form的原因只在于将表单验证逻辑和view

> 分 开,绝不能指望django生成HTML或JS代码......我们甚至发现,因为django form的as_xxx方法,有程序员为了方便就
> 将一大串 HTML写成字符串写到python代码中,这样在页面中生成一个input,前端开发人员想给它加个ID,都得去改python代码)
我对django不熟。但是象上面我解释的那样,我想鲁班应该不会让你有这个困扰。

>
> 第二点,就是所说的通用UI描述语言。关于这一点,用python做这件事,有点类似于XML,像MS .NET的XAML,及QT中的QML,现在
> 的 趋势是用XML描述UI,就像是WEB中的MVC,让描述语言去做描述的事,让编程语言做编程的事,各干各的,自得其乐。现在让python做描述
> 语言 的事,我看了代码,发现也全是dict,无非是一个树形结构,真正在"写python"的又较少,所以,个人理解,描述UI,相比较python
> 中的 dict,class,YAML,XML语法岂不是更好?另外,所谓MVC,用python写UI,又容易造成UI与业务逻辑混杂在一起的不好的
> 结果, 一页Python代码,发现全是GUI,但不对,竟然其中还有JAVASCRIPT代码。。。。----"阻止程序员犯错"。从另一方面看,一
> 种通用的描述 语言就意味着牺牲特定平台的功能(Swing啊)。我想没有前端开发经验的Python程序员不了解JS编程之道的----不了解UI交
> 互、浏览器中异步编 程的错误处理,他们不会知道为何一个JSONP请求有时会说JS代码语法错误,为何一个click事件会被不断触发,何时需要将某
> 个DOM操作排队异步 处理。(相比较而言,Native Destop GUI则要比浏览器中的编程要确定多了。)
我觉得你说的很对。前端的js编程是有很多技巧的。我在这方面不是很强。很希望有象你这样的高手参与到鲁班中来。但是从理念上讲,鲁班其实正是想把这些
非常detailed的东西和比较coarse-grained的,主要的人机界面的逻辑给分开。这里我把我在google plus上的一段回应抄过
来:

@Paolo: I agree that certainly this kind of approach has limitations.
But in an organization or a project (like danse http://danse.us) where
a common infrastructure is needed for web UI development, a luban-like
common asset could be quite helpful. Regarding fine-tuning web UI for
better user experiences, Luban is not a thing that you cannot change.
You can customize the widgets, or replace widgets with your own
implementations, or add new widgets as fancy as you like. One benefit
of using luban is a clean separation of the (js/html5) code for visual
appeal from the real user interface logic. You can fine-tune the
visual appeal of your user interface in your implementation of the
widget, instead of touching the final page generated by luban. Luban
is not trying to take away all your capabilities of doing all the nice
js/html5 tricks, but rather it could help you better structure your
code. For example, let us say we want to implement the google circle
widget (the circle that when hovered shows a bunch of icons of
contacts) into which a user can drop a contact. In essence, we can say
that one important behavior of that circle widget is

when a user widget is dropped into a circle widget, add a user
representation (icon) into the circle widget

roughly in the spirit of luban, the code could look like

>>> circle_widget.ondrop = circle_widget.add(dropped.icon)

while on the javascript implementation of this circle widget, you will
have code for animations to make it look nice. Imagine in the future,
it could be possible the visual effect would be that the circle is a
3d scene of people standing in a circle moving and chatting, and the
implementation of 3d scene would be still all on the javascript/html5/
future-technology side, while the ui logic will remain unchanged. So
luban will essentially help/force you separate clearly the eye candy
part of your user interface and the real ui logic part, and give your
widget a clean, simple API.

鲁班的主要思想我觉得是,无论界面如何复杂,它总是可以被简化为一些简单物体的相互作用。这些相互作用是可以用一些简练的语言来描述的。就好像物理学的
基本原理没有几个,但是大千世界却很丰富多彩。当然你也可以把界面搞得无限复杂,无法用简单物体的相互作用来描述。但是那不一定是必要的。


> 所以呢,对于luban的定位,我想,即是以前论坛中一位评价luban所说,不是做一个"网站",而只是做一个站点,我觉得这样的定位很不错。但
> 对 于"想用它做Web游戏开发"的,确实也不适合
>
> 另外,我的一点思考是,未来的趋势是,用XML家族的描述语言用描述GUI,通过id及行为绑定来关联业务逻辑(XAML,Qt QML,
> Flex mxml),如果说有luban这样的创新,我想应该也是,发明一种语法类似Python的描述语言吧(YAML,
> JSON,???) ^O^ PDL? Python Descriptor Language?

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
Reply | Threaded
Open this post in threaded view
|

Re: [CPyUG] Re: 鲁班 (luban) 1.0.0

Yu Shi-2
学习了

在 11-12-31,Marlon Yao<[hidden email]> 写道:

> 我个人是反对在代码中写html的。这让我联想起ASP.NET
> ,貌似写页面很容易,几个控件拖来拖去就可以了,但仅限制于控件所提供的功能,如果想做UI定制,麻烦就来了,绝对让你头疼死。UI应当向前端开发者公开,而不是封装起来。
>
> 我基本上同意CJ的观点,但我认为python并不适合做数据描述语言,python的缩进语法限制你"创建"一门新语言的可能性,除非你想代码中含有大量的"\",而ruby,
> scala就要容易得多。简言之,python不适合做DSL。
>
>
> 2011/12/31 linjiao <[hidden email]>
>
>> On Dec 30, 7:10 pm, CJ <[hidden email]> wrote:
>> > 我有一些想法和建议,可能和luban的发展方向有悖,就只管提啦。
>> 非常感谢!
>>
>> >
>> > 根据我的前端开发经验,Web应用常常陷入这样的境地,即,一开始,后端开发人员不懂前端开发技 术,可能有一点JS、CSS技能,但还不够专业,为了
>> > 生成UI方便,就使用了一些"通过后端代码生成前端代码"的库或框架,譬如用Python写一个 TabPage的类,
>> > addTabPage(title="XXX"),然后前端生成jQueryUI或ExtJS的Tab。典型的GWT是属于这一类 的东西。但后来,业
>> > 务或Art上要求对Tab页的外观做一些定制,或加入一些复杂的交互逻辑,这时,后端开发人员就完全无从下手了,因为这些改动很多可 能是对CSS的改
>> > 动甚至是对使用的JS框架的一些hack,这时他们就去找所谓的"专业前端工程师",然后F2E过来一看,哇,GWT创建了一个毫无作 用仅用于布局的
>> > Panel就嵌套了四五个div,然后F2E就吐血了。这时怎么办呢?只能对前端进行重构,不使用GWT创建UI。
>> 鲁班和GWT有很不一样的对前端技术的处理方式。在鲁班中,你完全可以掌控前端widget的javascript实现。这里有一个简单的例子:
>> http://www.lubanui.org/current/create-ext-tutorial.html#create-ext-tutorial
>> .
>> 鲁班只是试图在前端的具体实现和后端的描述之间架了一个桥梁。你可以相当自由的改造前端的实现。你甚至可以把鲁班的前端实现全部代替。
>>
>> > > 所以,第一点,我对luban的理解,就是,它的应用范围是有很大的限制的。类似有人对django的评价,适合于中型项目,但不适合小型项目和大型
>> > 项 目。(比如我们在使用django form时发现,as_p,as_table方法,不用为好,用form的原因只在于将表单验证逻辑和view
>>
>> > 分 开,绝不能指望django生成HTML或JS代码......我们甚至发现,因为django form的as_xxx方法,有程序员为了方便就
>> > 将一大串 HTML写成字符串写到python代码中,这样在页面中生成一个input,前端开发人员想给它加个ID,都得去改python代码)
>> 我对django不熟。但是象上面我解释的那样,我想鲁班应该不会让你有这个困扰。
>>
>> >
>> > 第二点,就是所说的通用UI描述语言。关于这一点,用python做这件事,有点类似于XML,像MS .NET的XAML,及QT中的QML,现在
>> > 的 趋势是用XML描述UI,就像是WEB中的MVC,让描述语言去做描述的事,让编程语言做编程的事,各干各的,自得其乐。现在让python做描述
>> > 语言 的事,我看了代码,发现也全是dict,无非是一个树形结构,真正在"写python"的又较少,所以,个人理解,描述UI,相比较python
>> > 中的 dict,class,YAML,XML语法岂不是更好?另外,所谓MVC,用python写UI,又容易造成UI与业务逻辑混杂在一起的不好的
>> > 结果, 一页Python代码,发现全是GUI,但不对,竟然其中还有JAVASCRIPT代码。。。。----"阻止程序员犯错"。从另一方面看,一
>> > 种通用的描述 语言就意味着牺牲特定平台的功能(Swing啊)。我想没有前端开发经验的Python程序员不了解JS编程之道的----不了解UI交
>> > 互、浏览器中异步编 程的错误处理,他们不会知道为何一个JSONP请求有时会说JS代码语法错误,为何一个click事件会被不断触发,何时需要将某
>> > 个DOM操作排队异步 处理。(相比较而言,Native Destop GUI则要比浏览器中的编程要确定多了。)
>> 我觉得你说的很对。前端的js编程是有很多技巧的。我在这方面不是很强。很希望有象你这样的高手参与到鲁班中来。但是从理念上讲,鲁班其实正是想把这些
>> 非常detailed的东西和比较coarse-grained的,主要的人机界面的逻辑给分开。这里我把我在google plus上的一段回应抄过
>> 来:
>>
>> @Paolo: I agree that certainly this kind of approach has limitations.
>> But in an organization or a project (like danse http://danse.us) where
>> a common infrastructure is needed for web UI development, a luban-like
>> common asset could be quite helpful. Regarding fine-tuning web UI for
>> better user experiences, Luban is not a thing that you cannot change.
>> You can customize the widgets, or replace widgets with your own
>> implementations, or add new widgets as fancy as you like. One benefit
>> of using luban is a clean separation of the (js/html5) code for visual
>> appeal from the real user interface logic. You can fine-tune the
>> visual appeal of your user interface in your implementation of the
>> widget, instead of touching the final page generated by luban. Luban
>> is not trying to take away all your capabilities of doing all the nice
>> js/html5 tricks, but rather it could help you better structure your
>> code. For example, let us say we want to implement the google circle
>> widget (the circle that when hovered shows a bunch of icons of
>> contacts) into which a user can drop a contact. In essence, we can say
>> that one important behavior of that circle widget is
>>
>> when a user widget is dropped into a circle widget, add a user
>> representation (icon) into the circle widget
>>
>> roughly in the spirit of luban, the code could look like
>>
>> >>> circle_widget.ondrop = circle_widget.add(dropped.icon)
>>
>> while on the javascript implementation of this circle widget, you will
>> have code for animations to make it look nice. Imagine in the future,
>> it could be possible the visual effect would be that the circle is a
>> 3d scene of people standing in a circle moving and chatting, and the
>> implementation of 3d scene would be still all on the javascript/html5/
>> future-technology side, while the ui logic will remain unchanged. So
>> luban will essentially help/force you separate clearly the eye candy
>> part of your user interface and the real ui logic part, and give your
>> widget a clean, simple API.
>>
>> 鲁班的主要思想我觉得是,无论界面如何复杂,它总是可以被简化为一些简单物体的相互作用。这些相互作用是可以用一些简练的语言来描述的。就好像物理学的
>> 基本原理没有几个,但是大千世界却很丰富多彩。当然你也可以把界面搞得无限复杂,无法用简单物体的相互作用来描述。但是那不一定是必要的。
>>
>>
>> > 所以呢,对于luban的定位,我想,即是以前论坛中一位评价luban所说,不是做一个"网站",而只是做一个站点,我觉得这样的定位很不错。但
>> > 对 于"想用它做Web游戏开发"的,确实也不适合
>> >
>> > 另外,我的一点思考是,未来的趋势是,用XML家族的描述语言用描述GUI,通过id及行为绑定来关联业务逻辑(XAML,Qt QML,
>> > Flex mxml),如果说有luban这样的创新,我想应该也是,发明一种语法类似Python的描述语言吧(YAML,
>> > JSON,???) ^O^ PDL? Python Descriptor Language?
>>
>> --
>> 来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
>> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>> 发言: [hidden email]
>> 退订: [hidden email] (向此发空信即退!)
>> 详情: http://code.google.com/p/cpyug/wiki/PythonCn
>> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>> 强烈: 建议使用技巧: 如何有效地报告Bug
>> http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
>>
>
> --
> 来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
> 发言: [hidden email]
> 退订: [hidden email] (向此发空信即退!)
> 详情: http://code.google.com/p/cpyug/wiki/PythonCn
> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
> 强烈: 建议使用技巧: 如何有效地报告Bug
> http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
>

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
发言: [hidden email]
退订: [hidden email] (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
强烈: 建议使用技巧: 如何有效地报告Bug http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html