<%@ Register TagPrefix="PCS" Namespace="PCSCustomWebControls" Assembly="PCSCustomWebControls" %>
Мы используем параметр TagPrefix таким же образом, как и раньше, но не используем атрибуты TagName или Src. Это связано с тем, что сборка специального элемента управления может содержать несколько специальных элементов управления, и каждый из них будет именован согласно своему классу, поэтому TagName является лишним. Кроме того, так как сборка находится в каталоге bin, мы можем использовать средства платформы .NET для динамического обнаружения требуемой сборки просто по имени и пространству имен в ней, которое содержит элементы управления.
Выше, в примере строки кода, мы говорим, что хотим использовать сборку с именем PCSCustomWebControls.dll с элементами управления в пространстве имен PCSCustomWebControls, и при этом используем префикс PCS. Если в этом пространстве имен имеется элемент управления с именем Control1, то можно использовать его с кодом ASP.NET:
<PCS:Control1 Runat="server" ID="MyControl" />
С помощью специальных элементов управления можно также воспроизвести некоторое вложенное поведение элементов управления, такое, как мы видим в списке элементов управления:
<asp:dropdownlist id="roomList" runat="server" width="160px">
<asp:ListItem Value="1">The Happy Room</asp:ListItem>
<asp:ListItem Value="2">The Angry Room</asp:ListItem>
<asp:ListItem Value="3">The Depressing Room</asp:ListItem>
<asp:ListItem Value="4">The Funked Out Room</asp:ListItem>
</asp:dropdownlist>
Можно создать очень похожим образом элементы управления, которые интерпретируются как потомки других элементов управления. Позже в этой главе мы увидим, как это делается.
Конфигурация проекта специального элемента управления
Применим часть этой теории на практике. Мы будем использовать для простоты единственную сборку для хранения всех специальных элементов управления примера этой главы, которую можно создать в Visual Studio.NET, выбирая новый проект типа Web Control Library. Назовем нашу библиотеку PCSCustomWebControls:
Здесь проект создан в каталоге wwwroot, хотя это и не обязательно. Библиотеки элементов управления Web можно создавать где угодно, необходимо только скопировать созданную сборку в каталог bin приложения Web, которое ее использует.
Один из технических приемов, применяемых для упрощения тестирования одиночного решения, состоит в добавлении проекта приложения Web к тому же решению:
В данный момент это единственное приложение, которое будет использовать нашу библиотеку специального элемента управления, поэтому для ускорения работы определим, что выводимая сборка библиотеки создается в правильном каталоге bin (то есть нам не нужно копировать файл после каждой перекомпиляции). Это можно сделать с помощью страниц свойств проекта PCSCustomWebControls:
Отметим, что здесь в раскрывающемся списке Configuration выбран элемент All Configurations, поэтому отладочная и окончательная сборка будут помещены в одном месте. Output Path был изменен на C:InetpubwwwrootPCSCustomWebControlsTestAppbin Чтобы облегчить отладку можно также изменить значение Start URL на странице свойств Debugging на http://localhost/PCSCustomWebControlsTestApp/WebForm1.aspx, a Debug Mode - на URL таким образом, чтобы увидеть результаты, проект можно выполнять просто в режиме отладки.
Убедимся, что все это работает, протестировав элемент управления, который поставляется по умолчанию в файле .cs для библиотеки специального элемента управления, называемой WebCustomControl1. Нам нужно внести следующие изменения в код WebForm1.aspx, который просто ссылается на вновь созданную библиотеку элемента управления и встраивает используемый по умолчанию элемент из этой библиотеки в тело страницы:
<%@ Page language="c#" Codebehind="WebForm1.aspx.cs"
AutoEventWireup="false" Inherits="PCSCustomWebControlsTestApp.WebForm1" %>
<%@ Register TagPrefix="PCS" Namespace="PCSCustomWebControls"
Assembly="PCSCustomWebControls" %>
<html>
<head>
<meta name="GENERATOR" Content="Microsoft Visual Studio 7.0">
<meta name="CODE_LANGUAGE" Content = "C#">
<meta name=vs_defaultClientScript content="JScript">
<meta name=vs_targetSchema content="Internet Explorer 5.0">
</head>
<body MS_POSITIONING="GridLayout">
<form id="WebForm1" method="post" runat="server">
<PCS:WebCustomControl1 Runat="server" Text="Testing again..." />
</form>
</body>
</html>
Теперь, пока библиотека PCSCustomWebControls сконфигурирована как приложение запуска, можно нажать кнопку Debug, чтобы увидеть результаты работы:
Добавим также ссылку на проект PCSCustomWebControls в раздел тестирования приложений:
Затем добавим инструкцию using в пространство имен PCSCustomWebControlsTestApp в WebForm1.aspx.cs:
using PCSCustomWebControls;
Это позволит нам использовать наши специальные элементы управления из кода, скрытого за формой.
Базовые специальные элементы управления
Как можно предположить из результатов предыдущего раздела, образец элемента управления, создаваемый по умолчанию, является версией стандартного элемента управления <asp:Labels>. Создаваемый в файле .cs код проекта, WebCustomControl1.cs, выглядит следующим образом:
namespace PCSCustomWebControls {
using System;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.ComponentModel;
/// <summary>
/// Краткое описание WebCustomControl1
/// </summary>
[DefaultProperty("Text"),
ToolboxData("<{0}WebCustomControl1 runat=server></{0}:WebCustomControl1>")]
public class WebCustomControl1 : System.Web.UI.WebControls.WebControl {
private string text;
[Bindable(true), Category("Appearance"), DefaultValue(" ")]
public string Text {
get {
return text;
}
set {
text = value;
}
}
/// <summary>
/// Предоставить этот элемент управления указанному параметру вывода.
/// </summary>
/// <param name="output"> The HTML writer to write out to </param>
protected override void Render(HtmlTextWriter output) {
output.Write(Text);
}
}
}
Начальные инструкции using для пространств имен вполне стандартны.
Здесь определен единственный класс WebCustomControl1 (отметим, как имя класса отображается прямо в элемент ASP.NET в простом примере, только что увиденном), который является производным из класса WebControl, как обсуждалось ранее. Для этого класса предоставлены два атрибута: DefaultProperty и ToolboxData. Атрибут DefaultProperty определяет, какое свойство будет использоваться по умолчанию для элемента управления в языках, которые поддерживают эту функциональность. Атрибут ToolboxData точно определяет, какой код HTML будет добавлен к странице .aspx, если этот элемент управления добавляется с помощью инструментальной панели Visual Studio (когда проект откомпилирован, можно добавить элемент управления в панель инструментов, конфигурируя панель инструментов для использования созданной сборки).
Класс содержит одно свойство: Text. Это очень простое текстовое свойство, похожее на те, которые встречались раньше. Здесь необходимо отметить только три атрибута:
□ Bindable — показывает, может ли свойство быть связано с данными.
□ Category — задает, будет ли свойство выводиться на страницах свойств.
□ DefaultValue — значение по умолчанию для свойства.
Представление свойств в таком виде работает точно таким же образом, как и для специальных элементов управления, и определенно предпочтительно по отношению к представлению открытых полей.
Остальная часть класса состоит из метода Render(). Это единственный самый важный метод для реализации при создании специальных элементов управления, так как в нем мы получаем доступ к потоку вывода для изображения содержимого элемента управления. Существует только два случая, когда этот метод не нужно реализовывать:
□ Когда создается элемент управления, не имеющий визуального представления (обычно называемый компонентом).
□ Когда создается производный элемент из существующего элемента управления и не требуется изменять характеристики его изображения.
Специальные элементы управления могут также предоставлять специальные методы, инициировать специальные события, и отвечать производным элементам управления (если они существуют). Ниже мы рассмотрим:
□ Создание производных элементов управления
□ Создание композитных элементов управления
□ Создание более развитых элементов управления
Конечный пример будет элементом управления выбором, который разрешает пользователю голосовать за одну из нескольких возможностей, и выводить графически результаты голосования. Варианты выбора будут определяться с помощью вложенных элементов управления потомков способом, описанным ранее.
