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"> form 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$MainBodyContent$PPItemName" type="hidden"
id="ctl00_MainBodyContent_PPItemName" />

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

 

[CJM]

Correct. That is standard behaviour.

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

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

 

[CJM]

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]

I have a bit of code that inserts some extra controls (specifically,
ordinary <input type="hidden" name="MyField"> form 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$MainBodyContent$PPItemName" type="hidden"
id="ctl00_MainBodyContent_PPItemName" />

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 ...

HtmlGenericControl hid = new HtmlGenericControl("input");
hid.Attributes.Add("type", "hidden");
hid.Attributes.Add("id", "MyField");
hid.Attributes.Add("name", "MyField");
this.Form.Controls.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>

 

[CJM]

Hi. Have you tried something like ...

HtmlGenericControl hid = new HtmlGenericControl("input");
hid.Attributes.Add("type", "hidden");
hid.Attributes.Add("id", "MyField");
hid.Attributes.Add("name", "MyField");
this.Form.Controls.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.Value & " [" & Me.Location.Value & " - " &
Me.EventDate.Value & "]"}
Me.divPPDetails.Controls.Add(oItemName)

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

Chris

 

[CJM]

This works great, Ben. but why?

Thanks anyway.

Chris

 

[Ben Amada]

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 HtmlGenericControl 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]

Whereas the value in a HtmlGenericControl 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 HtmlGenericControl 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 HtmlGenericControl "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 HtmlGenericControl elements on your own

 

[Ben Amada]

This works great, Ben. but why?

It appears that there's a difference if you set the
HtmlGenericControl's ID property directly, as opposed to giving it an
ID through the attributes collection.

HtmlGenericControl hgc = new HtmlGenericControl("input");
hgc.ID = "hgc";
hgc.Attributes.Add("name", "hgc");
hgc.Attributes.Add("type", "hidden");
hgc.Attributes.Add("value", "some value");
this.Form.Controls.Add(hgc);

This results in an altered server ID:

<input id="ctl00_hgc" name="hgc" type="hidden" value="some value"></
input>

If you try to omit setting the ID property with the HtmlInputHidden
and instead set it via the attributes collection,

HtmlInputHidden hih = new HtmlInputHidden();
hih.Attributes.Add("id", "hih");
hih.Attributes.Add("name", "hih");
hih.Attributes.Add("type", "hidden");
hih.Attributes.Add("value", "some value");
this.Form.Controls.Add(hih);

Unsuccessfully, you get:

<input name="ctl00$ctl02" type="hidden" id="hih" value="some value" />

So, best combination is what you already have.

 

[CJM]

It's all very curious... but, what-the-hell... it's working & my code isn't
a complete mess so I'm happy.

Thanks again for your thorough efforts on my behalf.

Chris