Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, gandjustas, Вы писали: S> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность.
Счегобы?
S>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд.
Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно.
S>Для терминальных сессий подойдут самые убитые бездискове станции.
А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций".
S>Так, что у каждой технологии есть свои плюсы и минусы.
Угу, у веба скорее плюсы, а у десктопа скорее минусы для этих самых бизнес-приложений, которые терминальным доступом пытаются закрыть.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, gandjustas, Вы писали: S>> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность. G>Счегобы?
Не все можно выполнить на сервере, а из-за этого приходится таскать данные. S>>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд. G>Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно.
За состоянием там не надо следить, так как оно уже выполняется в необходимом контексте, а вот для клиент серверных нужно передавать, сохранять извлекать нужное состояние, что не только нетолько усложняет программирование, но и тормозит выполнение. S>>Для терминальных сессий подойдут самые убитые бездискове станции. G>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций".
Но и для терминалов тоже. Да и на складе проще работать с терминалами, подключенным оборудованием итд. В том числе и офисе.
S>>Так, что у каждой технологии есть свои плюсы и минусы. G>Угу, у веба скорее плюсы, а у десктопа скорее минусы для этих самых бизнес-приложений, которые терминальным доступом пытаются закрыть.
Ну плюсы на самом деле в денежках требуемых на программирвание этих систем, а значит является нашим хлебушком.
Я как програмиист 1С смотрю как люди мучаются с переходом 8.2. Я в своем коде стараюсь выводить большую часть выполнения кода на сервер, но много намного проще решается на клиенте. При этом в терминалах народ аж с прошлого века работает на семерках.
и солнце б утром не вставало, когда бы не было меня
Re[4]: Стоил ли начинать сейчас учить WinForms?
От:
Аноним
Дата:
04.05.11 09:53
Оценка:
Здравствуйте, vmpire, Вы писали:
V>Здравствуйте, evo, Вы писали:
evo>>Здравствуйте, vmpire, Вы писали: V>>>Что мешает "учить" и то и другое? evo>>Такой подход мне кажется не эффективным, особенно для новичка. Это не тот случай, где технологии дополняют друг друга или идут параллельно, тут используешь или одно или другое. evo>>Я понимаю, когда хотя б год поработал с формами, без вопросов надо учить WPF. Но что делать, когда нормально с формс еще не успел разобраться и когда МС сказали, что развивать формс больше не будут? V>Всё зависит от цели обучения. Если цель — наработка общей эрудиции, то есть неглубокое изучение, то вполне можно учить и то и другое. Например, реализовать одну и ту же задачу на обоих технологиях, что позволит лекко увидеть сильные и слабые стороны. V>Если целью является конкретная дальнейшая работа, то нужно смотреть, что для этой работы потребуется с большей вероятностью.
Неипите мозг, есть масса более интересных занятий, чем "учить технологии"
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Serginio1, Вы писали:
S>>>Здравствуйте, gandjustas, Вы писали: S>>> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность. G>>Счегобы? S> Не все можно выполнить на сервере, а из-за этого приходится таскать данные.
Как раз наоборот. Все можно и нужно выполнить на сервере, на клиенте только отображение, ввод и валидация. Если правильно готовить ajax, то получится гораздо меньше трафика, чем толстый клиент + субд или удаленный рабочий стол.
S>>>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд. G>>Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно. S> За состоянием там не надо следить, так как оно уже выполняется в необходимом контексте, а вот для клиент серверных нужно передавать, сохранять извлекать нужное состояние, что не только нетолько усложняет программирование, но и тормозит выполнение.
Весь прикол в том что состояние меняется независимо от клиента. В многопользовательском окружении тебе придется выполнять те же действия. Только в вебе ты сразу так делаешь, у тебя вариантов других нет, а в толстом клиенте есть возможность сделать нехорошо.
В вебе у тебя четко разграничены состояние клиента (в js и полях формы) и состояние сервера (в бд), а в десктопном приложении ты вполне скокойно можешь байндиться на коллекции объектов из ORM а потом удивляться почему savechanges сохраняет то что ты менял на предыдущем экране.
S>>>Для терминальных сессий подойдут самые убитые бездискове станции. G>>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций". S> Но и для терминалов тоже. Да и на складе проще работать с терминалами, подключенным оборудованием итд. В том числе и офисе.
Ну если нет разницы то зачем париться? Веб доступен по-умолчанию на любом устройстве без установки доп. софта, в том числе можно браузер запусктаь в режиме киоска.
S>>>Так, что у каждой технологии есть свои плюсы и минусы. G>>Угу, у веба скорее плюсы, а у десктопа скорее минусы для этих самых бизнес-приложений, которые терминальным доступом пытаются закрыть. S> Ну плюсы на самом деле в денежках требуемых на программирвание этих систем, а значит является нашим хлебушком. S>Я как програмиист 1С смотрю как люди мучаются с переходом 8.2. Я в своем коде стараюсь выводить большую часть выполнения кода на сервер, но много намного проще решается на клиенте. При этом в терминалах народ аж с прошлого века работает на семерках.
Так 1с7.7 на терминале не от хорошей жизни, а от сложности многопользовательского развертывания и цены лицензий. Именно пытаются победить недостатки существующей версии терминальным доступом. Я предлагаю не создавать недостатки.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, gandjustas, Вы писали: S>> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность. G>Счегобы?
S>>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд. G>Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно.
За состоянием на декстопе не надо, т.к. оно уже выполняется в определенном контексте, а вот для тонкого клиента приходится это самое состояние таскать туда сюда, и не всегда это малый объем данных, что приводит к замедлению. S>>Для терминальных сессий подойдут самые убитые бездискове станции. G>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций".
Ну на мобильных устройствах не всегда удобно. Все же монитор как то привычнее, плюс подключение разного торгового, складского оборудования.
S>>Так, что у каждой технологии есть свои плюсы и минусы. G>Угу, у веба скорее плюсы, а у десктопа скорее минусы для этих самых бизнес-приложений, которые терминальным доступом пытаются закрыть.
Ну плюсы прежде всего в хлебушке, т.к. нужно все это дело прграммировать. К 1Совец вижу как народ на 8.2 переходит и мучается, а на 7 ках еще с прошлого века на терминалах сидят и не окают.
А мне лично побарабану на чем деньги зарабатывать, но я вижу (вернее знаю на опыте) плюсы и минусы двух этих технологий.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, Serginio1, Вы писали:
S>>>>Здравствуйте, gandjustas, Вы писали: S>>>> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность. G>>>Счегобы? S>> Не все можно выполнить на сервере, а из-за этого приходится таскать данные. G>Как раз наоборот. Все можно и нужно выполнить на сервере, на клиенте только отображение, ввод и валидация. Если правильно готовить ajax, то получится гораздо меньше трафика, чем толстый клиент + субд или удаленный рабочий стол.
А афик то там только изменение экранов. Куда уж меньше то? S>>>>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд. G>>>Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно. S>> За состоянием там не надо следить, так как оно уже выполняется в необходимом контексте, а вот для клиент серверных нужно передавать, сохранять извлекать нужное состояние, что не только нетолько усложняет программирование, но и тормозит выполнение. G>Весь прикол в том что состояние меняется независимо от клиента. В многопользовательском окружении тебе придется выполнять те же действия. Только в вебе ты сразу так делаешь, у тебя вариантов других нет, а в толстом клиенте есть возможность сделать нехорошо. G>В вебе у тебя четко разграничены состояние клиента (в js и полях формы) и состояние сервера (в бд), а в десктопном приложении ты вполне скокойно можешь байндиться на коллекции объектов из ORM а потом удивляться почему savechanges сохраняет то что ты менял на предыдущем экране.
Ну тут множество подходов. Но если данные хранятся в БД то нефиг их вытакскивать на клиента, другое дело если делать быстрый доступ через локальные базы, за счет кэширования данных, либо стараться вычислять на сервере и передавать на клиента по быстрому каналу. Все жду недождусь, ког да же весь клиентский код можно делать в СУБД. Но ведь состояние это не только БД, но и текущий незаписанный набор данных, ограничения, данные пользователя итд. S>>>>Для терминальных сессий подойдут самые убитые бездискове станции. G>>>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций". S>> Но и для терминалов тоже. Да и на складе проще работать с терминалами, подключенным оборудованием итд. В том числе и офисе. G>Ну если нет разницы то зачем париться? Веб доступен по-умолчанию на любом устройстве без установки доп. софта, в том числе можно браузер запусктаь в режиме киоска.
Только приложение тонадо написать. S>>>>Так, что у каждой технологии есть свои плюсы и минусы. G>>>Угу, у веба скорее плюсы, а у десктопа скорее минусы для этих самых бизнес-приложений, которые терминальным доступом пытаются закрыть. S>> Ну плюсы на самом деле в денежках требуемых на программирвание этих систем, а значит является нашим хлебушком. S>>Я как програмиист 1С смотрю как люди мучаются с переходом 8.2. Я в своем коде стараюсь выводить большую часть выполнения кода на сервер, но много намного проще решается на клиенте. При этом в терминалах народ аж с прошлого века работает на семерках. G>Так 1с7.7 на терминале не от хорошей жизни, а от сложности многопользовательского развертывания и цены лицензий. Именно пытаются победить недостатки существующей версии терминальным доступом. Я предлагаю не создавать недостатки.
Нет там как раз из-за скорости, так как для dbf файлы кэшируются и скорость выполнения увеличиваются на порядки, при этом как я писал выше используются премущества локальных баз для хранения состояний, а для SQL это проще в администрировании, надежности и опять же скорости, т.к. вкладываться нужно в серверы а не в клиентские машинки.
и солнце б утром не вставало, когда бы не было меня
кста , почему все решили что аппаратаное ускорение в UI даст приророст?
я могу вам сказать что даже теоретически оно может дать просадку.
потому что любой писатель 3д движков вам скажет, что часто всё упирается не в скорость видеокарты, а в скорость передачи и кол-во комманд отдаваемых ей из приложения.
поэтому в 3д движках используются всякие техники батчинга т.е. упаковки кучи буферов в одит, атласиг(упаковка кучи тестукр в одну) и прочего и строго следится за кол-вом вызовов отрисовки DrawIndexedPrimitive(DIP)
и даже крутость движка опредялется кол-вом DIPов за кадр, чем меньше — тем круче движок.
так вот я ОЧЕНЬ сомневаюсь что ВПФники такие крутые пацаны что смогли на такую сложную структуру впф приложения натянуть технологии упаковки, ибо мне это видится катастофический сложностью, потому что в 3д движках перерисовывается всегда весь экран и есть возможность собрать и подготовить данные.
А в впф нету понятия фпс, поэтому и не понятно как квантовать отрисовку для упаковки, а значит упаковки там нет и кучей мелких отрисовок можно заставить ВПФ приложение лечь.
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
K>А в впф нету понятия фпс, поэтому и не понятно как квантовать отрисовку для упаковки, а значит упаковки там нет и кучей мелких отрисовок можно заставить ВПФ приложение лечь.
более того, если они начнут ка-то квантовать отрисовку, то чем сильнее они начнут упаковывать, тем более тормозной отклик получат, а чем меньше упаковка тем больше команд — и тем сильнее томроза видухи
и не факт что получится найти золотую середину
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Serginio1, Вы писали:
S>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Здравствуйте, Serginio1, Вы писали:
S>>>>>Здравствуйте, gandjustas, Вы писали: S>>>>> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность. G>>>>Счегобы? S>>> Не все можно выполнить на сервере, а из-за этого приходится таскать данные. G>>Как раз наоборот. Все можно и нужно выполнить на сервере, на клиенте только отображение, ввод и валидация. Если правильно готовить ajax, то получится гораздо меньше трафика, чем толстый клиент + субд или удаленный рабочий стол. S> А афик то там только изменение экранов. Куда уж меньше то?
Угу проскроллил в одну сторону — полетели байты, проскроллил в другую сторону — аналогично, высокая чувствительность к латентности канала, на каждое нажатие клавиши раундтрип до сервера.
Если правльно готовить ajax, то передаваться будет только изменение данных. Это гораздо меньше.
S>>>>>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд. G>>>>Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно. S>>> За состоянием там не надо следить, так как оно уже выполняется в необходимом контексте, а вот для клиент серверных нужно передавать, сохранять извлекать нужное состояние, что не только нетолько усложняет программирование, но и тормозит выполнение. G>>Весь прикол в том что состояние меняется независимо от клиента. В многопользовательском окружении тебе придется выполнять те же действия. Только в вебе ты сразу так делаешь, у тебя вариантов других нет, а в толстом клиенте есть возможность сделать нехорошо. G>>В вебе у тебя четко разграничены состояние клиента (в js и полях формы) и состояние сервера (в бд), а в десктопном приложении ты вполне скокойно можешь байндиться на коллекции объектов из ORM а потом удивляться почему savechanges сохраняет то что ты менял на предыдущем экране. S>Но если данные хранятся в БД то нефиг их вытакскивать на клиента, другое дело если делать быстрый доступ через локальные базы, за счет кэширования данных, либо стараться вычислять на сервере и передавать на клиента по быстрому каналу. Все жду недождусь, ког да же весь клиентский код можно делать в СУБД. Но ведь состояние это не только БД, но и текущий незаписанный набор данных, ограничения, данные пользователя итд.
Ага, то есть ты сам выстраиваешь барьеры, которые уже есть в вебе.
То что ты хочешь сделать "в субд" в вебе делается на сервере, а на клиент попадает ровно то что ты скажешь. И что потом приходит с клиента на сервер ты определяешь. При хороших средствах генерации SQL на сервере пихать кастомный код в БД не имеет большого смысла.
S>>>>>Для терминальных сессий подойдут самые убитые бездискове станции. G>>>>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций". S>>> Но и для терминалов тоже. Да и на складе проще работать с терминалами, подключенным оборудованием итд. В том числе и офисе. G>>Ну если нет разницы то зачем париться? Веб доступен по-умолчанию на любом устройстве без установки доп. софта, в том числе можно браузер запусктаь в режиме киоска. S> Только приложение тонадо написать.
Любое приложение надо написать, из воздуха не появится.
Здравствуйте, gandjustas, Вы писали:
S>> А афик то там только изменение экранов. Куда уж меньше то? G>Угу проскроллил в одну сторону — полетели байты, проскроллил в другую сторону — аналогично, высокая чувствительность к латентности канала, на каждое нажатие клавиши раундтрип до сервера. G>Если правльно готовить ajax, то передаваться будет только изменение данных. Это гораздо меньше.
Так данные то хранить надо. А то народ скролить тысячами строк. G>>>В вебе у тебя четко разграничены состояние клиента (в js и полях формы) и состояние сервера (в бд), а в десктопном приложении ты вполне скокойно можешь байндиться на коллекции объектов из ORM а потом удивляться почему savechanges сохраняет то что ты менял на предыдущем экране.
Ну с дуру то можно ...
Все о чем ты говоришь легко делается и на декстопном приложении. Разницы абсолютно никакой. Только при Вэбе приложее на клиенте, а при терминалах на сервере.
Вот и вся разница. S>>Но если данные хранятся в БД то нефиг их вытакскивать на клиента, другое дело если делать быстрый доступ через локальные базы, за счет кэширования данных, либо стараться вычислять на сервере и передавать на клиента по быстрому каналу. Все жду недождусь, ког да же весь клиентский код можно делать в СУБД. Но ведь состояние это не только БД, но и текущий незаписанный набор данных, ограничения, данные пользователя итд. G>Ага, то есть ты сам выстраиваешь барьеры, которые уже есть в вебе. G>То что ты хочешь сделать "в субд" в вебе делается на сервере, а на клиент попадает ровно то что ты скажешь. И что потом приходит с клиента на сервер ты определяешь. При хороших средствах генерации SQL на сервере пихать кастомный код в БД не имеет большого смысла.
А на сервер то о откуда попадает? Ну вопервых SQL ущербен по сравнеию с C#, а на хранимые процедуры на Net накладываются ограничения. Так что так или иначе приходится тянуть код с СУБД, а вот здесь уже совсем не тонкий клиент. Межпроцессное взамодействие тормозит, а если учесть что СУБД как правило отдельно от Сервера приложений, то еще и сеть сказывается. Причем существенно, на коротких запросах.
Вобще в идеале конечно взаимодействие должно быть тонкий клиент -> СУБД, что по сути происходит при использовании локальных многопользовательских СУБД. S>>>>>>Для терминальных сессий подойдут самые убитые бездискове станции. G>>>>>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций". S>>>> Но и для терминалов тоже. Да и на складе проще работать с терминалами, подключенным оборудованием итд. В том числе и офисе. G>>>Ну если нет разницы то зачем париться? Веб доступен по-умолчанию на любом устройстве без установки доп. софта, в том числе можно браузер запусктаь в режиме киоска. S>> Только приложение тонадо написать. G>Любое приложение надо написать, из воздуха не появится.
Прости недопонял вопроса. Бездисковые станции с подачкой около 5 мб линукса, могут работать при минимуме ресурсов.
и солнце б утром не вставало, когда бы не было меня
Re[4]: Стоил ли начинать сейчас учить WinForms?
От:
Аноним
Дата:
04.05.11 15:26
Оценка:
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Аноним, Вы писали:
А>>все что работает через GDI работает медленнее чем через DirectX.
A>Вы не имеете ни малейшего понятия как работает видеокарта.
Нус, расскажи как с твоими познаниями "как работает видеокарта" GDI оказывается в выигрыше перед DirectX.
p.s
Попкорн с пивом купил...с нетерпением жду ответа
Здравствуйте, Аноним, Вы писали:
А>...Предположим, надо разработать отображение табличных данных по типу Excel. Будет ли достаточно winform для подобных приложений? Kак я понял из обсуждения, WPF это очень круто, но очень долго в смысле обучения, а winform это просто, но уже старо, что-ли. Так?
Главное, Silverlight для такого проекта не выбирай, ни один из поставщиков библиотек не предлагает нормальный грид, работающий с динамическими данными (костыли с кодогенерацией не в счет). Зачем вообще из силверлайта убрали ITypedList?
Здравствуйте, matumba, Вы писали:
M>Потому что видюха берёт на себя весь геморой по отображению — ей передаются лишь команды.
я там дальше написал почему "геммой по отображению" это еще не весь геморрой
M>Да хоть 4Д — они тут причём? Интерфейс — двумерный.
при том что впф рендерится через Direct3D, а писатели 3д движков знают особенности работы Direct3D лучше, чем впфники.
например я поставив впервые висту и включив аэро первое что отметил — огромный лаг всего интерфейса по сравнению с хр
тот же самый лаг ощущается и в любом впф приложении
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, gandjustas, Вы писали:
A>>Мне плевать на браузеры, мне нужно обновить содержимое списка не перегружая всей страницы с помощью клавиатурного сокращения. F5 — стандарт. Невозможность использовать стандарт — ограничение веба. G>f5 — стандарт для "обновить всю страницу", если ты попытаешься наделит ьэту клавишу другим поведением — пользователя не обрадуются. Все равно что сделать по ctrl-x вырезание одной буквы
F5 это стандарт на "обновить". "Всю страницу" — твои домыслы.
G>Это правда жизни. Описанная выше тенденция поддерживается от наколеночных приложений до крупных продуктов от ведущих производителей. Есдиничные исключения в расчет не берем.
Опять громкие заявления без фактов. Единственный кто перешёл на веб за последнее время 1С 8.2. В итоге платформа стала ещё большим говном, чем была.
A>>Это твои домыслы. G>Это не домыслы, это факт. Консоль управления IIS далеко не самая сложная и не единственная часть Server manager если что.
Вот именно, что это не единственная часть Server Manager.
G>Там 80-й порт, который открыт чуть более чем везде. В отличие от 3389.
Это смешно.
A>>gandjustas, ты не показываешь преимущества веба, ты показываешь убогость своих представлений о терминале. Прекрати, это уже не забавно. У веба действительно есть преимущества объективные перед терминалом, но умудрился не назвать ни одно из них. G>Ок, давай предложи сценарий обновления приложения в терминале без отключения пользователей. Покажи способ быстро добавить серваки для балансировки нагрузки. Покажи способ работы с приложением в терминале с android по GPRS каналу.
Посети курс сертицикации Windows Server и там тебе ответят на эти и многие другие вопросы. Ты зашорен, не умеешь использовать возможности ОС и соё незнание выставляешь как недостатки технологиии с которой не знаком.
G>Ты пытаешься спорить с фактами, которые есть. Приводшь в качестве аргументов что у тебя что-то работает.
Это у тебя что-то не работает. У меня и терминал работает и веб и я знаю место каждого и не пытаюськ ак ты везде протолкнуть только одну технологию.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Мне плевать на браузеры, мне нужно обновить содержимое списка не перегружая всей страницы с помощью клавиатурного сокращения. F5 — стандарт. Невозможность использовать стандарт — ограничение веба. G>>f5 — стандарт для "обновить всю страницу", если ты попытаешься наделит ьэту клавишу другим поведением — пользователя не обрадуются. Все равно что сделать по ctrl-x вырезание одной буквы
A>F5 это стандарт на "обновить". "Всю страницу" — твои домыслы.
Так работают все браузеры. И что ты думаешь люди буду ожидать нажимая f5 в браузере?
G>>Это правда жизни. Описанная выше тенденция поддерживается от наколеночных приложений до крупных продуктов от ведущих производителей. Есдиничные исключения в расчет не берем. A>Опять громкие заявления без фактов. Единственный кто перешёл на веб за последнее время 1С 8.2. В итоге платформа стала ещё большим говном, чем была.
Ну если ты знаешь только одно приложение, то ты прав
A>>>Это твои домыслы. G>>Это не домыслы, это факт. Консоль управления IIS далеко не самая сложная и не единственная часть Server manager если что. A>Вот именно, что это не единственная часть Server Manager.
G>>Там 80-й порт, который открыт чуть более чем везде. В отличие от 3389. A>Это смешно.
Ну посмейся, порты от этого не откроются.
A>>>gandjustas, ты не показываешь преимущества веба, ты показываешь убогость своих представлений о терминале. Прекрати, это уже не забавно. У веба действительно есть преимущества объективные перед терминалом, но умудрился не назвать ни одно из них. G>>Ок, давай предложи сценарий обновления приложения в терминале без отключения пользователей. Покажи способ быстро добавить серваки для балансировки нагрузки. Покажи способ работы с приложением в терминале с android по GPRS каналу. A>Посети курс сертицикации Windows Server и там тебе ответят на эти и многие другие вопросы. Ты зашорен, не умеешь использовать возможности ОС и соё незнание выставляешь как недостатки технологиии с которой не знаком.
Ответь на вопросы.
G>>Ты пытаешься спорить с фактами, которые есть. Приводшь в качестве аргументов что у тебя что-то работает. A>Это у тебя что-то не работает. У меня и терминал работает и веб и я знаю место каждого и не пытаюськ ак ты везде протолкнуть только одну технологию.
Угу, у тебя очень хорошо работает терминал если на гигабитном канале отзывчивость зависит от mtu.
Здравствуйте, gandjustas, Вы писали:
A>>F5 это стандарт на "обновить". "Всю страницу" — твои домыслы. G>Так работают все браузеры. И что ты думаешь люди буду ожидать нажимая f5 в браузере?
Люди буду ожидать, что работает в программе, а не в браузере.
G>>>Это правда жизни. Описанная выше тенденция поддерживается от наколеночных приложений до крупных продуктов от ведущих производителей. Есдиничные исключения в расчет не берем. A>>Опять громкие заявления без фактов. Единственный кто перешёл на веб за последнее время 1С 8.2. В итоге платформа стала ещё большим говном, чем была. G>Ну если ты знаешь только одно приложение, то ты прав
Ничто не мешает тебе расширить список ERP, просто тебе нечем.
G>>>Ок, давай предложи сценарий обновления приложения в терминале без отключения пользователей. Покажи способ быстро добавить серваки для балансировки нагрузки. Покажи способ работы с приложением в терминале с android по GPRS каналу. A>>Посети курс сертицикации Windows Server и там тебе ответят на эти и многие другие вопросы. Ты зашорен, не умеешь использовать возможности ОС и соё незнание выставляешь как недостатки технологиии с которой не знаком. G>Ответь на вопросы.
1) Покажи способ обновить код веб-приложения остановки Горячие патчи вызывают проблемы вне зависимости от технологии.
2) Просто берёшь и добавляешь север в NLB кластер. Создать кластер пятиминутное дело.
3) Работа в терминате с Androi dпо GPRS недоступна и вебу, потому что надо печатать. Мы уже договоролись до этого, так что не надо давать задний.
A>>Это у тебя что-то не работает. У меня и терминал работает и веб и я знаю место каждого и не пытаюськ ак ты везде протолкнуть только одну технологию. G>Угу, у тебя очень хорошо работает терминал если на гигабитном канале отзывчивость зависит от mtu.
Веб-браузер бы там вообще давно завис, так что не надо ля-ля. Ни один веб браузер не выдержит 4-5 синхронных запросов в секунду без лагов.
Картинка слегка устаревшая. В четвертом WPF либа называется не milcore, а wpfgfx_v0400. Если верить Вики, то:
It interfaces directly with DirectX and provides basic support for 2D and 3D surfaces, timer-controlled manipulation of contents of a surface with a view to exposing animation constructs at a higher level, and compositing the individual elements of a WPF application into a final 3D "scene" that represents the UI of the application and renders it to the screen.
Так что получается, любой WPF контент считается трехмерной сценой.