Wiki source for GeneralWikkaConfiguration
=====General Wikka Configuration=====
What do we need config files for? Why do we need additional table columns in the database?
These were the questions I had, browsing through some of the extensions for Wikka. Most time I noticed, that the config file is abused for storing settings that should be user configurable but seemingly the author hesitated to add an additional column in wikka_users -- resulting in a mere globally configurable option.
In the most extreme minimilization of file stored configuration there would only be the database access stored -- any other configuration might be stored as a wiki page. And why shouldn't we? Configuration is passive data, there's no logic inside, that requires PHP's built-in source acquisition mechanisms (##include## and ##require##). We could even store the configuration in the form we have today as a wiki page and access it via the ##/raw## page handler -- currently it's little more than a string. Actually, at the moment Wikka's configuration is stored as a PHP array, thus including it suffices to use it. This process would be a little bit more complicated if we were to use wiki config pages: First we had to access the config page and afterwards evaluate it.
But there's more benefit: Once we store Wikka's configuration as a wiki page we have almost all we need to store user configuration as a wiki page. 'Almost' because there must be some thinking about which global settings might be overridable by users and how to tell Wikka which ones are allowed to override. There are different ways of doing such:
~-Like in CSS we could mark configurations as important and not to override
~-Like in OOP we could declare some private, non-overridable and non-useraccessable settings and some public, overridable and useraccessable settings in different blocks
First, Wikka would apply its own configuration then it would look for user's config. It should **ever** check, which settings might be overridden -- I don't trust us getting it done in a way, where such thing might not happen :-).
Of course, Wikka config page should only be writable by Wikka admin, and user config pages should only be writable by admins and the corresponding user. If those pages can be read by the public might be up to admin and user.
====Clean definitions====
I'd suggest (completely altruistic of course ;-)) to define config pages using TypedPages.
====More uses====
Page specific configurations are imaginable. Currently the process of a wikka_pages row looks like:
~1)Get row
~2)Call actions/header.php
~3)Call formatters/wakka.php
~~a)Call any action that resides on the requested page
~~b)Check for every internal link if page exists
~4)Call actions/footer.php
~5)Send HTML output
This forbids to specify any page-specific modification of the delivered HTML page's ##""<head>""## -- and there are a lot of uses:
~1)Custom CSS
~2)Meta data: ##""<meta>""##
~3)Page related JavaScript
The best about this is, that it doesn't clutter up the page source with obscure and most boring techno-babble (you know: ""{{action para1="obscuresetting" para2="pathtostrangefile" para3="TLA"}}"") if we'd move such stuff to a dedicated page.
What do we need config files for? Why do we need additional table columns in the database?
These were the questions I had, browsing through some of the extensions for Wikka. Most time I noticed, that the config file is abused for storing settings that should be user configurable but seemingly the author hesitated to add an additional column in wikka_users -- resulting in a mere globally configurable option.
In the most extreme minimilization of file stored configuration there would only be the database access stored -- any other configuration might be stored as a wiki page. And why shouldn't we? Configuration is passive data, there's no logic inside, that requires PHP's built-in source acquisition mechanisms (##include## and ##require##). We could even store the configuration in the form we have today as a wiki page and access it via the ##/raw## page handler -- currently it's little more than a string. Actually, at the moment Wikka's configuration is stored as a PHP array, thus including it suffices to use it. This process would be a little bit more complicated if we were to use wiki config pages: First we had to access the config page and afterwards evaluate it.
But there's more benefit: Once we store Wikka's configuration as a wiki page we have almost all we need to store user configuration as a wiki page. 'Almost' because there must be some thinking about which global settings might be overridable by users and how to tell Wikka which ones are allowed to override. There are different ways of doing such:
~-Like in CSS we could mark configurations as important and not to override
~-Like in OOP we could declare some private, non-overridable and non-useraccessable settings and some public, overridable and useraccessable settings in different blocks
First, Wikka would apply its own configuration then it would look for user's config. It should **ever** check, which settings might be overridden -- I don't trust us getting it done in a way, where such thing might not happen :-).
Of course, Wikka config page should only be writable by Wikka admin, and user config pages should only be writable by admins and the corresponding user. If those pages can be read by the public might be up to admin and user.
====Clean definitions====
I'd suggest (completely altruistic of course ;-)) to define config pages using TypedPages.
====More uses====
Page specific configurations are imaginable. Currently the process of a wikka_pages row looks like:
~1)Get row
~2)Call actions/header.php
~3)Call formatters/wakka.php
~~a)Call any action that resides on the requested page
~~b)Check for every internal link if page exists
~4)Call actions/footer.php
~5)Send HTML output
This forbids to specify any page-specific modification of the delivered HTML page's ##""<head>""## -- and there are a lot of uses:
~1)Custom CSS
~2)Meta data: ##""<meta>""##
~3)Page related JavaScript
The best about this is, that it doesn't clutter up the page source with obscure and most boring techno-babble (you know: ""{{action para1="obscuresetting" para2="pathtostrangefile" para3="TLA"}}"") if we'd move such stuff to a dedicated page.
