Besides the Metadata Classes that live in the application tree and are represented by the Applied Objects in the Global Context, there is a bunch of system classes available for us in the Platform.
These are common objects, universal value collections, interface classes, and queries. This is what we are here to talk about today.
But first of all, let’s check out the difference between the Metadata Classes and the System Classes. Metadata Classes are meant for us to create their subclasses - Metadata Objects - like this Sales document, for example.
We can extend the Metadata Class data structure by adding new attributes and tabular sections. We also can change the default behavior by handling the Metadata Class events. We can even change the default appearance by redefining the Metadata Class forms.
This Metadata Object we created lives in the Global Context and can be used in the source code - the local context of some server-side procedure we’re writing. Here we can create its instance - the document object - using one of the factories it inherits from the Documents Metadata Class.
As for the System Classes - like this Array class, for example - there is no way on Earth to create its subclass and change Array’s behavior by adding all the bells and whistles we might want. The only thing we can do is to create an Array instance in the local context like this.
Note that we used the Metadata Object factory from the Global Context in the case of the Sales document. For the Array class, there is nothing in the Global Context, so we have to use this universal object factory - the New operator.
OK, let’s bring back the Script Engine picture and take a closer look at the System Classes we have on hand.
First up: Common objects. A huge pile of very different and highly specialized classes. We have a bunch of classes to read and write files of different formats, classes to work with the Internet and email, and way too many other useful and sometimes complex things.
We’ll cover some of them later in this course, but for the most part, they are for you to self-discover when you run into a task that requires one of them.
Next up: Interface-related system classes. These bad boys are to work with the user interface, and I’ll talk you through them in the very next module.
Next: Queries. Another topic well deserving its own module, which is Module 5 of this course.
So, let’s set it aside for now. And the last bunch of the System Classes: Universal value collections. We use them all the time all over the place, so let’s dig a bit deeper here.
All of these are in-memory value lists you can create in the local context. Let’s take a closer look at the most commonly used ones: Array, Structure, and Map.
First up: Array.
It’s basically just an indexed list of any number of values of any type. This is how we create it, and this is how we fill it out with data. I’m adding some random string and then some number using this Add method.
The Array elements are numbered starting from zero, but these numbers are bound to the positions of the elements in the array - not to their values. I can easily insert a new element into a specific position, in which case all further elements get moved down, and their indexes get changed.
We can read any element’s value by its index if we know it. And this will be the result.
We can cycle through the array elements just like this. And search for an element with a specific value like this, which will give us the index of the element.
So, this was the Array. Next: Structure.
I’m changing the collection type, and there is no Add method anymore. Luckily, Insert is still with us, although now it has two parameters: Key and Value. The thing is that instead of Index, the Structure uses the string-type Key attribute, which has to be a valid 1C:Enterprise variable name. Like this, for example.
The Key attribute is a unique identifier of the Structure element that goes along with the element’s value (rather than element’s position). So, if I do this, the same Structure element value will be replaced with the new one.
OK. Let’s give some valid names to the rest of the Structure’s elements. As for the reading, of course, we cannot address the Structure element by Index for there are no indexes in the Structure. But we can use the Key value and get the same result. Or even use the dot syntax like this and still get what we need, as you can see.
Of course, we can cycle through the elements the same way we do with the Array, but we cannot search by a value - only by a Key. So this one won’t work.
OK, this is our Structure. The Map collection looks pretty much the same, except its Key attribute can be of an arbitrary type, so we need another column here.
Obviously, there is no valid-name rule anymore, so we can get away with the Key values like this, or this, or even this if we need it for some reason.
And of course, we can search by the Key value as long as we use the correct one, and cycle through the elements, but we cannot use the dot syntax anymore, because the Key values do not conform to the 1C:Enterprise variable naming convention.
OK, let’s recap what we just learned about Array, Structure, and Map. All three of those can store values of any types. Array element position is indexed by serial number, while Structure has to have a unique name-valid string Key, and the Map can have the Key of any type. All three collections support square-brackets syntax to obtain a specific element, but the Array uses the index, while the other two use the Key value. The dot syntax is supported only by the Structure collection. All three collections support For Each cycle, but only the Array allows you to search by the value.
So. These are our System Classes.