To : opendb-devel@lists.sourceforge.net 
From : "Jason Pell" <jasonpell@hotmail.com>
Subject : [Opendb-devel] Re: Moving OpenDb configuration into table.
Date : Mon, 25 Mar 2002 02:53:03 +0000
 

Hi,

I am considering how this will be achieved.

First of all what of the current configuration would not be
defined in the table.

Would be leave just the database information?  What about
such things as proxy config and $use_php_mail which would
be the same across the whole php installation?

Should we have the concept of a 'root' site which hold all
the global information, and then a set of variables for
the particular site itself?

To avoid repeatedly querying this information, it would
need to be saved as part of the session as well.

Heres my first try:

CREATE TABLE s_site_conf(
  site VARCHAR2(30),
  varname VARCHAR2(50),
  varvalue VARCHAR2(100)
);

What is a problem here, is that all
the variables would be lumped willy
nilly onto the configuration maitenance
page.

A better solution would be:

CREATE TABLE s_site_conf(
  site VARCHAR2(30),
  s_cfg_section VARCHAR2(30),
  varname VARCHAR2(50),
  varvalue VARCHAR2(100)
);

the s_cfg_section would have values such as:
  'listings', 'item_input', 'item_display'
  'search'

In fact the names of the arrays in the current
configuration file could be used.

If we wanted to make the whole thing automated,
a s_cfg_section table would be useful:

CREATE TABLE s_cfg_section(
  s_cfg_section VARCHAR2(30),
  description VARCHAR2(100),
  order_no tinyint(3)
);

Then the configuration page could be layed
out according to the order_no, and the
description could be included in each block
to let the admin know what section is involved.

The only other issue I see with this structure
is that there is no variable level comments for
what the config variable actually does.

So perhaps a further modifications is required.

CREATE TABLE s_site_conf(
  site VARCHAR2(30),
  s_cfg_section VARCHAR2(30),
  varname VARCHAR2(50),
  description VARCHAR2(100)
  varvalue VARCHAR2(100)
);

This assumes that all s_site_conf values would be
populated initially with defaults, and would never
be deleted, to maintain the system defined description
of the field.

The effort to convert OpenDb to use $HTTP_SESSION_VARS
for configuration is considerable, but will also
result in benefits, because it will be clear what the
variables are for, whereas to date a array variable:
  $email['...']

... might be accidentally reset in code quite by
accident (Which has happened once or twice)

The format of a site config variable would be:

   $HTTP_SESSION_VARS['site-config']['section-varname']

So that one high level array $HTTP_SESSION_VARS['site-config']
would be created with everything underneath.

I am not sure whether it would be useful to further
discriminate thus:

   $HTTP_SESSION_VARS['site-config']['section']['varname']

I think this is overkill in the extreme...

The way that things would be structured, would be as follows:

  A reserved site 'root' would have all configuration that
  does not change, as well as admin defined defaults for
  new sites.

  Then the particular site would have the chance to override
  particular variables.

But once both the 'root' and particular site have been queried
it would result in a single array $HTTP_SESSION_VARS['site-config']
session variable.

This functionality would be added to OpenDb itself, and users
would modify a single 'default' site only.

I have not taken into account any of the other issues related
to supporting sites as yet.  Just the configuration at this point!

How does this all sound?

Cheers
Jason
-- 
Vegan Philosopher Programmer

