In the control
panel UMI.CMS inherently divided into basic software engine, which gets
under way is not a web developer (and is overwritten when updating the
system), and additional (custom) functional, which is the developer of
the site adapts itself: custom design templates, macros (PHP-functions
that are called from a template), custom modules, if necessary.
However, the development of the site, there are times when it is necessary to change the existing service to you:
In this case, the system must either edit the engine code (which immediately adds to the problems when upgrading CMS), or use the built-in functionality of events. In the documentation , or third-party resources to this question is considered, however, in my opinion, not enough detail. This article is an attempt to bring together information on the events in UMI.CMS, and on the basis of the example shows how to use event processing can extend the functionality of the system.
According to the documentation in UMI.CMS there are two types of event handlers:
If an event is a call to all designated his handlers (both system and user). Also (this is written in the documentation), system event handlers are executed after the user. This should be considered when developing a functional.
Events can be invoked to modify an object (eg, mode before) and after the change of the object (mode after). Not all events may be the "before" and "after", what they are, we must look at the link below.
List of internal events can be found in the documentation . It must be remembered that the action of one and the same object in different places will be called by different event handlers. This causes some disadvantages:
Suppose for example, we are developing online store based UMI, and we need to perform some action when the status of your order (for example, to send more email, put some other fields in order and so on, depending on status). Look where we can "catch" events change the order status:
Thus, to allow for a change in the status of all orders have to write 4 processor.
Let us dwell on the system event systemModifyPropertyValue. Mention of it in the documentation I found, saw his challenge only in the analysis of the code, and in fact do without it in the described sitatsii is difficult, because the site administrator (manager) can change the order data in two ways:
And if you only use an event handler systemModifyObject, you will have to explain to all future site administrators that they are in any case you can not change the data of the order from the list of orders, and only have to go to each order, and change something there. That, of course, very uncomfortable, and leaves a great opportunity to make a mistake.
SystemModifyPropertyValue system event has the following options:
This event can be used not only when editing the list of orders in the module "Store", and in other similar listings in admin UMI.CMS.
Appointed as an event handler, you can see for example here and here . I want to show a more complex example: as by creating an event handler to add the missing data import functionality in UMI - to teach the system to import optional product features.
Suppose, for example, we are developing an online store selling T-shirts. We have established 1C "Trade Management", in which we are going to keep track of goods and orders. In 1C wound all the necessary bill of goods and it is desirable to make it with minimal actions landed on the site.
Specificity sale of such goods is such that we have, for example, the model "T-shirt Dolce," which has sold the specific units:
That is, the set of positions of the model, different color and size (and perhaps the price for certain combinations). In terms of 1C is a "range of features." And in terms of the online store, we want to have a one-page model "T-shirt Dolce", on which the buyer could choose a color and size and build with them the order.
From the point of view of 1C seems simple. We put a range of settings, check "Specifications." Making the first unloading the disc, watch the resulting XML-file (offers.xml), these proposals have the right, rejoice and make uploading to the site. And then realize that happy early. Added goods themselves, but their characteristics (that particular shirt has a dozen offers with different combinations of colors and sizes) - no.
In the system we needed UMI functionality implemented by means of optional properties . That is, on the face of it all. However, upon further digging into the source code and the documentation it appears that the current version of UMI (2.8.6) module "Communication" can not import option properties. So we will build upon the desired functionality yourself.
Features imports from 1C UMI described in the documentation . To add the functionality to import the data to be modified template import / xsl/import/custom/commerceML2.xsl, and add your event handler imports.
Modify the pattern of imports:
With this template, you create a separate directory (Directory for the field "Specifications"), which records all of the characteristics of the options come 1C. In addition, the modified type for the directory object (product) to add back option properties. Thus, the very characteristics we have already uploaded to the site, you just write the code that would have compared the product characteristics.
Add your event handler. To do this, create a folder / classes / modules / exchange file custom_events.php c code
Thus, we set that as the establishment, and when an item is updated (product page) import method is called onImportElement. Let's write the code for this method in the file __ custom.php:
In this code after you create or add an item (check after) we read from the XML product features and the presence of optional properties are added to the appropriate product option features of the handbook "Handbook for the field characteristics."
After adding the specified code and re-unloading of goods to the site can see that each product has appeared positions, each with its own color and size. That is, the specified task dostinguta, and now we have a system UMI.CMS can import from 1C optional product features.
Thus, the events in the UMI - this is a very powerful tool, and with the help of their well-added event handlers can significantly extend the functionality of the site, without changing a single line of code CMS system and still have access to the system updates.
However, the development of the site, there are times when it is necessary to change the existing service to you:
- add your own logic to import data from XML;
- perform some action when importing data;
- perform some action when creating or modifying an order;
- perform some action on the Web;
- ... And so on.
In this case, the system must either edit the engine code (which immediately adds to the problems when upgrading CMS), or use the built-in functionality of events. In the documentation , or third-party resources to this question is considered, however, in my opinion, not enough detail. This article is an attempt to bring together information on the events in UMI.CMS, and on the basis of the example shows how to use event processing can extend the functionality of the system.
According to the documentation in UMI.CMS there are two types of event handlers:
- system - is preinstalled handlers that are written in the development of the module. These handlers are written in file events.php, which is the module directory. For the modules included in the delivery UMI.CMS, this file can not be edited.
- custom - these handlers must be in a file custom_events.php in the module.
If an event is a call to all designated his handlers (both system and user). Also (this is written in the documentation), system event handlers are executed after the user. This should be considered when developing a functional.
Events can be invoked to modify an object (eg, mode before) and after the change of the object (mode after). Not all events may be the "before" and "after", what they are, we must look at the link below.
List of internal events can be found in the documentation . It must be remembered that the action of one and the same object in different places will be called by different event handlers. This causes some disadvantages:
Suppose for example, we are developing online store based UMI, and we need to perform some action when the status of your order (for example, to send more email, put some other fields in order and so on, depending on status). Look where we can "catch" events change the order status:
- change of status to create customized site - event order-status-changed module Emarket;
- change of status from admin page detailed order information - system event systemModifyObject;
- change of status from admin page list of all orders - a system event systemModifyPropertyValue;
- change of status when importing it via XML (for example, during unloading of 1C) - event exchangeOnUpdateObject.
Thus, to allow for a change in the status of all orders have to write 4 processor.
Let us dwell on the system event systemModifyPropertyValue. Mention of it in the documentation I found, saw his challenge only in the analysis of the code, and in fact do without it in the described sitatsii is difficult, because the site administrator (manager) can change the order data in two ways:
- on the main page "Shop" in the list of all orders - UMI allows you to edit the status and other data directly to order right in this list;
- in the details of the order, which is opened by clicking on the order.
And if you only use an event handler systemModifyObject, you will have to explain to all future site administrators that they are in any case you can not change the data of the order from the list of orders, and only have to go to each order, and change something there. That, of course, very uncomfortable, and leaves a great opportunity to make a mistake.
SystemModifyPropertyValue system event has the following options:
- entity - a reference to the object that is changing the property;
- property - the name of the property to be changed;
- oldValue - the old value of the property;
- newValue - the new value of the property;
This event can be used not only when editing the list of orders in the module "Store", and in other similar listings in admin UMI.CMS.
Appointed as an event handler, you can see for example here and here . I want to show a more complex example: as by creating an event handler to add the missing data import functionality in UMI - to teach the system to import optional product features.
Suppose, for example, we are developing an online store selling T-shirts. We have established 1C "Trade Management", in which we are going to keep track of goods and orders. In 1C wound all the necessary bill of goods and it is desirable to make it with minimal actions landed on the site.
Specificity sale of such goods is such that we have, for example, the model "T-shirt Dolce," which has sold the specific units:
- White T-shirt Dolce, 40 size;
- White T-shirt Dolce, 48 size;
- Red shirt Dolce, 44 size;
- ... And so on.
That is, the set of positions of the model, different color and size (and perhaps the price for certain combinations). In terms of 1C is a "range of features." And in terms of the online store, we want to have a one-page model "T-shirt Dolce", on which the buyer could choose a color and size and build with them the order.
From the point of view of 1C seems simple. We put a range of settings, check "Specifications." Making the first unloading the disc, watch the resulting XML-file (offers.xml), these proposals have the right, rejoice and make uploading to the site. And then realize that happy early. Added goods themselves, but their characteristics (that particular shirt has a dozen offers with different combinations of colors and sizes) - no.
In the system we needed UMI functionality implemented by means of optional properties . That is, on the face of it all. However, upon further digging into the source code and the documentation it appears that the current version of UMI (2.8.6) module "Communication" can not import option properties. So we will build upon the desired functionality yourself.
Features imports from 1C UMI described in the documentation . To add the functionality to import the data to be modified template import / xsl/import/custom/commerceML2.xsl, and add your event handler imports.
Modify the pattern of imports:
Import template
With this template, you create a separate directory (Directory for the field "Specifications"), which records all of the characteristics of the options come 1C. In addition, the modified type for the directory object (product) to add back option properties. Thus, the very characteristics we have already uploaded to the site, you just write the code that would have compared the product characteristics.
Add your event handler. To do this, create a folder / classes / modules / exchange file custom_events.php c code
<?php new umiEventListener("exchangeOnUpdateElement", "exchange", "onImportElement"); new umiEventListener("exchangeOnAddElement", "exchange", "onImportElement"); ?>
Thus, we set that as the establishment, and when an item is updated (product page) import method is called onImportElement. Let's write the code for this method in the file __ custom.php:
Event handling code
In this code after you create or add an item (check after) we read from the XML product features and the presence of optional properties are added to the appropriate product option features of the handbook "Handbook for the field characteristics."
After adding the specified code and re-unloading of goods to the site can see that each product has appeared positions, each with its own color and size. That is, the specified task dostinguta, and now we have a system UMI.CMS can import from 1C optional product features.
Thus, the events in the UMI - this is a very powerful tool, and with the help of their well-added event handlers can significantly extend the functionality of the site, without changing a single line of code CMS system and still have access to the system updates.
Articles
0 commentaires:
Enregistrer un commentaire