[Flex]Java正在让位于Flex吗?

mikel阅读(827)

Java正在让位于Flex吗?

作者 Moxie Zhang译者 张龙 发布于 2008年11月15日 上午8时14分

社区
Java
主题
RIA
标签
Flex,
ActionScript

随着富Internet应用(RIA)技术的不断成熟,开发者可选择的余地也越来越大了,这样他们就不可避免地会对已有的技术如Java造成冲击。最近,游戏开发公司Sharendipitous Moments发表了一篇名为“我们正转向Flash,这就是原因”的博文,讨论了Java是否正在让位于RIA技术,如Flex。

这篇博文首先说到Java技术依然很棒:

Java语言要远远优于ActionScript,Java编译器也更加先进。Java能做的事情更多。还有,尽管Flex Builder构建在Eclipse之上,而针对Java的Eclipse开发环境已经出来好几年了。但公正的说,我们只是将800个类和将近 60,000行的Java代码转化为了ActionScript。

Sharendipitous Moments之所以转到基于Flash的开发(Flex),主要原因在于Java的品牌。该博文说到:

Java的品牌太失败了。Sun很早就鼓吹JavaFX是用来拯救Java的,但它的发布时间太长了。同时,Flash继续占据着统治地位。Silverlight也是一个竞争者,但它还需要很长一段时间才能达到Flash那样的市场占有率。

根据这篇博文所述,品牌失败导致的结果是:“如果你看到Java applet正在被加载,那么你就会在页面上随便点一个链接而转向其他页面。”

很多开发者并不认可Sharendipitous Moments的观点。正如一个开发者所说:

没人用Flex处理关键的事情。但是这篇博文的博主却不敢苟同。他们都在说Java有多么地差,Flash是多么地好。具备即时 编译JavaScript能力的浏览器即将面世。你认识到这一点了么?Flash的目标不是Java,而是完全基于浏览器的应用。同时,Java既可以应 用在服务器端,也可以应用在客户端。

然而另一些开发者与Sharendipitous Moments的立场是一样。例如,Artima Developer的高级编辑Frank Sommers说到:“我刚刚将一个规模庞大的Swing应用移植到了Flex上,整个过程让我非常满意。我真正缺少的东西就是一个好的IDE,如 IntelliJ。Flex Builder 3要想达到IntelliJ那样的高度还有很长一段路要走”。

来自Sun的Ken Russell也加入了这场争论:

我对Sharendipity(很有特点的JOGL应用之一)迁移到Flash感到很失望。我们刚在Java SE 6 Update 10中完成了对Java Plug-In的重写,这会使Java applet的部署更加可靠、强大且轻便。6u10现在可以用在Linux、Solaris及Windows上,同时Sun也正在积极地与Apple合作 以完成Mac版本。对于重新激起Java平台上的客户端开发来说,这是万里长征的第一步。

软件开发咨询师Martin Wildam的态度比较中立:

我觉得你的想法站不住脚。从一般用户的角度来看,我觉得你说的很对,因为他们很可能在看到Java starting之前就已经转到别的页面去了。但我记得Flash的加载时间更长。用户是不会认识到这一点的,因为出现在他们面前的只是不同的动画而已。 如果总是看到相同的Flex-loading图标,他们很可能也不会再等了。

Java World说到

与此同时,Java Lobby上的一篇文章对于Java开发者转到Adobe RIA平台很有帮助。但这对于可怜的JavaFX来说还不是世界末日,Artima Developer的Frank Sommers认为还在发展初期的RIA语言从Swing中借鉴了大量的东西

该博文的作者Dale Beermann对以上讨论进行了总结,他说到:“我喜欢这种对话。这种讨论是没有限制的,我渴望不同的声音。来吧,朋友”。

查看英文原文:Is Java losing Ground to Flex?

[MVC]让ASP.NET MVC页面返回不同类型的内容

mikel阅读(731)

