Key/Value display in Simple edit layout

(Sean) #1

Matrix Version: v5.5.6.10

Does anyone know if there is a way to display the Option Key instead of the Option Value for a select metadata field in a simple edit layout when using the %metadata-f_99999% keyword?

I’m aware of the ‘Show On Frontend’ option on the metadata details screen but it doesn’t seem to affect what is display in the simple edit layout when using %metadata-f_99999%.

EDIT
My other option for this, rather than switching the 2 around, would be to be able to use a search asset to search on the Options value rather than the Options key. However searches only seem to match on the key portion of the key/value pair.

Cheers

(Bart Banda) #2

No there’s no keyword that lets you do this. What’s the reason though? What problem are you trying to solve?

If you have to do it this way, you could use some simple JS perhaps that just copies the value into the key for the select field upon rendering of the edit layout?

(Sean) #3

Hi Bart, thanks for the response.

The reason is that I’ve set up a template so that backend users can easily update pages using the simple edit view (displayed on the content page with %metadata-f_1000%). In that template I have a metadata schema with a select field for activity types that are allowed in various areas. Each activity has an associated icon that I want to display on the relevant areas page so I have the asset id of the icon stored as well (key in below example)

eg.
Key------------------Value
1000----------------Running
1001----------------Skipping
1003----------------Flying

Each area then has a page of it’s own that displays a list of icons based on that metadata field. Done with SSJS.

eg.
Page------------icons listed
Area 1 -------- Running, skipping
Area 2 -------- Skipping, flying
Area 3 -------- Flying

Each activity also has it’s own page that has a search asset embedded and lists which activities are available in that area. So on each page a GET parameter is set and used in the search. Variable name = ‘activity’ and value = 1000 (the key in the metadata filed).

eg.
Page----------------list
Running ---------- Area 1
Skipping ---------- Area 1, Area 2
Flying -------------- Area 2, Area 3

The issue is that if I have the asset id in the key, the GET parameter needs to be this key (asset id of the icon) rather than the much more user readable value (Running or Skipping etc.). This is workable but possibly a little confusing for future maintainers as if a new icon is uploaded then the metadata field not only needs to be updated with the new icons asset id (this is fine), but the GET parameter in the relevant page also needs to be changed to match this new asset id.

If I swap around the key and value the search GET parameter is easy to understand but the simple edit layout just lists all the asset ids which isn’t workable as backend users won’t know which activity is which.

Hopefully that all makes sense.
Am I missing something really simple here as it seems this shouldn’t be this difficult?

Cheers

(Bart Banda) #4

Thanks for the explanation Sean, helps understand the issue.

I’d recommend you just use friendly names for both the value and the key then for your select field and keep the asset ID image mapping to each “activity” elsewhere, probably in some SSJS variable, because the important thing here is not the icons, it’s the value, the icons are just supplementary information, so they shouldn’t be the key data storage value IMO.

Seeing as you already use SSJS in your page implementation, this should hopefully easy to move to.

I did something similar to this actually not long ago with Squiz’s products and mapping to their logos:

var productLogos = {
  "Matrix": "./?a=18889",
  "Funnelback": "./?a=18888",
  "Datastore": "./?a=18890",
  "Connect": "./?a=18891",
  "SXC": "./?a=18892"
}

function printProductLogo(productName){
    print(`<img src="${productLogos[productName]}"/>`);
}

Depending on how you are showing the image on the frontend to, you could perhaps also use to CSS background images and keep the values of the select fields as CSS classes which then map to your different image asset background images?

(Sean) #5

Thanks Bart

I think you’re above advise is the best way to go and that’s what I would do but in our case the design has now changed and the icons are no longer needed which simplifies the whole thing.
Thanks for you help though.

Cheers