Верификация действий

у многих из встроенных действий имеются обязательные свойства, обозначаемые на поверхности визуального конструктора восклицательным знаком, который отображается в правом верхнем углу действия. Для обеспечения подобной возможностью специальных действий потребуется создать специальный класс проверки достоверности (validator).

Такой класс должен наследоваться от System. Workf low . ComponentModel. Compiler .ActivityValidtor и реализовать метод Validate. Этот метод будет вызываться как при первоначальном перетаскивании действий на поверхность визуального конструктора, так и при изменении их свойств. Метод Validate может возвращать любое количество ошибок проверки достоверности, ведь у проверяемого свойства может быть и несколько обязательных свойств.

После написания верификатор ассоциируется с действием с применением атрибута ActivityValidator. Увидеть, как это выглядит на практике, можно в следующем разделе, где приводится пример добавления верификатора действий.

Добавление верификатора

в следующем коде показана реализация верификатора для действия DebugActivity. При вызове метода Validate ему в качестве второго параметра передается действие, а поскольку это должно быть действие DebugActivity, выполняется соответствующая проверка и в случае, если верификатор был по ошибке присоединен к другому классу, генерируется исключение:

public class DebugActivityValidator : ActivityValidator {

public override ValidationErrorCollection Validate (ValidationManager manager, object obj)

DebugActivity act = obj as DebugActivity; if (null == act)

throw new ArgumentException( This validator is only designed to

validate DebugActivity instances ); Этот верификатор предназначен только для проверки экземпляров DebugActivity Извлечение списка возможных ошибок из базового класса ValidationErrorCollection errors = base.Validate (manager, obj);

Выполнение проверки на предмет наличия родителя

if (null != act.Parent)

OK - проверка свойства Message if (string.IsNullOrEmpty(act.Message)) errors.Add(

ValidationError.GetNotSetValidationError( Message ));

return errors;

После проверки допустимости параметра obj, вызывается метод Validate базового класса. Это гарантирует выполнение верификации также и любых наследуемых свойств.

Верификаторы обычно запускаются при компиляции кода и без проверки, подтверждающей наличие у действия родителя, могут на самом деле даже выдавать ошибки и просто во время компиляции класса, от которых нет никакой пользы. Поскольку у действия всегда есть родитель, в данном коде первым делом, до осуществления любых последующих операций по верификации, выполняется именно проверка наличия такового.

Далее необходимо удостовериться в том, что пользователь действительно ввел какое-нибудь значение в свойстве Message действия DebugActivity, поэтому затем в коде выполняется проверка на предмет того, не содержится ли в этом свойстве значение null или пустая строка. Если никакого сообщения не было задано, вызывается метод ValidationError. GetNotSetValidationError () с именем незаданного свойства в качестве параметра.

Напоследок остается только связать этот верификатор с действием DebugActivity путем добавления соответствующего атрибута в само действие. Чтобы сделать это, введите следующий код:

[ActivityValidator(typeof(DebugActivityValidator))] public class DebugActivity : Activity

Sequential Workflov;

-[j debugActivityl

После добавления такого кода вы можете скомпилировать приложение и убедиться в том, что верификация свойства Message действительно происходит. Перетащите на поверхность визуального конструктора новое действие DebugActivity - напротив него должен появиться указывающий на ошибку верификации символ восклицательного знака (рис. 36.16).

Щелкните на нем. Появится раскрывающееся меню с наименованием ошибки или ошибок, которые были выявлены в действии. Поскольку в данном примере был использован метод Рис 36 16 GetNotSetValidationError (), вы можете щелкнуть на каком-

Тестирование рабо- варианте в этом меню и в результате перейти прямо в ячейку шоспособпосши вери- соответствующего свойства. Обратите внимание то, что ошибка фикашора действий верификации будет также отображаться и в ячейке свойства, DebugActivity Р наведении курсора мыши на восклицательный знак внутри такой ячейки будет появляться всплывающая подсказка, содержащая сообщение об ошибке.

Если вы теперь определите значение для свойства Message, верификатор будет вызван снова: он удостоверится в том, что на этот раз были определены все обязательные свойства, и удалит ошибку верификации из пользовательского интерфейса. Обратите внимание, что при наличии ошибок верификации в каких-нибудь действиях успешно скомпилировать само приложение тоже не получится.

Улучшение внешнего вида на этапе проектирования

По сравнению со встроенными действиями действие DebugActivity выглядит на этапе проектирования заметно проще: оно отображается на белом фоне и сопровождается стандартной обобщенной пиктограммой. В настоящем разделе будет показано, как улучшить его внешний вид, добавляя код для прорисовывания фона другого цвета и замены стиля контура пунктиром.

Изменение поведения, отвечающего за прорисовывание действия, осуществляется подобно добавлению верификатора, а именно - созданием пары классов и связыва-

нием их с действием (каковым в данном случае является DebugActivity) с помощью соответствующих атрибутов.

В WWF за визуализацию действия отвечают два класса: АсtivityDesigner и ActivityDesignerTheme. Класс ActivityDesigner позволяет иметь полный контроль над всеми аспектами визуализации и, как правило, применяется для улучшения общего поведения на этапе проектирования за счет добавления дополнительных глифов (графических элементов) на поверхность действия. Путем написания класса конструктора можно полностью изменять визуальное представление действия, но для целей, преследуемых в данном примере, т.е. для изменения цвета фона и кое-каких других простых аспектов действия, вполне хватит класса ActivityDesignerTheme.

Практическое jO

Выполните следующие шаги, чтобы добавить конструктор и тему для действия DebugActivity и тем самым улучшить его внешний вид на этапе проектирования.

1. Создайте класс темы, как показано в следующем коде:

public class DebugActivityTheme : ActivityDesignerTheme {

public DebugActivityTheme(WorkflowTheme theme) : base(theme)

this.BackColorStart = Color.Green; this.BackColorEnd = Color.Yellow;

this.BackgroundStyle = LinearGradientMode.ForwardDiagonal; this.BorderStyle = DashStyle.Dot;

Здесь создается класс, унаследованный от ActivityDesignerTheme, вместе с конструктором, принимающим в качестве единственного параметра экземпляр класса Workf lowTheme, что является обязательным для всех классов тем. В рамках конструктора устанавливаются свойства вроде начального и конечного цвета фона и стиля. Они обеспечивают визуализацию данного действия с использованием градиентной кисти и пунктирного штриха для границ.

2. После написания класса темы можно переходить к написанию класса конструктора. В данном случае нужен не более чем просто пустой класс, поскольку перекрывать какие-то методы конструктора с целью предоставления темы для действия не требуется. Наличие такого класса, однако, все-таки является необходимым. Поэтому создайте его так, как показано ниже:

[ActivityDesignerTheme(typeof(DebugActivityTheme))] public class DebugActivityDesigner : ActivityDesigner

Обратите внимание на присутствие в этом коде атрибута ActivityDesignerTheme: он как раз и служит гарантом того, что поверхность визуального конструктора рабочего потока сможет находить соответствующий класс темы на этапе проектирования.

3. Напоследок осталось только связать специальный конструктор с самим действием. Для этого необходимо использовать атрибут: