Design questions about the use of System Settings

It occurred to me that snippet parameters could easily be re-born as System Settings in Revolution.

At first, I thought this was a terrible idea because it could crap up the System Settings table (a la Windows Registry). Now that System Settings have a namespace and can be easily included in a package, however, it seems much more feasible.

SPForm, for example, has a ton of parameters that can make for an awkward snppet call with lots of potential for typos. Most are yes/no parameters that would be easier for the user to set and edit in the System Settings grid. Currently, the user sets them by editing a file (assuming that he or she can find it).

For some snippets (especially the simpler ones), it might be a lot easier to just look in the System Settings grid under the appropriate namespace and do some quck edits than to try to find the parameter list, find the right parameters, and then load up the page(s) with the snippet and edit them.

For snippets that will be used multiple times with different parameters, obviously, the traditional way is better.

Snippets that used both methods would be a little more complex and slower because they’d have to check for a sent parameter (which would take precedence) and then use the system setting if no parameter is sent (and I suppose there’d still be a default in case neither is set), but users could more easily see the default settings by looking at the System Settings.

So I guess my question is -- are we encouraging or discouraging the practice of using the System Settings this way (or are we neutral)?

IMHO, the problem with using System Settings, which are overridden by Context Settings and User Settings remember, as parameters for snippets, is that the entire site is then burdened with data that does not apply across the whole ’System’. Namespaces are currently just a convenient way to organize Settings (System, Context and User) that will apply across a set of components that make up a complex Add-on or Core Extension. The use of Settings in this way will be much more common on core extensions that consist of multiple components meant to work together or possibly in Plugins that apply across Contexts or at least across all Resources in a site.

This is not to say that components shouldn’t ever use the Settings aggregated from System, Context and User, but this really needs to be evaluated based on the requirements of a particular solution.

Quote from: OpenGeek at Aug 30, 2008, 11:59 AM

IMHO, the problem with using System Settings, which are overridden by Context Settings and User Settings remember, as parameters for snippets, is that the entire site is then burdened with data that does not apply across the whole ’System’. Namespaces are currently just a convenient way to organize Settings (System, Context and User) that will apply across a set of components that make up a complex Add-on or Core Extension. The use of Settings in this way will be much more common on core extensions that consist of multiple components meant to work together or possibly in Plugins that apply across Contexts or at least across all Resources in a site.

This is not to say that components shouldn’t ever use the Settings aggregated from System, Context and User, but this really needs to be evaluated based on the requirements of a particular solution.

Excellent point. I guess the only way it would make sense is to have another table of "auxilliary settings" with namespaces and foci that could be loaded like lexicon entries are now (with a separate grid in the manager). That would also allow snippets that were used multiple times with different parameters to have separate foci for each instance.

Isn’t this where you would use the ’default properties’ tab of the snippet itself? The GUI for the properties tab could perhaps be brought more inline with the rest of the manager (ie use a grid where you can add/remove properties) ?

My personal preference is to have each element have its own configuration in a known standard location associated with the element’s other files (much like language files tend to be, or like the assets/wayfinder/configs/ folder).

Quote from: sottwell at Aug 31, 2008, 01:17 AM

My personal preference is to have each element have its own configuration in a known standard location associated with the element’s other files (much like language files tend to be, or like the assets/wayfinder/configs/ folder).

Revolution is more of a GUI operation (like it or not ). The language files are there, but you can edit them very easily from inside the Manager in "Lexicon Management." Installing components like Wayfinder is now done in the Manager with a few clicks rather than pasting code and copying files. So it’s not too far fetched, then, to think that setting a snippet’s default parameters could follow the same model.

TobyL’s suggestion could dovetail nicely with yours. If the defaults were in a standard location (e.g. assets/wayfinder/config/wayfinder.cfg.php) , there could theoretically be a grid to edit them.

I definitely agree the properties entry should be a grid where you can add and remove properties, but this has no relation to namespaces or lexicons or settings.  These are distinctly Element properties.

As for the properties being set in external files, that’s up to each component if it wants to include a file to set properties, though I dare say it is less accessible to have the properties kept in a file, and additional overhead to include the file on each call of a snippet (vs. just getting the properties from the tag and/or database row as it does currently).  I personally do not like this approach myself; I feel it has been used as a popular workaround for not being able to pass content through property values in the tags.

Quote from: OpenGeek at Sep 01, 2008, 10:23 AM

As for the properties being set in external files, that’s up to each component if it wants to include a file to set properties, though I dare say it is less accessible to have the properties kept in a file, and additional overhead to include the file on each call of a snippet (vs. just getting the properties from the tag and/or database row as it does currently). I personally do not like this approach myself; I feel it has been used as a popular workaround for not being able to pass content through property values in the tags.

In the case of SPForm, it was done as a workaround for not having a grid to edit the properties.

SPForm is really three separate snippets and they need access to a long list of properties. Rather than make the user type them all in three times (probably with some typos) going back and forth to the docs as they do so, they just do a quick edit of the config file (where they are all explained in comments) and call the snippets with no parameters. It also keeps sensitive parameters like the SMTP username and password out of the communication stream and allows the files that contain them to be kept outside the site structure as an option.

I look forward to creating a tab or panel in the manager to set them all.