Здравствуйте, adontz, Вы писали:
H>>Как насчет того, чтобы сравнивать WinForms и WPF там где ОБЕ технологии уместны? A>Я уже ответил на этот вопрос. Если бы ты читал мои сообщения, то заметил бы это.
Не, ну ведь правда. Ты привел в пример свою ситуацию, в которую тебе сложно вписать WPF, и предлагаешь нам смотреть на всё сквозь призму этого проекта. Да, я не участвовал в подобных разработках, поэтому по существу на твой пример ответить мне нечего. Но зато было штук семь других внедренных проектов, в которых переход на WPF, насколько я знаю, запланирован. И я уверен, что там он не вызовет проблем. Во многом еще и потому, что заказчики готовы платить за упрощение поддержки решения, к чему в итоге приведет внедрение WPF. Однако, по твоей логике получается, что этого делать не нужно. Причем если мы отбросим пример с терминалом, которого в данном случае нет, то причины для этого "редактор XAML тормозит, intellisense не работает, книжку купить влом".
Здравствуйте, gandjustas, Вы писали:
G>У нас видимо разные "действительности". Веб + ajaj + json + http compression, и меньше передавать уже вряд ли получится. Около килобайта на раундтрип при очень data-intensive приложении. Еще и клиентское кеширование есть.
Если тебе интересно, я могу попытаться посчитать трафик одной терминальной сессии с активно используемой ERP.
A>>К тому же отпадает вопрос о постраничном выводе как таковой. G>Не отпадает потому что постраничный нужен в первую очередь для человека.
Нет нужды в постраничной загрузке и нет нужды в постраничном выводе. При поиске картинок в Гугле постраничного вывода нет. Когда-нибудь постраничный вывод умрёт. Он не нужен людям, он нужет был исключительно для минимизации трафика во времена когда нельзя было подгружать без перезагрузки страницы.
A>>С терминалом можно (правда плохо, но можно) работать даже через GPRS. G>Очень плохо, но можно — считай нельзя.
Про очень никто не говорил. Подтормаживать иногда будет, но работать вполне возможно. Разница заметна, но не катастрофична.
A>>По сравнению с чем? Ты утверждаешь что веб (HTML или Silverlight) лучше WinForms или WPF. G>Угу, потому что работает на любой оси и на мобильных устройствах.
Ой, ну это просто сказки. Под Windows Силверлайт четвёртый, под MacOS третий, под Linux какой-то Мунлайт, который непонятно чему соответствует, под Android и iOS Силверлайта нет. При этом даже четвёртый так убог, что ты советуешь учить пятый.
A>>Разница между Silverlight и WPF не заметна в микроскоп. G>Ты видимо очень много на SL писал что так утверждаешь.
Я правильно ттебя понял, что на Силверлайте писать удобнее, чем на WPF? Если я и ошибаюсь, то явно не в пользу твоих уверждений.
A>>Веб-браузер не даст тебе свободы в UI. Даже клавиатурное сокращение толком назначить нельзя. G>Перехватывай нажатие клавиш и обрабатывай, в чем проблема?
В том что, например, Ctrl+D в файрфоксе создаёт закладку и хоть ты и можешь получить сообщение о том что Ctrl+D нажата, отменить действие по умолчанию ты не можешь. Когда я последний раз смотрел в оОпере было тоже самое. А сколько у нас ещё разных юраузеров разных версий? Везде свободных клавиатурных сочетаний крайне мало.
A>>Silverlight или продвинутый движок HTML тоже. G>Да ну? HTML4 доступен чуть менее чем везде, HTML 5 доступен на любом десктопе. А что насчет remote desktop?
Вот как раз Remote Desktop действительно везде доступен. Все версии Windows, все версии Windows Mobile, Windows Phone 7, MacOS, Linux. Причём пользователь получит абсолютно одинаковый UX и не надо думать об особенностях ОС на которйо он сидит. По факту RDP доступен на большем количестве платформе, чем Silverlight.
A>>Это неправда. Ставишь второй терминал, настраиваешь NLB, забываешь о проблеме. Я работал с фермами терминалов, никакой проблемы масштабирования там нет. G>Это на словах просто, а на деле не каждый админ потянет. По сравнению с масштабированием веб-решений на порядок сложнее.
Ой, ну что за глупости. Любая подобная балансировка нагрущзки под Windows делается через NLB, будет это 80й порт или 3389 порт, значения не имеет. Тот кто сделает одно, сделает и другое.
A>>Тоже не правда. Наоборот, в среде развитого домена Active Directory тебе вообще не надо что-либо настраивать, потому что все пользователи уже есть, уже объединены в группы и т.д. G>Я не про AD, его можно и в вебе использовать, я про разрешения на сервере терминалов и в приложении.
На сервер терминалов никаких особых разрешений задачать не надо, разве что сразу на всех через групповые политики. Разрешения в приложении вообще не зависят от способа подключения.
A>>Сколько стоит программист у которого хватит навыков? Сколько стоят два таких программиста (один мало, риски)? Зачем платить больше? G>Ну программисты на вебе, как ни странно, стоят дешевле админов, умеющих NLB поднимать.
Ты заблуждаешься. NLB поднять — пятиминутное дело.
Здравствуйте, gandjustas, Вы писали:
S>>DataTrigger-ы, команды, multibinding, FlowDocument, {DynamicResource}, биндинг к xpath, объединение ресурсов, наследование стилей — это только то, что я с ходу вспомнил; если покопаться — наберу раза в 2 больше. Большей части нет в SL4 и даже в 5. Ну и нафига? G>1)Большинство нафиг не нужно
Тут не КСВ и "___ не нужен" — ни разу не довод. Плиз, давайте будем обосновывать своё мнение
G>2)SL это не только веб, но и windows phone
Угумс. Проблема в том, что мне периодически стучится в аську товарищ, занимаюшийся разработкой под WP7.
С самыми элементарными вопросами — как выровнять текст по ширине, как использовать compiled-регэксы, как захостить flow document, как показать gif, как прибиндиться с {RelativeSource AncestorType}, как поставить биндинг в стиле, как менять картинку в зависимости от значения нескольких свойств, как динамически менять оформление...
Я тоже должен был отвечать — оно всё не нужно?
G>ЗЫ. Мне вообще-то искренне жаль людей, которые сначала освоили WPF, а потом пересели на SL.
Аналогично.
Здравствуйте, MxMsk, Вы писали:
A>>Я уже ответил на этот вопрос. Если бы ты читал мои сообщения, то заметил бы это. MM>Не, ну ведь правда. Ты привел в пример свою ситуацию, в которую тебе сложно вписать WPF, и предлагаешь нам смотреть на всё сквозь призму этого проекта. Да, я не участвовал в подобных разработках, поэтому по существу на твой пример ответить мне нечего. Но зато было штук семь других внедренных проектов, в которых переход на WPF, насколько я знаю, запланирован. И я уверен, что там он не вызовет проблем. Во многом еще и потому, что заказчики готовы платить за упрощение поддержки решения, к чему в итоге приведет внедрение WPF.
Если у тебя один (малое и ограниченное сверху количество) заказчик и сложный интерфейс программы является существенной её частью, то безусловно WPF может быть (и во многих случаях будет) привлекательной альтернативой.
MM>Однако, по твоей логике получается, что этого делать не нужно. Причем если мы отбросим пример с терминалом, которого в данном случае нет, то причины для этого "редактор XAML тормозит, intellisense не работает, книжку купить влом".
По моей логике получается, что случаи бывают разные и не надо кричать "А-а-а-а, все учите WPF, лучше консоль, чем WinForms!", это не адекватно. Есть большие сектора разработки ПО в которых красота интерфейса далеко не на первом месте. Я своими глазами видел Dynamics NAV и меня от него тошнит. Я своими глазами видел 1С, в базовой конфигурации терпимо, но после переделок франчиз он может быть просто ужасен. За них платят миллионы. Я делаю выводы о важности красивого интерфейса для некоторых весьма платежеспособных категорий заказчиков. Байндинг из коробки в WPF лучше, всякие MVVM прикрутить проще. Вопрос только в том, чтобы не зацикливаться на технологиях. У меня сейчас есть программа просто сказка. WinForms, да, но один из лучших экземпляров. Красивый интерфейс, оптимизирован под разботу с клавиатурой, на трёх языках, везде автодополнение, цветовая индикация. Всё гармонично, качественный дизайн. А у клиента стоит программа на одном языке (причём не государственном), с существенно меньшим функционалом и... в ней нет двух кнопок одинакового размера, нет двух полей одинакового размера. Окна программы это хаотичные нагромождения элементов управления. Но старая программа им нравится! И я свою лапочку переделываю в говно, потому что они так привыкли. Вот эта жопа и есть реалии бизнеса. Интересует меня в такой ситуации крутой бандинг в WPF? Ничуть.
P.S. XAML редактор тормозит. Честно-честно. Это заметный минус, но, конечно, не фатальный недостаток. У Дельфи дизайнер не тормозит, но это же не заставлят меня говорить глупости А книжку я купил два года назад. Она уже неактуальна
Здравствуйте, adontz, Вы писали:
A>По моей логике получается, что случаи бывают разные и не надо кричать "А-а-а-а, все учите WPF, лучше консоль, чем WinForms!", это не адекватно. Есть большие сектора разработки ПО в которых красота интерфейса далеко не на первом месте. Я своими глазами видел Dynamics NAV и меня от него тошнит. Я своими глазами видел 1С, в базовой конфигурации терпимо, но после переделок франчиз он может быть просто ужасен. За них платят миллионы. Я делаю выводы о важности красивого интерфейса для некоторых весьма платежеспособных категорий заказчиков. Байндинг из коробки в WPF лучше, всякие MVVM прикрутить проще. Вопрос только в том, чтобы не зацикливаться на технологиях. У меня сейчас есть программа просто сказка. WinForms, да, но один из лучших экземпляров. Красивый интерфейс, оптимизирован под разботу с клавиатурой, на трёх языках, везде автодополнение, цветовая индикация. Всё гармонично, качественный дизайн. А у клиента стоит программа на одном языке (причём не государственном), с существенно меньшим функционалом и... в ней нет двух кнопок одинакового размера, нет двух полей одинакового размера. Окна программы это хаотичные нагромождения элементов управления. Но старая программа им нравится! И я свою лапочку переделываю в говно, потому что они так привыкли. Вот эта жопа и есть реалии бизнеса. Интересует меня в такой ситуации крутой бандинг в WPF? Ничуть.
С такой позицией я могу согласиться. Если бы ты еще удержался от стебя над "крутым байндингом", был бы совсем респект.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>У нас видимо разные "действительности". Веб + ajaj + json + http compression, и меньше передавать уже вряд ли получится. Около килобайта на раундтрип при очень data-intensive приложении. Еще и клиентское кеширование есть. A>Если тебе интересно, я могу попытаться посчитать трафик одной терминальной сессии с активно используемой ERP.
Ну это надо сравнить с объемом данных для веба.
A>>>К тому же отпадает вопрос о постраничном выводе как таковой. G>>Не отпадает потому что постраничный нужен в первую очередь для человека. A>Нет нужды в постраничной загрузке и нет нужды в постраничном выводе. При поиске картинок в Гугле постраничного вывода нет. Когда-нибудь постраничный вывод умрёт. Он не нужен людям, он нужет был исключительно для минимизации трафика во времена когда нельзя было подгружать без перезагрузки страницы.
Это чисто визуальный трюк, который по сути делает тот же постраничный вывод.
A>>>С терминалом можно (правда плохо, но можно) работать даже через GPRS. G>>Очень плохо, но можно — считай нельзя. A>Про очень никто не говорил. Подтормаживать иногда будет, но работать вполне возможно. Разница заметна, но не катастрофична.
Я вот с sharepoint много работаю. Открываю со своего ноута сайт — нормально работает, при этом remote desktop на ту же машину довольно ощутимо тормозит.
Весь прикол в том что remote desktop имеет латентность на каждое действие, а веб — только на отправку данных.
A>>>По сравнению с чем? Ты утверждаешь что веб (HTML или Silverlight) лучше WinForms или WPF. G>>Угу, потому что работает на любой оси и на мобильных устройствах.
A>Ой, ну это просто сказки. Под Windows Силверлайт четвёртый, под MacOS третий,
Ты неправду говоришь. http://go.microsoft.com/fwlink/?LinkID=188040 — Silverlight 4 для макоси http://go.microsoft.com/fwlink/?LinkId=213905 — Silverlight 5 для макоси
A>под Linux какой-то Мунлайт, который непонятно чему соответствует
Это очень легко проверить: запустил, посмотрел где отвалилось, посмотрел в инете как поправить чтобы работало и так несколько раз.
Примерно на уровне SL3 сейчас.
A>под Android и iOS Силверлайта нет.
И не надо, SL то нужен для печати и все. Нафиг не надо с телефона печатать...
В итоге: без напряга получаем полный функционал для Windows, MacOs. Ограниченный под *nix и мобильные устройства.
Если постараться, то и под Linux помжно получить полный функционал.
A>При этом даже четвёртый так убог, что ты советуешь учить пятый.
Я советую учить пятый потому что к моменту когда человек что-то изучит пятый уже зарелизится.
Какой смысл изучать предыдущие версии?
A>>>Разница между Silverlight и WPF не заметна в микроскоп. G>>Ты видимо очень много на SL писал что так утверждаешь. A>Я правильно ттебя понял, что на Силверлайте писать удобнее, чем на WPF? Если я и ошибаюсь, то явно не в пользу твоих уверждений.
Нет, я утверждаю что разница между ними есть, это ты выдумал утверждение до "писать на sl удобнее, чем на wpf".
A>>>Веб-браузер не даст тебе свободы в UI. Даже клавиатурное сокращение толком назначить нельзя. G>>Перехватывай нажатие клавиш и обрабатывай, в чем проблема?
A>В том что, например, Ctrl+D в файрфоксе создаёт закладку и хоть ты и можешь получить сообщение о том что Ctrl+D нажата, отменить действие по умолчанию ты не можешь. Когда я последний раз смотрел в оОпере было тоже самое. А сколько у нас ещё разных юраузеров разных версий? Везде свободных клавиатурных сочетаний крайне мало.
Дык не используй Ctrl+D. В чем проблема?
Тебе десятка сочетаний хватит? Я думаю везде найдется.
Больше наверное и запомнить сложно.
A>>>Silverlight или продвинутый движок HTML тоже. G>>Да ну? HTML4 доступен чуть менее чем везде, HTML 5 доступен на любом десктопе. А что насчет remote desktop?
A>Вот как раз Remote Desktop действительно везде доступен. Все версии Windows, все версии Windows Mobile, Windows Phone 7, MacOS, Linux.
Этот софт надо ставить.
A>Причём пользователь получит абсолютно одинаковый UX и не надо думать об особенностях ОС на которйо он сидит.
Что-то я соменваюсь что пользователи обрадуются увидев "абсолютно одинаковый UX" на телефоне.
A>По факту RDP доступен на большем количестве платформе, чем Silverlight.
Что-то я пока не увидел "больше", не забывай что для веба sl использоваться будет только для расширения возможностей браузера.
A>>>Это неправда. Ставишь второй терминал, настраиваешь NLB, забываешь о проблеме. Я работал с фермами терминалов, никакой проблемы масштабирования там нет. G>>Это на словах просто, а на деле не каждый админ потянет. По сравнению с масштабированием веб-решений на порядок сложнее. A>Ой, ну что за глупости. Любая подобная балансировка нагрущзки под Windows делается через NLB, будет это 80й порт или 3389 порт, значения не имеет. Тот кто сделает одно, сделает и другое.
Ну тоже неверно, гугли webfarmframework.
A>>>Тоже не правда. Наоборот, в среде развитого домена Active Directory тебе вообще не надо что-либо настраивать, потому что все пользователи уже есть, уже объединены в группы и т.д. G>>Я не про AD, его можно и в вебе использовать, я про разрешения на сервере терминалов и в приложении. A>На сервер терминалов никаких особых разрешений задачать не надо, разве что сразу на всех через групповые политики. Разрешения в приложении вообще не зависят от способа подключения.
Ну как-бы реальный пример: одна говнопрограмма, запускающаяся под rdp требовала очень высоких прав для работы (типа писать в HKLM) хотела. Админы не подумали и дали права админа на сервере. В итоге кто-то повалил весь сервак имея эти самые права.
После этого админы еще долго мучались вылизывая разрешения чтобы и прога работала и свалить что-то нельзя было.
Слой абстракции в виде веба полностью решает проблемы.
A>>>Сколько стоит программист у которого хватит навыков? Сколько стоят два таких программиста (один мало, риски)? Зачем платить больше? G>>Ну программисты на вебе, как ни странно, стоят дешевле админов, умеющих NLB поднимать. A>Ты заблуждаешься. NLB поднять — пятиминутное дело.
Я поднимал, а также видел админов, которые не могли. Админов, которые могли, кстати получилось сильно меньше, чем веб-програмистов.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>DataTrigger-ы, команды, multibinding, FlowDocument, {DynamicResource}, биндинг к xpath, объединение ресурсов, наследование стилей — это только то, что я с ходу вспомнил; если покопаться — наберу раза в 2 больше. Большей части нет в SL4 и даже в 5. Ну и нафига? G>>1)Большинство нафиг не нужно S>Тут не КСВ и "___ не нужен" — ни разу не довод. Плиз, давайте будем обосновывать своё мнение
обоснование: sl и без этого прекрасно работает, причем уже пятую версию клепают. То что реально нужно — включают в sl. Команды сделали, Implicit Templates сделали
G>>2)SL это не только веб, но и windows phone S>Угумс. Проблема в том, что мне периодически стучится в аську товарищ, занимаюшийся разработкой под WP7. S>С самыми элементарными вопросами — как выровнять текст по ширине, как использовать compiled-регэксы, как захостить flow document, как показать gif, как прибиндиться с {RelativeSource AncestorType}, как поставить биндинг в стиле, как менять картинку в зависимости от значения нескольких свойств, как динамически менять оформление...
S>Я тоже должен был отвечать — оно всё не нужно?
FlowDocument и динамически менять оформление в wp7? А человек точно понимает что он делает?
Я же говорю — большая часть нафиг не нужна. Этим просто не надо заниматься.
ХЗ, на сайте Эпла я 4 и 5 не нашёл.
A>>под Android и iOS Силверлайта нет. G>И не надо, SL то нужен для печати и все. Нафиг не надо с телефона печатать...
Ты глубоко не прав. Я знаю с десяток компаний которые печатают с телефонов (или устройств аналогичных характеристик) на матричные принтеры через блютуз адаптер.
G>Дык не используй Ctrl+D. В чем проблема? G>Тебе десятка сочетаний хватит? Я думаю везде найдется. G>Больше наверное и запомнить сложно.
Ctrl+Alt+Shift+F7 свободно может и везде, но толку от этого никакого. Есть общепринятые сочетания клавиш, есть сочетания клавиш, которые были в какой-то другой, знакомой, программе и т.д.
A>>Вот как раз Remote Desktop действительно везде доступен. Все версии Windows, все версии Windows Mobile, Windows Phone 7, MacOS, Linux. G>Этот софт надо ставить.
А Силверлайт не надо? Кстати под Windows ставить RDP не надо.
A>>По факту RDP доступен на большем количестве платформе, чем Silverlight. G>Что-то я пока не увидел "больше", не забывай что для веба sl использоваться будет только для расширения возможностей браузера.
Ну сравни списки и увидишь.
A>>Ой, ну что за глупости. Любая подобная балансировка нагрузки под Windows делается через NLB, будет это 80й порт или 3389 порт, значения не имеет. Тот кто сделает одно, сделает и другое. G>Ну тоже неверно, гугли webfarmframework.
Это вообще другого уровня решение. NLB компонент ОС администрирование которого входит в програмы базовой сертификации.
A>>На сервер терминалов никаких особых разрешений задачать не надо, разве что сразу на всех через групповые политики. Разрешения в приложении вообще не зависят от способа подключения. G>Ну как-бы реальный пример: одна говнопрограмма, запускающаяся под rdp требовала очень высоких прав для работы (типа писать в HKLM) хотела. Админы не подумали и дали права админа на сервере. В итоге кто-то повалил весь сервак имея эти самые права.
Это крайне редкая проблема + неправильное её решение.
G>После этого админы еще долго мучались вылизывая разрешения чтобы и прога работала и свалить что-то нельзя было. G>Слой абстракции в виде веба полностью решает проблемы.
Связь между странной попыткой записи в HKLM и вебом чуть менее чем никакая.
A>>Ты заблуждаешься. NLB поднять — пятиминутное дело. G>Я поднимал, а также видел админов, которые не могли. Админов, которые могли, кстати получилось сильно меньше, чем веб-програмистов.
Таких "админов", которые не умеют администрировать базовые компоненты ОС, надо гнать. Я видел "админа", который не знал что такое DNS. Я же не стал после этого везде использовать IP адреса Есть стандартное решение. Либо оно используется, либо пишем служебную записку о непрофпригодности. Велосипеды в продакшене мне не нужны.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Весь прикол в том что remote desktop имеет латентность на каждое действие, а веб — только на отправку данных. A>Согласен. Но на практике это не создаёт заметных проблем.
Угу, наверное поэтому на вебе делается на порядок больше, чем с использование remote desktop. Просто ты привык и проблем не замечаешь, хотя многое можно было бы сделать проще.
A>>>под Android и iOS Силверлайта нет. G>>И не надо, SL то нужен для печати и все. Нафиг не надо с телефона печатать... A>Ты глубоко не прав. Я знаю с десяток компаний которые печатают с телефонов (или устройств аналогичных характеристик) на матричные принтеры через блютуз адаптер.
А смысл мобильные устройства на то и мобильные чтобы их можно было носить с собой везде. В поезде или машине например, принтер такими свойствами не обладает. 0.00001% юзкейсов даже рассматривать не хочу.
G>>Дык не используй Ctrl+D. В чем проблема? G>>Тебе десятка сочетаний хватит? Я думаю везде найдется. G>>Больше наверное и запомнить сложно.
A>Ctrl+Alt+Shift+F7 свободно может и везде, но толку от этого никакого. Есть общепринятые сочетания клавиш, есть сочетания клавиш, которые были в какой-то другой, знакомой, программе и т.д.
Самые частоиспользуемые и так работают, они завязаны на редактирование текста.
A>>>Вот как раз Remote Desktop действительно везде доступен. Все версии Windows, все версии Windows Mobile, Windows Phone 7, MacOS, Linux. G>>Этот софт надо ставить.
A>А Силверлайт не надо?
Если Windows Update включен, то не надо, страница сама предлагает, administrative effort нулевой.
A>>>Ой, ну что за глупости. Любая подобная балансировка нагрузки под Windows делается через NLB, будет это 80й порт или 3389 порт, значения не имеет. Тот кто сделает одно, сделает и другое. G>>Ну тоже неверно, гугли webfarmframework. A>Это вообще другого уровня решение. NLB компонент ОС администрирование которого входит в програмы базовой сертификации.
Угу, я на одного сертифицированного вижу 10 абсолютно безграмотных админов. Ситуация со временем не меняется.
A>>>На сервер терминалов никаких особых разрешений задачать не надо, разве что сразу на всех через групповые политики. Разрешения в приложении вообще не зависят от способа подключения. G>>Ну как-бы реальный пример: одна говнопрограмма, запускающаяся под rdp требовала очень высоких прав для работы (типа писать в HKLM) хотела. Админы не подумали и дали права админа на сервере. В итоге кто-то повалил весь сервак имея эти самые права.
A>Это крайне редкая проблема + неправильное её решение.
Это как раз крайне частая проблема. Куча десктопного кастомного софта требуют права админа.
Правильное решение проблемы это затраты, которые заранее никто не планировал.
G>>После этого админы еще долго мучались вылизывая разрешения чтобы и прога работала и свалить что-то нельзя было. G>>Слой абстракции в виде веба полностью решает проблемы.
A>Связь между странной попыткой записи в HKLM и вебом чуть менее чем никакая.
Для веба сильно другой инструментарий используется, другие привычки и гайдлайны. 99,9% веб-разработчиков и не подумают в реестр писать, а куча десктопных программ, требующие права админа — факт.
Здравствуйте, gandjustas, Вы писали:
G>>>Весь прикол в том что remote desktop имеет латентность на каждое действие, а веб — только на отправку данных. A>>Согласен. Но на практике это не создаёт заметных проблем. G>Угу, наверное поэтому на вебе делается на порядок больше, чем с использование remote desktop. Просто ты привык и проблем не замечаешь, хотя многое можно было бы сделать проще.
Оба утверждения странные. Приложение не делается для терминала как-то особенно, поэтому как ты сравнил количество бизнес-приложений на вебе и в терминале я не понимаю. И я не использую терминал сам, поэтому я не мог к чему-либо привыкнуть. Я пишу приложения, которые время-от времени используют и в терминале тоже, но я их пишу так, что мне не надо их переписывать. Иногда о том что приложения используется в терминале я узнаю чуть-ли не последним.
A>>Ты глубоко не прав. Я знаю с десяток компаний которые печатают с телефонов (или устройств аналогичных характеристик) на матричные принтеры через блютуз адаптер. G>А смысл мобильные устройства на то и мобильные чтобы их можно было носить с собой везде. В поезде или машине например, принтер такими свойствами не обладает. 0.00001% юзкейсов даже рассматривать не хочу.
Ну вот ты не разбираешься в предметной области, а опять навешиваешь ярлыки. Принтер в машине, это мобильные сотрудники, которые ездят на служебных машинах. Так работают абсолютно все дистрибьюторские компании с которыми я общался: еда, билеты, стиральные порошки.
A>>Ctrl+Alt+Shift+F7 свободно может и везде, но толку от этого никакого. Есть общепринятые сочетания клавиш, есть сочетания клавиш, которые были в какой-то другой, знакомой, программе и т.д. G>Самые частоиспользуемые и так работают, они завязаны на редактирование текста.
Ты заблуждаешься.
A>>А Силверлайт не надо? G>Если Windows Update включен, то не надо, страница сама предлагает, administrative effort нулевой.
А RDP есть и без WU.
A>>Это крайне редкая проблема + неправильное её решение. G>Это как раз крайне частая проблема. Куча десктопного кастомного софта требуют права админа. G>Правильное решение проблемы это затраты, которые заранее никто не планировал.
Я не знаю откуда ты взял эту кучу. Я уже очень давно с таким не сталкивался.
A>>Связь между странной попыткой записи в HKLM и вебом чуть менее чем никакая. G>Для веба сильно другой инструментарий используется, другие привычки и гайдлайны. 99,9% веб-разработчиков и не подумают в реестр писать, а куча десктопных программ, требующие права админа — факт.
Зато они запросто подумают что база должна быть MDB, потому что на халявном хостинге, на котором лежит демо, нет MSSQL и лежать она должна в папке C:\Inetpub\ потому что этот путь зашит в программе. Накосячить можно везде. Терминал это ещё и SSO, а вот как твоё веб-приложение пройдёт аудит безопасности вопрос отдельный.
Сабж тоже интересует, т.к. ни одном ни в другом я не копенгаген, но надо прибиваться какому-то берегу. Прежде всего интересуют обычные Windows GUI программы, можно сказать так называемые толстые клиенты, т.е. то, что когда-то делалось на MFC или "голом" Win32 API (QT не предлагать). Свистелки и перделки типа воспроизведения аудио/видео интересуют в последнюю очередь и то если их можно просто добавить. Предположим, надо разработать отображение табличных данных по типу Excel. Будет ли достаточно winform для подобных приложений? Kак я понял из обсуждения, WPF это очень круто, но очень долго в смысле обучения, а winform это просто, но уже старо, что-ли. Так?
A>Что WinForms, что WPF, что ASP.Net вам проще (заметно) купить сторонний компонент, если функциолнальности DataGridView существенно не хватает.
Согласен. Хорошо, покупаем компонент. Но надо же его куда-то встроить, т.е. надо сначала изучить либо WinForms либо WPF.
Здравствуйте, Аноним, Вы писали:
A>>Что WinForms, что WPF, что ASP.Net вам проще (заметно) купить сторонний компонент, если функциолнальности DataGridView существенно не хватает. А>Согласен. Хорошо, покупаем компонент. Но надо же его куда-то встроить, т.е. надо сначала изучить либо WinForms либо WPF.
WinForms изучить проще. Думаю с этим никто не будет спорить. Библиотека практически не развивается самим Microsoft (хотя в 4 фремворке исправили несколько багов, так что...), но есть огромное количество (не потому что WPF хуже, а просто потому что WinForms значительно дольше существует) сторонних компонент. В том числе беплатных. Бесплатных компонент для WPF тоже не мало. В любом случае даже у платных качество бывает так себе, так что тут надо под конкретную задачу искать.
Если говорить именно про элемент управления максимально похожий на Excel, то для WPF я вообще ничего не встречал. Для WinForms есть spreadsheetgear, но он считает высоту строк не так как Excel. То есть в Excel при печати на листе помещается 20 строк, а в SSG — 19 строк.
Если нужен просто грид, то такого добра предостаточно для всех библиотек.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>>>Весь прикол в том что remote desktop имеет латентность на каждое действие, а веб — только на отправку данных. A>>>Согласен. Но на практике это не создаёт заметных проблем. G>>Угу, наверное поэтому на вебе делается на порядок больше, чем с использование remote desktop. Просто ты привык и проблем не замечаешь, хотя многое можно было бы сделать проще.
A>Оба утверждения странные. Приложение не делается для терминала как-то особенно, поэтому как ты сравнил количество бизнес-приложений на вебе и в терминале я не понимаю. И я не использую терминал сам, поэтому я не мог к чему-либо привыкнуть. Я пишу приложения, которые время-от времени используют и в терминале тоже, но я их пишу так, что мне не надо их переписывать. Иногда о том что приложения используется в терминале я узнаю чуть-ли не последним.
Любое приложение не пишется как-то особенно. Только веб изначально доставляет меньше проблем, которые пытаются решить терминальным доступом.
Иначе не был бы веб сейчас так популярен.
A>>>Ты глубоко не прав. Я знаю с десяток компаний которые печатают с телефонов (или устройств аналогичных характеристик) на матричные принтеры через блютуз адаптер. G>>А смысл мобильные устройства на то и мобильные чтобы их можно было носить с собой везде. В поезде или машине например, принтер такими свойствами не обладает. 0.00001% юзкейсов даже рассматривать не хочу.
A>Ну вот ты не разбираешься в предметной области, а опять навешиваешь ярлыки. Принтер в машине, это мобильные сотрудники, которые ездят на служебных машинах. Так работают абсолютно все дистрибьюторские компании с которыми я общался: еда, билеты, стиральные порошки.
Да, да, помню я. Это как раз решается созданием специализированной клиентской версии, заточенной под свои задачи.
Еще раз: большая часть кейсов покрывается веб-приложением на html\css\js. Там где не хватает пишется отдельное предложение со специализированным интерфейсом. Это и полезнее с точки зрения реализации кейсов.
Например в macdonalds есть кассы со своим интерфейсом, есть мобильные терминалы и переносной принтер. Странно что они удаленный рабочий стол не догадались использовать
A>>>Ctrl+Alt+Shift+F7 свободно может и везде, но толку от этого никакого. Есть общепринятые сочетания клавиш, есть сочетания клавиш, которые были в какой-то другой, знакомой, программе и т.д. G>>Самые частоиспользуемые и так работают, они завязаны на редактирование текста. A>Ты заблуждаешься.
Ctrl+Z, Ctrl+X, Ctrl+C, Ctrl+V, Ctrl+B, Ctrl+I все работает, больше я и не знаю.
A>>>А Силверлайт не надо? G>>Если Windows Update включен, то не надо, страница сама предлагает, administrative effort нулевой.
A>А RDP есть и без WU.
Ага, особенно на линуксе и маке
A>>>Это крайне редкая проблема + неправильное её решение. G>>Это как раз крайне частая проблема. Куча десктопного кастомного софта требуют права админа. G>>Правильное решение проблемы это затраты, которые заранее никто не планировал. A>Я не знаю откуда ты взял эту кучу. Я уже очень давно с таким не сталкивался.
Ты вообще в каком-то идеальном мире живешь. У тебя устаревших приложений нет, зато встречаются кейсы, которые у других встречаются один на миллион.
A>>>Связь между странной попыткой записи в HKLM и вебом чуть менее чем никакая. G>>Для веба сильно другой инструментарий используется, другие привычки и гайдлайны. 99,9% веб-разработчиков и не подумают в реестр писать, а куча десктопных программ, требующие права админа — факт.
A>Зато они запросто подумают что база должна быть MDB, потому что на халявном хостинге, на котором лежит демо, нет MSSQL и лежать она должна в папке C:\Inetpub\ потому что этот путь зашит в программе.
Ты таких заешь? Я — нет.
A>Накосячить можно везде.
Можно, но где-то больше возможностей, где-то меньше. Для веба меньше, обычно веб приложения на более высоком уровне абстракции работают.
A>Терминал это ещё и SSO, а вот как твоё веб-приложение пройдёт аудит безопасности вопрос отдельный.
А что мешает в вебе SSO сделать?
ЗЫ. Вообще многие твои советы, которые ты даешь в этой теме, адекватны только с учетом кучи редких кейсов, которые кажись только у тебя и встречаются.
Re[5]: Не надо уходить от темы
От:
Аноним
Дата:
03.05.11 19:55
Оценка:
Спасибо за ответ, значит WinForms все еще котируется для подобных приложений, и даже по видимому наиболее оптимальное решение с точки зрения времени разработки (для чайника). Какая студия минимально подойдет для этого? 2005, 2008 или обязательно 2010?
В принципе, похожесть на Excel совсем не важна, т.е. надо обычный, но достаточно красивый, грид, ячейки которого можно редактировать; где каждая ячейка, строка, или колонка может отображается в заданнном формате/цвете. Еще хорошо бы иметь несколько страниц таблиц (как в Excelе) и возможность брать и сохранять данные из файла, базы данных, или из сокета.
Здравствуйте, Аноним, Вы писали:
А>Спасибо за ответ, значит WinForms все еще котируется для подобных приложений, и даже по видимому наиболее оптимальное решение с точки зрения времени разработки (для чайника). Какая студия минимально подойдет для этого? 2005, 2008 или обязательно 2010? А>В принципе, похожесть на Excel совсем не важна, т.е. надо обычный, но достаточно красивый, грид, ячейки которого можно редактировать; где каждая ячейка, строка, или колонка может отображается в заданнном формате/цвете. Еще хорошо бы иметь несколько страниц таблиц (как в Excelе) и возможность брать и сохранять данные из файла, базы данных, или из сокета.
Здравствуйте, Аноним, Вы писали:
А>Спасибо за ответ, значит WinForms все еще котируется для подобных приложений, и даже по видимому наиболее оптимальное решение с точки зрения времени разработки (для чайника). Какая студия минимально подойдет для этого? 2005, 2008 или обязательно 2010?
Любая.
А>В принципе, похожесть на Excel совсем не важна, т.е. надо обычный, но достаточно красивый, грид, ячейки которого можно редактировать; где каждая ячейка, строка, или колонка может отображается в заданнном формате/цвете. Еще хорошо бы иметь несколько страниц таблиц (как в Excelе) и возможность брать и сохранять данные из файла, базы данных, или из сокета.
Если особых требований нет, стандартного DataGridView вполне хватит. Страницы можно сделать табом.
Здравствуйте, gandjustas, Вы писали:
G>Любое приложение не пишется как-то особенно. Только веб изначально доставляет меньше проблем, которые пытаются решить терминальным доступом. G>Иначе не был бы веб сейчас так популярен.
Популярность веба утверждение которое может быть и истиным и ложным, в зависимости от сегмента рынка.
G>Да, да, помню я. Это как раз решается созданием специализированной клиентской версии, заточенной под свои задачи.
Но не вебом
G>Например в macdonalds есть кассы со своим интерфейсом, есть мобильные терминалы и переносной принтер. Странно что они удаленный рабочий стол не догадались использовать
Во-первых, я не говорил что терминал решит все проблемы. Я вообще за него не агитировал, я лишь сказал что есть компании в которых используют терминальные сессии и есть объективные причины почему так стоит делать. Переводить всех на веб в общем случае не приемлемое решение.
во-вторых, веба к макдональдсе тоже нет, так что что ты пытался доказать не понятно.
A>>Ты заблуждаешься. G>Ctrl+Z, Ctrl+X, Ctrl+C, Ctrl+V, Ctrl+B, Ctrl+I все работает, больше я и не знаю.
Уверен, ты знаешь F5
A>>А RDP есть и без WU. G>Ага, особенно на линуксе и маке
А в Линуксе или на маке есть Силверлайт через из коробки? Мне эта подтема надоела. Утверждать что силверлайт доступнее RDP просто нелепо.
A>>Я не знаю откуда ты взял эту кучу. Я уже очень давно с таким не сталкивался. G>Ты вообще в каком-то идеальном мире живешь. У тебя устаревших приложений нет, зато встречаются кейсы, которые у других встречаются один на миллион.
Ой ну да, только твой кейсы самые популярные.
A>>Зато они запросто подумают что база должна быть MDB, потому что на халявном хостинге, на котором лежит демо, нет MSSQL и лежать она должна в папке C:\Inetpub\ потому что этот путь зашит в программе. G>Ты таких заешь? Я — нет.
А я знаю лично. Правда мы этих людей перевоспитали.
A>>Накосячить можно везде. G>Можно, но где-то больше возможностей, где-то меньше. Для веба меньше, обычно веб приложения на более высоком уровне абстракции работают.
Обычно, веб приложения двузвенки с говёной архитектурой без выделенного DAL (LINQ != DAL) и BLL. О каком тут можно говорить уровне абстракции?
A>>Терминал это ещё и SSO, а вот как твоё веб-приложение пройдёт аудит безопасности вопрос отдельный. G>А что мешает в вебе SSO сделать?
NTLM через Интернет?
G>ЗЫ. Вообще многие твои советы, которые ты даешь в этой теме, адекватны только с учетом кучи редких кейсов, которые кажись только у тебя и встречаются.
