Using properties and property sets correctly

I may just use TV’s for this

I don’t have real confidence when not even the development team are on the same page...

First, OpenGeek is definitely the authority here -- not me.

Second, I don’t think we really disagree on anything of substance. There’s no disagreement at all, for example, on how property sets are usually used or how they were originally intended to be used. We also agree completely on how property sets can be accessed in code and on how to get and set their properties.

I’m just pointing out that property sets can also be thought of as generic, independent associative arrays that persist across sessions and can be accessed very conveniently in code. I think it’s likely that there are some cool uses for that, although I haven’t personally found any yet.

I’m fairly confident that there are cases where they would be preferred over TVs and custom DB tables for storing simple associative data (e.g. names=>job titles), assuming that you didn’t need the rendering and input control available in TVs or the searching and sorting capabilities of a custom DB table.


To go back to the original question of the thread, to use a property set with a snippet in a particular template, as OpenGeek has suggested, you attach the property set to the snippet, then in the template you put a snippet tag for that snippet specifying the name of the property set:



The properties in the property set will then be available in the $scriptProperties array in the snippet.

I find this fascinating, as now I am getting into configurations.

In my extra, I don't want to create a CMP or any System Settings to store data for my two external 3rd party software, I want things a bit in one place for the less pro user.
I am using one MODx plugin, and I am thinking of attaching two property sets (one of which is actually a default) to this plugin that the above two 3rd party software can connect to using the MODx api whatnots.

Is this a valid use-case?

It seems like it to me, but I'm not sure it's the best way. I've put config stuff in files, snippet properties, System Settings, and chunks.

Properties (or property sets) have the advantage of providing a nice user interface for naive users. You can give them drop-down lists and Yes/No options to limit the chance of mistakes. They also give you the chance to add descriptions, explanations, warnings, and examples in the 'description' field. The down side is that they're stored as JSON strings and have to be parsed whenever you use them. You also have to get and parse all of them, just to use one.

For users who don't need as much hand-holding, I lean toward chunks, since they're much easier for me to update and transport, and easier for the users to find. You can also get all of them very fast and they're cached. The down side is that you have to parse the whole chunk and there's a greater opportunity for the user to corrupt it.

You could make a case for using System Settings with Mark Hamstra's Client Config. They have the all the advantages of properties, plus you can use the raw values and you can access only the ones you need at the time. OTOH, each time you get one, it's a separate query.

Using a hybrid method might be a good solution in some use cases. For example, you could store them in a way that's convenient for users, but you could then use them to create a cached include file (like config.inc.php). You could then just check for the existence of that file and either create it or include it.

Also, there is always MIGX.

The one place I would never put config data, is in regular TVs. They're slow and inefficient, and they're designed to store resource-specific data, which is usually not what config stuff is about.

Solid analysis!

I am almost sure that Client Config has limited xtypes, which I found distressing since it is supposed to be shadowing the System Settings, or did I get it all wrong?
Being myself a somewhat palpable user, I use Propertysets because of that nice export feature (JSON format), which Client Config (XML format) has but not the System Settings (or do I need new glasses?)

I think external files/chunks is the way to go - naive users should upgrade.

I haven't used Client Config, though I would be surprised if any xtypes are missing.