В ответ на этот постинг

Автор:
Дата: 07.11.02

На самом деле viewstate для UserControl-ов сохраняется, и все обработчики вызываются при соблюдении двух простых правил:

1) При postback нужно перезагружать control в методе OnInit(), чтобы UserControl был загружен до того, как загружается ViewState (например, сохраняем в hidden field путь к контролу, а затем в OnInit смотрим на
Request.Params["CurrentControlPath"])
2) Кроме того, нужно, чтобы всегда control.ID при PostBack был тот же, что и при загрузке. Для этого можно либо
а)выставлять его при первой загрузке control-а и при перезагрузке страницы, либо
б) сохранять его еще в одном hidden field

2 TK Можно требовать от ASP.NET того же, что и от Windows Forms. Я для своей конторы спроектировал что-то вроде системы Wizard-ов для ASP.NET, в которой каждая aspx страница по сути является контроллером use case, а UserControl является отдельной страничкой Wizard-а. Для всех сохраняется состояние, вызываются обработчики и т.п. Теперь дизайнерам этих контролов нужно только писать что-то вроде

OnButtonClick(..)
{
BusinessFacade.DoThis();
_container.MoveNext();
}

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

IMHO, asp.net горазжо лучше подходит для сценариев, когда данные в основном выводятся, а не редактируются/заносятся, т.к. во втором случае из-за stateless-ности asp.net (а)вся нагрузка по хранению промежуточных данных ложится на сервер и(б) усложняется модель программирования.

Здравствуйте, Oganes, Вы писали:

O>В ответ на этот постинг

Автор:
Дата: 07.11.02

O>На самом деле viewstate для UserControl-ов сохраняется, и все обработчики вызываются при соблюдении двух простых правил:

O>1) При postback нужно перезагружать control в методе OnInit(), чтобы UserControl был загружен до того, как загружается ViewState (например, сохраняем в hidden field путь к контролу, а затем в OnInit смотрим на
O>Request.Params["CurrentControlPath"])
O>2) Кроме того, нужно, чтобы всегда control.ID при PostBack был тот же, что и при загрузке. Для этого можно либо
O> а)выставлять его при первой загрузке control-а и при перезагрузке страницы, либо
O> б) сохранять его еще в одном hidden field

O>2 TK Можно требовать от ASP.NET того же, что и от Windows Forms.

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

O>Я для своей конторы спроектировал что-то вроде системы Wizard-ов для ASP.NET, в которой каждая aspx страница по сути является контроллером use case, а UserControl является отдельной страничкой Wizard-а. Для всех сохраняется состояние, вызываются обработчики и т.п. Теперь дизайнерам этих контролов нужно только писать что-то вроде

O>
O>

O>OnButtonClick(..)
O>{
O>BusinessFacade.DoThis();
O>_container.MoveNext();
O>}
O>

O>и дизайном заниматься :) Если интересно, могу код выложить куда-нибудь.

Не знаю что стояла за цель, но по моему мнению городить огород с runtime загрузкой пользовательских элементов (особенно если реализуются п.п. 1 и 2) только ради создания визарда — такое только в страшном сне можно представить.

O>IMHO, asp.net горазжо лучше подходит для сценариев, когда данные в основном выводятся, а не редактируются/заносятся, т.к. во втором случае из-за stateless-ности asp.net (а)вся нагрузка по хранению промежуточных данных ложится на сервер и(б) усложняется модель программирования.

Каждый сам себе усложняет жизнь.

Здравствуйте, TK, Вы писали:


O>>2 TK Можно требовать от ASP.NET того же, что и от Windows Forms.

TK>Можно требовать похожести интерфейса, но добиваться однотипности реализации — это не лучший выход.

Ну, кажется, я не добиваюсь. Просто человек хотел пользоваться ViewStat-ом и обработчиками для своих control-ов. Мне кажется, вполне естественное желание


