LINUX.ORG.RU

Выбор PHP-фреймворка


0

0

Привет, ребята! Тема уже поднималась не раз тут, но хочу спросить еще раз. Вообще в последнее время очень полюбил джангу, и писать надо на похапэ, и поэтому встал выбор подходящего фреймворка. Интересует вот что:

  • ORM, генерация SQL из моделей
  • Возможность удобно делать миграции в бд
  • Шаблонизатором не должен быть сам похапэ
  • Возможность создавать многоязычные приложения
  • Хорошая, объемная документация


Последнее исправление: cheerfulboy (всего исправлений: 1)

> Шаблонизатором не должен быть сам похапэ

Опаньки. Надо ожидать шаблонизатора, написанного на Smarty?

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

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

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

Попробуйте внятно объяснить зачем один шаблонный язык нужно компилировать в другой не менее шаблонный?

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

Потому что синтаксис у похапэ избыточен для шаблонов. Меня вот раздражают эти круглые скобки, и точка с запятой после endif, endforeach и так далее, или вообще {}. Да и фильтры будут реализоваться через функции. А еще как же наследование в шаблонах? В общем, нужен шаблонизатор.

cheerfulboy
() автор топика

http://bors.balancer.ru/

* ORM, генерация SQL из моделей


есть

* Возможность удобно делать миграции в бд


Что под этим понимается?

* Шаблонизатором не должен быть сам похапэ


Любой. Исторически по дефолту используется Smarty, реже - чистый PHP. Есть примеры использования Twig, Quicky. Вообще, любой шаблонизатор легко прикручивается к конкретным классам индивидуально.

* Возможность создавать многоязычные приложения


Заложена поддержка gettext, но пока на практике нигде не используется.

* Хорошая, объемная документация


Вот тут полный epic fail :)

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

>>* Возможность удобно делать миграции в бд

Что под этим понимается?

Думаю изменения схемы базы данных вместе с изменениями моделей. Вобщем как в rails или django-south. Примером похожего функционала на php может быть liquid-base, но он был слаб и на его основании сложно понять что такое полноценные миграции. Если посмотреть его, то возникнет вывод, что миграции не нужны, но это не так. Ещё как нужны.

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

>Думаю изменения схемы базы данных вместе с изменениями моделей

Пока такого нет. В далёких планах подумываю, но пока проще при изменениях в БД править строчку-другую в модели :)

Вобщем как в rails или django-south


Я пока только в голом Django видел. В смысле - syncdb. Но там миграции не нашёл :)

Если посмотреть его, то возникнет вывод, что миграции не нужны, но это не так. Ещё как нужны.


Неужели так сложно при изменении очередного параметра в структуре БД подправить параметр в модели? Или я чего-то не понимаю? :)

...

Да, возможно, речь ещё о раздельном обновлении БД в разных проектах, но с одной моделью. Тут уже требуется некоторая самодисциплина - при каждом изменении модели прикладывать соответствующий SQL (обычно у нас же БД - это SQL?). Но это в моей практике редко бывает.

В общем, пока время, затраченное на автоматизацию процесса, для меня себя не окупает :) И стимул подумать над этим моментом - чисто спортивный.

KRoN73 ★★★★★
()

Повторю свои мысли из прошлого треда. Если брать - то symfony 2. Фабьен мужик умный, плохого не напишет:) А если серьезно - ничего такой фреймворк, налицо тенденция «срезать к чертям все лишнее» (до этого наоборот все набирали всякие разные свистелки). С доками проблемы - их нет - но код понятный. Если опыт похапе есть, разберешься.

portalgun
()
Ответ на: комментарий от KRoN73

> Я пока только в голом Django видел. В смысле - syncdb. Но там миграции не нашёл :)

Увы, там их нету. Но есть сторонные приложения. Тот же south подменяет родной syncdb.

Неужели так сложно при изменении очередного параметра в структуре БД подправить параметр в модели? Или я чего-то не понимаю? :)

По рельсам не скажу с уверенностью, но в django работа идёт от модели. Т.е. первична модель, структура базы уже зависит от неё. К тому же может быть несколько проектов с разной версией базы, причём с возможностью двигаться в обе стороны. К тому же сами базы могут быть разные. Вероятно лучшей аналогией является система контроля версий. Тут те же профиты.

Для php пробовал только liquidbase, но эта штука «не окупает время, затраченное на автоматизацию процесса». SQL в XML и всё такое для роботов.

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

Вышеупомянутый Twig как раз сделан создателем Symfony. Вообще Symfony - один из немногих светлых лучей в PHP. Особенно 2 версия.

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

> Неужели так сложно при изменении очередного параметра в структуре БД подправить параметр в модели? Или я чего-то не понимаю? :)



миграция - это не только add/remove field.
это вполне может быть UPDATE table SET, который должен быть выполнен.

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

Всё равно не понимаю сложности. Видимо, не сталкивался с такими задачами в своей практике.

KRoN73 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.