Sam Dark писал(а):Да что примеры необходимы и так понятно. С обсуждением необходимости пора заканчивать и переходить к конкретным действиям — сбору заявок на примеры к классам и методам. Далее всё это дело я оформлю в тикеты и постепенно добавлю в фреймворк.
Неплохим вариантом было бы добавить кнопку "Даешь пример! " рядом с конкретным методом или классом в Api. Действует так - юзверю что то нужно -> он лезет в доки по Api -> находит нужный метод, и видит напротив него эту кнопку (если примера еще нет). Соответсвенно, он ее жмет если ему не понятно как пользоваться методом. При нажатии увеличивается счетчик заявок на конкретно этот метод.
Что получат юзвери - возможность легко, простым нажатием добавить заявку.
Что получат разработчики - увидят на что "спрос" больше, т.е. к чему пример нужно написать в первую очередь. Ну и косвенно - что более востребованно при разработке, а чем пользуются редко.
Пс. Конечно если такое вообще можно реализвать без сильных осложнений.
snowflake писал(а):Это понятно что у каждого свои потребности...
Да, Вы меня поняли Необходимо создать "минимум для новичка", а дальше пусть либо каждый сам по себе, либо в комментах будут рьяно обсуждать конкретный вопрос )))
Было бы неплохо где-нибудь создать страницу (пускай даже в форуме), где желающие скидывали ссылки близкие к теме.
Например свои блоги. http://www.dbhelp.ru/ - почти всё в блоге про yii, а в гугле по запросу на 8й строке (хотя конечно ищущий найдёт).
Более адекватный пример: поведения (behavior). В форуме есть те кто с фреймворками работал и есть вообще новички в этом деле (например я).
Первым термин вполне знаком и использование поведений не составляет труда (суть та же самая, что и в других фреймворкаХ) - о таких фундаментальных вещах в любом случае где-то уже написано (ну википедия даёт поверхностное представление). Пускай даже еслив документации другого фреймворка, если там написана теория то с ней желательно бы ознакомиться.
ПС не то чтобы я умоляю - дайте теорию по поведениям. Просто в фреймворке есть большое кол-во класов и их предназначение неизвестно.
Да, примеры это самое больное место документации фреймворка.
Желательно для каждого метода и поля хотя бы по одному примеру. В этом плане мне нравится кодекс вордпресса, там есть примеры на все случаи жизни
Лично я довольно часто даже копирую куски кода из документации а потом только подпиливаю под свои нужды.
Я даже не против по ходу написания приложения и чтения документации добавлять собственные примеры и думаю таких людей найдется много. Только надо как-то это удобно организовать... что-то типа комментариев к каждому методу и полю. Сейчас есть комментарии к классу, но это не совсем удобно и там чаще пишут вопросы а не примеры.
В документации очень не хватает примеров задания различных отношений AR, например как связать 2 таблицы посредством третей (я пока так и не понял, возможно ли это вообще сделать (viewtopic.php?f=3&t=1089 дополнительный вопрос в 3 посте))
Поговорил тут со своими учениками, проблема в примерах есть, и очень большая. Самая большая проблема "Полное руководство по yii" в том, что примеры там оторваны от реальности. Хотя бы в том, что сейчас есть Gii, и то что там генерируется совсем не описано нигде, в итоге без литра водки не разберёшься. Вчера буквально вот разбирались со студентом что к чему (благо я уже месяц ковыряюсь, более-менее разобрался) - когда разобрали, всё ему стало легко и понятно и он буквально за час сделал больше чем за приведущие 2 недели.
Насчёт реляций тоже есть большой недостаток в отсуствии обработки данных, которые собственно попадают в виде AR объектов или CActiveDataProvider во views. Ну получил ты этот массив данных - а как с ним работать остаётся только догадыватся - var_dump и print_r в помощь, да метод научного тыка. То что реляции у объектов моделей появляются как public properties нигде не упомянуто, не говоря уже о том, что это массивы объектов вытыщенных по связям. Да и само описание relations не блещет - реляцию сделали, данные в таблице есть - а при попытке вывести связанные данные большая фига. Делаешь var_dump реляции, а там Array(0).
Ещё с авторизацией весьма весело получается - там довольно запутано в доках, я сам не сразу въехал. Потом объяснял всем студентам, потому что по докам ни у кого не вышло сделать авторизацию самим. Я если честно вообще не понимаю, почему нету 2-х вариантов сразу - авторизация по файлу/массиву и по базе в стандартной поставке. Ибо наверно 99.9% именно базу и используют. Ну а для всяких OAuth и OpenId компоненты я думаю и так уже есть.
Я могу предоставить пример из реальной жизни, который мне вот первым на yii пришлось делать - по сути это админка к системе обработки транзакций операторами (можно так-же и приём сделать - он там довольно не простой) - так вот из-за недостатков документации я вместо недели мучался 4. При этом ещё и баг-репорт сгенерировал.
Общался с Sam Dark на тему доков, собираю сейчас все проблемы, которые возникали и фидбек от студентов. Как соберу - ему отправлю и посмотрим что мы можем с этим сделать. Другое дело что нужно не только нам двоим этим заниматься, но и другим людям тоже подключатся.
Что до плагинов - как я уже писал - нужно срочно принимать стандарты. К примеру плагин SRBAC. Да, он крут, но интерфейс у него хреновый. Но вкладывать в него кучу времени стоит или нет - не понятно. Автор пропадёт и модуль помрёт. Комюнити может подхватит, а может подхватит другой модуль. Не переделывать же всё потом под новый модуль.
Yii изучаю недавно, фреймворк хороший, но дока.... Приходится простые вещи ковырять очень долго и терять уйму времени , а стоило то всего написать поподробней. Про работу с аяксом я так и не нашел толковой документации, пришлось ходить по форуму к блогерам и по крупицам собирать информацию и это бесит. В общем порог в хождения в Yii высокий из-за недописанной доки.
Вот ещё задачка, одна из распространённых, но нигде не описанных и только гуглится если, и то по крупицам.
Есть сайт, часть функций за авторизацией. Как правильно организовать так, что бы при попытке доступа к функциям, требующих авторизации автоматом показывало форму для входа, при этом не нужно было бы писать всё это в контроллере каждом. А самое оно это когда можно положится в проверку прав через RBAC (как это обычно и делается).
Элементарная вещь, с которой начинается любой сайт с админкой и/или пользователями
Если пользователь не аутентифицирован и в свойстве loginUrl компонета user задан URL страницы входа, браузер будет перенаправлен на эту страницу. Заметим, что по умолчанию loginUrl перенаправляет к странице site/login;
Если пользователь не аутентифицирован и в свойстве loginUrl компонета user задан URL страницы входа, браузер будет перенаправлен на эту страницу. Заметим, что по умолчанию loginUrl перенаправляет к странице site/login;
Т.е. по сути если используем RBAC, то настраиваем публичные actions как Always Allowed и всё получается на ура?