Working with controls clientside (js) ?

[Skoder]

Hey, i was wondering how you work with controls client-side now that it is impossible to use the ID as refference (document.getElementById()), because it adds ctl0_ infront of it, or if it is inside a contentplaceholder (masterpage) it might add ctl0_contentplaceholderid_ ... Not even the NAME attribute can be used as it is also rendered to something different.... Hmmm ... of some reason they must have thought that people wasnt clever enough to manage the ids and names themselves... :doh: I find it pretty "stupid" if you have to add the references server side in order to make it work client side (like getting the myTextbox.clientid and adding it as a variabel in a script block for every single control (or something like that)). Maybe the only possibility is to add client events server side ? Like Button1.Attributes.Add("onclick", "myFunction('"+Button1.ClientID+"')"); ? ? ? I am trying to prevent writting something server side which will to be run everytime the page loads when it instead easily can be added as static "text". There must be some proper solution to this ? :confused: All i want to do is to get hold of a refference to an element like document.getElementById('myElement'); by something that i can "count" on ... Right now the best i can come up with is wrapping all elements into spans or divs and assign the id there, and then get that elements child .. (not a very good solution) ... :(( btw. I found an article on msdn about working with clientscript... (http://msdn2.microsoft.com/en-us/library/3hc29e2a#IdentifyingServerControlsInClientScript[^]). It gives an example of a asp:textbox with id="Textbox1" being rendred as id="Textbox1" ... i dont see how they managed to do that. On my server that never happens ... it always adds at least ctl0_ infront of the id .. !? :confused:

[Mike Ellison]

Hi there. I think the prefix you're seeing (like ctl0_) is coming from the naming container in which your control resides. Are you putting your controls in a Panel for example? Pretty much any control that has child controls will implement the INamingContainer[^] interface. The prefixing is actually a very useful thing, particularly for databinding controls. Imagine a Repeater control... you have the same control inside a template that gets repeated for each record of data. ASP.NET has to manage the naming such that the client sees a unique ID for each of the repeated controls - it wouldn't make much sense to manage that manually. Here's a good article by Dino Esposito on the INamingContainer interface, in the context of developing a custom control. Use Naming Containers[^] I hope this helps.

[Skoder]

Hey, thanks for the answer. I see why the ID should be unique. I am using asp.net 2.0 and masterpages soo all controls going into a contentplaceholder will have an id like ctl0_contentplaceholderID_acutalID_i_wrote But if they at least just had left the Name tag alone. Then it would be possible to do getElementsByName() to get all elements with one name and then loop through them. Hmm but i guess working with static javascript and asp.net is just a pain in the ass. Best way will probably be to write out a javascript variabel in the page which can be used by the javascript. like var controls = "ctl0_"; (output from the server side - soo you know the "path") then when working client side with javascript it would just be document.getElementById(controls+"controlID"); it will work ... but still stupid it should become soo "dificulty"... as it is very used ... Am i really the only one having problems with working with clientside javascript, and controlling 's which comes from asp:controls ?

[Mike Ellison]

This is interesting to me. I've been asking myself why I haven't run across the same frustration as you are describing - I work a lot with client-side javascript too. It occured to me that my work with client-side js is usually in the context of building a custom control. Within the custom control, when I construct the client-side js code to send, I always use control.ClientID, so the naming container is not an issue at the client. But it sounds like you're not building a custom control, rather just dealing with regular server controls. I suppose it depends on what you're ultimately trying to accomplish, but if you're building on additional client-side functionality to an existing server control, have you considered creating a subclass of the control in .NET and let your subclass output the necessary javascript? This becomes particularly useful if you reuse the functionality. For example, I've seen folks use javascript on a TextBox to limit the characters that may be entered. Creating a subclass of TextBox which encapsulates this client-side functionality allows for its reusability without any additional work on your part. Just a thought.

[Skoder]

Hey again, the difference between what you do and I do (as far as i can see) is that you create the javascript server-side and write it to the page. I have all my javascript in a static .js file (soo it is cached in the browser). Then it is only loaded once and it doesnt add any extra code to the page. I am trying to prevent writting out stuff server-side to be able to access the controls. But it seems to be almost "impossible" .. Soo if i want to etc do my own validation of controls (instead of using the validation controls - adds unessecary code), it is pretty much impossible to know the names of the controls i want to validate as there ids are rendered. except if i write out something server-side (which i am trying not to). BUT.... :) what i do now is that either i hardcode it ctl0_Content_ID ... or etc for validation i pass the button (clicked) and takes out the id and splits it up to the last "_" and then use that when checking controls.

[Mike Ellison]

Skoder wrote:

the difference between what you do and I do (as far as i can see) is that you create the javascript server-side and write it to the page. I have all my javascript in a static .js file (soo it is cached in the browser). Then it is only loaded once and it doesnt add any extra code to the page.

Hi there. Actually, I also create .js libraries with most functionality; I then output through server-side code enough js to issue a ClientID... for example, my client-side .js library will have something like an initialize() function that takes a string for a parameter. My server-side code will output something like "Initialize(" + this.ClientID + ")". My client-side library can then be initialized with the proper control id. (Usually I'm creating javascript objects, with prototype methods, and I'll capture the ClientID as a property of this client-side object, either through an Initialize() function or through the constructor). I just sort of made a habit of doing it this way when working with client-side code for ASP.NET custom controls.

[Skoder]

Thanks again for the reply. I see the point in your method, and i guess that is a good alternative. At least i have come to that conclusion that most likely i have to write out just a little code server-side to make javascript work properly (normally). By now i just stick with pulling the first part of the ID from the button clicked (when validating). The custom control i made (when posting) luckily needs to have a wrapper around the control in order to work properly soo i have just assigned an id to it (the wrapper) and as the functions are called on the wrapper i can just call function like onclick='myFunction(this)', and in the function i just do the following to get the control i want thisRef.firstChild.... Martin :)

[Mike Ellison]

Sounds good, Martin. I enjoyed this conversation :cool: