Process all form fields with a loop?

[mechro99]

Hi,

I was wondering if there is a way to create a do while loop that would get the name of each field in a form, and use that name to determine which database column to write to... Doesn't have to be a do while. Any method would be great.

Rather than having a processing page that reads:

rs.addnew
rs("field1") = request.form("field1")
rs("field2") = request.form("field2")
rs("field3") = request.form("field3")
etc.

my thought was to have some kind of loop read through the form, and create the code above dynamically. Thus having an include that could be dropped into any processing page instead of manually writing the processing code for really long forms.

Is this possible?

Thanks,
Dan

 

[Sheco]

The Request.Form may include items that do not have a corresponding column in the database.

For example, the Submit button and its "value" will often be in there is in the HTTP Request but there is probably not a field in the database table for this item.

How about if instead, the "loop" is through a recordset and the logic simply checks to see if the HTTP Request happens to include a form item with that same name?

 

[mechro99]

I think I understand. I'll give that a try. Thanks for the response.

 

[Sheco]

something like this:

Dim rs         'holds Fields collection
Dim cn         'db connection
Dim oFld       'ado field object
Dim strFields  'sql fields string
Dim strValues  'sql values string

Set cn = Server.CreateObject("ADODB.Connection")

'ToDo: Open connection here

'get an empty recordset with fields
Set rs = cn.Execute "SELECT * FROM MyTable WHERE 1 = 2"

'iterate through the recordset's Fields collection
For Each oFld In rs.Fields
  strFields = strFields & oFld.Name & ","
  strValues = strValues & "'" & oFld.Value & "'," 
Next 

'chop off extra trailing commas
strFields = Left(strFields, Len(strFields) - 1)
strValues = Left(strValues, Len(strValues) - 1)


'INSERT new row here
cn.Execute "INSERT MyTable (" & strFields & ") VALUES (" & strValues & ")"

Obviously this is just to give a rough idea. Depending on the database table there may be required fields that are missing, field values that must be within a certain range, datatypes other than alphanumeric characters, and so on but nothing you can't handle if you put your mind to it.

But that brings up another point that I want to make... If you spend a lot of time making a fancy bit of code, it will be a lot harder for the next guy who comes along after you than if you just do it the long boring way. It may not look elegant and all that but it will be maintainable by someone less qualified than yourself.

 

[mechro99]

Good point. Funny you should mention that, I was just having a conversation about a previous co-worker that ALWAYS went the way of the dynamic, fancy code method, and how she drove me insane because of it.

I never could figure out how she came up with the loops within loops within loops that she'd pull off. But it made me think that I should try to do more code like that, just to make my pages shorter and cleaner.

I'm pretty new to scripting in general, so I'm still trying to learn what the most efficient ways of doing things are. Sounds like you'd suggest simply hard coding the processing page.

Thanks again for the insight.

-Dan

 

[Sheco]

As programmers, we are trained to look for efficient and elegant solutions... we are trained to hate messy, bulky, repetative code.

But ASP was born to be messy. It mixes program logic with HTML presentation, the default language has terrible error handling, and code reuse depends on INCLUDE directives. Then add to this the fact that HTTP is inherently stateless and efforts to maintain state are kludges... also in a web application the location of each file withing the folder structure is critically important.

I guess what I'm trying to say is that you can never really make an ASP application as elegant and clever as your professors would have required. So maybe it is better to make something that is as simple as possible.

 

[monksnake]

I never could figure out how she came up with the loops within loops within loops that she'd pull off. But it made me think that I should try to do more code like that, just to make my pages shorter and cleaner.

That usually hints at the programmer only knowing one way to get something done.

The simpler a code is, the easier it is to work with, usually faster, and all around sexier.

<.

 

[gbaughma]

faq333-6618

By meeeeeeeeeeee.



Just my 2¢
-ARRGH! All my clothes are wrinkled! Oh, the irony!

--Greg

http://parallel.tzo.com

 

[Tarwn]

Sheco, I'm not sure I would agree that you can't write elegant or clean code in ASP. It's ust harder to do consistently then it would be in many other languages. I currently program actively in about 4-5 languages, but I feel that I could write clean and, in some cases, elegant ASP code. Clean is often easier then elegant and I will agree there aren't many things that are elegant in ASP.
On the other hand, shorter line count does not equate to clean, maintainable code.

Any time you start trying to get too complex with your code, just remember the last time you had to clean up someone elses code and all the names you called them. Then try to re-organize and comment your code so that the next poor schmuck who has to work on your code will have a slightly better day.

Or you could pretend I am going to be the next one to look at your code
I just found a series of bugs in an application I have been semi-reverse engineering. You don't want to know how I feel about their coding practices, testing (hah), etc. I don't tend to wind down for quite some time (and unfortunately that means less business for them).

 

[Sheco]

Tarwn, I didn't mean to imply that it is impossible... merely that the deck is stacked against you.

From what I've seen it is common for ASP applications to be either elegant or maintainable; more commonly neither than both.

I’m suggesting that in most cases, maintainability should not be sacrificed in the name of elegance.

 

[Tarwn]

Sheco, I agree completely, it just sounded like you were venturing towards the "it's not possible" realm of thought and I had to respond.