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

Допустим, есть бизнес-задача, где есть ряд однотипных окон (скажем, диалоги и у всех OK/Cancel).
Логично было бы, как мастодонты ООП, заделать базовый MyWindow, где есть кнопки OK/Cancel, а однотипные окна унаследовать от этого самого MyWindow и накидать нужные дополнительные редакторы.
А вот фигушки! 'MyWindow' cannot be the root of a XAML file because it was defined using XAML.
Получается, сели мы с этой декларативностью в лужу! Хотя вопрос-то принципиально разрешимый — в том же Delphi можно было спокойно наследовать окна и дополнять контролами.

Может, и в WPF можно заделать какую-никакую наследуемость? Скажем:

<Window>
    <PlaceholderForInheritors />
    
    <Button>OK</>
</>

...и тогда VS будет вместо PlaceholderForInheritors давать редактор для внутренних тегов!
Понятно, что это костыль и кто-то даже захочет что-то вставить ПОСЛЕ кнопки ОК, но тут уж решать — либо космические архитектуры, либо вполне простое решение 99% проблем.

Так или иначе, факт тот, что при всех приятностях декларативности, она проваливается даже на самом базовом принципе ООП.

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

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

K>Допустим, есть бизнес-задача, где есть ряд однотипных окон (скажем, диалоги и у всех OK/Cancel).
K>Логично было бы, как мастодонты ООП, заделать базовый MyWindow, где есть кнопки OK/Cancel, а однотипные окна унаследовать от этого самого MyWindow и накидать нужные дополнительные редакторы.
K>А вот фигушки! 'MyWindow' cannot be the root of a XAML file because it was defined using XAML.
K>Получается, сели мы с этой декларативностью в лужу! Хотя вопрос-то принципиально разрешимый — в том же Delphi можно было спокойно наследовать окна и дополнять контролами.

K>Может, и в WPF можно заделать какую-никакую наследуемость? Скажем:

K>

K><Window>
K>    <PlaceholderForInheritors />
    
K>    <Button>OK</>
K></>
K>

K>...и тогда VS будет вместо PlaceholderForInheritors давать редактор для внутренних тегов!
K>Понятно, что это костыль и кто-то даже захочет что-то вставить ПОСЛЕ кнопки ОК, но тут уж решать — либо космические архитектуры, либо вполне простое решение 99% проблем.

Это решается контролами. На пустую форму с двумя базовыми кнопками помещается требуемый контрол и все.
В Делфи для этого использовались фреймы.

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

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

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

Расширение наследованием не единственный и не самый удобный способ. Только упоротые мастодонты все подряд наследуют. Минус этого, банально, что ты не расширишь окно которое уже унаследовано от чего то другого.
Более гибким является навешивание поведения снаружи (Behavior, attached properties,...). Наследование уместно когда требуется оверайдить виртуальный метод.


K>А вот фигушки! 'MyWindow' cannot be the root of a XAML file because it was defined using XAML.

Не понял откуда ты это взял. Можно запросто сделать наследника MyWindow:Window и юзать этот MyWindow в разметке.
Я даже для кастомных контролов больше не юзаю UserConrol, сразу наследника от Grid например делаешь и готово, это немного ускоряет разгрузку UI.

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

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

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

K>А вот фигушки! 'MyWindow' cannot be the root of a XAML file because it was defined using XAML.
K>Получается, сели мы с этой декларативностью в лужу! Хотя вопрос-то принципиально разрешимый — в том же Delphi можно было спокойно наследовать окна и дополнять контролами.
Просто описывать новое окно надо не только в XAML, но и .CS соответствующий не забыть. Новички часто с этим накалываются.
Но обычно наследовать окна в WPF реально приходится только лишь для каких-то вещей уровня инфраструктуры всего приложения. Всё остальное легче разрулить контролами (потому что окно в WFP — оно тоже контрол)

K>Так или иначе, факт тот, что при всех приятностях декларативности, она проваливается даже на самом базовом принципе ООП.

ООП и декларативность — это лишь инструменты. Равно как и агрегирование.

K>либо космические архитектуры, либо вполне простое решение 99% проблем.
В старину недолго существовало такое интересное явление, как Delphi8 и VCL.Net — там сделали возможность в VCL'ной форме (dfm), с её полностью работоспособным визуальным наследованием, использовать в контролах нетовские источники данных (DataTable и т. п.) Но, увы, "спектакль прошёл успешно, а вот публика провалилась".

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

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

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

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

