Когда у меня есть пользовательский элемент управления, которому требуется JavaScript, я обычно определяю объект JavaScript для инкапсуляции его поведения. Так что в вашем примере у меня будет отдельный файл JavaScript MyCustomControl.js
, который выглядит примерно так:
// MyCustomControl JavaScript object constructor:
function MyCustomControl(clientID) {
this.id = clientID;
}
// MyCustomControl prototype:
// Declare any methods for the object here.
MyCustomControl.prototype = {
set_text: function(text) {
$("#" + this.id).val(text);
}
};
Затем вы добавляете amethod на свою серверную часть пользовательского элемента управления, чтобы сгенерировать вызов конструктора объекта JavaScript для экземпляра пользовательского элемента управления:
public string GetClientSideObject()
{
var serializer = new System.Web.Script.Serialization.JavaScriptSerializer();
return string.format("new MyCustomControl({0})",
serializer.Serialize(this.ClientID));
}
Затем вы можете встроить вывод GetClientSideObject()
в динамически сгенерированный скрипт, чтобы создать экземпляр объекта JavaScript вашего элемента управления:
<script type="text/javascript>
var myUserControl = <%= this.myUserControl.GetClientSideObject() %>;
myUserControl.set_text('Foo Bar Baz');
</script>
Одна из приятных сторон этого подхода заключается в том, что большая часть вашего JavaScript является статической и заканчивается в отдельном файле .js, который можно кэшировать / комбинировать / минимизировать / и т.д., как любой другой скрипт. Он также четко связывает экземпляр с исходным пользовательским элементом управления для всех, кто читает код.
Однако следует обратить внимание на сериализацию аргументов в конструкторе в GetClientSideObject()
. Я склонен использовать класс JavaScriptSerializer
для записи своих аргументов, поэтому я могу быть уверен, что строки заканчиваются как строки в кавычках, а числа - это числа и т. Д.