Поделитесь мнением и опытом изпользования апплетов на клиентской части.
Есть приложение (обработка форм — ввод данных) основанное на апплетах — нужно убедить заказчика что это не есть хорошо, и лучше переделать чем поддерживать то что уже написано.
Спасибо.
Здравствуйте, 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 уже имеется у подавляющего большинства пользователей.
Если хочешь выскажи эти агрументы здесь и форумчане их обсудят.
по сравнению с html — нет
