titi

服务器配置
---------------------------------------
双至强3.0 2m缓存
intel原装主板
ecc ddr2 800m 2G内存
72G scsi 万转硬盘 *2 做镜像备份

带宽
---------------------------------------
共享100m

资源份数
---------------------------------------
10人

费用 
------------------------------------
第一年 服务器+带宽 每人1000元
第二年 开始每人500 需要扩展硬件和维修 大家一起商量后共同决定 共同承担


服务器环境
-------------------------------
windows2003 iis6
sqlserver2005
xlight ftpserver
.net 1.0 2.0 3.0 3.5
svn 服务器端

每份资源及权限
-------------------------------
默认5G空间(如果大家都觉得空间不够可以一起承担加一个大硬盘)
10%cpu资源限制
10%的带宽资源限制
独立 iis进程池 sqlserver账号 ftp账号 svn仓库
需要跑特殊server 只要不超出配额资源许可范围,不会引发安全问题，我可以代劳
需要对iis\sqlserver\ftp 特殊操作均由我代劳,不可能给每个人提供远程管理权限
所有网站希望共享人积极备案,不允许跑反动 色情 赌博 黑客等违法应用。如果
受到通知要关闭站点的只能按照通知办事情,另不允许跑论坛这样敏感的应用。


目前参与人数 4人 [主要都是园子里的朋友]
henry 寒风天上 我 我朋友
我的联系方式
qq 131147

便捷式的个人web服务器  主要针对asp.net应用 默认支持*.*映射
可以用来定制属于自己的单机版asp.net应用 也可以用来测试繁多的asp.net应用

下载

针对任意asp.net应用的目录 点右键 选择 "0-作为web应用运行" 即可创建一个针对该目录为根的web服务器供测试
可以用命令行起用 “webserver 物理路径 端口 虚拟路径”
可以直接将安装后的 webserver.exe、Boxi.ASPX.dll复制到任意asp.net应用的bin目录 然后直接执行webserver.exe运行

如何修改CCS的页面布局 相信很多人觉得比较麻烦
这里就来看看CCS的首页有些什么

1、加载默认首页布局
<CS:ContentContainer runat="server" id="MPContainer">
文件位置：CommunityServerControls\ContentContainer.cs该类继承于MetaBuilders.WebControls.MasterPages.ContentContainer

用来加载MasterPage(主页布局)的实体类
首先会访问当前设定的样式风格的(主页控件) 默认为Matser.ascx
如果不存在~ 则会进一步访问默认风格的主页控件~ 默认风格为Default

在具体运行过程中。它首先去加载 ~/Themes/当前用户选择的风格名称/Masters/Master.ascx
如果该文件不存在~ 则会跑去加载~/Themes/Default/Masters/Master.ascx
如果也不在~ 那就啥都不加载~
 所以当你设定某个风格后
你又不小心把这个风格的文件夹删除了或者这个风格除了文件夹啥都没有
首页依然还会有内容输出~ 正式因为他们默认加载的~/Themes/Default/Masters/Master.ascx
但是由于你当前风格不是Default所以仅能显示页面布局 而不懈怠Default的CCS样式控制
如果基于默认布局做新皮肤~ 可以新建一种风格的文件夹 然后仅仅添加需要的样式控制和图片就可以了

关于<CS:ContentContainer runat="server" id="MPContainer">的内部
 public class Region : MetaBuilders.WebControls.MasterPages.Region{}
 public class Content : MetaBuilders.WebControls.MasterPages.Content{}
 public class Form : MetaBuilders.WebControls.MasterPages.NoBugForm {}
说明了Region  Content  Form  均是继承MetaBuilders公司的MasterPages控件的部分
大家可以去http://www.metabuilders.com/Tools/MasterPages.aspx下载控件来做研究
该控件大致分为4个类
(1)Content: This control contains the content for a particular region
此类控件包含真实内容
(2)ContentContainer: This control serves two distincts purposes: - it marks the location where the Master Page will be inserted into the Page - it contains the various Content sections that will be matched to the Master Page's Region controls (based on their ID's).
此控件有两个意图:
·作为一个定位标志，标识Master Page将被插入到页中；
·与Region Controls相匹配
(3)NoBugForm: A server form that does not cause a problem by being inside a master page or other naming container.
无错form。可以放心使用
(4)Region: The control marks a place holder for content in a master page
占位控件

