N>>... Вашу задачку можно решить ста способами. В зависимости от того, частью чего эта задачка является, какой-то конкретный способ может быть хорош или плох. ... AP>Тем самым у вас растет связность -- у вас наличие остальных частей сущности (в данном случае формы) влияет на способ реализации маленькой части. А мне как раз интересны приемы, которые не приводят к росту связности.
Да с чего вдруг она растет? Я же не про это.
Ваши две формы в чистом виде можно нарисовать за полчаса. Если этим задача ограничивается, то способ вообще не имеет значения, лишь бы он в полчаса реализации укладывался. А если эти две формы будут частью приложения, в котором 200 подобных форм, то я возьму датагрид, который уже умеет карточки рисовать, и задача будет решена в общем виде с минимальной связностью. При этом каждый первый WPF датагрид будет использовать внутри себя xaml. В этом варианте я буду думать только про свои данные и (может быть) немного про темплейты.
Ну а в промежутке может быть масса вариантов. Не для каждой задачи надо выдумывать сущности.
Понимаете в чем дело? Вы начали обсуждать c# и xaml, а теперь скатились к связности. А это же вообще перпендикулярно, можно в шарпе все плохо сделать, а можно в xaml'е никаких архитектурных принципов не нарушить. Так что мы обсуждаем?
N>>... Вам предложили несколько вариантов в надежде, что вы идею поймете. ... AP>Идею я понял, и подробно описал ее недостатки.
Там нет недостатков, которые вы описали. Вы описываете недостатки конкретных маленьких примеров, а не идеи.
Вот если бы вы начали с того, что сделали дизайн просто в терминах ООП и разговаривали об этом, то вам бы и примеры дали близкие к тому, чего вы хотите. Вы же начала разговор с двух формочек, а потом поплыли с одного на другое. А остальным уже не интересно дальше плавать. Конечно, я могу ошибаться.
N>Там нет недостатков, которые вы описали. Вы описываете недостатки конкретных маленьких примеров, а не идеи.
Идея была использовать недоступный для изменений готовый контрол HeaderedContentControl. И вкладывать HeaderedContentControl-ы друг в друга. Это кривизна, было описано почему.
N>Вот если бы вы начали с того, что сделали дизайн просто в терминах ООП и разговаривали об этом, то вам бы и примеры дали близкие к тому, чего вы хотите. Вы же начала разговор с двух формочек, а потом поплыли с одного на другое. А остальным уже не интересно дальше плавать. Конечно, я могу ошибаться.
Еще раз повторю заниматься декомпозицией (я так понял, Вы это назвали ООП) просто так ради самой декомпозиции никому не нужно. И я сам стою на этой позиции. К декомпозиции я обратился только для того, чтобы показать, в чем кривизна предложенного решения. Моя позиция такая, что если выбран хороший инструмент, то о правильной декомпозиции можно не беспокоится, она сама будет вырисовываться при использовании простых приемчиков.
Здравствуйте, Alexander Polyakov, Вы писали:
N>>Вот если бы вы начали с того, что сделали дизайн просто в терминах ООП и разговаривали об этом, то вам бы и примеры дали близкие к тому, чего вы хотите. Вы же начала разговор с двух формочек, а потом поплыли с одного на другое. А остальным уже не интересно дальше плавать. Конечно, я могу ошибаться. AP>Еще раз повторю заниматься декомпозицией (я так понял, Вы это назвали ООП) просто так ради самой декомпозиции никому не нужно. И я сам стою на этой позиции. К декомпозиции я обратился только для того, чтобы показать, в чем кривизна предложенного решения. Моя позиция такая, что если выбран хороший инструмент, то о правильной декомпозиции можно не беспокоится, она сама будет вырисовываться при использовании простых приемчиков.
AP>>Тем самым у вас растет связность -- у вас наличие остальных частей сущности (в данном случае формы) влияет на способ реализации маленькой части. А мне как раз интересны приемы, которые не приводят к росту связности. N>Да с чего вдруг она растет? Я же не про это.
Я же написал что на что у вас влияет. Это лишнее влияние.
N>Ваши две формы в чистом виде можно нарисовать за полчаса. Если этим задача ограничивается, то способ вообще не имеет значения, лишь бы он в полчаса реализации укладывался.
Если время одинаковое, то почему не выбрать решение, которое лучше принимает изменения?
N>А если эти две формы будут частью приложения, в котором 200 подобных форм, то я возьму датагрид, который уже умеет карточки рисовать, и задача будет решена в общем виде с минимальной связностью. При этом каждый первый WPF датагрид будет использовать внутри себя xaml. В этом варианте я буду думать только про свои данные и (может быть) немного про темплейты.
Почему у вас 200 форм является критичной точкой, проходя которую вы будете менять способ решения? Могу предположить, что это решение имеет большие накладные расходы, которые можно оправдать только при наличии 200 форм. Это так?
На C#-е решение диктуется появлением 2-ой секции, а не 200-ой.
N>Если этим задача ограничивается, то способ вообще не имеет значения, лишь бы он в полчаса реализации укладывался. А если эти две формы будут частью приложения, в котором 200 подобных форм, то я возьму датагрид, который уже умеет карточки рисовать, и задача будет решена в общем виде с минимальной связностью. При этом каждый первый WPF датагрид будет использовать внутри себя xaml. В этом варианте я буду думать только про свои данные и (может быть) немного про темплейты.
Зачем там датагрид? Этого решения я пока не понимаю, нужны подробности. Желательно код.
N>Не для каждой задачи надо выдумывать сущности.
Согласен. Надо выбирать “острый” инструмент, тогда правильные сущности появляются сами.
N>а можно в xaml'е никаких архитектурных принципов не нарушить
На xaml-е сценарий с секциями выглядит громоздко, требует больше времени на написание, развитие и сопровождение. Архитектура это или нет, называйте, как хотите, суть от этого не поменяется.
N>Вы начали обсуждать c# и xaml, а теперь скатились к связности. А это же вообще перпендикулярно, можно в шарпе все плохо сделать, а можно в xaml'е никаких архитектурных принципов не нарушить. Так что мы обсуждаем?
Мы обсуждаем выразительные способности двух языков. К связности скатились, потому что перед вами встала задача выбора из ста решений. На языке с высокой выразительной способностью правильное решение пишется при минимальном количестве сведений о задаче, вам же требуется дополнительные сведения, чтобы сделать выбор из ста решений.
Фактически мы обсуждаем отрицательные проявления вот этой философии
One of the primary architectural philosophies used in building WPF was a preference for properties over methods or events. Properties are declarative and allow you to more easily specify intent instead of action. http://msdn.microsoft.com/en-us/library/ms750441.aspx
т.е. майрософтовцы решили, что свойства предпочтительней функций. А на самом деле, именно функция является фундаментальным понятием большинства успешных языков.
Было бы еще полбеды, если они придерживались этой философии только при построении объектной модели WPF. Самое неприятное, что они эту философию распространили на язык -- сделали язык без понятия функции.
P.S. Замечу, что я тоже люблю свойства, в описание моего проекта написано “Property-oriented programming” .
AP>т.е. майрософтовцы решили, что свойства предпочтительней функций. А на самом деле, именно функция является фундаментальным понятием большинства успешных языков.
Вот кто вас научил говорить "на самом деле"? Откуда вы взяли, что ваша точка зрения единственно верная?
Я не читаю всех ваших возражений, ибо бред. Еще раз — идея была не во вкладывании HeaderedContentControl. Вы каждый раз считаете, что вам все ясно, и кто-то должен лоб расшибить, чтобы каждый раз объяснять, чего именно вы не поняли.
В общем, я голосую за то, чтобы перенести эту тему во флуд, где ей и место.
N>В общем, я голосую за то, чтобы перенести эту тему во флуд, где ей и место.
афигеть, сами же не написали ни строчки кода, по большей части анализируете мою личность, вместо обсуждения технических моментов. А теперь во флуд, ... просто нет слов ...
N>>В общем, я голосую за то, чтобы перенести эту тему во флуд, где ей и место. AP>афигеть, сами же не написали ни строчки кода, по большей части анализируете мою личность, вместо обсуждения технических моментов. А теперь во флуд, ... просто нет слов ...
а вы посмотрите, что огребли те, кто вам строчки кода написал. Считаете, что с вами можно обсуждать технические моменты? Вы же тут достаточно много написали, чтобы можно было это понять. Технические моменты я обуждаю тогда, когда мне это интересно. А с вами никак не удается даже сам предмет дискуссии выявить. Каждый раз оказывается, что он был опять в чем-то другом.
Тут есть такой форум, "Священные войны" называется — почитайте. Вы ведете дискуссию как раз в таком стиле. Если эту тему туда перенесут, то вы, скорей всего, только выиграете. Именно там тусуются люди, которые любят поспорить или которым как раз сейчас нечем заняться. А мне лично подобный стиль дискуссий не близок. Поэтому и код вам не пишу. Спросите что-нибудь конкретное в .Net UI — может быть отвечу с кодом.
AP>P.S. Замечу, что я тоже люблю свойства, в описание моего проекта написано “Property-oriented programming” .
Судя по количеству скачавших, идея в массы не пошла... А теперь по существу. Уважаемый, вы, конечно, считаете, что вы всегда правы и ваш подход априори верен во всех случаях. В таких случаях дискуссии не получается. Вы или начинаете придираться к мелочам, либо, как тут верно заметили, утверждаете, что имели в виду совсем другое. В общем, типичное поведение форумного тролля.
Теперь по поводу подхода. Все эти споры по поводу того, что круче, XAML или Ваша реализация, будут валидны только при следующих условиях:
1. Ваша поделка пойдет в массы.
2. Ваша поделка по функционалу не будет уступать XAML.
3. У вашей поделки будет нормальная читабельность кода.
4. У XAML есть возможность загрузить XAML файл в приложение без компиляции проекта. Где такая возможность у Вас?
В заключение, для того, чтобы поднять Ваше ЧСВ, утверждаю:
1. Вы нереально крутой программист, видящий то, что не видят все остальные.
2. Ваша имплементация завоюет мир и Microsoft откажется от XAML как от жалкого подобия Вашего продукта.
3. Миллионы программистов и дизайнеров во всем мире, использующие XAML, коренным образом неправы. Эту ересь надо выжигать каленым железом.
4. Единственно правильная точка зрения на проблемы архитектуры и программирования — Ваша. Все остальные точки зрения по дефолту считаются неправильными и вредными.
Собственно, к чему это я. Присоединяюсь к просьбе notacat перенести данную тему в СВ. Там можно и пофлудить всласть, и полаяться.В данном разделе теме не место, ибо неконструктивно.
В принципе все устраивает. Слегка портит жизнь (но не критично) то, что дизайнер не работает в следующем случае. Если свойство MergeStyle выставлять через property element syntax. Компилируется и запускается, а дизайнер пишет “The attachable property 'MergeStyle' was not found in type 'MergedStyles'.” Может какой-нибудь атрибутик надо вставить?
Кстати, если пойти по ссылке в конце той статьи, то встретим фразу
XAML cannot do everything, and in any good application we need to write code. However if there are some code that are repetitive and we want to declare those code in XAML markup we can write our own markup extensions. http://dotnet.dzone.com/news/extend-wpf-add-your-own-keywor
То есть, народ чтобы избежать дублирования кода применяет кастомные Markup Extension-ы. Но ведь Markup Extension-ы не настолько мощные для решения проблемы дублирования кода как обычные функции (в ООП языках к ним добавляются еще классы).
Отмечу, что моя позиция начинает меняться в сторону XAML-а. С XAML-ом можно попытаться ужиться, набирая костыли для примитивных задачек. Но любви к этому недоязычку вряд ли возникнет. Просто хотелось, чтобы хотя бы примитивные изъезженные задачки были "out of the box".
На простой вопрос ответите? Зачем вы применяете inline стили? Глупо же.
Про "Dependency Property Value Precedence" читали что-нибудь? А поняли?
Если у вас руки тянутся стиль заинлайнить — не мучайтесь, а прямо сразу значения свойств напишите, без стилей. Такое ощущение, что вы просто не знаете, как стиль из ресурсов применить к текст боксу или действительно открыли для себя "множественное наследование".
Нет никакого смысла создавать стиль, если единственная цель — задать локальные значения свойств. Может я какой-то глубины вашей мысли не постигла.
Приведу все-таки строчки кода. Может быть я где-то ошиблась, не охота было проверять ваш пример целиком, прямо в тексте поправила. Но вся ваша простыня должна бы выглядеть примерно так:
N>На простой вопрос ответите? Зачем вы применяете inline стили? Глупо же. N>Про "Dependency Property Value Precedence" читали что-нибудь? А поняли? N>Если у вас руки тянутся стиль заинлайнить — не мучайтесь, а прямо сразу значения свойств напишите, без стилей. N> ... N>Нет никакого смысла создавать стиль, если единственная цель — задать локальные значения свойств. Может я какой-то глубины вашей мысли не постигла.
Просто в демонстрационном примере не стал плодить именованные стили, а сами стили хотелось показать. Никаких других мыслей (или недопониманий с мой стороны) в инлайн стилях нет. В реальном приложении большинство инлайн стилей уйдут в ресурсы, например, для TextBox-а точно уйдет, потому что будет несколько похожих текстбоксов.
Кстати, Вам всегда удается точно определить какие свойства пойдут в стиль, а какие задавать по месту? Просто, если не угадать с этими, и потом переделывать свойства, заданные по месту, на стили/ресурсы -- это не очень приятное занятие (а тулзы с таким автоматическим рефакторингом пока не наблюдается, или я ошибаюсь?). Это аргумент в пользу того, чтобы сразу использовать стили, т.е. пишем инлайн стиль, а потом, если требуется его заиспользовать, переносим в ресурсы. (В CSS это как-то унифицировано, инлайн стили выглядят точно так же, как вынесенные.)
не хотелось делать. Хотелось иметь стиль TextBoxStyle без стиля FontStyle.
N>Такое ощущение, что вы просто не знаете, как стиль из ресурсов применить к текст боксу или действительно открыли для себя "множественное наследование". N>Custom markup extension тут вообще ни с какого боку не нужны. Не надо микроскопом гвозди заколачивать.
А как Вы живете с таким множественным наследование стилей? Терпите? Да же просто при открытии в Visual Studio разметки XAML в списке появляются ошибки и волнистая синяя линия в месте ошибки. Да и дизайнер не работает, для Вас же он критичен.
AP>А как Вы живете с таким множественным наследование стилей? Терпите? Да же просто при открытии в Visual Studio разметки XAML в списке появляются ошибки и волнистая синяя линия в месте ошибки. Да и дизайнер не работает, для Вас же он критичен.
С чего вдруг дизайнер не работает? Пишите нормально и будет вам счастье. Последний раз у меня в WPF дизайнер не работал где-то до первого сервиспака к VS 2008, и то это были специальные баги, которые я постила в MS и они их в сервиспаке фиксили. Вы пока ничего подобного по сложности не изобразили, что бы могло не работать.
А синии линии сами по себе меня не тревожат.
N>С чего вдруг дизайнер не работает? Пишите нормально и будет вам счастье. Последний раз у меня в WPF дизайнер не работал где-то до первого сервиспака к VS 2008, и то это были специальные баги, которые я постила в MS и они их в сервиспаке фиксили. Вы пока ничего подобного по сложности не изобразили, что бы могло не работать. N>А синии линии сами по себе меня не тревожат.
Вы множественное наследование стилей используете? Свойство MergeStyle выставляете через property element syntax?
Мой вышеприведенный XAML дизайнер не открывает. Вот можете взять солюшен в сборе http://files.rsdn.ru/74431/WpfApplication8.zip
N>>С чего вдруг дизайнер не работает? Пишите нормально и будет вам счастье. Последний раз у меня в WPF дизайнер не работал где-то до первого сервиспака к VS 2008, и то это были специальные баги, которые я постила в MS и они их в сервиспаке фиксили. Вы пока ничего подобного по сложности не изобразили, что бы могло не работать. N>>А синии линии сами по себе меня не тревожат. AP>Вы множественное наследование стилей используете? Свойство MergeStyle выставляете через property element syntax?
Нет, не собираюсь, и вам не советую. Вы ничем не обосновали необходимость подобных извращений. А я вам говорю, что в большом проекте от этого будет больше неприятностей, чем пользы.
Здравствуйте, Codechanger, Вы писали:
C>Судя по количеству скачавших, идея в массы не пошла... А теперь по существу. Уважаемый, вы, конечно, считаете, что вы всегда правы и ваш подход априори верен во всех случаях. В таких случаях дискуссии не получается. Вы или начинаете придираться к мелочам, либо, как тут верно заметили, утверждаете, что имели в виду совсем другое. В общем, типичное поведение форумного тролля.
Что-то из вас такая ненависть прет, как будто вас с завтрашнего дня решением Александра Полякова пользоваться заставляют.
C>Теперь по поводу подхода. Все эти споры по поводу того, что круче, XAML или Ваша реализация, будут валидны только при следующих условиях: C> 1. Ваша поделка пойдет в массы. C> 2. Ваша поделка по функционалу не будет уступать XAML. C> 3. У вашей поделки будет нормальная читабельность кода. C> 4. У XAML есть возможность загрузить XAML файл в приложение без компиляции проекта. Где такая возможность у Вас?
C>В заключение, для того, чтобы поднять Ваше ЧСВ, утверждаю: C> 1. Вы нереально крутой программист, видящий то, что не видят все остальные. C> 2. Ваша имплементация завоюет мир и Microsoft откажется от XAML как от жалкого подобия Вашего продукта. C> 3. Миллионы программистов и дизайнеров во всем мире, использующие XAML, коренным образом неправы. Эту ересь надо выжигать каленым железом. C> 4. Единственно правильная точка зрения на проблемы архитектуры и программирования — Ваша. Все остальные точки зрения по дефолту считаются неправильными и вредными.
C>Собственно, к чему это я. Присоединяюсь к просьбе notacat перенести данную тему в СВ. Там можно и пофлудить всласть, и полаяться.В данном разделе теме не место, ибо неконструктивно.
Александр показал, что xaml как язык имеет определенные ограничения, части из которых нет у полноценных языков программирования вроде С#. И предложил обсудить как эти ограничения можно обойти на xaml'е и сравнить это с тем, что может дать кодогенерация. Пользоваться своим решением Александр никого не заставлял и не заставляет. Вы же вместо конструктивного диалога почему-то постоянно скатываетесь на обсуждение личности автора и лозунгам, что xaml это абсолютный идеал.
U>Александр показал, что xaml как язык имеет определенные ограничения, части из которых нет у полноценных языков программирования вроде С#. И предложил обсудить как эти ограничения можно обойти на xaml'е и сравнить это с тем, что может дать кодогенерация.
А не могли бы вы своими словами конспективно перечислить эти ограничения xaml'а и пользу кодогенерации? Я почему-то ни один аргумент Александра воспринять не могу. Мое ощущение, что он просто не понимает, как работать с xaml'ом и делает выводы из неверных предпосылок, никак не изменилось с момента его первого сообщения.
Если вы прониклись, может сможете объяснить так, чтобы кто-то еще понял?
AP>Кстати, Вам всегда удается точно определить какие свойства пойдут в стиль, а какие задавать по месту? Просто, если не угадать с этими, и потом переделывать свойства, заданные по месту, на стили/ресурсы -- это не очень приятное занятие (а тулзы с таким автоматическим рефакторингом пока не наблюдается, или я ошибаюсь?). Это аргумент в пользу того, чтобы сразу использовать стили, т.е. пишем инлайн стиль, а потом, если требуется его заиспользовать, переносим в ресурсы. (В CSS это как-то унифицировано, инлайн стили выглядят точно так же, как вынесенные.)
Я стараюсь не задаваться такими вопросами. Это как анекдот про сороконожку, которую спросили, с какой ноги она шагает.
Вы что, постоянно об этом думаете и рефакторингом занимаетесь?
Ну например для текстбоксов:
— если я знаю, что в приложении будет куча текстбоксов, как в ваших формочках, то логично для них сделать общий дефолтный стиль, куда включить
Padding, Margin, FontSize, FontStyle, VerticalAlignment, MinWidth, можно еще цвета. На самом деле, я бы предпочла ограничиться Padding и Margin, шрифты лучше задавать глобально на родительском элементе. Ну, а если у какого-то конкретного текстбокса что-то должно быть не так, то свойства, заданные в стиле, переопределяются по месту.
Да, Width и Height в моем xaml'е скорей всего вообще не будет, ни в стилях, ни в свойствах. По крайней мере, для текста это должно задаваться выбором адекватного лейаута.
Если уж вы выясняете у дизайнера, как и что должно выглядеть, спросите у него, что общее в оформлении разных элементов, а что индивидуально должно настраиваться. Он вам скажет, а вы общее в стиль вынесете.
Здравствуйте, Undying, Вы писали:
U>Александр показал, что xaml как язык имеет определенные ограничения, части из которых нет у полноценных языков программирования вроде С#. И предложил обсудить как эти ограничения можно обойти на xaml'е и сравнить это с тем, что может дать кодогенерация. Пользоваться своим решением Александр никого не заставлял и не заставляет. Вы же вместо конструктивного диалога почему-то постоянно скатываетесь на обсуждение личности автора и лозунгам, что xaml это абсолютный идеал.
XAML — не идеален. А обсуждение ограничений, как вы это называете, вылилось в итоге в то, что лично я так толком и не понял, чего же автор хочет добиться. Далее была куча умных слов про декомпозицию, master page и т.д. Ничего полезного, кроме увеличения опыта троллинга, я для себя из этой дискуссии не вынес.
.
...
