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

AVM>Практически тоже самое, только раскидано по разным хостам. Даже транспорт один и тот же может быть HTTP.
Ахха. URLConnection использовать? Или Commons HTTP Client? Тем самым увеличивая колличество ненужного траффика.

AVM>Ты думаешь они сильно проще/быстрее/легче? Как только мы говорим Web UI, считай что мы сразу захватываем несколько связанных между собой технологий (HTML,DHTML,CSS,DOM,JavaScript,Servlet/JSP-based framework,Browsers compatibility, etc). Связать все это до кучи и отладить — задачка еще та.
На сколько бы ужасающим этот список не выглядел — не сложно найти студента который бы это все дело модифицировал. В тоже время апплет, общающийся с сервером через XML, да ещё и Swing в нагрузку для молодого специалиста очень и очень сурьзное задание. Так что все упирается в финансы.
А то что гуру и то и другое напишет с одинаковой легкостью и скоростью — не вопрос. Вопрос сколько стоит такой человек.


AVM>>>Посмотри здесь и здесь. Быстро дешево и со вкусом
B>>Сейчас тебе Сергей расскажет что такое быстро и дешево.
AVM>Вкуса нет

На вкус и цвет...

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

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

AVM>>Практически тоже самое, только раскидано по разным хостам. Даже транспорт один и тот же может быть HTTP.
B>Ахха. URLConnection использовать? Или Commons HTTP Client? Тем самым увеличивая колличество ненужного траффика.
IMHO тут надо считать каждый конкретный случай, например мне встречался web-компонент: навороченная таблица, которая перегружала всю страницу при сортировки. Не самое экономичное решение, можно ее конечно поместить в IFrame, но это в конечном итоге ведет к росту сложности приложения. Обеспечивать синхронную работу кучки фреймов с учетом совсместимости с различными browsers требует неслабой квалификации.

AVM>>Ты думаешь они сильно проще/быстрее/легче? Как только мы говорим Web UI, считай что мы сразу захватываем несколько связанных между собой технологий (HTML,DHTML,CSS,DOM,JavaScript,Servlet/JSP-based framework,Browsers compatibility, etc). Связать все это до кучи и отладить — задачка еще та.
B>На сколько бы ужасающим этот список не выглядел — не сложно найти студента который бы это все дело модифицировал. В тоже время апплет, общающийся с сервером через XML, да ещё и Swing в нагрузку для молодого специалиста очень и очень сурьзное задание.
Это просто зависит от опыта работы. IMHO Web Frameworks имеют большее распространение, отсюда и больше специалистов, имеющих опыт работы с ними. Соответственно больше студентов, знающих их.

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

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

C0s>>>с одной стороны я вижу "если" — "если наймет кого-то, который порекомендует то-то и т.д."
C0s>>>с другой стороны многие забывают, что серьезный переносимый XML начинается с нехилых XML-схем с применением пространств имен. которые в разработке также не просты, как и бинарные технологии. при этом и то и другое при соответствующей документации осваивается "новым человеком" примерно с эквивалентной скоростью.
AVM>>Вот тут проявляется второй плюс XML — XML спецификации от W3C вообще, и группа спецификаций DOM в частности. Там определяются platform independent интерфейсы для разбора XML документов. Это я к тому что через пару лет, в новой платформе ты наверняка найдешь этот интерфейс для работы с XML документом, но там скорее всего не будет класса, способного правильно прочитать object из двоичного
AVM>>java-based потока.

L>Я вот никак не могу догнать в чем спор? Сергей говорит, что XML сакс а бинарный поток рулит. Ты говоришь что это не так. Но вот контекста спора то не обозначили. Оба формата имеют право на жизнь, только где-то живучее оказывается один, где-то второй. Это не точка зрения — это факт, и спорить с ним считаю безсмысленно. Почему бы не прекратить полемику?
Контекст примерно такой, by default я предпочитаю XML-based маршалинг, Сергей видимо by default предпочитает binary-based маршалинг. Спора особого нет, просто обмен мнениями.
Собственно, если мы кому то мешаем, то давай полемику прекратим

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

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

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

MT>>>Поделитесь мнением и опытом изпользования апплетов на клиентской части.
MT>>>Есть приложение (обработка форм — ввод данных) основанное на апплетах — нужно убедить заказчика что это не есть хорошо, и лучше переделать чем поддерживать то что уже написано.
MT>>>Спасибо.
AVM>>Надо просто привести заказчику убедительные аргументы что в его случае applets "не есть хорошо" Если хочешь выскажи эти агрументы здесь и форумчане их обсудят.

MT>1. Апплеты основаны на awt-классах, большинство из них depricated
MT>2. Долгое время загрузки и инициализации
А это уже от пряморукости разработчика зависит. Копайте в сторону Java Web Start
MT>3. Апплет привязан к определенной версии java, возможны конфликты с jre броузера
Сверху вниз есть совместимость, о каких конфликтах тогда идёт речь.
MT>4. Не дружественны интерфейс — html страница предоставляет больше возможностей для оформления
А вот это уже совсем некоректное утверждение, не сможете вы стопроцентно покрыть все нужды современного UI через веб-интерфейс. Кроме того веб-интерфейс почти гарантировано требует привлечения JavaScript, что имеет свооим следствием, немного разные реализации в разных браузерах, так как и HTML, кстати таблиц не предвидится? Вот попаритесь с кросброузерностью таблиц и о SWING будете мечтать только, кроме того для меня разработка чего-то большого на JavaScript, это просто кошмар, изз-за сложностей его отладки.

Едиснственный недостаток Java это малая распространённость JRE на клиентских машынах и необходимость выкачивать из нета довольно жырный дистриб.

Ну и чтоб сделать болеее гибким дизайн, можете попробовать сварганить что-то мимнимальное типа XUL, чтоб реализовать то что вы говорили, шрифт задать, линк добавить.