TK>Не знаю что стояла за цель, но по моему мнению городить огород с runtime загрузкой пользовательских элементов (особенно если реализуются п.п. 1 и 2) только ради создания визарда — такое только в страшном сне можно представить.

Задача такая: есть много операций с бизнес объектами, которые (а)можно проделывать над разными объектами (б) используются в разных вариациях в большом количестве разных UC. В основном операции связаны с добавлением данных и редактированием существующих. Все это должно быть расширяемо.

ASP.NET — потому что deployment Windows Forms в конторе связан с большими трудностями (используется Kaspersky AVP, а Framework с ним не совместим. Уродство конечно, но тут я бессилен )

Что касается "городить огород с runtime загрузкой пользовательских элементов "...
Можно еще прописывать контролы статически, но тогда они будут создаваться при каждой загрузке страницы. Предположим их 5 штук. Тогда работы в 5 раз больше. Или вообще ими не пользоваться, а каждый раз делать переход на новую страницу, передавая ей в качестве параметров ссылку на контроллер use case. Это лучше/быстрее?

Может есть более простое решение?

Здравствуйте, Oganes, Вы писали:

O>>>2 TK Можно требовать от ASP.NET того же, что и от Windows Forms.

TK>>Можно требовать похожести интерфейса, но добиваться однотипности реализации — это не лучший выход.

O>Ну, кажется, я не добиваюсь. Просто человек хотел пользоваться ViewStat-ом и обработчиками для своих control-ов. Мне кажется, вполне естественное желание :)

Вот я бы только не сказал, что использование LoadControl просто для сокрытия/отображения элементов интерфейса это очень естественное решение.

TK>>Не знаю что стояла за цель, но по моему мнению городить огород с runtime загрузкой пользовательских элементов (особенно если реализуются п.п. 1 и 2) только ради создания визарда — такое только в страшном сне можно представить.

O>Задача такая: есть много операций с бизнес объектами, которые (а)можно проделывать над разными объектами (б) используются в разных вариациях в большом количестве разных UC. В основном операции связаны с добавлением данных и редактированием существующих. Все это должно быть расширяемо.

O>ASP.NET — потому что deployment Windows Forms в конторе связан с большими трудностями (используется Kaspersky AVP, а Framework с ним не совместим. Уродство конечно, но тут я бессилен :( )

А в чем выражается не совместимость?

O>
O>Что касается "городить огород с runtime загрузкой пользовательских элементов "...
O>Можно еще прописывать контролы статически, но тогда они будут создаваться при каждой загрузке страницы. Предположим их 5 штук. Тогда работы в 5 раз больше. Или вообще ими не пользоваться, а каждый раз делать переход на новую страницу, передавая ей в качестве параметров ссылку на контроллер use case. Это лучше/быстрее?

Что значит работы в пять раз больше? По сравнению с чем?
И зачем пытаться разместить все на одной странице? Если это wizard с отдельными страницами, то и что мешает сделать так, что-бы каждая страница была-бы со своим уникальным адресом.
И что значит "передавая ссылку на контроллер use case"? чем переход с одной страницы на другую отличается от выполнения того-же postback?

O>Может есть более простое решение?

Ну, оно есть практически всегда. :)

O>>ASP.NET — потому что deployment Windows Forms в конторе связан с большими трудностями (используется Kaspersky AVP, а Framework с ним не совместим. Уродство конечно, но тут я бессилен )

TK>А в чем выражается не совместимость?

Он просто не ставится, если работает AVP. Кроме того, у одного из программеров asp.net не работал. Когда avp удалили, заработало. Скорее всего, это не единственный глюк.

O>>
O>>Что касается "городить огород с runtime загрузкой пользовательских элементов "...
O>>Можно еще прописывать контролы статически, но тогда они будут создаваться при каждой загрузке страницы. Предположим их 5 штук. Тогда работы в 5 раз больше. Или вообще ими не пользоваться, а каждый раз делать переход на новую страницу, передавая ей в качестве параметров ссылку на контроллер use case. Это лучше/быстрее?

