About the answering your question:

I have a namespace that is in the file: blahbase.cs, and inside there I have some subroutines.

I was planing on uniformity of the web form id names, so that the subroutine would "assume" the key name and do whatever the routine was designed to with the associating value.

That way I would be able, when adding or updating records, to send the data form fields from many different pages without have to declare all the variables and send each form field data.

For example:
public void updateContactAddressRecord(string idcontact, string line1address, string line2address, ...<all the rest of the fields>)
{
...update the records...
}
[This is not redundant, however this is where I'm duplicating code]
in webform: form1.aspx.cs
updateContactAddressRecord(hidContactID, txtLine1Address.Text.ToString(), txtLine2Address.Text.ToString(), ...);

in webform: form2.aspx.cs [in some other area, I have to change the address record]
updateContactAddressRecord(hidContactID, txtLine1Address.Text.ToString(), txtLine2Address.Text.ToString(), ...);

and maybe some other page does it again...so I'm up to three places.

If all the form fields are uniform in thier names across the diffent pages, then it would be easier to write it this way:
public void updateContactAddressRecord(string idcontact, <cast unknown to me> formcollection)
{
...pull the name and value pairs out of the formcollection array, and then manipulate data...
}

then the calls are used like this:
updateContactRecord(hdnContactID, Request.Form.<unknown to me>);

less code writing, but more important to me, is the ease of changing my data structure if needed: I can add a web form element (with a uniformed name such as txtCountry) to all the pages that need to accept the data, and then modifiy in only one place the actual code that is used to manipulate the data, since the entire form collection is being sent to the location that does the data manipulation....

does this make sense? Is my fundemental understand of code normalization putting me in a box I'm going to want to get out of later as the application gets more sophisticated?

Brian
PS: no spell check, sorry 4'em

Brian Sausser, MCP
(858) 229-6129

Writing code on the basis of assumption will inevitably get you into a lot trouble and head-banging. Particularly with .net. If you haven't already learned about user controls, do so. User controls will really mess up any assumptions you make regarding the form field names. Here's why:

When you have just a simple web form, with a textbox named "txtName" the resulting posted form key will be "txtName". However, if you have a user control that has a textbox ("txtEmail") and that user control exists on a web form, the actual field name of that email textbox will end up having a name (and thus the form post key) that looks like this: "ucMyUserControl1:txtEmail". So you couldn't have any code that assumes anything because the control names will vary.

If you have scenarios where you have pieces of a form that are being duplicated from page to page, you should look into user controls. They give you the ability to create a small, self-contained piece of a webform in a reusable control that you can drag and drop onto many web forms. A good example of this is an address form. If you have several pages that need to allow updating of an address, you create a user control for the address part and include it in your web form. The address control handles all items related to the address. It can load up the address from where you want in the database or you could provide properties on the control so the web form could set values on it.

Here's a sequence of events that may help to explain the power of user controls:

- User control (living on ANY web form) loads an address from database.
- All the fields of the "address form" are prefilled.
- User changes a value in the address form.
- When you post back the control, the user control's controls (address1, address2, state, city, etc) can determine their own state changes (i.e. user changed the value in state) and can then update the data where necessary.

The user control has eliminated the need for you to:
- name all your controls the same on each page you create
- prefill the values on each page
- call the "UpdateAddress" function on each page.

All you have to do is add the user control as a single control on your web form. The user control itself can handle everything else. You can even include the same user control on the page any number of times and .net will keep each instance of each separate.

Think of a user control as a little page unto itself. You can leave it as-is and let it do its own thing or you can open it up and expose it for interaction with the page it's living on or with other controls.

The main topics I would recommend you research further are:
- User controls
- Event driven programming

How long have you been working with .net? What technologies are you coming from? The reason I ask is that the mindframe one needs to build solid and flexible .net applications is much different from that needed for traditional ASP. Old school ASP is very linear and must be programmed in a linear fashion where as ASP.net is event driven and functions in a much different way. I have found a very big difference in design and programming style between them.

Peter
------------------------------------------------------
Work smarter, not harder.