K>А вот фигушки! 'MyWindow' cannot be the root of a XAML file because it was defined using XAML.
K>Получается, сели мы с этой декларативностью в лужу! Хотя вопрос-то принципиально разрешимый — в том же Delphi можно было спокойно наследовать окна и дополнять контролами.

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

K>Может, и в WPF можно заделать какую-никакую наследуемость? Скажем:

K>

K><Window>
K>    <PlaceholderForInheritors />
    
K>    <Button>OK</>
K></>
K>

K>...и тогда VS будет вместо PlaceholderForInheritors давать редактор для внутренних тегов!
K>Понятно, что это костыль и кто-то даже захочет что-то вставить ПОСЛЕ кнопки ОК, но тут уж решать — либо космические архитектуры, либо вполне простое решение 99% проблем.

K>Так или иначе, факт тот, что при всех приятностях декларативности, она проваливается даже на самом базовом принципе ООП.

В итоге в WPF можно унаследовать окно, а потом еще переназначить стиль, в котором хоть выкинуть кнопки вовсе, хоть засунуть до плейсхолдера, хоть повернуть всё на 90 градусов.
Непонятно только что с этой наркоманией потом делать.

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

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

WPF заточен на композицию, там для такого вообще наследоваться не надо

можно к окну диалога добавить attached property "ButtonsTemplate" c типом DataTemplate,
сделать шаблон окна с контентом и панелью снизу, где помещается UI заданный ButtonsTemplate.
шаблон окна поместить в стиль, и все что остается — это применить стиль диалога к окну или контролу и у него автоматом
к контенту добавится панель с кнопками снизу.
99% кейсов покрывается шаблоном по умолчанию с OK/Cancel, но если надо 1 раз вставить другой вид кнопок, делается без
всяких "запихиваний" молотком

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

BE>Это решается контролами.

Обходные пути я и сам знаю. Вопрос подымается более важный — в принципе построения "декларативных ГУЁв".
Как видно по WPF, если базовое окно сделали на *.cs + *.xaml, унаследоваться и дизайнить уже нельзя. Просто от "окна в *.cs" файле наследоваться можно.

BE>В Делфи для этого использовались фреймы.

Нет. Дельфи прекрасно это делал на "родных окнах".

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

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

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

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

_>Расширение наследованием не единственный и не самый удобный способ. Только упоротые мастодонты все подряд наследуют.

Ясно. Ты из тех стоматологов, которые вместо лечения зубов предлагают перейти на манку. Извините, такой тупейший способ абсолютно неинтересен.


_>Более гибким является навешивание поведения снаружи

Мне не нужна гибкость или какие-то упоротые attached properties. Я хочу общий класс и наследников.

_> Наследование уместно когда требуется оверайдить виртуальный метод.

И кто тебе сказал, что у меня его нет?


K>>А вот фигушки! 'MyWindow' cannot be the root of a XAML file because it was defined using XAML.

_>Не понял откуда ты это взял. Можно запросто сделать наследника MyWindow:Window и юзать этот MyWindow в разметке.

Непонятно, с чего ты решил, что это можно. Видимо, на практике ты этого никогда не делал.
Создай окно, положи на него кнопку (ну или в XAML сбацай). Теперь создай второе окно и унаследуйся от первого. Как только получишь ошибку как у меня, приходи обсуждать.

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

MD>Кнопки — можно, но не нужно. Юзаем контролы и стили, получаем желаемое куда меньшими усилиями.

Почему ты пытаешься решать свою задачу, вместо той, что я описал? Меня не интересуют чужие идеи с контролами, я их и так знаю.
Я поднял принципиальный вопрос недостатка декларативного гуя — он (в текущем виде) абсолютно неюзабелен в рамках ООП парадигмы. Хотя мы уже лет 30 как строим ООП библиотеки "контролов".

MD>Просто описывать новое окно надо не только в XAML, но и .CS соответствующий не забыть. Новички часто с этим накалываются.

Причём тут это?? Я посто создал тривиальное окно, у него уже есть xaml и cs. А теперь я хочу ещё одно окно — наследника первого и чтобы тоже xaml+cs.

MD>Но обычно наследовать окна в WPF реально приходится только лишь для каких-то вещей уровня инфраструктуры всего приложения.

Я уже описал самый что ни на есть бизнес случай: множество однотипных диалогов.

MD> Всё остальное легче разрулить контролами (потому что окно в WFP — оно тоже контрол)

Никакой логики. Мне пофиг, кто Window в суперклассах, я просто хочу окно, унаследованное от другого окна.

