You have to understand that ASP.NET naming containers exist and what they change about a page. This affects client side and server side code and often kicks my a** when I forget that I am in one.
A naming container is a marker interface (INamingContainer), meaning that it does not implicitly enforce the hierarchy of controls under it but does create a naming scope for all contained controls.
Any controls that exist inside the naming container have their Ids altered at runtime with a prefix to ensure they are unique and belong to the context of the parent container. When you see a control with a name like TextBox1 change to ct100_xxxxxx then you know that it's in a naming container and has had a naming adjustment. This can make client side scripting a pain but there are many hints around on the web to help you cope with that.
The naming containers you will be most familiar with are master pages, content place holders and data bound controls like GridView.
My latest bottom kicking came when I was using fluent validators that wanted my validation specification to sit in the same naming comtainer as the controls it was validating. I chucked it at the top of the user control and the validation specification wasn't found. Not finding it as a sibling to the controls meant that validation just wouldn't happen. There was no error.
This makes sense when you are implementing server side code that looks up to a certain level in the hierachy to find an optional element on the page.
The thing is to know what your naming containers are and where you should place things.
No comments:
Post a Comment