Understanding the placement.info file in Orchard

ArticleDirectory

• Placement.info File
• Scope)
• Placement Node
• Place Node
• Match Node
• Rewrite location file
• References

(This Article applies to Orchard V1.1)

 

In CMS systems such as orchard, the content can be composed of any number of parts. For example, a blog post consists of: routable part, body part, tags part, and comment part) and other common components (common and publishlater. To get a template to present such objects, you can clearly access each part of the content and present them. This is an implementation method, but it cannot handle some unpredictable modifications that often occur in CMS. If the Administrator downloads a scoring module and adds the rating part to the blog post. If the display page clearly defines the entire blog article, you need to modify the template to clearly display the newly added parts.

The explicit presentation of a content refersCodeDirectly use the following code.

For example, to display a blog, you can use: @ Display (model. routabletitle) @ Display (model. Body) @ Display (model. tags) @ Display (model. Comments) If you want to add a scoring component, You need to modify the template: @ Display (model. routabletitle) @ Display (model. Body) @ Display (model. tags) @ Display (model. rating) @ Display (model. Comments) In this way, the corresponding template needs to be modified for each added function. It is inconvenient to do so.

In orchard, we do not need to modify it like this. To add a new part, we can display it correctly without modifying any code. This feature can be implemented due to the separation of "rendering" (executed by the template or shape method) and "placement" (implemented by the placement.info file) in Orchard. In this way, the widget not only specifies its default rendering mode, but also can be rewritten in the topic. In addition, you can add a new placement.info file to the topic to overwrite the display location and region of the widget.

To understand the separation of "rendering" and "placement", we should first talk about the content organization in Orchard. All the data in orchard is content, which is composed of different content parts. A type consists of those components and can be customized in the background. The so-called "rendering" and "placement" separation mean that each component has its own Rendering Method and corresponding rendering template. Each part only takes into account its own rendering, so you do not have to worry about other parts. When a content is displayed, the corresponding parts are displayed in different regions in sequence and then merged into a complete content display through the definition in the placement file of each part.

Before proceeding to the placement.info file, you must first introduce content. cshtml (content item template ). First, the content items in Orchard must be displayed using this template. This template is called regardless of the content. Of course, this template can also be rewritten in the topic. Here we take the default content item template as an example: (File Location :~ \ Core \ contents \ views \ content. cshtml)

<Article class = "content-item @ contenttypeclassname"> <Header> @ Display (model. header) @ If (model. Meta! = NULL) { <Div class = "metadata"> @ Display (model. Meta) </Div> } </Header> @ Display (model. Content) @ If (model. footer! = NULL) { <Footer> @ Display (model. footer) </Footer> } </Article> This template defines four areas: Header, Meta, content, and footer. How to present each part in a content in this template, for example, the parts must be presented in the header and those parts must be presented in the content, what is the order of positions displayed in the content. These all need to be processed by a placement file, which is placement.info. The placement.info file describes the role of the placement.info file and its necessity. If you look at the files in orchard, you will find that most modules and themes have a placement.info file under their root directory. This is an XML file used to define the position where the corresponding layout is displayed in the content item. The following file shows an example of file placement. (Specifically, it comes from the placement.info file of orchard. tags) <Placement> <Place parts_tags_edit = "content: 7"/> <Match displaytype = "detail"> <Place parts_tags_showtags = "header: after.7"/> </Match> <Match displaytype = "summary"> <Place parts_tags_showtags = "header: after.7"/> </Match> </Placement> What does this file mean? First, this tags part has two shapes: parts_tags_edit and parts_tags_showtags. Parts_tags_edit is the shape used to edit the screen, and parts_tags_showtags is the shape used to display the screen. When parts_tags_showtags is used in the display screen, there are two display modes: Detailed display mode and abstract display mode. Secondly, through this file, we can know that when editing the screen display, the tag part needs to be displayed in the content area of the content item, and the position number is 7. When the display screen is displayed, the label part needs to be displayed in the header area of the content item, and the position is back. When the label part is back, the serial number is 7. The tag module defines the display position of the tag component by default. In the future, as long as the tag part is used, the display position of the tag part will be automatically arranged according to the definition of the placement file, instead of being specified in the Code.

If you haven't figured it out, let's give an example. For example, a blog post is displayed, which contains four parts: title, Tag, content, and comment. The placement.info file of the four parts is defined as follows:

<Place parts_routabletitle = "header: 5"/> <Place parts_tags_showtags = "header: after.7"/> <Place parts_common_body = "content: 1"/> <Place parts_comments = "content: 10"/> The displayed HTML will be: <Article> <Header> <Display the title content first, because the title is displayed in the header area, and the position number is 5, but it is no longer in front of it> <Then display the label. The label should also be displayed in the header area, but the display position is defined as backward> </Header> <The article content is displayed here, because the article content is displayed in the content area and the position number is 1> <The article comment is displayed here. Because the article comment is displayed in the content area and the position number is 10, it is displayed after the article content> <Footer> </Footer> </Article>

Through the above examples and descriptions, I believe you have some knowledge about the placement.info file. The following describes how to write a placement.info file.

 

Scope: the scope of objects to be placed is the content item. This means that you can use it to display any content items (blog articles, pages, comments, custom items, parts, etc.), but not necessarily any shape ). If a shape is not processed by a content part, you do not need to provide a file for placement. For example, the branding defined in the default topic is a shape, but it does not need to be processed by content components. Of course, it cannot be used to place files.

 

