Property Sets + Templates

[debussy]

debussy created Redmine issue ID 3778

Assigning a Property Set to a Template This would require an extra interface dongle somewhere in the Template editing screens that allowed you to actually assign a property set for the template (more of a hard setting than an on-the-fly setting like in Snippets & Chunks). I could very easily be wrong, but it seems like it shouldn't be too hard to just add a pop-up menu on the template editor somewhere: "Use Property Set: [list of property sets]" that the backend uses to make the property set assignment.

Use example: When developing on a dev server, each template (and there may be many) has properties which are used to generate paths on the dev server (to a template folder, for example). Then a property set with the correct values is assigned to each template. When migrating to the server, rather than changing the template property on every template, one only need change the value in the Property Set.

[splittingred]

splittingred submitted:

Actually, I think a more appropriate use for Property Sets on Templates is in the Resource layer - once you select a Template for a Resource, you can then select a Property Set to use with that Template.

[wshawn]

wshawn submitted:

Why not use a TV to house the path? Then you will only need to change that one value....

[debussy]

debussy submitted:

I thought MODx was all about "many ways to skin a cat"...

A static TV would actually work pretty well for me... but I think it says quite a bit that I never even thought of doing that (and I've been using MODx exclusively for a few years now). ...hear me out before you dismiss me as one of those guys ... hear me out, then you can dismiss me. :)

I think it's a mindset thing here—which is important. When I think of a TV, I think of Resource-specific content not Template-specific content. Yes, a TV can be set up to spit-out static content, and that's fine, but when I think of variables associated with objects, my Revo-conditioned brain wants them to be in properties. It seems to me to be messy and inconsistent to use TVs for that kind of data—that's not what TVs are for. (Now, I know that there are those MODx wizards out there—BobRay—that can finagle TVs into filing their taxes, doing their laundry, and feeding the cat, but I'm talking more here about best-practices, and what is intuitive and consistent.)

Allow me to illustrate:

(In the examples below I refer to "Instantiation" by which I mean the values assigned at the particular point when an element is actually loaded. So, for Chunks and Snippets, these would be the values assigned in the tags themselves.)

When you make a Chunk with placeholders, you set default values for those placeholders in the Chunk's Properties. When you want to use a single set of values for multiple Chunks (or multiple instantiations of one Chunk), you put those values in a Property Set. The order of precedence for setting a value, then, is:

• Chunk: Property → Property Set → Instantiation

When you make a Snippet with variables, you set default values for those variables in the Snippet's Properties. When you want to use a single set of values for multiple Snippets (or multiple instantiations of one snippet), you put those values in a Property Set. The order of precedence for setting a value is:

• Snippet: Property → Property Set → Instantiation

When you make Templates with variables/placeholders, you set default values for those placeholders in the Template's Properties. When you want to use a single set of values for multiple Templates, you put those values in a -Property Set- ... Template Variable? The order of precedence for setting a value is:

• Template: Property || Template Variable

Wait... what? ... It should be:

• Template: Property → Property Set → Instantiation

For a Template, Instantiation occurs whenever a Resource is loaded. So, setting an instation value would require something like a Resource property (as Shaun alluded to).

---

Other annoyances with using static TVs:

You are dealing with single values rather than a set of values.

• This means that you have to hack on some type of grouping scheme, i.e., naming convention, categories, etc., in order to keep track of which sets of values apply to which sets of templates... actually, after checking, Categories wouldn't help as they do not show up in the TV assignment field when editing a template.
• Editing values becomes more cumbersome the more you have as they are spread across multiple TVs--especially frustrating when there already exists a great tool for managing sets of values (the property set manager).

The bigger / more complex the site, the more difficult to manage.

• If I had, for example, 2 properties that I wanted to set on 2 different sets of templates, I would need to create 4 TVs to house all the values (as opposed to 2 property sets).
• If I had 6 properties to set on 4 different sets of templates, I would need 24 TVs to house all the values (as opposed to 4 property sets).
• If you throw in all the TVs that might be created for content on a big site and ... well, that's a lot of TVs to swim through!

(All this has convinced me to file another feature request regarding the viewing of categories on the TV tab of the template editor)

[debussy]

debussy submitted:

Addendum

Ok - I know I'm getting annoying here... but here is some more thinking on the topic...

I failed to address before that in the "Properties → Property Set → Instantiation" model, Property set assignment (for Snippets and Chunks) occurs at the same time as Instantiation. Thus, this is the point at which Shaun thinks it should occur for templates, as well, (by allowing Property creation on a Resource). This is consistent with current practice... but... it's not terribly helpful when it comes to template-dependent, resource-independent values (or other situations it turns out).

To expand the thinking here... a more accurate description of the current model would be:

• Properties → Instantiated Property Set → Instantiated Values

IF one were to add to the basic Element mechanisms the ability to assign a Property Set statically (just as one can add individual Properties statically), the proposed model would be:

• Properties → Assigned Property Set → Instantiated Property Set → Instantiated Values

Instantiated Property Sets (the only method currently available) lend themselves more to a one-to-many relationship with code and data such that you can run many different sets of data through one piece of code:

• mySnippet@dataSet1
• mySnippet@dataSet2
• mySnippet@dataSet3
• etc.

Assigned Property Sets, on the other hand, lend themselves more to a many-to-one relationship with code and data such that you can run one set of data through many pieces of code without having to specify a Property Set:

• mySnippet1
• mySnippet2
• mySnippet3
• etc.

If the "Assigned Property Set" concept were added to the Element model, Templates would just inherit this ability (if I'm reading things correctly) and fulfill this feature request. It would also open up whole new possibilities in implementing other elements. My first intuition about how Property Sets worked assumed the "Assigned" model not the "Instantiation" model, and I was disappointed when I couldn't get them to work that way and had to do a "workaround".

Anyway... I hope you guys are getting something out of all this!

[splittingred]

splittingred submitted:

Pushing to 2.2 as there's a lot to think about with this, and therefore wont be included in the 2.1 release (which is focused on multi-db, caching and TV input options).