Как всегда сейчас набежит толпа anonymous и начнет это дело обсирать, а быдлопыХЕРры расскажут какая это рулезная штука :)

Урра! Неделя пых-пыха на ЛОРе!

Не начинайте новых проектов на PHP! (C)

> Не начинайте новых проектов на PHP! (C)

Начинайте новые проекты на onPHP! (C) Я

А не тот ли этот фрэймворк, который так прославился на ЛОРе 
своей убогостью, кривостью и дешевым пиаром? 

Нет, это другой фрэймворк, который так прославился на ЛОРе своей убогостью, кривостью и дешевым пиаром

Новость для анонимусов. Все другие комментарии просьба модераторам удалять.

А кто-то еще реально пишет на пхп?

>А кто-то еще реально пишет на пхп?

По состоянию на конец 2006-го, примерно столько же, сколько на Питоне, Перле, Руби и C# вместе взятых.

Быдлопыхпыхеры поинтересуются - а кто, собственно, назначил onPHP популярным? ;-)

По состоянию на февраль 2007 суммарный индекс популярности по версии TIOBE для Python, Perl, Ruby, C# сотавляет 15.356%, в то время как у PHP 8.847%

Подробнее можно ознакомиться вон там - http://www.tiobe.com/tpci.htm

P.S. Настоящее зло это Java. А PHP просто маленький обгадившийся котенок, по сравнению с этим Дарт 'Java' Вейдером поработившем миллионы несчастных леммингов и вручив им нелепое знамя ООП. И вся их некчемная жизь расписана UML диаргаммами. Диаграмма жизни, диаграмма размножения, диаграмма смерти. Они наверно в туалет по диаграммам ходят.

P.P.S. Обратите внимание, как много общего у слов "програММист" и "леММинг"!

P3S: Python + Ruby по всетамужерейтенгу обогнали Perl. Возрадуемсо!

Да, забыл про onPHP написать

Гавно.
Больше всего вызывает непринятие фаллической символики положенной в основу этого фреймворка. Всюду какие то '()->'. Если перефразировать первый тезис, то получается не "Гавно" а "Х%йня" какая то. Для равновесия стоит почаще писать '()+'. Тогда будет "Пи%датая Х%йня", или "Х%евый Пи%дец" или... ну, в общем, это все равно не поможет.

Про популярность onPHP

По последним исследованиям проведенным администратором форума http://onphp.org/forum/ население рунета составило 12 зарегистрированных пользователей и 13 анонимусов, что в случае возведения числа 12 в 13тую степень дает огроооомную популярность в рунете, не рунете, на планете земля, и за пределами нашей галактики. Алелуя!

Пять за бурную фантазию!

я пишу и слизать с него не буду

причина- производительность и стандартизация

>я пишу и слизать с него не буду

s/слизать/слизывать/

От об этом я и говорю. Ужас летящий на крыльях ночи.

Вот это:

OSQL::select()->from('employer')-> get('id')->get('name')->get('birth_date')-> where( Expression::between( 'birth_date', DBValue::create(1980), SQLFunction::create('now') ) )-> toString( DBFactory::getDefaultInstance()->getDialect() );

вместо:

SELECT "employer"."id", "employer"."name", "employer"."birth_date" FROM "employer" WHERE ("birth_date" BETWEEN '1980' AND now())

Вообще DSLи делают, чтобы писать короче и лаконичнее, а тут велосипед который делает все длинее и ахуитительнее. Тип скуэля не любим, бум все на PHP ваять?

А что бла-бла getDialect внутри спрятать было не судьба?

>OSQL::select()->from('employer')-> get('id')->get('name')->get('birth_date')-> where( Expression::between( 'birth_date', DBValue::create(1980), SQLFunction::create('now') ) )-> toString( DBFactory::getDefaultInstance()->getDialect() );

Django:

e = Employer.objects.get(birth_date__range=(date(1980, 1, 1), now())) print e.id, e.name, e.birth_date

lol

>причина- производительность

perl?

>и стандартизация

Стандартизация чего? Глюков?

>P.S. Настоящее зло это Java. А PHP просто маленький обгадившийся котенок, по сравнению с этим Дарт 'Java' Вейдером поработившем миллионы несчастных леммингов и вручив им нелепое знамя ООП. И вся их некчемная жизь расписана UML диаргаммами. Диаграмма жизни, диаграмма размножения, диаграмма смерти. Они наверно в туалет по диаграммам ходят.

Что плохого в java?

>P3S: Python + Ruby по всетамужерейтенгу обогнали Perl. Возрадуемсо!

Что хорошего в python? Отказался я от SQLObject-а, zope, django и нисколько не жалею. А про отсутствие типизации - ваще жопа, сам гвидо это походу понимать начинает.

