хочется немного обсудить yii

  • Автор темы Автор темы grigori
  • Дата начала Дата начала
grigori
ну может ты тогда объяснишь сакральный и единственно верный способ как собрать 3 разных view в 1 в зависимости от разных условий, или ты так и будешь на новичков гнать?или раскроешь особый способ работы с шаблонами?или то что даже в примерах Yii в view вызываются методы renderPartial() это тоже неверный способ работы с шаблонами да?
 
Lirik к сожалению, я не понимаю реальную задачу
задач вроде "собрать 3 разных view в 1 в зависимости от разных условий" не бывает
 
grigori
посмотри demo blog в Yii, там есть такое, значит такие задачи бывают.
 
Lirik - как раз хочу отметить, что никто на тебя не гонит, попробуй объяснить задачу конкретнее...

или то что даже в примерах Yii в view вызываются методы renderPartial()

Такой вызов не обрабатывает layout, вот и вся разница...

grigori Я правильно понял, что виджет - это своеобразный миниконтроллер, который автоматом вызывается из view? Сейчас буду тестить =) Просто я думал Widget - это только с Zii все связанное, поэтому и пропустил...
 
Иван Redjik Матвеев, 1. да
2. наоборот, Zii по большей части построен на виджетах

у yii куча интересных решений, но доки по ним нет и надо смотреть исходники



Lirik, мне наплевать на твою задачу, не хочешь объяснять так, как удобно мне - пиши как хочешь
 
у yii куча интересных решений, но доки по ним нет и надо смотреть исходники

По крайней мере по классам дока хороша + там ссылка на исходник есть, перенастраивал форму логина, нужно было через email сделать, а в CformLogin в конструкторе только поля username, password..., узнал об этом за 5 минут... сначала методы класса просмотрел, потом по ссылке тут же исходник глянул - все встало на места...

Defenitive Guide - я не рассматриваю как доку, хотя там много полезной инфы.
 
я имею ввиду то, что касается фронт-энда - например, такие штуки, как CHTML::linkButton c опцией confirm, CListView/CACtiveDataProvider/CPagination, CClientScript, CAssetManager
 
разобраться-то несложно, только в доке о них не написано
 
Нашел неприятный сюрприз... пришлось убрать из разработки ajaxLink и ajaxSubmit, довольно много постов на офф форуме на тему множественного запуска скриптов...

Суть проблемы, при загрузке нескольких аякс запросов, колличество скриптов увеличивается в геометрической прогрессии... решения этому нет, кроме как сделать все ручками, поменял ajaxLink, на Link и прописал логику в js скрипте...
 
не понял, дай ссылку на обсуждение или репорт
 
ясно, как-то интуитивно я подобных путей избегаю - перегружаю страницу после каждой операции и пишу самостоятельный js
в yii приятное ядро и архитектура, а рюшечки для client-side сырые, часть вообще предназначена только для админки, это надо учитывать
 
Сырые и кривые в архитектуре, и этот CHtml-переросток статикой в первую очередь.
 
при умеренном использовании CHTML мне кажется разумным, я бы не смог сделать лучше
статические методы тут лучше, чем работа с объектом
 
Не знаю чем лучше. Запихнуть как тот-же компонент в локатор сервисов, и будет счастие. Проблема в том, что он толстый, там сидит куча функционала, который используется виджетами, например CActiveForm и что бы банально этот функионал расширить - приходится переписывать по 2-3 метода из Chtml, ибо они там все в цепочку.
 
интересно, расскажи, для чего пришлось расширять CActiveForm
 
Самое неприятное впечатление осталось от попытки обернуть ошибку в еще один див, ибо так нужно по дизайну, который нужно, ясно дело, скрывать и отображать вместе с основным. В последнем проекте решил это костылем на JS на afterValidateAttribute... до этого пытался оборачивать внутри error. Если сам делал бы такое изначально - просто определил бы классы "чего скрывать" и "куда пихать текст ошибки", и было бы счастие.
 
та же проблема будет с QuickForms и любым другим генератором форм
решается ... грамотным тимлидом, который планирует работу над версткой после создания приложения, я так делаю
верстальщик не может быть знаком с работой генераторов форм, а то, что яйца мешают - это не проблема yii

никто не мешает писать ручками, взять ошибки из модели, как раньше,
или просто взять другой правильный шаблонизатор
 
У нас планирует интерфейс дизайнер интерфейсов, а не верстальщик или программист. А верстальщику это нужно исполнять, дивы растут не от того, что так захотелось верстальщику, а от того, что иначе не реализовать задуманное.
Ну никто не мешает написать аналог cactiveform самому с нуля, о чем я и писал.. а не, не писал, но имел ввиду, хехе. С другой стороны, CActiveForm очень мощный инструмент, особо с появлением валидации на стороне клиента... и его можно использовать очень гибко, если бы не отдельные мелочи.
 
Сверху