Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
Наконец-то, давно жду))
Есть ли какие-то особенности при обновлении с Beta и RC?
Upgrading from v1.1rc
— — CRudColumn is renamed as CButtonColumn
— CDataColumn.dataField and dataExpression are renamed as name and value, respectively
— The alias name for the primary table in an AR query is fixed to be 't'
Пришлось пересмотреть код всех контролеров, чтобы заменить алиасы главной таблицы на «t».
— — CRudColumn is renamed as CButtonColumn
— CDataColumn.dataField and dataExpression are renamed as name and value, respectively
— The alias name for the primary table in an AR query is fixed to be 't'
Пришлось пересмотреть код всех контролеров, чтобы заменить алиасы главной таблицы на «t».
очень нужна табличка сравнения возможностей популярных фрейм-ворков с Yii таких как: CodeIgniter, Kohana, Zend, Symphony и другими
поддерживаю!
Табличкой тут не обойтись. Задавайте вопросы, попробуем ответить.
Возьмем к примеру такую задачу:
— курсы валют обновляются раз в 3 часа
— страница обновляется, если ее кто-то отредактировал
— страницу можно комментировать, достаточно интенсивно иногда бывает
— есть блок голосование (данные меняются если кто-то проголосовал)
— есть блок новые страницы — обновляется если появится хотя бы одна страница новая
нужно минимум запросов, максимально быстрая работа, и удобное и эффективное кеширование
— курсы валют обновляются раз в 3 часа
— страница обновляется, если ее кто-то отредактировал
— страницу можно комментировать, достаточно интенсивно иногда бывает
— есть блок голосование (данные меняются если кто-то проголосовал)
— есть блок новые страницы — обновляется если появится хотя бы одна страница новая
нужно минимум запросов, максимально быстрая работа, и удобное и эффективное кеширование
Что Yii даст в этом плане:
— Хорошая реализация кеша: кеширование данных, блоков и т.д.
— Поддержка событий (подойдёт для очистки кеша).
— Поддержка консоли. На крон поставить раз в три часа.
— Хорошая реализация кеша: кеширование данных, блоков и т.д.
— Поддержка событий (подойдёт для очистки кеша).
— Поддержка консоли. На крон поставить раз в три часа.
урааа, с этого, пожалуй, и начну изучение php фреймворков.
Дождались!
Теперь бы как наиболее безсолезненно с 1.0.11 на 1.1.0 перейти :)
Теперь бы как наиболее безсолезненно с 1.0.11 на 1.1.0 перейти :)
Мелочь, но если вы имеете отношение к сайту yiiframework.ru, то можно в футере заменить 2008-2009 на 2008-2010 )))
С наступившим!
С наступившим!
Замечательно! Нет повода не выпить!
Построитель форм, это конечно супер (как и другие нововведения, в Yii 1.1, впечатляет, Yii прямо поднимается в глазах, стоит только пожелать разработчикам дальнейшего активного развития Yii), но:
Вот почему бы не совместить массив, описывающий настройки, необходимые для CForm с моделью? Не понимаю, почему так не делают в большинстве этих ваших фреймворков? Неужели это не интуитивное и логичное архитектурное решение?
(Типа пофлеймим об архитектуре MVC-подобных фреймворков?)
Вот почему бы не совместить массив, описывающий настройки, необходимые для CForm с моделью? Не понимаю, почему так не делают в большинстве этих ваших фреймворков? Неужели это не интуитивное и логичное архитектурное решение?
(Типа пофлеймим об архитектуре MVC-подобных фреймворков?)
Совместить в какую сторону? Всё слить в конфиг или всё запихать в модель?
На самом деле есть причина и она описана в руководстве Yii. Дело в том, что конфиг формы — это штука презентационная, а модель формы — это у нас логика. Вот чтобы их не мешать, чтобы можно было при необходимости одно подменить другим, они разделены.
На самом деле есть причина и она описана в руководстве Yii. Дело в том, что конфиг формы — это штука презентационная, а модель формы — это у нас логика. Вот чтобы их не мешать, чтобы можно было при необходимости одно подменить другим, они разделены.
Все запихать в одну сущность. которая и будет моделью, только расширенной.
Иначе ведь (при таком состоянии вещей, как сейчас) получается дублирование описаний только ради какого-то сомнительного в этом конкретном случае! разделения логики и вида, объясню:
Я считаю, что модель и структура(!) формы (и туда же можно валидацию) настолько связаны логически между собой, что разнесение их в отдельные сущности является избыточным и не всегда оправданным шагом. Тут же естественно встает вопрос о том, что отношение модель-форма может быть к примеру один ко многим, но с этой проблемой вполне успешно помогают справиться принципы наследования и полиморфизма в ООП. И при этом из логики все так же может быть вынесена презентационная составляющая, к примеру в виде шаблонов типовых элементов форм, что имхо является более правильным.
А какие-то более нестандартные варианты интерфейсов можно реализовать либо с помощью механизма декораторов, либо работая напрямую с библиотекой форм, не привязывая ее к модели (т. е. делаем кастомную форму и пишем ручками логику ее обработки, где мы собственно и будем дергать нашу модель)
Вот какбы такой подход.
Мысли?
Иначе ведь (при таком состоянии вещей, как сейчас) получается дублирование описаний только ради какого-то сомнительного в этом конкретном случае! разделения логики и вида, объясню:
Я считаю, что модель и структура(!) формы (и туда же можно валидацию) настолько связаны логически между собой, что разнесение их в отдельные сущности является избыточным и не всегда оправданным шагом. Тут же естественно встает вопрос о том, что отношение модель-форма может быть к примеру один ко многим, но с этой проблемой вполне успешно помогают справиться принципы наследования и полиморфизма в ООП. И при этом из логики все так же может быть вынесена презентационная составляющая, к примеру в виде шаблонов типовых элементов форм, что имхо является более правильным.
А какие-то более нестандартные варианты интерфейсов можно реализовать либо с помощью механизма декораторов, либо работая напрямую с библиотекой форм, не привязывая ее к модели (т. е. делаем кастомную форму и пишем ручками логику ее обработки, где мы собственно и будем дергать нашу модель)
Вот какбы такой подход.
Мысли?
Ну и естественно, модели вовсе не обязаны содержать расширенную информацию о формах, т. е. если пациент делает какую-то не подлежащую осмыслению в категориях такой архитектуры магию, мы возвращаемся к старой структуре приложения, где есть отдельно модели, отдельно формы и отдельно логика, связывающая их.
Каждая форма может включать несколько вложенных форм и использовать несколько моделей. При этом модели эти могут использоваться и отдельно от составной формы в более простых формах.
Например, при регистрации нам предлагается заполнить профиль и основные данные. Используется составная форма и модели LoginForm и ProfileForm. Поля профиля при этом можно заполнить и позже. После регистрации заполнять основные данные уже не нужно т.к. они обязательны, а вот профиль нам понадобится. При этом оформление формы у нас будет немного другим так как профиль надо вписать в другую по дизайну страничку.
Например, при регистрации нам предлагается заполнить профиль и основные данные. Используется составная форма и модели LoginForm и ProfileForm. Поля профиля при этом можно заполнить и позже. После регистрации заполнять основные данные уже не нужно т.к. они обязательны, а вот профиль нам понадобится. При этом оформление формы у нас будет немного другим так как профиль надо вписать в другую по дизайну страничку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Yii 1.1.0