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. So, let’s get to the basics. When the Platform runs a 1C application, it fills out the upper panel with the Subsystems we specified right here. Each Subsystem’s command 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 want it to make it to the interface or not by setting (or not setting) this flag. You also decide what Subsystem (or Subsystems) it goes to. This is how the Platform knows it needs to put the object commands to the command interface. Every Metadata Class has a set of predefined commands. In the case of the document, these are: open the documents 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 ones 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 guy 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 Subsystems it does or does not belong to. Now. How does the Platform know what to do when a user clicks one of the commands in the command interface? Let me show you.
So, 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 this Metadata Object and looks it up in this form’s 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 standard 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. And 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 and tell the Platform to use mine instead. After the browsing in 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 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 it 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. And the last one is the Folder selection form, which gets open when we need to select a parent folder for some item.
OK, let’s now open this item form both at runtime 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 as seen by a user, then 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 DataPath property of theirs. This form shows the Products catalog item, so when it gets opened, the current list item gets read from the database, then the form copies the attribute values to the elements according to this DataPath setting, and all this data travels all the way up to the user’s screen.
After a user changes 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 know how to change mutual positions of other elements or divide the form into several tabs, text labels and pictures that get displayed on the form "as is", 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, 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 spend filling out this form. To get this done, you can create an independent attribute called Start, give it the Date type and use it as a temporary in-form storage for the form opening time stamp. So, when the form gets closed, you can write something like this and calculate the time spent.