Metadata Objects are all different. They belong to different Metadata Classes, they have different structure and purpose. But there is something they have in common - they all need to be recognizable. The Platform, the application developers, and the application users - all of them need to tell one object from another.
Therefore, every Metadata Object has a set of properties aimed at telling to the world who they are.
We are calling them the main properties. This is what we are going to discuss in this episode.
The Metadata Class name and the Object Name is how the Platform tells one object from another.
Whenever I need to call the object from the code, I write the Metadata Class name, dot, and here is my Metadata Object name taken directly from here.
It means that this name is, probably, all over the script, and you might have a hard time trying to change it if you need.
I can ask the Platform to show me where it's used, and here we go. We already have these three entries in our simple application.
I can try and change the name if I really need. And the Platform will do its best to help me. But there are cases that the Platform can miss and, which is even worse, there might be some false positives.
So, trust me: renaming Metadata Objects after there is any code written can cause severe headaches. Try to avoid it.
Here are some hints for you:
- Name objects wisely
- Create all Metadata Objects before you start writing any code
There are also some pretty standard rules about what the Name can and cannot be, but don't worry. The Platform will stop you if you try to misname the object.
So, the Name property is for the Platform and developers.
Another developers' property is the Comment. Use it to inform the future you what you were thinking when creating the object. The future you will be immensely grateful to the present you for that, and this will happen much quicker than you think.
All other properties are not for the Platform or developers. They are for users. They help users to understand what object they are working with and to find a command they need.
Let me start with the Synonym.
I'm going to fill out this property like this. Now I want to decouple the Products object with the forms we created to make the Platform recreate them from scratch. I also want to add the Product: Create command to the Lists subsystem.
Now, check this out. I'm running the application, and now I can see that whenever the Platform needs to mention the Products Catalog, it uses the Synonym:
In the name of the command that opens the Products List.
In the tooltip explaining what this command does.
As the Products List title.
As an explanation of what kind of object this is.
And as the name of the command to create a new object.
But sometimes I need these guys to be named differently because it will be more grammatically correct or more clear for users.
This is what these presentation properties are all about. Let me show you.
I'm going to fill out all these properties and show you how the UI will change.
Now, the UI has changed, and this is how the presentation properties got mapped to the interface.
So, we use the presentation properties of Metadata Objects to help the Platform to name them properly in various parts of the UI.