Let's say that the server control ID is chkAvailableOptions. At the time of rendering this collection is translated to as many checkboxes there are in the collection.
For example, if in the code-behind:
chkAvailableOptions.Add("first_item");
chkAvailableOptions.Add("second_item");
chkAvailableOptions.Add("third_item");
This is mapped to:
< id="some_prefix_chkAvailableOptions_0" name="some_prefix$chkAvailableOptions$0" type=" checkbox ">
< for="some_prefix_chkAvailableOptions_0">first_item< /label >
< id="some_prefix_chkAvailableOptions_1" name="some_prefix$chkAvailableOptions$1" type=" checkbox ">
< for="some_prefix_chkAvailableOptions_1">second_item< /label>
< id="some_prefix_chkAvailableOptions_2" name="some_prefix$chkAvailableOptions$2" type=" checkbox ">
< for="some_prefix_chkAvailableOptions_2">third_item< /label >
Take note of the mapping of each item text to an HTML label. This makes it hard to get access to the text (or value) of the checkbox checked off/on in the browser. To solve this, you can include a server control asp:HiddenField and populate it with indexed items that are in the CheckBoxList collection. Then in the javascript, through some string manipulation, you can get the corresponding text to the checkbox checked off/on.
The way to get to the checkboxes in javascript:
for(i=0; i<8; i++)
{
var chks = document.getElementById("ctl00_Checkbox_" + i);
if(serverMethods != null) { ... }
}
The challenge is to know the number of checkboxes that needs to be looped over, for example, if you're trying to find which one's have been checked or unchecked. To get over this, on the server side, you can pass the checkbox count as a hidden field, for example.
Another challenge is to read the labels associated with each of the checkboxes. Again, I've been using a hidden field that gets populated on the server side. On the client side, through some index matching you can map a label to the checkbox.
Thursday, March 27, 2008
Wednesday, March 26, 2008
Request.UrlReferrer could be null
The Request.UrlReferrer is the client's previous request that has linked to the current URL. The URLs don't necessarily need to be in the same domain. Even if it's in a separate domain, the client's current URL will be sent to the other page as the client's current URL address.
So let's say you've been redirected to the other page, Request.UrlReferrer gets the client's previous URL. If the client is a browser, and you refresh (for example F5), the server request still has the client's previous URL. There is one exception. If, in the browser address bar, you click on the Go button beside it, this new server request has the Request.UrlReferrer as null. This is why the code-behind needs to check for nulls when accessing the Request.UrlReferrer object.
Another way of getting to UrlReferrer is: Request.ServerVariables["HTTP_REFERER"];
Considerations: Proxies may remove the referrer information.
So let's say you've been redirected to the other page, Request.UrlReferrer gets the client's previous URL. If the client is a browser, and you refresh (for example F5), the server request still has the client's previous URL. There is one exception. If, in the browser address bar, you click on the Go button beside it, this new server request has the Request.UrlReferrer as null. This is why the code-behind needs to check for nulls when accessing the Request.UrlReferrer object.
Another way of getting to UrlReferrer is: Request.ServerVariables["HTTP_REFERER"];
Considerations: Proxies may remove the referrer information.
Subscribe to:
Posts (Atom)
