CMS system template engine design (1): Basic Type

I like writing tutorials in blog posts. There are few people who are interested in specific project design schemes, and their ideas are not necessarily clear. It is hard to write blogs, the author is also a little lazy, which is basically a waste of text. Even so, I still want to write about the module design of a project I have done-the template engine of CMS. Haha, It's just eye-catching to call it an "engine. It is actually a tag interpretation process module. My friends who have done website work are familiar with CMS, and some of my friends have also been familiar with N-plus CMS systems. Among the popular ones in China are dedecms, phpcms, Empire CMS, kingcms, powereasycms, etc, they all share a common feature, that is, the front-end implementation is the template tag mechanism. The advantage of tags is that non-professional developers can call data through specific tags. A tag indicates a data call. My CMS is also doing this, but it is implemented with. net. The idea of implementation is also figured out by myself. If there are similarities, it's a coincidence: Where can I start from? Start with the business! When the company receives a website list, it must estimate the price. To estimate the price, you should generally ask the development manager about the development cycle and difficulty of the website (which makes it easy to fool the price). The Development Manager is our technical leader and he will estimate the approximate number of pages required for the website, how long does it take for a sub-module to work (if there is no CMS ). Well, here is an important piece of information, that is, how many pages and modules are needed. To create a website, we must consider its functional modules and the number of pages. Function modules generally include articles, images (photo albums), videos, voting, messages, comments, downloads, single pages, and Custom forms. We will introduce the template, so we will not mention these functional modules. The concept of a page is how much page. aspx needs to be created. Generally, there are homepage (sub-site homepage), cover page (which can be understood as the topic cover), list page, details page, and independent page (about us and so on ), different data types are not necessarily the same, for example, news and downloads are different pages. Templates cannot be created by the Creator to create Aspx. They only use templates. So through this information, we can think of the classes to be designed? Page, template, label, page, template, and label. Label involves the specific label series. Let's not talk about it for the moment. First, let's look at how to design the template? What is the design of a template? Some CMS systems directly read static files, but I say this is not good. We need to have specific types in the Code to facilitate the processing.

/// <Summary> /// template class /// </Summary> public class template {// <summary> /// template ID /// </Summary> public guid templateid {Get; set ;}//< summary> /// Template Name /// </Summary> Public string name {Get; Set ;} /// <summary> /// template content /// </Summary> Public String content {Get; set ;} /// <summary> /// whether the view is partial /// </Summary> Public bool ispartial {Get; Set ;}}

The preliminary design adds an ispartial attribute, because our template may be called as part of the view in Other templates, just like usercontrol.

The design of the page class is a little complicated. We want to access a page at least with an access path, so we need to have a urlpattern attribute, that is, an access rule. Because a detailed page is usually a parameter change, the URL cannot be written to death, only one rule is allowed. Since there are rules, there will also be some parameters, and the parameters are not necessarily? Name = value form, which may be in the/value/value1 form, so we have to design a urlpattern class.

/// <Summary> /// URL access rules /// </Summary> public class urlpattern {// <summary> /// specific rules /// </Summary> Public String Pattern {Get; set ;}//< summary> /// Regular Expression Engine //</Summary> Public RegEx {Get; set ;} /// <summary> /// parameter list /// </Summary> Public String [] parameters {Get; set ;} /// <summary> /// obtain the value of a parameter /// </Summary> /// <Param name = "rawurl"> current URL </param> /// <Param name = "name"> parameter name </param> /// <returns> </returns> Public String getvalue (string rawurl, string name) {Throw new system. notimplementedexception ();}}

Yes, you are not mistaken. We should use regular expressions, which may be the most difficult part for the production staff. :) But they can teach them how to write at the beginning to meet the vast majority of requirements.

For example, if I write a rule as follows/details /(? <ArticleID> \ D +), which indicates that the parameter is named ArticleID and the access rule is "/details/number"

Besides accessing URLs, pages also have the concept of caching. Otherwise, how can we improve performance ?! The cache may also use labels. If the page is not cached but only a label is cached, the label must also be cached. Do we need to design a cache class?

/// <Summary> // page/template/label cache // </Summary> public class cache {// <summary> // /</Summary> Public String key {Get; set ;}//< summary> /// cache seconds /// </Summary> Public int cacheseconds {Get; set ;} /// <summary> /// obtain the cached data /// </Summary> /// <returns> </returns> Public object getdata () {Throw new system. notimplementedexception ();} // <summary> // remove cache /// </Summary> Public void remove () {Throw new system. notimplementedexception ();} /// <summary> /// update the cache /// </Summary> /// <Param name = "data"> </param> Public void setdata (Object Data) {Throw new system. notimplementedexception ();}}

So what else should the page class have? Labels! Yes, it is impossible to interpret the template every time to obtain all the labels. Instead, after the page is cached, we only need to access its labelcollection. Let's take a look at the prototype of page design.

/// <Summary> /// page class /// </Summary> public class page {// <summary> /// ID /// </Summary> Public guid pageid {Get; set ;}//< summary> /// name /// </Summary> Public string name {Get; Set ;} /// <summary> /// title /// </Summary> Public String title {Get; set ;} /// <summary> /// keyword /// </Summary> Public String keywords {Get; set ;} /// <summary> /// description /// </Summary> Public String description {Get; set ;} /// <summary> /// template /// </Summary> Public template {Get; set ;} /// <summary> /// access path rule /// </Summary> Public urlpattern {Get; set ;} /// <summary> /// tag /// </Summary> Public Label [] labels {Get; set ;} /// <summary> /// cache /// </Summary> Public cache {Get; set ;} /// <summary> /// display HTML code /// </Summary> Public void render () {Throw new system. notimplementedexception ();}}

Good, good.

In fact, the concept of sub-stations is indispensable for large websites. Or our CMS needs to support multiple sites, so we also need a site class.

 

/// <Summary> /// site /// </Summary> public class site {// <summary> /// site ID /// </Summary> Public guid siteid {Get; set ;}//< summary> /// site name /// </Summary> Public string name {Get; set ;} /// <summary> /// site remarks /// </Summary> Public String note {Get; set ;} /// <summary> /// site domain name /// </Summary> Public String [] domains {Get; set ;} /// <summary> /// Site status /// </Summary> public status {Get; set ;} /// <summary> /// page of the site /// </Summary> Public page [] pages {Get; Set ;}}

Websites generally contain multiple accessible domain names, so there is a domains. Of course, the site contains N pages.

Well, the preliminary design is here. Next we will explain how to make these classes work.