[room] Вопрос по PHP (или I Hate PHP)

[Eugene Prokopiev]

Eugene Prokopiev пишет:
> Денис Смирнов пишет:
> 
>>On Mon, Feb 12, 2007 at 09:00:12AM +0300, Eugene Prokopiev wrote:
>>
>>
>>
>>>>Вот обижусь на все эти языки, уйду в отпуск, и начну писать себе набор
>>>>библиотек чтобы на ocaml каком писать... :)
>>
>>EP> Боюсь показаться навязчивым, но есть такая платформа - JVM ;) c жутким 
>>EP> количеством библиотек и с несколько меньшим количеством языков, среди 
>>EP> которых, помимо Java, есть и функциональные (Scala и CAL - аналог 
>>EP> хаскела без части syntax sugar, кстати и небезызвестный г-н Луговской 
>>EP> вроде как на том же поприще подвизался), и много еще какие, если же 
>>EP> того, что надо все же нет, то есть, например, ANTLR ;)
>>EP> Вот хостиг с Java - да, дороже LAMP выйдет ...
>>
>>Зря боишься :) О JVM я думаю больше всего. А твоими стараниями думаю более
>>осознанно :)
>>
>>Из последнего твоего разъяснения и вкуривания докуметации я уяснил для
>>себя что:
>>
>> - Java как язык мне очень нравится для построения платформы;
>> - Java категорически не нравится собственно для написания web-приложения.
>>   В общем-то это пофиг, потому как я не ленивый, и сделать некий простой
>>   скриптовый язык из которого генерировать код на жабе я смогу. А где
>>   нужна хоть чуть-чуть нетривиальная логика не выпендриваться, а писать
>>   на жабе;
>> - Генерировать самому код для JVM -- гм, а что, есть для этого
>>   более-менее удобные средства (типа тех что есть в .NET)? Да ещё и
>>   более-менее эффективные (умеющие задействовать при необходимости фишки
>>   как сановской, так и IBM'овской реализации)?
> 
> 
> http://java-source.net/open-source/bytecode-libraries

а в Java 6 есть такое - 
http://java.sun.com/javase/6/docs/api/javax/tools/package-summary.html

хотя и раньше jasper (компилятор JSP в байт-код) и ant как-то 
выкручивались, используя, как я понимаю, недокументированные классы из 
tools.jar

в некоторых случаях для динамической генерации кода удобнее AOP, см. 
AspectJ и Spring AOP

>> - То, что считается общепринятым методом разработки web-приложений на
>>   Java мне не нравится ну совсем. JVM поднимается не шустроб поэтому
>>   использовать как CGI нельзя. Остается FastCGI или встраивать в свое
>>   приложение http-сервер. Я псих, и могу пойти даже на второе, хотя
>>   предпочел бы FastCGI. Как я понимаю писать мне его поддержку придется
>>   самостоятельно.
> 
> 
> http://docs.codehaus.org/display/JETTY/Embedding+Jetty
> 
> Я не пойму, чего ты так цепляешься за FastCGI. Чем это принципиально 
> отличается от HttpServlet.do*? Сделай поверх сервлетов любое API, 
> которое тебе будет удобно, в FastCGI ты же ведь тоже наверное не в 
> терминах ввода/вывода символов работаешь ...

Кстати, встраивание http-сервера в приложение - не такая глупая мысль, 
как поначалу кажется. Многие проекты это практикуют, правда я не могу 
вспомнить ни одного, кто бы использовал свой наколенный http-сервер. В 
большинстве случаев встраивают Jetty, и я не могу придумать причины для 
написания своего http-сервера вместо него. С учетом использования NIO 
его конкурентом в плане производительности должен быть скорее nginx, 
нежели apache, хотя задачи выжать из него максимум пока у меня не было.

Я встраивал Jetty, правда не прямо в свой Java-код, а в контекст 
Спринга. И наблюдаю интересную тенденцию: многие проекты уже используют 
Spring/XBean или Hivemind в качестве механизма конфигурирования 
отказываясь от изобретения собственных велосипедов. Меня, как 
пользователя Spring, это очень радует. Логика работы контекста и 
синтаксис его описания в Spring разделены, т.е. xml - только один из 
возможных способов его описания. Еще поддерживается никем вроде не 
используемый формат properties, а одни веселые ребята сделали реализацию 
Ruby-подобного синтаксиса - 
http://svn.trampolinesystems.com/springy/trunk/README

Сейчас для одного совсем маленького web-проекта я использую DWR, там 
работа ведется не в терминах http-запросов, а скорее в терминах RPC. GUI 
на HTML (еще лучше здесь будет смотреться XUL), клиентская логика на 
JavaScript, серверная - Java (точнее контекст Spring со встроенными в 
него бинами Jetty, DWR, самого Spring и моими). Собственно DWR нужен, 
чтобы из JavaScript дергать Java-код (бины, размещенные в контексте 
Spring) и наоборот. Не факт, что тебе это подойдет, но посмотри.

-- 
С уважением, Прокопьев Евгений