Umi.CMS developer problem tree, options for slowing growth
Unfortunately for the programmer, after finishing the project development on Umi.CMS he may have two problems:
1) How to explain to the person responsible for filling the content, the project device.
2) How to quickly solve problems with the project during the warranty service period.
Umi.CMS provides a set of modules that are rather abstracted from solving real problems. Actually, none of the modules available in the system
It does not allow to immediately solve the tasks of the customer, as the functionality incorporated in the templates by default is rather limited. Instead of ready-made solutions
offers a set of tools that allows you to flexibly prepare the necessary solutions.
')
This flexibility has a reverse side of high dependence on the level of training and the particular thinking of an individual programmer.
Tasks can be solved in different ways, and the method can be so nontrivial that it will create real problems for everyone who uses it.
The person filling the content, be it a professional copywriter or an unknown performer of the customer, wants to solve only his own tasks, but instead
it takes a long time to adapt to the features of a specific project implementation. Insufficient qualification of a programmer or a complex project that requires a non-standard approach,
lead to the fact that in the administrative panel Umi.CMS grows a spreading tree of interrelated pages of different data types with numerous parameters.
Getting lost in such a tree is very easy, even documentation prepared for a copywriter cannot insure against accidents. The question arises of optimizing the tree to such an extent that even in case of serious errors
there was the possibility of restoring the site. And preferably only by means of the administrative panel, without interfering with the code templates and macros.
The shock growth of the page tree is caused by the following reasons:
1) A large number of registered in the template system. For example, templates for all occasions are registered in the settings of the Structure module: for the main page, for news, polls, a forum, etc.
In addition to templates with an obvious purpose, specialized templates of the type “Special offer of our company such and such” or “Report form No. 22” can be registered.
When creating a new page, a copywriter is forced to choose a template from a large list, which is unpleasant in itself and can cause certain difficulties if the purpose of the template is not clear.
As a rule, many templates are registered using the Umi TPL template, but some projects have such an eclectic design that even using the XSLT template engine,
register additional templates. Although using the XSLT template engine at least allows you to create really different templates.
2) A large number of parameters created for individual data types. For example, in addition to special pages with parameters for displaying a catalog or online store, groups of parameters can be created for displaying a specific section of a catalog.
To exacerbate the problem can the desire of the programmer to reduce development time and bind a selection of parameters from critical pages to the identifiers of these pages.
Often, a page of the form “Vital Parameters of an Online Store” is created with a specific identifier. To access the properties of this page, the programmer
right in the template prescribes this identifier. A copywriter or, strangely enough, happens more often, an unknown artist of the customer accidentally deletes this page. The online store is broken and the simple creation of a page of the same type of data in the administrative panel
does not save the situation, since its identifier does not coincide with that prescribed in the templates. You have to involve a programmer, analyze templates, and it will be good if there are few such templates.
3) The close relationship of the pages of the tree, used to implement some of the functionality of the project.
Suppose there is a task to display a gallery of photos of a certain product, and the number of photos can be anything. This can be implemented as follows.
An image gallery is created and in the page tree it is embedded in the product page, becoming its child page. The template searches for a child gallery and displays it on the page. For a copywriter, everything is quite simple. He will still have to create a gallery, and its purpose for a product is made by moving the tree to the right place.
However, if the gallery is not moved to the right product, nothing will be displayed, because the product template will not find it.
If you set the “Link to tree” property to a product and specify a specific gallery in it, then its movement will not be displayed on the photo display, but the copywriter will have to add an extra property.
Any of these options solves the final problem, but has its drawbacks.
Realizing that content filling errors can significantly complicate the life of a programmer, it is better for a programmer to try in advance to optimize the page tree as much as possible in the context of a specific project.
And it should be done immediately at the stage of preparing the system for work.
1) If there is an opportunity, it is better to use the XSLT template engine, since it is possible to relatively simply reduce the number of templates registered in the system. This will save the copywriter from having to make difficult choices.
and the programmer from having to look for and fix errors caused by assigning the wrong template. You can, of course, implement the output of various functional and within the same TPL-template, but it will take a lot of effort to write custom macros and JavaScript-code. Despite the efficiency of this approach
terms and complexity of development increase significantly.
2) Since the work of a programmer in Umi.CMS is reduced to the creation of new data types, as well as properties for new and existing data types, it is advisable to do all the necessary work in advance in the Data Templates module.
Particular attention should be paid to creating data types of parameter pages. If the project is supposed to use certain parameters, they are desirable not to be placed in many different pages, but to create a separate data type with the necessary property groups.
Pages of this kind are desirable to be grouped in one place to reduce the likelihood of their accidental deletion. You can create a separate parent page for these pages.
A special type of data is useful in that the selection of parameters can not be tied to the page identifier. Instead, you can execute a request to search a page with parameters.
For example, we have an online store options page. We need an identifier not of the page itself, but of its data type, for example, 152. Create a ussel getSpecial.xml query of the form
Then a query like usel: // getSpecial / 152/0/0 / ascending / id / 1 / will return the first page of this data type to us. If the copywriter accidentally deletes this page, you can create a new one directly in the administration panel without interfering with the templates. This will be especially useful if
prevent the copywriter from accessing the “Data Templates” module by registering an individual user with limited rights for it.
In project templates, it is advisable not to use any page identifiers at all. Search for many pages can be organized by their data type or by special properties using the Usel protocol.
To reduce the mention in the templates not only page identifiers, but also data type identifiers, you can actively use variables. For example,
Using the last variable further in the template eliminates the need to apply the data type identifier 152. Although, if the copywriter gets to the data templates and deletes them, you still have to redo everything.
3) Despite the fact that the close interrelation of pages can cause certain problems, with its help it is easy to organize a copywriter training on the principle of "Do as here", creating a test sample of data, as it is extremely intuitive.
Let's return to the example with photos for the goods. You can create a separate container page with a list of galleries, and the product to create the property "Link to a tree" to select the correct gallery. If the gallery is assigned, then it will regularly be displayed on the product page until it is deleted.
However, since the gallery is in a separate thread, its connection with the product is not obvious. When filling in the content, you will have to take into account that the product is somewhere there, and the gallery is somewhere here. In addition, the choice of "Link to the tree" from a large tree of pages can be inconvenient.
If the gallery is embedded in the product, their relationship is obvious.
Do not underestimate the importance of taking care of the convenience of a copywriter during development, unless, of course, you are not sure that your project will not come back to you for revision and you will not have to explain
copywriter logic of their decisions. Optimization of the page tree in addition to the documentation is one of the ways to reduce the complexity of the copywriter's adaptation to the project and to remove a significant part of the questions on its design.
As a result, the programmer gets rid of unnecessary risks for himself at the stage of technical support of the project.
1) How to explain to the person responsible for filling the content, the project device.
2) How to quickly solve problems with the project during the warranty service period.
Umi.CMS provides a set of modules that are rather abstracted from solving real problems. Actually, none of the modules available in the system
It does not allow to immediately solve the tasks of the customer, as the functionality incorporated in the templates by default is rather limited. Instead of ready-made solutions
offers a set of tools that allows you to flexibly prepare the necessary solutions.
')
This flexibility has a reverse side of high dependence on the level of training and the particular thinking of an individual programmer.
Tasks can be solved in different ways, and the method can be so nontrivial that it will create real problems for everyone who uses it.
The person filling the content, be it a professional copywriter or an unknown performer of the customer, wants to solve only his own tasks, but instead
it takes a long time to adapt to the features of a specific project implementation. Insufficient qualification of a programmer or a complex project that requires a non-standard approach,
lead to the fact that in the administrative panel Umi.CMS grows a spreading tree of interrelated pages of different data types with numerous parameters.
Getting lost in such a tree is very easy, even documentation prepared for a copywriter cannot insure against accidents. The question arises of optimizing the tree to such an extent that even in case of serious errors
there was the possibility of restoring the site. And preferably only by means of the administrative panel, without interfering with the code templates and macros.
The shock growth of the page tree is caused by the following reasons:
1) A large number of registered in the template system. For example, templates for all occasions are registered in the settings of the Structure module: for the main page, for news, polls, a forum, etc.
In addition to templates with an obvious purpose, specialized templates of the type “Special offer of our company such and such” or “Report form No. 22” can be registered.
When creating a new page, a copywriter is forced to choose a template from a large list, which is unpleasant in itself and can cause certain difficulties if the purpose of the template is not clear.
As a rule, many templates are registered using the Umi TPL template, but some projects have such an eclectic design that even using the XSLT template engine,
register additional templates. Although using the XSLT template engine at least allows you to create really different templates.
2) A large number of parameters created for individual data types. For example, in addition to special pages with parameters for displaying a catalog or online store, groups of parameters can be created for displaying a specific section of a catalog.
To exacerbate the problem can the desire of the programmer to reduce development time and bind a selection of parameters from critical pages to the identifiers of these pages.
Often, a page of the form “Vital Parameters of an Online Store” is created with a specific identifier. To access the properties of this page, the programmer
right in the template prescribes this identifier. A copywriter or, strangely enough, happens more often, an unknown artist of the customer accidentally deletes this page. The online store is broken and the simple creation of a page of the same type of data in the administrative panel
does not save the situation, since its identifier does not coincide with that prescribed in the templates. You have to involve a programmer, analyze templates, and it will be good if there are few such templates.
3) The close relationship of the pages of the tree, used to implement some of the functionality of the project.
Suppose there is a task to display a gallery of photos of a certain product, and the number of photos can be anything. This can be implemented as follows.
An image gallery is created and in the page tree it is embedded in the product page, becoming its child page. The template searches for a child gallery and displays it on the page. For a copywriter, everything is quite simple. He will still have to create a gallery, and its purpose for a product is made by moving the tree to the right place.
However, if the gallery is not moved to the right product, nothing will be displayed, because the product template will not find it.
If you set the “Link to tree” property to a product and specify a specific gallery in it, then its movement will not be displayed on the photo display, but the copywriter will have to add an extra property.
Any of these options solves the final problem, but has its drawbacks.
Realizing that content filling errors can significantly complicate the life of a programmer, it is better for a programmer to try in advance to optimize the page tree as much as possible in the context of a specific project.
And it should be done immediately at the stage of preparing the system for work.
1) If there is an opportunity, it is better to use the XSLT template engine, since it is possible to relatively simply reduce the number of templates registered in the system. This will save the copywriter from having to make difficult choices.
and the programmer from having to look for and fix errors caused by assigning the wrong template. You can, of course, implement the output of various functional and within the same TPL-template, but it will take a lot of effort to write custom macros and JavaScript-code. Despite the efficiency of this approach
terms and complexity of development increase significantly.
2) Since the work of a programmer in Umi.CMS is reduced to the creation of new data types, as well as properties for new and existing data types, it is advisable to do all the necessary work in advance in the Data Templates module.
Particular attention should be paid to creating data types of parameter pages. If the project is supposed to use certain parameters, they are desirable not to be placed in many different pages, but to create a separate data type with the necessary property groups.
Pages of this kind are desirable to be grouped in one place to reduce the likelihood of their accidental deletion. You can create a separate parent page for these pages.
A special type of data is useful in that the selection of parameters can not be tied to the page identifier. Instead, you can execute a request to search a page with parameters.
For example, we have an online store options page. We need an identifier not of the page itself, but of its data type, for example, 152. Create a ussel getSpecial.xml query of the form
<?xml version="1.0" encoding="UTF-8"?> <selection> <target expected-result="pages count" force-hierarchy="1"> <type id="{1}" /> <category depth="{3}">{2}</category> </target> <limit page="{p}">{6}</limit> <sort order="{4}">{5}</sort> </selection> Then a query like usel: // getSpecial / 152/0/0 / ascending / id / 1 / will return the first page of this data type to us. If the copywriter accidentally deletes this page, you can create a new one directly in the administration panel without interfering with the templates. This will be especially useful if
prevent the copywriter from accessing the “Data Templates” module by registering an individual user with limited rights for it.
In project templates, it is advisable not to use any page identifiers at all. Search for many pages can be organized by their data type or by special properties using the Usel protocol.
To reduce the mention in the templates not only page identifiers, but also data type identifiers, you can actively use variables. For example,
<xsl:variable name="commonParamsId" select="document('usel://getSpecial/152/0/0/ascending/id/1/')/udata/page[1]/@id" /> <xsl:variable name="commonParams" select="document(concat('upage://', $commonParamsId))/udata" /> Using the last variable further in the template eliminates the need to apply the data type identifier 152. Although, if the copywriter gets to the data templates and deletes them, you still have to redo everything.
3) Despite the fact that the close interrelation of pages can cause certain problems, with its help it is easy to organize a copywriter training on the principle of "Do as here", creating a test sample of data, as it is extremely intuitive.
Let's return to the example with photos for the goods. You can create a separate container page with a list of galleries, and the product to create the property "Link to a tree" to select the correct gallery. If the gallery is assigned, then it will regularly be displayed on the product page until it is deleted.
However, since the gallery is in a separate thread, its connection with the product is not obvious. When filling in the content, you will have to take into account that the product is somewhere there, and the gallery is somewhere here. In addition, the choice of "Link to the tree" from a large tree of pages can be inconvenient.
If the gallery is embedded in the product, their relationship is obvious.
Do not underestimate the importance of taking care of the convenience of a copywriter during development, unless, of course, you are not sure that your project will not come back to you for revision and you will not have to explain
copywriter logic of their decisions. Optimization of the page tree in addition to the documentation is one of the ways to reduce the complexity of the copywriter's adaptation to the project and to remove a significant part of the questions on its design.
As a result, the programmer gets rid of unnecessary risks for himself at the stage of technical support of the project.
Source: https://habr.com/ru/post/142601/
All Articles