Здравствуйте, 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 сакс а бинарный поток рулит. Ты говоришь что это не так. Но вот контекста спора то не обозначили. Оба формата имеют право на жизнь, только где-то живучее оказывается один, где-то второй. Это не точка зрения — это факт, и спорить с ним считаю безсмысленно. Почему бы не прекратить полемику?
, говорили о JAVA вообще.
не знал. эх пойду щас кой кого носом натыкаю.
