grabbing a traditional form value via .net (instead of referencing an object)

[darrel]

I have a contact form that a person submits to the server.

In ASP, you'd make a page, post the form to another page, which would grab
the values and do somethign with them.

in ASP.NET, it appears that you grab the values directly from the form
objects on the postback.

Here's our problem:

We wanted to make a list of radiobutton options. Unfortunately, .net's
datalist and radioButtonGroup controls produce invalid HTML if you want to
format it in columns and you don't have enough record to populate every
column of every row of the table. So, to remedy this, I am building the HTML
for this list of radio buttons on the codebehind page and passing it to the
aspx page as text for a label.

The problem is that the person that is grabbing the data from the form to
submit it to the database and email can't 'grab' the value of these
radioButtons since they don't 'exist' on the ASPX page until the page is
processed on the server.

Is there a way around this? We're thinking that perhaps we can add a
radioButton to the aspx page in a hidden panel, which will allow the
codebehind to 'see' the radioButotn prior to page rendering. Then, when the
page does render, the radioButtons that do appear can override the value of
the hidden default one. Of course, this seems like a giant hack to me. ;o)

-Darrel

[Kevin Spencer]

Hi darrell,

the hidden default one. Of course, this seems like a giant hack to me. ;o)
The whole thing IS a giant hack. Unfortunately, and I can certainly
sympathize with you in regards to this situation, but you will need to
understand ASP.Net's programming model a good bit better before you can
really make use of it effectively. For example, instead of using a
RadioButtonGroup for radio buttons, you could certainly use individual
RadioButton Controls in your page.

The rub here, is, of course, you have to produce a product. But it would be
better in the long run if you got to know this much bigger than ASP
programming model before you try to implement it in production. If you're in
a bind, you can access any form field data posted by the client in the
Request.Form collection, regardless of whether the client-side HTML elements
are connected to CodeBehind Controls or not.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"darrel" <no*****@hotmail.com> wrote in message
news:ud**************@TK2MSFTNGP09.phx.gbl... I have a contact form that a person submits to the server.

In ASP, you'd make a page, post the form to another page, which would grab
the values and do somethign with them.

in ASP.NET, it appears that you grab the values directly from the form
objects on the postback.

Here's our problem:

We wanted to make a list of radiobutton options. Unfortunately, .net's
datalist and radioButtonGroup controls produce invalid HTML if you want to
format it in columns and you don't have enough record to populate every
column of every row of the table. So, to remedy this, I am building the HTML for this list of radio buttons on the codebehind page and passing it to the aspx page as text for a label.

The problem is that the person that is grabbing the data from the form to
submit it to the database and email can't 'grab' the value of these
radioButtons since they don't 'exist' on the ASPX page until the page is
processed on the server.

Is there a way around this? We're thinking that perhaps we can add a
radioButton to the aspx page in a hidden panel, which will allow the
codebehind to 'see' the radioButotn prior to page rendering. Then, when the page does render, the radioButtons that do appear can override the value of the hidden default one. Of course, this seems like a giant hack to me. ;o)

-Darrel

[darrel]

> For example, instead of using a

RadioButtonGroup for radio buttons, you could certainly use individual
RadioButton Controls in your page.
Well, as you said, I need to produce real product based on what I know. I'm
always up to learning more though!

So, conceptually, what would the solution be if I were to use individual
RadioButton Controls?

Here's what I'm doing:

Grabbing a set of records from a table.
Assigning each record to a radioButton.
Rendering it on the page.
If you're in
a bind, you can access any form field data posted by the client in the
Request.Form collection, regardless of whether the client-side HTML elements are connected to CodeBehind Controls or not.

That's good to know. What is the disadvantage of using this? I'm all for
doing things the 'right way--the .net way' but sometimes the .net way seems
counter-intuitive, or just plain verbose for web development. I know part of
that is just making the mental leap from interpreted code to OOP but there
are times when classic ASP and ASP.NET seem to be at polar opposites of the
web development methodology spectrum when, in the real world, there seems to
be a need for that middle-ground.

-Darrel

[Kevin Spencer]

> So, conceptually, what would the solution be if I were to use individual

