Server altering name of form fields

[CJM]

[A third attempt - my first two attempts doesn't appear to have shown
up -yet]

I have a bit of code that inserts some extra controls (specifically,
ordinary <input type="hidden" name="MyField"f orm fields) into an existing
HTML form. However, it is mangling the name & IDs of these controls when
they are rendered:

For example, the PPItemName field is rendered as: <input
name="ctl00$Mai nBodyContent$PP ItemName" type="hidden"
id="ctl00_MainB odyContent_PPIt emName" />

Ordinarily, I wouldn't care (and it wouldn't matter either), but this form
is posting to a Paypal server and paypal is expecting particular field
names - so consequently we are having problems.

I can understand that .NET needs to use the ID attribute, but why the name
attribute? The name attribute is important in standard HTML, but I wouldn't
have thought so for .NET.

A workaround would be to use a placeholder, and use .innerHTML to inject
straight HTML inside. But this entire piece of code is already a workaround
for .NETs inability to handle multiple forms, so I thought there must be a
limit to the amount of messing about that I have to do.

Is there a way that I can force the server not to change the name of the
fields?

Thanks in advance...

Chris

[Mark Rae [MVP]]

"CJM" <cj*****@remove me-yahoo.co.ukwrot e in message
news:6j******** ****@mid.indivi dual.net...

I have a bit of code that inserts some extra controls (specifically,
ordinary <input type="hidden" name="MyField"f orm fields) into an
existing
HTML form. However, it is mangling the name & IDs of these controls when
they are rendered:

Correct. That is standard behaviour.

Is there a way that I can force the server not to change the name of the
fields?

Absolutely not! Don't even try - you'll almost certainly break your app if
you do.

Ordinarily, I wouldn't care (and it wouldn't matter either), but this form
is posting to a Paypal server and PayPal is expecting particular field
names - so consequently we are having problems.

Ah yes - a familiar problem...

A workaround would be to use a placeholder, and use .innerHTML to inject
straight HTML inside. But this entire piece of code is already a
workaround
for .NETs inability to handle multiple forms, so I thought there must be a
limit to the amount of messing about that I have to do.

Regrettably, I don't know any other way of doing what you're trying to do so
long as you continue to use form submission.

Obviously, form submission isn't the *only* way to interface with PayPal...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[CJM]

"Mark Rae [MVP]" <ma**@markNOSPA Mrae.netwrote in message
news:eh******** ******@TK2MSFTN GP05.phx.gbl...

>
Correct. That is standard behaviour.

Agreed - I just wasn't sure whether 'standard' meant 'only' behaviour. It
does.

>Is there a way that I can force the server not to change the name of the
fields?

Absolutely not! Don't even try - you'll almost certainly break your app if
you do.

Any more than a succession of workarounds?

It's frustrating that, while .NET is leagues ahead of Classic ASP in almost
every other area, it still manages to shoot itself in the foot in this way.

>
Obviously, form submission isn't the *only* way to interface with
PayPal...

No, but it is the simplest and easiest, especially for the way in which I am
using it. I will be looking into the other APIs and mechanisms in good time,
but in the short term I will persist with this.

It's not the end of the world, but it's a shame.

C'est la vie!

Thanks

Chris

[Mark Rae [MVP]]

"CJM" <cj*****@remove me-yahoo.co.ukwrot e in message
news:6j******** ****@mid.indivi dual.net...

>>Is there a way that I can force the server not to change the name of the
fields?

Absolutely not! Don't even try - you'll almost certainly break your app
if you do.

Any more than a succession of workarounds?

A workaround isn't supposed to break your app, not even a succession of
them...

It's frustrating that, while .NET is leagues ahead of Classic ASP in
almost every other area, it still manages to shoot itself in the foot in
this way.

The munging of control identifiers is necessary to allow things like
nesting, MasterPages and other UserControls to co-exist etc...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[CJM]

"Mark Rae [MVP]" <ma**@markNOSPA Mrae.netwrote in message
news:ur******** ******@TK2MSFTN GP03.phx.gbl...

>>
Any more than a succession of workarounds?

A workaround isn't supposed to break your app, not even a succession of
them...

Every bit on 'unneccessary' code makes it harder to maintain and makes bugs
more likely - as well as making development more of a chore.

