Originally Posted by paulh1983
Or could I create a form that creates this class automatically? because the whole idea of this form generation is so that I do not have to waste my time creating forms and instead one of other non-IT colleague can use this "thing" i am creating.
Ok, so at some point each non standard form requires some input from someone to make the form different.

You could spend 5 minutes wring an extended class with the required fields in, and only you can do this

Or you can spend an amount of time (currently unknown) building a system to allow others to manage the forms, which seems to be your preferred choice at the moment. In this case I would go down the database route. At the very least you'll want 3 tables just for the fields:

form
form_field
form_field_option

Then you'll want tables for

client
client_form (client_id,form_id)
form_response (form_id, timestamp)
response_value(response_id, form_field_id,response_value)

Originally Posted by paulh1983
The tracking pixel is there so that we know the user has submitted the form. This data goes to an external system we have. basically for each "lead" we collect we send it off to our client. tracking pixel i think helps us do rough counting i.e. 21 leads came in today so if the client argues saying it was less we know it isn't. something to that effect.
I understand tracking, I just don't see the need for a pixel - if you have 21 responses in your database, then you have 21 responses. if you wanted to track views/completions/etc then this can all be databased. you can even set a cookie in an attempt to stop the same person submitting the form again