Hi Jerry, hi Holger,
simpleSolutions.dk wrote:My suggestion is actually fully compatible with the current configuration files
Actually it is! The only problem is, that a user having an "old" version of CMSimple(_XH) might be quite confused reading in the config form:
Code: Select all
+------------------------------------------+
Theme: | green{{{select:default,red,green,blue}}} |
+------------------------------------------+
Holger wrote:simpleSolutions.dk wrote:
Using stristr or preg_mathc to request a value "green" will find the value in above string.
That's not the complete truth. What about "lightgreen" and "darkgreen" as possible options?
And even worse: stristr($plugin_cf['fictous']['theme'], 'red') will return 'red'! A preg_match('/^red/i', $plugin_cf['fictuos']['theme']) will do the trick, but that means not only the configuration but also the plugin has to be (slightly) adpated. BTW: I consider the use of stristr() a bad practise for checking, if a string is contained in another. stripos() is much more effecient -- unfortunately it's available only since PHP 5, but a simple fallback can be easily written. If the substring contained non ASCII characters a UTF-8 aware variant would be necessary anyway.
simpleSolutions.dk wrote: I do not hope that our mission is to make configuration unmanageable.
Unmanagable for whom?
- it shouldn't be too hard to implement the configuration management for the core
- the plugin author could simply ignore the "types" he doesn't consider useful
- the end-user might prefer a checkbox over a selectbox; if options will be presented as a group of radiobuttons or a selectbox should be configurable, so the user is able to choose, what he prefers; the new HTML5 input types are currently at most partially supported on the most common browsers, but that's quite likely going to change in the future.
simpleSolutions.dk wrote:Textareas?, a modern browser (expect IE) treats input fields as an expandable textarea
I'm not aware of any such browser. Perhaps you mean textareas with rows=1? Indeed these textareas are quite versatile, but they have the disadvantage that pressing return inserts a line break, instead of submitting the form, what a user expects for input fields (see
http://cmsimpleforum.com/viewtopic.php?f=16&t=3991).
Holger wrote:So what about putting the definition of the config-fields to $plugin_tx[] like it's done with the tooltips?
...
So I think using $plugin_cf is the best place to store the definitions:
I've thought about this too. But than we might use a second file as well, as this is actually more efficient, as it doesn't have to be read most of the time (never in the front-end, and only if a config form is called or saved).
simpleSolutions.dk wrote:May be we should start over and rewrite all configuration to XML
IMHO XML might have it's use, but it's a poor choice for data storage. Consider:
unknown wrote:"XML combines the efficiency of text files with the readability of binary files"
(more critique of XML can be found on
http://harmful.cat-v.org/software/xml/ and
http://c2.com/cgi/wiki?XmlSucks).
And to process XML with PHP 4 one has to use the xml extension. As it's a SAX parser it's good for processing large XML documents, but it's rather inconvenient to handle.
But anyway, changing the config format to something incompatible should better wait for CMSimple_XH 2.
Christoph