CMS: Document Management Model and store

Article management involves the t_category, t_content, t_tag, and t_tagincontent tables. on the client side, the display of the two tables of tags is merged into the content of the article, therefore, document management requires at least two models and two stores. One is classified and the other is content.

The question is: the classification on the left of the document management interface is displayed in the tree form. Do I need to use a complete model? A complete model must be required, because the classification must also be edited, modified, and added. But does the tree directly use this complete model? This is to be considered. First, the model structure of the tree must be different from that of the complete model. It will automatically add many fields, and the ID and text are required. This can be changed when defining the model or store, but not very convenient. Second, the full model data is returned for each tree node expansion, which is a waste of communication because the complete model data is not required at this time and is only required for node editing. Based on the above two points, the author's opinion is that it is more appropriate to split the model into two models. Although it has the advantage of returning the complete model, when editing the model, the server does not have to fetch data again.

When editing an article, you need to use ComboBox to select an article category. Therefore, you also need a model and store. here you need to consider whether to use the drop-down tree selection box or a common drop-down box. If you use the drop-down tree selection box, you can directly use the store in the tree list. The only problem with using the tree list is that when you edit an article, if the current tree has not been expanded, it will be blank, therefore, before opening the editing window, you must expand the tree first, which is complicated to process. The second method is the drop-down selection box, which returns all nodes at a time, or displays the results using a query method similar to a search website. I prefer to return all nodes and implement the query method locally. Therefore, a model and store are also required.

So should the article be split into two models and stores? The main consideration is the communication problem. The author's habit is not to split, just use one, for a reason, get used to it.

Based on the above, the models to be created include category, categorytree, categorycombo, and content. Store includes categoriestree, categoriescombo, and contents. Here, a store with a category is missing because the complete classification model is only used for editing and adding. These are operations performed on a single model instance and do not need to be used for the store, therefore, it can be left unspecified.

Now, you can do it. Under the scripts \ app \ model directory, create category. js to define the complete classification model. The Code is as follows:

Ext. Define ('simplecms. model. Category ',{

Extend: 'ext. Data. model ',

Fields :[

{Name: "parentid", type: "int", defaultvalue: "-1 "},

{Name: "categoryid", type: "int "},

"Title ",

"Image ",

"Summary ",

"Content ",

{Name: "created", type: "date", dateformat: "Y-m-DH: I: s", defaultvalue: new date ()},

{Name: "sortorder", type: "int", defaultvalue: 0}

],

Proxy :{

Type: "ajax ",

URL: "category/details ",

Reader :{

Type: 'json ',

Root: "data ",

Messageproperty: "MSG"

 

}

},

Idproperty: "categoryid"

});

 

From the definition code, we can see that the field name is the same as the field name defined in the table, which is convenient. If you are afraid of information leakage, you can modify the information as needed. Some fields are not defined because they are omitted without being displayed during editing. The definition of proxy is basically the same as that of the previous definition. The purpose is to ensure that a unified data return format is used.

Create the categorytree. js file to define the classification tree model. The Code is as follows:

Ext. Define ('simplecms. model. categorytree ',{

Extend: 'ext. Data. model ',

Fields: ["text ",

{Name: "ID", type: "int "},

{Name: "parentid", type: "int "}

]

});

 

No proxy is defined in the Code. This is defined by the store, because the basic operation is at the store level.

Next is categorycombo. js. The Code is as follows:

Ext. Define ('simplecms. model. categorycombo ',{

Extend: 'ext. Data. model ',

Fields: ["text ",

{Name: "ID", type: "int "},

{Name: "parentid", type: "int "},

"Listtext ",

"Fullpath ",

{Name: "hierarchylevel", type: "int "}

]

});

 

This model actually only requires two fields, but in order to display the needs, we have added several other fields.

 

Followed by content. JS, the Code is as follows:

Ext. Define ('simplecms. model. content ',{

Extend: 'ext. Data. model ',

Fields :[

{Name: "contentid", type: "int "},

{Name: "categoryid", type: "int", defaultvalue: 10000 },

"Title ",

"Image ",

"Summary ",

"Content ",

{Name: "created", type: "date", dateformat: "Y-m-DH: I: s", defaultvalue: new date ()},

{Name: "hits", type: "int "},

{Name: "sortorder", type: "int", defaultvalue: 0 },

"Tags"

],

Proxy :{

Type: "ajax ",

URL: "content/details ",

Reader :{

Type: 'json ',

Root: "data ",

Messageproperty: "MSG"

 

}

},

Idproperty: "contentid"

 

});

A tags field is added to the Code to display tags. This field will return data in the form of arrays, which will facilitate subsequent processing. In categoryid, the default value is 10000, indicating that the default category is "Unclassified" when the document is created ".

In this way, all models are defined. Now, switch to the store directory and create categoriestree. js first. The Code is as follows:

Ext. Define ("simplecms. Store. categoriestree ",{

Extend: 'ext. Data. treestore ',

Batchactions: false,

Remotefilter: false,

Remotesort: false,

Model: "simplecms. model. categorytree ",

Root: {text: "document category", ID:-1 },

Proxy :{

API :{

Destroy: 'category/delete'

},

Type: "ajax ",

URL: "/category/list ",

Reader :{

Type: 'json ',

Root: "data ",

Messageproperty: "MSG"

},

Writer :{

Type: "JSON ",

Encode: True,

Root: "data ",

Allowsingle: True

}

}

})

 

Because the addition and editing of categories are completed in the form, only the delete address is defined in the configuration item API.

 

Next is categoriescombo. js. The Code is as follows:

Ext. Define ("simplecms. Store. categoriescombo ",{

Extend: 'ext. Data. store ',

Batchactions: false,

Remotefilter: false,

Remotesort: false,

Autoload: True,

Model: "simplecms. model. categorycombo ",

Proxy :{

Type: "ajax ",

URL: "/category/All ",

Reader :{

Type: 'json ',

Root: "data ",

Messageproperty: "MSG"

}

}

});

 

The Code defines the configuration item autoload as true, indicating that data is automatically loaded after the store is instantiated.

 

The final part is contents. js. The Code is as follows:

Ext. Define ("simplecms. Store. Contents ",{

Extend: 'ext. Data. store ',

Model: 'simplecms. model. content ',

Batchactions: false,

Remotefilter: True,

Remotesort: True,

Pagesize: 50,

Proxy :{

Type: "ajax ",

URL: "content/list ",

Reader :{

Type: 'json ',

Root: "data ",

Messageproperty: "MSG"

}

}

})

 

From the code, we can see that the article store must support remote sorting and search, and each 50 records is one page.

 

Now, the model and store managed in this article have been defined, and the Controller will be defined below.