Hi, I'm reading the schemas manual and playing around with the options but I totally don't get the hierarchy metadata field. It sounds like you can organise a select field with levels, or something, but the manual doesn't explain how you make these different levels or provide a picture of a finished end product.
Has anyone got an example I can see, or explain what the purpose of this is and how I can use it? I feel like it could be very useful to me if I could just sort out what it is supposed to do!
You're not alone, we had trouble understanding where the hierarchy is actually coming from. It's always been a problem with the matrix documentation: lack of practical examples to help clients. With the manual site there is a perfect opportunity to provide working examples.
I'll try to explain how it seems to work on our dev 3.28.0 system.
First set up your metadata schema with a field type of Hierarchy.
Click on Edit metadata field.
Go down to the bottom and change Display Type to Drill-Down View and commit that. It'll help you see the hierarchy take shape in the Settings block of this screen where it shows a Preview of the hierarchy.
The settings block is where you enter your metadata in key/value pairs. The Key is what is displayed in the HTML of your site (and must be unique to this metadata field) while Value is what is displayed on the metadata screen of an asset (it does not need to be unique and you'll see the hierarchy preview using the value as you enter pairs).
The hierarchy builds based on key which needs to start with a letter. Matrix looks at the keys and seems to try to find keys that start with the exact match for other keys. When it finds matches it tries to create a hierarchy from those and if none is found it just presents a textbox with each option value listed to choose from. Where it finds matches it creates a dropdown selector and you get an option appear at the bottom of the metadata field screen to label the level. So to usefully create a hierarchy you need to think about the keys you use and build them from each other.
Example:
Suppose you wanted to represent the personnel level within a business using metadata. You have the Big Boss, Managers, Supervisors and Workers, a pretty typical hierarchical structure. Lets assign a letter to each of those levels and use two numbers to represent each individual at the same level, we'll use these as the unique Option Key.
So we have Big Boss as A01.
For the Managers to appear under the Big Boss in the hierarchy we need ALL their option keys to start with A01.
Manager 1 becomes A01B01
Manager 2 becomes A01B02
etc
For the supervisors to appear under their respective managers in the hierarchy they need to start with the same option key for thier particular manager.
So Manager 1 has two supervisors they manage: A01B01C01 and A01B01C02
and Manager 2 has three supervisors they manage: A01B02C01, A01B02C02 and A01B02C03
Likewise each Supervisor has workers they manage and the workers option keys also need to start with the exact match for their specific supervisor.
Eg: the fourth worker who reports to the second supervisor who reports to the first manager would have the option key of A01B01C02D04
So anything that can be represented by a hierarchy can be stored in this way, product catalogues, site structure, etc.
hope this helps.
I… kind of get it… I mean, I guess it's working now…
Thanks! Maybe if I sleep on it…