ASP.NET 2 UserControls

Greetings,

We have a application that was recently migrated from ASP 1.x ==> ASP 2.0
(I'm sick of saying .NET after everything so just know that I'm talking
about .NET). We have <INPUT /> controls on the UserControl. We also have
tons of JavaScript all over the place, some hardcoded, some autogenerated
that refer to these controls when rendered.

In ASP 1.x, the HTML was rendered of the form <INPUT
name="usercontrol_inputcontrol" id="usercontrol_inputcontrol" />

But in 2, it renderes <INPUT name="usercontrol$inputcontrol"
id="usercontrol_inputcontrol" />

And all over our javascript is broken. I really don't want to change
thousands of different locations to findbyid on the name as that makes for
harder to read code and will be very timeconsuming to track all the places
down the need to be changed. Do we have any control over the rendering? Is
there a way we can make it emit the name the way it used to so that
backwards compatibility isn't sacrificed for the time being?

We've had nothing but hardships updating our web to 2.0. Took 20
programmers full-time almost 4 weeks to finally get our (1000 pages) ASP.NET
1.x application to function in 2 and even then, we still keep finding these
"little" things all over the place. Many times we almost made the decision
not to migrate to 2.0 because of the shear number of differences between 1.x
and 2.0 (ASP.NET) that need to be addressed before we can even run the
website on a staging server). Its annoying, I tell ya, annoying. And for
all that, we still may not because the migration has been so costly. We
aren't making progress on the bugfixes or other enhancements because of this
extravaganza.


Thanks,
Shawn

re: ASP.NET 2 UserControls

I agree, the migration to 2.0 is smooth only if you don't try to
combine .NET output with any external languages/markup.

I'm in the same boat, and the path I'm heading down is a custom class
that can take a page, loop through its controls, and generate
javascript along the lines of:

var {ClientID} = document.getDocumentById["{ClientID}"];

A bit of a hack, but then I can consistently refer to form fields via a
simple syntax, and not worry about how they're actually generated.

re: ASP.NET 2 UserControls

> I'm in the same boat, and the path I'm heading down is a custom class[color=blue]
> that can take a page, loop through its controls, and generate
> javascript along the lines of:
>
> var {ClientID} = document.getDocumentById["{ClientID}"];
>
> A bit of a hack, but then I can consistently refer to form fields via a
> simple syntax, and not worry about how they're actually generated.[/color]

This might not be a bad idea, after all. But we'd have to change in so many
places. I figured out how to make it work... most of the code I work on has
always used the document.forms[0]. ... syntax for identifying form elements.
Code I have not worked on used the document.Form1. ... syntax. This was one
of those cases. In ASP.NET 2, it is "form1" (lower-case F) which caused the
problem.

I'm all for change and progress. But when Microsoft expects us to upgrade
and migrate to the latest and greatest, they should at least do more than
pay lip-service to compatibility. ASP.NET 2.0 is so drastically different
from 1.x... even their own migration wizard failed to convert the site.
Their rendered output isn't friendly to client-scripting, either. For
example, we can't use MasterPages in our site where it would make the most
sense and give us tremendous benefits because, we would have no way to
predict how the Javascript should reference the controls on the Master page
because it tries to uniquely name each thing. Prudent, I suppose. But they
need to not assume that I'm an idiot. I know what I'm doing. Thus, we
can't store any client script in the Master Pages. Well, then Master Pages
are useless for our site and the design of our site won't change to fit into
the tiny little box MS wants us to be in. Our web application is so much
bigger than their vision, appearantly.

But, in all, apart from ASP.NET, the migration was smooth. Unfortunately,
our applications is Web based, thus its a problem.


Thanks,
Shawn