1) can I send the entire form collection to a subroutine in *base.cs file for processing? [this in not the code-behind file]

2) how do I, when declaring the subroutine, cast the collection?

e.g.:
public void updateContactRecord(string idcontact, <xxx> formcollect)
{
...
}

I'm sorry for such a bone-head question...but I spent hours, looking around the web and the books online...but what is <xxx>?

Brian

Brian Sausser, MCP
(858) 229-6129

__________________
Brian Sausser, MCP
(858) 229-6129

If this function is running in the context of a web page you can access the current forms collection like this:

System.Web.HttpContext.Current.Request.Form

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

Again,

In my post, it is not in the context of the web page.

I want to send the form collection to a subroutine outside of the context of the web page, and I'm blanking on how to cast the form collection when I defined the routine.

Please reference the first message...

Brian Sausser, MCP
(858) 229-6129

I think Peter meant 'context of the web application' because I used the same code in my class file for my application.

Yes, thank you, that is what I meant. I guess I really should have said, "if you are calling this function only from a web application page..." which one would assume you would be otherwise you wouldn't be writing a function that used the web request form collection. :)

Perhaps clarifying that "context" is different from "scope" would help. Obviously, if the function is in the scope of a web control class you don't need that at all, you can refer directly to "Request" because that is a member of all controls (page and user control included). As long as it's in the context of a web request, using the current context reference will work, regradless of the scope.

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

I want to appoligize for any huffyness in my last post. The answer is no.

I want to send the form collection to the subroutine that is not in context or scope of the web page that submits the form.

The question has evolved into how to cast the form collection when I declare the subroutine in a completly different *.cs file in the root of web application?

When I create the subrouting called updateContactRecord:
   updateContactRecord(string idcontact, xxx formcollection)
   {
   ...
   }

What should xxx be? (like when I cast string for the variable idcontact) And is that possible?

Brian

Brian Sausser, MCP
(858) 229-6129

The Form collection is a NameValueCollection.

If your *.cs file is within a web application then it IS in the context of a web application, but it is not within the scope of a web application page (any class that derived from System.Web.UI.Page). Therefore you do not technically need to have a parameter to pass the form collection into the method. You certainly may do so if you desire but you can just as easily use System.Web.HttpContext.Current.Request.Form to access the form collection without the need for a method argument.

May I ask why you have the need to pass the raw form collection around for use in your application? ASP.net virtually eliminates the necessity to access the form collection.

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

Peter,

thank you for the terminology brief; It makes questions asked and answered easier and concise.

I want to send the form collection to avoid code duplication. I want to use subroutines that is part of my web application's namespace when i add a record or update a record in many different web pages within the web app.

So, when i define the subroutine i can cast the form collection like this:
    updateContactRecord(string idcontact, NameValueCollection Request.Form)
{
...
}

Brian

Brian Sausser, MCP
(858) 229-6129

That still doesn't really answer the question: Why are you accessing the raw form collection instead of accessing the page controls? If you really want to create a clean n-tier application that has the data logic separate from the UI you should consider creating some entity classes that you can pass around to your data logic methods instead of passing to or expecting those methods to know how to handle a collection based on the web classes. Instead of passing the whole form collection, you can use the form's controls to populate a business class object, then pass that to the data logic method. This is much more modular design.

Also, when working with ASP.net, trying to deal directly with the form collection can be very very tricky because of the way .net names the form elements. A simple example of this is when you have a user control. All the child controls of a user control get their form name/id prefixes to the Nth degree based on their parent controls so it's nearly impossible to be able to know what their eventual form element name will be at design time.

It sounds like you have the right approach to building a system that doesn't have redundancy and separates the UI logic from the data logic, but the technique you are using still requires that the data logic be knowledgable of the UI. This defeats the purpose of n-tier design.

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

Peter,

Thank you very much for your advice, although much of it went right over my head. Do you have a reading suggestion to get me up to speed on "best practices" of code design in the .NET Framework? Something more on the philosophy rather than the technical.


Brian Sausser, MCP
(858) 229-6129