First of all, I want us to recap how UX UI works in 1C Enterprise to make sure we have a solid basis before we dig any deeper. Let's get to the basics. When the platform runs a 1C application, it feels out the upper panel with the subsystems we specified right here. Each subsystems common set is taken from this Command Interface setting. But how did these guys get here in the first place? This is how. When you create a metadata object, you decide if you wanted to make it to the interface or not by not setting this flag. You also decide what subsystem or subsystems it goes to. This is how the platform knows it needs to prove the object commands to the Command Interface. Every metadata class has a set of predefined commands indicates of the document. These are, open the document list and create a new document. Besides that, you can define your own commands doing whatever else you might need, and they will follow the standard wants to this form and to the UI as soon as this flag is on, and the application is run. Besides the Subsystems, we have this Quick menu guide, whose commands come from these settings. This quick menu is where we can decide to show any command of any metadata object regardless of the subsystem it does or does not belong to. Now, how does the platform know what to do when the user clicks one of the commands in the Command Interface. Let me show you. This is the standard command that came from the catalogs metadata class, and is meant to open the list of the products catalog items. The platform goes to these metadata object and looks it up in these forums settings. These are the five forms the platform knows how and where to use for the catalogs metadata class. In other words, the platform has some standards UX UI hardwired into this class, and then inherited by all the catalogs you create. The platform assumes that working with the object data, like a catalog or a document, is supposed to start with opening the Items list. The purpose of this form is to give an overview of the items and provide users with tools to browse through objects, search for a specific one, as well as create, edit, and delete objects. This setting is how the platform knows what form to use as the list form. If I clear this property, the platform will use the generic list form taken from the catalogs metadata class. If I'm not entirely happy with the generic form design or functionality, I build my own version until the platform to use mine instead. After the browsing and the list form is done, I might want to add a new item or edit an existing one. This is where the item form gets opened, and the platform passes and the current list item to it. Besides that, we have the folder form, which is used to create new folders. It gets taken from this setting which is empty, so the platform generates the default form. We also have the choice form, which is used whenever we need to select a specific catalog item when filling out other objects. The last one is the folder selection form, which gets opened when we need to select a parent folder for some item. Let's now open this Item form both at run time and in designer, and see how it works in a nutshell. I'm editing out all the rest, and there we have it. The form is seen by user than the form elements and attributes as seen by a developer. Form elements speak to a user. Form attributes speak to a database. Some of the elements also speak to some of the attributes using this data path property of this. This one shows that the products catalog item. When it gets opened, the current list item gets read from the database, and then the form copies to the attribute values to the elements according to these data path setting. All these data travels all the way up to the user's screen. After a user changes to any form data, this data goes downstream and gets written to the database. Some elements might have nothing to do with the data and therefore have no connection with the form attributes. There might be groups that now how to change mutual position, so further elements or divide the forum into the several tabs, text labels on pictures so that can displayed on a form SE's and so on. But connected to the data or not, they affect the form either by being visible themselves or by changing the appearance of other elements. As for the attributes, so they can be as independent as it gets even connected neither to the attributes nor to the database. For example, you might want to track how much time users spent filling out this form. To get this done, you can create an independent attributes called start, given the date type, and to use it as a temporary informed storage for the form opening time stamp. When the form gets closed, you can write something like this and calculate the time spent.