TK>Что значит работы в пять раз больше? По сравнению с чем?

С тем, если на странице прописан статически один контрол. Но это, наверное, я прогнал. Если Control1.Disabled == true, то, наверное, он и не парсится. Но в любом случае, работать мой вариант должен лишь чуть-чуть медленнее, чем если все статически закодить. По идее, т.к. все скомпилировано и хранится в памяти, дополнительное время должно тратиться только на переключение между объектами, которые пишут в Response Правда, я не тестил еще

TK>И зачем пытаться разместить все на одной странице? Если это wizard с отдельными страницами, то и что мешает сделать так, что-бы каждая страница была-бы со своим уникальным адресом.

Да наверное ничто не мешает.

TK>И что значит "передавая ссылку на контроллер use case"? чем переход с одной страницы на другую отличается от выполнения того-же postback?

А кто должен следить за тем, с какой странички мы переходим на какую и т.д.? У меня за этим следит сама страничка, которая хранится промежуточные данные между Postback-ами в viewstate. В случае перехода со страницы на страницу это видимо какой-то объект, который выдает название следующей/предыдущей страницы, которую нужно загрузить, поддерживает события типа LastPage и т.д. Его можно хранить в Session и просто передавать между страницами ключ. Еще нужна страничка, которая является точкой входа для всех use cases, инициализирует объкты-контроллеры и т.д.

Но в этом случае куча markup-а и кода будет дублироваться на всех страничках. Я решил со всем этим не возиться. Для каждого use case отдельная страничка. И для все довольно просто в настройке и описании. Например, aspx файл:

<%@ Page language="c#" Codebehind="test1.aspx.cs" AutoEventWireup="false" Inherits="AAA.WebUI.Tests.test1" %>
<%@ Register TagPrefix="uc1" TagName="AppTemplate" Src="../UserControls/Templates/AppTemplate.ascx" %>
<%@ Register TagPrefix="uc1" TagName="WizardTemplate" Src="../UserControls/Templates/WizardTemplate.ascx" %>
<uc1:AppTemplate id="AppTemplate1" runat="server">
<BODY>
<uc1:WizardTemplate
id="WizardTemplate1"
UCName="Добавление регистрационной карточки"
DataObjectName="RegCard"
WizardPagesList="CheckRegNum.ascx; SelectUser.ascx; AA1.ascx; AA2.ascx"
OnSuccess="ShowResult"
runat="server">
</uc1:WizardTemplate>
</BODY>
</uc1:AppTemplate>



O>>Может есть более простое решение?

TK>Ну, оно есть практически всегда.

Здравствуйте, Oganes, Вы писали:

O>Он просто не ставится, если работает AVP. Кроме того, у одного из программеров asp.net не работал. Когда avp удалили, заработало. Скорее всего, это не единственный глюк.

Знал бы ты сколько софта с avp сканером не работает. Что то мне подсказывает что крив avp.

Здравствуйте, Oganes, Вы писали:

O>>>Что касается "городить огород с runtime загрузкой пользовательских элементов "...
O>>>Можно еще прописывать контролы статически, но тогда они будут создаваться при каждой загрузке страницы. Предположим их 5 штук. Тогда работы в 5 раз больше. Или вообще ими не пользоваться, а каждый раз делать переход на новую страницу, передавая ей в качестве параметров ссылку на контроллер use case. Это лучше/быстрее?

TK>>Что значит работы в пять раз больше? По сравнению с чем?

O>С тем, если на странице прописан статически один контрол. Но это, наверное, я прогнал. Если Control1.Disabled == true, то, наверное, он и не парсится. Но в любом случае, работать мой вариант должен лишь чуть-чуть медленнее, чем если все статически закодить. По идее, т.к. все скомпилировано и хранится в памяти, дополнительное время должно тратиться только на переключение между объектами, которые пишут в Response Правда, я не тестил еще :)

