Hi Greg,
> This is probably the route I'll end up taking, but I was hoping for a
> solid (ha!) starting point. My fear is that if I borrow someone else's
> mistakes, I might be compounding the problem. We'll see what I get.
Yeah, start with something small. Like creating an UI page with a single input
field (may that be a checkbox or a form field), which does something on the
system level. And may that just be creating a temporary file with "hello
world" in it. Create the schema for your database object, a Perl handler that
writes the tempfile and a config file that triggers the handler whenever the
database object is updated. Then finally the UI page(s) for it.
A good starting point to "borrow" the code for that could be base-apache or
base-ftp for example.
As for borrowing "bad" code ... <lol>. Yeah, after a few years of working the
Sausalito code I think I've seen it all. There are plenty of way of how to do
things - some more efficient than others. And some of the original code really
shows if it was done by a master or an apprentice. Sometimes when I look at
some of the handlers or Perl modules that have Will DeHaan's handwriting on
them, then I still have to tip my hat. Some of that code is utterly splendid.
Example: There is a function in one of the original Cobalt Perl modules called
"hash_write". It deals with writing "stuff" to files. Often when you update a
config file you have to jump through burning loops to make sure that you add
all the relevant info in the correct syntax, without putting the same line
twice. And it would also be nice if manual addition to that config file
weren't overwritten either. Re-writing the entire config file from top to
bottom ain't the most stylish way to do this - of course.
Now here it really shows how ill Cobalt documented their own stuff, because
this brilliant "hash_write" function is used like only once or twice in the
entire code. For all other transactions where they write to config files they
use sub-standard methods, sometimes just re-creating the entire file with
popen() and fputs().
Why is "hash_write" so great? Well, it works like this: You put everything
that you want to add or change in your config file into a Perl Hash. Then you
call the function and pass the Hash to it, together with the delimiter that
separates switch name and value, plus you specify the character that indicates
that the line is a comment (typically "#" ). Oh, and of course the file name
of the config file to edit.
The function will then "walk" through that config file, where it replaces just
the lines you want to change. If you passed a switch that it didn't find,
it'll (optionally) add it. And it won't touch any other line in that config
file - so manual changes to other sections of said file will be retained. Or
if the config file is missing, it'll simply create it with whatever info you
had in your Hash.
The entire function is just a few lines of code and calling it is a simple one
liner. But it saves a hell of a lot of time and hassles.
> I seriously wonder if there was a Chapter 1-16 to go with the #17 I
> have (and possibly 18-26...). I wish there was one of the original
> engineers who also happened to be an information pack-rat (like me)
> who happened to keep a copy of all this stuff, for posterity.
Yeah, I'd love to take a look at those as well. :o/
--
With best regards,
Michael Stauber