界面设计一直是Web开发的一种重点，而为用户提供可以调节界面的机制也是非常有必要的，Scheme(类似于博客堂采用的)技术也就因此应用而生。然而，Scheme只能提供给用户有限多的选择，而且无法对页面的布局和样式进行更改(指在运行期，而不是开发期)
是否可以让用户在Web application的运行时期更改页面布局和样式呢？
答案是肯定的！
大约一年前，我写过一篇文章《如何构建积木式Web应用》，在篇文章里，讲述了如何采用User Control来构建一个Web Application，不过，仍然没有脱离Scheme的范畴，而且也不能算是真正的一种积木式构建技术。开发者除了要开发各种积木(User Control)，还需要构建积木的布局，用户无法参与这一布局过程。开发好了就无法改变(除非修改代码)。在那之后，我一直想实现一个真正的积木式Web application开发平台(称为平台实在是太过，不过一直找不到一个好的名字，不知道bricks mini-framework好不好？)
开发者只需要开发所有的User Control积木块和积木块对应的样式即可，至于页面的布局，样式的更改等工作都可以交给系统去处理。
今天，这些都已经有了答案。
用户可以在Web applicaion运行时更改页面布局，样式(最好自己加入权限控制)；而开发者只需要开发所有的UserControl积木块和相应的样式就可以了。目前所采用Scheme机制也可以很方便的加入其中，只需要把每一套Scheme的布局和样式保存下来即可。
这里是演示站点(由于考虑到任何人都可以更改布局和样式，为了保证大家可以看到有效的演示效果，该演示站点只是模拟操作过程，而不会真正的更改样式和布局，如果想了解所有的效果请在该站点上下载源码)
这个mini-framework是免费的，任何人都可以基于此创建自己的项目，不过要符合GPL；而且也不能用于商业用途。
(BTW：有任何建议、发现任何bug，都欢迎回复。因为还存在有很多不完善的地方，这只是一个0.1版)
打印 | 张贴于 2004-09-19 19:40:00 | Tag:暂无标签
留言反馈
不过我要做的东西不会差，因为我前面做过一个Teamwork Portal，很多思想都是从那边过来的。
很高兴你能这么看。
我是觉得可以给开发者和最终用户带来很多好处。
但是，最终会怎么样，很难说。尤其是LongHorn出来后，整个IT世界都会有些变化。
Portal是我下一步想做的一个东西，但是不知道时间是什么时候，Access正是这个Portal准备采用的数据库，但是要考虑扩展性，像DataProvider一样将来可以比较好的扩展到SQL Server。
但是这个东西，我更想让它成为一个基础性的东西，而不是一个具体的实现。我更想让它成为一个开发者可以使用的mini-framework。
至于感兴趣的方面，只要有你感兴趣的就行，管他是什么呢。HEHE
在对alpha所提的问题上，我的看法是差不多的。以前给客户作东西，客户说想要那样，我那个时候就考虑到定制化的东西对客户来说应该是有用的。其实很多论坛非常流行的原因，就是提供了比较好的定制功能。
在目前的东西上，我在想不知道要不要做成与SharetPoint中的属性编辑器一致，本来想做成那个样子的，但是考虑到有些属性可能依赖于其他属性的值，比如演示站点中的一些Textbox要取决于所依赖的Checkbox的值，所以目前选择了这种方式。但是，这样的话要提供一定的Attributes，所以要考虑的事情比较多，目前还没有考虑很多的因素，可能将来会有些情况不够用。
我下一步想要做的是把积木的上传做好。这样希望开发者就可以脱离掉在这个mini-framework上编程的需要。
你可以把它做成很好的一个 Portal：
第一个版本中可以包含许多基本的模块，比如： News or Article Publishing Part，Guestbook Part, Simply Forum Part 等等。
这样或许能够很快推广。。。
有一点是数据源一定考虑多种，特别是 Access，这样可以有很多小的站点使用 Access 版本的 Portal。目前，还没有成熟的支持 Access 的 .net Portal。
我同意你的关于“普通用户”“专业用户”的说法，但不太同意你的结论。
我大学时一个搞安全的朋友懂一点 PHP，他经常使用 PHP 的一些 Portal 系统去架设 Web 站点，效率显然非常快。（好像 PHP 中有一个叫 Nuke 的 Portal System）
.NET 世界中也有 Portal 系统，比如 Microsoft SharePoint Portal System,
IBuySpy Portal, DotNetNuke, Rainbow Portal 等等。
Portal 系统的目的就是要提供给人们架设 Web 站点的快速方法，尽管你可以说自己是“专业用户”，可以从 HTML,CSS 等等底层做起。但在实际需求中，某些时候我们需要更快的架起一个站点，这种事情还是很常见的。
比如在大学里，有时举办一些大型学术会议，需要临时架起一个支持站点，包括会议新闻动态，BBS 讨论，会务咨询等等模块。如果从底层开始做，当然也是可以的；但大多数时候，时间上无法满足。如果使用现成的 Portal，就没有这些问题了，可以在一天以内搞定所有这些。
当然这个例子只是一个 Portal 使用的最佳情景，但不仅仅是这些，比如一个文学爱好者，想使用 .NET 技术构架一个个人网站，展示自己的作品。网络空间可以购买，站点程序当然也是优先考虑 Portal 系统比较简单。
这里说了很多关于 Portal 的事情。我也很想知道 Jasper 有没有想过把你的这个东西做成 Portal？
如果你本意不是要做 Portal 的话，那我插的这句嘴，就多余了……
我想你有点激动了！我只是顺着你的那句话，说了一点我在这个应用中所看到的“最有价值的东西”。你认为最有价值的东西，并不是我认为最有价值的东西。这是我和你的区别。
但对于这个应用本身来说，我是很喜欢的，很期待它的成熟。
至于你说的 DotNetNuke 不是完全以 User Control 构建的这点，我也承认是这样的。但我的意思显然是从 DotNetNuke （实际上是从 Microsoft IBuySpy Portal）开始就已经存在并有人在实践这样的想法了。
你说你没有想“首创”“创新”，这点我很佩服！看来是我上次写评论时的担心是多余的。当时我担心，你会反驳说“这是我独立想出来的，不是参考别人的。” 如果这样的话，争论就会偏向不正确的方向，毕竟大家争论这个东西谁首创，意义真的不大。还好，你没有这样的想法。我也不想争论这些，所以才加了那么一句关于微积分的话。
--
罗嗦了这么多，应该还是一句话：我在这个应用中所看到的最感兴趣的是你的形式：Drag & Drop。希望能够保持并发扬光大！
我的本意就是积木式构建技术，而不是布局，这从我的前面相关的帖子中可以看出来。
我个人认为：布局和UI是附加的，因为没有这些是无法做到好的积木式构建。
"这种思想在.net推出之际便早已体现在他的framework构造中了。
你的实现只是顺应了.net的思路，另外加了一点ui上面的trick罢了。
在这个层面上是谈不上任何创新的。 "，这简直就是废话，用这句话理解的话，这个世界上的很多东西没有存在的理由，你也没有用这个架构在.text上的blog的理由。
对，.net framework提供了很多东西，但是你发现了没有？苹果是只会往下掉，而不会往上掉，这是自地球存在之日就存在的真理，但是只有牛顿发现了，你是不是要说"这个东西在牛顿之前就已经存在了，牛顿只不过是用了一点trick罢了，没有任何的创新"。我想这应该是你应该表达的观点。
至于谁会去用它，不是我特别关心的问题。因为那是别人的决定，我只知道的是，我会在我的项目中用它，然后尽可能的提供给想用它的人，全部的东西就只有这么多。
还有一点：为什么很多人一开始总会想到首创啊，创新啊。我从来就没有想过要去争论这些东西，我想争论的是优点与需要改进的地方，我想争论的是对你有没有用。如果没有用，那很简单，忘记它就是了。
可是为什么很多人的第一想法就是去争论这些呢？思维定势吗？
谈到需求，用你那么多假设的话，地球都不知道装在第几个瓶子里了。
你如果想讨论需求，先要做的是调查，而不是在这里，我并没有讲过有多少需求，有什么需求，我只是讲你想用的话，就用吧。
你的实现只是顺应了.net的思路，另外加了一点ui上面的trick罢了。
在这个层面上是谈不上任何创新的。
此外我们上面谈论了这个需求的合理性，我想你还没有意识到我所说的问题。
用户包括两类：普通用户和专业用户。虽然中间并没有硬性的分界，但通常根据经验往往可以这么分。
普通用户是肯定不会存在这种需求的，于是我们抛开不谈。
你的这个demo是面向专业用户，也就是那些懂一点技术的用户。那么这些用户的需求是什么？你认为懂得HTML和CSS的人会满足于这么一个简单的web界面么？灵活性会足够么？他们做的东西也是要给他们的客户看的，而他们的客户的需求也是多样化的，这样的话，你的这套程序如果最终不能具备足够的扩张性以满足各类需求的话，那最终还是被淘汰。我们假设你最后做得和dw一样强大了，那么好，优势在哪里？你希望的是简化过程，但是由于需求过于繁多而让系统变得过于复杂，又和你的初衷相矛盾了。
所以，放弃吧，hehe.
我个人是觉得DotNetNuke的出发点就不一样，Rainbow portal我没有看过，无法提供什么观点。
为什么呢？DotNetNuke提供的UserControl搭建方式仅仅是针对极个别的页面，他没有想把整个web application就采用这种方式搭建起来（我昨天看了几十分钟，如果是我搞错了，请更正）。
还有一点就是我认为有价值，不是说要去争一个自己最先发明的功劳。我一直没有表达过这种观点。如果说到参考，其实给我思想是的.Text和SharePoint。.Text让我了解到UserControl的妙用，而SharePoint中的WebPart又让我想到可以采用那种方式完全的建立一个站点（本来我想去兼容WebPart，不过发现难度很大，无法获得信息；庆幸的是，现在我觉得UserControl是一种更好的形式，因为WebPart是从WebControl继承，一定程度上就削弱了页面表现的能力，要实现同样的效果会给开发者带来比较大的不便利）。
首先，我不同意你说的：
“我认为最有价值的东西，是用UserControl积木块来构建Web Application，而Layout,Style只是附加的一些表现形式。”
因为 UserControl 搭积木的方式，已经在 Microsoft IBuySpy Portal 以及从此衍生来的 DotNetNuke、Rainbow Portal 等框架中运用很多了，你的这个在这点上已经不是首创了。
虽然这可能也是你自己想出来的，没有参考过别的框架，但在这里争论“到底是牛顿还是莱布尼兹发明了微积分”是意义不大的。所谓“英雄所见略同”罢了。
但你超越 DotNetNuke、Rainbow Portal 之处，却首先是形式！
我看到 DotNetNuke、Rainbow Portal 时，一直抱怨它们的页面调整过于繁琐，没有提供 Drag & Drop 方式的调整；而你的这个框架在这方面作的很好，我认为这一点才是你这套框架最吸引人的地方！
毕竟你这套框架现在是 0.1，还是可以充满期待的！
想着保持这个优势，到 1.0 时肯定能超越 DotNetNuke、Rainbow Portal 了！
祝好运！
用户是不是需要，我还是那句老话：让用户参与这个过程是完全现实的，现在懂HTML的人非常多，而且CSS也不是难的东西，公司有人懂的话，可以很方便的设计自己想要的东西。而且对于开发者来说，他如果需要根据客户要求去修改页面，可以非常轻松的做到。
请注意这句话：如果用户要修改页面，开发者会非常轻松的做到。
记住：这个东西开发者肯定必须提供给用户一个合理的初始界面。否则用户根本不知道怎么用。那从这一点上说，比目前的无法定制Layout,Style的方案是不是好多了呢？用户有了选择，可以自己去选择改变还是不改变。
最重要的是：每个人的观点都不一样，如果你认为没有价值，不代表别人也认为没有价值。我所作的只是给认为有价值的人提供一些我认为有价值的东西。
我不想争论有用还是没用。让别人去说吧！至少现在是两方面的人都有。这我就很满足了。
还有一点，可能大家把目光都投在了表现形式上，我个人认为是一个误区。我认为最有价值的东西，是用UserControl积木块来构建Web Application，而Layout,Style只是附加的一些表现形式。
@dust2k:
XHTML + XSLT我想和这个东西是不一样的。从某种程度上说，我是认为是在现有.NET Framework基础上提供另一个编程方式。就好像ASP.NET 2.0中的MasterPage,Scheme等，这是一种编程方式。
而且，我想这里面有软件复用的一些思想。你想，你构建的UserControl如果设计得好，是不是可以在很多projects中拿来就用呢。答案是肯定的。
目前所写的东西，还有很多不完善的地方，比如和UserControl Properties相关的一些东西，就还有很多地方值得深究。
不过从程序员角度考虑，样式，布局，表现和具体逻辑功能的分离不是个很简单的问题，从现有的技术来看，CSS或者XSLT无疑是最具有潜力的根本解决办法，尤其是XHTML＋XSLT是比较终极的方式，但实现的难度很高，没有可视化的工具，且由于不同的Brower对标准的实现略微不同导致调试困难。。。
又，俺也看过Msn中文版的界面，俺也下载了Jasper的代码，我觉得他的实现不止是js这么简单，不知您是否也阅读了他的代码才发出“无非是用了一些js的技巧”这样的感叹？
最后，您的论点和语气和我导师很相似：）
用户是不会自己去订制页面的。当然是你设计好给他用，他用了觉得方便，这才是最重要的。我们经常说，用户自己都不清楚自己的需求，就是希望技术人员能帮他们理清楚思路现在倒好了，你反倒把难题丢给用户自己...
话说回来，这个东西无非是用了一些js的技巧。去看看msn.com的页面布局管理，如果要追求技术，先学习一下吧。
另外一个典型的例子是，microsoft.com首页以及msdn的一些栏目在早些时候是采用类似的用户可自定义布局的方式。不过后来统统被取消了，其原因可想而知。
其实这个0.1版本已经可以用了。我打算基于它架构我的下一个项目。
但是这种Page Design肯定是需要权限控制的。有很多地方还需要使用者自己开发。
我会尽量在以后的版本中完善更多的内容。
在Blog软件中, 特别需要这个功能, 这样每个博客可以自由地定制自己的页面, 现在.Text只能定制页面的CSS, 而页面的布局无法定制。
关注你的mini-framework, 希望能在CN .Text的开发中能够用上它。
还有好多想法没有在这个版本实现。
（比如所有页面的样式，支持Scheme，Page、CustomControl的管理等）
如果大家有什么想法、启发，可以和我交流。
我一直就追寻这种效果。
我一定要好好研究一下
我已经看过DotNetNuke了。确实很多思想是一致的，不过他的布局限制的太死（3栏布局结构），而且目前也没有支持拖放。
还有几点小的区别，就是Nuke没有提供整个页面的布局，而只是中间核心区域（当然了，这不是重点）
我看了Nuke的源码，中间有少部分使用了ASPX，而我的想法是只有ASCX，根本就没有一个ASPX。所有页面想怎么样就怎么样。
我想你应该比较了解Nuke，我只是稍微看了一下，好像比较复杂。很多功能都还不会用。但是主要的还不会。：（
我想你去稍微看一下演示站点明白两者的区别了。
目前我的设计是：每一个ASCS都对应有一个CSS文件和JS文件（当然也可以不对应），每个积木块ASCS在任何地方都可以有不一样的样式（通过CustomCSS来控制）。
这样开发者可以只需要开发所有的ASCS，并且指定好CSS，剩下的就都很好办了。但是这里面有一个小的缺陷，就是没有整体的CSS控制，导致了ASCS自带的CSS文件写起来可能比较繁琐，有比较多的重复工作。将来可以加入一个所有页面都会带的CSS，这样可以控制很多比如TextBox等需要一致性的东西。（这和ASP.NET 2.0里用的一种Scheme好像有点相同，我还没有接触ASP.NET2.0，从很多其他地方大概这么认为的），还可以把布局的设置保存成Scheme，让用户可以方便的再次使用，这些都是目前没有的东西，只是一种想法。
@wollaston:
你指的是DotNetNuke吧？我不是很明白你想表达一种什么意思。诚然，别人自然可以有这种想法和实现，但是我也有一些不同的想法和实现。
我想你可以做一些比较。这样谈起来比较有针对性。
@micropentium6:
我想这个东西对很多人都还是有借鉴，有用的。
我非常喜欢这个设计。我曾经做过winform下的窗体二次开发，要求提供一个类似vb的设计界面来完成窗体和控件的drag/drop，调整大小，添加事件，并且生成的文件可以在某个环境中运行（您好像用了了xml，而我选择了二进制序列化：）
我的师弟曾经跟我打赌说，webform下也能作出相同的东西，用来对网页进行二次设计，我当时不相信，今天算是看到了，马上去通知了他：）
我同意您的“让用户参与这个过程是完全现实的，现在懂HTML的人非常多，而且CSS也不是难的东西，公司有人懂的话，可以很方便的设计自己想要的东西。而且对于开发者来说，他如果需要根据客户要求去修改页面，可以非常轻松的做到。 ”的观点。记得这个blog里曾经有人做过银行系统时就要求必须有这样的二次开发环境，那么这就是一个b/s下的设计环境了！
这个blog并不是积木块式的，该css只可以改变样式，不可以改变布局。
比如说，我希望在没有左边这一块，而需要另一个积木块，就无法做到。当然了如果作者提供了多套Scheme，但是无论提供多少Scheme，总是无法满足所有需求的。
@dayday:
其实一个网站没有任何页面，即连前端页面都没有。
所有页面都是根据积木块的布局来生成的。
@cooldama:
一、让用户参与这个过程是完全现实的，现在懂HTML的人非常多，而且CSS也不是难的东西，公司有人懂的话，可以很方便的设计自己想要的东西。而且对于开发者来说，他如果需要根据客户要求去修改页面，可以非常轻松的做到。
二、不知道可不可以具体的谈谈还有哪些差距。
三、自然也是一种快速构建的手段。
@dudu:
我没有看过DotNetNuke，我一定会看看。