ASP.NET MVC的controller中大部分方法返回的都是ActionResult,更确切的是ViewResult。它返回了一个View,一般情况下是一 个HTML页面。但是在某些情况下我们可能并不需要返回一个View,我们可能需要的是一个字符串,一个json或xml格式的文本,一个图片。
ActionResult是一个抽象类,我们平时比较常用的ViewResult是它的派生类,所以我们也可以写一个StringResult、 XmlResult、ImageResult来实现上面提到的需求。由于返回字符串可以有更简单的方法,直接将需要返回字符串的方法的返回值设置成 string型就可以了,JsonResult在ASP.NET MVC中已经有提供。所以下面只演示XmlResult和ImageResult。
ASP.NET MVC项目是开源的(可以在http://www.codeplex.com/aspnet下载源代码),所以我们可以参考其中ViewResult和JsonResult的代码进行改写。主要的思路是设置返回数据流HTTP Header中的Content-Type,然后将要返回的内容写入Response中。


先演示XmlResult

XmlResult的代码:

 

 1 public class XmlResult:ActionResult
 2     {
 3         // 可被序列化的内容
 4         object Data { getset; }
 5 
 6         // Data的类型
 7         Type DataType { getset; }
 8 
 9         // 构造器
10         public XmlResult(object data,Type type)
11         {
12             Data = data;
13             DataType = type;
14         }
15 
16         // 主要是重写这个方法
17         public override void ExecuteResult(ControllerContext context)
18         {
19             if (context == null)
20             {
21                 throw new ArgumentNullException("context");
22             }
23 
24             HttpResponseBase response = context.HttpContext.Response;
25 
26             // 设置 HTTP Header 的 ContentType
27             response.ContentType = "text/xml";
28 
29             if (Data != null)
30             {
31                 // 序列化 Data 并写入 Response
32                 XmlSerializer serializer = new XmlSerializer(DataType);
33                 MemoryStream ms = new MemoryStream();
34                 serializer.Serialize(ms,Data);
35                 response.Write(System.Text.Encoding.UTF8.GetString(ms.ToArray()));
36             }
37         }
38     }

在controller中调用它

1 public ActionResult Xml()
2         {
3             // 创建一个DemoModal对象,No属性为1,Title属性为Test
4             DemoModal dm = new DemoModal() { No = 1, Title = "Test" };
5 
6             // 序列化为XML格式显示
7             XmlResult xResult = new XmlResult(dm, dm.GetType());
8             return xResult;
9         }

 

显示出来的结果

 

下面演示的是ImageResult

ImageResult的代码

 1 public class ImageResult:ActionResult
 2     {
 3         // 图片
 4         public Image imageData;
 5 
 6         // 构造器
 7         public ImageResult(Image image)
 8         {
 9             imageData = image;
10         }
11 
12         // 主要需要重写的方法
13         public override void ExecuteResult(ControllerContext context)
14         {
15             if (context == null)
16             {
17                 throw new ArgumentNullException("context");
18             }
19 
20             HttpResponseBase response = context.HttpContext.Response;
21 
22             // 设置 HTTP Header
23             response.ContentType = "image/jpeg";
24 
25             // 将图片数据写入Response
26             imageData.Save(context.HttpContext.Response.OutputStream, ImageFormat.Jpeg);
27         }
28     }

在controller中调用

 

 1 public ActionResult Img()
 2         {
 3             // 获取博客园空间顶部的banner图片
 4             WebRequest req = WebRequest.Create("http://space.cnblogs.com/images/a4/banner.jpg");
 5             WebResponse res = req.GetResponse();
 6             Stream resStream = res.GetResponseStream();
 7             Image img = Image.FromStream(resStream);
 8 
 9             // 输出给客户端
10             ImageResult r = new ImageResult(img);
11             return r;
12         }

结果图

这个比较多用在向客户端传送验证码图片时。

 

 转载:http://www.cnblogs.com/Snowdreams/archive/2008/11/15/let-aspnet-mvc-view-return-different-type-content.html

 

[C#]BlogEngine.Net架构与源代码分析系列part15:总结篇

mikel阅读(959)

     本文是这个系列的总结篇,在这篇文章里,仅从我个人的角度发表一下对BlogEngine.Net的一些看法。内容包括BlogEngine.Net的优缺点,性能问题,如何阅读源代码等。

     重申一下写这个系列的目的

1.使自己更加深入的理解BlogEngine.Net的架构,对BlogEngine.Net的代码能够更深刻的掌握。
2.给那些想学习BlogEngine.Net的源代码,但是不知道从何开始或者比较迷茫的朋友们一个学习指南。
3.在博客园上永远的保存下来,方便你我查看。因为这方面的资料实在太少了。

     关于如何阅读源代码

     其实BlogEngine.Net的注释已经很清晰了,但是由于它确实很大,很强 壮,我在学习它的源代码时还是走了不少弯路,曾经放弃过很多次,不过最后还是找到了感觉。BlogEngine.Net的最大特点就是麻雀虽小,五脏俱 全,从使用上看不到太多,但是它里面的东西真是很经典,设计和实现得很漂亮。我个人觉得我们在研究它时只要坚持以下几点就行了:
1.按照文章的顺序一块一块的研究:这个系列的写作顺序就是我觉得最佳的学习路线。
2.坚持住整体把握,细致入微的原则。也就是对它的源代码该宏观考虑的时候就要宏观考虑,该细细推敲的时候就要细细推敲。看代码时首先看看这段代码大概是做什么的,之后再去一行一行的看。对于弄不明白的地方,可以先放在一旁,以后你自然会知道的。
3.对于不确定的部分要一边调试一边看,就是F10,F11这样看。

     关于BlogEngine.Net的性能问题的一点看法

     BlogEngine.Net最初是一个单人博客,目前支持多人写博客,但是和 cnblogs这种社区博客还是有大区别的。其实我觉得BlogEngine.Net的市场定位也就是使用托管服务的单人博客系统。从它的实现代码中我们 可以看出对于Post等的处理方式是从持久存储设备完全填充到内存中的对象,评论中有的朋友提出这样处理的内存膨胀问题。其实我的看法是这样的,像 BlogEngine.Net这种市场定位的Blog系统中的Post再多也多不到哪去,Post中等存储的都是纯文本,对于图片,文件等大资源还是存储 在磁盘上的,这样的需求完全可以满足。再者BlogEngine.Net支持导出备份,我们完全可以在一定情况下将一些Post文本部分导出成 BlgoXML格式存储起来,之后删除一些Post,但是那些图片等依然保存不动,这样HttpHandler处理时依然有效。那么 BlogEngine.Net这样处理业务对象带来了什么好处呢?我觉得主要有以下两点:

1.控制上的灵活,数据的控制完全交给了业务对象,数据库等只是一个持久存储功能。

2.性能上的提升,BlogEngine.Net的那种搜索方式只能使用这样的业务对象数据处理方式才可以满足。

所以BlogEngine.Net在大用户量下的优势我觉得就会很明显,这也是这样的博客系统所需求的。我觉得像BlogEngine.Net这样的系统架构适合于应用在数据是动态的,数据量不是很大,但是用户量很多的系统设计中。

     BlogEngine.Net的特性和优缺点

     关于BlogEngine.Net的特性,大家可以参照一下官方的说明,表格上说明的很全,大家在阅读源代码时可以参照它,如果您弄清楚了所有这些特性的源代码,你实际上也就掌握了它。对于BlogEngine.Net的优缺点总结也都是我自己的个人看法,仅供参考,也欢迎大家讨论。

值得参考:
1.支持很多现有的XML标准格式,例如BlogXML,Apml,Rss等。
2.架构设计得很好,利用了很多面向对象设计的特性。很多地方使用了继承。
3.最大限度的利用了.Net Framework已有资源,例如Provider等。
4.很好的利用了C#的语言特性,例如泛型,特性等。
5.正则表达式,缓存等大量应用。
6.开发扩展的设计部分。Extension,Widget等扩展模型。
7.自定义的HttpHandler和HttpModule应用得很合适。
8.部分代码实现应用到了几个典型的设计模式带来了更好的解决办法。
9.Ajax的使用也很合适,达到了一定的页面效果。
10.代码分隔的很好,结构很清晰。

……

不推荐部分:
1.ExtensionManager部分还有待完善(前面有一篇文章提及过)。
2.Ajax在线预览有些地方不够完美(上文也提及过)。
行了,给BlogEngine.Net点面子,就先说这两点吧,实际上也想不出来了,因为我觉得它真是太完美了,也可能是我见识短吧。BlogEngine.Net的团队很优秀。

     结束语

     第一次写系列的文章,以前单篇文章也很少发布,现在知道写文章很不容易啊!最主要的是我的这个系列文章能给大家带来收获,哪怕一点点,我就会很高兴。

     博客园是一块圣地,我把我两周以来收获的果实种在这块圣地上,希望能给匆匆茫茫的过客带来一点收获。

     最后一句话:BlogEngine.Net真的是一件好东西!

     本系列完!祝大家学习愉快,工作顺利!

     上一篇:BlogEngine.Net架构与源代码分析系列part14:实现分析(下)——网站页面上值得参考的部分

 

     返回到目录

版权声明
作者:Thriving.country
出处:http://thriving-country.cnblogs.com/
本文版权归作者和博客园共同所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接.

[C#]BlogEngine.Net架构与源代码分析系列part14:实现分析(下)——网站页面上值

mikel阅读(741)

     BlogEngine.Net 的成功不仅在于它的架构设计,它的代码实现细节也都是很经典的,每个结构分割的很清晰很自然,希望大家多多品位一下。在这篇文章里我将给大家介绍一下 BlogEngine.Net的Web实现上的几个亮点,包括Web.config,Ajax的运用等。

     Web.config中的几个结点说明

     让我们看一下appSettings结点中的各个选项的含义,以便您对整个BlogEngine.Net的认识更加清晰。
BlogEngine.FileExtension:在这里我们可以自定义Url请求的后缀名称,默认是.aspx。您可以定义自己喜欢的扩展名,例如.extguo,那么对于文章等生成的Url就成了类似http://HostName/CategoryName/PostTitle.extguo的形式。这个结点的使用在很多地方都可以见到,例如:

Post类中的RelativeLink

BlogSettings.Instance.FileExtension就是读取这个结点获得的扩展名。

BlogEngine.VirtualPath:主要是为一些文章等的链接而服务的。我们可以使用虚拟目录安装我们的BlogEngine.Net,那么我们只要设置一下这里就可以得到和直接在根目录下一样的效果。我们需要注意一下Utils关于Url处理的部分,其中:

Utils中的RelativeWebRoot

就是获得相对Web目录。

BlogEngine.MobileDevices:它的值是一个正则表达式,主要是对移动设备做出判断,并给移动设备使用设置的主题。它在这里被使用:

Utils中的IsMobile判断

之后在BlogSetting的Theme中返回。

BlogEngine.AdminRole:管理员角色名,可以动态配置管理员角 色,也就是说系统对是否是管理员的判断中的管理员名称实际上是从这儿获得的。比如有一天我们想把某个角色改为管理员,那么就直接修改这儿就行了,不过这儿 需要的数据肯定也是角色管理中的一个角色名称。

StorageLocation:数据的存储位置,主要是给数据存储是XML格式时使用。在DataStore.cs文件中StorageLocation方法会涉及到。

BlogEngine.HardMinify: 对于JavaScript脚本指定强行压缩(去除一些不必要的字符)的文件名称。我们知道BlogEngine.Net中对于JavaScript请求都 是通过JavaScriptHandler进行的,JavaScriptHandler有一个HardMinify来判断是否已经指定强行压缩。 JavaScriptHandler中会涉及到这部分的引用。注意对WebResource.axd的请求在BlogBasePage中替换成对于 js.axd的请求,之后JavaScriptHandler的处理是使用RetrieveRemoteScript来输出脚本的。

     Ajax的运用

     BlogEngine.Net的很多部分使用原生的Ajax完成。例如 评论的打分,widget的管理等部分。我们在讲述BlogBasePage时提到的AddLocalizationKeys实际上就是初始化页面脚本的 一些变量,之后使用AddJavaScriptInclude(Utils.RelativeWebRoot + "blog.js")引入blog.js,如果是管理员(Widget可被管理)又使用 AddJavaScriptInclude(Utils.RelativeWebRoot + "admin/widget.js")引入widget.js,使用 AddStylesheetInclude(Utils.RelativeWebRoot + "admin/widget.css")引入widget样式,注意先后顺序,因为widget.js需要使用核心的blog.js。blog.js中这段代码就是Ajax调用的核心:

Ajax核心

 

     在线评论预览与评论的提交

     结合blog.js与User controls\CommentView.ascx,我们看一下它的处理过程。CommentView可以显示文章的评论列表和提交新评论。当点击 Preview时,会调用blog.js中的ToggleCommentMenu:

评论的预览与提交

     请注意isPreview的引入与它的逻辑,这个Preview实际上也是需要回调到服务器端的程序的,之后生成预览的Render,当 点击Save时isPreview为false,这时回调服务器端的代码时才真正的保存,然后浏览器回调客户端的AppendComment完成一些初始 化工作。CommentView是一个UserControl并实现了 ICallbackEventHandler接口,这个接口有两个方法GetCallbackResult和RaiseCallbackEvent,在 RaiseCallbackEvent中我们可以看出,提交的评论参数使用"-|-"作为分隔符,经过一系列处理最后将这个新评论的呈现给了 _Callback,_Callback由GetCallbackResult返回。浏览端使用 WebForm_DoCallback('ctl00$cphBody$CommentView1',argument, callback,'comment',null,false);在这部分里我们只要实现ICallbackEventHandler接口就行了,实现的 细节都已经有.Net提供了,感兴趣细节的朋友可以查一查ASP.NET的回调方面的资料。

     Widget排序的实现

     当我们用鼠标拖住一个Widget移动到某个位置再放开鼠标时,发现这个Widget在WidgetZone中的排序被永久存储了,甚至 在你清空cookie时依然生效,BlogEngine.Net是在服务器端进行的存储,DataStore的be_WIDGET_ZONE中的 Widget的顺序就是在页面上Widget的显示顺序。这实际上是通过间接调用WidgetEditor.aspx中的MoveWidgets方法实现 的(前文提及过)。那么在浏览器端是如何处理这些排序问题的呢?

     在widget.js中的大部分代码都是用来处理拖放排序的,initdragableElements主要完成使某个Widget可以 被拖动的初始化工作,widget.js的最后一句代码addLoadEvent(initdragableElements)使其在页面加载时执行。注 意initdragableElements中:

拖动事件的Hookup

当鼠标onmouseup时执行stop_dragDropElement,在stop_dragDropElement中通过调用 saveData,saveData使用上文提到的CreateCallback完成服务器端的回调,其中saveString就是已排序的字符串,主要 用于发送给服务器端程序处理。

     总结

     实际上在BlogEngine.Net的Web站点中还有很多比较有用的东西值得我们去研究,例如FilterByApml的实现,对文 章的评分,邮件的发送等,这里就不做更多的讨论。关于在线评论预览我个人觉得没有必要去回调服务器,完全可以由客户端搞定,不知道大家是怎么想的。那个 Widget的排序一直都深深的吸引着我,这种处理我见得很少,所以拿出来分享。

     在本系列的最后一篇文章中我会就BlogEngine.Net的优秀部分和不太推荐的部分做一个总结,并谈一下我对它的感受,希望大家继续关注。

     坚持写完,坚持看完。

     上一篇:BlogEngine.Net架构与源代码分析系列part13:实现分析(上)——HttpHandlers与HttpModules

 

     返回到目录

版权声明
作者:Thriving.country
出处:http://thriving-country.cnblogs.com/
本文版权归作者和博客园共同所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接.

[Flash]Flash加密和破解大法

mikel阅读(1015)

FLASH的破解与加密大法

转载:http://hi.baidu.com/lisa910502/blog/item/7719e306827fc97e03088166.html
一、破解篇

  这里所谈的破解,包括提取swf、破解已加密及未加密的swf,即通常所说的“swf to fla”。

  获取swf的工具:

   * Flash Saver 保存网页中的swf
   * Flash文件格式转换器(FlashChanger) 转换未加壳的exe为swf
   * Flash吸血鬼 不得已时用之。

2 flash资源的下载提取

提取范围很广,只要能看到Flash的窗口,包括加壳及未加壳的exe、网页等等。在使用 Flash吸血鬼提取swf的过程中建议不要进行其他操作,否则速度会变得极其缓慢,配置不好的机器有可能死机。这也是这款软件目前版本(v2.2)最大的一个不足之处。如果想中止程序,可以在任务管理器中结束。

  使用Temporary Internet Files(IE缓存)下载MV、SWF等资源

  偶尔会有网友问笔者关于网上 MV 如何下载,其实方法很简单,只要到 Temporary Internet Files 文件夹下就能找到想找的大部分网络资源。

  Temporary Internet Files IE 的临时文件夹。目录一般在C:\Documents and Settings\你的用户名\Local Settings\Temporary Internet Files

  使用 Temporary Internet Files 查找资源的技巧:先清空 Temporary Internet Files,然后用 IE 打开或刷新你要找的资源 (比如 MV) 所在的网页。再刷新 Temporary Internet Files 就能看到了,如果资源比较大,需要过一会,等下载完后再刷新才能看到。

  有时,部分资源会被隐藏。查看 Temporary Internet Files 的属性可以断定里面有文件,可是里面的内容却看不到。此时,用 WinRAR 压缩一下 Temporary Internet Files 就能看到了。为了不浪费时间,压缩的时候,压缩方式请选择“存储”。为了便于搜索查找,可以把压缩后的 Temporary Internet Files 解压到另一个目录下,里面的东西此时已经一目了然,分别分布在 Content.IE5 文件夹下的四个子文件夹中。

  可以将 Temporary Internet Files 移动到其他分区下,一方面可以给系统分区减负,另一方面也便于查找。移动方法如下:
Internet 选项 常规选项卡 在“Internet 临时文件”区点击“设置” 移动文件夹 选择一个分区,例如选择 D,就把 Temporary Internet Files 移到了 D 盘的根目录下。最后会提示重启,其实不是重启,是注销。记得保存当前的其他工作,按确定注销。

  从Word中提取Flash
  测试环境:WindowsXP / Office2003

3.从doc文档中提取flash、flash的破解工具

1. 需要一款16进制编辑工具WinHex
  2. 打开含有Flash的Word文档,点击“控件工具箱”的“设计模式”按钮进入设计模式,选择Word中的Flash,复制粘贴到任意文件夹,会看到一个“片段”文件。
  3. 打开WinHex,将该“片段”文件拉到WinHex中,单击下拉菜单“搜索”→“查找16进制值”,搜索“465753”,在搜索到的“465753”中的“4”位置上单击右键,选择“选块开始”。
  4. 继续“搜索”→“查找16进制值”,搜索“3A5C”,然后按住F3,直到出现“3A5C未找到”,点击“是”,在最后搜索到的“3A5C”中 “C”位置上单击右键,选择“选块结尾”。(注:少数情况可能会搜索不到“3A5C”,则改为搜索“3A”或“5C”,方法相同)。
  5. 在选块内任意处点击右键→编辑→复制选块→进入新文件→输入文件名 (如test.swf) →保存。

  常用破解工具

  谈到破解,很多朋友都会想到时下流行的闪客精灵。以下为常用的破解工具,按笔者使用的频繁程度,分别有:

  * 硕思闪客精灵(Sothink SWF Decompiler)
  * Action Script Viewer(ASV)
  * Imperator FLA(有使用者译为“罗马统治者”)
  (这是笔者最早认识的用来还原swf的工具,可惜一直在关注也没有发现2.0以上的破解版,只有1.6.9.8的破解版,这已经是3年前的版本了,只对Flash6.0以下有效。)
  * 硕思闪客之锤(Sothink SWF Quicker)

  以上四款,以Decompiler最为常用。ASV虽然强大,但在实用性方面却不如Decompiler,这应当也是为什么数年来 Decompiler能够长久风靡的原因。而ASV对付Flashincrypt加密过的swf却是轻而易举,这大大弥补了Decompiler的不足。不少网友知道用ASV来查看swf,但是不知道如何使用它来将swf还原成fla,以5.01版本为例,只需两步:

  1. 打开等待破解的swf文件(支持拖放打开),输出重建数据(File Export Rebuild Data (JSFL)…)到某一目录下,例如:桌面\新建文件夹。
  2. 双击目录下的“rebuildcommand.jsfl”,系统将启动Flash重建fla文件。根据原swf文件的复杂程度,重建fla所需的时间将有所区别。

4.flash的破解:修改后缀绕开下载工具

破解附言

  破解swf,依赖的主要是现成工具,多款工具综合使用,一款不行试另一款,如果作者有意加密,视破解者自身水平,在获取 swf时将遇到规模可大可小的困难,在破解时亦将不可避免的多花些许心思。如果遇到 SWF Encrypt 加密过的作品,只能对其中的AS无奈了。前几天听闻闪客互联的猎人兄对 SWF Encrypt 有破解之法,然而似有卖关之嫌,未见其实。

———————————————————————–

二、加密篇

  加密方法流传不少,此处只谈笔者所知的较为实用的方法:

  更改后缀,避开 Flash Saver 等下载工具

  此方法可有效避开 Flash Saver 等下载工具。使提取者不得不从缓存中查找文件,一定程度上增加了提取难度。后缀可改为 gif、jpg、txt 等等。虽然可以更改后缀,然而在插入到网页时,仍然需要以 swf 的形式插入,使用此 swf 来加载改过后缀的影片。

  限制 Flash 在指定域名/网址中播放 (Flash 防盗链)

  url = "http://www.zhugao.cn";

  /*
以下判断网址的前 20 个字符(字符数根据你的网址作相应修改),如果与"url"不一致则播放失败。注:swf 可以放在任意目录下,只要网址的前 20 个字符是正确的。
*/

  if(_url.substring(0, 20)<>url){
gotoAndStop(2);

  /*
这里可以做一些东西,例如:将发布设置中的“本地回放安全性”设为“只访问网络”,然后在这里做无数的弹窗
onEnterFrame = function(){
getURL("http://www.zhugao.cn", "_blank");
}
*/

5.flash常用加密工具

 }else{
gotoAndPlay(3); //跳到正常播放
}

  为了便于阅读,以下是没有注释的代码:

  url = "http://www.zhugao.cn";
if(_url.substring(0, 20)<>url){
gotoAndStop(2);
}else{
gotoAndPlay(3);
}

  如果要允许多个域名,可以这样写:
url = "http://www.zhugao.cn";
url2 = "http://zhugao.cn";
if((_url.substring(0, 20)==url) || (_url.substring(0, 16)==url2)){
gotoAndPlay(3);
}else{
gotoAndStop(2);
}

  注意:用此方法,设计过程中导出时的技巧:
用IE打开先打开指定目标网址,以避免在导出时频繁弹出窗口,如果无效,请将默认浏览器设置成IE,关闭导出时的player窗口即可继续编辑。有时Flash软件会因此发生错误而被强行结束,导出前请保存文档,切记!

  常用加密工具

  * SWF Encrypt
可有效防止目前流行的几乎所有破解工具对其所加密作品的AS查看。2006年10月更新为3.0.12,尽管加密后文件仍然有明显的增大(视原swf的复杂程度,增大幅度有所不同),然而令人振奋的是,已经支持放射状渐变,支持Flash8.0。加密技巧:分解 swf逐个加密,以尽量避免加密后单个文件体积庞大的问题。

  * Flashincrypt
  可轻易防止闪客精灵目前的版本对其所加密作品的AS查看,加密后的文件几乎保持原文件大小。遗憾的是不能防止 Action Script Viewer 5.0 以上的版本。

6.与JavaScript的结合

适当应用与JavaScript结合

  加密JS,从而实现间接加密swf。相关工具及例子:

  * T4nk JS混淆工具
  用于javascript的混淆加密。
  * Encrypt HTML
  加密网页脚本,包括 HTML source code, javascript, VBScript, text, links and graphics 等。
  * 从Flash到JavaScript的通讯,从JavaScript到Flash的通讯
  * 控制 Flash Player JavaScript 方法一览表:
·播放动画:Play()
  例:(网页中的 Flash id).Play();
·停止动画:StopPlay()
·动画是否正在播放:IsPlaying()
·跳转到某帧:GotoFrame(frame_number)
·获取动画总帧数:TotalFrames()
·回传当前动画所在帧数:CurrentFrame()
·使动画返回第一帧:Rewind()
·放大指定区域:SetZoomRect(left,top,right,buttom)
·改变动画大小:Zoom(percent)
·使动画在 x,y 方向上平移:Pan(x_position,y_position,unit)
·返回动画被载入的百分比:PercentLoaded()
·加载动画:LoadMovie(level_number,path)
  例:(网页中的 Flash id).LoadMovie(0, "***/***.swf");
·movie_clip 跳转到指定帧数:TGotoFrame(movie_clip,frame_number)
  例:(网页中的 Flash id).TGotoFrame("_root.实例名.次实例名",帧数);
·movie_clip 跳转到指定标签:TGotoLabel(movie_clip,label_name)
  例:(网页中的 Flash id).TGotoLabel("_root.实例名.次实例名","标签名");
·回传 movie_clip 当前帧:TCurrentFrame(movie_clip)
·回传 movie_clip 当前标签:TCurrentLabel(movie_clip)
·播放 movie_clip:TPlay(movie_clip)
·停止 movie_clip 的播放:TStopPlay(movie_clip)
·获取变量:GetVariable(variable_name)
·变量赋值:SetVariable(variable_name,value)
·call 指定帧上的 action:TCallFrame(movie_clip,frame_number)
·call 指定标签上的 action:TCallLabel(movie_clip,label)
·获取 movie_clip 的指定属性:TGetProperty(movie_clip,property)
·设置 movie_clip 的指定属性:TSetProperty(movie_clip,property,number)

7.在Word中插入flash;打包加壳成exe

在Word中插入Flash

测试环境:WindowsXP / Office2003

可用在独立文件给客户看的时候,尽管可以用前述方法从word中提取swf,然而此方法仍然具有一定防范效果。

1. 新建一Word文档并保存。
2. 在Word中依次单击下拉菜单“视图”→“工具栏”→“控件工具箱”。
3. 在“控件工具箱”中点击“其他控件”,选择列表中的“Shockwave Flash Object”。
4. 右键单击插入进来的Flash播放控件,选择“属性”。
5. 在“属性”窗口的“Movie”栏输入Flash动画的路径及文件名,需要用绝对路径,可采用以下两种:
file:///C:/test/test.swf
http://www.zhugao.cn/test.swf
6. 将“EmbedMovie”项设置为“True”,使Flash嵌入到Word中。“Height”和“Width”分别为Flash的高和宽。 “Scale”默认为ShowAll,为缩放模式,始终显示Flash中的所有内容,如果改为NoScale则始终按1:1比例,不会缩放Flash中的内容。
7. 单击控件工具箱上的“退出设计模式”按钮,在Word中即可播放Flash了。再次按下该按钮则暂停播放,进入设计模式。如当时未显示Flash,请保存退出Word,再打开该Word文档,点击“退出设计模式”按钮即可看到Flash。

打包成加壳exe

用Flash的默认程序打包的exe很容易转成swf,SWFKit是一款很不错的加壳打包软件,不易被还原。

  三、后记

破解时需要多种方法或工具综合使用,加密亦然,需根据用途综合加密。对于网络用swf的推荐加密方案:更改后缀,限制在指定域名播放,分解成多个swf并用SWF Encrypt加密。此方案主要依赖于SWF Encrypt,重在保护作品的AS,一旦SWF Encrypt遭到破解软件的有效攻击,此方案即宣告破产。 文/互联网


几款常用的FLASH
Imperator–最好的FLASH破解工具 1.0
最好的Flash破解工具之一,能将FLASH还原到99%,包括所有的元件,层,侦,As,我见过的最好的工具.

FLASH破解利器 Flash Decompiler v2.9.0.349

SWF Brower

SWF Scanner

硕思闪客精灵 (重点推荐)

Flash发展到现在已经进入MX时代了,Flash的破解软件也随着Flash版本的不断更新发展出了很多种类,我收集的Flash破解软件就不下二十种。

在没有用硕思闪客精灵之前,一般破解一个Flash要经过以下几个步骤:
一.如果是EXE文件,先要转化成SWF文件,这要用Exetoswf或者Swfextractor。
二. 如果要查看其中的Action Script代码,你又要用新的软件了,一般用Action Script Viewer。
硕思闪客精灵的使用相当简单,如果你用过SWF Brower和SWF Scanner的话一看界面就清楚了。打开一个你想破解的SWF文件,选择你需要的素材,然后点Export,选择相应的文件夹就可以了。然后你在这个文 件夹中寻找你需要的素材就可以了。
在这里我结合我使用的经验把硕思闪客精灵和当前名气最盛的SWF Brower、SWF Scanner进行比较,对硕思闪客精灵的优点和缺点做一点个人的分析。
我在Windows 2000平台下对三个软件使用做了一些比较,硕思闪客精灵版本为2001a,SWF Brower版本为2.93,SWF Scanner版本为2.0。
一.三者安装都很简单,在Win2000下能都稳定运行,截面类似,主要功能一目了然,操作性比较好。硕思闪客精灵、SWF Brower在98、me、2000和XP下都可以正常运行,SWF Scanner在XP下不能安装。
二.三者都可以只能打开SWF文件,对打包之后的EXE文件没办法打开。如果以后SWF Decompile能直接打开打包的EXE文件就方便多了。
三. SWF Brower只能打开输出时没有设保护的SWF文件,如果设了保护,就必须用Deflash处理之后才能打开,但硕思闪客精灵不需要使用Deflash处理就可以破解。
四. 三者均能打开Flash5.0及以前版本的SWF文件,对最新的Flash MX输出的6.0版本的flash文件都不能打开。
五. 硕思闪客精灵和SWF Brower都提供了Flash播放功能,但SWF Scanner没有。SWF Brower还能对SWF文件播放进行控制。SWF Dcompiler和SWF Scanner都能想资源管理器一样对电脑的文件夹进行管理,但SWF Scanner只能一次打开一个文件,不便于快速预览。
六.硕思闪客精灵能够对SWF文件里的9中对象进行提取,包括 shape,image,sound,font,text,sprite,buttom,frame。SWF Brower能提取sound events,sound streams,graphics,movies clips,swf internals。SWF Scanner能提取Actions,Sound,Images等。这里就硕思闪客精灵提取的种类最多,达到9种。
七.我们最关系的还是图片和声音的提取。对与位图,三者都能很好获得,但有时候SWF Brower不能提取得很完全,特别是对那些用Deflash处理过的SWF文件提取经常有问题。对于声音的提取,三者都是输出MP3格式的声音,但 SWF Brower提取的声音却经常因为不支持这种格式而不能直接导入Flash中。
八.硕思闪客精灵最大的特点就是能输出frame,就是能把打开的SWF文件分解成单帧的SWF文件。这有什么用处呢,当你要查看这帧里的图片时就可以直 接将生成的这帧SWF文件导入Flash就可以了,而不用将原来庞大的SWF文件整个导入。
九.硕思闪客精灵也提供矢量图输出,但输出的文件格式是gls,只能配合闪客巫师才能使用,而不能直接用Flash打开或导入,这也使我们不能方便的调用源SWF文件中的矢量图。
十. 在输出素材前SWF Brower能预览提取的位图,SWF Scanner能预览提取的声音和图片。硕思闪客精灵没有这些预览功能。
十一.硕思闪客精灵的输出操作可以一步到位,只要选取所有输出类型之后,点Export就可以了。但其他两个软件都要一个一个输入,显得要麻烦多了。
十二.硕思闪客精灵打开文件和输出文件的速度相当快,处理同样大小的SWF文件要比SWF Brower和SWF Scanner要快。
十三. SWF Brower能够做屏幕保护程序,SWF Scanner能够更改文件属性、查看Action Script(没有Action Script Viewer专业)。这些都是硕思闪客精灵所没有的功能。
十四.硕思闪客精灵是由中国人开发的,不仅有英文版而且有中文版,再也不用到处找汉化。

[搜索引擎]Apache Solr : 基于Lucene的可扩展集群搜索服务器

mikel阅读(704)

Apache Solr : 基于Lucene的可扩展集群搜索服务器

作者 Ryan Slobojan译者 崔康 发布于 2008年11月13日 上午7时27分

社区
Java
主题
搜索
标签
Lucene,
Apache Solr

Apache Solr项目,是一款基于Apache Lucene的开源企业搜索服务器,最近发布了1.3版。InfoQ采访了Solr的创建者Yonik Seeley,了解了新版本的更多信息和Solr提供给最终用户的功能。

Seeley首先描述了目标用户:“需要搜索框、分面浏览(导航)或者两者结合的任何人”,Solr的关键特性包括:

  • 基于标准的开放接口——Solr搜索服务器支持通过XML、JSON和HTTP查询和获取结果。
  • 易管理——Solr可以通过HTML页面管理,服务器统计数据以JMX输出,Solr配置通过XML完成。
  • 分面浏览——搜索结果自动分类。
  • 突出显示命中词——匹配的字符自动在搜索结果中高亮显示。
  • 可伸缩性——快速增量更新和快照分发/复制到其他服务器。
  • 灵活的插件体系——新功能能够以插件的形式方便的添加到Solr服务器上。

Seeley同时谈到了该版本中的主要新功能:

  • 分布式搜索——索引现在可以透明的分割成多个部分,单个Solr服务器基于各个配置和模式支持多索引,无须停止Solr服务器就可以改动主要的配置。
  • 扩展了查询功能——包含了一个新的Java客户端(SolrJ)和若干新功能,例如直接配置对于特定查询哪些文档首先命中、近似命中、搜索过期、记录分面时间和拼写检查
  • 增强了数据导入工具——数据库和其他结构化数据源现在都可以导入、映射和转化。
  • 更多可定制扩展点——存在一个新的更新处理器链,允许在查询时修改和重定向文档;一个搜索组件链修改和添加查询结果、用户查询分析器和插件式功能。
  • 性能增强——显著提高了索引速度,二进制响应格式和快速查询删除功能。

详细的更新日志可以这里获得。

Seeley谈到了更多Solr在伸缩性、功能和实用性方面的细节:

Solr已经部署过数以百万计容量的文档,如果借助分布式搜索,Solr应该能够处理数十亿的文档集合。
Solr基于Lucene,具有优秀的全文相关性,可以很方便的提供词组接近性增强、近期文档增强、编辑增强和基于数字值的专有函数的定制评分机制。
AOL正在使用Solr增强它的频道功能:音乐、橄榄球运动、食谱、参考中心、房地产和汽车都使用这项技术。Solr的搜索功能也应用于Netflix、 Zappos、Gamespot、和Internet Archive。还有很多大客户我目前还不能透漏。

关于Solr的未来计划,Seeley提到了更多的可扩展性、对大集群更方便的配置和管理、基于区域和实时的搜索、重构以使用Spring配置插件。Seeley同时提供了一个邮件列表,在那里他详细讨论了Solr未来、特别是2.0版的计划。

查看英文原文:Apache Solr: Extensible, Clustered Search Server Built on Lucene

[C#]BlogEngine.Net架构与源代码分析系列part13:实现分析(上)——HttpHa

mikel阅读(845)

     这已经是系列 的第13篇了,实际上到现在为止您应该对BlogEngine.Net的整体设计有了一定的把握,对部分实现细节有了比较深刻的认识,在阅读 BlogEngine.Net时希望坚持到最后,并把握住宏观,深入到微观。本文将详细介绍BlogEngine.Net中的HttpHandlers与 HttpModules,主要说明它们要实现的功能以及如何使用,并对几个必要的HttpHandler或HttpModule进行比较细致的分析。

     HttpHandler和HttpModule

     对于HttpHandler和HttpModule我这里不想多说了, 因为关于它们讲解的文章实在太多太多了,大家可以在博客园的找找看中直接输入“HttpHandler和HttpModule”就可以找到。我的理解就是 一个HttpHandler要实现IHttpHandler接口,主要是对某个请求进行直接处理,一个HttpModule要实现IHttpModule 接口,主要是在HttpApplication的生命周期的事件中对请求和响应进行过滤。它们都可以在Web.config文件中进行配置。

     BlogEngine.Net中的HttpHandler

     BlogEngine.Net中的HttpHandler都在BlogEngine.Core.Web.HttpHandlers空间下(除了MetaWeblogHandler,已经讲过,这里就不包含它了),通过Web.config我们可以看到它们的映射关系:

HttpHandlers映射表

下面对它们进行一一描述:

FileHandler:主要完成对于一些物理文件的请求,例如在文章中插入的文件资源的请求就由它来处理。它的实现比较简单,就直接去磁盘的文件保存目录中读取,我们只要留意一下SetContentType就行了。

ImageHandler:与FileHandler类似,不过它处理的是图片。与FileHandler分开的原因主要就是图片需要在页面上展现(ContentType必须给浏览器讲清楚或采用默认)。

SyndicationHandler:它比较复杂,主要完成各种订阅需求的处理,需要结合 SyndicationFormat(格式枚举)和SyndicationGenerator(按照SyndicationFormat的格式生成 XML)一起使用。我们可以看一下它的实现过程,首先根据请求的查询字符串生成标题,格式,列表(GenerateItemList使用了Search 等),使用CleanList进行了一个过滤,分页处理,SetHeader,最后使用SyndicationGenerator的WriteFeed进 行了输出。这里考虑的情况比较多,但是BlogEngine.Net使用的分割方法很好的解决了复杂的订阅问题,值得研究一下。

SiteMap:网站地图,可以给一些搜索引擎提供更好的搜索信息,以XML格式将一些文章等页面的链接输出。

TrackbackHandler:接收Trackback信息的处理,前文已经讲过,这里不多说了。

PingbackHandler:接收Pingback信息的处理,前文已经讲过,这里也不多说了。

OpenSearchHandler:提供公开搜索处理,前文已经讲过,这里也不多说了。

RsdHandler:这个处理器很有用,它完成将BlogEngine.Net中的一些公开的接口等信息发布出去,类似WebService的WSDL文件。

CssHandler:主要处理了页面中的Css文件的压缩,上文中讲述BlogBasePage中提及过。处理器的实现很值得关注,压缩可以使用gzip或deflate两种格式,

经典的压缩处理

并提供了一些事件供外界Hookup处理。压缩之前去掉空格等字符,分为从本地获得文件和从远程使用WebClient下载文件。并使用了缓存。

JavaScriptHandler:主要处理页面中引用的脚本的压缩,与Css处理方式类似。注意StripWhitespace的处理与Css的不同。

RatingHandler:主要完成给Post打分的功能,记得上文中有部分涉及到,从PostViewBase中的Rating可以看出,这个请求实际上是通过Ajax发送过来的。

OpmlHandler:获得OPML列表文件,类似收藏文章的列表。

BlogMLExportHandler:BlogEngine.Net中的文章导出处理,以前的文章讲过。

Sioc、Foaf、Apml的注释都是“Based on John Dyer's (http://johndyer.name/) extension.”,这个应该是对于某个标准XML的输出吧,主要提供了本博客系统中的一些公开的信息。关于它们不做太多的研究,我想这并不影响我们 对BlogEngine.Net的研究。

     实际上这些HttpHandlers的请求链接很多都是在BlogBasePage加入到Html的Head中的,或者给浏览器使用,或者给搜索引擎使用。

     BlogEngine.Net中的HttpModule

     BlogEngine.Net中的HttpModule都在BlogEngine.Core.Web.HttpModules空间下,通过Web.config我们可以看到它们的映射关系:

httpModules映射表

请注意它们的注册顺序,因为WwwSubDomainModule和UrlRewrite都Hookup了HttpApplication的BeginRequest事件。下面对它们进行一一描述:

WwwSubDomainModule:Hookup了HttpApplication的BeginRequest事件,主要是对请求的URL中的"www"的处理以得到绝对的链接。

UrlRewrite:Hookup了HttpApplication的BeginRequest事 件,对一些URL的重写,实际上WwwSubDomainModule和UrlRewrite都是在处理URL,我们在看BlogEngine.Net中 的源代码时多留意一下它的URL,包括Post中的各种链接的URL等,注意区分它们都是做什么用的。

ReferrerModule:主要是对于请求的Referrer进行统计,纪录这些请求都是从哪里发送来的,提供了相应的事件供外部Hookup,注意IsSpam的实现和对于纪录日志使用了新线程来异步完成。

CompressionModule:一个Page页面的压缩处理模块,同样根据请求来判断是使用 gzip还是deflate,对于页面中链接的WebResource也是用WebResourceFilter进行了过滤处 理,WebResourceFilter实现了Stream,

WebResourceFilter的Write方法

在重写的Write中主要是将webresource.axd转交给了JavaScriptHandler处理以达到压缩的目的。注意它是在PreRequestHandlerExecute中Hookup的,都是给Response提供的流过滤器。

     总结

     由于篇幅所限,对于BlogEngine.Net中一些 HttpHandlers和HttpModules我并没有作更多的深入讨论,这里只是提供给大家一个学习指南,希望有所帮助。 BlogEngine.Net中大量使用了正则匹配,Url处理,压缩,缓存等都是比较通用的,值得我们关注与学习。

     通用的处理方法值得我们去收藏

     上一篇:BlogEngine.Net架构与源代码分析系列part12:页面共同的基类——BlogBasePage

     

     返回到目录

版权声明
作者:Thriving.country
出处:http://thriving-country.cnblogs.com/
本文版权归作者和博客园共同所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接.

[C#]BlogEngine.Net架构与源代码分析系列part12:页面共同的基类——BlogBa

mikel阅读(876)

     上一篇文章我 向大家展示了BlogEngine.Net中Theme的原理和一些开发规范,里面有很多内容和这篇文章有着联系,建议大家这两篇文章结合在一起看,这样 效果会更好。在这篇文章中我主要向大家说明BlogBasePage,PostViewBase,CommentViewBase这三个类的内部实现上的 一些技巧以及它们与页面,文章和评论之间是如何组织在一起的,希望对大家阅读这部分代码有帮助。

     认识一下它们

     BlogBasePage,PostViewBase,CommentViewBase它们都是一些元素的基类,首先把这些元素定义成基类,然后使用继承的方式实现我认为主要有以下好处:

1.代码复用会得到提升,对于一些大量的同样操作都可以放在基类中,子类直接可以继承使用。

2.职责清晰,例如在Theme中的CommentView.ascx直接继承CommentViewBase就行了,CommentView.ascx只是来处理将Comment如何展现的问题。

3.规范化,这是继承带来的一个很重要的好处,因为子类就是一个父类,只要它是就可以使用

BlogBasePage:Web站点的根目录下的每一个页面都是从它继承而来,BlogBasePage继承自Page。而页面不是直接从Page继承而来。
PostViewBase:是一个Post显示功能部分的基类,themes中每个主题的PostView.ascx都是直接从它继承而来,PostViewBase继承自UserControl。
CommentViewBase:是一个Comment显示功能部分的基类,themes中每个主题的CommentView.ascx都是直接从它继承而来,CommentViewBase继承自UserControl。

     实现分析

     BlogBasePage到底都做了些什么?

OnPreInit中主要完成根据BlogSetting中的Theme找到相应的页面的Master文件(包括主题选择时的预览判断),此外还处理了Post的删除。
OnLoad中做得事情很多,主要是在head中加入一些资源引用(包括SIOC,APML,FOAF等),实际上就是当我们打开页面查看源代码看到 head中多如牛毛的link。还有增加一些脚本的全局变量,增加BlogSetting中的自定义Head的html,增加track脚本,增加脚本引 用(通过JavaScriptHandler来实现),增加样式(注意css的压缩是通过CssHandler实现的)。
OnPreRenderComplete中完成了标题的设置。
OnError中还对使用Comment的恶意攻击做了处理。

protected override void OnError(EventArgs e)
{
    HttpContext ctx 
= HttpContext.Current;
    Exception exception 
= ctx.Server.GetLastError();
    
if (exception != null && exception.Message.Contains("callback"))
    {
        
// This is a robot spam attack so we send it a 404 status to make it go away.
        ctx.Response.StatusCode = 404;
        ctx.Server.ClearError();
        Comment.OnSpamAttack();
    }
    
base.OnError(e);
}

 

     PostViewBase到底都做了些什么?

PostViewBase是一个用户控件,主要是显示一个Post,内部除了一些Post属性 外,还有CommentFeed(通过SyndicationHandler处理),增加分类链接,增加Tag链接,增加管理链接,增加评分的脚本来给文 章评分等。此外在Page_Load还对加入内容中的一个自定义的控件标签进行了特殊的处理,这种格式如:[UserControl:~/path /usercontrol.ascx],使用一个正则来判断,如果内容中有这种标签,那么内容显示时使用加载的控件来代替。

     CommentViewBase到底都做了些什么?

CommentViewBase是一个用户控件,主要是显示一个Comment,内部除了Comment和Post属性外,还有内容,管理链接,国旗显示,Gravatar显示等。请大家留意一下后面的两个图片的显示处理。

     了解了这些,上一篇文章中讲述的Theme中的几个必要文件的数据显示问题就清晰多了吧。

     页面的继承与组织关系

     这部分没有什么原理性的东西,只是帮助大家快速阅读代码而做的一个文件的介绍。

login.aspx:继承BlogBasePage,完成登录,注销,修改密码等与登录有关的用户接口。
default.aspx:继承BlogBasePage,内部使用PostList.ascx用户控件完成文章的列表显示接口。
search.aspx:继承BlogBasePage,用一个repeater显示搜索结果,这个以前提及过。
archive.aspx:继承BlogBasePage,对文章的归档显示,注意它的归档的处理过程。
contact.aspx:继承BlogBasePage,主要是完成阅读者给文章的发布者发送邮件。注意它还实现了ICallbackEventHandler,来完成ajax回调提交。
error404.aspx:继承BlogBasePage,404错误转向。
page.aspx:继承BlogBasePage,完成删除Page,显示Page(注意对注入控件显示的处理和与Post区别)。
post.aspx:继承BlogBasePage,完成文章的显示,使用User controls/CommentView.ascx来完成评论列表的显示和评论的提交。Page_Init中动态加载PostViewBase,处理了 “上一篇”和“下一篇”等导航链接(需要Post类本身的支持),phRDF完成了Trackback的接收(以前文章提及过)。
对于Theme中的文件上文已经讲过,这里就不再多说。
对于admin/Pages中的这些管理页面都是直接继承自Page,Master为admin1.master,在Web.config中定义了访问权限等,这主要是实现了前端页面和后台管理的分开处理。
blog.js是BlogEngine.Net的所有脚本文件,里面封装Ajax处理(例如回调,评论的在线浏览等)。

     总结

     像BlogEngine.Net这种将几乎所有页面的Page再进行一下自定义的封 装的处理方式在很多项目中都会得到应用,这一点我觉得很好。对于注入控件的处理方式也值得我们去学习。这种注入控件我想主要是完成一些外部资源的引入问题 的,把文章或Page的显示交给这个用户控件来处理会很灵活。

     麻雀虽小,五脏俱全

     上一篇:BlogEngine.Net架构与源代码分析系列part11:开发扩展(下)——自定义Theme

 

     返回到目录

版权声明
作者:Thriving.country
出处:http://thriving-country.cnblogs.com/
本文版权归作者和博客园共同所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接.

[C#]BlogEngine.Net架构与源代码分析系列part11:开发扩展(下)——自定义The

mikel阅读(865)

     个性化的主题是一个完善的 Blog系统中所必备的,同时也是一个亮点。在这篇文章里我将给大家展示一下BlogEngine.Net的第三个开发特性,那就是自定义的Theme。 本文的重点放在BlogEngine.Net的开发规范和实现原理上。如果您对BlogEngine.Net的架构很了解的话,那么开发一个自己的 Theme是一件很简单的事情,如果您不是很了解,那么你也可以按照本文讲述的规范开发出一个自定义的Theme来。

     BlogEngine.Net中的Theme

     在BlogEngine.Net的源代码中默认存储了三个Theme(Standard默认,Mobile移动版,Indigo),更多的Theme您可以到它的官方站点下载。 同样这些Theme支持热插拔,我们只要把下载的Theme放在themes目录下就可以实现它的安装。相信这种Theme会给用户带来更多的使用上的感 受。由于BlogEngine.Net开放源代码,所以对于Theme的开发也完全由用户自己控制。如果大家想知道这个Theme到底有多厉害,看看 BlogEngine.Net的官方站点就知道了,估计那就是使用BlogEngine.Net,然后换了一个Theme做的。

     规范与原理

     对于用户来说到底使用哪个Theme是存储在BlogSetting中的,在设置页 面中我们可以看到一个下拉列表来选择主题,这个下拉列表的数据是通过读取themes目录下的子文件夹名称获得的,这就要求我们在开发Theme时要以 Theme的名称作为这个文件夹的名称。需要注意的一个问题就是在BlogEngine.Net的Web站点的根目录下的所有.aspx的 Codebehind都是继承自BlogBasePage,这个类又继承自Page类,也就是说BlogBasePage将一些页面中共有的操作进行了统 一的处理,对于这个类我会在接下来的一篇文章中进行分析。

     在BlogBasePage中有这么一段代码:

private string _Theme = BlogSettings.Instance.Theme;
/// <summary>
/// Assignes the selected theme to the pages.
/// </summary>
protected override void OnPreInit(EventArgs e)
{            
    
if (Request.QueryString["theme"!= null)
        _Theme 
= Request.QueryString["theme"];
    MasterPageFile 
= Utils.RelativeWebRoot + "themes/" + _Theme + "/site.master";
    
base.OnPreInit(e);
    
//….

}

 

这段代码就是在页面预初始化时(注意一定要放在这个处理器中)将Page的 MasterPageFiles设置为BlogSetting中所设置主题名称的目录中的site.master,这就要求我们在开发自己的Theme时 需要创建页面的主文件site.master。

     此外就是在研究了PostViewBase和CommentViewBase(这两个类也会在下一篇文章中做详细的说明)的实现以后对于Post和Comment的显示也是到BlogSetting中所设置主题名称的目录中去查找PostView.ascx(直接继承自PostViewBase)和CommentView.ascx(直接继承自CommentViewBase),这就需要我们在开发自己的Theme中需要创建文章的显示界面PostView.ascx和评论的显示界面CommentView.ascx。

     以上几个文件是开发BlogEngine.Net的Theme所必须的,实际上也就形成了一个完整的前台页面了。当然你也可以定义自己的布局,css,图片等。这些文件到底应该如何定义,以Standard为例,先让我们看一下它的实现。

     site.master中依次是资源的引入,header部分,顶部的一些链接,主题部分,版权部分,WidgetZone。请注意:

<blog:SearchOnSearch runat="server" MaxResults="3" Headline="You searched for" Text="Here are some results for the search term on this website" />
<asp:ContentPlaceHolder ID="cphBody" runat="server" />

SearchOnSearch是一个控件,主要完成根据搜索引擎的参数在本站中进行再次搜索。<asp:ContentPlaceHolder ID="cphBody" runat="server" />在site.master中必须存在的,因为Page中已经存在对它的引用。

     PostView.ascx中依次是标题,作者,创建时间,主体,标签,分类,一些链接和管理菜单。其中<asp:PlaceHolder ID="BodyContent" runat="server" />同样也是必须存在的,因为在PostViewBase中就是将Post的内容输出到BodyContent控件中(请参照PostViewBase的Page_Load方法)。

     CommentView.ascx中依次是评论的作者,时间,Gravatar图片显示,内容,管理连接等。这里似乎没有什么是必须的。

     只要遵守这些规范我们就可以开发Theme了,除此之外对于Widget的引入我们也不必使用WidgetZone,只要将这些Widget的控件类直接放在site.master中就行了,其实这已经不能算作一个Widget,只能说是一种类似Widget的控件。对于BlogBasePage,PostViewBase,CommentViewBase以及各个页面之间的继承关系,我会在下一篇文章中做详细的介绍,希望大家继续关注。

     总结

     这篇文章涉及到的内容比较少,并且和下一篇文章有很多联系。实际上,Theme的实现应该是基于BlogBasePage,PostViewBase,CommentViewBase等的,它主要应用了ASP.NETsite.master布局页面,通过动态设置实现。这样操作损失了一个IDE的重要特性——智能感知,开发起来可能会有些不便,但是这样的架构还是不错的。

     看来ASP.NET的site.master的确很有用

     上一篇:BlogEngine.Net架构与源代码分析系列part10:开发扩展(中)——Widget小工具

 

     返回到目录

版权声明
作者:Thriving.country
出处:http://thriving-country.cnblogs.com/
本文版权归作者和博客园共同所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接.