Поделитесь мнением и опытом изпользования апплетов на клиентской части.
Есть приложение (обработка форм — ввод данных) основанное на апплетах — нужно убедить заказчика что это не есть хорошо, и лучше переделать чем поддерживать то что уже написано.
Спасибо.
Здравствуйте, MT, Вы писали:
MT>Поделитесь мнением и опытом изпользования апплетов на клиентской части. MT>Есть приложение (обработка форм — ввод данных) основанное на апплетах — нужно убедить заказчика что это не есть хорошо, и лучше переделать чем поддерживать то что уже написано. MT>Спасибо.
Надо просто привести заказчику убедительные аргументы что в его случае applets "не есть хорошо" Если хочешь выскажи эти агрументы здесь и форумчане их обсудят.
Здравствуйте, AVM, Вы писали:
AVM>Здравствуйте, MT, Вы писали:
MT>>Поделитесь мнением и опытом изпользования апплетов на клиентской части. MT>>Есть приложение (обработка форм — ввод данных) основанное на апплетах — нужно убедить заказчика что это не есть хорошо, и лучше переделать чем поддерживать то что уже написано. MT>>Спасибо. AVM>Надо просто привести заказчику убедительные аргументы что в его случае applets "не есть хорошо" Если хочешь выскажи эти агрументы здесь и форумчане их обсудят.
1. Апплеты основаны на awt-классах, большинство из них depricated
2. Долгое время загрузки и инициализации
3. Апплет привязан к определенной версии java, возможны конфликты с jre броузера
4. Не дружественны интерфейс — html страница предоставляет больше возможностей для оформления
Здравствуйте, MT, Вы писали:
MT>Здравствуйте, AVM, Вы писали:
AVM>>Здравствуйте, MT, Вы писали:
MT>>>Поделитесь мнением и опытом изпользования апплетов на клиентской части. MT>>>Есть приложение (обработка форм — ввод данных) основанное на апплетах — нужно убедить заказчика что это не есть хорошо, и лучше переделать чем поддерживать то что уже написано. MT>>>Спасибо. AVM>>Надо просто привести заказчику убедительные аргументы что в его случае applets "не есть хорошо" Если хочешь выскажи эти агрументы здесь и форумчане их обсудят.
MT>1. Апплеты основаны на awt-классах, большинство из них depricated
Swing ? MT>2. Долгое время загрузки и инициализации
Долго это сколько? как и кто измерял? MT>3. Апплет привязан к определенной версии java, возможны конфликты с jre броузера
Привязан чем? jre броузера это Java от MS? MT>4. Не дружественны интерфейс — html страница предоставляет больше возможностей для оформления
Посмотри examples от Swing, некоторые вещи на HTML/DHTML/JavaScript практически нереализуемы.
IMHO основной принципиальный недостаток applets — необходимо наличие современной JRE на клиентской машине.
Здравствуйте, MT, Вы писали:
MT>1. Апплеты основаны на awt-классах, большинство из них depricated
кажется, в каком-то интернет-банкинге я видел свинговые апплеты
MT>2. Долгое время загрузки и инициализации
субъективно. скорее, упирается в требования к клиентским рабочим местам. хоть они и выше, чем для "просто броузера", тем не менее, сам по себе без привязки к возможностям клиентов аргумент не состоятелен — ведь клиенты могут быть все сплошь достаточно богатыми, чтобы иметь быстрые процессоры и линии связи
MT>3. Апплет привязан к определенной версии java, возможны конфликты с jre броузера
ну, достаточно попросить всех клиентов ставить "самый последний jre" или "jre не меньше 1.4"
MT>4. Не дружественны интерфейс — html страница предоставляет больше возможностей для оформления
если jre взять соответствующего уровня, то еще не известно, где больше возможностей
ps. я это все не к тому, чтобы оппонировать вам или разжигать флейм — я-то тоже не уверен, что апплеты — это хорошо. но аргументы должны быть настоящими
Здравствуйте, MT, Вы писали:
MT>1. Апплеты основаны на awt-классах, большинство из них depricated MT>2. Долгое время загрузки и инициализации MT>3. Апплет привязан к определенной версии java, возможны конфликты с jre броузера MT>4. Не дружественны интерфейс — html страница предоставляет больше возможностей для оформления
Мда. Демонстрируете полное незнание предмета.
1. Никакое большинство классов AWT не deprecated. AWT был, есть и будет есть.
2. Долгое время, это смотря с чем сравнивать. Более менее сложное решение будет грузится и работать на том же DHML или Flash гораздо дольше.
3. Эт вот близко. Конфликтов с jre браузера не будет. Но вот проверять версию JRE у клиента придется.
4. Вообще чушь какая-то и там и там возможностей хоть отбавляй.
Теперь ближе к делу.
И так есть 2 направления в разработке апплетов.
1) Апплеты на MS JVM. Это там где только AWT. И то что будет работать скорее всего только в IE. Который вскоре может и не будет поддерживать Java. Вобщем безперспективняк.
2) Это апплеты, которые будет просить пользователя скачать JRE с сайта Sun.
Минус тут только 1. Надо заставлять пользователя скачивать этот самый JRE. Для довольно жирного клиентского решение это может оказатся самое то.
Поэтому для выбора "to applet or not to applet" надо исходить из того какая функциональность будет или не будет им реализовыватся. И на каких клиентов мы рассчитываем, не накладно ли им будет качать JRE.
Здравствуйте, AVM, Вы писали:
C0s>><SKIP> я-то тоже не уверен, что апплеты — это хорошо <SKIP> AVM>Почему?
Рискну ответить, хотя вопрос адресован и не мне.
IMHO, апплеты способны решать эффективно только узкий круг задач. Такие задачи находятся довольно не часто. ActiveX, Flash, DHTML составляют очень серьёзную конкуренцию апплетам, потому что так же эффективно решают эти задачи, но при этом не требуют загрузки JRE.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, MT, Вы писали:
MT>>1. Апплеты основаны на awt-классах, большинство из них depricated MT>>2. Долгое время загрузки и инициализации MT>>3. Апплет привязан к определенной версии java, возможны конфликты с jre броузера MT>>4. Не дружественны интерфейс — html страница предоставляет больше возможностей для оформления
B>Мда. Демонстрируете полное незнание предмета.
B>1. Никакое большинство классов AWT не deprecated. AWT был, есть и будет есть.
Компиляция проекта выдала более 100 , для небольшого приложения это много.
B>2. Долгое время, это смотря с чем сравнивать. Более менее сложное решение будет грузится и работать на том же DHML или Flash гораздо дольше.
Сложной логики на клиенте нет — проще перенести все на сервер (это опять же к изначальной дилеме — зачем апплет когда приложение обрабатывает ввод данных в форму)
B>3. Эт вот близко. Конфликтов с jre браузера не будет. Но вот проверять версию JRE у клиента придется. B>4. Вообще чушь какая-то и там и там возможностей хоть отбавляй.
Хм, не соглашусь — изменить страниц тривиальная задача, которая в идеале при правильном дизайне приложения задействует веб-дизайнера и веб-кодера, то что будет в этом случае с апплетом?
B>Теперь ближе к делу. B>И так есть 2 направления в разработке апплетов. B>1) Апплеты на MS JVM. Это там где только AWT. И то что будет работать скорее всего только в IE. Который вскоре может и не будет поддерживать Java. Вобщем безперспективняк. B>2) Это апплеты, которые будет просить пользователя скачать JRE с сайта Sun. B>Минус тут только 1. Надо заставлять пользователя скачивать этот самый JRE. Для довольно жирного клиентского решение это может оказатся самое то.
B>Поэтому для выбора "to applet or not to applet" надо исходить из того какая функциональность будет или не будет им реализовыватся. И на каких клиентов мы рассчитываем, не накладно ли им будет качать JRE.
Здравствуйте, Blazkowicz, Вы писали:
B>2) Это апплеты, которые будет просить пользователя скачать JRE с сайта Sun. B>Минус тут только 1. Надо заставлять пользователя скачивать этот самый JRE. Для довольно жирного клиентского решение это может оказатся самое то.
может быть, также стоит помнить про java web start — для "совсем жирных" клиентов, если я правильно понимаю, не всегда приемлемы внутриброузерные параметры "песочницы".
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, vladserge, Вы писали:
V>>лажа
C0s>я, конечно, понимаю, что краткость сестра сами-знаете-чего , но, может быть, стоит давать комментарии слишком резким высказываниям?
Пастернака не читал(про апплеты нефига незнаю) НО(!)...... вот как прозвучал вопрос.
А на неконструктивные вопросы совершенно не тянет отвечать конструктивно, предмет отсутствует.
по-настоящему коротко было бы если б я совсем не ответил, но было бы ли это лучше....
Здравствуйте, AVM, Вы писали:
C0s>><SKIP> я-то тоже не уверен, что апплеты — это хорошо <SKIP> AVM>Почему?
исключительно субъективно
допустим, есть набор требований, который реализуется без апплетов, только на html. без нужды лепить апплеты? — ни в коем случае.
предположим, возникает требование, которое дает фантазии разгуляться — прежде всего, фантазии заказчика, который хочет фишечки и еще бантички сбоку впридачу. тут уже надо смотреть — готов ли заказчик спонсировать свои аппетиты. обычно в такой ситуации апплеты рассматриваются как скачкообразное усложнение архитектуры, что влечет за собой массу подготовительных действий. при правильном финансовом и временном обосновании заказчик смягчает требования.
но у вас — другой случай, в котором апплеты _уже_ есть. наверное, надо отталкиваться от того, насколько легко удается нести бремя поддержки, и адекватны ли финансы заказчика это добра
Здравствуйте, MT, Вы писали:
B>>1. Никакое большинство классов AWT не deprecated. AWT был, есть и будет есть. MT>Компиляция проекта выдала более 100 , для небольшого приложения это много.
Мы говорим о классах AWT или о ворнингах в вашем проекте?
MT>Сложной логики на клиенте нет — проще перенести все на сервер (это опять же к изначальной дилеме — зачем апплет когда приложение обрабатывает ввод данных в форму)
Вот уже хорошо. Имеем требование — формы ввода данных. Да, использование апплета в данном случае не будет эффективным. Но не понадобится ли нам ещё к этим формам и красивый вывод данных a la автоматизированое рабочее место?
B>>4. Вообще чушь какая-то и там и там возможностей хоть отбавляй.
MT>Хм, не соглашусь — изменить страниц тривиальная задача, которая в идеале при правильном дизайне приложения задействует веб-дизайнера и веб-кодера, то что будет в этом случае с апплетом?
Опять же вроде мы говорили о дружественно интерфейсе, а теперь перешли на задачу апдейта. Тут так же надо исходить из того какая планируется разработка. Если есть более-менее нормальная спецификация, то не уже ли так часто придется модифицировать апплет?
Но если предполагается XP/Agile программинг, или, например формы будут менятся так же часто как отечественные законы, то тут ты на 100% прав. Регулярный апдейт апплета проигрывает простоте модификации HTML based решений.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, AVM, Вы писали:
C0s>>><SKIP> я-то тоже не уверен, что апплеты — это хорошо <SKIP> AVM>>Почему?
B>Рискну ответить, хотя вопрос адресован и не мне. B>IMHO, апплеты способны решать эффективно только узкий круг задач.
Чем определяется эта узость? Безопастностью? Бездарностью програмиста?
если нужно отобразить обычное поле и кнопку, то тут да, все технологии пересекаются.
Как с пмощью DHTML отобразить содержимое DXF файла? Где взять такой редактор кода и столько готового кода на ActionScript(Flash) какой есть у JAVA. Небывает "песочниц" для ActiveX.
B> но при этом не требуют загрузки JRE.
Здравствуйте, MT, Вы писали:
MT>Поделитесь мнением и опытом изпользования апплетов на клиентской части. MT>Есть приложение (обработка форм — ввод данных) основанное на апплетах — нужно убедить заказчика что это не есть хорошо, и лучше переделать чем поддерживать то что уже написано. MT>Спасибо.
Приложение используется работниками организации заказчика, или его клиентами?
Каково количество пользователей (единицы, десятки, сотни, тысячи, больше)?
Здравствуйте, Blazkowicz, Вы писали:
B>Но если предполагается XP/Agile программинг, или, например формы будут менятся так же часто как отечественные законы, то тут ты на 100% прав. Регулярный апдейт апплета проигрывает простоте модификации HTML based решений.
Мы такие разные....
По мне так все определяется инструментом. Рефакторинг .
Куда как проще сопровождать, отслеживать и обновлять когда все сделанно в одной идеологиии на одной языковой платформе.
Здравствуйте, nant, Вы писали:
N>Здравствуйте, MT, Вы писали:
MT>>Поделитесь мнением и опытом изпользования апплетов на клиентской части. MT>>Есть приложение (обработка форм — ввод данных) основанное на апплетах — нужно убедить заказчика что это не есть хорошо, и лучше переделать чем поддерживать то что уже написано. MT>>Спасибо.
N>Приложение используется работниками организации заказчика, или его клиентами? N>Каково количество пользователей (единицы, десятки, сотни, тысячи, больше)?
N>Вопросы имеют принципиальное значение.
Сотрудниками предприятия (офисы удаленные в том числе)
Здравствуйте, vladserge, Вы писали:
B>>Рискну ответить, хотя вопрос адресован и не мне. B>>IMHO, апплеты способны решать эффективно только узкий круг задач.
V>Чем определяется эта узость? Безопастностью? Бездарностью програмиста?
Вроде бы из поста должно было быть понятно. Ну, если спросил то отвечу:
Более эффективными альтернативными решениями.
V>если нужно отобразить обычное поле и кнопку, то тут да, все технологии пересекаются. V>Как с пмощью DHTML отобразить содержимое DXF файла?
Как часто приходится на вэб страничке динамически отображать контент клиентского DXF?
V>Где взять такой редактор кода и столько готового кода на ActionScript(Flash) какой есть у JAVA.
IDE — не аргумент. Не много java программистов которые способны в короткие сроки создать симпатичную визуализацию.
V>Небывает "песочниц" для ActiveX.
И?
B>> но при этом не требуют загрузки JRE. V>для Flash поддержки нужен тоже свой runtime.
Flash runtime уже имеется у подавляющего большинства пользователей.
Здравствуйте, MT, Вы писали:
MT>1. Апплеты основаны на awt-классах, большинство из них depricated MT>2. Долгое время загрузки и инициализации MT>3. Апплет привязан к определенной версии java, возможны конфликты с jre броузера MT>4. Не дружественны интерфейс — html страница предоставляет больше возможностей для оформления
блиин, вот не надо
вы приводите частные случаи, это не минус технологии в общем
а про недружественный интерфейс — вообще на вашей совести :)
Здравствуйте, vladserge, Вы писали:
B>>Но если предполагается XP/Agile программинг, или, например формы будут менятся так же часто как отечественные законы, то тут ты на 100% прав. Регулярный апдейт апплета проигрывает простоте модификации HTML based решений.
V>Мы такие разные....
V>По мне так все определяется инструментом. Рефакторинг . V>Куда как проще сопровождать, отслеживать и обновлять когда все сделанно в одной идеологиии на одной языковой платформе.
Сергей, ты всегда судишь с позиции себя — любимого разработчика. И никогда с позиции эффективности денежных ресурсов. И при это при том что мы уже давно живем в капитализме.
Если что случится с java девелопером, который разработал супер мощный апплет. То во что выльется модификация решения заказчику? Купить студента на месяц, который тебе подкрутит HTML. Или нанять крутого спеца, который стоит раз в 5 — 10 дороже. Который разберется в существующем клиент-серверном взаимодействии и сможет эффективно модифицировать существующее решение?
Здравствуйте, Blazkowicz, Вы писали:
B>Как часто приходится на вэб страничке динамически отображать контент клиентского DXF?
Возможности аплета покрывают всю функциональность доступную DHTML.
Тут я привел пример где на DHTML(в отличии от JAVA) просто вообще никогда решения небудет.
V>>Где взять такой редактор кода и столько готового кода на ActionScript(Flash) какой есть у JAVA. B>IDE — не аргумент. Не много java программистов которые способны в короткие сроки создать симпатичную визуализацию.
V>>Небывает "песочниц" для ActiveX. B>И?
незнаю как кто, а я ActiveX из интернета (кроме от MS) никогда не ставлю.
B>>> но при этом не требуют загрузки JRE. V>>для Flash поддержки нужен тоже свой runtime. B>Flash runtime уже имеется у подавляющего большинства пользователей.
те читать нужно так. Большинство пользователей скачало и поставило поддержку Flash.
ну так ничто не мешает скачать поддержку JAVA. это так же просто
(Я правильно понял тему. Мы говорим о +/- решении на Applet вообще, а не конкретно по тому с чего начался топик.)
Здравствуйте, vladserge, Вы писали:
V>те читать нужно так. Большинство пользователей скачало и поставило поддержку Flash.
как-то в моем IE она сама собой появилась, а вот в mozilla наоборот после какого-то апдейта слетела и больше не поднимается
так что я с Flash уже примерно как с месяц не особо дружу
V>ну так ничто не мешает скачать поддержку JAVA. это так же просто
думается, модемные пользователи в качестве контраргумента скажут, что инсталляшка JRE больше, чем Flash
впрочем, в контексте вопроса автора и то и это одинаково — раз клиенты суть члены организации, то могут поставить то, что им скажут "сверху" (или, админы могут им поставить)
Здравствуйте, Blazkowicz, Вы писали:
B>Сергей, ты всегда судишь с позиции себя — любимого разработчика. И никогда с позиции эффективности денежных ресурсов. И при это при том что мы уже давно живем в капитализме.
Я в двух позициях одновременно. Стандартная ситуация прибегает заказчик — мне тут побыстрому, пару кнопочек, пару полей ...
В итоге выростает в нечто совсем непохожее на то, чего он хотел когда пришел. Поэтому пердпочитаю "приподнять" его на мой уровнь, а если не получается тогда да, он не мой клиент.
B>Если что случится с java девелопером, который разработал супер мощный апплет. То во что выльется модификация решения заказчику? Купить студента на месяц, который тебе подкрутит HTML. Или нанять крутого спеца, который стоит раз в 5 — 10 дороже. Который разберется в существующем клиент-серверном взаимодействии и сможет эффективно модифицировать существующее решение?
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, vladserge, Вы писали:
B>>>Но если предполагается XP/Agile программинг, или, например формы будут менятся так же часто как отечественные законы, то тут ты на 100% прав. Регулярный апдейт апплета проигрывает простоте модификации HTML based решений.
V>>Мы такие разные....
V>>По мне так все определяется инструментом. Рефакторинг . V>>Куда как проще сопровождать, отслеживать и обновлять когда все сделанно в одной идеологиии на одной языковой платформе.
B>Сергей, ты всегда судишь с позиции себя — любимого разработчика. И никогда с позиции эффективности денежных ресурсов. И при это при том что мы уже давно живем в капитализме.
B>Если что случится с java девелопером, который разработал супер мощный апплет. То во что выльется модификация решения заказчику? Купить студента на месяц, который тебе подкрутит HTML. Или нанять крутого спеца, который стоит раз в 5 — 10 дороже. Который разберется в существующем клиент-серверном взаимодействии и сможет эффективно модифицировать существующее решение?
Подписываюсь — незначительные интерфейс-изменения в данном случае не обходятся без девелопера, когда как линк вставить или текс поменять не должны быть настолько трудоемкими (и дорогими).
Здравствуйте, C0s, Вы писали:
C0s>как-то в моем IE она сама собой появилась,
трояны и черви тоже, именно так ими же путями, сами собой, вдруг появляются. все ли у Вас хорошо с безопастностью?
C0s>а вот в mozilla наоборот после какого-то апдейта слетела и больше не поднимается C0s>так что я с Flash уже примерно как с месяц не особо дружу
V>>ну так ничто не мешает скачать поддержку JAVA. это так же просто
C0s>думается, модемные пользователи в качестве контраргумента скажут, что инсталляшка JRE больше, чем Flash
поэтому я и стараюсь писать не вылезая за jdk 1.1.8 она предустановленна в Win 95, но лучше её проапгрейдить до той что в win 98
А если из MS VM повыкидывать WFC классы, то останется всего лишь 3мb из 5 — совсем немного.
MT>Подписываюсь — незначительные интерфейс-изменения в данном случае не обходятся без девелопера, когда как линк вставить или текс поменять не должны быть настолько трудоемкими (и дорогими).
те, вы экономя бюджет своего заказчика, согласны на маленькую зарплату НЕдевелопера...
редкая забота о заказчике тронут
Здравствуйте, vladserge, Вы писали:
B>>Как часто приходится на вэб страничке динамически отображать контент клиентского DXF? V>Возможности аплета покрывают всю функциональность доступную DHTML. V>Тут я привел пример где на DHTML(в отличии от JAVA) просто вообще никогда решения небудет.
Тоже могу привести как минимум 2 примера где апплеты очень эффективно работают. Никто не говорит что таких ниш нет. Они есть. Но их на столько мало, что приходится серьёзно анализировать область прежде чем решится на использование в ней апплета.
V>>>Небывает "песочниц" для ActiveX. B>>И? V>незнаю как кто, а я ActiveX из интернета (кроме от MS) никогда не ставлю.
Ты авторитетно заявляешь что 90% пользователей вэб делают точно так же? Для них все равно разрешить ли установится ActiveX или дать пермишены апплету. Они понятия не имеют к чему это приведет. От них требуется только да/нет, и исходят они из того нужно или нет им предлагаемое решение. И вопросы безопастности тут встают, к сожалению, в последнюю очередь.
B>>Flash runtime уже имеется у подавляющего большинства пользователей. V>те читать нужно так. Большинство пользователей скачало и поставило поддержку Flash. V>ну так ничто не мешает скачать поддержку JAVA. это так же просто
Такое очучение, что тебе просто хочется поспорить. Приблизительная математика:
90% — уже имеют Flash.
10% — уже имеют JRE.
Мы предлагаем скачать пользователю JRE. Мы не знаем на сколько эффективное наше решение поэтому считаем пользователь скачает его с вероятностью 50%.
С flash мы имеем 90% + 5% запустивших нашу программу. C апплетом мы имеем 10% + 45%.
Итого 95% vs 55%.
То есть с учетом того что рапространение flash среди пользователей больше решение на нем будет более эффективным (если отбросиь все другие параметры).
V>(Я правильно понял тему. Мы говорим о +/- решении на Applet вообще, а не конкретно по тому с чего начался топик.)
И да и нет. Все выше написаное относится к апплетам вообще. Но анализ с учетом исходного поста будет как минимум интересен его автору. Так что можно и нужно их обсуждать с соответствующей оговоркой.
Re: Апплет - за и против
От:
Аноним
Дата:
07.11.05 18:42
Оценка:
Здравствуйте, MT, Вы писали:
MT>Поделитесь мнением и опытом изпользования апплетов на клиентской части.
Апплеты традиционно используются в качестве клиентов в приложениях, отображающих в реальном времени результаты биржевых торгов. Клиент — многопоточное приложение, общающееся с сервером через сокеты. Частичная обработка данных на клиенте, кэш и собственный протокол позволяют уменьшить трафик. Апплет позволяет трейдеру подсоединиться к системе из любого места (теоретически, так как теперь уже необходимо наличие java плагина), где есть интернет.
А если нужны только формочки и кнопочки, то наверное DHTML удобнее.
В принципе, все верно, только маленькое замечение.
B>1) Апплеты на MS JVM. Это там где только AWT. И то что будет работать скорее всего только в IE. Который вскоре может и не будет поддерживать Java. Вобщем безперспективняк.
Неверно, апплет, написанный под MS JVM будет работать везде, где есть хоть какая-то ява-машина (кроме старой макоси, где я видел машину 1.0, работающую в старом нетскейпе). По крайней мере пока не отменят обратную совместимость.
Здравствуйте, MT, Вы писали:
MT>Здравствуйте, nant, Вы писали:
N>>Здравствуйте, MT, Вы писали:
MT>>>Поделитесь мнением и опытом изпользования апплетов на клиентской части. MT>>>Есть приложение (обработка форм — ввод данных) основанное на апплетах — нужно убедить заказчика что это не есть хорошо, и лучше переделать чем поддерживать то что уже написано. MT>>>Спасибо.
N>>Приложение используется работниками организации заказчика, или его клиентами? N>>Каково количество пользователей (единицы, десятки, сотни, тысячи, больше)?
N>>Вопросы имеют принципиальное значение.
MT>Сотрудниками предприятия (офисы удаленные в том числе)
Так я и думал.
Я смотрю там выше по ветке методом последовательных приходят к правильному решению с правильной мотивацией. Мотивация для заказчика — финансовая целесообразность.
Решение вопросов:
1) Стоимости поддержки и наличия deprecation — рефакторинг.
2) Скорости работы — рефакторинг + оптимизация, если таковая понадобится после рефакторинга.
3) Проблем с версией Java — переход на JDK 1.5. Лучше после рефакторинга, так как в общем случае — дешевле.
4) Проблем с установкой Java — сборка инсталляционного пакета, который установит нужную версию Javа или, если таковая уже установлена, сконфигурирует Java Plugin отдельного браузера
Deployment такого пакета — через механизмы ОС ( profile, group policy, etc), либо предложением пользователю: у вас не та версия, поставьте заботливо подготовленный пакет.
А вбухивать деньги (а вы посчитайте во что выльется перетестирование и миграция, да) и время только для того, чтобы уйти с обной технологии на другую, потому как оная не нравится разработчику — я бы на месте заказчика (его CIO как минимум) не стал.
Я виду не все, поэтому может быть и другой вариант развития событий — вы доказываете почему плохо _существующее_решение_, а тезнология на котором оно сделано — это второй план. Даете оценку на создание нового решения и на приведение того, что есть в нужный заказчику вид (что именно этот вид нужен заказчику — нужно доказать). И тогда уже разговор приобретает предметный для закахчика вид. X1 против X2 с возможностями F1 против F2
Мало того, во вормя сбора этой информации вы найдете еще некоторое количество проблем в том, как существующая система поддерживает бизнес заказчика.
Тут тоже будет определенный пласт работы, которую можно предлагать сделать.
<advise nooffence="on">
Cоздавать себе объем работы манипулированием тем, на какой технологии сделана система — не есть профессиональный подход. Хороший игрок — это тот, кто не проигрывает с плохими картами, а не тот, что выигрывает с хорошими.
</advise>
Здравствуйте, Cider, Вы писали:
C>Неверно, апплет, написанный под MS JVM будет работать везде, где есть хоть какая-то ява-машина (кроме старой макоси, где я видел машину 1.0, работающую в старом нетскейпе). По крайней мере пока не отменят обратную совместимость.
К сожалению подобной информацией в полном объёме не владею. Но сотня ворнингов в проекте настораживает. По крайней мере каждый из них нужно будет проверить на современных JRE
Имел ввиду Java 1.4 и выше. Приведенная статистика учитывает MS JVM. И так понятно что она предустановлена и о ней речь не идет. Так что не надо тут "цифрами" раскидываться.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, AVM, Вы писали:
C0s>>><SKIP> я-то тоже не уверен, что апплеты — это хорошо <SKIP> AVM>>Почему?
B>Рискну ответить, хотя вопрос адресован и не мне. B>IMHO, апплеты способны решать эффективно только узкий круг задач. Такие задачи находятся довольно не часто. ActiveX, Flash, DHTML составляют очень серьёзную конкуренцию апплетам, потому что так же эффективно решают эти задачи, но при этом не требуют загрузки JRE.
Позволю с тобой не согласиться. Аплеты это обычное десктопное java приложение (с некоторыми ограничениями по security) + удобный механизм доставки приложения на клиент.
Самый серьезный и принципиальный минус у аплетов — необходимо наличие JVM на клиенте. К сожалению Sun &MS сделали все от них зависящее, чтобы JVM by default отсутствовала на большинстве десктопов.
IMHO аплеты ничем не хуже обычной java application. Правда с появлением Java Web Start они начали смахивать на неуловимого Джо, за исключением некоторых случаев. Похоже один из этих случаев мы сейчас рассматриваем — есть legacy system кторую надо промантейнить, и есть мы — пра-пра-пра-правнуки интернационала "весь мир насилья мы разрушим до основания " и все перепишем нафик заново на технологии T . Проблема в том, что к тому моменту как все будет переписано, технология Т уже тоже будет немодной. Круг замкнется.
Здравствуйте, vladserge, Вы писали:
V>поэтому я и стараюсь писать не вылезая за jdk 1.1.8 она предустановленна в Win 95, но лучше её проапгрейдить до той что в win 98
MS JVM, пусть покоиться она с миром, и будем вспоминать в суе войну на которой она погибла.
Здравствуйте, AVM, Вы писали:
AVM>Позволю с тобой не согласиться. AVM>Самый серьезный и принципиальный минус у аплетов — необходимо наличие JVM на клиенте.
Это такой приём полемики? Выразить несогласие и повторить слова
Здравствуйте, C0s, Вы писали:
C0s>допустим, есть набор требований, который реализуется без апплетов, только на html. без нужды лепить апплеты? — ни в коем случае.
почти согласен
C0s>предположим, возникает требование, которое дает фантазии разгуляться — прежде всего, фантазии заказчика, который хочет фишечки и еще бантички сбоку впридачу. тут уже надо смотреть — готов ли заказчик спонсировать свои аппетиты. обычно в такой ситуации апплеты рассматриваются как скачкообразное усложнение архитектуры, что влечет за собой массу подготовительных действий. при правильном финансовом и временном обосновании заказчик смягчает требования.
Поясни плиз, почему аплеты должны усложнить архитектуру, да еще скачкообразно?
Какое они вообще влияние на архитектуру могут оказать? В простейшем случае это presentation (причем может быть очень навороченный presentation, с графиками, картами, VoIP, etc), если архитектор вставил в аплет business logic это не проблема с аплетами, это проблема с архитектором.
C0s>но у вас — другой случай, в котором апплеты _уже_ есть. наверное, надо отталкиваться от того, насколько легко удается нести бремя поддержки, и адекватны ли финансы заказчика это добра
IMHO написать тонкого клиента на Swing-е (считай applet), будет менее трудоемко, чем тоже самое изобразить например на Struts-е.
Здравствуйте, vladserge, Вы писали:
B>>Имел ввиду Java 1.4 и выше. Приведенная статистика учитывает MS JVM. И так понятно что она предустановлена и о ней речь не идет.
V>почему , говорили о JAVA вообще.
Не понял что вообще начинается? Обвинения в отстутствие логики?
Если MSJVM находится во всех последних версиях ослика. А ослик захватил 90% рынка. То о каких 10% можно было бы говорить???
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, AVM, Вы писали:
AVM>>Позволю с тобой не согласиться. AVM>>Самый серьезный и принципиальный минус у аплетов — необходимо наличие JVM на клиенте.
B>Это такой приём полемики? Выразить несогласие и повторить слова
Здравствуйте, AVM, Вы писали:
C0s>>предположим, возникает требование, которое дает фантазии разгуляться — прежде всего, фантазии заказчика, который хочет фишечки и еще бантички сбоку впридачу. тут уже надо смотреть — готов ли заказчик спонсировать свои аппетиты. обычно в такой ситуации апплеты рассматриваются как скачкообразное усложнение архитектуры, что влечет за собой массу подготовительных действий. при правильном финансовом и временном обосновании заказчик смягчает требования. AVM>Поясни плиз, почему аплеты должны усложнить архитектуру, да еще скачкообразно?
Потому что появляется дополнительный способ доставки данных клиенту. И надо поддерживать уже 2 способа.
C0s>>но у вас — другой случай, в котором апплеты _уже_ есть. наверное, надо отталкиваться от того, насколько легко удается нести бремя поддержки, и адекватны ли финансы заказчика это добра AVM>IMHO написать тонкого клиента на Swing-е (считай applet), будет менее трудоемко, чем тоже самое изобразить например на Struts-е.
Не очень понимаю что значит "изобразить на Struts-е", и откуда могло появится такое мнение.
Для того чтобы обеспечить активное общение клиента с сервером в случае апплета надо много думать об уровне транспорта (способ доставки данных и формат этих данных). В то время как servlet based решения таких проблем не имеют. Заботится нужно только о представлении и серверной логике.
AVM>IMHO, апплеты способны решать эффективно только узкий круг задач.
Этим хотел сказать что альтернативы смогут решить те же задачи более эффективно при этом не требуя дополнительных загрузок. Поэтому область где апплеты могут себя показать себя более эффективно (чем эти решения) и сужается.
AVM>А повторил я свои слова
N>А вбухивать деньги (а вы посчитайте во что выльется перетестирование и миграция, да) и время только для того, чтобы уйти с обной технологии на другую, потому как оная не нравится разработчику — я бы на месте заказчика (его CIO как минимум) не стал.
N>Я виду не все, поэтому может быть и другой вариант развития событий — вы доказываете почему плохо _существующее_решение_, а тезнология на котором оно сделано — это второй план. Даете оценку на создание нового решения и на приведение того, что есть в нужный заказчику вид (что именно этот вид нужен заказчику — нужно доказать). И тогда уже разговор приобретает предметный для закахчика вид. X1 против X2 с возможностями F1 против F2
N>Мало того, во вормя сбора этой информации вы найдете еще некоторое количество проблем в том, как существующая система поддерживает бизнес заказчика. N>Тут тоже будет определенный пласт работы, которую можно предлагать сделать.
N><advise nooffence="on"> N>Cоздавать себе объем работы манипулированием тем, на какой технологии сделана система — не есть профессиональный подход. Хороший игрок — это тот, кто не проигрывает с плохими картами, а не тот, что выигрывает с хорошими. N></advise>
Обьем работы в принципе создан — вопрос в том как эффективнее доделать (или переделать) оставшиеся 50%. На данный момент большая часть кода — гуи (апплет) — в купе с бизнес логикой впаяной в эти апплеты (тут правильно заметили — не апплетов проблема, а архитектора...)
Здравствуйте, Blazkowicz, Вы писали:
B>Если что случится с java девелопером, который разработал супер мощный апплет. То во что выльется модификация решения заказчику? Купить студента на месяц, который тебе подкрутит HTML. Или нанять крутого спеца, который стоит раз в 5 — 10 дороже. Который разберется в существующем клиент-серверном взаимодействии и сможет эффективно модифицировать существующее решение?
Правильная архитетура приложения подразумевает:
1. Интерфейсная часть представления (используемые компоненты, цвета и прочий дизайн) отделена от логики представления.
2. Логика представления отделена от бизнес логики. Логика представления находится на аплете, бизнес логика — на сервере.
Таким образом, если нам нужно поменять только дизайн при правильной архитектуре в аплете придется поменять совсем немного.
Другое дело, что в отличие от веб-приложений, где интерефейс просто не позволяет в себя впихнуть какую-нибудь логику (java/script и dhtml не рассматривается) и поэтому разработчик вынужден использовать правильную архитектуру, в богатом клиенте можно смешать интерфейс / логику представления / бизнес-логику и тогда действительно чтобы во всем разобраться нужен крутой спец. Или тот чел, который писал аплет.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, AVM, Вы писали:
C0s>>>предположим, возникает требование, которое дает фантазии разгуляться — прежде всего, фантазии заказчика, который хочет фишечки и еще бантички сбоку впридачу. тут уже надо смотреть — готов ли заказчик спонсировать свои аппетиты. обычно в такой ситуации апплеты рассматриваются как скачкообразное усложнение архитектуры, что влечет за собой массу подготовительных действий. при правильном финансовом и временном обосновании заказчик смягчает требования. AVM>>Поясни плиз, почему аплеты должны усложнить архитектуру, да еще скачкообразно? B>Потому что появляется дополнительный способ доставки данных клиенту. И надо поддерживать уже 2 способа.
Честно говоря не понял про два способа, какие и откуда они взялись?
C0s>>>но у вас — другой случай, в котором апплеты _уже_ есть. наверное, надо отталкиваться от того, насколько легко удается нести бремя поддержки, и адекватны ли финансы заказчика это добра AVM>>IMHO написать тонкого клиента на Swing-е (считай applet), будет менее трудоемко, чем тоже самое изобразить например на Struts-е. B>Не очень понимаю что значит "изобразить на Struts-е", и откуда могло появится такое мнение.
IMHO UI на Swing написать и отладить быстрее и легче чем тот же UI реализовать например на Struts. (UI на голых JSP/Servlets писал в далекой молодости и тогда же понял бесперспективность этого занятия). Подчекну что это мое IMHO.
B>Для того чтобы обеспечить активное общение клиента с сервером в случае апплета надо много думать об уровне транспорта (способ доставки данных и формат этих данных).
Посмотри здесь и здесь. Быстро дешево и со вкусом
B>В то время как servlet based решения таких проблем не имеют. Заботится нужно только о представлении и серверной логике.
Там есть другие проблемы, например динамическое обновление данных без перезагрузки страницы, отладка в контейнере, необходимость знать смежные технологии, такие как HTML/DHTML/JavaScript/Tag Libs/etc.
Здравствуйте, AVM, Вы писали:
AVM>Здравствуйте, vladserge, Вы писали:
V>>поэтому я и стараюсь писать не вылезая за jdk 1.1.8 она предустановленна в Win 95, но лучше её проапгрейдить до той что в win 98 AVM>MS JVM, пусть покоиться она с миром, и будем вспоминать в суе войну на которой она погибла.
ну Вы не правы, она попрежнему рвет любую JDK как тузик грелку К вопросу о шустриках
Здравствуйте, AVM, Вы писали:
AVM>Честно говоря не понял про два способа, какие и откуда они взялись?
Сервер -> HTML
Сервер -> Модель -> Applet
B>>Не очень понимаю что значит "изобразить на Struts-е", и откуда могло появится такое мнение. AVM>IMHO UI на Swing написать и отладить быстрее и легче чем тот же UI реализовать например на Struts. (UI на голых JSP/Servlets писал в далекой молодости и тогда же понял бесперспективность этого занятия). Подчекну что это мое IMHO.
Но ведь Struts не панацея. Существует огромное количество альтернатиных решений для web представления.
B>>Для того чтобы обеспечить активное общение клиента с сервером в случае апплета надо много думать об уровне транспорта (способ доставки данных и формат этих данных). AVM>Посмотри здесь и здесь. Быстро дешево и со вкусом
Сейчас тебе Сергей расскажет что такое быстро и дешево.
Здравствуйте, AVM, Вы писали:
AVM>Поясни плиз, почему аплеты должны усложнить архитектуру, да еще скачкообразно? AVM>Какое они вообще влияние на архитектуру могут оказать? В простейшем случае это presentation (причем может быть очень навороченный presentation, с графиками, картами, VoIP, etc), если архитектор вставил в аплет business logic это не проблема с аплетами, это проблема с архитектором.
здесь уже Blazkowicz ответил, я лишь добавлю, что неразумно было бы пользоваться одними достижениями апплетов (более навороченный gui), но не пользоваться другими (возможность организации binary-стримов общения с сервером для исключения лишних шагов преобразования в строки и обратно), тогда становится очевидно, что на сервере надо готовить другие листенеры (в смысле другого типа)
XML для меня — та же строка, только вид сбоку... но даже если и использовать его и поверх http, то все равно писать отдельные сервлеты с несколько другой логикой
C0s>>но у вас — другой случай, в котором апплеты _уже_ есть. наверное, надо отталкиваться от того, насколько легко удается нести бремя поддержки, и адекватны ли финансы заказчика это добра AVM>IMHO написать тонкого клиента на Swing-е (считай applet), будет менее трудоемко, чем тоже самое изобразить например на Struts-е.
по-моему понятие легкости здесь проистекает исключительно из личных предпочтений и опыта. в том смысле, что на swinge я не программировал вообще никогда, а на struts+velocity+tiles+разные_дополнительные_наработки удавалось лепить вполне сносные визарды и прочие элементы gui с минимальным привлечением javascript, а местами даже без оного.
безусловно, их как решение тоже можно было бы критиковать и без особых проблем найти слабые стороны, ограничения в примененении и т.д. и т.п. важно другое: и там и там требуются упомянутые разные дополнительные наработки (общие классы). получается, что в проекте, который, скажем, начинался без апплетов, пришлось создать набор доп. классов. если потребовалось добавить апплеты — сразу получаем необходимость в новом наборе доп. классов.
Здравствуйте, vladserge, Вы писали:
V>Здравствуйте, AVM, Вы писали:
AVM>>Здравствуйте, vladserge, Вы писали:
V>>>поэтому я и стараюсь писать не вылезая за jdk 1.1.8 она предустановленна в Win 95, но лучше её проапгрейдить до той что в win 98 AVM>>MS JVM, пусть покоиться она с миром, и будем вспоминать в суе войну на которой она погибла.
V>ну Вы не правы, она попрежнему рвет любую JDK как тузик грелку К вопросу о шустриках
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, AVM, Вы писали:
AVM>>Честно говоря не понял про два способа, какие и откуда они взялись? B>Сервер -> HTML B>Сервер -> Модель -> Applet
Не давай уж тогда вот так:
1. DB — Entity — Business Logic — Transfer Object — Presentation (Servlet/JSP/Struts/etc)
2. DB — Entity — Business Logic — Transfer Object — Presentation (Applet)
Практически тоже самое, только раскидано по разным хостам. Даже транспорт один и тот же может быть HTTP.
B>>>Не очень понимаю что значит "изобразить на Struts-е", и откуда могло появится такое мнение. AVM>>IMHO UI на Swing написать и отладить быстрее и легче чем тот же UI реализовать например на Struts. (UI на голых JSP/Servlets писал в далекой молодости и тогда же понял бесперспективность этого занятия). Подчекну что это мое IMHO. B>Но ведь Struts не панацея. Существует огромное количество альтернатиных решений для web представления.
Ты думаешь они сильно проще/быстрее/легче? Как только мы говорим Web UI, считай что мы сразу захватываем несколько связанных между собой технологий (HTML,DHTML,CSS,DOM,JavaScript,Servlet/JSP-based framework,Browsers compatibility, etc). Связать все это до кучи и отладить — задачка еще та.
B>>>Для того чтобы обеспечить активное общение клиента с сервером в случае апплета надо много думать об уровне транспорта (способ доставки данных и формат этих данных). AVM>>Посмотри здесь и здесь. Быстро дешево и со вкусом B>Сейчас тебе Сергей расскажет что такое быстро и дешево.
Вкуса нет
Здравствуйте, C0s, Вы писали:
C0s>здесь уже Blazkowicz ответил, я лишь добавлю, что неразумно было бы пользоваться одними достижениями апплетов (более навороченный gui), но не пользоваться другими (возможность организации binary-стримов общения с сервером для исключения лишних шагов преобразования в строки и обратно), тогда становится очевидно, что на сервере надо готовить другие листенеры (в смысле другого типа) C0s>XML для меня — та же строка, только вид сбоку... но даже если и использовать его и поверх http, то все равно писать отдельные сервлеты с несколько другой логикой
IMHO, в данном контексте, плюс у XML тут один — переносимость. Когда через пару лет custonmer наймет человека и этот человек, порекомендует переписать presentation на NET, то customer сможет сделать reuse business layer-а и съэконить на этом немножко денег.
C0s>>>но у вас — другой случай, в котором апплеты _уже_ есть. наверное, надо отталкиваться от того, насколько легко удается нести бремя поддержки, и адекватны ли финансы заказчика это добра AVM>>IMHO написать тонкого клиента на Swing-е (считай applet), будет менее трудоемко, чем тоже самое изобразить например на Struts-е.
C0s>по-моему понятие легкости здесь проистекает исключительно из личных предпочтений и опыта. в том смысле, что на swinge я не программировал вообще никогда, а на struts+velocity+tiles+разные_дополнительные_наработки удавалось лепить вполне сносные визарды и прочие элементы gui с минимальным привлечением javascript, а местами даже без оного. C0s>безусловно, их как решение тоже можно было бы критиковать и без особых проблем найти слабые стороны, ограничения в примененении и т.д. и т.п. важно другое: и там и там требуются упомянутые разные дополнительные наработки (общие классы). получается, что в проекте, который, скажем, начинался без апплетов, пришлось создать набор доп. классов. если потребовалось добавить апплеты — сразу получаем необходимость в новом наборе доп. классов.
У меня больше опыта при написании presentation на Web, чем на Swing. Наработок соответственно для web больше, но на swing-е у меня (да и у коллег тоже) получается быстрее.
Здравствуйте, AVM, Вы писали:
AVM>IMHO, в данном контексте, плюс у XML тут один — переносимость. Когда через пару лет custonmer наймет человека и этот человек, порекомендует переписать presentation на NET, то customer сможет сделать reuse business layer-а и съэконить на этом немножко денег.
с одной стороны я вижу "если" — "если наймет кого-то, который порекомендует то-то и т.д."
с другой стороны многие забывают, что серьезный переносимый XML начинается с нехилых XML-схем с применением пространств имен. которые в разработке также не просты, как и бинарные технологии. при этом и то и другое при соответствующей документации осваивается "новым человеком" примерно с эквивалентной скоростью.
но тогда возникает вопрос — зачем делать что-то, что требует оверхеда в runtime, если это можно не делать? причем в ситуации, когда "не делать" означает "писать меньше кода"
Здравствуйте, C0s, Вы писали:
C0s>с другой стороны многие забывают, что серьезный переносимый XML начинается с нехилых XML-схем с применением пространств имен. которые в разработке также не просты, как и бинарные технологии. при этом и то и другое при соответствующей документации осваивается "новым человеком" примерно с эквивалентной скоростью.
Лично мне бинарный протокол писать читать и отлаживать проще.
Польза, от возможности увидеть глазами, чего там передается сомнительна.
Максимум, что можно выжать, так это визуально проконтролировать и понять на каком этапе ошибка, на этапе формирования пакета или на этапе чтения. Ну так это мелочи. Формируем и посылаем тестовый пакет, и начинаем пошагово его разбирать, чего сложного непонимаю.
C0s>но тогда возникает вопрос — зачем делать что-то, что требует оверхеда в runtime, если это можно не делать?
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, AVM, Вы писали:
AVM>>IMHO, в данном контексте, плюс у XML тут один — переносимость. Когда через пару лет custonmer наймет человека и этот человек, порекомендует переписать presentation на NET, то customer сможет сделать reuse business layer-а и съэконить на этом немножко денег.
C0s>с одной стороны я вижу "если" — "если наймет кого-то, который порекомендует то-то и т.д." C0s>с другой стороны многие забывают, что серьезный переносимый XML начинается с нехилых XML-схем с применением пространств имен. которые в разработке также не просты, как и бинарные технологии. при этом и то и другое при соответствующей документации осваивается "новым человеком" примерно с эквивалентной скоростью.
Вот тут проявляется второй плюс XML — XML спецификации от W3C вообще, и группа спецификаций DOM в частности. Там определяются platform independent интерфейсы для разбора XML документов. Это я к тому что через пару лет, в новой платформе ты наверняка найдешь этот интерфейс для работы с XML документом, но там скорее всего не будет класса, способного правильно прочитать object из двоичного
java-based потока.
C0s>но тогда возникает вопрос — зачем делать что-то, что требует оверхеда в runtime, если это можно не делать?
Для portability & supportability. Разработать софт — 30% бюджета, внедрить софт — 70% бюджета, легкость сопровождения софта в условиях меняющегося бизнеса — бесценна. Не забывай, что enterprise software пишется на годы.
C0s>причем в ситуации, когда "не делать" означает "писать меньше кода"
Не совсем понятно, поясни плиз.
Здравствуйте, AVM, Вы писали:
C0s>>с одной стороны я вижу "если" — "если наймет кого-то, который порекомендует то-то и т.д." C0s>>с другой стороны многие забывают, что серьезный переносимый XML начинается с нехилых XML-схем с применением пространств имен. которые в разработке также не просты, как и бинарные технологии. при этом и то и другое при соответствующей документации осваивается "новым человеком" примерно с эквивалентной скоростью. AVM>Вот тут проявляется второй плюс XML — XML спецификации от W3C вообще, и группа спецификаций DOM в частности. Там определяются platform independent интерфейсы для разбора XML документов. Это я к тому что через пару лет, в новой платформе ты наверняка найдешь этот интерфейс для работы с XML документом, но там скорее всего не будет класса, способного правильно прочитать object из двоичного AVM>java-based потока.
Я вот никак не могу догнать в чем спор? Сергей говорит, что XML сакс а бинарный поток рулит. Ты говоришь что это не так. Но вот контекста спора то не обозначили. Оба формата имеют право на жизнь, только где-то живучее оказывается один, где-то второй. Это не точка зрения — это факт, и спорить с ним считаю безсмысленно. Почему бы не прекратить полемику?
Здравствуйте, 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, чтоб реализовать то что вы говорили, шрифт задать, линк добавить.
Если хочешь выскажи эти агрументы здесь и форумчане их обсудят.
по сравнению с html — нет
1с рулит 
тронут 
не знал. эх пойду щас кой кого носом натыкаю.
На вкус и цвет...
