Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, henson, Вы писали:
H>>* Тяжелый deployment O>Поподробнее, плиз. Там же вроде все должно быть примитивно и просто.
Ну я к тому что с появлением WPF .NET Framework дистрибутив прилично вырос в размере. Это может быть не напрямую связано с WPF, но еще один фактор усложняющий процесс.
Ибо сказать клиенту, что мы вот тут вам сейчас качнем быстренько 100 мегабайт может быть непростительной ошибкой. Client Profile поменьше, но все равно больше .NET 2.0 с WinForms
Здравствуйте, henson, Вы писали:
H>Ну я к тому что с появлением WPF .NET Framework дистрибутив прилично вырос в размере. Это может быть не напрямую связано с WPF, но еще один фактор усложняющий процесс. H>Ибо сказать клиенту, что мы вот тут вам сейчас качнем быстренько 100 мегабайт может быть непростительной ошибкой.
Здравствуйте, henson, Вы писали:
H>Ну я к тому что с появлением WPF .NET Framework дистрибутив прилично вырос в размере.
Для интранетовских бизнес приложений это не очень актуально. Особенно, если софт в конторе распространяется и ставится централизованно.
Если совсем критично, что сильверлайт спасет демократию.
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, henson, Вы писали:
H>>Ну я к тому что с появлением WPF .NET Framework дистрибутив прилично вырос в размере. O>Для интранетовских бизнес приложений это не очень актуально. Особенно, если софт в конторе распространяется и ставится централизованно. O>Если совсем критично, что сильверлайт спасет демократию.
Однозначно, сильверлайт еще предпочтительней в плане Security
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, henson, Вы писали:
H>>Ну я к тому что с появлением WPF .NET Framework дистрибутив прилично вырос в размере. Это может быть не напрямую связано с WPF, но еще один фактор усложняющий процесс. H>>Ибо сказать клиенту, что мы вот тут вам сейчас качнем быстренько 100 мегабайт может быть непростительной ошибкой.
Q>dotnetfx35.exe — 231.4 Mb Q>dotNetFx40_Full_x86_x64.exe — 48.1 Mb
Зачем сравнивать размер полного Framework и Client Profile?
Здравствуйте, me2, Вы писали:
me2>Первое время все казалось сложным, но стоит только разобраться — не так и страшно.
А по-моему, всё ровно наоборот: сначала смотришь примитивные примеры — о, да это как два байта переслать! А как начинаешь разбираться — боже мой... чесание левого уха правой рукой, в которую загипсован чесальщик спины для левой ноги. Вот вам простейшая задача, обратите внимание "как всё просто" и... абсолютно неочевидно, переусложнённо, череззаборногузадерищенски. Авторское "Drat and double drat!" достаточно хорошо выражает общую мысль. Нет, не читайте решение — сначала решите сами, а потом спросите себя — стоило ваше время того тривиального эффекта, что вы достигли?
me2>p.s. При большом желании можно так же все в коде писать.
Не "так же", WPF предполагает совершенно другую модель, под которую надо менять мозг и весь опыт. WinForms был намного проще и прямолинейнее в достижении целей.
Мне "гибкость и мощь" WPF напоминает радиоконструктор — если всё чётко по схеме и без выпендрёжей (т.е. кастомизации) — да, спаял и всё работает. Но стоит подумать о снижении помех или увеличении мощности, как понимаешь, что не одними микрофарадами жив конденсатор — СТОЛЬКО всего приходится учить, что полжизни нужно потратить. Чего ради? Ради маркетоидной "гибкости"? Мне не нужна полдюймовая дрель, мне нужна полдюймовая дыра без головной боли — ДРУГИХ забот навалом. Так что в моём видении WPF как-то почертыхается, но потом все всё равно придут к очевидному — затраты на обучение и секс с шаблонами по каждому чиху не окупают результата — либо WPF упростят до дельфийских DFM'ок, либо ещё какую трёхбуквенную хрень придумают.
Здравствуйте, matumba, Вы писали:
M> Вот вам простейшая задача, обратите внимание "как всё просто" и... абсолютно неочевидно, переусложнённо, череззаборногузадерищенски.
Проблема не столько в архитектуре WPF, сколько в абсолютно долбанутых на всю голову авторов дефолтных шаблонов. Увы, практически любая попытка их изменить неизменно заканчивается или вознёй с visual tree, или копипастом всего шаблона с прилегающими стилями и правкой всего с 0.
Если не нравится решение по ссылке, можно добавить такой костыль:
В то же время, чтобы прочувствовать все приятные мелочи WPF, достаточно поработать с 3м сервелатом. Такое ощущение, что разработчики специально убирали фичи, которые на первый взгляд незаметны, но их отсутствие сильно усложняет жизнь
Здравствуйте, Sinix, Вы писали:
S>Проблема не столько в архитектуре WPF....
Ты так реально считаешь? А мне кажется, что "сишарп", превращённый в архимудаические "атрибуты" — это и есть глобальное заблуждение авторов WPF. Шаблоны можно написать любые, но я сомневаюсь, что они смогут покрыть все случаи употребления. А код — мог бы...
S>...или копипастом всего шаблона с прилегающими стилями и правкой всего с 0.
Именно. Поэтому я как-то недоумеваю (мягко говоря) на расхваливателей WPF — либо им заплатили много долларей либо они не решали ничего, сложнее кастомизации ListBoxItem. Возможно и так: решать-то они решали, но затратив в разы больше времени, чем на тупой перекодинг OnPaint — и чего тут расхваливать?
S>В то же время, чтобы прочувствовать все приятные мелочи WPF, достаточно поработать с 3м сервелатом.
Мы же сравниваем не чего ВПФ лучше, а чего он хуже — хуже нормального, нативного кода в отрисовке. Причём если подумать над архитектурой (этакий WinForms-2), можно грамотно скомбинировать стили и контролы-примитивы, комбинация которых (даже несколько контролов) будет решать задачу без простыней кода.
Здравствуйте, matumba, Вы писали:
M>Ты так реально считаешь? А мне кажется, что "сишарп", превращённый в архимудаические "атрибуты" — это и есть глобальное заблуждение авторов WPF. Шаблоны можно написать любые, но я сомневаюсь, что они смогут покрыть все случаи употребления. А код — мог бы...
Вы однозначно не пробовали играться с винформовскими девэкспрессами. Пара строчек стиля в XAML у девекспресса регулярнейше превращается в пару-тройку классов.
M>Именно. Поэтому я как-то недоумеваю (мягко говоря) на расхваливателей WPF — либо им заплатили много долларей...
Много чего. Особенно если сравнивать с глюками винформса и с кастомизацией TreeView/ListView. Спасибо, накушался.
M> Причём если подумать над архитектурой (этакий WinForms-2), можно грамотно скомбинировать стили и контролы-примитивы, комбинация которых (даже несколько контролов) будет решать задачу без простыней кода.
Ок. Простейшая задача. Прибиндьте TreeView к источнику данных. С нормальной производительностью — не перерисовывая всё дерево на каждое изменение коллекции. Сколько у вас уйдёт?
Приммер 2 — заказчик хочет в это дерево добавить экспандер или попап (он сам ещё не определился). Или лишнюю кнопочку на выделенном элементе. Или выравнивание TreeView по правому краю. И да, когда вместо того, чтобы объяснять почему хотелки заказчика фигня, и что только на прототип уйдёт пара дней, ты просто показываешь ч/з 10-20 минут прототип — это круто
M>Ты так реально считаешь? А мне кажется, что "сишарп", превращённый в архимудаические "атрибуты" — это и есть глобальное заблуждение авторов WPF. Шаблоны можно написать любые, но я сомневаюсь, что они смогут покрыть все случаи употребления. А код — мог бы...
Чет троллингом пахнет слегка.
M>Именно. Поэтому я как-то недоумеваю (мягко говоря) на расхваливателей WPF — либо им заплатили много долларей либо они не решали ничего, сложнее кастомизации ListBoxItem. Возможно и так: решать-то они решали, но затратив в разы больше времени, чем на тупой перекодинг OnPaint — и чего тут расхваливать?
Решали, решаем и будем решать. Например, панель навигации как в Outlook.( снизу там такая есть, где почта и т.д.). На WPF это один небольшой класс плюс два шаблона. Во что это выльется на ВинФормах, честно говоря, не знаю.
S>>В то же время, чтобы прочувствовать все приятные мелочи WPF, достаточно поработать с 3м сервелатом.
M> Мы же сравниваем не чего ВПФ лучше, а чего он хуже — хуже нормального, нативного кода в отрисовке. Причём если подумать над архитектурой (этакий WinForms-2), можно грамотно скомбинировать стили и контролы-примитивы, комбинация которых (даже несколько контролов) будет решать задачу без простыней кода.
В общем, если по теме, то Матумба ниасилил. В силу каких причин, не берусь судить. Тут может быть совокупность нескольких факторов. Как минимум не стоит подходить к WPF с мерками WinForms.
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, me2, Вы писали:
me2>>Первое время все казалось сложным, но стоит только разобраться — не так и страшно.
M>А по-моему, всё ровно наоборот: сначала смотришь примитивные примеры — о, да это как два байта переслать! А как начинаешь разбираться — боже мой... чесание левого уха правой рукой, в которую загипсован чесальщик спины для левой ноги. Вот вам простейшая задача, обратите внимание "как всё просто" и... абсолютно неочевидно, переусложнённо, череззаборногузадерищенски. Авторское "Drat and double drat!" достаточно хорошо выражает общую мысль. Нет, не читайте решение — сначала решите сами, а потом спросите себя — стоило ваше время того тривиального эффекта, что вы достигли?
Да не так страшно. Если про ItemsPanelTemplate — вполне нормальное поведение. Список может быть совершенно любым, соответсвенно контейнер элементов должен меняться. Свойство horizontal|vertical — частный случай, так что выносить его в элемент управления не совсем правильно (список может быть вообще "каруселькой"). Про WrapPanel — туда же. У них там изначально все очень абстрактно, вот и получаются всякие якобы не очевидные вещи. Но если поработать с технологией — быстро привыкаешь и становится вполне логичным такое поведение (или просто не обращаешь внимания)
либо они не решали ничего, сложнее кастомизации ListBoxItem. Возможно и так: решать-то они решали, но затратив в разы больше времени, чем на тупой перекодинг OnPaint — и чего тут расхваливать? 
