Re: mapping form fields to database and handling multiple users

At 09:39 AM 7/1/2001 -0400, Rich Bowen wrote:
>On Sun, 1 Jul 2001, Bennett Haselton wrote:
>
> > I've written a Web-based application that allows users to log in and 
> edit
> > profile data associated with their username.  Right now the application
> > consists of perl code written from scratch, and for each username, the
> > "database" storing information for that username is just a flat text 
> file.
> >
> > The perl code I've written actually does an OK job -- handling logins 
> for
> > multiple users just involves checking a username and password against a
> > text file, and then reading another text file that stores the user's
> > settings, and filling in the correct values in form fields.  Sometimes 
> it's
> > an advantage that I've written everything from the ground up -- for
> > example, I wanted to have a field in the user's settings file that
> > indicated whether the user had changed a particular setting in the last 
> 24
> > hours.  I just added new "Fieldname_HasChanged" field, and altered the
> > update code so that the new value would be checked against the old 
> value,
> > and "Fieldname_HasChanged" would be set to 1 if they were 
> different.  If I
> > had been using an out-of-the-box solution, I doubt if that kind of
> > low-level tinkering would have been possible.
> >
> > On the other hand, since I'm about to rewrite the application using a 
> more
> > scalable language and a better database system anyway, are there 
> pre-built
> > solutions already out there for handling either or (ideally) both of 
> the
> > following situations:
>
>Where you are lacking scalability is your database solution, not the
>language you have chosen. I have written, and others have writte, very
>large scale applications (web and otherwise) in Perl using the DBI
>modules. Perl is very scalable, particularly when used in an
>environment like mod_perl, which removes all the remaining things
>about CGI that cause it to be slow and unscalable.

Actually it really is perl that's causing me problems.  First there is the 
lack of a text editor that can do statement completion -- might seem like 
training wheels at first, but if you add up all the time that you spend 
looking up the name of a function you wrote and the list of arguments that 
it takes, you can really speed things up a lot with statement 
completion.  Then there is the language syntax itself -- like the fact that 
both
         ClassName::methodname()
and
         ClassName->methodname()
will compile and run, but the first one just passes the arguments to the 
function, and the second one passes the class name as the first argument, 
as a string.  Gack!  Yes, it's possible to insert code at the top of the 
function that will test for the two cases and do the right thing, but it 
seems bizarre that the language would even let each method behave as a 
static and a non-static method, depending on how you call it, making it 
necessary to put code at the top of each function to test how it was 
called, and split off in two directions depending on the result of that 
test.

Otherwise, accidentally typing "->" instead of "::" will make the program 
do something weird, instead of failing to run, the way it would in C or 
Java.  I think that to the maximum extent possible, a language should 
ensure that making a syntax error will cause the program to fail to run, 
rather than letting the program run and do something you never 
intended.  Of course, you can't catch every typo (an interpreter couldn't 
possibly know if you meant to type "+" when you actually typed "-"), but 
you should catch as many as you can.

I still think perl is great for small jobs, and it's conveniently easy to 
learn, because you can switch back and forth so quickly between changing 
your perl code, and running it on the command line to see the 
result.  (Wjile learning C and Java, I always got annoyed that every time 
you changed your code to see if you'd gotten the syntax right, it took 
about ten seconds for the compiler to get going, try to compile it, and 
finally print out the errors.)  But it just isn't scaling for me.  The 
extra brain space that you could use to make up for these problems (i.e. 
concentrating extra hard to avoid typos, or memorizing the arguments and 
names of all your functions so you don't have to keep looking them up) 
could be better used thinking about the big picture of your project while 
you're working on it.

Just my 2 yen.

         -Bennett

bennett(at)peacefire.org     http://www.peacefire.org
(425) 649 9024

HWG: hwg-servers mailing list archives, maintained by Webmasters @ IWA