Alex,

I gather the order of things is:

Config.pm
ConfigData.pm
globals.txt

I have about 4 dozen "custom" tags I use from site to site, and which are
things I'd like to "incorporate" into the basic configuration, rather than on template basis.

I use set options to build other options, etc.

Which file should be edited? And how should these configurations be added.

For instance, I want to install a set of color tags.

I use:

<%color1%>
<%color2%>
<%color3%>
<%color4%>
<%color5%>
<%color6%>
<%color7%>
<%color8%>
<%bg_white%>
<%ff_white%>
<%bg_black%>
<%ff_black%>

Across all the sites. I would like to add an option page for "Colors". -- In a way divide up into pages the sections of the ConfigData.pm file.



In looking around, all this is "hard coded"

Why isn't it dynamically generated? using the templates?

If all the information is added to the Config.pm file, then the HTML templates could be dynamically generated just like the Links records are.

Rightnow, the HTML page is a series of :

Types of tags.

If the Config.pm record was changed to be a hash of hashes, or arrays, such that:

$self->{tag_name} = ['value', 'description'];

A Config record would then look like:

$self->{color1} = {value => '#ffffff',
description => 'Color for the background shading on the main page'};

You are already doing this for several of the options, and I wonder it can't be expanded, and make the whole menu system self generating??

It would prevent a host of errors, and loads of redundant work, and changes, since only the Config.pm file would have to change, all the other files get updated on the next generation/iteration.

I might be missing something.... but Since these data are used to generate configuration files, why not make the 'setup' stage as easy and foolproof as possible??




http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/