Ruby? JRuby! (хотя тоже хз зачем)

>По состоянию на февраль 2007 суммарный индекс популярности по версии TIOBE для Python, Perl, Ruby, C# сотавляет 15.356%, в то время как у PHP 8.847%

Ну, у меня перед глазами просто цифры другой статистики были. Но общая тенденция всё равно налицо. _Некоторые_ на PHP всё равно пишут ;)

...

Лично для меня, в PHP привлекательны три вещи:
- Поддержка у хостеров (т.е. стороннему заказчику меньше париться).
- Простота развёртывания проекта (скопировал на хостинг - запустил. Не для меня, а для иных юзеров моих проектов)
- И, смешно, но - очень удобная организация документации на php.net. Пишу в браузере php.net/file и через пару кликов вижу все тонкости (многое - в виде комментариев) работы, скажем, с нужной мне функцией file_put_contents, название которой никак не запомню.

С удовольствием бы сменил PHP на Python, но первые два пункта плотно удерживают, а третий - подслащивает :)

php rulez!! а вот из-за таких ТУПЕЙШИХ поделок, как этот "фреймворк" на пхп начинают навешивать ярлыки типа быдлокодерства и тп. автор новости и фреймворка - ну прекрати ты засорять своим мусорным кодом интернет. тебе не ДАНО программировать.

> Простота развёртывания проекта (скопировал на хостинг - запустил.
> Не для меня, а для иных юзеров моих проектов)

Вот здесь и начинается весь геморой. То у хостера не та версия
PHP/mySQL, то не все либы нужные слинкованы. Либо меняет версию и
твой сайт перестает работать.

> php rulez!! а вот из-за таких ТУПЕЙШИХ поделок, как этот
> "фреймворк" на пхп начинают навешивать ярлыки типа быдлокодерства

Свой код в студию!!!! На PHP разумеется

>Вот здесь и начинается весь геморой. То у хостера не та версия PHP/mySQL, то не все либы нужные слинкованы. Либо меняет версию и твой сайт перестает работать.

Я пока не нарывался :) Может быть оттого, что стараюсь тестировать на разных платформах.

>Свой код в студию!!!! На PHP разумеется

Скоро свою CMS положу на публичный SVN :) Критика будет очень необходима.

>> Свой код в студию!!!! На PHP разумеется

> Скоро свою CMS положу на публичный SVN :) Критика будет очень
> необходима.

О нет!!!! Еще один велосипедописатель!


P.S.
Каждый программист должен написать:
HelloWorld
calculator
text editor
а теперь еще CMS :^)

Korwin, когда ты напишешь CMS, которая легко подходит под любую задачу, я договорюсь, чтобы тебе выделили местечко в кремлевской стене ;)

> Korwin, когда ты напишешь CMS, которая легко подходит под любую
> задачу, я договорюсь, чтобы тебе выделили местечко в кремлевской
> стене ;)

Да ну?! Серьезно? Ты это того, точно уверен, что **нужна** CMS которая
подходит под любую задачу?
Понимаешь, понятия "легко" и "любая задача" несколько противоречат. Тут
нужен компромис, а лучше решение заточенное под определенную задачу.

Универсальность хороша, но только в определенных пределах.

Если универсальной CMS не бывает (и это совершенно верно), почему же ты называешь тех, кто пишет свою CMS "изобретателями велосипедов"?

Потому что, в 90% случаев она не нужна - есть аналоги покрывающие нужный функционал + возможность дописать недостающий.

Только эти 90% случаев покрываются не одной CMS, а десятком, причем зачастую криво написанных и с большим трудом расширяемых.

> олько эти 90% случаев покрываются не одной CMS, а десятком, причем > зачастую криво написанных и с большим трудом расширяемых.

Весьма спорное утверждение. Сколько раз наблюдал новые проекты под которые писались новые CMS и убедительно так доказывалась необходимость этого и отсутствие подходящей CMS. В итоге, практически все проекты получались дороже задуманного. Экономии не происходило и чем дольше проект живет, тем дороже обходится заказчкику.

Другое дело использование не готовых CMS, а "оболочек" + знания часто достаточны для построения любой узко-заточенной CMS в малые сроки. Под оболочкой имею ввиду набор решений для хранения, выборки, индексации любых типов документов, а также шаблоны дизайна.

>О нет!!!! Еще один велосипедописатель!

Почему "ещё один"? Системе в нынешнем виде около четырёх лет, а корни её идут ещё 1999-й год. В то время я что-то не помню массовых доступных CMS. Собственно, потому писать и пришлось.

Да и сегодня у целой массы CMS нет многих возможностей, без которых нормальную систему себе не представляю. Скажем, навигации на О-графа, модулей, не требующих модификации кода при установке, автоматической загрузки иллюстраций в текст, нормальной шаблонной системы, высокой скорости работы этого всего зоопарка.

>Сколько раз наблюдал новые проекты под которые писались новые CMS и убедительно так доказывалась необходимость этого и отсутствие подходящей CMS.

Тогда это явно не мой случай, так как CMS писалась под проект, которому уже десять лет в этом году будет, а прикручивалась потом к другим проектам уже как готовый продукт :D

Забавное API :)
OSQL::select
OSQL::update
OSQL::update

Правильно ли я понимаю, что для описания синтаксиса Informix
придется сделать (по аналогии с существующими) следующие классы:

OSQL::AllocateQuery
OSQL::AlterQuery
OSQL::BeginQuery 
OSQL::CloseQuery
OSQL::CommitQuery 
OSQL::ConnectQuery
OSQL::CreateQuery
OSQL::DeclareQuery
OSQL::DeleteQuery
OSQL::DropQuery
OSQL::ExecuteQuery
OSQL::FetchQuery
OSQL::FlushQuery
OSQL::FreeQuery
OSQL::GetQuery
OSQL::GrantQuery
OSQL::InsertQuery
OSQL::LoadQuery
OSQL::LockQueryE 
OSQL::OpenQuery
OSQL::PrepareQuery
OSQL::RenameQuery
OSQL::RevokeQuery
OSQL::SelectQuery
OSQL::SetQuery
OSQL::UnloadQuery
OSQL::UnlockQuery 
OSQL::UpdateQuery

и плюс еще несколько десятков (или сотен?) разнообразнейших
врапперов для функций.

Если да, то где тут кроссдиалектность?

Нет, это праздник какой-то! Так ничего и не поменялось.

Поскольку ссылки на ЛОРе не читают, придется копировать ответы из прошлых обсуждений.

return $query-> set('id', $message->getId())-> set('name', $message->getName()) -> set('content', $message->getContent())-> set('forum_id', $message->getForumId())-> set('person_id', $message->getPerson()->getId())-> set('parent_id', $message->getParentId())-> set('thread_id', $message->getThreadId())-> set('created', $message->getCreated()->toString());

Это, безусловно, ОЧЕНЬ повышает читаемость программы.

Непонятно, зачем надо было городить классы SelectQuery; InsertQuery; UpdateQuery; DeleteQuery; Какой смысл __динамически__ конструировать запрос порсредством методов а-ля from() -> orderBy() -> desc ... groupBy ... limit

Вы, простите, хотите сделать АРХИпереносимый API? Поздравляю, но какой ценой? Каково быстродействие полученного кода? Какова читаемость? Сложность поддержки?

При всем перечисленном есть сомнения на счет того, что любой SQL запрос можно описать перечисленными классами. Я не увидел (может, не там смотрел?) функций манипуляции с датами/временем и прочими database-specific вещами.

Извините, Вы и для MySQL будете делать fake-таблицу DUAL, чтобы все работало единообразно с Oracle?

Зачем надо было делать все НАСТОЛЬКО сложно? Вы хотели поразить публику ООП стилем?

P.S. Непонятна направленность этого ПО: для сложных высокопосещаемых проектов все будет работать слишком медленно с пожиранием огромного количества ресурсов (да-да, я про тот проект, который писали в офисе на Дровяном переулке).

В то же время, для простых наколенных сайтов такое решение не подходит из-за слишком высокой сложности разработки.

return $query-> set('id', $message->getId())-> set('name', $message->getName()) -> set('content', $message->getContent())-> set('forum_id', $message->getForumId())-> set('person_id', $message->getPerson()->getId())-> set('parent_id', $message->getParentId())-> set('thread_id', $message->getThreadId())-> set('created', $message->getCreated()->toString());

я после таких конструкций снимаю все обвинения в адрес автора.. спасибо ему за мою долгую жизнь, после такого безудержного смеха :))))))

это просто мегаклоунада :)

Вот, кстати, за что мне не нравится (заочно) Ruby. Потому что его стиль программирования поощряет такие конструкции :D По крайней мере все защитники Руби на форуме, приводят нечто подобное как пример высокого удобства языка :)

>это просто мегаклоунада :)

Это обычный бинд параметров? Если так что ту такого?

у пехепешников что ни новая библиотека - то новый ужЫс :) лучше бы попробовали ORM на пхп сделать, примерно как в Hibernate :)

Если бы вы почитали исходники, то поняли, что многое взято именно оттуда. А переложить hibernate полностью на php невозможно, да и бессмысленно.

По-поводу ORM вообще, однозначного мнения зло это или добро к сожалению нет :-(