My Email Response
(with some text added later)
"Thanks for the comments. I'm actually very
well aware of all the issues that you mentioned. When
I port FutureSQL to mod_perl, I intend to resolve most of those issues.
(I have at least 15 books on Perl, so I have a number
of excellent resources on hand [and yes, I have a
lot to learn :-)].)
I use CGI.pm for some html -- I don't believe that
it's a requirement for good coding, in all cases (using
it for all html output). I use it for popup_menus
and other things as well as the primary function of
capturing form values. I think it's mostly a matter
of taste or the required purpose.
(In a similar vein, one could argue that using
strict referential integrity with related data tables
(removing all duplicate fields) is the only way to
go. However, in web applications, sometimes it's better
and faster to copy a value from one related table
to another, to make coding or usage simpler. An interesting
discussion :-)).
I didn't use 'my' and 'use strict' in FutureSQL,
primarily because of the way I structured it originally,
using hashes of hashes in dictionary and setup files,
and what I perceived (then) as the need for global
variables. I'm planning on reviewing and reworking
that concept soon, to accomodate mod_perl.
I also started programming that way years ago because
I came out of the Clipper Summer '87 / dBASEIII+ realm,
and I was comfortable with procedural programming
using globals. (I still have to make the long jump
to OOP -- I think I really like procedural programming
better.)
I do try to make a lot of effort to program in a
clear and 'self-evident' fashion, using variable and
subroutine names that are easy to understand (e.g.
$report_subhead instead of $rs). I also try to focus
on clarity of programming logic and hopefully efficient
and clever ways of doing things, as well as programming
in error checking.
I suppose programming is much like writing (I'm also
a writer). One can't really have
confidence in one's writing until enough people validate
it. One doesn't want to be a legend in one's own mind.
:-)
However, your points are correct, and restricting
variables is certainly necessary when I port things
to mod_perl. Of course, it's also better programming
in general, since you don't have to worry about variable
conflicts.
I use 'no strict refs' because of my heavy use of
symbolic references in hashes of hashes and hashes
of subroutines, in the dictionary and spec files in
FutureSQL, as in this example of code from FutureSQL:
for
$attrib_name ( keys %{$s_spec{action}{$a_}} )
{
$attrib_value = $s_spec{action}{$a_}{$attrib_name};
$$attrib_name = $attrib_value;
}
.... where I create variable names and then set
the values to them.
To comply with 'use strict' and 'my' will require
acres of work in re-coding, since every single subroutine
will have to be retested, which is why I've delayed
doing that. However, making it work with mod_perl
is high on my todo list, so I'll get around to it
eventually. Again, thanks for your comments."
Feedback is welcome
I appreciate feedback very much, so if you have any
clever ideas about how to accomplish certain things
in a better fashion, let me know. For example, in
FutureSQL, for session ids, I use a
certain programming method. I'd very much appreciate
constructive review of the security method that I
employ in those subroutines (see Security.txt).
Also, in my effort to port FutureSQL to mod_perl,
I'll be taking a long look at the hashes of hashes
and hashes of subroutines method that I use in data
dictionaries and spec files.
My todo list includes the following:
1. comply with mod_perl (Registry)
requirements, including 'use strict', 'my', taint
checking, warnings, etc. Rework the method of
loading dictionary and spec files ('require')
to accomodate mod_perl.
2. Optimize the data dictionary
and spec file loading method to make joined table
queries faster (a script issue, not a MySQL issue
-- loading dictionary files over and over for
joined tables takes too long).
(Item 2 above
has been finished, and the script is *much* faster
because of it.)
3. Do a thorough security review
of the scripts, focused on form input and taint
checking.
4. Adding functionality and simply
making things cleaner and better.
5. Creating a web-based installation
and setup interface for non-programmers.
Conclusion
I've released my code as Open Source because of a
desire to give back to the Perl community, since I've
been so greatly helped by the existence of Perl as
an Open Source language (and MySQL -- hooray for Monty
and crew!). However, I'm not Larry Wall (the author
of Perl -- what a genius), and as the above text illustrates,
code can always be improved.
My Open Source code has been used in various production
environments for quite awhile. If anyone finds things
to improve, please do email me at
peterbrown@worldcommunity.com.
In addition, also note that as in most Open Source
code, there is
No Warranty expressed or implied.
