Re: freeware scripts (was Re: [MacPerl] learning UNIX concepts)

[Patrick Beart <patrick@WebArchitecture.com>]

On 11/12/98, Chris Nandor took the time to write:
>At 14.33 -0500 1998.11.12, Patrick Beart wrote:
>>	If anyone knows of other options, with respect to this issue, I
>>know of a few hundred developers on the CyberStudio list that would LOVE to
>>hear about it. Hell, we'd probably even PAY a few bucks for a decent, well
>>coded script!  I know that I would - which is why I'm trying to learn PERL,
>>BTW.
>
>What is so hard about parsing form data?  Use the CGI module.  If you need
>help, buy Lincoln's CGI.pm book.  Perhaps I misunderstand.
>

	Excellent question. Since I hate confusion - especially in myself -
let me see if I can outline the issue for you (and anyone else on the list
- sorry if some consider this post "OT", BTW):

	Parsing HTML form data is just the first step, really.  That's the
part of forms data processing that HAS to be done, based on what I've been
able to see in various PERL scripts. Otherwise the output is funky, to say
the least.
	My clients need the data (from the HTML text boxes, radio buttons,
checkboxes, etc.) sent back to them. Generally, this is most effectively
done via Email. ...The user/customer fills out the form, clicks "submit"
and the CGI script parses the data and Emails the result back to the
client/company. Sounds simple.

1)	The output of the parsed data needs to be received in a
"user-friendly" manner. Most "basic" CGI forms handling scripts ("Doug's
WWW Mail gateway" comes to mind) are so basic that the data output is
rendered in a left-justified column of ASCII - with some odd character, or
group of characters such as a colon or a dash-right angle bracket
separating the "name"/"value" pairs. This type of format is anything but
user-friendly. It's hard to read, and you can't import it into a
spreadsheet or database very effectively.

2)	Often, for my clients, some kind of low-tech "data-mining" is
valuable - especially if the form is a "feedback" form, rather than an
"order" form.  This can be accomplished by defining the ASCII output of the
CGI script as "tab-delimited", so that the client/customer can directly
import the Emailed form data into some kind of database (READ: Excel or
similar, at the low-end).

3)	Since many clients use forms to SELL products, or services, Credit
card numbers and the associated "ecommerce" issues are involved. Meaning
that a "credit card block" is included on the form, and the script needs to
do as much as possible to verify that part of the data, before it is sent
back to the client. We generally want the scrip to match the card type
(VISA, etc.) with the first number of the credit card number. (e.g. all
VISA's start with the number "4", MasterCards use a "5".)
	Going further, it's REAL nice if the script "checksums" the number,
to determine if it is a valid, issued number, rather than a made-up number
(such as 1234-5678-1011).

4)	For product purchases, seperate "ship to" and "bill to" fields need
to be in place. The script needs (ideally) to understand that the person
placing the order isn't necessarily the person who is to receive it.

5)	Perceived security issues may necessitate the use of PGP encryption
of the data prior to it being Emailed back to the company (yet another PERL
script, BTW).

	There are other, more specific "features" that a BASIC forms
processing script needs to have - I'm not talking about a "shopping cart"
program, either. I'm referring to a simple, elegant PERL-based CGI program
that a client/customer can use on a $1500 (development cost) Web site,
which sells a few (generally less than 12) items.
	I've yet to find one.

	In fact, I'm in the process of PAYING my favorite progammer $800
for a "C" program that includes the features, above. However, the fact that
the C program need to be compiled  - and that once done, no one can READ
the damn thing - dampens my enthusiam for the flexibility and control over
the product/program. Such is the nature of desperation.  (sigh)

	I have better things to do with my time (like the concept of
weekends and vacations) than trying to learn PERL, or programming in
general. However, I feel that I MUST do this - both for purposes of
improving my personal skillset, AND in an effort to FINALLY get a usable,
flexible, utilitarian script for my clients to use on their Web sites! (not
necessarily in that order, BTW.)

	Hope that this helps to clarify the issue and my frustration.   ; )


Patrick Beart

-------------------------------------------------------------------
patrick@WebArchitecture.com       503-281-4147      Portland, OR
Web Architecture:   http://www.WebArchitecture.com

* Founding MEMBER *  Internet Professionals Northwest. (www.ipn.org)
* MEMBER * Webmaster's Guild/ Association of Internet Professionals
 -------------------------------------------------------------------



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch