LINUX.ORG.RU
← Kaspersky Antivirus for free
Выпущен PHP5 Beta 1 →

уё..щный пакет. для любителей делать простые вещи через жопу

anonymous
()

Ребята, попробуйте FreeMarker (www.freemarker.org) и ваши волосы будут мягкими и шелковистыми.

Korwin ★★★
()

мне как то JSTL хватает

anonymous
()

s/MFC/MVC/g ?

Да конечно, очепяточки.. :))

Alter ★★
() автор топика

2 Korwin

Ну о вкусах... спорить не буду. :))

Alter ★★
() автор топика


Кстати, тут один перец много раз спрашивал реализацию MVC для PHP. Дык вот она: http://www.phpmvc.net/

anonymous
()

Этот перец будет здорово смеятся.. :)))

...
php.MVC is a PHP port of Jakarta Struts. It currently supports many features of Struts, including declarative application configuration via the XML digester. For example, mappings from the various Action business logic components to appropriate results pages can be specified declaratively in the XML configuration file.
...

Alter ★★
() автор топика

А гораздо проще:

<html> <!--###A --> статик контекст <!--###B --> <!--###C --> </html>

парсишь в сервлете, подставляешь согласно своему маппингу А, B и C на какой угодно код, кешишь и имеешь _реальное_ разделение html и кода. И этот html, между прочим, в отличие от вышеперечисленных 2х фреймворков - в любом web-редакторе можно _независимо_ редактировать.

Anode

anonymous
()
Ответ на: комментарий от Alter


> Этот перец будет здорово смеятся.. :)))

Скорее плакать ;)) Довод про отсутствие реализации MVC в php
был его основным коньком в защиту java-технологий применительно к вебу. Все остальные доводы были порушены еще раньше.
Хотя я подозреваю, что тот чудак не понимал до конца о чем он
говорит. Принцип MVC несложно реализовать средствами любого
языка. Не понятно о чем он спорил.

anonymous
()

>> Этот перец будет здорово смеятся.. :)))
>Скорее плакать ;)) Довод про отсутствие реализации MVC в php

От этого он еще больше смеяться будет :)
Попробуй на PHP. Именно на PHP напиши, WEB-сервер, брокер, доставщик сообщений, базу данных, XML/XSLT процессинг, аналог технологии servlet.

А теперь посмотри как все это дело сопровождать, использовать и, главное, скорость работы всего этого барахла.

Korwin ★★★
()

>его основным коньком в защиту java-технологий применительно к вебу..

AFAIR, там еще много вопросов было... :))), так что давайте будем объективны. :))

Alter ★★
() автор топика

2 anonymous (*) (2003-07-02 18:59:28.168127)

Как у человека более знающего PHP, хочу получить консультацию.

Возьмем к примеру этот форум. Я думаю вам известны его ээ... некоторые проблемы с производительностью. О чем хочу спросить - возможно ли средствами PHP написать форум который будет:

- иметь сonnection pool к RDBMS, чтобы не тратить время на подключения
- иметь cache постов, чтобы лишний раз не дергать базу на чтение?

>Хотя я подозреваю, что тот чудак не понимал до конца о чем он говорит.
>Принцип MVC несложно реализовать средствами любого языка.

Не считайте других за дураков. Говорили о содержании, а не о форме. Думаю, Korwin совершенно прав, в том что этот перец от этого еще больше смеяться будет :) Возможно :)))

Alter ★★
() автор топика

2Alter: > - иметь сonnection pool к RDBMS, чтобы не тратить время на подключения connection pool имеется, но он не общий,а для каждой БД отдельный. К примеру с PostgreSQL глючный и частенько оставляет "мертвые" соединения.

