3月份DsJian 2.1beta会正式和大家见面

二 07

Ben产品设计, 技术相关 , , , 5 Comments

经过了很长一段时间，DsJian2.1终于接近尾声了（特别说明，中途重构了一次，因此版本 +0.1 ）。

这个版本是全新开发的版本，除了基本架构保留1.0的之外，其他几乎所有东西都重构了。期间认真学习并参考了WordPress的设计理念，受其影响，以至于后台管理布局也有很多雷同之处。并吸取到一条教训：以后若要做产品，记住，先自己想，不要一开始就去看一些优秀的产品，否则你的设计思路会不知不觉的跟着这些优秀的产品走，且一发不可收拾， :(

更多信息，可以点这里看看

简单列一下features:

  • 基本博客功能（文章、页面、链接、评论等）
  • trackback 发送
  • 内置邮件发送
  • 自定义文章伪静态地址
  • 附带数据缓存，提高访问速度
  • SEO相关（sitemap、rebots等）
  • 文章、评论 Rss 等
  • 支持完全自定义主题
  • 多作者撰写支持
  • 数据导入与导出
  • 便捷安装
  • IIS6与IIS7经典模式支持
  • Gravatar 身份认证
  • 多种数据库支持（Sqllite, MySql, MSSql, Access等）
  • …

show 一些截图：

管理后台

分类管理

分类管理

前台 inove

前台仍然保留 iNove 这套主题，后面可以自己做一套默认主题

VN:F [1.8.3_1051]
Rating: 1.5/5 (2 votes cast)

利用MVC UserControl实现博客自定义主题

十二 12

Ben产品设计, 技术相关 , , , , No Comments

前面谈到完成DsJian2.0的前端开发，其中有一点，使用ASP.NET MVC View UserControl来做博客模板，对于这一点，我自己也感觉有些别扭，今天在这里单独谈一下，这到底是怎么个情况。

背景

根据我对ASP.NET MVC的了解，项目中所有的ViewPage都必须放在Views文件夹内，Views文件夹内的每一个子文件夹对应一个Controller。不得不说这样的设计有一定的局限性，因此ASP.NET MVC 2.0才有Area这样的概念融入其中。

谈到局限性，具体表现在当我需要创建主题文件夹的时候，应该怎么弄呢？我想要的效果是这样的：Views > themes > default > All View Pages，在themes这个目录下，允许有若干个子文件夹，每个子文件夹就是一个主题包。主题包里面包含系统所需的所有View Pages，当然，共用的页面及用户控件除外。

也许由于对ASP.NET MVC的了解不够深入，存在有别的解决办法，只是我没找到而已。

解决思路

于是我就在想应该如何实现“自定义主题”，了解到View User Control（下称UC）可以放在任何目录里，只要在Render时指定好路径即可。因此我开始尝试用UC来做主题文件。

由于采用UC做模板文件，因此我的View文件就只有这样一句话：

<% Html.RenderPartial(this.CreateEngine().GetThemeVirtualPathWithPartial(“ListByCategory.ascx”)); %>

CreateEngine 是我在 ViewPage 上增加的扩展方法，即返回所谓的博客引擎（Engine），通过这个博客引擎可以完成所有博客业务数据的提取，甚至包括生成部分简单的HTML代码。

通过这样一段代码“this.CreateEngine().GetThemeVirtualPathWithPartial(“ListByCategory.ascx”)”，我可以得到当前系统指定的主题文件夹下的ListByCategory.ascx这个主题文件。

这样的话，我所有的View文件不包含任何实质性的HTML标记，所有的HTML标记应该由主题制作人员完成。我只需要在引擎上提供足够用的数据接口供制作主题时调用。

于是，我的目录结构变成如下这种形式：

Views > View Folder > View Pages

Themes > Theme Folder > All Theme Files（CSS、脚本、图片、图标、主题文件：UCs）

如果，某某人有兴趣自己开发一套模板，他只需要遵循我的规范，做一个主题包，然后放在网站的 Themes 文件夹下，就可以在后台配置使用这个新主题。类似于wordpress，我想用过wp的朋友都理解。

存在的问题

本文开始我就说了，这样的设计还是感觉有些别扭。ASP.NET一些比较好的特性好像就不能使用了，比如Master Page。我自己在尝试开发主题包时就想使用Master Page，因为这样会方便许多，但是用不了（UC 无法使用 Master Page）。

大量使用UC会不会有其他问题，比如执行效率上，目前还不得而知。所以，如果有其他更好的形式，我想我会考虑考虑，只是到目前为止还没有想到更好的办法。

VN:F [1.8.3_1051]
Rating: 2.5/5 (2 votes cast)

完成DsJian2.0前端开发

十二 10

Ben产品设计, 技术相关 , 3 Comments

完成博客程序前端的开发工作，今天在这里留个笔。到目前为止，已完成如下功能：

  • 博客安装（包括数据库、系统初始化等）
  • Smtp邮件发送与配置
  • 基本博客功能（文章、页面、评论、链接、分类、存档、Tag等）
  • 自定义主题功能
  • 数据引擎API搭建（前端模板数据获取与交互）
  • 自定义文章URL
  • 多数据库架构支持
  • Rebots、Sitemap生成
  • Rss、Atom（文章、评论等）
  • Trackback接受与发送
  • Scheduled Tasks（类似于Background Services，为以后的插件功能做准备）
  • Gravatar 头像应用

其他不想多说，感觉最近自己忙麻木了，因此写不出什么东西出来。对于以上Features中的一点：自定义主题，我现在还对我的设计持怀疑态度，感觉使用Mvc UserControl来做模板页面有些别扭，但到现在为止还没想好替代方案。希望能得到网络上的朋友们的帮助。

贴一下博客项目结构：

dsjian.com:2.0架构

VN:F [1.8.3_1051]
Rating: 5.0/5 (1 vote cast)

有必要说明一下DsJian博客引擎

十二 06

Ben技术相关 , , No Comments

好久没上来添加新内容，一方面工作上的事情比较忙，另一方面工作之余也开始了2.0版本博客程序的开发，今天抽时间上来对2.0版本博客程序写一些说明。

上一篇文章这样写出来实在不好意思，就那么几句话，第一次看到这篇文章的朋友肯定会云里雾里，看不懂。所以今天在这里首先谈谈我所说的“博客引擎”是什么意思：

相信了解ASP.NET MVC的朋友都知道，她给了我们一个很好的模式，将View与Model分开，这样有一个好处，在你的团队中，可以根据员工的技术特长再次细分出不同的职能团队，比如细分为“数据库小组”、“业务逻辑小组”、“前端开发小组”等。

上一个版本（我说的DsJian1.0）中，我采用面向接口的开发模式，可以在约束好接口后，各个职能团队根据接口规范自己做自己的事情，最后再将整个系统整合起来，这样可以进一步的提高开发效率，易于测试……打住，这个话题说下去可没完没了。

回到正题，我之所以继续做这套博客程序，其实是为了解决一个问题：想给自己建博客网站的人不一定都是懂技术的人。如果你的程序太过技术化，可能会影响一般用户的使用。

于是自己就在琢磨，既然Mvc能很好的将展现与业务分开，那么是不是应该发挥一下这个特点，我来充当业务模型开发人员这个角色，让博客使用者来充当前端开发人员的角色？也就是说，我发布的博客程序可以没有任何View，所有的View都由博客使用者来创建，当然前提是我要提供非常易于使用的数据接口（这才是重中之重）。

我提供所有数据存储、业务接口、安装、后台等，因此实际上我所说的“博客引擎”就是一个套博客平台。使用者不用关心平台内部是如何实现的，只需根据自己的需要创建主题就行了。

当然，要完成这样的平台是需要花很多心思的，会遇到很多问题，也不简单，但我想我还可以坚持。简单理了一下DsJian2.0 Features，关于博客的开发状态，可以在这里查看：

VN:F [1.8.3_1051]
Rating: 0.0/5 (0 votes cast)