文章标签 ‘模板引擎’
[转载]DotLiquid-Asp.net模板引擎 – loogn – 博客园. 以前用过一段时间的PHP，感觉非常不错，其中最让我难忘的就是Smarty模板引擎，当时就微微地想ASP.NET里有没有像这样的模板引擎呢？不过由于之后的工作内容都用不到，或者说没有想到用模板，这想法也没导致我做一些事情，就不了了之了。 现在也是工作需要，用模板是一个不错的选择。之前没用过这种东西，盲搜一片没找到自己想要的，于是自己就试着写写，大思路用的是Smarty的，用html页面做为模板，生成aspx页面，把数据放在HttpContext.Items里，代码如下： html模板： <div>{$title}</div> <select> {foreach $l in $list} <option value=”{$l.Age}”>{$l.Name}</option> {/foreach} </select> 生成的aspx页面： <%@ Page Language=“C#“ %> <% if (HttpContext.Current.Items["SMARTY_TEMPLATE_DIR"]==null) { Response.Write(“no direct access allowed“); Response.End(); } %> <div><%=DotSmarty.Smarty.GetTemplateArg(“title“) %></div> <% var list = DotSmarty.Smarty.GetTemplateArg(“list“) as System.Collections.Generic.IList<SmartyTest.User>; %> <select> <% foreach (var l in list){ %> <option value=”<%=l.Age %>”><%=l.Name %></option> <%}%> </select> 调用如： Smarty smarty = new Smarty(); List<User> list = new List<User>(); list.Add(new [...]
[转载]小泥鳅解剖系列之模板机制 – 小泥鳅博客技术交流区 – 博客园. 为了给小泥鳅实现一套好的模板机制，曾经花了大量时间来分析目前互联网上的成熟,流行的通用程序,包括blog,cms,shop,bbs/.net,php,asp等，总结下来主要有以下几种： 1、CSS 通过加载不同的CSS文件来实现不同的展现效果。 相信熟悉CSS的话，便知CSS的强大，ASP.NET的默认主题基于此实现 优点：维护方便，速度快 缺点：2/8原则，可以实现大部分功能，灵活性不够 2、模板引擎 通过加载不同的模板文件（模板文件内容可不同），使用模板引擎自己的语言机制动态替换数据，来实现不同的展现效果。 优点：灵活，可实现绝大部分需求 缺点：影响性能，需要引入第三方模板引擎(当然可以自己开发)，增加复杂度。 3、.ascx用户控件，母版页（.Net平台独有） 通过加载不同的.ascx用户控件来实现不同的展现效果。当然也可以动态加载. master母版页。 原理和使用第三方模板引擎类似。 优点：可使用.net语言，比模板引擎更灵活，可实现任何需求 缺点：通过反射机制影响性能(据说，未验证)，.net特征偏多，对美工不友好 4、生成.aspx文件 需要使用一次模板引擎生成.aspx文件，利用URL重写加载不同的.aspx文件，运用时与模板引擎和模板文件无关。 优点：灵活，速度快 缺点：维护相对麻烦，修改模板后需要重新生成.aspx文件， 加入第三方模板引擎，增加复杂度。 5，xml+xslt 名词解释：XSL 指扩展样式表语言（EXtensible Stylesheet Language），XSLT 指XSL 转换 设计思想跟模板引擎一样，不过xslt是通用标准 优点：标准，跨平台，跨语言 缺点：不够灵活，容易出错， 对美工来说，偏复杂 问题来了，哪种更合适小泥鳅的呢？受Community Server，BlogEngine.NET等国外程序的影响，老农开始选择了第3种，通过动态加载不同用户控件的方式来实现模板机制，功能很给力，并且 在相当长的内部开发阶段使用了这种方式（胎死腹中），同时也是在这个阶段，在与其它职业的同事，朋友交流中，慢慢觉得这可能不是一种最合适的方式（实践出 真知），对于广大普通用户，特别是主题设计者，太多的.net特性会让他们看花了眼。 小泥鳅的定位一个成熟，通用，面向所有人群的博客程序，最后把焦点放在了模板引擎上， 现在.net平台的主要模板引擎有Nvelocity, StringTemplate等，经过多方面的测试，评估，最终选择了NVelocity，当然不排除今后有能力，有时间自己造轮子。 NVelocity源自Java，历史悠久，语法优雅，减少了重复学习的成本 如以下代码用于输出最新日志（简单就是美）： view sourceprint? 1 <div id=”recentposts” class=”widget”> 2 <h3>最新日志</h3> 3 [...]
[转载]MVC3.0 中Razor 学习 – RyanDing – 博客园. 随着MVC3.0RTM版本的发布，最近将公司的项目从MVC2.0升级到MVC3.0。同时打算在MVC3中全面使用Razor模板引擎。现将Razor学习拿出来和大家分享，如果存在不足的地方欢迎您指出。 其实在使用<%= %>在html中调用C#代码时，内心总在埋怨。这个写法非常麻烦。麻烦在哪呢？其实就是闭合。比如： ASP.NET: <script src=”<%=Url.Content(“~/Scripts/JQuery-1.4.4.min.js”)%>” Razor: <script src=”@Url.Content(“~/Scripts/JQuery-1.4.4.min.js”)” 非常明显，Razor在内部帮我们做了闭合“%>”。其实就是这个小小的闭合让我们可以在html内更加“流畅”的调用服务端代码。故Razor给开发带来了一定的便捷！下面介绍Razor的基本用法。 一、模板页 Razor出现后我们就可以选择不再使用ASP.NET master 模板页。取而代之的是cshtml razor的模板文件。用法个人认为还是和master模板页类似。但在mater模板页的原有功能上有了进一步扩展，更方便开发。比如只要在View文 件夹内加入_ViewStart.cshtml文件，我们就无需在每一个具体的View页面引入模板页。减少View页面内的重复代码。具体的可以建立一 个MVC3 Application 选择razor模板，VS会自动建立上述机制。这里值得提出的是@RenderSection方法。可以让我们在模板页预设一个区域，未来给继承该模板页 的View使用。具体请看以下操作： 在MVC3.0 shared文件夹下_Layout.cshtml这个模板文件内加入以下代码： view sourceprint? 01 <!DOCTYPE html> 02 <html> 03 <head> 04 <title>@ViewBag.Title</title> 05 <link href=”@Url.Content(“~/Content/Site.css”)” rel=”stylesheet” type=”text/css” /> 06 <script src=”@Url.Content(“~/Scripts/jQuery-1.4.4.min.js”)” type=”text/JavaScript”></script> 07 @RenderSection(“Head”, required: true) 08 [...]
[转载]代码生成技术–CodeDom VS T4 – 破狼 – 博客园. 在微软的自家代码生成方案中我们有两种选择方式:CodeDom 和Text Template Transformation Toolkit（T4）模板。同样我们可以利用简单的String或者StringBuilder来拼接字符串，但是那对于简单的还可以，但是对于复杂的 问题就。其实在ASP.NET MVC 3.0中有多处了一个更简洁语法的模板-Razor，我们同样可以运用于我们自己的代码生成中，我随便有一篇简单的介绍Razor Templating Engine，在以后有机会了会写Razor Demo。今天的主题不在这里，所以不多说了。 一：简介： CodeDom：这 个类库出现在我们的.NET Framework 2.0，并且被深深的用于我们的ASP.NET项目中。CodeDom关注于一个语言独立性，以至于我们可以利用我们熟悉的语言（C#，vb等）构建一个 CodeDom Model Tree,就可以生成我们在.NET平台所支持的语言代码。对于我们的ASP.NET要求语言的独立。 T4：T4模板作为VS2008的一部分出现，他以<# #> 、<#= #>接近于ASP.NET的语言在模板中插入一段段的动态代码块，可以像asp或者ASP.NET一样简单的更让人贴切，相对于CodeDom就更 简洁，但是没有了语言层次的抽象，不具有语言独立性，我们必须为同一个功能的模板在不同的语言上写不同的模板，但是在开发中往往C#模板就足够了，以及更 简单化所以得到了更多人的青睐。 二：Code Demo： 下面我们将用CodeDom和t4分别生成一个简单的Code，根据时间输出不同的问候，如下： 1：CodeDom Code: 代码 using System; using System.Text; using System.CodeDom; using System.IO; namespace RazorDemo { public class CodedomDemo { public CodeCompileUnit CrateCodeCompileUnit() [...]
[转载]闲语MVC3和Razor – 阿不 – 博客园. 原本没有这篇博客，直到看到ScottGu的这篇文章ASP.NET MVC 3: Razor’s @: and <text> syntax。我才决定，把我这几天对MVC3和Razor的一些观点记录一下。 关于Razor 因 为最近我身边的朋友和博客的博友，似乎对MVC3和Razor没有什么好感，甚至于认为微软开发Razor是走在另一条错误的路上。虽然我也没有在项目中 实际用到Razor，但是一直以来都还是挺关注Razor的进展，对它的语法也是了解一二，总体感觉就是更为干净和流畅了，其它的并没有更深的认识。晚上 在看ScottGu文章的时候，一段代码片段立即吸引了我： 你知道这段代码哪里吸引了我吗？没错，就是C#代码与html结合的非常流畅，（特别是它在花括号的处理上面，真的是让我眼睛一亮，因为目前最讨有花括号的ASPX代码了），相应的ASPX语法是这样的： 从两个代码片段对应，至少两点非常吸引我： ASPX 的语法，一句完整的foreach代码片段，被人为的拆分了几个不同的代码段。在书写上，我们可以通过Code Snippet来快速生成foreach代码格式，但是由于ASPX的语法问题，我们需要不断的去移动光标位置来把花括号拆分出来，在中间才放要输出的 HTML代码。在阅读上，我不得不去用第三只眼睛来数<%%>（其实我没有，只能让原本的两只多承担一点）。 不知道你注意到了没有，属于相同代码块的C#代码都会以高亮的方式显示。而在ASPX代码中，我们一眼是无法很好的区分哪些代码块是相关。 其实从这两代码我已经能够想像到，当我们的代码里面，出现了几层嵌套时的它们各自的场景了。由于ASPX是目前主要（几乎是唯一）的一种模板引擎，我已经几乎习惯，要睁大眼睛去匹配花括号对应关系的情况了，特别是当我们的代码超过一屏时，那真是一种享受啊。 在 读完ScottGu的整篇文章之后，自己做了几个新手实验之后，我大概明白了Razor的大概做法了。Razor在处理C#代码时，从以@开头的代码片段 开始（if..else, for,foreach，或是空语句@{}代码块）等语句，从{开始，到对应的}结束，在这个区域内都是可以写C#代码的区域，我们可以写任何的C#代 码，而不需要再有任何额外的标识，直到我们再次碰到： @(这时的@是用可以用于输出C#变量或属性值）。 @:用于输出静态字符串。 Html标签会直接输出，Html标签内的区域不属于C#代码区域，不可以写C#代码，里面的文件会直接输出，输出属性需要用@。 text文本块，text文本块也是以html标签的形式存在，但它不是标准的html标签，只是它会被Razor特殊处理，只输出text里面的文本，而它自身的标签并不会被输出。这对于我们需要输出多行文本时可能会非常有用。 这 里，我还想特别说明一点。我不知道大家是否有遇到，在ASPX里面，如果我要给标签的属性绑定C#变量时，我在里面就无法使用代码提示了。我经常都是要到 外头去写好一段代码，然后复制进去。这让我非常痛苦，即使我手工也可以写完那段代码。请原谅我的水平低下，我真的不是那种可以完全用notepad就可以 写程序的程序员。如果你跟我有一样的痛苦的话，Razor将会给你带来惊喜，看看真相如何： @是Razor的灵魂，所有的语法都是以@开头或结束，@using、@model、@**@、@: 。我目前知道的就这些了，但是不难想象，Razor的一切都会比ASPX来的简单，虽然@**@看着没有比<%– –%>强多少，但也还是比较有个性的 。甚至连Razor文件的图标都是@符号。 至 于模板的性质，Razor本身还是以服务器代码驱动的，而不是限制性的标记性语法。在View当中可以写任何代码，安全性方面确实需要考虑，但是从灵活性 来讲，我相信还是有很多程序员离不开自由模板的，虽然限制性模板也可以达到相同的目的。我一直在想，有没有办法可以单独限制View中的代码的访问权限， 类似于trust level，只是这个trust level是用来限制模板中的代码。 关于MVC3 关于 MVC3，我个人不否认我的跟进态度有点激进，以至于在会影响其它项目的情况下还是升级到MVC3 R2。其实在R1出来的时候，我就尝试过升级，但是由于一个很难绕过的Bug而放弃。原本是没有那么强烈的意愿升级到MVC3 R2，只是周一那天，同事在介绍MVC3的时候，提到的unobtrusive js，突然让我想到，我是否可以利用这个特性来突破我们那天遇到的难题。在那天前的博客当 [...]
