Я конечно могу ошибаться, но по идее многие вещи должны быть спрятаны внутри модуля (очистка индексов, пред- и постобработка данных и тд), например в модели Model_Searchindex.
If you find that you need a particular model globally throughout your application, you can tell CodeIgniter to auto-load it during system initialization. This is done by opening the application/config/autoload.php file and adding the model to the autoload array.
Бугага, автозагрузка ))
Судя по документации, они остались на уровне Kohana v2.3
1. Не могу сказать, CI успел потрогать года 4 назад только.
2. Вы про переопределение? Да, с помощью Каскадной Файловой Системы и наличия специальных классов-пустышек все очень просто. То есть для класса Database весь функционал реализован в Kohana_Database, и ничего не мешает добавить что-то свое в Database.
3. Обычный PHP-шаблонизатор, в который можно передать переменные из контроллера. Прочие шаблонизаторы только в виде модулей можно подключать.
4. Стороны надо сравнивать с чем-то )) Про слабости проще сказать. Я считаю, что главная проблема — разработчики модулей тупо забили на наличие нескольких параллельных версий (сейчас это 3.2 и 3.3), и обычно актуализируют только свою, с которой работают. И не все модули получится вот так вот взять и портировать с одной версии на другую.
5. Не знаю, решайте сами )) Сейчас фреймворков много, и решает наверное даже не «сила» фреймворка, а количество вакансий/заказов и расценки на них.
Недавно на форуме было обсуждение темпов разработки, и там проскакивали слова, что при должной активности и качестве отправляемого кода любой разработчик может попасть в команду.
Смысл в том, что порядок параметров может меняться (гибкий роутинг позволяет впихнуть в начало или в середину необязательные сегменты адреса), что в таких случаях делать предлагаете? Не вижу ничего страшного, чтобы в начале экшена записать в локальную переменную нужный параметр и далее с ним работать. В CI вроде бы тоже есть длиннющие портянки вызовов, и ничего ))
С дыркой вроде все ясно. А почему у вас возможны такие значения для param1? Все-таки первичный контроль УРЛы должны проходить еще при обработке роутов, используя заданные регекспы для сегментов адреса.
Был ощутимый простой в разработке, но сейчас в ближайшее время стоит ожидать последовательно релизы веток 3.1 (там вообще один тикет остался незакрытым), 3.2 и 3.3.
1. Методы isHuman() и getForm() статические, поэтому и вызывать их надо без использования фабрики.
2. Какой смысл в конструкторе несколько раз грузить конфиг? Достаточно один раз — когда $botobor_class пустой. Аналогично с правилами, секретом и т.д. — их можно добавить в Botobor через статические методы ОДИН раз.
В целом, складывается ощущение жуткой поделки на коленке, с использованием неизученной библиотеки. Абы как.
PS. В голову пришла мысль — такие вещи было бы прикольно прикручивать к штатному валидатору, как правило (callback). Очень полезная штучка получилась бы.
1. Не «все равно», а в случае конфликта имен. Этого не избежать.
2. Никто не мешает ему автоматом сгенерировать пароль (либо просто предоставить возможность указать пароль для входа через стандартную схему). Но и OAuth должен остаться доступным. Храните его OauthID (по идее, это комбинация oAuthID и ProviderID), потом всегда сможете проверить, существует ли учетка.
3. Конечно, стоит проверять его email, и объединять учетки. Ник ни в коем случае не является показателем, в лучшем случае предложите указать свои прочие учетки (вход через них является подтверждением, т.е. email вроде и необязателен). Как-то так.
На самом деле на Хабре есть несколько статей с подобным обсуждением, одну из них вроде и я создавал.
Model_Searchindex.Ну и конечно
меняем на
(сортировка скорее всего тоже не нужна)
Бугага, автозагрузка ))
Судя по документации, они остались на уровне Kohana v2.3
2. Вы про переопределение? Да, с помощью Каскадной Файловой Системы и наличия специальных классов-пустышек все очень просто. То есть для класса Database весь функционал реализован в Kohana_Database, и ничего не мешает добавить что-то свое в Database.
3. Обычный PHP-шаблонизатор, в который можно передать переменные из контроллера. Прочие шаблонизаторы только в виде модулей можно подключать.
4. Стороны надо сравнивать с чем-то )) Про слабости проще сказать. Я считаю, что главная проблема — разработчики модулей тупо забили на наличие нескольких параллельных версий (сейчас это 3.2 и 3.3), и обычно актуализируют только свою, с которой работают. И не все модули получится вот так вот взять и портировать с одной версии на другую.
5. Не знаю, решайте сами )) Сейчас фреймворков много, и решает наверное даже не «сила» фреймворка, а количество вакансий/заказов и расценки на них.
Core Devs тоже люди, им тоже семьи кормить надо.
Насчет внедрения в сайты о недвижимости — интересно. Только это продавец должен сам нарисовать проект?
Неслабая ложка дегтя в итоговой стоимости.
2. Какой смысл в конструкторе несколько раз грузить конфиг? Достаточно один раз — когда $botobor_class пустой. Аналогично с правилами, секретом и т.д. — их можно добавить в Botobor через статические методы ОДИН раз.
В целом, складывается ощущение жуткой поделки на коленке, с использованием неизученной библиотеки. Абы как.
PS. В голову пришла мысль — такие вещи было бы прикольно прикручивать к штатному валидатору, как правило (callback). Очень полезная штучка получилась бы.
2. Никто не мешает ему автоматом сгенерировать пароль (либо просто предоставить возможность указать пароль для входа через стандартную схему). Но и OAuth должен остаться доступным. Храните его OauthID (по идее, это комбинация oAuthID и ProviderID), потом всегда сможете проверить, существует ли учетка.
3. Конечно, стоит проверять его email, и объединять учетки. Ник ни в коем случае не является показателем, в лучшем случае предложите указать свои прочие учетки (вход через них является подтверждением, т.е. email вроде и необязателен). Как-то так.
На самом деле на Хабре есть несколько статей с подобным обсуждением, одну из них вроде и я создавал.