In this case, the working solution is only slightly more clumsy than my
first attempted method, but it's the principle that I feel like I'm fighting
*against* the system rather than working *with* it.

Still, it's been an education - which is half of the objective.

>
The munging of control identifiers is necessary to allow things like
nesting, MasterPages and other UserControls to co-exist etc...

I realise that; but couldnt there be some sort of override? It's a very
useful feature in general, but in this case, I'd rather be allowed to trust
my own naming judgements.

[Ben Amada]

On Sep 23, 4:07*am, "CJM" <cjmn...@remove me-yahoo.co.ukwrot e:

I have a bit of code that inserts some extra controls (specifically,
ordinary <input type="hidden" name="MyField"f orm fields) into an existing
HTML form. However, it is mangling the name & IDs of these controls when
they are rendered:

For example, the PPItemName field is rendered as: <input
name="ctl00$Mai nBodyContent$PP ItemName" type="hidden"
id="ctl00_MainB odyContent_PPIt emName" />

<snip>

I can understand that .NET needs to use the ID attribute, but why the name
attribute? The name attribute is important in standard HTML, but I wouldn't
have thought so for .NET.

A workaround would be to use a placeholder, and use .innerHTML to inject
straight HTML inside. But this entire piece of code is already a workaround
for .NETs inability to handle multiple forms, so I thought there must be a
limit to the amount of messing about that I have to do.

Is there a way that I can force the server not to change the name of the
fields?

Hi. Have you tried something like ...

HtmlGenericCont rol hid = new HtmlGenericCont rol("input");
hid.Attributes. Add("type", "hidden");
hid.Attributes. Add("id", "MyField");
hid.Attributes. Add("name", "MyField");
this.Form.Contr ols.Add(hid);

Even in a content page, for example, the input tag renders in the form
without any ID or name mangling:

<input type="hidden" id="MyField" name="MyField"> </input>

--
Ben
http://allben.net/

[CJM]

"Ben Amada" <be*******@gmai l.comwrote in message
news:99******** *************** ***********@a2g 2000prm.googleg roups.com...
On Sep 23, 4:07 am, "CJM" <cjmn...@remove me-yahoo.co.ukwrot e:

Hi. Have you tried something like ...

HtmlGenericCont rol hid = new HtmlGenericCont rol("input");
hid.Attributes. Add("type", "hidden");
hid.Attributes. Add("id", "MyField");
hid.Attributes. Add("name", "MyField");
this.Form.Contr ols.Add(hid);

Even in a content page, for example, the input tag renders in the form
without any ID or name mangling:

<input type="hidden" id="MyField" name="MyField"> </input>

Thanks Ben, I'll look into this...

My current code is:

Dim oItemName As New HtmlInputHidden With _
{.ID = "PPItemName ", _
.Name = "item_name" , _
.Value = Me.EventName.Va lue & " [" & Me.Location.Val ue & " - " &
Me.EventDate.Va lue & "]"}
Me.divPPDetails .Controls.Add(o ItemName)

I'm curious as to why a HTMLGenericCont rol would work OK, but not an
HTMLInputHidden .... Any ideas?

Chris

[CJM]

This works great, Ben. but why?

Thanks anyway.

Chris

[Ben Amada]

CJM wrote:

This works great, Ben. but why?

Glad to hear that works. Off hand, I don't know the exact reason why the
ID/name is changed for HtmlInputHidden .

HtmlInputHidden along with its siblings (HtmlInputText, HtmlInputButton etc)
are form controls that would typically be included in postback data.
ASP.NET may need to be able to uniquely identify each form control by its
ID. Whereas the value in a HtmlGenericCont rol is not passed back to the
server in the form's post data. So it is probably not necessary for it to
have a unique ID.

[Ben Amada]

Ben Amada wrote:

Whereas the value in a HtmlGenericCont rol is not passed back to the
server in the form's post data. So it is probably not necessary for it
to have a unique ID.

Actually, when the tag name for the HtmlGenericCont rol is a form control
tag, like <input>, the value is passed back to the server in a form post.
If you were to have multiple HtmlGenericCont rol "input" controls with the
same ID, the browser will send each piece of data to the server with the
same ID (I just checked). So you would want to avoid that situation. I
guess ASP.NET lets you manage HtmlGenericCont rol elements on your own :-)