MD>ООП и декларативность — это лишь инструменты. Равно как и агрегирование.

Ну вот я и хочу "всего лишь" использовать ООП на ООП-библиотеке! Для чего тогда все эти развесистые классы в WPF?? Чтобы кнопки кастомайзить?
Дай задачу "однотипных диалогов" — даже школьник тут же придумает "базовый класс-окно"! Это самое прямое и очевидное использование наследования.

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

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

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

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

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

И что в этом логичного?? Ты ООП вообще в глаза видел? Классы там, наследование... Самое очевидное решение при описании множества схожих объектов — ОБЩИЙ ПРЕДОК. Точка. А вот теперь, исходя из этой модели, хотелось бы посмотреть, что (не)может "декларативный ГУЙ".


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

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

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

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

K>WPF заточен на композицию, там для такого вообще наследоваться не надо

В этом и беда — WPF заточен! Захардкожен киянками по самые гланды. И ленивость вкорячили где надо и не надо, и MVVM у них, одно только забыли — всё это должны использовать люди.

Итак, снова формулирую проблему: есть однотипные окна, у которых напрашивается общий родитель (и не обязательно только с общим ГУЁм — могут быть виртуальные методы).
Как имея базовое окно (xaml+cs) создать наследников, чтобы их тоже можно было дизайнить и писать код?

K>можно к окну диалога добавить attached property

Да можно хоть маршаллинг на Марс организовать! Я прошу решать не ваши личные задачи, а мою — чистый, незамутнённый ООП в ГУЯх.
Можно сформулировать даже жёстче: вот дал вам архитектор структуру: базовое окно, пара виртуальных методов и какие-то общие контролы. И нужны наследники с кастомными дополнениями. Всё это запилить на WPF. Никому не интересно, что можно чесать правое ухо левой рукой, потому что уже дана чёткая иерархия классов, задача прогера — лишь реализовать это при помощи WPF.
Насколько я вижу, WPF тут лажает по полной.

Здравствуйте, 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, но точно с наследованием было и я не понимаю зачем нужно именно наследование, да еще и в интерфейсе.

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

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

K>>WPF заточен на композицию, там для такого вообще наследоваться не надо

K>В этом и беда — WPF заточен! Захардкожен киянками по самые гланды. И ленивость вкорячили где надо и не надо, и MVVM у них, одно только забыли — всё это должны использовать люди.

K>Итак, снова формулирую проблему: есть однотипные окна, у которых напрашивается общий родитель (и не обязательно только с общим ГУЁм — могут быть виртуальные методы).
K>Как имея базовое окно (xaml+cs) создать наследников, чтобы их тоже можно было дизайнить и писать код?

K>>можно к окну диалога добавить attached property

K>Да можно хоть маршаллинг на Марс организовать! Я прошу решать не ваши личные задачи, а мою — чистый, незамутнённый ООП в ГУЯх.
K>Можно сформулировать даже жёстче: вот дал вам архитектор структуру: базовое окно, пара виртуальных методов и какие-то общие контролы. И нужны наследники с кастомными дополнениями. Всё это запилить на WPF. Никому не интересно, что можно чесать правое ухо левой рукой, потому что уже дана чёткая иерархия классов, задача прогера — лишь реализовать это при помощи WPF.
K>Насколько я вижу, WPF тут лажает по полной.

задача прогера, сделать UI, быстро, с минимумом телодвижений, расширяемо и т.д.
WPF вполне себе годен для этого, но действительно не вяжется с "незамутнённым ООП в ГУЯх"

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

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

_>>Расширение наследованием не единственный и не самый удобный способ. Только упоротые мастодонты все подряд наследуют.

K>Ясно. Ты из тех стоматологов, которые вместо лечения зубов предлагают перейти на манку. Извините, такой тупейший способ абсолютно неинтересен.

Нет, это ты из тех проктологов которые все лечат через задний проход. И кто лучше? Подсказка — оба нужны.

_>>Более гибким является навешивание поведения снаружи

K>Мне не нужна гибкость или какие-то упоротые attached properties. Я хочу общий класс и наследников.

_>> Наследование уместно когда требуется оверайдить виртуальный метод.

K>И кто тебе сказал, что у меня его нет?

Тогда у тебя нет проблем — вперед, ты знаешь сам все ответы.


K>>>А вот фигушки! 'MyWindow' cannot be the root of a XAML file because it was defined using XAML.

_>>Не понял откуда ты это взял. Можно запросто сделать наследника MyWindow:Window и юзать этот MyWindow в разметке.

