Подскажите фреймворк наподобие Django, но для PHP

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

А в Django что, модель только одна? (Без подколок, я про этот фреймворк ничего не знаю).

> А в Django что, модель только одна? (Без подколок, я про этот фреймворк ничего не знаю).

В Django модель - это такой класс, который "is the single, definitive
source of data about your data. It contains the essential fields and
behaviors of the data you’re storing." (не могу нормально перевести это
на русский).

Например есть такой класс:
class Person(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)

Django, посмотрев на него, создает таблицу в базе данных, в которой он
будет хранить данные для объектов класса Person, и генерит формы в
админке, что бы можно было заполнить эту таблицу.

А, всё, понял. Т.е. имеется в виду, что в проекте - масса админок, по каждой модели.

...

У меня такая фигня скоро будет, давно назрела. Только не придумал ещё формат описания полей модели. Да и тормозит процесс то, что админка на любую модель пишется за 5 минут во view. Например... (следующим постингом, чтобы не мучить форматирование)

{form class="aviaport_admin_events_event" id=$this->id() action="this"}
<table class="btab w100p">

<tr><th>Алиас<br />(разрешается использовать символы:<br />A-Z, a-z, 0-1, подчеркивание)</th>
    <td>{input name="alias" maxlength="255"}</td></tr>

<tr><th>Название</th>
    <td>{textarea name="title" cols="50" rows="2"}</td></tr>

<tr><th>Дата начала</th>
    <td>{input_date name="begin_date"}</td></tr>

...

</table>

{if $this->linked_children()}
<div class="box">
Объекты, привязанные к событию:
<ul>
{foreach from=$this->linked_children() item=x}
<li>{$x->class_type()} {$x->titled_url()} [{$x->titled_admin_url('admin')}]</li>
{/foreach}
</ul>
</div>
{/if}

{submit value="Отправить"}
{go value=$this->admin_url()}
{/form}

Класс для такой админки выглядит так:

<?php

class aviaport_admin_events_edit extends aviaport_admin_events_event
{
    function can_be_empty() { return !$this->id(); }

    function class_file() { return __FILE__; }
    function config_class() { return 'aviaport_admin_events_config'; }
    function title() { return $this->id() ? ec('Редактор') : ec('Новое событие'); }
    function extends_class() { return 'aviaport_event'; }
}

Symfony. Ещё в нём офигенно удобно делать деплоймент.

А что это вы такое интересное пишите, если не секрет?

simphony, cakephp - оба могут генерить админки.

Вот в этом треде немножко есть про cakephp: http://www.linux.org.ru/view-message.jsp?msgid=2573163&lastmod=1205408473397

> А, всё, понял. Т.е. имеется в виду, что в проекте - масса админок, по каждой модели.

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

>А что это вы такое интересное пишите, если не секрет?

Фреймворк, который функциклирует на ряде сайтов. Для широкой публики не предназначен, т.к. нет документации пока вообще и много старого мусора. Фактически, глобальный рефакторинг начался лишь недели три назад, до этого - лет пять постоянных извратов. Когда вычищу - постараюсь доку обеспечить. Будет всё под GPL. Сейчас в сыром виде можно на http://hg.balancer.ru/ поглядеть.

>Нет, админка как раз одна на все таблицы.

Тогда они, выходит, должны быть жёстко прописаны в системе? У меня каждый класс активируется своим расположением в системе каталогов, прописывается только имя класса, соответствующее определённым регекспам URI. Многие классы вообще не имеют фиксированной привязки, грузятся в коде других классов. Что-нибудь, типа

object_load('airbase_image', $this->id())->thumbnail('200x150')->html_code();

Так что для написания универсальной админки придётся тупо сканировать каталоги и файлы... :)

А вот автоматическая админка конкретного класса вполне возможна. Как только, как уже писал, придумаю удобный механизм описания полей класса... Особенно, если эти поля - это индексы отдельных списков и т.п... В общем, пока получается быстрее писать админку вручную каждый раз :) По строчке-другой на параметр - немного.

> Тогда они, выходит, должны быть жёстко прописаны в системе?

Я не совсем понимаю как это - жёстко. Вообще в двух словах это выглядит так. В отдельном файле описывается несколько классов-наследником от django.db.models.Model. Каждый класс - таблица, каждое свойство - поле в таблице. Хотя можно определить целые методы для сложных вычислений или обработки полей. Затем запускается сервисный скрипт, который был создан автоматом при создании проекта. Этот скрипт в зависимости от настроек создаёт реальную БД. И дальше вся работа с этой БД выполняется через эти классы. Всё довольно просто. Хотя на первый взгляд наверное запутанно.

Забыл про админку :) Админка в понятии джанги - это приложение, которое находится в проекте. Это приложение вообще можно не включать. А если включил - оно доступно по определённому урлу. И из админки видны таблицы всего проекта, а не только какого-то приложения. Короче, чтобы в этом разобраться, нужно обязательно почитать джангобук, иначе сложно... :)

>Каждый класс - таблица, каждое свойство - поле в таблице.

А что на счёт нескольких таблиц на класс? Вычисляемых таблиц и полей?

>Этот скрипт в зависимости от настроек создаёт реальную БД.

Т.е. Django работает только с базами своего формата? Привязаться к чужой базе и конвертировать при запросах и сохранениях, скажем, DATETIME в UNIXTIMESTAMP и обратно там нельзя?

>Забыл про админку :) Админка в понятии джанги - это приложение, которое находится в проекте.

Ну, в этом смысле - оно как и у меня. Все компоненты системы иделогически равнозначны. Изначально она вообще была микроядерной, и нынешний объектный механизм был лишь одним из возможных базовых механизмов (ещё были необъектные хэндлеры, плагины и т.п.). Просто механизм оказался настолько удачным, что его поддержку перенёс в ядро, а всё остальное понемногу сношу и переписываю :)

Идеология такова, что одна таблица - один класс. Насчёт построения приложения вокруг чужой БД - я с этим не сталкивался. Верней, у меня была возможность допилить базу до нужного вида. В этом случае лучшее решение - RoR. Там, насколько я помню, модель создаётся автоматом вокруг БД, а не наоборот, как в джанге.

В django можно и на основе существующей таблицы - python manage.py inspectdb

http://www.djangobook.com/en/1.0/chapter16/

>Идеология такова, что одна таблица - один класс.

Понятно. Значит, правильно, что я не стал связываться в своё время с Django :) У меня в двух из четырёх коммерческих проектов приходится подстраиваться под имеющуюся инфраструктуру. А там - один объект имеет нередко поля в разных базах. А уж перекрёстных привязок... Так что мой ORM умеет джойнить разные таблицы по разным ID и выдёргивать классы и массивы классов одним запросом.

О, спасибо, может когда-нибудь пригодится :)

Если я правильно понял доку по django то и собирать объект разных источников - есть объект Manager, который можно изменить для конкретной модели и выполнять нужный sql для получения объекта.

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

P.S. вроде описание того как сделать объединение объекта из различных таблиц видел в рельсах, правда особо это не смотрел - рельсы мне по производительности не очень подошли

Еще создать свое поле для Model и в нем уже определять всю логику для связки данных