Creating a new system setting in Revolution

To answer that, I’d have to understand "context settings," which I don’t. There’s no "context" field in the System Settings grid and I don’t see any place in the Manager to set "context settings."

Tools -> Contexts -> right click a context, Update Context -> Context Settings tab.

Basically, context settings will override System Settings. If I created a System Setting called ’use_editor’ for the ’mgr’ context and set it to false, $modx->config[’use_editor’] will be false when the ’mgr’ context is initialized. So that means, in the manager context, my system setting of use_editor was getting overridden by my context setting.

User settings can override context settings. Basically, in order of increasing granularity:

System Settings -> Context Settings -> User Settings.

Quote from: splittingred at Oct 13, 2008, 05:23 PM

To answer that, I’d have to understand "context settings," which I don’t. There’s no "context" field in the System Settings grid and I don’t see any place in the Manager to set "context settings."

Tools -> Contexts -> right click a context, Update Context -> Context Settings tab.

Basically, context settings will override System Settings. If I created a System Setting called ’use_editor’ for the ’mgr’ context and set it to false, $modx->config[’use_editor’] will be false when the ’mgr’ context is initialized. So that means, in the manager context, my system setting of use_editor was getting overridden by my context setting.

User settings can override context settings. Basically, in order of increasing granularity:

System Settings -> Context Settings -> User Settings.

Doh (sound of hand hitting forehead).

Ok, is there any expectation that a snippet like Ditto or Wayfinder would typically have its own context and that the default properties of the snippet would be set here as context settings?

Quote from: BobRay at Oct 13, 2008, 05:36 PM

Ok, is there any expectation that a snippet like Ditto or Wayfinder would typically have its own context and that the default properties of the snippet would be set here as context settings?

No, I wouldn’t expect those snippets to have their own context, though. They aren’t really meant for that - they are cross-context tools by their nature, working at pulling resources from specific contexts that they are already in.

I think you’re wanting default snippet parameters.

Quote from: splittingred at Oct 13, 2008, 05:56 PM

Quote from: BobRay at Oct 13, 2008, 05:36 PM

Ok, is there any expectation that a snippet like Ditto or Wayfinder would typically have its own context and that the default properties of the snippet would be set here as context settings?

No, I wouldn’t expect those snippets to have their own context, though. They aren’t really meant for that - they are cross-context tools by their nature, working at pulling resources from specific contexts that they are already in.

I think you’re wanting default snippet parameters.

Actually splittingred, no, he wants a combination of system settings and snippet properties in his case that can be overridden by context settings, because he has a set of components that are related; i.e. a "namespace" to encapsulate multiple Elements, some Resources, Settings, and Lexicon strings. You would only put values in them into the ’web’ context for the front-end, ’mgr’ and ’connector’ contexts for manager UI and AJAX management calls, if values needed to be overridden or added to the configuration loaded from system settings. Basically, each request loads the system settings, then merges contexts settings for a context when it is initialized, and finally, when a session is established, and the user loaded, any user settings are then merged over those. Then when a snippet is processed, the properties would be established as follows at runtime:

1. The default snippet properties are loaded from the database object.
2. Any tag properties (or properties passed to the process() function when called via API) are merged over top of the default.
3. The properties are passed into the function call for the snippet and extracted as variables in the local scope of the snippet.
4. The snippet can then decide to set the value of a variable based on if it is already set, and if not, use a named value from $modx->config (i.e. the result of merging system, context, and user settings). This is the ternary things you describe with a little more functional grace:

And if you just use local variables instead of an array for your "config" (the properties are the config IMO), it’s even simpler:

Or, if you want to get really clever:

with that, $spfconfig would have every system, context, user and snippet configuration setting (er, property, whatever lol) at your disposal with very little effort.

And that gives me an idea for strenghtening the modNamespace concept as well. What I could do is simply make it so that you could get settings for a particular namespace by simply calling a function like $modx->namespace(’spform’); and we could automatically apply them into the properties for all Elements that are related to a namespace. I see a modNamespaceElement table in our future that will provide an alternative way to organize Elements into groups, for functional, rather than visual categorization; and with a many-to-many relationship (i.e. 1 Element can be in multiple Namespaces). This will be the functional equivalent of module dependencies in 0.9.6, except it applies to all elements by way of relation to a namespace, and the "shared parameters" are set (and potentially overriden) in the configuration.

Actually, I’m not sure what I want any more.

Assuming that I make the captcha fix we discussed, I don’t really need any System Settings except on a read-only basis, and I can already get those.

I still don’t fully understand context settings, but I’m guessing that they would automatically override System Settings when I get them with $modx->config[] (or the function that replaces that).

The two document ID parameters, I could set myself as snippet properties the first time the snippet runs. In fact, I can generate them on the fly each time it runs, if necessary, with a small speed penalty.

The handful of items I’m now doing the search and replace on, I could set as snippet properties the first time the snippet runs (if I knew how to get, set, and update snippet properties). Looking in the DB, I see that very few snippets use that field now. If I could just write the spfconfig[] array to the snippet properties field and get it in the other snippets, it would make things a lot easier and more efficient. $obj->getProperties($array) and $obj->setProperties($array) would come in real handy (as would $obj->getProperty(’key’) and $obj->setProperty(’key’,$value) ).

The only other thing that’s really missing is a GUI for the snippet user to set the values the snippet uses (and maybe override them with parameters in the snippet call). I’ve created a clumsy version of this with my config chunk/snippet. And, for snippets that could be used multiple times on the same site, like Ditto and Wayfinder, it would be cool to have a way of having multiple sets of snippet properties -- though maybe that’s asking too much. Just having a GUI for the *default* snippet properties would be a big step up, IMO.

Quote from: BobRay at Oct 13, 2008, 09:50 PM

The only other thing that’s really missing is a GUI for the snippet user to set the values the snippet uses (and maybe override them with parameters in the snippet call). I’ve created a clumsy version of this with my config chunk/snippet. And, for snippets that could be used multiple times on the same site, like Ditto and Wayfinder, it would be cool to have a way of having multiple sets of snippet properties -- though maybe that’s asking too much. Just having a GUI for the *default* snippet properties would be a big step up, IMO.

A GUI for the snippet user to set values for a snippet? Like, on a per-resource basis?

As for replicating the snippet default properties GUI in 096, I’m working on something for it, and should have something in the next day or two.

Quote from: splittingred at Oct 13, 2008, 10:28 PM

A GUI for the snippet user to set values for a snippet? Like, on a per-resource basis?

For starters, that would be great if it just set the default properties and the four object methods I mentioned above were implemented.

Ultimately, it would be nice to have a way to set multiple "per use" sets of properties and use a snippet parameter to determine which set applied, but I don’t see that happening any time soon.

As for replicating the snippet default properties GUI in 096, I’m working on something for it, and should have something in the next day or two.

What? Take away another reason to migrate?