phpOpenBiz - enterprise-ready PHP framework

> Двойное BSD/GPL лицензирование.

Зачёт.

> phpOpenBiz
> php

Ненужно.

Мда. Велосипеееееды...

Вот скажите, зачем в PHP тащить какой-то язык шаблонов, когда в распоряжении разработчика есть такой язык шаблонов, как сам PHP?

> SQL-like language

Кому в ORM нужен SQL-like language, если есть такой замечательный и проверенный временем SQL-like language, как сам SQL? Это, кстати, и в Hibernate относится.

> Openbiz Eclipse plugin with wizards

Ну конечно, без визардов быдлокодерам никак...

И кому в наше время Ajax и POX понадобился тяжёлый и глючный SOAP?

> Вот скажите, зачем в PHP тащить какой-то язык шаблонов, когда в распоряжении разработчика есть такой язык шаблонов, как сам PHP?

/me передумал целовать вам ручку.

Ладно уж, дайте скидку :). Что в этом замечании не так? Ну разве что надо дать недоверенному пользователю возможность писать шаблоны, а если их пишет сам разработчик, то специальный язык шаблонов - это только лишняя морока.

Отличная шутка!

Как бы это сказать, в PHP настолько низок порог вхождения, что в некоторых местах надо усложнять (0_o). И хотя при правильном подходе дела даже без применения шаблонизаторов возможно разделение данных и формы, но пусть даже в чисто воспитательных целях лучше применять, например, XML+XSLT или Smarty. Чтобы не было соблазнов.

Прошу прощения за стиль :-). Сделайте скидку - пятница же :-)

> например, XML+XSLT или Smarty

Хороший, опытный индус способен писать бизнес-логику на Smarty и потом смотреть с невинными глазами.

XSLT в печь. Делать из XML, по сути, язык программирования это издевательство.

Вот Mako это наше все.

Итак для Ынтырпрайз-рэди PHP имеем

Фреймворки:
http://phpopenbiz.org/
http://sourceforge.net/projects/p4a/

Генератор табличных отчетов:
www.codeplex.com/PHPExcel

Ъ ынтерпрайз

http://phpopenbiz.org/ob22/demoapp/bin/controller.php?view=demo.ReportView

Parse error: syntax error, unexpected T_STRING in /home/phpopenb/public_html/ob22/openbiz/bin/Expression.php(160) : eval()'d code on line 1

Parse error: syntax error, unexpected T_STRING in /home/phpopenb/public_html/ob22/openbiz/bin/Expression.php(160) : eval()'d code on line 1

:)))

/me схватился за сердце

http://phpopenbiz.org/ob22/openbiz/bin/

оу...шит!!!!

http://phpopenbiz.org/ob22/openbiz/bin/sysheader.inc

А-а-а-а-а-а!!!!!

Не, ну а че? Вполне себе Ынтерпрайс - конкурентам такое подпихивать самое оно)

Видать серьезные ребята :)

> http://phpopenbiz.org/ob22/openbiz/bin/sysheader.inc

А-а-а! Мой мозг!

Барышня всё верно говорит. Тоже никогда этого не понимал.

> Барышня всё верно говорит. Тоже никогда этого не понимал.

мешать код и шаблоны ? да и если проект изначально ориентирован на работу с ORM, то это будет намного лучше, чем чистый SQL или какие-то классы вроде sql_query("SELECT NOW();") ...

Я не против ORM. Даже за.

Но городить свои велосипедистые языки вместо того, чтобы позволять в отдельных случаях применять просто SQL - не метод.

И почему "мешать код и шаблоны"? Вы представляете себе, что такое MVC применительно к PHP?

> Но городить свои велосипедистые языки вместо того, чтобы позволять в отдельных случаях применять просто SQL - не метод.

открою секрет, все ORM позволяют писать SQL запросы вручную :)

> И почему "мешать код и шаблоны"? Вы представляете себе, что такое MVC применительно к PHP?

это фантастика :) да и MVC без ORM я себе плохо представляю, где взять модель ?

> да и MVC без ORM я себе плохо представляю, где взять модель ?

Ну, я вообще говорила про вью, а не про модель. Но если уж пошла такая пьянка, то модель может быть вообще основана на чём угодно - хоть на ООСУБД, хоть на plain text. Никто ведь не говорит, что это должна быть именно РСУБД.

> Ну, я вообще говорила про вью, а не про модель. Но если уж пошла такая пьянка, то модель может быть вообще основана на чём угодно - хоть на ООСУБД, хоть на plain text. Никто ведь не говорит, что это должна быть именно РСУБД.

да хоть кисточкой по унитазу написано :) объясни дураку, как выглядит модель с прямыми SQL запросами ...

Модель-то нормально выглядит с ORM. А вот в контроллерах, когда начинаются выборки по какому-нибудь хитрому джойну с вложенными запросами и груп бай, тут волей-неволей придётся прибегать к языку запросов.

Я так понимаю, ORM'ные недоэскюэли именно для таких случаев и предназначены? Ну так и идут они лесом. Для простых запросов используем простой API самой модели, для сложных - передаём параметры поиска в виде SQL. Все довольны, так зачем было огород городить со всякими HQL?

> Модель-то нормально выглядит с ORM. А вот в контроллерах, когда начинаются выборки по какому-нибудь хитрому джойну с вложенными запросами и груп бай, тут волей-неволей придётся прибегать к языку запросов.

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

> Я так понимаю, ORM'ные недоэскюэли именно для таких случаев и предназначены? Ну так и идут они лесом. Для простых запросов используем простой API самой модели, для сложных - передаём параметры поиска в виде SQL. Все довольны, так зачем было огород городить со всякими HQL?

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

Мадмуазель, мне снова хочется поцеловать вам ручку, но по вопросам шаблонизации мы всё равно расходимся во мнениях :-)