Now let's talk metadata. Let me make some room down here and run the application right under the designer. This is the boundary. All the metadata leaves above it and all the data leaves below each data item for example, this sales document here is an instance of a specific metadata object, sales in our case. Each metadata object in its turn is an instance of a specific metadata class, which would be the documents. Data is controlled by the users. Metadata objects are controlled by the 1C developers like you and me. Metadata classes are God given to us. Just kidding. There are the part of the platform which can be changed only by the 1C Company. But what does it even mean to be an instance to instantiate? It's exactly what happens between classes and objects in the object oriented programming. Classes define object's structure and behavior. This is what metadata classes do for the metadata objects and what they in turn do for the data. Let's look at the structure inheritance first. Each metadata class defines its specific set of so-called standard attributes. For the documents, it could be the reference, the number, the date, and so on. These guys were all inherited from these metadata class and will always be there whenever I create a new document. This structure can be easily extended under metadata object level. Let's add a payment method attribute to the sales document. Down the road. All of this will be inherited by the sales documents created by users. After we added a new attribute to the metadata object, we should tell the platform what type it has. Let's browse through all the types available and see orders where to store numbers. It can be as long as 32 digits can have a fractional part and support or not support negative values. The string can be of a fixed length, of a variable length up to a certain limit or of an unlimited length. The date tag can contain the date, the time or both. The Boolean is just true or false. Boring. The value storage is for any bulky stuff like pictures, videos, big documents, etc. They UID is for the universally unique identifier, which is an almost certainly unique value across all other UIDs existing anywhere else. Then we have a bunch of reference types. You can choose any of the existing metadata objects and point to them from other objects. For example, the product attribute here has catalog graph dot products type, meaning data it can store a reference to the products catalg located. That was simple, wasn't it? Now check this out. I'm selecting this Chatbox and all of a sudden I'm going to select more than one type for the single attribute. This is called a composite type attribute. It means you can afford to be as unsure about the attribute type as you want. For example, I can add a new attribute called Additional Info and give to user a bunch of options to choose from. During the runtime, a user will decide what exact type he wants for these very document. Then specify the value of the attribute. This was the data structure. Now to the behavior, we spend literally a couple of minutes to draft a few metadata objects. We didn't write a single line of code, but the application auditive works. We can browse lists, edit existing data items, create the new ones, even print out the reports. This is what metadata classes do for us. Each class knows how to order by default, what forum to open for the data item, what to do when a user clicks "Save" or post and so on. We can modify this default behavior on the metadata objects level. The same way we can modify the structure. We can redraw the forums, replace the standard algorithms with our source code, etc. The metadata classes can afford been that ready to go because as they are highly specialized. Catalog knows exactly what to do because it's purpose is very well-defined. The same applies to each and every metadata class. None of them are interchangeable. Each one has specific purpose and we need to know exactly who does what. You don't want to use a catalog for their accumulation registers task, trust me on this. This is what it means to develop 1C applications. This is what 1C developers do. They pick the metadata class most fit for the task. Create metadata object and then modifies it's structure and behavior to meet the requirements.
