|
SL/WPF code sharing
|
|||
---|---|---|---|
#18+
SeVaСервис навигации prism перед закрытием окна на автомате вызывает ConfirmNavigationRequest, прописываем его в базовом классе, навсегда забываем об if. Если что-то не устваивает, то переопределяем метод.Что мешает перенести if в базовый класс во всех других случаях? Ничего не мешает. А вот таскать continuationCallback между разными окнами, в случае чуть сложнее одного диалога подтверждения, когда их может быть несколько - это да... ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2011, 06:03 |
|
SL/WPF code sharing
|
|||
---|---|---|---|
#18+
Алексей КА вот таскать continuationCallback между разными окнами, в случае чуть сложнее одного диалога подтверждения, когда их может быть несколько - это да...Да и с одним окном таскать его между методами лениво. Сегодня он где-то там не нужен, завтра понадобится только из-за того, что view поменялся и стал требовать дополнительного диалога. Нуегонах... ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2011, 07:25 |
|
SL/WPF code sharing
|
|||
---|---|---|---|
#18+
1. Меняется не View, а бизнес-логика. 2. Я уже писал, что если нужны изменения, то переопределяем метод. 3. callback никто с собой не таскает, он зашит в сервисе навигации. Рассуждения о том, что во рту могут вырости грибу - не аргументы. Чтобы они не росли есть простые правила гигиены - отсутствие таких "общих" решений с обработчиками событий и code-behind как у тебя. Ты даже этот простой вариант обобщить не можешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2011, 08:41 |
|
SL/WPF code sharing
|
|||
---|---|---|---|
#18+
SeVaРассуждения о том, что во рту могут вырости грибу - не аргументы. Чтобы они не росли есть простые правила гигиены - отсутствие таких "общих" решений с обработчиками событий и code-behind как у тебя. Ты даже этот простой вариант обобщить не можешь.2-й раз уже повторяю, причём тут code-behind. В нём сделано чтобы пример был проще. Принципиальных отличий обработчика события от биндинга на ICommand во вьюмодели в данном случае нет. Впрочем ладно, проехали... ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2011, 11:23 |
|
SL/WPF code sharing
|
|||
---|---|---|---|
#18+
SeVa1. Меняется не View, а бизнес-логика.Как ни странно, View тоже может измениться. SeVa2. Я уже писал, что если нужны изменения, то переопределяем метод.Ну это понятно, полиморфизм возможен только при использовании sliverlight-style ShowDialog. :-) SeVa3. callback никто с собой не таскает, он зашит в сервисе навигации.А вызывающий код должен его вызвать, поэтому его возможно придётся таскать. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2011, 11:44 |
|
SL/WPF code sharing
|
|||
---|---|---|---|
#18+
Алексей КSeVaРассуждения о том, что во рту могут вырости грибу - не аргументы. Чтобы они не росли есть простые правила гигиены - отсутствие таких "общих" решений с обработчиками событий и code-behind как у тебя. Ты даже этот простой вариант обобщить не можешь.2-й раз уже повторяю, причём тут code-behind. В нём сделано чтобы пример был проще. Принципиальных отличий обработчика события от биндинга на ICommand во вьюмодели в данном случае нет. Впрочем ладно, проехали... Принципиальные отличия есть и очень большие: - жесткая связанность - усложнение кода и невнятность - обработчики и события с потенциальной возможностью утечек ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2011, 13:04 |
|
SL/WPF code sharing
|
|||
---|---|---|---|
#18+
SeVaПринципиальные отличия есть и очень большие: - жесткая связанность - усложнение кода и невнятность - обработчики и события с потенциальной возможностью утечекНу а в контексте обсуждаемого вопроса? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2011, 13:09 |
|
|
start [/forum/topic.php?fid=21&msg=37400674&tid=1442184]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
others: | 327ms |
total: | 456ms |
0 / 0 |