DotNetNuke 皮肤制作白皮书
|
日期 |
版本 |
简介 |
作者 |
|
2003-10 |
1.0 |
DNN 1.10 HTML皮肤主题开发者指南 |
David Haggard, Erik France |
|
2003-11 |
1.1 |
DNN 2.0 HTML皮肤主题开发者指南 |
David Haggard |
|
|
1.2 |
DNN 2.0 皮肤系统白皮书 |
Shaun Walker |
|
|
1.3 |
增加皮肤对象的处理以及安装相关资料 |
Shaun Walker |
|
|
1.4 |
增加资源部分，皮肤上传许可，修改部分内容。 |
Shaun Walker |
|
|
1.5 |
更新以反映 |
Shaun Walker |
|
|
1.6 |
2.0最终版发布更新。 |
Shaun Walker |
|
|
1.7 |
|
Jeremy White |
|
|
1.8 |
|
Jeremy White |
|
|
1.9 |
2.2版更新 |
Shaun Walker |
目录
简介
“ 传统上网页设计公司依靠制作静态HTML网站作为主要的收入来源. 然而随着经济的门户应用程序先露头脚，用户很快就意识到动态网站所带来的好处。为了适应新的需求，网页设计人员应该知晓新技术带来的机遇。DotNetNuke的皮肤框架结构使得专业的网页设计人员可以创建极好的用户界面，并可以和后台的门户应用程序无缝结合，构建功能强大界面美观的网站。”
“皮肤”是指软件架构提供了一种可管理的方式将应用程序逻辑和内容与其展示形式相分离。 界面(form)和功能(fuction)的抽象通常指双层架构模式 。使用皮肤技术的优势是使应用程序逻辑和网页展示形式分离并能分别设计和修改。软件开发人员和网页设计人员可以相互协作，不用顾虑会影响对方。
––ASP的一个优点也是使其成为流行的网页快速开发工具的主要原因就是ASP脚本可以插入到常规的HTML中，使静态的HTML内容变成智能的网页。这样就可以通过创建asp应用程序通过数据库或其他的外部数据源创建动态网页，构建功能强大的web应用程序。
然而这样的享受也伴随着代价。大多数的asp网站的HTML和asp脚本向乱粥一样掺杂在一起，很难读懂也很难维护。当网页设计人员修改用户界面的时候问题就跳出来了。由于展示层嵌在asp脚本当中这些修改必须由开发和设计人员一同完成才能保证修改的完整性。最终结果是更多时间、更多精力和更多的开销。
皮肤技术包括使用“模版”，“模版”将展示和布局同应用程序逻辑分离。然后智能的皮肤引擎将各部分装配到最终产品当中。双层架构使得在维护网站的时候设计人员和开发人员都有了相当的独立性，工程发布后需要投入的时间和精力就会显著减少。
当然，皮肤系统在提供这种方便的同时也增加了web应用程序的复杂性。在合并大量文件生成一个单一页面的过程中可能导致web应用程序性能的下降，同时也要求开发者必须具备良好的素质确保表现层及内容在他们的脚本代码中得到良好的表达和精确的定位。以上两个问题可以通过技术和一个可靠的皮肤系统得以减轻。
术语
术语 “Skinning（皮肤）”是一个很难用语言解释清楚的东西，简单的说，一种皮肤体系提供给你一个静态的布局，但允许你修改颜色和样式甚至可以用你的图片代替原有的图片，另外一种皮肤体系则拥有允许你自定义除了内容以外的任何外观上的表现。这两种手段有着明显的区别，你需要根据你的商务需要去选择最适合你的应用程序的解决方案。
Windows 客户端程序
皮肤技术在Windows客户端程序中已经流行了相当一段时间了，这或许会让你认为不需要太大努力就可以将同样的皮肤体系运用在你的web应用程序上，然而，这个想法被证明是一个错误。
这是由于Windows 客户端程序并没有和web应用程序相同的需求，一个Windows 客户端程序界面可以使用多种分解技术而并不会对性能产生任何影响，这是因为Windows 客户端程序的用户界面具有长久的容器生命周期，而web应用程序的界面则是对web浏览器的对每个页面的请求进行装配和传输的，这就要求我们需要一个高性能的表现层机制来应付web应用程序的需求。
技术
有很多种方法可以从页面上提取用户界面元素，每种方法都包含不同程度的分解元素，需要将表现层与业务层融合在一起。因此，定义何处，何时，以及这些分解元素如何产生成为整个解决方案的重点。
在很多脚本语言中很流行的一种技术是用在用户界面文件中使用标记或标识符描述动态函数，当页面被载入时，这些标识符将被对应的应用逻辑取代。不管采用什么方法（智能分解，字符串函数，正则表达式等等）来完成这个替换工作，关键在于web应用程序的界面是当页面被处理的时候产生的，如果在每个请求之后都进行一次替换工作，那么性能将无可避免的受到影响。为了减轻这种影响，最佳的解决方案需要利用预处理或者汇编技术。
Asp.Net 提供了强大的抽象web页面成为一个组件的特性。用户控件类似于传统的ASP中的 #include标志…除了性能上的区别。用户控件使得分离用户界面和在不同页面重用成为可能。用户控件和一个aspx页面只有两个差别：一个是后缀，用户控件的后缀为ascx，另一个就是他可以不包含<HTML>, <Body>, 或者 <Form>标签，其他几乎没有区别。用户控件可以插入大量的文件中，将表现层从应用程序或者后台代码中分离出来。这个特性允许创建大量的引用同一后台代码的表现层文件 ，另外由于Asp.Net是一种编译过的语言，页面由大量的编译过的用户控件组成，这使得传送的效率相当高，比那些解释型的语言来得快得多。
定义
在任何一个皮肤解决方案当中要考虑的另一个重要方面是皮肤作者的界定。谁会创建皮肤？什么技术更适合他们。在他们的日常工作中使用什么样的设计工具。在这一方面的考虑决定了如何的定义皮肤。
Asp.Net的用户控件技术给我们提供了较强的核心支持，他们是微软平台相对较新的技术。一些设计工具(如. FrontPage, DreamWeaver, 等 ) 已经提供了对用户控件技术的支持。在这一概念对于一些专业的网页设计人员还很陌生。可以不要说用户空件中包含了Asp.Net 服务器端控件中不畏设计人员所知的属性。网页设计人员打乱或删除重要的服务器端控件的风险是不可接受的。基本上我们希望网页设计人员选择自己的工具设计皮肤并保持和用户控件分离。
最后皮肤解决方案应该能让网页设计人员通过简单和基本的技术创建皮肤。 对于万维网HTML是最低的通用语言，并被网页设计工具所广泛支持。 唯一的问题是HTML是静态的-而web应用程序要求动态的元素。
总和以上对解决方案的描述,允许设计人员在HTML中插入占位符来代替动态内容会很有效。 这就提供了对表单（form）和功能(fuction)的很好的抽象。皮肤文件在修改的时候不会影响应用程序逻辑。 应用程序逻辑也可以在不影响用户界面的情况下重新定义。唯一的问题是额外增加的层会降低性能。
DotNetNuke
在DotNetNuke
不幸的是，在最佳解决方案的看法上具有很多不同的观点，需求分析的进度因此而停滞不前。大部分这些观点都带来了技术实现方案并且不久又有大量的关于皮肤体系的有价值的建议在社区中被提出——这些观点都有他们自己的优点和弱点。如何选择这些解决方案作为DotNetNuke 的核心程序是一件具有非常大压力的事情。实际上我们并没有全盘接受任何一个方案，围绕着所有的业务需求，根据我们理解，我们很慎重的建立了一个未完善的标准并发布了一个用于测试的解决方案，并尝试在实践过程中去完善它。
DotNetNuke 2.0对核心门户框架进行了一次大规模的重写，最初仅对数据访问层和业务逻辑层进行修改，但显而易见的对于表现层也必须重新检查和改写以达到我们的目的。 DotNetNuke 现在拥有了一个强大的皮肤体系，实现了表单（form）和功能(function)的分离，在这个文档接下来的部分，我们将介绍关于这个皮肤体系的详细技术实现过程。
概要
DotNetNuke崇尚简单原则，简单在不同的应用领域有不同的解释，在DotNetNuke中，我们的目标是使复杂的皮肤体系有一个人性化的表现——在使用和管理上简易方便。另外，性能是任何web应用程序的一个关键的问题，因此，我们在这个标准中多次强调这一点。好消息是在DotNetNuke 的皮肤体系中兼具优越的性能和简易性，这在一些案例中已经被证明。
在底层技术上，Asp.Net用户控件明显优越于模版管理。因为用户控件是经过编译的，这在性能上明显高于解释型语言。从后台编码的业务逻辑中提取表现层也是一个关键的特点。
为了使创建皮肤对web设计者来说尽可能的简单而且灵活，我们决定使用纯粹的HTML来定义皮肤。这样做的好处是设计者可以使用他们习惯的工具来创建和维护皮肤。我们定义了一些占位符来将皮肤对象从静态标记中分离出来，设计者可以在设计完成后插入到他们的皮肤中。占位符就是如[TOKEN] 一样的简单文本，它和皮肤对象是一一对应的。为了减轻在替换过程中的性能损失，我们建立了一套简单的皮肤上传机制来进行这种替换生成可以直接由DotNetNuke表现出来的用户控件。这个预处理仅在皮肤上传过程中执行一次。这个方法让我们享受用户控件在性能上的优势而且满足了web设计者与web开发者独立开发的需求。
在布局方面，DotNetNuke允许皮肤设计者自由的组织他们想要的页面布局。为了将内容模块插入页面，设计者可以创建任意数量的可以放置模块的内容栏。这种自由的方法提供了在界面设计上的灵活性，但同时也在无缝集成即插即用的皮肤系统上增加了一定的复杂性。为了达到真正的即插即用，每个皮肤的布局，名称，内容栏的数量必须是协调的。
大多数皮肤解决方案都存在一个弱点，那就是皮肤组件总是去定义他自己的布局和外观表现。在DotNetNuke 中，内容模块向这种体系提出了强有力的挑战，通过复杂的内容模块和大量的函数来表达一个单一的控件，使得控件至少包含了一部分布局特性。这就严格限制了他的使用，必须依赖于皮肤的指定区域 ( 比如他可以仅被插入到一个大的皮肤栏目中)。更糟糕的是如果一个内容模块包含静态的文字，颜色，图片或者样式，这就更限制了他在皮肤解决方案中的作用。
文件组织
皮肤可以应用到主机、站点或者分页级别。 皮肤也可以应用到模块级别，但这时我们称其为容器。所有的皮肤文件保存在portals文件夹下。有一个名为_default的特殊文件夹代表主机的文件夹，然而每一个站点都一起在数据库中的ID为名字有各自的文件夹。这样的结构使得整个网站中需要读写权限的文件夹集中到一个单一的文件夹里。同时使得文件的物理组织和应用程序当中的逻辑应用联系起来，这样就不需要外部数据库支持就可以管理两者之间的关系。
皮肤和容器可以包含不限数量的子文件夹– 每个文件夹代表构成皮肤必须的一个文件包。 子文件夹以皮肤的名称来保存。使用名称增加了不同皮肤间重名的可能性，然而这样当你直接通过文件系统管理文件的时候就不必考虑要和外部数据源保持一致的问题。
页面处理
DotNetNuke 使用单一的 ASPX 页面 ( Default.aspx ) 来展示所有的控件和内容。这样做的好处有两个。首先由户界面管理逻辑集中到了一个单一的页面上，其次是坚少了应用程序的入口，增强了方案的安全性。Default.aspx只有很有限的功能 –包含页面管理的<HEAD> 元素、包含用来放置皮肤的占位符。
当用户第一次访问DotNetNuke 应用程序的时候, 首先检查从用户浏览器发来的 URL 和 request header（怎么翻？？）, 确定所用的皮肤. 这个过程需要访问数据库中的Skins表，这个表里包含了所有的皮肤和容器的使用分配表。 分配表以等级的方式存储这样子分配就可以覆盖父分配 (例如，分页级别的皮肤设置应该覆盖站点级别的皮肤设置).核心程序通过有效的对象缓存来减少由于获取当前皮肤设置而访问数据库对性能的影响。
一旦皮肤确定，相关的用户控件就可以动态的加载并安置到页面上的占位符上。每一个使用皮肤的空间都要引用保存在\adimin\Skins文件夹里的skin.vb文件。这个文件负责皮肤处理中的所有工作：安全管理、加载内容。
皮肤包
皮肤包或者容器包由构成一个完整皮肤的大量文件组成：
- *.htm, *.html 文件——在皮肤上传机制中用来建立*.ascx文件的皮肤定义文件。
- *.ascx 文件—— 皮肤机制对html文件进行必须的格式化和预编译后产生的用于定义皮肤的用户控件。
- *.css 文件——与皮肤相对应的样式表文件。
- *.gif, *.jpg, *.jpeg, *.png ——皮肤中的图形文件。
- *.* ——其他在皮肤中使用到的资源文件（注意需要在站点上传文件拓展名设置中允许上传。）
一个皮肤包中可以包含多个的皮肤文件，这允许设计者可以创建多个拥有相同图片，但在布局方面却略有差别的系列皮肤。显然，当你将作一些常规表现层的修改，包含越多的皮肤文件就需要更多的工作。
大多数“包裹”体系使用文件清单的概念来识别包裹中的各种文件并定义额外的包裹属性。虽然这种概念有利于原始数据的性能，但是同时引进了额外的创建和维护的工作。对于产品的维护，我们的主要观点是：简单的将这些文件压缩成一个压缩包比起引进一个清单具有更大的好处。
皮肤定义
皮肤的定义可以通过来种方法来创建：HTML或者ASCX（用户控件）。如果你是一个对Asp.Net并没有多少了解web设计者，那么HTML是最好的选择。如果你对Asp.Net比较熟练，而且打算用VS.NET这样的工具来创建皮肤那么ASCX是你的第一选择。基本上，这两种方法的区别仅在于皮肤定义文件后缀以及对应用户控件标识符不同（详细请查阅附录A）
一般一个皮肤包最少需要两个皮肤文件，一个用来定义网站前台的布局，一个用来定义网站后台管理的布局。前台一般拥有各式各样的内容控件以及不同的布局栏目，而后台管理界面则仅有一些管理控件放在一个单独的栏目里面。
制作皮肤
制作皮肤没有特定的顺序，但如果按如下顺序操作会更好。
- 设置皮肤开发环境
为了简化皮肤的开发并加快后续打包的速度，建议按如下的文件结构组织文件
\Skins
\SkinName ( 你开发的皮肤包的自定义名称 )
… ( 这里放要发布的皮肤包的zip文件)
\containers ( this is a static name to identify the container files for the skin package )
… ( 与容器相关的所有资源文件 )
\skins ( this is a static name to identify the skin files for the skin package
… ( 与皮肤有关的所有文件 )
例如： - 设计皮肤
The free-form nature of skinning provides almost unlimited creative freedom with your design. 设计者通常创建一幅图片作为最初的设计原型( 使用PhoteShop或其他的专业设计工具 ). 应当注意的是在原型设计当中应包括所有的用户界面元素，包括静态元素如图片和文本，同时也要包含动态元素，如登录链接、导航栏、菜单等。 but it should also include active elements such as Login links, a navigation/menu system, etc… 由于本系统在运行时动态的加载内容，所以在设计是要为这些内容留出空间。Since this is a portal system which injects dynamic content at runtime, you will need to leave room in your design for this content.
设计结束的时候，设计者就要站到下一步：将图片转换为html文档。如何有效的降图形元素转换为html形式涉及到很多技术问题。HTML展示形式要比自由战士的图片要规整很多而且将图片转换为HTML文档对于最终产品的展现形式非常重要。由于HTML文档本身也有很多动态的属性，所以你也需要处理这些动态的问题。例如, 你学要确定皮肤的某一部分是否根据客户端浏览器的屏幕分辨率缩放或者保持固定宽度。
- 选择HTML 或ASCX编辑器.
如果你熟悉HTML表格和相关属性并且能处理简单的CSS，你就可以制作皮肤。 所见即所得的编辑器是其变得相当容易。 你可以使用 FrontPage, HotMetal, ColdFusion, DreamWeaver, VS.NET等等，任何你喜欢的编辑器。 ’反正都是HTML。
所有的HTML标记必须是"well formed." 就是说所有的HTML标记都必须闭合。 例如, 你有一个 <TABLE> 标记, 就必须用</TABLE> 闭合。所有的标记的属性的“=”边上不留空格, 属性值必须有双引号( 如<TABLE WIDTH=”
- 管理图片
图片是皮肤设计内在的一部分。为了让皮肤引擎能找到你的图片文件，在引用图片的时候你需要使用特殊的格式。将图片文件和皮肤文件放在同一个文件夹里是个好办法。当然也不是必须这么做，因为皮肤引擎能识别你所指定的任何文件夹。
为了让DotNetNuke找到你的图片文件，皮肤上传工具必须在处理皮肤包的时候将图片引用的URL转换为相对路径。这种路径形式能在加载皮肤图片时有最好的性能 (相对路径不需要在运行时每次请求都要进行检测).
皮肤上传工具将会将如下的HTML标记转化为相对路径( 包含在HTML或ASCX 文件中的 ): IMG SRC, TD BACKGROUND, SCRIPT SRC. 同时也会处理叠层样式表( CSS )标记: BACKGROUND-IMAGE:URL(). 为了支持众多HTML编辑器产生的代码，各标记的顺序对于皮肤上传工具并不重要。
DotNetNuke 包含一些静态的图片并不能自皮肤包中设定。这些图片代表应用程序的全局管理功能，存储在网站的/images文件夹下。 在完全灵活的皮肤架构中绝对不应该有静态图片。也就是说在灵活和性能之间应该有一个折中，在这方面DotNetNuke选择了后者。使用静态的管理图片主要有如下几点好处: 1)提高性能，皮肤架构在单一的位置访问管理图标，而不要那个一个一个的确定该图标在皮肤中是不是存在2) 简化皮肤管理，皮肤中只需要包含同皮肤直接相关的图片 3)减少磁盘空间占用， 管理图标不必在每一个皮肤包里都包含4) 使DotNetNuke有一致的管理界面体验 –每一个皮肤的管理图标都一致对编写文档和用户培训有好处。
- 加入皮肤对象Skin objects和内容块Content Panes
皮肤对象是在运行时动态处理的对象。 如果你要创建 ASCX 皮肤， 你就需要指定 @Register 和实际的用户控件标记 (如 <dnn:Login runat="server" id="dnnLogin" /> ). 如果创建的是 HTML皮肤，你只需要简单指定标记即可( 如 [LOGIN] ). 为了设计皮肤了解每一个皮肤对象的功能很重要 ( 参见附录B ).
除了皮肤对象还有一个概念内容块 Content Panes. 内容块是运行时动态插入的内容模块的容器。内容块是带有和DotNetNuke皮肤交互的自定义属性的简单HTML标记。 内容块允许的HTML标记有<TD>, <DIV>, <SPAN>,和<P>. 最精简的情况下你也必须包含至少一个内容块，并将其命名为“ContentPane”. 内容块不需要连续 ，他们可以在页面的任何地方。 内容块时可折叠的，也就是说如果在运行时内容块也不包含仁和内容，它就是不可见的。如果你创建的是HTML内容块，你就可以在设计中使用皮肤标记[CONTENTPANE] 来表示你要插入内容的区域。
皮肤对象支持实例命名named instances. 例如, 你想在皮肤中包含两个菜单控件, 你就可以在皮肤文件里设定 [MENU:1] 和 [MENU:2]. 多数情况下在你的皮肤里只使用一个皮肤对象实例，所以最好使用单一实例方式 ( 如 [MENU] ). 实例命名对内容块很重要，因为多数情况下在皮肤中你需要使用不止一个内容块。这样你就需要使用 [CONTENTPANE:1], [CONTENTPANE:2], 等实例命名( 由于 [CONTENTPANE] 是默认的 皮肤块，所以你必须有一个内容块叫这个名字).
皮肤对象还包含属性。 属性允许你在皮肤中自定义皮肤对象的外观。每一个皮肤对象都包含一个属性对象集，详见附录B.如果你创建的是ASCX 皮肤，你就需要在皮肤中直接指定属性 (如 <dnn:Login runat=”server” id=”dnnLogin” Text=”Signin” /> ). If you are creating HTML skins then you must include your attributes specifications in a separate file – this preserves the presentation of the HTMLskin file for the designer. 皮肤包可以包含全局属性设定文件“skin.xml” ( 或者容器的 “container.xml”) ，应用到皮肤包的每一个文件. 另外, 你也可以通过为皮肤提供一个 “skinfilename.xml”文件来覆盖全局皮肤属性设定.皮肤上传工具通过将皮肤属性设置和HTML展示文件合并创建一个ASCX皮肤文件。下面的xml片段描述了属性文件的结构:
<Objects>
<Object>
<Token>[LOGIN]</Token>
<Settings>
<Setting>
<Name>Text</Name>
<Value>Signin</Value>
</Setting>
</Settings>
</Object>
</Objects>
注意在xml文件中将是一个接一个的皮肤对象的定义和属性设置( 如 [MENU] ) ， 当然也包含实例命名. 例如，你想在皮肤中包含一个垂直的和一个水平的菜单，你就可以在xml文件中指定两个实例命名 [MENU:1] 和 [MENU:2]，并设置不同的属性。
在创建HTML皮肤并使用多个内容块的时候，你需要在属性文件里指定“ID”属性。
<Objects>
<Object>
<Token>[CONTENTPANE:1]</Token>
<Settings>
<Setting>
<Name>ID</Name>
<Value>LeftPane</Value>
</Setting>
</Settings>
</Object>
</Objects>
- 创建叠层样式表
DotNetNuke使用外部叠层样式表 (CSS ) ，以充分利用叠层样式表优点。 实质上DotNetNuke可以在同一个页面引用多个 外部的叠层样式表，每一个叠层样式表的引用都指定引用顺序，这样就可以实现层次覆盖. 叠层样式表的层次顺序简述如下( 每一项覆盖前一项):
1. Modules – 自定义的模块样式定义在 PortalModuleControl.StyleSheet
2. Default – 默认主机样式 – default.css
3. Skin – 皮肤样式 – skin.css 或 skinfilename.css
4. Container – 容器样式 – container.css 或 containerfilename.css
5. Portal – 由门户站点管理员定义的样式 – portal.css
皮肤包可以包含一个名为 “skin.css” ( 或容器的 “container.css” ) 的样式表，应用到皮肤包中的文件. 另外你也可以使用“skinfilename.css” 为皮肤指定样式覆盖全局的皮肤样式. DotNetNuke 默认的样式表 ( /Portals/_default/default.css )中包含多个CSS "classes" (the entries that start with a period)，门户站点依赖于这些样式获得一致的用户界面体验。你可以随便创建自己的样式，但是至少你应该覆盖默认样式来和你的皮肤设置一致。
- 发布皮肤
为了能在Skin Gallery中能看到你的皮肤，你需要创建一个高质量的屏幕截图。
你也应该为每一个皮肤或容器创建对应的扩展名为JPG的屏幕截图 (如果你的皮肤文件为skin.html，则屏幕截图为skin.jpg ).
- 将皮肤打包
所有的皮肤相关的文件将被打包到一个zip压缩文件. 如果你使用Windows XP, 或者安装了 "Compressed Folders"功能的 Windows ME,你可以在文件加上单击鼠标右键选择 "Send to >", 单击 "Compressed (zipped) folder." 操作系统会为你压缩好，然后就可以上传了。如果没有上述操作系统，可以使用Winzip或其他的zip压缩工具。
许多时候你可能要将皮肤文件和容器文件打包到同一个压缩文件中。为此你学要将容器文件压缩为“containers.zip”. 同样把皮肤文件压缩到“skins.zip”. 然后将两个文件压缩到同一个压缩包里，按照你皮肤的名称命名你的压缩包。 这样人们就可以通过皮肤上传工具上传一个文件就可以安装整个皮肤( 同时包含皮肤和容器 ) 。
容器的创建
根据早期的想法，容器也属于一种可以应用于内容模块的皮肤定义。容器如皮肤一样被精确的定义其外观，不同的是两者的设置是不一样的。
比起皮肤唯一额外的限制是在创建容器时行为控件必须被包含在容器的皮肤。行为控件是DotNetNuke一个新的特性，它扮演一个将内容模块功能性与门户框架连接起来的角色。行为控件实质上是一个让内容模块功能性表现出来的一个用户界面控件。它的主要功能包括：能够管理模块在内容栏目中的位置，能够编辑模块的设置。同时具有对特定模块自定义的功能的能力，允许用户编辑内容以及导航到其它控件。在DotNetNuke 中有许多这样的行为控件。默认的行为控件是SolPartActions 控件，当你的鼠标移动到默认容器的左上角时它可以弹出一个下拉菜单。这个控件对于高版本的浏览器来说无疑是合适的，但由于低版本的浏览器无法支持这个弹出特性，我们同时采用了一个DropDownActions 控件,他可以在低版本的浏览器中表现出下拉框。
虽然皮肤和容器被单独的创建，打包以及配置，但还是需要有意识的将它们结合在一起。当然，这可以通过上传机制来实现并将它们应用于网站的用户界面。这样的操作只是一个简单的过程，你的用户界面还会有很大的间隔，因为大家都知道栏目在皮肤还是可见的。栏目级的设置只能在皮肤设计者设计皮肤的时候加以设置，包括在栏目使用自定义属性来增加栏目的功能。可以使用容器类型，容器名称和容器的地址这些属性来定义将要使用在所有模块的容器。为了使其正常工作，这些特殊容器必须放置在一个特殊的位置，否则将显示默认的容器。
<Objects>
<Object>
<Token>[CONTENTPANE:1]</Token>
<Settings>
<Setting>
<Name>ID</Name>
<Value>LeftPane</Value>
</Setting>
<Setting>
<Name>ContainerType</Name>
<Value>G</Value>
</Setting>
<Setting>
<Name>ContainerName</Name>
<Value>DNN</Value>
</Setting>
<Setting>
<Name>ContainrSrc</Name>
<Value>standard.ascx</Value>
</Setting>
</Settings>
</Object>
</Objects>
在2.0版本之前，DotNetNuke拥有一些有限的模块容器功能，允许管理者使用HTML来给内容模块提供自定义的边框或者轮廓。这种容器的观念有很多问题，比如提供的图形存储于站点的上传文件夹，每次请求都必须分析一次HTML来将它们结合在一起，而且表现也是完全静态表现。然而虽然有这些限制，还是有许多容器包被创建和发布。为了管理和维护这些容器，一个用来将容器图片放在它们专属的一个子文件夹并提供一个选择机制的第三方插件被发布。好消息是现在，将这些最早的容器转换并融入新的DotNetNuke 皮肤体系只需要做一点细微的修改。（更多详细信息请参考附录C）
皮肤上传
一旦基于ASCX文件格式的可以执行的皮肤被加入到ASPX页面中，一些皮肤文件中的恶意脚本可能危害到整个系统。基于这个考虑，主机拥有对主机或者网站进行皮肤上传的授权功能。用HOST账户登录，选择主机栏目下的主机设置，你可以看到这个选项。如果该选项被设置成Portal（默认），那么网站的管理者可以不受到主机的干涉上传自己网站的皮肤。
任何文件上传的功能都被集中在DotNetNuke 中网站管理或主机管理下的文件管理栏目。在网站管理下的文件管理中上传皮肤则这个皮肤仅适用于该站点，而如果在主机管理下上传皮肤则适用于该主机的所有站点。文件管理器有一个上传选项，选择该选项则出现允许上传皮肤和容器包的文件上传界面。在上传压缩包之前应选择适当的文件用途选项（应用程序通过这个来区分压缩包的用途）。注意：如果没有得到上传授权，这个选项无法出现。：（
皮肤上传机制将自动解压缩皮肤包，创建必要的文件夹并释放文件，而且还会通过Asp.Net脚本将HTML文件中的占位符替换掉以实现将HTML文件转换成ASCX用户控件的目的。这个转换是按照数据库中ModuleControls表中皮肤对象的定义来实现的。ASCX用户控件文件和CSS样式表文件依旧以相对路径的方式关联图形文件。注意：如果你上传的皮肤包同时包含了皮肤和容器( containers.zip and skins.zip )，那么应该选择皮肤包选项。
XCOPY 部署
在DotNetNuke
皮肤管理
在DotNetNuke中，皮肤可以以多种等级运用。类属选择控件用来表现站点用户界面不同区域可以运用的皮肤。每个站点可以像主机皮肤一样使用自己的皮肤。皮肤以子皮肤可以覆盖父皮肤的等级机制来进行配置。比如说，运用于频道级别的皮肤总是取代门户级别的皮肤。
主机级别
主机级别的皮肤运用于主机的所有站点。他们可以由超级用户在主机配置中设置。用户可以配置前台站点和后台管理界面的皮肤或者容器。
站点级别
站点级别的皮肤运用于特殊的站点，他们可以由该站点管理员在站点设置中设置。用户可以配置前台站点和后台管理界面的皮肤或者容器。
频道级别
频道级别的皮肤运用于网站中特殊的频道，他们可以由站点管理员在栏目设置中设置。用户可以配置频道的皮肤或者容器。
栏目级别
栏目级别的皮肤实际上是模块的容器，运用于频道中的特殊栏目。他们必须由皮肤设计者在创建皮肤中配置，无法在站点的用户界面中被管理。只可以通过模块级别的皮肤来覆盖栏目级别的皮肤。
模块级别
模块级别的皮肤也叫容器，运用于特殊的模块（比如频道中的内容模块）。他们可以由站点管理员在模块动作菜单中的编辑模块设置中设置。
皮肤预览
DotNetNuke拥有皮肤预览功能，允许管理者在运用皮肤之前预览缩略图。皮肤设计者必须创建一张JPEG格式的皮肤截图并打包在皮肤包中，这样才可以显示缩略图。
控制条
为了达到所见即所得的目标，当管理员的身份被识别，控制条将被动态的插入页面。控制条提供了多个频道和模块的管理选项。默认状态下，控制条横向显示于浏览器的顶端，这样做的目的是让整体页面的显示尽可能的不受到影响。
皮肤解决方案也允许用户改变默认的控制条位置使其包含在某个栏目中，方法是在自定义皮肤中设置一个名为“ControlPanel”的栏目。这个栏目可以放置在页面中的任何位置——但是必须记住的是它仅仅在网站管理员和主机管理员登陆的时候显示。你也可以通过站点设置创建或修改自定义控制条。
数据模块
为多种应用等级配置的皮肤设置必须是稳固的，所以这些设置需要存储在数据库中。为了对核心的站点表产生尽可能小的影响，我们创建了一个外键允许为空的映射表。这个映射表存储了皮肤的配置信息，包括页面皮肤和容器，并且允许前台站点和后台管理页面具有不同的皮肤。站点，频道，模块的等级关系表现为一个平面，这样就允许了简单的查询来确定对任意对象的皮肤的正确分配。
映射表的数据存储是相当简明的——唯一的复杂性在于ID字段。如果一个站点ID为空，则该站点将引用主机级别的皮肤，如果不为空则引用特定站点的皮肤。同样一个频道的ID引用一个特定频道皮肤，一个模块ID引用一个特定模块的容器。如果在映射表中找不到需要的数据，应用程序将使用默认的应用程序皮肤和容器 ( _default )。
皮肤对象
皮肤对象是一个可以包含在皮肤文件的静态HTML标签中的动态元素，它提供了动态的用户界面。由许多默认的皮肤对象已经包含在DotNetNuke 中(请看附录B的定义)，这些默认的皮肤对象提供了最普遍的应用程序函数，比如登陆，身份，以及导航。然而，事实上一个解决方案如果没有良好的拓展性，那么它将无法称为优秀的解决方案。基于这个需求，DotNetNuke 添加了允许用户创建和安装自定义皮肤对象的特性。
自定义皮肤对象和自定义模块（私有配件）的安装是一样的。所有必须的皮肤对象资源文件与DotNetNuke 清单关联在一起，并压缩成ZIP包。
一个皮肤对象创建成私有配件的样本已经包含在/DesktopModules/PageTitle 中，如下所示的*.dnn清单定义了该私有配件包：
<?xml version="1.0" encoding="utf-8" ?>
<dotnetnuke version="2.0" type="SkinObject">
<folders>
<folder>
<name>CompanyName - PageTitle</name>
<modules>
<module>
<controls>
<control>
<key>PAGETITLE</key>
<src>PageTitle.ascx</src>
<type>SkinObject</type>
</control>
</controls>
</module>
</modules>
<files>
<file>
<name>PageTitle.ascx</name>
</file>
<file>
<name>YourCompanyName.PageTitle.dll</name>
</file>
</files>
</folder>
</folders>
</dotnetnuke>
致谢
在DotNetNuke中实现的皮肤解决方案获得了大量优秀的程序员无私的帮助和努力。我们在这里将感谢：
Bandar Naghi HostIsIt Networks ( http://www.naghi.net ) – 版面设计
Phil Beadle of Nexxus Systems International ( http://www.nexxus.com.au ) – xml皮肤
David Haggard and Erik France of NewCovenant Evangelistic Ministries ( http://www.newcovenant.com ) – HTML 主题
Snapsis Dynamic Website Services ( http://www.snapsis.com ) – CSS皮肤
Joe Brinkman of TAG Software ( http://www.tag-software.net ) – 模块名称
and Steve Fabian of Gooddogs.Com (http://www.gooddogs.com/dnn ) - 加强的容器.
同时我们要感谢SMARTY template engine ( http://smarty.php.net/ ) 的概念设计。最后，我们要感谢微软的Asp.Net项目组提供了如此强大和优秀的web应用程序框架。