>>...я определённо ценю и уважаю превосходные решения сложных проблем... ..PHP..

-------------------------------------------------------------------------
SP: Думаете ли вы, что крупные корпорации будут использовать PHP в своих внутренних средах вместо J2EE и .NET в будущем?

RL: Некоторые используют, поэтому "да".
------------------------------------------------------------------------

Задолбали уже альтернативщики своими пионЭрскими язычками.
Щас, все сядут на PHP! Если phpclub не знает что такое сохранение состояния компонента, стандартные шаблоны классов, сервис передачи сообщений и т.п., то это прооблема пионЭров из пыхыпы-клуба, не обремененных нормальными зарплатами.

anonymous (*) (2002-10-30 17:34:10.869) Из того что PHP не подходит для крупных компаний не следует: Что при любом упоминание о PHP в одном предложении с J2EE и .NET, сразу об этом кричать. Человек сказал, что если сейчас кто-то использует, то в будущем тоже найдеться кто-то кто будет использовать и ни слова о том что ему там место. Как говориться какой вопрос такой и ответ. Учитывая то что ставить на одну полку уже давно работающую и проверенную J2EE и только что появившийся .NET тоже не коректно, так как использовать для посторение таких систем не проверенную технология глупо

Не обращай внимания на этих любителей покричать... Так как это бесполезно. Они выучили один язык и кричат что он самый крутой на свете... Каждый выбирает то, что ему удобно и что лучше для конкретной задачи.

>Задолбали уже альтернативщики своими пионЭрскими язычками.

Оооо, какой крутой мэн.

Сам-то уж наверно не один язык написал, уж никак не меьше
чем Java.

... Реально GPL не нужна ...

Щас ему ввалят, чтоб не наезжал на истинную религию.

Щас тебе ввалят чтобы попусту не трындел

А тем временем Yahoo переходит на PHP http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm

Ну вот опять экспионер проснулся и процитировал фичи из любимого учебника :)

Ну не юзаю я php совсем (обхожусь perl + c), ну и что - сделали люди полезный инструмент, кому то он нравиться - ну и пусть.. Обязательно надо кому то прийти и все отменить 8)
Нихрена не выйдет - люди любят пхп и учебниками их не запугать ;)
Навороты сами по себе нафиг никому не нужны - юзал вот сpp по жизни, да вот на с пересел, потому как полезные библиотеки и хорошие интерфейсы для задачи подвернулись, а классы пока без надобности. Будет выгодно - вообще fortran вспомню если к векторному суперкомпьютеру пустят и плюну на всю крутизну и ооп :)

> А тем временем Yahoo переходит на PHP

Все просто: мода на яву проходит, вот и выбираются правильные решения :)

Как я уже сказал. Все выбирают то, что им удобнее и ближе к душе. Кому-то для его задач PHP кому-то J2EE а кому-то бейсик ;) Все зависит от решаемых задач.

2Sergio (*) (2002-10-31 01:45:16.285):

>> А тем временем Yahoo переходит на PHP

> Все просто: мода на яву проходит, вот и выбираются
> правильные решения :)

Золотые слова! :-)

yahoo переходит на php с C++, то есть там совес отсталые товарищи идели.
У яхи все еще впереди, и они перейдут на java как пару лет назад на нее перешел linux.org.ru...

просто в яхе тормоза сидят...

2anonymous (*) (2002-10-31 04:12:59.765)

это на каком диалекте русского?

Ну вообще-то по той ссылке, которая ведет в домашний каталог пользователя YAHOO совсем не понятно на самом деле YAHOO переходит на PHP или это просто кто-то выпендривается. Далее, там же по ссылкам можно узнать почему люди хотели, но не выбрали Java:
• Pros
– strongly typed
– good performance (JIT), sandboxing
– works w/lots of off-the-shelf software
• But… you can’t really use Java w/o threads
• Threads support on FreeBSD is not great
Короче только по причине использования FreeBSD. Если же была бы в этой ОС нормальная поддержка JAva, то перешли бы на нее.

Также занятно почитать:
Early Adopters
• PHP for new properties
– remember.yahoo.com for Sep 11 2002
• Internal tools
– content mgmt, package repository, aclviewer
• Most Y! properties integrating slowly
– no plans to rewrite entire site
– mix PHP, Apache DSOs, yScript1 & yScript2
pages

Так что любители PHP YAHOO не довод в пользу.

Цель определяет калибр

Опрять флейм! IBM использует PHP:

http://www.eclipse.org/downloads/index.php

"Пусть расцветает тысяча цветов, пусть расцветает тысяча школ"
Хоть сам я неисправимый "джаванец" (http://javasphere.hotmail.ru)

P.S. Кстати, не сочтите за оффтопик, но позиция сайта http://phpclub.net/index.phtml?newlang=ru (Александра Смирнова(PHPClub)) за эти дни вызывает симпатии.

PHP незаменим для написания простых и очень быстрых веб приложений, его большой плюс - возможность встраивания в HTML код. PHP занимает очень мало места на диске.

P.S. Крутым кульхацкерам с .net и прочим отстоем от мелкософта - пока ваше приложение не работает с реальным трафиком (от миллиона в сутки), вы можете играться с .net и j2ee, но потом необходимо взрослеть и использовать php/perl/c.

мне кажеться что этот Расмус - мудак. а PHP - руль!

Возможность встраивания в HTML код -- это, вообще-то, минус, причем любой технологии, позволяющей делать это. А крутым кульхакцерам, пользующимся такой возможностью, желательно руки отрывать в назидание прочим.

2 vs240:

>> вы можете играться с .net и j2ee, но потом необходимо
>> взрослеть и использовать php/perl/c.

Виктор, а Вы работаете на zSeries или x86?
Я то вообще не замечаю никакой низкой производительности на Linux for zSeries (или мои коллеги на zOS) при использовании IBM WebSphere 4.

>> .../c.

Так лучше сразу на ассемблере.;))

2anonymous:

>> встраивания в HTML код -- это, вообще-то, минус, причем любой
>> технологии, позволяющей делать это

Прочитайте про подход "MVC". Мои личные MVC-демки на
http://javasphere.hotmail.ru (пока из главы про EJB 2.0)

Возможность встраивания в HTML код - это большой плюс! Например, имеется необходимость менять каждый час картинки на странице. Спрашивается, какой смысл мне городить огород из каких-то технологий, если я могу добавить в HTML три нужные строки на PHP за 5 минут? Руки лучше отрывать тем дебилам, которые не могут писать совместимый код и делают порталы объемом 100-200 килобайт.

2 NikS:

>> Виктор, а Вы работаете на zSeries или x86?
>> Я то вообще не замечаю никакой низкой производительности
>> на Linux for zSeries (или мои коллеги на zOS) при использовании
>> IBM WebSphere 4.
Не спорю, наверняка специализированные решения хард+софт могут держать высокую производительность, но я имею в виду типичные предложения хостинговых компаний - x86(Linux,BSD)/PHP/Perl.

P.S. Кстати любопытная вещь (из личного опыта) - Unix хостинги можно приобрести без проблем, а большинство из того меньшинства, которое предлагает еще и решения microsoft, требуют объяснения, почему собственно вам нужен этот microsoft а не Unix :))

Yahoo переходит к использованию PHP http://www.compulenta.ru/2002/10/30/35082/

Знаешь, существует тысяча и один способ решить эту задачу, не прибегая к встраиванию кода в HTML и написанию порталов объемом 100-200 килобайт. И кстати, с чем совместим код на PHP? О чем ты вообще?

Я как бы в курсе, что такое MVC, tnx. Кстати, логично было бы в связи с этим отправить смотреть Struts, ну да вам, судя по всему, виднее. Если это архив j2eeex.zip, то MVC я там что-то не углядел.

http://java.sun.com/blueprints/patterns/MVC.html

Смешно смотреть на фразы типа
PHP - панацея, все кто на яве - козлы, и наоборот.
У всего есть своя ниша, а вообще встраивание HTML - очень и очень плохо для сколько нибудь серьёзных проектов где задействовано много народа. Нарушается процесс разработки.

Весь JSP - тоже полнейший бред. Сделали сильно типизируемый язык ява слабо типизируемым + возможность юзать недекларированные переменные -в общем уродство.

Прекрасно. Ну и почему у вас тогда то контроллер за просмотр отвечает, то просмотр модель дергает? Это что, так сан велит? Ваши примеры, извините уж, как раз и показывают, как _не надо_ использовать J2EE. Посмотрите хоть на struts -- это почти чистый MVC.

Вот, короче, ссылка. Там в самом начале достаточно доходчиво объясняется, что такое MVC вообше, и чем Model 2, использующая MVC отличается от технологий, имеющих такой несомненный плюс, как встраивание кода в HTML:

http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-strutsxslt.html

>> Ну и почему у вас тогда то контроллер за просмотр отвечает, >> то просмотр модель дергает?

Craig Larman, chapter 22.9. (У меня первое издание) Критика "чистого" MVC, предложение автором концепции model-view separation.

>> struts -- это почти чистый MVC

Без "почти" ;)) (Paul R.Allen J2EE, Chapter 10, там же pro- и contra- MVC ) Обратите внимание, что Allen дает "распорки" (struts) до изучения EJB.

1. Не разу не использовал struts, хотя и качнул. 2. JSP для меня обязательны.

>> так сан велит?

Нет, не Sun. Хотя WSAD помогает опционально создать Bean-adapter и (опционально опционально) сервлет и (не опционально;)) JSP. Могу выложить в понедельник.

>> встраивание HTML - очень и очень плохо для сколько нибудь серьёзных проектов

Если Вы подробно обоснуете это, то было бы интересно.

Пока же также JSP юзерские тэги стали обязательными. Sorry, пока я не выложил примеры из главы про JSP - там как написать простой tag.

PS Не знаю как живут аналитики по PHP и Jаva, но старый смоллтокер бы действительно был бы в шоке от нарушения чистоты MVC (см реализацию WWW в IBM VA ST). :-)

>> Craig Larman, chapter 22.9.

