Property set values

I think I may be misunderstanding property sets, but here's my situation:

I want to have a property for each MODX element (chunks, snippets, TVs, etc) that is a checkbox. It will have a different value for each element. User should not have to "create" it for each element (and so it is not a Default Property). Essentially, I want this to function the same as TVs do for resources.

I thought that creating a property set would be the way to do this. The property is not going to be used in tags so I will never be calling it like:



So I created the property set, created a property (isTrue) as a checkbox, and its default value is No. I goto MyChunk, add the property set, set the value of isTrue to Yes, and save. The problem is it appears that this value is global in scope, and so if I try to add this property set to another element, the value is already Yes. I thought that property sets behaved like TVs do for resources--create a property that can be used across the system, with each element having its own value.

So assuming that this behavior is by design, how do I achieve a what I'm try to do, which is essentially create a TV for all elements, where each element will have its own, independent value?

PropertySets are simple sets of property key/value pairs that can be reused in various places to override (or supplement) Element default properties. These can further be overridden and supplemented by the tag property string. They are not like Template Variables at all, lacking per-Resource or per-Element values.

ok, that's what it looked like. how would i go about implementing a TV-type scenario with per-element values? I suppose I would have to use Default Properties?

OpenGeek's statement about them not having per-element values could be somewhat misleading. A value in a property set is not tied to a particular element because you can use the same property set with various elements.

Once you tie the property set to an particular element, either by specifying it in the tag, or by naming it in the Plugins System Events grid, its values will override the default properties for that element.

For a snippet or chunk, for example, doing this will always make the element use the property set's values (though they, in turn, can be overridden by properties specified with &propety=`someValue` in the tag itself):

Well put, Bob. Thanks for the clarification. You have a way with words.

So I think I have two options:
- train the users to add a default property for each element
- train/remind the users to add/apply the property set when they want to use the value

Neither is as good as a TV-approach, but it may have to do.

Mark, thanks for the kind words. It's not clear to me what, exactly, the users will be doing. For example, are they skilled PHP developers, naive clients, or something in between?

One possible scenario is to package the elements in a MODX transport package (like extras) and install the property sets, resources, templates, chunks, etc. as part of the package. They can be installed with tags that specify the property sets you create during the install.

If there will be a lot of ad hoc specifying of properties, I'd recommend just setting them in the element tags (except for plugins).

Default properties are easier to manage than property sets, but their values almost always get overwritten when a package is updated. That makes it a choice between having the users use properties in the tags (which will always have the highest priority); use property sets everywhere; or use property sets for elements in packaged extras and default properties for custom elements.

I should mention that System Settings, Context Settings, and User Settings, are another option, since they end up in the same array. They are available site-wide for use in any resource or element and have the a lower priority than the things listed above (i.e., they can be overridden by default properties, properties in property sets and properties in tags).

What we're trying to implement is a change management process. File system files are fine b/c they're managed in Git. But the db is another question. Transport package is nice b/c it's the MODX way of moving stuff around, but:
- can you "mark" certain elements for inclusion in a package on one day, then mark others on another day, so the package manifest is constantly changing?
- can you include other snippets and plugins?

If so, then we're back to "How do you include those things"? TVs? Properties? Or manually in a text file?

(I haven't worked much with transport packages yet)

Sounds to me like you need MyComponent. http://bobsguides.com/mycomponent-tutorial.html

If the packages are relatively simple, PackMan might also be an option.

MyComponent would work, but I'm not sure how well. It assumes that you're working on the same package over time. There's only one config file and editing it determines what goes in the package, but you'd have to create a new package with a new name for each new combination of components. If you can have descriptive names for the packages and would reuse them, it might be a good choice, but if you're constantly creating new configurations, not so much.

In the latter case, PackMan, which creates packages on the fly after you select the components in a grid in the Manager might be a better choice, though I don't think it packages Resources or Manager Menu options (MyComponent will).

Neither extra will package users or security/permission stuff, so if you need that they won't work for you.

MyComponent will package all MODX elements (chunks, plugins, templates, template variables, snippets, default properties, and property sets) as well as resources, system settings, contexts, namespaces, categories, and menus. It automatically handles connections between the objects (e.g., connecting resources to parents and templates, TVs to templates, plugins to their events, elements to categories and property sets, etc.). It also handles any lexicon entries you might need.

What about a combination? I'm looking at PackMan now. I can use that for bundling the various elements and creating a versioned package that looks like can be installed via MODX API (modTransportPackage->install). We have a 3rd party change management tool that handles moving files/code/data between various platforms, etc.

Then we'd have SQL run for Resources, looking for a TV value being set to indicate that resource is to be moved. Or is there a DB/SQL extra that could assist with this?