Gossamer Forum
Home : Products : Gossamer Links : Discussions :

Standard Options

Quote Reply
Standard Options
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 :

Code:
<tr>
<td width="100%" colspan="2"><font face="Tahoma,Arial,Helvetica" size="2">Links
SQL Debug Level. This will display debug information into the error
logs, and also show debug information on any fatal error.</font></td>
</tr>
<tr>
<td width="16%"><b><font size="2" face="Tahoma,Arial,Helvetica">debug_level</font></b></td>
<td width="84%"><font face="Tahoma,Arial,Helvetica" size="2"><input type="text" name="debug_level" value="<%cfg_debug_level%>" size="40"></font></td>
</tr>
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/

Quote Reply
Re: Standard Options In reply to
Expanding on this, I should be able to add a

Code:
sub default_colors {
# ------------------------------------------------------------------
# Set the default site colors.
#
my $self = shift;
$self->{color1} = {
type => ['text', '10'],
value => '#ffffff',
description => 'Color for the background shading on the main page'};
$self->{color2} = {
type => ['text', '10'],
value => '#afafaf',
description => 'Color for the background shading on the main page'};
$self->{color3} = {
type => ['text', '10'],
value => '#ffffff',
description => 'Color for the background shading on the main page'};
$self->{color4} = {
type => ['text', '10'],
value => '#ffffff',
description => 'Color for the background shading on the main page'};
$self->{color5} = {
type => ['text', '10'],
value => '#ffffff',
description => 'Color for the background shading on the main page'};
$self->{color6} = {
type => ['text', '10'],
value => '#ffffff',
description => 'Color for the background shading on the main page'};
}
Which would set up each of the tags, read the "type" parameter, and display them as:

<input type="text" size="10" name="color1" value="#FFFFFF">

Or, in whatever format the "type" parameter defined.

It would really seem to me that having the program do all the HTML generation, would save countless hours of frustration on the development side, and millions of hours on the implementation side <G>

Adding a new tag could be pick the type of field (text, checkbox, radio, etc) and then enter the default parameters for that type of field.


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

Quote Reply
Re: Standard Options In reply to
I was toying with this idea early on, but ran into some implementation problems. I still do think it's a great idea, basically an "Auto Config" that will take a config file, and build a web interface for it. There would be enough information in the config file to make it descriptive and useful enough for different type of form fields, etc.

Let me see what I can do..

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: Standard Options In reply to
I realize this is a diversion of sorts, but from past experience, the problems with having separate web pages to display the "supposed values" from the configuration, rather than the _real_ values from the configuration can lead to nightmarish problems on both the development and implementation ends.

Since you do have some great codes for parsing and using anonymous arrays, hashes, and HOH HOA's , the time is now to bite the bullet (and maybe after the time has passed, the configuration will become clear).

As someone who has at least a half dozen sites deployed, I see some issues that others may not have (things that apply to code reuse and configuration standardizations).

Taken to it's final version, it would be a mirror image of the plug-in system, where adding a configuration page to the program is just adding a new "sub default_something" to the Config.pm.


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

Quote Reply
Re: Standard Options In reply to
In Reply To:
I realize this is a diversion of sorts, but from past experience, the problems with having separate web pages to display the "supposed values" from the configuration, rather than the _real_ values from the configuration can lead to nightmarish problems on both the development and implementation ends.
Not sure I understand this. When you click on a setup page, the values you are seeing are the real (?) values taken from your ConfigData file. What do you mean by "supposed values"?

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: Standard Options In reply to
Ok,

The Config.pm has a hash, that is passed as $self->{value}

But, to display that hash, there is a hard-coded, line by line, HTML template.

If there are two values in the Hash, such as "Contact_Name" and "Contact Name",
or Email and email, or even something like User and Username, this will be an IMPOSSIBLE bug to track down, because the _display_ option is hard coded into templates, not auto-generated.

So, you have three sources for error in template parameter:

<TD>This value is "Contact Name"<TD>
<TD><input type="text" value="contact_name" name="<%Contact_name%>"></TD>

See what I mean??

If this was auto-generated, the key('value') would be used for the name of the field, and the description line, and the value would be inserted correctly in each of the fields as "Contact_Name" or <%Contact_Name%> (the tag name, or the tag value).

If there are 100+ tags, there are 300+ sources for errors that will be impossible to track down. What you _THINK_ is going on, isn't, because the HTML adds a translation (potentially inaccurate) to the whole proces.

Is this clear??

It's like the add.html vs the Validate routine. The Validate displays the link record by auto-generating the table of values from the key/value pairs directly.

The add.html is a hard-coded list of template tags, that I know I've had a bunch of problems getting in sync with the reality of life through the various generations and modifications of my sites.

ooops... actually four sources of error, because you might "assume" that Username is what is in the Config, but you are using "User" in your template, and with auto-vivification and other such "features" of perl, this can get nasty. Much better if the _actual_ list of passed parameters were displayed fully, and accurately, by self-generating the HTML, rather than "assuming" what you expect to be passed, and passing back something the program isn't really expecting.


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

Quote Reply
Re: Standard Options In reply to
Ah, I see what you mean. A couple points:

All config options are loaded with:

<%Links::config_vars%>

and are prefixed with cfg_. So you don't need to worry about a config option Username conflicting with your links Username field.

Also, right now users are not meant to add to the config. That's what plugins and template globals are for. Plugins have their own built in options storage/retrieval. If you go to Plugins->Plugin Manager->Edit for the SearchLogger (assuming it's installed), the SearchLogger has two options (just foo and bar right now, more testing it). These are separated from the main system config.

I do agree though that it needs a more sophisticated form building system, and for future changes, the form builder would be nice for the main config as well (HTML isn't nearly as fun as perl is). =)

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: Standard Options In reply to
<G> I do a _LOT_ of things I wasn't meant to ;)



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