K>Непонятно, с чего ты решил, что это можно. Видимо, на практике ты этого никогда не делал.
K>Создай окно, положи на него кнопку (ну или в XAML сбацай). Теперь создай второе окно и унаследуйся от первого. Как только получишь ошибку как у меня, приходи обсуждать.

Почувствуй разницу между "нельзя" и "не умею". Правильно то что это и не надо делать. Кактус — он колется если его жрать.
Ты путаешь наследование в коде и разметку. Разметка в принципе не наследуется. Головешку свою включи и подумай, как бы выглядел унаследованый UserControl _с_разметкой_. В разметке что? Новая наследника старая базового? Ни то ни другое. В WinForms тоже можно было наследовать формы и юзерконтролы. Только боль от этого была в перспективе жуткая.

K>Насколько я вижу, WPF тут лажает по полной.

Насколько я вижу у топикстартера ООП мозга. Он в принципе не понимает как это так что ООП молотком ни все забивается
Ну давай еще разжуем. Представь 3 окна. По части фукнционала (т.е. в коде) все одинаково. Но внешний вид разный. И что твой ООП должен делать, что наследовать?
А наследуется ведь только код, конкретные классы. Выходит ты создал бы наследников _только_ ради изменения разметки. Но зачем если можно просто указать другуя разметку.
Просто для этого ни надо юзать USerControl. Для этого есть другой патерн в WPF: создание кода контрола и разные шаблоны. Тебя огорчает что под шаблоны нет такова же дизайнера в студии? Да, это упущение, UserControl легче дизайнить. Но это недостаток тула, студии, и никак ни технологии WPF. К тому же есть Blend, может там проблема решена.

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

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

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

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

Открой для себя "зачем придумывать костыли, когда 40 лет назад уже изобрели ООП".

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

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

Ну с такой логикой вам в мир BASIC, а у нас в ООП наследование и выделение общего предка как бы базовая вещь.

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

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

Выдуманной... но не мной, а "изобретателями ООП". Кто ты такой, чтобы с ними спорить??

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

K>UPD. Сейчас подумал, возможно там был UserControl, а не Window

Вот именно. Внимательно читаем проблему, вникаем, отвечаем.

K>... и я не понимаю зачем нужно именно наследование, да еще и в интерфейсе.

Ну так почитай Буча что ли... он всё разжёвывает, кто такой предок и зачем он нужен! Я это тоже разжевал.
Хочешь писать стотыщ однотипных методов — ради бога, я напишу один и просто унаследуюсь.

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

_>Ты путаешь наследование в коде и разметку. Разметка в принципе не наследуется.

Это в твоём ограниченном воображении. Подыми глаза и посмотри, что я написал в стартовом сообщении.

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

_>Ну давай еще разжуем. Представь 3 окна. По части фукнционала (т.е. в коде) все одинаково.

нет. В коде тоже будут различия — переопределённые методы, свои методы.

_> Но внешний вид разный. И что твой ООП должен делать, что наследовать?

Всё — внешний вид и поведение.

_>А наследуется ведь только код, конкретные классы. Выходит ты создал бы наследников _только_ ради изменения разметки. Но зачем если можно просто указать другуя разметку.

Белиберда полная — учись выражать мысли. Просто посмотри, что я предложил в топике — там пусть и убогонькое, но наследование UI — собсно, его за глаза достаточно.

Ещё один сугубо практический момент задачи:

Допустим даже, что мы вместо прямого решения средствами ООП, забацали чисто WPF-ный костыль "Окно + внутри кастомные контролы".
Но тогда нам нужно решить ещё одну задачу — доступ из контрола к "инфраструктуре" окна-владельца! Потому что если ты захочешь из контрола показать модальное окно, тебе надо будет задать у модального окна Window.Owner — а вот фигушки, из контрола нет (прямого) доступа к окну, на котором он лежит! Т.е. опять костыли — придётся лепить интерфейс, который будет у всех контролов и где можно получить доступ к окну-владельцу. Ну спасибо, чо! Мне ж больше не на что тратить время, кроме как городить хелперы для обхода неуклюжего WPF!

Короче, судя по ответам, я был прав — при разработке WPF на ООП вообще забили — налепили декларативной (и overengineered) шняги, а как ею пользоваться... ну вот же, кнопочки кастомайзятся! "Чего тебе ещё надобно, собака?!" (ц) ИВМП
Смешно сказать — в декларативном файле, который даже в сборку не попадает, нельзя использовать #if ! Зато у нас "облака" и дебильный git.