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

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

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

K>>>Ребят, интересный вопрос в свете "декларативного ГУЯ" и WPF в частности.

K>>>Допустим, есть бизнес-задача, где есть ряд однотипных окон (скажем, диалоги и у всех OK/Cancel).
K>>>Логично было бы, как мастодонты ООП, заделать базовый MyWindow, где есть кнопки OK/Cancel, а однотипные окна унаследовать от этого самого MyWindow и накидать нужные дополнительные редакторы.

K>>Логично сделать окно с общим функционалом, а различающиеся части оформить, например, в виде UserControl и засунуть в окно через всякие ContentPresenter.

K>И что в этом логичного?? Ты ООП вообще в глаза видел? Классы там, наследование...

Открой для себя еще агрегацию.

K>Самое очевидное решение при описании множества схожих объектов — ОБЩИЙ ПРЕДОК. Точка.

Вообще не очевидное. Наследуются где попало, а потом думают от кого унаследовать колёсный танк. Вроде и танк, но не на гусеницах.

K>А вот теперь, исходя из этой модели, хотелось бы посмотреть, что (не)может "декларативный ГУЙ".

Зачем самому себе создавать трудности какой-то выдуманной дурацкой моделью?
Можно конечно суп вилкой есть, но зачем?

K>>Точно можно наследовать окна и кнопочки унаследуются, я так делал и эта дичь работала.

K>Если базовый класс описан ТОЛЬКО в *.cs файле — да. Но это самый неинтересный случай. Не для того придумывали визуальные инструменты, чтобы заниматься внешним видом в коде!

K>Итак, возвращаемся к нерешённой проблеме: базовое окно из xaml+cs и окна-наследники из xaml+cs.

Нет. Делал базовое окно в xaml+cs и наследники так же. Дичь, но работало.

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

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

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

K>>>Ребят, интересный вопрос в свете "декларативного ГУЯ" и WPF в частности.

K>>>Допустим, есть бизнес-задача, где есть ряд однотипных окон (скажем, диалоги и у всех OK/Cancel).
K>>>Логично было бы, как мастодонты ООП, заделать базовый MyWindow, где есть кнопки OK/Cancel, а однотипные окна унаследовать от этого самого MyWindow и накидать нужные дополнительные редакторы.

K>>Логично сделать окно с общим функционалом, а различающиеся части оформить, например, в виде UserControl и засунуть в окно через всякие ContentPresenter.

K>И что в этом логичного?? Ты ООП вообще в глаза видел? Классы там, наследование...

Открой для себя еще агрегацию.

K>Самое очевидное решение при описании множества схожих объектов — ОБЩИЙ ПРЕДОК. Точка.

Вообще не очевидное. Наследуются где попало, а потом думают от кого унаследовать колёсный танк. Вроде и танк, но не на гусеницах.

K>А вот теперь, исходя из этой модели, хотелось бы посмотреть, что (не)может "декларативный ГУЙ".

Зачем самому себе создавать трудности какой-то выдуманной дурацкой моделью?
Можно конечно суп вилкой есть, но зачем?

K>>Точно можно наследовать окна и кнопочки унаследуются, я так делал и эта дичь работала.

K>Если базовый класс описан ТОЛЬКО в *.cs файле — да. Но это самый неинтересный случай. Не для того придумывали визуальные инструменты, чтобы заниматься внешним видом в коде!

K>Итак, возвращаемся к нерешённой проблеме: базовое окно из xaml+cs и окна-наследники из xaml+cs.

Нет. Делал базовое окно в xaml+cs и наследники так же. Дичь, но работало.
UPD. Сейчас подумал, возможно там был UserControl, а не Window, но точно с наследованием было и я не понимаю зачем нужно именно наследование, да еще и в интерфейсе.