[UFO Chicago] web development opinions needed.

[Greg Groth]

> 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.

This is for internal use only, design is mandated by my co-workers, and 
they want it all on one page.  There's too many idiosyncrasies for us to 
allow our clients to generate quotes on their own.  These are quotes for 
support contracts.  Customer gives us a list of equipment, we load it 
into the database, and generate the aforementioned form.  Co-workers 
make modifications, and generate a quote.  The lists of equipment we get 
from customers are generally in the 50-200 line items range, but on 
occasion go into  the 1200-1500 line items range.  Basically each line 
item has is listed on a form, and has 7 form elements per line item. 
When you get into the 1200-1500 range, you end up with 8500+ form 
elements.  These forms can take up to 5 minutes to render in a browser, 
but my co-workers are happy because it can take 20-24 man hours to do 
this stuff by hand.  I could break up the form into multiple pages to 
increase rendering speed, but overall it would take just as long to 
render 10 large pages as 1 gigantic one.

Another question for the PHP gurus.  How difficult is it to protect 
against SQL injection?  97% of our web apps reside on our Intranet, and 
I'm not worried about hacking there.  We currently have only 6 people on 
staff, and I can say with authority that hacking a server is way above 
their capabilities.  Our public site does have a few forms though. 
Currently we protect against SQL injection by using stored procs, a 
custom 500 error page, and checking for SQL command characters in 
returned variables.  We do not use stored procs on our intranet for a 
number of reasons.

Thanks again for all the comments

Best regards,
Greg Groth