Динамическая загрузка пользовательских элементов управления в веб-приложении C #, а не на веб-сайте

Question

Я пытаюсь создать собственную структуру управления веб-сайтом, аналогичную DNN / SiteFinity (только урезанную версию).

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

Я бы предпочел использовать предварительно скомпилированное .NET "Веб-приложение" вместо динамически скомпилированного "Веб-сайта".

Каковы последствия использования метода LoadControl длядинамически добавлять пользовательский элемент управления для предварительно скомпилированных веб-приложений с особым учетом:

1. Сеанс (предположим, я использую сервер состояний)
2. Что происходит со всеми другими пользователями - будетони вышли из системы?
3. Переработка пула приложений из-за изменений в какой-либо компиляции ??

Я не уверен, что когда-либо динамически добавлял пользовательский элемент управления в предварительно скомпилированные веб-приложениятак как я в основном использую «Веб-сайты», поэтому я предполагаю, что он будет работать, потому что, если веб-сайт предварительно скомпилирован, этоn динамически добавляемый пользовательский элемент управления будет динамически компилироваться по мере необходимости, даже если сайт предварительно скомпилирован?

EDIT

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

Спасибо!Dan.

Answer 1

Вы можете динамически добавлять пользовательский элемент управления на своем предварительно скомпилированном веб-сайте.

Я даю описание жизненного цикла пользовательского элемента управления:

Каждый элемент управления на странице имеет уникальный идентификатор, который называется ClientID. (Это фактическое свойство для каждого элемента управления.) Пользовательский элемент управления является «контейнером именования». Это означает, что каждый элемент управления, который он содержит, также содержит идентификатор элемента управления пользователя. Например, «TextBox1» в UserContro l с идентификатором «UserControl1» будет иметь clientID: UserControl1_TextBox1.

Post back возвращает значения из каждого поля по ClientID. Например, чтобы получить указанное выше значение TextBox's из формы, используйте Request.Forms["UserControl1_TextBox1"]. Теперь, что происходит, когда вы заменяете один UserControl другим, который имеет тот же ClientID? Второй получает данные первого.

Рекомендации:

1. Всегда присваивайте уникальный идентификатор UserControl в его свойстве ID.

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

3. Так что на Post_Back, я рекомендую позвонить LoadControl, чтобы получить оригинал UserControl. Затем перед загрузкой второго установите Visible первого свойство false, чтобы удалить его.

Answer 2

1. Нет проблем в сеансе
2. Нет
3. Нет

Мое единственное предложение - вы читаете:

http://weblogs.asp.net/infinitiesloop/archive/2006/08/25/TRULY-Understanding-Dynamic-Controls-_2800_Part-1_2900_.aspx

http://weblogs.asp.net/infinitiesloop/archive/2006/08/30/TRULY-Understanding-Dynamic-Controls-_2800_Part-2_2900_.aspx

http://weblogs.asp.net/infinitiesloop/archive/2006/08/30/TRULY-Understanding-Dynamic-Controls-_2800_Part-3_2900_.aspx

http://weblogs.asp.net/infinitiesloop/archive/2006/10/16/TRULY-Understanding-Dynamic-Controls-_2800_Part-4_2900_.aspx

Тот факт, что вы в настоящее время используете «веб-сайт», а не веб-приложение, не меняет вашу способность динамически добавлять элементы управления. То есть было бы весьма полезно, если бы MS просто удалила «Веб-сайт», поскольку это не создает ничего, кроме проблем. Это другой аргумент для другого дня.