Have been following this thread with some interest. Here are my
comments :
1. I believe that the client side scripting support in ASP.NET is
fabulous, considering that its whole premise is server side. I don't
think it is incompatible at all. To clarify, JS never *runs* at the
server side, but can be *served* to the client where it will be run.
The timing of execution can also be controlled closely based on which
rendering method you use.
2. The names and ID's of server controls do change when the page
renders, and the names reflect the hierarchy of the control within its
containers. As Joe mentioned if you need the renderedID of the control
on the server side, use the ClientID property, which is formed by
appending the ID and the UniqueID. Additionally, the format of the
names follow a pattern that is easy to identify and replicate. So much
so that you might even go with hard coding the names of the controls
because they will always be the same.
Personally, I never like to use a server side expression in a JS
script block (like Joe's example). It is prone to a number of problems
in addition to the one Chuck pointed out. I would much rather have a
modular function that accepts the names of the controls as parameters
and in the Code-behind, I would call a
ClientScript.RegisterStartupScript() method which renders a call to
the JS function and passes the ClientID's of the required controls as
parameters :
// Code Behind.
string txtA = textBoxA.ClientID;
string txtB = textBoxB.ClientID;
string scriptText = string.Format("<script
type='javascript'>doSomething({0}, {1})</script>", txtA, txtB);
ClientScript.RegisterStartupScript(this.GetType(), "Something",
scriptText);
// JS function already defined in ASPX or JS file.
function doSomething(txtAID, txtBID)
{
var textBoxA = document.getElementById(txtAID);
var textBoxB = document.getElementById(txtBID);
textBoxA.value = "whatever";
textBoxB.value = "whoever";
}
Note that I only *call* the JS function through the Code-behind. This
allows me to avoid rendering larger script fragments from the code
behind.
3. I recommend the use of plain Html controls for most simple tasks
(instead of HtmlServerControls or WebControls) where this ID/naming
problem doesn't occur in most cases.
