[UFO Chicago] web development opinions needed.

[Richard Lynch]

On Sat, September 23, 2006 2:27 am, Greg Groth wrote:
> After I sent this, I realized that I probably should have included
> some
> more details.  I'll try to keep this brief.  The apps are mostly CRM
> apps, tracking contacts, appointments, sales leads, that kind of
> stuff.
>   The other big thing is to upload a list of customer part numbers,
> and
> generate quotes based off of the list.  A dynamic form is created for
> end users to make needed modifications to the data to produce the
> quote.

PHP eats this kind of stuff before breakfast. :-)

You may even be able to find at least part of the CRM stuff "out
there" to just take.  Certainly worth checking out the existing ones
to see what you like/hate about them.  And mostly being Open Source,
you can always figure out how they did what they did, and do it the
same, or not, as your preferences see fit.

>   Worst case scenario I've seen is a form to generate a quote that
> contained 8500 form elements.

Whoa.

If you intend to build an HTML page with 8500 elements, it doesn't
make a dang bit of difference what language you write it in.  IT WON'T
WORK.

The *browser* is gonna puke on your pretty blue suede shoes somewhere
closer to 50 or 100 FORM elements.

And your users will abandon you even faster.

Re-think the design.

Let me search for the pieces of kit I need, and then you tell me the
price on what I picked, like a traditional shopping cart -- You hand
me a 8500 blank form, and I'll just go down the road to the other guy
to buy.

> Apps are pretty much record adding, editing and deleting except for
> the
> following:
> 1.) Scrape data from Excel files (no formatting), and insert into
> database - preferably natively so the end user doesn't have to convert
> files into tab delimited text files beforehand.

You should be able to find an Excel2CSV parser somewhere.
You may need to run it in a shell in a cron job or something if it's
not in PHP, but this won't be an issue.

> 2.) Ability to scrape data from a password protected website, download
> tab delimited text files, scrape the data and insert into database.

Assuming you actually know the password, right?...
http://php.net/curl
is your buddy.

> 3.) Create PDFs & Excel files on the fly.  (Excel files have some
> basic
> formatting - no macros)

http://php.net/pdf

And you can just dump out CSV and Excel will happily import them.

> Also, I'm fairly new to Apache.  I'm assuming that there are numerous
> methods of authenticating for a password protected site.  Right now
> we're using a 3rd party COM object to add / edit / delete user
> accounts
> in active directory.  We're using active directory to avoid having to
> use session variables in ASP.  I'm assuming that creating something
> with
> similar functionality on a LAMP box (or in this case FAMP) would be
> considerably easier?  I'm hoping that there is a method of keeping
> users
> and passwords in MySQL, and having Apache authenticate against the db.

You have so many options here, I won't even try to list them.

If you absolutely have to, you can even continue to use Active
Directory and pretend it's an LDAP server, and it kinda sorta works...

This makes sense only if you are stuck with a "one login" rule and
must use Windows, which you probably will NOT be able to convince to
use anything other than Active Directory.

If you're dumping Windows, you've got much nicer/cleaner/simpler options.

> Last but not least, SQL programming is no big deal.  I've kept all the
> existing SQL calls generic enough that they are platform independent.
> One thing that would be a headache saver would be error handling.
> Error
> handling in ASP is a nightmare.  Stuff like checking variables that
> the
> end user didn't put string data into a date / time field.  Actually
> it's
> fairly straightforward, just mind numbingly tedious to write all of
> the
> needed code.  How bad are other languages in this regard?

PHP 6 has a new "filter" extension which looks pretty nice, though I
haven't messed with it.

You'll never totally replace the tedium of sanitizing user input,
though, because it's always a Custom Tailor job if you want to do the
job right, and being a Security Job, you want to do the job right...

PHP does have an isset() function which makes it trivial to check if
there is any data presented, and strlen() tells you if it's blank or
not.

Some folks use empty() to check both at once, but that has some
versioning issues, where "0" was considered "empty" for awhile and...
Well, anyway, I don't like using empty, but different strokes for
different folks.

PHP error handling can be a bit... crude, say compared to Lisp or even
C++.

But compared to ASP's nightmare of having every DB SQL error have the
same error CODE number, but a different error message...  WTF?!

PHP 5 does have try/catch, but without quite the flexibility I'd want,
personally.

-- 
Like Music?
http://l-i-e.com/artists.htm