TK>>И зачем пытаться разместить все на одной странице? Если это wizard с отдельными страницами, то и что мешает сделать так, что-бы каждая страница была-бы со своим уникальным адресом.

O>Да наверное ничто не мешает.

TK>>И что значит "передавая ссылку на контроллер use case"? чем переход с одной страницы на другую отличается от выполнения того-же postback?

O>А кто должен следить за тем, с какой странички мы переходим на какую и т.д.? У меня за этим следит сама страничка, которая хранится промежуточные данные между Postback-ами в viewstate. В случае перехода со страницы на страницу это видимо какой-то объект, который выдает название следующей/предыдущей страницы, которую нужно загрузить, поддерживает события типа LastPage и т.д. Его можно хранить в Session и просто передавать между страницами ключ. Еще нужна страничка, которая является точкой входа для всех use cases, инициализирует объкты-контроллеры и т.д.

O>Но в этом случае куча markup-а и кода будет дублироваться на всех страничках. Я решил со всем этим не возиться. Для каждого use case отдельная страничка. И для все довольно просто в настройке и описании. Например, aspx файл:

Нужно сделать базовый класс для страницы в котором описать необходимую реализацию и от нее наследоваться. Если используются UserControls, то страницы для отображения конкретного элемента можно вообще реализовывать, а все запросы просто передавать в один обработчик.
В самой сессии можно ничего не хранить. вполне достаточно ViewState для хранения между Postback и HttpContext для сохранения при осуществлении Transfer между страницами.
т.к. каждый на каждую страницу есть один набор элементов управления то и не возникнет проблем с определением того что нужно создавать в Page_Load/Page_Init.

Здравствуйте, Oganes, Вы писали:

O>В ответ на этот постинг

Автор:
Дата: 07.11.02

O>На самом деле viewstate для UserControl-ов сохраняется, и все обработчики вызываются при соблюдении двух простых правил:

O>1) При postback нужно перезагружать control в методе OnInit(), чтобы UserControl был загружен до того, как загружается ViewState (например, сохраняем в hidden field путь к контролу, а затем в OnInit смотрим на
O>Request.Params["CurrentControlPath"])
O>2) Кроме того, нужно, чтобы всегда control.ID при PostBack был тот же, что и при загрузке. Для этого можно либо
O> а)выставлять его при первой загрузке control-а и при перезагрузке страницы, либо
O> б) сохранять его еще в одном hidden field

O>2 TK Можно требовать от ASP.NET того же, что и от Windows Forms. Я для своей конторы спроектировал что-то вроде системы Wizard-ов для ASP.NET, в которой каждая aspx страница по сути является контроллером use case, а UserControl является отдельной страничкой Wizard-а. Для всех сохраняется состояние, вызываются обработчики и т.п. Теперь дизайнерам этих контролов нужно только писать что-то вроде


O>

O>OnButtonClick(..)
O>{
O>BusinessFacade.DoThis();
O>_container.MoveNext();
O>}
O>

O>и дизайном заниматься Если интересно, могу код выложить куда-нибудь.

Очень интересно можешь отослать на daz@list.ru

Здравствуйте, Zorya, Вы писали:

Z>Очень интересно можешь отослать на daz@list.ru

Я не могу перестать удивляться неистребимому желанию людей использовать велосипеды. Вы не пробовали посмотреть User Interface Processing Application Block?

Здравствуйте, Zorya, Вы писали:

Z>Очень интересно можешь отослать на daz@list.ru

Кстати, слабо было посмотреть что сообщению 2 года уже?

Здравствуйте, Gollum, Вы писали:

G>Здравствуйте, Zorya, Вы писали:

Z>>Очень интересно можешь отослать на daz@list.ru

G>Кстати, слабо было посмотреть что сообщению 2 года уже?
Сам, наверное, увидел потом уже

Здравствуйте, trolik, Вы писали:

G>>Кстати, слабо было посмотреть что сообщению 2 года уже?
T>Сам, наверное, увидел потом уже

Ага, даже гневный ответ написал Но стер же