RadioButton Controls?
HTML Radio Buttons are grouped by their name attribute. When several Radio
buttons have the same name, they belong to the same group. The form will
post only ONE value for the entire group, whichever Radio button that is
checked. In the RadioButton WebControl, the GroupName property determines
the name attribute of the RadioButton when rendered on the client. I
wouldn't set them to AutoPostBack, but when the PostBack occurs you could
certainly check their Checked properties. Only one will be true.
That's good to know. What is the disadvantage of using this? I'm all for
doing things the 'right way--the .net way' but sometimes the .net way seems counter-intuitive, or just plain verbose for web development. I know part of that is just making the mental leap from interpreted code to OOP but there
are times when classic ASP and ASP.NET seem to be at polar opposites of the web development methodology spectrum when, in the real world, there seems to be a need for that middle-ground.
Good question, Darrel. There are a good number of reasons why the ASP.Net
programming model was designed the way it was. HTTP is stateless, which
means that, in ASP, you had to build your own routines for maintaining state
in your ASP pages. ASP.Net has state management built right into it. ASP was
a bit too relaxed in its rules, making for some serious spaghetti code out
there (I've had to untangle a good bit of it in the past myself). ASP.Net is
more rigidly structured by nature, and tends to force the developer to
separate presentation code and business logic, which is a very good thing
when it comes to code maintenance. Object-oriented programming is by nature
much better overall than procedural, for quite a few reasons.

As for being "counter-intuitive," that's just a matter of time and practice.
Once you "get it" it becomes entirely intuitive.

Good luck!

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"darrel" <no*****@hotmail.com> wrote in message
news:eE**************@TK2MSFTNGP10.phx.gbl...

For example, instead of using a
RadioButtonGroup for radio buttons, you could certainly use individual
RadioButton Controls in your page.

Well, as you said, I need to produce real product based on what I know.

I'm always up to learning more though!

So, conceptually, what would the solution be if I were to use individual
RadioButton Controls?

Here's what I'm doing:

Grabbing a set of records from a table.
Assigning each record to a radioButton.
Rendering it on the page.

If you're in
a bind, you can access any form field data posted by the client in the
Request.Form collection, regardless of whether the client-side HTML elements

are connected to CodeBehind Controls or not.

That's good to know. What is the disadvantage of using this? I'm all for
doing things the 'right way--the .net way' but sometimes the .net way

seems counter-intuitive, or just plain verbose for web development. I know part of that is just making the mental leap from interpreted code to OOP but there
are times when classic ASP and ASP.NET seem to be at polar opposites of the web development methodology spectrum when, in the real world, there seems to be a need for that middle-ground.

-Darrel

[darrel]

HTML Radio Buttons are grouped by their name attribute. When several Radio
buttons have the same name, they belong to the same group. The form will
post only ONE value for the entire group, whichever Radio button that is
checked. In the RadioButton WebControl, the GroupName property determines
the name attribute of the RadioButton when rendered on the client. I
wouldn't set them to AutoPostBack, but when the PostBack occurs you could
certainly check their Checked properties. Only one will be true.
Oh...right...I know all of that. That is what I'm doing. I'm making my own
set of radio buttons with the same name in the codebehind and then spitting
it out to the aspx page as text for a label.

The issue is that I can't use the built in controls for RadioButtonLists
since .net spits out invalid HTML when it makes a multi-column table. As
such, the codebehind doesn't see the object , since the object is just a
label that has standard HTML assigned to it in the codebehind.
ASP.Net is
more rigidly structured by nature, and tends to force the developer to
separate presentation code and business logic, which is a very good thing
Well, I agree that conceptually it is a good thing, but I'm also finding
that you can't allow .net to make your presentation for you. It's bad at it.
It tends to make bloated, innaccessible and oft-times invalid markup. Hence,
I'm finding that I end up using a lot of repeater controls (which is still
good) but then at times having to move my presentation back to the
codebehind side so I can build it myself.

I'm sure part of that is me not fully understanding all there is to know
about .net, but there also seems to be clear concensus that .net has a long
way to go before developers fully trust it to handle the presentation side
for us.
As for being "counter-intuitive," that's just a matter of time and practice. Once you "get it" it becomes entirely intuitive.

I'm getting there. Thanks for the help!

-Darrel