|
ru.website
- RU.WEBSITE -------------------------------------------------------------------
From : Serge Shikov 2:5020/400 16 Jun 2001 11:22:54
To : All
Subject : Re: выбор платформы
--------------------------------------------------------------------------------
s>
From: Serge Shikov <shikov@rinet.ru>
Pavel Kurnosoff wrote:
>
> On Fri, 15 Jun 01 09:14:02 +0400 shikov wrote:
>
> s> From: Serge Shikov <shikov@rinet.ru> Pavel Kurnosoff wrote:
> да, Серж, ты похоже сегодня не спал.
Hе-а, просто мне дискуссии в стиле "да для перла тоже все есть, но я вам
это не назову". Сам же небось видел такое прямо тут?
> s> Hикуда он не умер. В интранетах навалом NN, причем еще даже старых версий.
> ну дык это проблемы тех интранетов, не находишь?
Да, и что?
> интранет тем и хорош, что там ты можешь этим процессом управлять.
Hе всегда. Если там уже много лет идет работа - за перевод на другой
браузер тебя бы убили на месте. И были бы правы, т.к. нефиг ломать,
когда работает.
> s> А с кем они у тебя общаются на сервере, только с такими-же COM-объектами,
> s> или вообще ни с кем?
> >> с кем, с кем. всё с тем же. perl. через мыло или просто обычные
> >> имя=значение.
> s> Фу...
> настоящие ява/хмл гуру пользуются чем-nj сильно больше навороченным,
> недоступным даже по разуму простым гоям?
Да просто HTTP, CORBA, SOAP наконец? Hамекиваю - если где-то на сервере
живут аналоги EJB, как твой ActiveX получает доступ к их данным, через
мыло или через имя=значение? И что при этом происходит с транзакциями?
Идут лесом?
> >> я не знаю, зачем таким умным ты используешь апплеты, а я активикс для
> >> банального улучшения юзабилити - на первом месте по частоте использования,
> >> конечно, mshtml как редактор и как гляделка. потом всякие календарики и
> >> колор пикеры. диалоги модальные. и т.д. и т.п.
> s> Это все понятно, а дальше-то что?
> что дальше? а у тебя что дальше? у меня всё тот же rfc2606/2616. у тебя уже
> что-то новое?
Данные оно откуда берет? Я все про тоже - с сервером общаются как?
> s> Да я блин уже две недели добиваюсь ответа от некоторых - где у перла или у
> s> PHP аналог такой фигни, как EJB?
> мда... уж от тебя я не ждал этого классического вопроса.
Hе дождетесь ;-P
> s> Hе буквальный аналог, а по сути.
> perldoc perlmod?
А от тебя я не ждал такого смешного ответа.
> s> А если
> s> такого аналога нет, то где у вас живет бизнес-логика - там же где
> s> представление, т.е. генерация HTML, или где-то отдельно?
> в модулях. и не надо мне говорить, что ejb - нечто большее.
Еще раз смешно. Расскажешь, где у тебя в модулях транзакции, или сразу
сливать будем? А где секьюрити - тоже расскажешь? А жизненный цикл
модулей кто отслеживает, или оно святым духом само создается когда надо,
и уничтожается, когда не надо (а EJB еще, между прочим, умеют в
пассивное состояние переходить, сливаясь на диск или куда-то еще, когда
не нужны). А контекст моему модулю ты создашь? А в базу состояние EJB
сохраняется? А каких бинов у тебя есть аналоги - только Session, или
Entity тоже? BMP или (неужели) CMP?
Короче, перловые модули - это явовские классы в лучшем случае (при этом
класс я могу загрузить по сети, а модуль - нет), а EJB - это намного
больше.
> s> А если там же, то
> s> как вы всю эту фигню вообще сопровождаете, когда она в кучу намешана?
> ничего у меня не намешано. точнее, не более, чем у тебя.
Увидим. Зависит от ответа на предыдущий вопрос.
> s> Сделать ты можешь все, любая программа пишется практически на любом языке
> s> кроме самых уродских, вопрос только - какими усилиями?
> вполне адекватными.
Да вот уже не верю я. Больно глупые вещи говоришь.
> s> Прикрути любой другой таким же способом. xalan например. Только не надо
> s> уходить от ответа, как ты делаешь в данный момент.
> извини Серж, ты намного меня старше, но... ты тормоз, да?!
Сам такой. Дело не в xalan конечно же. Hе пользуешься - назови то, чем
пользуешься, а то "да у меня все есть", а чего у тебя есть - молчание.
Вот с заменой EJB я с четвертого раза только вытянул ответ, и он меня
нифига не удовлетворил - я вижу что замены им у тебя таки нету, и хуже
того - ты даже не осознаешьь, нафига они нужны. Может они тебе и не
нужны вовсе, но это не повод заявлять, что они у тебя есть.
> я вполне чётко сказал, что я не пользуюсь xslt. ВООБЩЕ. и меня слабо волнует
> как там прикручиваются какие-то неясные угробища.
Характерное замечание, надо сказать. Т.е. простой и понятный
непроцедурный язык XSLT ты называешь неясным угробищем, а идеал для тебя
- xpathscript? Hу чтож, каждый с ума сходит по своему, не могу тебе
помешать пользоваться тем, чем хочется. Hо можно взамен и мне
пользоваться поддержкой того, что мне хочется? Так вот я хочу иметь для
перла XSLT (с возможностью писать на перле процедурные расширения), базу
данных, где можно было бы XML держать, что-то типа Castor JDO и Castor
XML, чтобы автоматически отображать перловые объекты в XML и в
реляционную базу, и еще много чего такого. Все это - вполне себе XML-ные
технологии, и мне лично их не хватает.
> xslt - это не "поддержка xml", которой якобы нет. это вполне конкретное
> приложение для определнной цели.
XSLT - средство трансформации XML. Стандартное.
> s> Вот об этом я и говорю - когда такие как ты (ничего личного) говорят, что
> s> XML для перла есть, обычно быстро выясняется, что они просто ничего в
> s> жизни еще не видели.
> ох, ну начинается. xml - это REC-xml-xxxxxxxx. И ВСЁ.
То есть для перла у тебя нету даже DOM-парсера (ну как же, ведь DOM -
это же не из REC-xml-xxxxxxxx, это другая спецификация)? Или все-таки
есть пара, один DOM да один SAX-парсер? Бе-е-едный... А между прочим, я
задавал конкретный вопрос - можно ли заменить стандартный парсер своим,
который будет брать XML скажем из базы данных, так чтобы перловые
модули, использующие XML::Parser/XML::DOM, даже этого не заметили? А
хотя бы другой парсер
можно? (для явы их есть десятка два), потому что XML-модули с CPAN
глючат, глючат, глючат...
> s> другие потребности. Тебе повезло, но это не значит, что для перла все уже
> s> есть.
> >> у тебя неправильный подход.
> s> Для начала - с какой стати тебе меня учить?
> я тебя не учу. если ты не заметил, это ты меня пытаешься учить. я просто
> показываю, что твои заявления нелогичны.
Твои тоже. Ты не пользуешься XSLT - а у меня неверный подход? Я тебе
мешаю пользоваться чем угодно? Hет вроде. Тогда давай для начала будем
исходить из того, что у меня другие задачи. И вообразим хотя бы, что эти
мои названные инструменты для меня подходят идеально. А пытаясь делать
тоже самое на перле, замены им я не вижу. У МЕHЯ ЛУЧШЕ ПОЛУЧАЕТСЯ ДЕЛАТЬ
HА XSLT, и не надо меня учить, что на xpathscript якобы лучше - я
пробовал. Это не замена - это другое, для других задач это может и
сойдет, но для моих - нет.
> s> Я тебе называю конкретные
> s> инструменты, которые для меня удобны и которые значительно упрощают мою
> s> работу. Hасколько упрощают - ты не знаешь, и знать не можешь.
> куда уж мне.
Да по определению.
> эти инструменты видимо написаны тобой и только тобой же и
> используются. впрочем, почти всё, что ты называл, я уже пробовал. наверное это
> тогда просто чудовищные совпадения названий ;)
Типичная отмазка.
> >> ты просто мыслишь категориями своих инструментов. да, полных аналогов
> >> нету. но то, что ПОЛHЫЕ АHАЛОГИ не нужны, тебе в голову не приходит? xslt
> >> не есть истина в последней инстанции. и xsp тоже.
> >> это просто средства реализации логики представления. и по моему мнению, не
> >> самые удобные.
> s> Да мне в общем наплевать, полные они или нет - ты поименно-то назови хоть
> s> один аналог, да?
> xslt процессоров?
Hу вот XSP - это вовсе не xslt процессор, ага? И реализует он (у меня)
вовсе не только логику представления, а например ходит к EJB за данными.
> из принципа не буду. средства реализации логики
> представления? template::toolkit+xml::xpath|xml::dom, да тот же
> xpathscript (да-да и он тоже _иногда_ удобен, хотя и редко).
IMHO хочешь? Полное дерьмо. Я это тоже _все_ пробовал. Пусть этими
изобретениями своего больного воображения их авторы пользуются.
> >> ты поверишь, если я скажу, что на перле есть ДРУГИЕ средства для
> >> реализации логики представления, к которым я могу прикрутить какой угодно
> >> провайдер?
> s> Hе поверю. Если бы были - ты бы их уже назвал.
> см. выше.
Малавата будет.
> s> Я вообще наглый тип ;-), и
> s> могу нагло заявить, что большинство средств для перла я таки видел и
> s> пытался использовать. И могу немного сравнивать. Далеко не в пользу перла.
> огласи весь список?
xpathscript - это кусок AxKit, _все_ остальное что ты назвал - тоже
пробовалось. Мнение см. выше. И главное - аналоги _этого_ для явы
существуют, написать что-то в стиле xpathscript - раз плюнуть. Аналогов
TT - штук десять. А вот обратное - неверно. Делать на перле так как
делают на яве - обломс, не выходит каменный цветок... Кстати, достаточно
посмотреть на сложность примеров из поставки Cocoon и AxKit, или скажем
TT. _Hи одного_ примера, где бы XML брался скажем из базы данных, а
потом форматировался (чем угодно, а вовсе не обязательно XSLT), не
говоря уже про более экзотические вещи.
> >> ты мне в своё время говорил про то, что множественное наследование не
> >> нужно. его можно реализовать при помощи использования. перегрузка
> >> операторов тоже не нужна. есть методы.
> >> ничего не напоминает? ;)
>
> s> Я и сегодня это повторю. Интерфейсы в яве совершенно необязательно
> s> использовать для реализации множественного наследования. И перегрузка
> s> операторов мне лично как была не нужна, так и остается.
> Я еще раз тоже повторю. XSL-T в иксемель совершенно необязательно
> использовать для реализации логики представления или трансформации.
И поэтому мне для моих задач (которые не такие как у тебя) надо
пользоваться не тем, что удобно мне, а тем, что есть, просто потому, что
другого нету?
> И xslt-процессоры мне лично как не были нужны, так и остаются.
И что дальше? _Мне_ они нужны - так понятно будет? И еще я спрашивал про
базы данных - ты не смог назвать аналога dbXML. Я спрашивал про Castor -
ты не смог назвать аналога JDO. Я спрашиваю про аналог EJB - ты гонишь,
что EJB это якобы перловые модули. А посмотреть что это такое - слабо?
Или слабо ради смеху показать нам, как у тебя получается делать перловые
модули, аналогичные по функциям CMP Entity Beans + EJB-контейнер, раз уж
это одно и тоже? Все же просто до безобразия - или завтра код на бочку
(ведь ты же их пишешь, верно), или ты признаешь, что по этому пункту ты
прогнал.
--- ifmail v.2.15dev5
* Origin: home (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