Читаем: "Согласно шаблону Model-View Separation ... объекты модели не должны напрямую взаимодействовать с объектами уровня представления... специальные классы должны инкапсулировать информацию и поведение, связанные с логикой приложения, а классы окон являтся относительно тонкими." Ну и далее описание самого шаблона. Это как раз первое издание. Правда, у вас в примерах шаблоны несколько другие используются? Это я к тому, что не надо называть MVC те вещи, которые к MVC никакого отношения не имеют.

Что касается Struts, то здесь все зависит от того, как писать. Вполне можно написать такое приложение, что вся парадигма MVC полетит к чертям, потому я и говорю, что это почти MVC.

То же касается пользовательских тегов в JSP -- это как раз возможность отделения логики представления от самого представления, хотя опять-таки, нет таких преград, которые...

>> Это я к тому, что не надо называть MVC те вещи, >> которые к MVC никакого отношения не имеют

OK, дайте, pls, практический пример. Примеры к главам 3 (сервлеты) и 4 (JSP) выложу в понедельник.

Процитируем мнение консалтинговой компании UCNY, Inc.:

"Модель: JavaBeans или EJB - бизнес-логика Представление: JSP - используется для формирования пользовательского интерфейса. Контроллер: сервлет - используется для обработки HTTP-запроса и управления ходом работы приложения."

Поль Аллен, J2EE, 2002.

>> Что касается Struts, то здесь все зависит от того, как писать.

Много проектов было спонсировано IBM. 90% из них были чисто исследовательскими. Интересны были бы примеры практического внедрения "распорок" в реальных проектах.

>> пользовательских тегов в JSP -- это как раз возможность >> отделения логики представления от самого представления,

Абсолютно согласен. Но мне очень хотелось бы знать причину Вашего недоверия к JSP, PHP & etc "технологий, имеющих такой несомненный плюс, как встраивание кода в HTML" с практической, а не теоретической точки зрения.

>> Читаем: "Согласно шаблону Model-View Separation .

Есть (Larman) еще небольшая ссылочка в правом нижнем углу курсивом... (Не могу процитировать - книга не под рукой) Весьма философский вопрос: броузер может быть контроллером?

> Весьма философский вопрос: броузер может быть контроллером?

Весьма философский ответ: не может. А в той ссылочке Ларман рассуждает о том, что вот, дескать, куда лучше говорить Model-View Separation, чет Model-View-Controller, поскольку термин контроллер "является анахронизмом".

Может прямо признаем, что не надо искать дизайн там, где его нет?

Пример был - Struts. Если нужно еще, читайте Advanced JavaServer Pages by David M. Geary, глава 5 и осбоенно 6. Что касается взаимодействия с EJB -- Programming Java Struts by Chuck Cavaness, номер главы уже не помню. Не знаю, о каких главах вы говорите, т.к. книгу вашу не читал, а опираюсь исключительно на примеры.

По поводу мнения компании UCNY Inc. Все правильно, но это не значит, что надо из просмотра дергать модель (это я, кажется, уже второй раз повторяю). Посмотрите, наконец, такие паттерны, как Session Facade, как Value Objects и подумайте, а зачем они нужны.

> Интересны были бы примеры практического внедрения "распорок" в реальных проектах

http://jakarta.apache.org/struts/resources/powered.html

Ну и конечно, довольно многие используют Struts вo внутрикорпоративных решениях. Кстати, Oracle jDeveloper последней беты уже включает средства для разработки на Struts.

> Но мне очень хотелось бы знать причину Вашего недоверия к JSP, PHP & etc "технологий, имеющих такой несомненный плюс, как встраивание кода в HTML" с практической, а не теоретической точки зрения.

Модифицировать проекты неудобно. Я предпочитаю держать мух отдельно от котлет, посему и JSP особо не пользую. XSLT просто удобнее (для меня).

>> Все правильно, но это не значит, что
>> надо из просмотра дергать модель

Согласен, хотя бы было бы неплохо выслушать аргументы против обращения модели из просмотра.

>> Посмотрите, наконец, такие паттерны, как Session Facade,
>> как Value Objects и подумайте, а зачем они нужны.

Facade пришла в техзадании, но правда как интерфейс к MQSeries.
Value Objects явно не указана. (Это я немножко про свое, мне интересен спектр мнений.)

>>Ну и конечно, довольно многие используют Struts

Спасибо за информацию, постараюсь набросать для себя несколько демо-примеров.

>> Модифицировать проекты неудобно.
>> Я предпочитаю держать мух отдельно от котлет,
>> посему и JSP особо не пользую.

WebSphere - ну что тут поделать! ;-( ;-)

>> XSLT просто удобнее (для меня).

Я предполагаю, что сейчас WebServices и XSLT будут развиваться.
Посмотрю внимательнее на следующей неделе бету WebSphere 5.

PS Кстати, в Sun WSTK пофиксины ли траблы с цепочными XSLT вызовами?

to
anonymous (*) 2002-10-30 17:34:10.869
anonymous (*) 2002-10-31 18:32:27.529
Блин, ананимус тут с форматированием - строки в километр, хуман-фриендли :-) в районе 50 символов в строке, раз сам разметку ляпаешь :-)... Блин... как накакал, читайте мол, как хотите...