powerhouse has asked for the wisdom of the Perl Monks concerning the following question:

I'm sorry, but I would like all of your opinions AGAIN ;o)

Here is what I'm trying to do... I have an Admin interface that is secured by one way password encryption, which I know can not stop a determined hacker... anyways, I did have a file get required:
require "/home/path/to/congif.dat";

[download]
That file contains a whole bunch of variables, that are for several purposes... some of which are for all the colors, font attributes and things such as that.

I created this site using MySQL. I wanted the admin interface to be able to edit those variables, but that would not work, as long as they are apart of the config.dat file. so I created a Table for those variables. Two fields. the first is the "name", second is the "value".

I created a subroutine that I can pass the "name" of the variable to and it will return the value of that variable in the table.

My question to you is this. Would you do it like that, or do you think it would add more time to the page loading, since every variable would have to run that subroutine to get the value of that variable?
How would you recommend doing it(how would YOU do it)?

I really do appreciate your feedback, and advice.

Thank you, so much.
Richard

Replies are listed 'Best First'.
Re: Another Opinion Request...(config file)
by edoc (Chaplain) on May 12, 2003 at 05:30 UTC

    I'd probably be inclined to keep the config as a perl hash in a separate file and build an admin facility that allows the editing of the variables in it.. see Modperl Guide - Writing Configuration Files. This has some great stuff even if you aren't fortunate enough to be using mod_perl.

    At the very least, and for minimum extra effort for where you are now, write another sub that returns a hashref of all the config variables. At least that way you can let MySQL fetch them all in 1 query.

    cheers,

    J

[reply]
Re: Another Opinion Request...(config file)
by draconis (Scribe) on May 12, 2003 at 13:48 UTC
    I would add one field to the file - a "type". This way you can arrange the variables in a grouping and fetch the entire group - and then massage them to your hearts content.

    When loading the page - you just need to grab the group and perform whatever initializations you would need to do at that time.

    The admin facility would simply load the group and allow for modifications of their values.

    Now, one nice this about taking this approach is that you have created a simple dynamic table - let's say in the future you need to extend a table say - customer - and add a field. Normally you would have to have the DB Admin create the field and roll in the change. Now, however, you can extend that table (type=customer) and store the field name (name=lastVisitDate) and the value (value="whatever time value you want to store"). Now, viola, you can dynamically add fields to tables until such time in the future when a DB change can actually take place. Don't forget to tag your code so that you can find which programs need to be changed in the future - if you do it with some planning up front - a simple search and replace may be all that you need!

[reply]
      draconis, I don't really know what you mean, can you explain a little more?
      I'm sorry, but you lost me ;(

      Thank you very much!
      Richard
[reply]
        Let me see if I can make this a bit more clear. After your comments I can see how you might have been confused. Now, after 5 hours of meetings, this might get more confusing but lets hope not.

        By adding a field to the table that you want to store your generic "name" and "value" fields into - you increase it's ability to accept values for different reasons exponentially (or is it geometrically?). My suggestion is to add another field - call it "type". This new field would contain a value that you could use to group all your variables together with. Kinda like tieing a bunch of sticks together so that when you grab the bunch your get them all - same idea with the data fetching routine - grab them by "type" not by variable name. If you do this you limit the Disk I/O and optimize the use of buffering available for which ever data base engine you are using.

        This new field now groups all your variables - you fetch them (using your WHERE clause by including the new "type" field). Once you have all your vairables - you can allow the user to alter them in any fashion you wish. Or for that matter, the program can alter them in any fashion it wishes.

        Ok - with that understanding - now you can extend any database table without having to specifically add new fields to existing tables - you simply add data to an already existing table - this new data allows you to group, identify and quantify the new field data. So - for instance - there is an already existing table named MonthlyStats - you need a field for MeanSales - you simple add a record in the the "other" table (the one you added "type" to) type = MonthlyStats, name - MeanSales, value=1,200,000.00.

        If you add some "smart comments" into your code where you place these "hooks" - you can then later search and replace this code with code that looks at the parent table (the one you extended) - this of course assumes that the "quick fix" you did to avoid having to bring the database server down for maintenance to add a field earlier has at some point been done. Oh yeah - you would have to create a data migration utility to take the data from one table to the parent.

        If this is still confusing (as I'm sure it is) - just drop me a note and I will forward you my phone number. Maybe I can explain this better in that context.

[reply]

Back to Seekers of Perl Wisdom