2加载文件和基本设置
3.1加载js文件
<CS:Script Src = "Utility/UpdatePosts.js" runat = "server" />
文件位于：CommunityServerControls/Script .cs
文件继承于LiteralControl 表示一个html元素
他会通过Src属性来定义js文件 并输出<script src=\"{0}/{1}\" type=\"text/javascript\"></script>这样的js引用html语句
如果Src属性为空 则默认加载Utility/global.js全局js文件

默认超链接方式设置
<cs:Base Target="_top" runat="server"/>
转换输出<base target='_top'/>  这样的标签



3加载自定义的皮肤控件

有不少包含了皮肤功能的控件均继承于
SecureTemplatedWebControl或者TemplatedWebControl.cs两个控件
SecureTemplatedWebControl继承于TemplatedWebControl而TemplatedWebControl又继承于WebControl, INamingContainer
TemplatedWebControl控件会通过SkinName属性加载当前风格下的皮肤如果不存在则会加载默认布局的皮肤文件
SecureTemplatedWebControl除了具备TemplatedWebControl的功能外还有检验当前url的功能用来判断当前访问是否一个基于本站的访问
在每个皮肤控件对应的类中我们可以通过重构CreateChildControls方法对该控件进行初始化的设置重构AttachChildControls方法
来对皮肤上的控件对应的变量事件进行设定
比如首页上的<CS:Login SkinName="Skin-LoginSmall.ascx" runat="server" />
会去加载Skin-LoginSmall.ascx的布局
在CommunityServerControls\Login.cs里面我们可以看到该控件的代码

CS是啥？可不是用枪爆头那个东西~ 是.net世界里面开源的典范
包含了 一个论坛 一个电子相册 还有一个博客，最早期要从宝玉研究asp forums的汉化工作算起
 一直到宝玉建立了CCS 把这么优秀的代码介绍了给大家 在这里像宝玉致敬了！！
但是由于宝玉他们主要是精力没法集中在CCS的商业化进程上~CCS的结构又很复杂。所以让一般的开发者望而却步！！
小弟不才就有过想在CCS的基础上基于某一成熟版本 做商业化的开发乃至于产品。不过那些都是以后有精力才敢想的了
昨天我提出了一些对UI权限管理的控制想法
今天在研究CCS后台管理的UI组织上所幸看见了根据权限进行UI界面组织的实现~~乐得把手都拍红了
现在就为大家大致介绍一下。如果是一知半解希望大家抱着宽容的态度 不要说些刻薄的话~

首先~在CCS后台管理是通过CommunityServerControls\Navigation\tabs.cs来进行界面组织的~
在该文件中首先申明了Tab和TabCollection两个实体类 Tab是表示每个选项的Tab标签页的实体类
其主要属性有
        private string _text;//文字
        private string _href;//超链接
        private string _name;//名称
        private string _queryString;//用来设置当前的url传值参数
        private string _roles;//角色~能够访问该Tab的角色
        private bool _enable = true;//是否可以使用
        private Tab[] _children;//子功能的Tab数组
        private bool _isRoot = false;//是否根
        private string _filter = null;//用来存放该Tab的操作

而TabCollection则主要含有一个Tab的数组用来存放一组Tab实体对象。

TabControl类用来组织Tab标签显示和操作。首先它可以通过配置的一个xml配置文件获取后台管理可能出现的所有菜单组织
在GetTabs()方法中我们能够通过本地xml文件获得后台管理的TabCollection实体类来获得后台管理的配置
然后在读取配置文件的过程中它会根据配置文件的权限角色说明来确定每个标签及其子标签可以允许哪些用户浏览其xml配置简要如下:
我们在filter属性中设置某一层UI界面允许的操作以及在roles属性设置该Tab标签运行访问的角色
比如上述配置文件中管理Blog就只能是系统管理员(SystemAdministrator)和博客管理员(BlogAdministrator)
另一方面filter属性中设置了该Tab标签允许的操作
querystring用来获取当前Http请求的url传值 querystring="App"
如果后台管理的地址为~/admin/blogs/postlist.aspx?App={0} 当我们访问后台是时会从当前的http请求中获取Querystrng["App"]格式化到{0}的部分
从而实现了其区分每个人能通过它访问管理自己的程序的操作
通过这个配置文件 TabCollection类能够通过一个Render(HtmlTextWriter writer)方法将菜单根据用户角色和xml配置来组织显示给大家浏览。
当然 系统从逻辑层有效的进行了权限控制~ 这里仅仅是用来让用户通过UI层获得更好的用户体验~具体它的逻辑层的权限控制还有待进一步研究

