Общий шаблон Obeserver для пользовательских элементов управления - PullRequest
1 голос
/ 13 октября 2009

Я хочу реализовать универсальный шаблон наблюдателя для пользовательских элементов управления. Каков наилучший способ сделать это?

Существует 3 пользовательских элемента управления: A, B и C. Каждый из этих пользовательских элементов управления представляет собой набор данных. Каждый элемент управления имеет выбор режима отображения (базовый или подробный). Посетитель сайта выбирает, какой режим. При изменении режима отображения на любом из элементов управления другие элементы управления должны отражать это изменение.

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

Я думал, что Шаблон наблюдателя - лучший подход, не так ли? и если да, то есть ли какие-нибудь примеры наилучшего способа добиться этого?

Спасибо, Ричард

Ответы [ 2 ]

1 голос
/ 13 октября 2009

Я имел дело с несколькими пользовательскими элементами управления, которые должны были отвечать на один и тот же фрагмент пользовательского ввода.

Я создал базовую страницу, унаследованную от System.Web.UI.Page. Я включил пользовательский ввод как свойство здесь (подробнее об этом позже).

Я определил этот интерфейс

public interface IRespondToInput 
{
    int InputID 
    {
        get;
        set;
    }
}

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

public int InputID 
{
  get
  { 
    return _inputID 
  }
  set
  {
    _inputID = value;
    SetInputs(this, _inputID);
  }
}

В установщике метода базовой страницы я вызываю процедуру, которая рекурсивно перепрыгивает через иерархию элементов управления, ища что-либо, реализующее IRespondToInput , устанавливая свойство всякий раз, когда был найден пользовательский элемент управления, соответствующий этому интерфейсу. (см. код)

 protected void SetInputs( Control theControl, int theInputID )
    {
        if (theControl.Controls.Count > 0)
        {
            foreach (Control mySubControl in theControl.Controls)
            {
                if (mySubControl is UserControl || mySubControl is System.Web.UI.HtmlControls.HtmlForm)
                {
                    if (mySubControl is IRespondToInput)
                    {
                        ((IRespondToInput)mySubControl).InputID = theInputID;
                    }

                    SetInputs(mySubControl, theInputID);
                }
            }
        }
    }

Это, в свою очередь, вызовет локальные события привязки на пользовательском элементе управления.

По правде говоря, я мог бы вызвать свойство из унаследованной страницы.

например. (в коде управления пользователя сзади)

int mySetting = ((MyBasePage)Page).InputID;

Я просто хотел поместить совместимые элементы управления на совместимую страницу и заставить их работать. Этот подход может работать для вас.

Добавлено для оригинального плаката

Если вы не хотите помещать эту логику в производную базовую страницу, почему бы не создать отдельный UserControl (D - продолжение вашего примера), который инкапсулирует вашу логику переключения, но также находит все элементы управления, реализующие IRespondToInput интерфейс

В этом UserControl ваш установщик будет выглядеть так: -

public int InputID 
{
  get
  { 
    return _inputID 
  }
  set
  {
    _inputID = value;
    SetInputs(Page, _inputID);
  }
}

Включить этот элемент управления в качестве элемента управления UserControls A, B и C.

Таким образом, вам не нужно делать каждую страницу ADerivedPage - вы можете просто разместить элементы управления пользователя на тех страницах, где они вам нужны. И вы будете в порядке, передавая Page в качестве параметра, поскольку он наследуется от Control.

1 голос
/ 13 октября 2009

При изменении режима отображения на любом из элементов управления другие элементы управления должны отражать это изменение.

Почему бы не иметь одну настройку на странице? Зачем умножать одинаковые настройки во всех элементах управления?

Вам может быть интересно посмотреть на DropThings . Его автор также написал книгу, объясняющую, как он это сделал. Создание портала Web 2.0 с ASP.NET 3.5

Building a Web 2.0 Portal with ASP.NET 3.5

...