Re: mapping form fields to database and handling multiple users
by Bennett Haselton <bennett(at)peacefire.org>
|
Date: |
Mon, 09 Jul 2001 06:02:25 -0700 |
To: |
<hwg-servers(at)hwg.org> |
References: |
speakeasy |
|
todo: View
Thread,
Original
|
|
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