在WEB权限控制里面 多见的方式是于UI层进行控制。当用户需要进行某样操作时根据一个PowerCheck()的方法检查用户是否拥有该操作。如果有则执行，无则进行弹窗提示。更进一步则是在Page_Load()或者用户空间的类似Init()这样的初始化函数里面来进行权限控制。如果用户拥有某项权限则显示相应的功能按钮给用户看，无则隐藏之。

 1//按钮执行过程中的 
 2If (PowerCheck(userid,”文章管理”))
 3{
 4  //执行按钮事件
 5}
 6Else
 7{
 8//弹窗警告
 9}
10
11//或者
12
13Page_Load
14{
15  //判断用户是否拥有该权限。如果拥有则允许用户访问。
16  If (PowerCheck(userid,”新增文章”))
17   btnAddMessage.visable=true;
18   else btnAddMessage.visable=false;
19}
20

 

老式的权限控制的方法其目的在于通过对UI层界面的控制实现业务逻辑中的权限控制。但是缺点在于每次进行权限控制时均需要针对具体权限编码。而且权限控制过于分布，每次修改时会比较繁琐。特别拥有大量且负责的UI界面时极为复杂。

 

在我曾经参与开发过轻型工作流过程中，我发现在工作流中每一条工作流所有的业务逻辑均靠一个剧本来描述。每一次一条工作流的实例化就像一个电影的演出，若干幕情节构成了一个完成的流程。每一幕拥有自己的场景和角色。每个角色根据自己的台词执行不同的任务。更为复杂的是有些幕结束后才会知道下一幕的舞台和角色。然后正是因为有了工作流引擎，它能够非常灵活和强大的控制好每个角色做好自己本分的事情。每一幕就是一个场景，在工作流中往往是一些文件夹，还有表单，资料。每个角色在这个场景中能做什么不能做什么都是经过严格控制的。软件开发的艺术正是在于我们通过软件创作剧本然后让用户角色去扮演我们希望他们成为的角色。

 

在更为自动编码方式繁多的今天。我寻思着是不是模仿工作流引擎做一个权限监督的方法去控制UI界面来实现对业务逻辑的控制。当然如果能对业务逻辑直接控制权限更佳。但是如何让UI及其事件自配置相应的业务逻辑确不易实现。所以本次研究的重点在于如果开发一套更为通用的UI层权限控制方法。

首先 在普通的WEB管理后台中。我们可以把所有不同的后台管理看成不同的流程。每种后台管理同样拥有一个或者多个场景和角色。和工作流不同之处在于，用户环境这里变成了不同的UI界面。我们仅仅需要对每个UI界面的按钮、文本按钮、菜单进行权限控制。就能整体上把握每个用户在场景中能够做什么不能做什么。在ASP.NET里面每个页面均采用控件树的形式来构成。通过搜索树我们很容易判断需要对什么和不对什么进行权限控制。

 

现在看看如果要实现我们需要的权限控制方式,我们需要做些什么。

 

我们需要一个统一的Framework来实现UI层的表现方式。这方面我们可以开发一个基类，该基类继承于WebControl并重构了初始化方法。然后所有的功能我们可以做成用户控件并继承于该基类。我们可以在每个用户登录后在系统中实例化一个该用户的权限剧本。每个用户界面需要显示之前会通过该剧本获取这个用户界面显示的方式。这样的话当需要进行权限控制时，我们只需设置好该用户的权限剧本既可。当然，每个用户控件得知道自己的剧本是什么。工作流中，所以需要针对用户设定的权限均是针对剧本的一个实例来设置的。不同的剧本不同的实例在初始化时指定相应的角色和用户（或者用户组）。在WEB后台中，不同的用户访问一个后台界面我们可以理解为一个流程的实例化。该用户是扮演哪些UI中的角色是需要我们实例化时确定的。这些东西需要用一个方式来存放。我们可以采用二机制的加减法或者Xml文件来完成这样的配置,从而使具体的权限控制从开发中解放出来。每次实例化界面时读取用户的权限配置表即可以知道UI用什么样的方式来组织。这样的话我们每次开发用户控件时仅仅需要做的事情就是继承于该基类。然后在数据库中设置响应的权限配置即可。