PHP-фреймворк

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

Я еще подожду другие комментарии.
А в чем ее преимущества? И какую ветку щас использовать: 2 или 3?

>1)Мечтательный.
>Суть в том чтобы описать модели и их связи, а фреймворк бы сам генерил таблицы и т.п.

В моём есть обратное - примитивный генератор классов из имеющейся таблицы. Т.е. лепим в pgpMyAdmin табличку нужного формата, скармливаем скрипту и получаем код ORM-класса для этой таблицы.

...

Хотя, конечно, можно сделать и генератор таблиц по какой-нить несложной структуре. А то phpMyAdmin нередко громоздко :) ... Хм. Даже, наверное, так и сделаю на днях, хорошая мысль! :)

>Увелечение скорости разработки, готовое решение рутинных задач(например, авторизцация).

Ну, конкретный механизм авторизации - это уровень уже не фреймворка, а CMS. Фреймворк должен уметь работать с любым механизмом.

> А в чем ее преимущества?

удобство и строгое OOP. PHP5 only. ORM, MVC, все дела :)

> И какую ветку щас использовать: 2 или 3?

разработчики для новых проектов рекомендуют третью.

Дурацкий вопрос - а есть какие-нибудть _стандартные_ и простые способы human-writable описания структуры БД? Ну, скажем, что-то типа такого:

news_poster:
    int     id++!
    string  target_class_name
    int     target_object_id
    int     show_begin_time!
    int     show_end_time!
    bool    is_active!
    uint    was_moderated

symfony смотрите,там так :)
или symfony-components чтоб отдельно от фреймворка

посмотреть в сторону uml?

>посмотреть в сторону uml?

Насколько я помню тамошний синтаксис, проще сразу ручками писать SQL-запросы CREATE TABLE :)

...

В общем, поскольку задача примитивная, написал пока парсер для описанного выше формата. Если кто-то найдёт простое стандартное решение - всегда можно поменять :)

А чем мой вариант не понравился?

>А чем мой вариант не понравился?

symfony? Я не помню тамошний формат, так что без комментариев пока оставил :) Погляжу потом, сделаю выводы. А так - это тот случай, когда свой кодогенератор быстрее слепить, чем чужую систему распаковать и найти что там к чему :)

15 минут ушло на написание по приведённому выше формату генератора SQL, генератора PHP-кода класса фреймворка, их тестирование и фоновую болтовню на LOR'е :)

Посмотри CakePHP. Пусть там с генерацией моделей не всё так прекрасно, но оно уж попроще и побыстрее чем симфони.

Посмотрел формат описания symphony. Слишком много букв:

JobeetJob:
  actAs: { Timestampable: ~ }
  columns:
    category_id:  { type: integer, notnull: true }
    type:         { type: string(255) }
    company:      { type: string(255), notnull: true }
    logo:         { type: string(255) }
    url:          { type: string(255) }
    position:     { type: string(255), notnull: true }
    location:     { type: string(255), notnull: true }
    description:  { type: string(4000), notnull: true }
    how_to_apply: { type: string(4000), notnull: true }
    token:        { type: string(255), notnull: true, unique: true }
    is_public:    { type: boolean, notnull: true, default: 1 }
    is_activated: { type: boolean, notnull: true, default: 0 }
    email:        { type: string(255), notnull: true }
    expires_at:   { type: timestamp, notnull: true }
  relations:
    JobeetCategory: { onDelete: CASCADE, local: category_id, foreign: id, foreignAlias: JobeetJobs } 

В этом случае проще сразу SQL нужный писать.

[quote] Насколько я помню тамошний синтаксис, проще сразу ручками писать SQL-запросы CREATE TABLE :) [/quote] что-есть, то есть :) Согласен с тем, что в заданной ситуации это ядерная бобма по воробьям.

правда есть и бонусы:

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

2). Там у тебя xml, соответственно можно генерить sql запросы xsl преобразованиями и, например, сразу приготовить функции для всяких частых селектор и инсертов, или даже заготовку класса. Хотя это скорее бонус любого xml будет. (блин было бы время можно было бы попытаться заняться)

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

Тут, как и во многих других случаях работает правило 90/10. Перекрытие 90% случаев описывается за 10% времени разработки. Оставшиеся 10% случаев требуют 90% времени разработки :)

Поскольку я никогда не гонюсь за академической чистотой, то мне обычно достаточно, чтобы мой инструмент легко и без сложностей покрывал 90% случаев. Оставшиеся 10% можно уже и ручками прописать :) В нашем контексте - собрать БД в phpMyAdmin "вручную", и описать связи объектов прямо в классе объекта.

>Там у тебя xml, соответственно можно генерить sql запросы xsl преобразованиями

Можно. Но задача стояла от human-writable формате. Что толку с мощнейшего синтаксиса, если он потребует излишних затрат времени на написание? Задача программиста системного (можно этот уровень назвать системным, полагаю) стоит в минимизации затрат времени программиста прикладного при реализации заданной задачи (даже если эти программисты - один человек в разное время ;)). Написание шаблона БД прикадным программистом в XML не способствует минимизации трудозатрат.

А что вы думаето об yii? По-моему неплохо.
Смущает только то что его изначальна разрабатовали два китайца.

akelos, как rails-клон позволяет писать в миграциях такое, например:

$this->createTable('banners', "
place_id integer,
category_name string,
description string,
imgsrc string,
alt string,
type string,
is_hidden boolean «);
}

А что вы думаето об yii? По-моему неплохо.

Отличный фреймворк. Мне понравился.

Смущает только то что его изначальна разрабатовали два китайца.

Проблем то..

>> А что вы думаето об yii? По-моему неплохо.

Отличный фреймворк. Мне понравился.

Мне тоже.

> yii

отлично, спасибо. будем смотреть.

а CodeIgniter как? Пока использую MaxCMS на его основе...

CI загнулся, имхо.
Kohana - идеальный выбор для любителей CI

да, верно, в общем-то. А у Kohana тоже ситуация непонятная... С будущим...

> А у Kohana тоже ситуация непонятная... С будущим...

ну они там щас новую ветку пилят..

кто, они? =) Если речь про 3.*, то в википедии сказано, что по сути 1 чел занят новой веткой. А качать предлагают 2,3,* и ждать предлагают 2,4,* =)

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

но новые проекты предлагают начинать на тройке.

> Придумано от балды

Сколько процентов от общего времени разработки проекта вы тратите, описывая структуры данных на SQL, и сколько планируете сэкономить за счет кастомного синтаксиса?

Бросьте это бесполезное занятие. Неважно, что вы сейчас потеряете время на разработку синтаксиса «от балды», парсера и генератора sql. Важно то, что такое решение необоснованно увеличит стоимость поддержки данного проекта, т.к. людям придется разбираться с одному вам понятными кракозябами.

>Сколько процентов от общего времени разработки проекта вы тратите, описывая структуры данных на SQL

В среднем - наверное, процентов 20 :)

и сколько планируете сэкономить за счет кастомного синтаксиса?

Ну, соответственно, раза в два - т.е. процентов 10 :)

Бросьте это бесполезное занятие

Ну, почему же. Я потратил на это «бесполезное занятие» минут 20. Окупится через месяц разработок :)

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

Учитывая, что со своим проектом я уже лет 7 вожусь в одиночку, думаю, на других людей смотреть мне смысла нет. Достаточно того, чтобы оно было удобно мне и экономично для меня :)

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

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