Now, let’s talk data and metadata. Let me make some room down here and run the application right under the Designer. So, this is the boundary: all the metadata lives above it and all the data lives 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. And the Metadata Classes are God-given to us. Just kidding. They 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 objects structure and behaviour. 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 will be the Reference, the Number, the Date and so on.
These guys were all inherited from the this metadata class and will always be there whenever I create a new document.
This structure can be easily extended on the Metadata Object level. So, let’s add the PaymentMethod attribute to the Sales document.
Down the road, all of these will be inherited by 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 what is where.
The Number is, well, 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 can contain the date, the time or both.
The Boolean is just True or False. Boring.
The ValueStorage is for any bulky stuff, like pictures, videos, big documents, etc.
The UUID is for the the universally unique identifier, which is an almost-certainly-unique value across all other UUIDs existing anywhere else.
Then we have a bunch of reference types, so you can choose any of the existing metadata objects and point to them from other objects.
For example, the Product attribute here has CatalogRef.Products type, meaning that it can store a reference to the Products catalog item.
OK, that was simple, wasn’t it? Now check this out. I’m selecting this checkbox and, all of a sudden, I can select more than one type for the single attribute. This is called a composite-type attribute and 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 AdditionalInfo and give to a user a bunch of option to choose from.
During the runtime, a user will decide what exact type he wants for this very document and then specify the value of the attribute.
OK, this was the data structure. Now, to the behavior. We spend literally couple of minutes to draft a few Metadata Objects; we didn’t write a single line of code; but the application already 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 work by default - what form to open for the data item, what to do when a user clicks Save or Post, and so on.
We can modify this default behaviour on the Metadata Objects level the same way we can modify the structure.
We can redraw the forms, replace the standard algorithms with our source code, etc.
The Metadata Classes can afford being that ready to go because they are highly specialized. Catalog knows exactly what to do, because its 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 the Accumulation Register’s task, trust me on this.
This is what it means, to develop 1C applications. This is what 1C developers do. They pick the Metadata Classes most fit for the task, create Metadata Objects and then modify its structure and behaviour to meet the requirements.