Общий шаблон Obeserver для пользовательских элементов управления

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

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

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

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

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

13.10.2009 09:54:33
2 ОТВЕТА
РЕШЕНИЕ

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

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

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

Создание портала Web 2.0 с ASP.NET 3.5

1
8.02.2017 14:16:13
Пользовательский опыт похож на виджет или гаджет. Независимое управление пользователем, но с возможностью обновления других виджетов / гаджетов в соответствии с этим параметром.
Richard Lennox 13.10.2009 10:06:50
Тогда эта книга для вас. Речь идет о настраиваемом пользовательском портале на основе виджетов.
user151323 13.10.2009 10:19:44
это дало мне достаточно информации для завершения моей работы. Спасибо.
Richard Lennox 22.10.2009 13:38:09

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

Я создал базовую страницу, унаследованную от 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
14.10.2009 14:55:01
Я бы предпочел полностью избежать страницы, если это вообще возможно.
Richard Lennox 14.10.2009 13:25:49