> - иметь cache постов, чтобы лишний раз не дергать базу на чтение? Есть позможность в нутри сессии сохранять промежуточные значения (что-то вроде serializable для простых типов данных) в файлах (/tmp/* обычно). Но частенько это не удобно и, опять же, бывает не подчищает их за собой.

С другой стороны, если говорить о PHP в связе с их Application server который стоит немалых денег, то там есть более развитые средства.

Korwin ★★★
()

2Alter: > - иметь сonnection pool к RDBMS, чтобы не тратить время на подключения connection pool имеется, но он не общий,а для каждой БД отдельный. К примеру с PostgreSQL глючный и частенько оставляет "мертвые" соединения.

> - иметь cache постов, чтобы лишний раз не дергать базу на чтение? Есть позможность в нутри сессии сохранять промежуточные значения (что-то вроде serializable для простых типов данных) в файлах (/tmp/* обычно). Но частенько это не удобно и, опять же, бывает не подчищает их за собой.

С другой стороны, если говорить о PHP в связе с их Application server который стоит немалых денег, то там есть более развитые средства.

Korwin ★★★
()

2 Korwin

Уппс.. О тяжелой артилерии не договаривались. :)))) Говорят, что задавая вопрос надо знать половину ответа. :)))

Мне было интересно мнение от anonymous (*) (2003-07-02 18:59:28.168127), т.к. цитирую "..Не понятно о чем он спорил...". Просто хотелось донести до человека свою скромную кочку зрения. Я не сторонник спора с фанатами и себя к таковым не отношу, надеюсь многие anonymous'ы тоже вменяемые, но почему то мне не нравятся безапелляционные заявления по теме J2EE vs PHP. :))

>connection pool имеется, но он не общий,а для каждой БД отдельный.
Поправьте меня если я ошибаюсь, это пул ведь реализован средствами интерпретатора, а не языка?


Alter ★★
() автор топика

2Alter: > - иметь сonnection pool к RDBMS, чтобы не тратить время на подключения connection pool имеется, но он не общий,а для каждой БД отдельный. К примеру с PostgreSQL глючный и частенько оставляет "мертвые" соединения.

> - иметь cache постов, чтобы лишний раз не дергать базу на чтение? Есть позможность в нутри сессии сохранять промежуточные значения (что-то вроде serializable для простых типов данных) в файлах (/tmp/* обычно). Но частенько это не удобно и, опять же, бывает не подчищает их за собой.

С другой стороны, если говорить о PHP в связе с их Application server который стоит немалых денег, то там есть более развитые средства.

Korwin ★★★
()

Прошу прощения за повторы.

>Уппс.. О тяжелой артилерии не договаривались. :)))) Говорят, что задавая вопрос надо знать половину ответа. :))) :)

>>connection pool имеется, но он не общий,а для каждой БД отдельный. >Поправьте меня если я ошибаюсь, это пул ведь реализован средствами >интерпретатора, а не языка?

Реализован средствами интерпретатора. Могу ошибаться, но вроде бы драйвером ДБ через который ведется соединение иначе не могу объяснить почему с одними БД работает нормально, а с другими нет.

>но почему то мне не нравятся безапелляционные заявления по теме >J2EE vs PHP. :)) И мне тоже. Сколько не проводил собственных тестов между Perl, PHP, Java. Ну ни как не удавалось повторить ситуацию кодга Java бы отставала или хотя бы не вырывалась в перед (на реальных задачах разумеется).

Korwin ★★★
()

>Прошу прощения за повторы.

Да ничего :)) "Хорошего человека должно быть много" (с) :))
Там вроде есть ссылки - удалить свой пост. :))

Для полной компании только Карсона и не хватает :)). Давненько что-то его не видно. :)) Разрешите еще полюбопытствовать - нет ли у вас опыта работы с JBoss? Очень интересно было бы услышать впечатления, нарекания, /etc. :))

Alter ★★
() автор топика

2Alter
Работы с JBoss нет. Все руки не дойдут, но сколько не спрашивал/интересовался основная проблема это документация. Если есть возможнось лучше купить либо найти у кого она есть в электронном виде. В остальном нареканий не слышал. К тому же SUN официально сертифицировала JBoss.

Korwin ★★★
()
Ответ на: комментарий от Korwin


> Попробуй на PHP. Именно на PHP напиши, WEB-сервер

Ага. Мы знали, что вы не знали ;) Давайте сначала RTFM, а потом
будем спорить? Чего в php нет такого, что не давало бы
возможности написать на нем веб-сервер? Нет, просто интересно послушать.

> А теперь посмотри как все это дело сопровождать

Как в анекдоте:
- А если три бутылки водки выпьешь, сможешь работать?
- Дык работаю ведь...

Собственно вопрос тот же: чего в php нет такого, что не давало
бы возможности сопровождать, и т.д. [подставьте по вкусу, чтоб
не повторяться].

anonymous
()
Ответ на: комментарий от Alter


> AFAIR, там еще много вопросов было... :))), так что давайте будем объективны. :))

Давайте... Нет проблем. На все вопросы было отвечено. Аргументы
у сторонников жабы тогда исчерпались. Можно повторить, если у
кого они остались.

anonymous
()

2last anonymous. Задолбали анонимусы. Ведь точно не головой думают. Это тебе надо RTFM и мне не надо доказывать что PHP и радом не стоит с Java, я это и без тебя знаю. Указали на то, что реально может делать Java и пропросили показать соответствующие _реализации_, а не потенциальные возможности. С чем у вас туго.

А возможностей и у ASM дофига, было бы время...

Korwin ★★★
()

>> AFAIR, там еще много вопросов было... :))), так что давайте будем
>>объективны. :))

>Давайте... Нет проблем. На все вопросы было отвечено. Аргументы
>у сторонников жабы тогда исчерпались. Можно повторить, если у
>кого они остались.

Во истину короткая память у anonymous'ов :) и только Read-only, что прошили в детстве, так и живут.

Забавные, честное слово.

Korwin ★★★
()
Ответ на: комментарий от Alter


> возможно ли средствами PHP написать форум который будет:
> - иметь сonnection pool к RDBMS, чтобы не тратить время на подключения

Да. В связке с веб-сервером, который поддерживает долгоживущие
копии php. Например, apache. Для php есть куча библиотек для
абстракции доступа к любым БД с использованием persistent
connection. Да и в самом языке есть для этого готовые конструкции: mysql_pconnect, pg_pconnect и т.д.

> - иметь cache постов, чтобы лишний раз не дергать базу на чтение?

Здесь тоже много разных способов, как это реализовать.
Для такой наколенной поделки как LOR (без обид - так оно и
есть) оптимально было бы использовать mysql, как это делают все нормальные люди. В mysql уже присутствует встроенное
кеширование запросов. И отдаются они мгновенно. Есть другой
вариант - использовать в php-программе библиотеку для
кеширования отдельных кусков и целых страниц. Таких библиотек
я на вскидку могу назвать с десяток, начиная с той, что есть
в PEAR, которая доступна из коробочной установки php.

anonymous
()
Ответ на: комментарий от Korwin


> пропросили показать соответствующие _реализации_, а не потенциальные возможности.

Говоришь задолбали анонимусы? Говоришь плохая память?
Меня не задолбали Korwin'ы, хотя память у них и вовсе никакая ;)
Я устал показывать реализации и не понимаю смысла их показа,
так как их на самом деле множество, а те, кто спрашивают,
похоже вообще не в курсе возможностей php. Потому-то я стал
спрашивать, какие из возможностей php вы конкретно не знаете.
Так проще и быстрее найти проблему в ваших головах.

Меня спрашивали про:
- database abstraction
- connections pool
- MVC
- аналог javadoc
- прозрачная работа с сессиями
- template engine
- xml/xslt
- может еще что-то забыл

На _все_ эти вопросы был дан ответ и были приведены примеры
реализаций. Вот сейчас спросили пример веб-сервера на php.
Да нате получите: http://nanoweb.si.kz/

Но этак можно до бесконечности спрашивать. Я вам не гугл.
Потому и спрашиваю, что вы такого не знаете о возможностях
php, что заставляет вас думать, что в нем чего-то нельзя
реализовать, по крайней мере применительно к веб-приложению.


anonymous
()
Ответ на: комментарий от Korwin


> Есть позможность в нутри сессии сохранять промежуточные значения (что-то вроде serializable для простых типов данных) в файлах (/tmp/* обычно).

;))) Воистину глубочайшие познания php у г-на Korwin'a...

anonymous
()

Чудненько :) как я уже говорил, мне не интересна какая-то _отдельная_ реализация. Мне, думаю и многим тоже, интересно полноценное решение для веб-сервиса. А это включает в себя:
* собственно WEB-сервер (контейнер скриптов и проч.)
* базу данных (не подключение к внешней ДБ, а полная реализация ДБ с SQL92 стандартом)
* систему шаблонов MVC (см. Velocity, MicroWEB, FreeMarker у которых возможностей не меньше чем у PHP хотя это только часть MVC)
* брокер
* load balancing
* XML/XSLT
* работу с почтовым и FTP серверами
* SSL and basic authorization
* логирование
* централизованное управление (не только WEB, а любой протокол)
* application server

Все, абсолютно все это можно и давно реализованно на Java, т.е. кроме JVM больше никаких C/C++ и прочих библиотек не требуется. Все только Java. При этом скорость и надежность впечатляют.

На PHP возможно это? При стандартной сборке PHP? Мы ведь говорим о полной реализации на PHP без использования libxml, libxslt и прочих не PHP реализаций.

Надеюсь теперь вопрос будет понятен, а также понятна разница между Java и PHP... Эти языки слишком разны чтобы противостовлять их так как ты пытаешься.

Korwin ★★★
()

> Есть позможность в нутри сессии сохранять промежуточные значения (что-то вроде serializable для простых типов данных) в файлах (/tmp/* обычно).
;))) Воистину глубочайшие познания php у г-на Korwin'a...

Обоснуй.

Korwin ★★★
()
Ответ на: комментарий от Korwin


Слушай, все можно, но зачем нужно это:
> базу данных (не подключение к внешней ДБ, а полная реализация ДБ с SQL92 стандартом)

Это что, изврат такой сейчас модный?

> load balancing

Из той же оперы. Про основополагающий принцип Unix слышал?
KISS. Каждой проге - своя задача. Зачем делать load balancing
жаба-приложения, если есть отличные внешние средства для этого?
А если кроме жабы у меня крутится еще с десяток не-жабаприложений,
которым тоже нужен load balancing?

> Все только Java. При этом скорость и надежность впечатляют.
;)) Кого и по-сравнению с чем? Некоторые впечатляются, если
им пальчик показать. Меня _не_впечатляет_ скорость работы
даже такой простенькой поделки как LOR. Что уж говорить о
чем-то крупном...

> Мы ведь говорим о полной реализации на PHP без использования libxml, libxslt и прочих не PHP реализаций.

Опа, что за бред? Это что, партия и правительство ввели такие
ограничения? ;) А топик, то бишь Jakarta Struts куда отнесем?

> Эти языки слишком разны

Никто не говорил, что они одинаковы ;) Только весь тот бред,
который тут впаривают про "невозможность" сделать что-либо на
php так бредом и остался.


anonymous
()
Ответ на: комментарий от Korwin


to Korwin (*) (2003-07-03 15:07:31.271037)

Смотри реализацию сессий в phplib. Тогда поймешь и про "простые
типы данных" и про хранение в "файлах /tmp/*" ;)

anonymous
()


Кстати, что означает "простые типы данных" на вашем жаргоне?
B какие "непростые" типы по вашему мнению нельзя сохранить в сессии php?

anonymous
()

Уфф. Последний раз расжевываю.

Все можно и на ASM и BASIC написать, но результат/время разработки будут устрашающими.

Слушай, все можно, но зачем нужно это:
>> базу данных (не подключение к внешней ДБ, а полная реализация ДБ с
>>SQL92 стандартом)
>Это что, изврат такой сейчас модный?
см. ниже.

>> load balancing
>Из той же оперы. Про основополагающий принцип Unix слышал?
load balancing для разных приложений/протоколов слишком отличается чтобы его делать унивесальным - раз. Во вторых см. ниже.

>> Все только Java. При этом скорость и надежность впечатляют.
>;)) Кого и по-сравнению с чем? Некоторые впечатляются, если
В сравнении с PHP. Ведь о нем говорим?
С другой стороны реальны случаи когда Java ВЕБ-приложение работает существенно быстрее C/C++, но это, скорее особенности используемых подходов и протоколов.
Посмотри скорость XML парсинга на Java и на PHP не говоря уже о XSLT. Даже если бросить тормознутый PHP и подключить C сторонную библиотеку, то скорость при обработке большого количества документов у PHP сильно меньше чем у Java.


>> Мы ведь говорим о полной реализации на PHP без использования libxml,
> libxslt и прочих не PHP реализаций.
>Опа, что за бред? Это что, партия и правительство ввели такие
Это не бред, а часто необходимость. См. ниже.

>Никто не говорил, что они одинаковы ;) Только весь тот бред,
>который тут впаривают про "невозможность" сделать что-либо на
>php так бредом и остался.
Ты с зеркалом разговариваешь? Или все из головы вылетело, что до этого было написано? ROM однако :)

=====
PHP как и Java позициируются как платформонезависимые языки. Из этого следуюет, что написанное приложение _должно_ работать там где есть виртуальная машина или интерпретатор. Но на это накладывется множество ограничений из них:
1. Очень часто не возможно в систему доставить доп. сторонние библиотеки. Вся реализация должна везтись на одном языке.

2. Библиотека может не иметь версий под другие платформы, либо работать не стабильно или несколько с другим чем ожидалось результатом (пример BlowFish для Perl под Linux и FreeBSD)

3. База данных, написанная на том же языке позволяет быть независимым от внешних БД. Это актуально для встраиваемых приложений, клиентских, когда имеется ограничение на работу с сокетами, либо все должно быть в одном флаконе. Так же может быть требование максимально снижать трафик между приложением и БД в случае большой удаленности или только периодичной доступности - необходимо держать встроенную БД в качестве кеширующего SQL сервера.

4. Единая среда выполнения позволяет более эффективно проводить обмен данными между частями приложения. К примеру DOM дерево от W3C _реально_ передавать между всеми существующими реализациями XML/XSLT парсинга и процессинга без потери на преобразование в каждый внутренний формат. В случае использования решений на сторонних языках каждая передача потребует преобразования в свой формат, что приведет к большой деграции в скорости.


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


Во истину с anonymous возиться пора бросать. Правы ifconfig, speer, Alter, да вот иногда подмывает :)

Korwin ★★★
()

2 anonymous (*) (2003-07-03 15:42:49.562493)

Сейчас я не спорю ради того чтобы спорить, пожалуйста, поверьте.
Мне действительно интересно ваше мнение, т.к. я мало знаю технологию PHP, хотя помню еще времена PHP/FI. Это не нападки, поверьте. :)) Мне интересно ваше, мнение, и я уважаю грамотных людей.

Давайте вернёмся к относительно простой проблеме:
возможно ли средствами PHP написать форум который будет:

- иметь сonnection pool к RDBMS, чтобы не тратить время на подключения.

Я хочу иметь нормальный, свой, управляемый мною connection pool в Контроллере, хочу отдавать его всем Action'ам или Command'am. Реально ли это?

- иметь cache постов, чтобы лишний раз не дергать базу на чтение?
Я хочу иметь нормальный вариант "своего" кэша постов в Модели. (!)

>оптимально было бы использовать mysql, как это делают все нормальные люди.

Оно может быть и так, но этот кэш увеличит производительность в 10-15 раз, если соотношение read/write (читающих форум/постящих) составит примерно 80/20. Мое IMHO, в том, что дергать Db по 100-300 одним и тем же запросом - это серьезная проблема архитектуры и низкий потолок производительности. Нормальные люди, IMHO, допускают до базы 20-30% запросов на чтение, в зависимости от реализации кэша.

Могу ли я иметь свой кэш постов в PHP?

>Есть другой вариант - использовать в php-программе библиотеку для
кеширования отдельных кусков и целых страниц.

Скажем местный Resin так и поступает, но это не избавляет от всех проблем архитектуры правда? Такие решения я не отношу с аргументам.

Хотел бы осведомиться вот еще по какому вопросу: как у PHP с отражением с CORBA? В частности интересуют управление распределенными транзакциями, что-нибуль типа аналога JTS/JTA?

P.S.
Korwin, дорогой я тебя уважаю, и мне дорого твое общесто, но пожалуйта, не повышай температуру треда - давай искать правду я не эмоции. :)))

Alter ★★
() автор топика

2Alter. Злой я сегодня 8^[] с чего-то.

--- skip ---
В связи с сегодняшним своим настроением приношу извенения если кого задел, обидел, поднял температуру в форуме и не только (остальное дописать).
--- skip ---

Смотря насколько управляемый connection pool, а так возможно. Возможно также его всем Actionam передавать.

За кеш результатов выборки ответят anonymous'ы - они лучше меня в этом разбираются.

По поводу корбы не уверен, но обходными путями можно добиться:
http://ru2.php.net/manual-lookup.php?pattern=CORBA&lang=en

Korwin ★★★
()

2 Korwin

А только хотел сказать, что если кто-то позволяет себе гнуть пальцы, то это его проблема, а нам IMHO, такие выходки не сильно к лицу :))). Прости и ты меня.

>За кеш результатов выборки ответят anonymous'ы

Аnonymous'ы по __теме__ отвечать сегодня будут?

Alter ★★
() автор топика
Ответ на: комментарий от Alter


> Я хочу иметь нормальный, свой, управляемый мною connection pool в Контроллере, хочу отдавать его всем Action'ам или Command'am. Реально ли это?

Брр. Ей богу, какие только сложности не придумают себе.
Автоматические persistent connections никак не подходят?
Кстати, еще раз про mysql напомню: стоимость создания коннекта
к базе mysql ничтожно мала. Она меньше тех усилий, которые
тратятся на создание и поддержание connections pool ;)

> Оно может быть и так, но этот кэш увеличит производительность в 10-15 раз, если соотношение read/write (читающих форум/постящих) составит примерно 80/20.

Если структура базы прямо сделана, то кроме самих постов, есть еще куча вспомогательной информации в других таблицах,
которые редко изменяются и отлично кешируются. Есть библиотеки на php, в которых кеширование реализовано на
любой вкус - shared memory, temp files, database storage,
on-the-fly compression.

anonymous
()

Korwin, ты наверно прав. :(((

Возможно мы зря тут распинались - человек не понимает о чем речь. :(((
>Во истину с anonymous возиться пора бросать. Правы ifconfig, speer, Alter,

Ну и Korwin, конечно!! Ну да ладно. :)))

Кстати мыльни как-нибудь, если конечно есть желание, на ifreeman AT mail.ru. "Давайте дружить домами" (с) - Москва слезам..

Alter ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Kaspersky Antivirus for free
Java
Выпущен PHP5 Beta 1 →