The placement node must be the root node of the placement.info file. This is equivalent to a simple container, indicating that the content under the node is what is to be defined in the file. The place node is the main node in the placement.info file. It can have any number of attributes, but based on readability requirements, it is recommended that each place node define only one shape location. The positions of multiple shapes can be defined by multiple place nodes. Line by line, which is clear and clear. The attribute of each place node corresponds to a shape name (for example, parts_tags_showtags). The value of this attribute is the location definition of the shape. For the shape of a module that needs to be defined, I can view the drive code of the corresponding module. When returning contentshape, you must specify a shapetype, which is the shape name. A simpler way is to use a design tool module provided by orchard to view the shape names of various content. For more information about this tool, see Customizing orchard using designer helper tools.

The attribute name of the place node can be the name of any shape (but not its replacement name, for example, a part can have the details display mode, abstract display mode, etc, match nodes are required to define the display positions of the same shape in different display modes, which will be described below ). However, when some fields are displayed, there are some special situations where files can be expanded. For example, the following placement file will disable the display of fields named "Occupation. (Note that the property value in this example is a short horizontal representation of the hidden meaning, but it does not mean that this special extension method is only applicable to hiding, and the property value can also be a positioning function, such as = "header: 1 ")

<Places Fields_Common_Text-Occupation = "-"/> Field developers should note that

To implement the above functions, when contentshape is returned in the drive of the field, a flag (differentiator) that can distinguish different fields is passed ). In this way, you can add the dash and field names behind the shape name to locate a specific field. For more information, see the method used to return contentshape in the drive of the textfield field.

The attribute value of the place node is composed of the region name + colon + positioning tag. The region names are generally header, Meta, content, or footer, which are defined in the content item template (content. cshtml. If you override the content item template, the names of these regions are the region names defined in the template. The positioning mark can be a separate number (1, 2, 3, 10, 20, etc.) or a multi-level combination of numbers separated by points (1.2, etc ). When multiple parts are arranged in the same region, they are arranged in ascending order. For multi-level digital combination positioning, first sort by the first number, then by the second number, and so on. For example, 1 is before 2.4.5 and 2.4.5 is before 2.10.

 

You can also use some delimiters to mark positioning tags, such as before and after. The part defined by a qualifier must be located before or after a number. For example, content: Before must be placed before content: 1, and header: After must be placed behind header: 10. The identifier of this positioning mark can also be used in hierarchical combinations separated by vertices. It is determined that the rules are compared one by one based on each layer. The qualifier must be preceded by or followed by a number.

 

In multi-layer comparison, if some positioning layers have three layers, some have only two layers. After sorting by comparison of existing layers, the part with a lower layer is ranked first by default. For example, 1.2 must be placed before 1.2.1 and 1.2.before.

 

In orchard V1.1, several new features are added: the replacement name of the specified shape, the packaging of the specified shape, and the rename of the Shape name. If you want to write a separate template for the tag part of a blog post in the topic, you can replace the name with a specified shape, in the blog article type, replace the shape name displayed in the label with a special name, so that you can easily specify the template for this particular example. Add the following code to the placement.info file: <Match contenttype = "blogpost"> <Place Parts_tags_showtags = "header: After; Alternate = parts_tags_showtags_blogpost"/> </Match> Then you can add a parts/tags. showtags. blogpost. cshtml file in the topic views directory to customize the Label display in the blog post.

Similarly, you can provide a packaging (header: After; wrapper = wrapper_greendiv) for a shape or name a shape (header: After; shape = iprefertocallthosestickersforsomereason ).

The function of specifying packaging and replacing names is similar. You can also specify a new template for a special case of a shape in the topic directory. In addition, I feel that these two new features are not very useful, because the template replacement rules can be used to create a specific template with different names for various special circumstances to override the original template function. For example, the tag display in the blog post mentioned above. In fact, I can also add a new tags. ShowTags-BlogPost.cshtml template in the theme views directory to achieve the same effect. It may be more flexible to specify the packaging and replacement name. I will try again later. To rename the shape name, you can replace a specific shape displayed in the part with another shape. I still cannot figure out what I can do. I will try again later.

 

The match node can define the application scope defined by the place node. The match node has the following attributes: Displaytype: Display type. It indicates that the location definition of the place node under the match node is applicable to some display mode. Display modes include detail and summary. Contenttype: Content type. It indicates that the location definition of the place node under the match node applies to a specified type. For example, you can specify the position of each part in a blog post. Path: Path. It indicates that the location definition of the place node under the match node applies to a specified path. For example, Path = "/about" indicates that the location definition of the corresponding part on the about page can be defined in the place node under the match node. You can also specify some wildcards, such: path = "/myblog/*" indicates that all corresponding parts on the page under this path can be defined in the place node under this match node. For example,/myblog and/myblog/firstpost are applicable. This attribute is unique to orchard1.1. All modules (with display requirements) of the rewrite location file must define a default placement file. This placement file must contain the location definition of all the display parts in this module. This file must be named placement.info and placed under the root directory of the corresponding module. Default file placement, which can be rewritten in any topic. By Rewriting the location definition of the corresponding display part, each topic can have its own module placement definition. Reference http://www.orchardproject.net/docs/Understanding-placement-info.ashx