Pull to refresh

Comments 34

Я бы еще engine, views, config вынес из www, оставил бы там только index.php и css+js
В принципе, как вариант, можно оставить вместо www одну папку public_html, где будет индекс и стили-скрипты)
Надо подумать над этим вариантом)
Честно говоря никаих нововведений здесь нет, так и советуют использовать yii сами разработчики.
Единственное, в вашем варианте непонятен сакральный смысл хранения тем внутри ядра фреймворка, в то время, как тема является частью проекта и, как правило, изменяется от проекта к проекту — это усложнит публикацию проекта на продакшн.

По поводу серии статей для новичков, я думаю, стоит написать. Когда сам впервые начинал с ним работать, то пока не расковырял все внутрености и не построил диаграмму классов принцип создание проекта отличного от стандартного блога был неизвестен.
Нет, темы не хранятся в ядре, они хранятся в папке с проектом, в в папке themes. Yii ведь сначала ищет их в themes, а потом уже в engine/views
Да, каюсь, проглядел — пора спать идти:). Тогда в принципе непонятен смысл идеи — отдельные конфигурации продакшн сервера и сервера разработки?
Ну теперь я точно спать:). Это ответ на этот коментарий
Доброй ночи)) Высыпайтесь)
В основном это, плюс, на мой взгляд, достаточно удобная файловая организация.
Как дополнение, это можно использовать вообще для организации нескольких различных точек входа как на девел, так и на стейбл-серверах
Собственно так и надо. Еще хорошая практика добавлять фильтр по IP для дев режима, если у вас скажем дев версия в другой точке входа (у Simfony это app.php для продакшена и app_dev.php для дева)
У меня допустим при доступе с моего IP проект запускается в dev среде, тобиш обычный конфиг я расширяю dev настройками (дебаг панель и прочее).

К слову еще забавное решение скелета проекта под Yii — Phundament 3. Там реализована попытка разделения на пакеты. По сути та же идея что бандлы для симфони. Из плюшек — полностью модульная, независимые пути а так же по умолчанию поставляется twittter bootstrap. На данный момент это самая качественная реализация скелета проектов. Хоть и немного избыточная.
По поводу разделения по IP, согласен, на моей работе на другой схеме подобный механизм используется, плюс, для некоторых проектов на девел-точку привязана вся офисная подсеть.
А за ссылку спасибо, изучу на досуге!
Касательно цикла статей — если честно статей предостаточно. Даже книги есть. Так что написание проекта — это не то что нужно.
Мне по работе частенько приходилось поддерживать проекты на Yii, и ни в одном я не встретил использования конструктора форм. Хотя все эти вопросы уже довольно хорошо освещены в документации, но некоторые вопросы все-таки возникают.

К сожалению волею судьбы я больше не пишу под Yii (разочаровался пока. Жду вторую ветку, но судя по обсуждениям на форуме, особо нового ничего не будет). Приходится осваиваться с Symfony 2. А после нее Yii как-то кажется… уж слишком детским. Но все же как вторая ветка Иии выйдет — обязательно потыкаю.

Как по мне в Yii ужасна система маршрутизации, хотя это дело можно поправить ручками, расширить UrlManager.
Симфония весьма себе громоздкая штука, если нужно развернуть какой-то небольшой проект, то, как мне кажется, лучше ею не заморачиваться) Особенно с ее генераторами кода и генераторами генераторов кода… Где-то тут была статья про фабрики фабрик фабрик фабрик инструментов, вот весьма в тему)

По поводу маршрутизации соглашусь, но с другой стороны, лучше — враг хорошего. Порой, когда надо сделать несколько фиксированных разделов, вроде '/shop/item<item_id:\d+>/buy' => 'shopcontroller/buyaction', то не хочется заморачиваться сколько-нибудь сложными конструкциями (что иногда весьма раздражало, например, в кохане).
Вопрос, конечно, в уровне разрабатываемого проекта
Мне казалось что генераторы генераторов это больше в сторону Yii, под симфони кодогенераторов особо нету. Есть генераторы сущностей, но это отдельная песня. Фабрики фабрик — тоже такого еще не видел — но может увижу. Как-то Фабьена тролили, мол симфони это java со значком доллара.

Однако что могу сказать — проработав 2 года с Yii, переход на симфони был тяжелым. Но сейчас я явно ощущаю что это уже другой уровень. Самая главная проблема Yii, да и PHP — низкий порог вхождения. А потому количество бесполезных/ужасно написанных расширений просто зашкаливает. Иногда ищешь что-то… находишь… и понимаешь что лучше самому написать, ибо это убожество использовать как-то не хочется. В симфони такое тоже встречается, но значительно реже.

Аналогично, я из за этого перестал любить коробочные решения и до сих пор иногда кошусь на коллег, когда мне радостно предлагают использовать тот или иной модуль (не обязательно к фреймворку).
По поводу маршрутизации… ну я бы хотел допустим что бы маршруты отдельных модулей были прописаны непосредственно в модуле, а при подключении они бы включались в общий список правил. Тобиш ты подключаешь модуль, указываешь префикс, и на этом все. А то сейчас приходится все руками прописывать, и это не всегда удобно.
Хм, кажется, вы подали мне идею) Спасибо)
После подобных выкрутасов с Друпалом зарёкся использовать несколько не связанных «семантически» проектов на одном ядре. Лучше плавненько по одному обновлять. Хотя, конечно, если однотипных проектов десятки и сотни, то другие критерии. И то, пожалуй, просто бы заскриптовал обновление. Сейчас вообще проекты стараюсь по максимуму изолировать друг от друга, пожалуй из более-менее популярных способов осталось только с chroot разобраться или вообще в «облака» переехать.

А цикл статей был бы интересен.
Все же, Друпал это полноценная и весьма тяжелая CMS, так разделять ее, как те же фреймворки вроде Yii или Kohana, в основном себе дороже, если здесь весь процесс разделения находится в трех местах, то в друпале точек стыковки намного больше. Плюс, у друпала достаточно сложная система наследования шаблонов, с этим тоже надо как-то бороться.

Главной проблемой центрального ядра на множество проектов может быть тот случай, когда после какого-нибудь обновления версий, какая-нибудь недокументированная или новая штука может поменять логику работы существующих проектов, но на моей памяти таких ситуаций еще не было)
Долго пытался понять реальную пользу, так и не понял, может не проснулся еще. С загрузкой конфига для dev/prod понятно, но такой подход наверное используется в каждом втором проекте. Раньше тоже по всякому меня структуру каталогов. Сейчас ограничиваюсь помещением повтороно используемых файлов в отдельный подкаталог extensions
Данный способ описывался больше для тех, кто хочет сделать именно распределенную, по тем или иным причинам, систему, где не надо заморачиваться с переносом проектов и рутиной при создании новых (достал, распаковал, выгрузил, переименовал, и так далее). В идеале, для этого пишется скрипт, где указывается название проекта (или, Как варинт, гит-репозиторий), на основе чего проект выкачивается конкретному пользователю и создается конкретная локальная девел-точка доступа к нему, и все.
Если общественности понравится, дополню статью описанным выше примером)
Полезная статья для новичком, однако, замечу, что редактирование файлов ядра чревато большими проблемами. Если что-либо вас не устраивает в самом ядре- в помощь ООП.
Также стоит заметить, что в реальной ситуации, при работе с крупными проектами такой подход, по моему мнению, не самый удачный, так как часто приходится разносить проекты на разные сервера. В таком случае, при достаточном уровне финансирования больше подходит вариант с промежуточным сервером для тестирования+система контроля версий(я использую mercurial).В таком варианте можно уже на уровне .htpasswd настроить доступ+ ip.
На текущей работе как раз используется примерно описанное вами, вполне себе удобно)
svn:externals решает проблему использования различными проектами одних и тех же библиотек. Может быть не стоило настолько все усложнять.

P.S. юзать DIRECTORY_SEPARATOR реально круто, попробуйте:-)
Ну, сложностей тут никаких нет, но, согласитесь, фишка, которая используется в одной системе контроля версий, может отсутствовать в других, потому это не выход)
А по поводу сепаратора, знаем, плавали, не вдохновило) Вернее, вдохновило, но лишь из принципа «Приколись, братва, как я могу!»)
Я как-то не особо понял в чем смысл выносить assets/runtime/upload непонятно куда?
Для себя решил, что в www оставлять только то, что доступно в паблик. Темы, статик js/css, assets, uploads.
Сам код проекта лежит в application на одном уровне с www. Библиотеки фреймворка где-то в отдельном месте, общем для всех.
..../workspace/demo.lori/
-----www/
-------css/
-------js/
-------assets/
-------smth_else/
-----application/
-------runtime/

Конфиги разбиваю так: есть main.php общий конфиг, на конкретном хосте лежит main_local.php. В девелопер окружении у меня свой main_local, на продакшене свой. Также main_local в игнор-списке контроля версий. В index.php подключаю main.php всегда, поверх main_local.php, если он присутствует. Аналогично для остальных конфигов — cli/еще что надо. Иногда бывает удобным вынести в какой-нибудь common_local.php все, что связано с подключением к базе/кешу/message source и т.п. и подключать его и в обычном режиме и в cli.
На продакшене в дебаг-режиме ничего не запускаю, даже для себя — можно же отладить на локальной машине с xdebug и плюшками, все равно править локально и коммитить в удаленный репозитарий.

Вот кусок из index.php. Выглядит немного страшновато, зато довольно гибко
// change the following paths if necessary
$yii=dirname(__FILE__).'/../framework/yii.php';

require_once($yii);

//Подключаем конфиг для веб-части
$config = require(dirname(__FILE__).'/protected/config/main.php');

//Подключаем локальный конфиг для веб-части, если есть
if ( file_exists(dirname(__FILE__).'/protected/config/main_local.php') ) {
    $config = CMap::mergeArray($config, require(dirname(__FILE__).'/protected/config/main_local.php'));
}
//Подключаем общий конфиг
if ( file_exists(dirname(__FILE__).'/protected/config/common.php') ) {
    $config = CMap::mergeArray($config, require(dirname(__FILE__).'/protected/config/common.php'));
}
if ( file_exists(dirname(__FILE__).'/protected/config/common_local.php') ) {
    $config = CMap::mergeArray($config, require(dirname(__FILE__).'/protected/config/common_local.php'));
}
Ну по поводу main.php, он и лежит на всех версиях, плюс для каждой версии он свой. Да, в принципе, можно сделать некоторый Extend одного конфига дополнениями, в некоторых случаях это было бы удобно) Хотя на счет выделения некоторых частей конфига в отдельные файлы, это я, в принципе, и сделал, вынеся в отдельный файл routes.php.

По поводу assets, по теории Yii, в ней хранятся файлы, которые присоединяются так или иначе к проекту, а если я, например, использую какой-то js-скрипт или, например, css-reset в каждом из своих проектов, мне удобно, чтобы он у меня всегда присутствовал в одном месте и к нему был доступ. Мне это кажется логичным решением.

Да, особого смысла выносить runtime не было, но по поводу upload:
— А если у меня в локальной сети развернута девел-локация, где, например, используется загрузка картинок/других файлов на сайт, и все это крутится на одной базе данных? Что делать моим коллегам, если я загрузил файл в некоторую структуру, а они его не увидят? Вот для этого случая и одно удаленное место.
Не совсем понял вот это
а если я, например, использую какой-то js-скрипт или, например, css-reset в каждом из своих проектов, мне удобно, чтобы он у меня всегда присутствовал в одном месте и к нему был доступ. Мне это кажется логичным решением.

Вы хотите, чтобы одни и те же файлы были доступны для нескольких приложений? Но тогда зачем класть assets в /home/projects/data/demo.lori/assets? Там же явно указано к какому проекту они принадлежат. Или я чего-то не понимаю? Сама идея сделать симлинк куда-то понятна.

Про uploads понятно, я предпочитаю иметь свою копию для девелопа (и базу) и чтобы тестовый сервер в локальной сети был тоже полноценным и независимым.
По поводу assets, да, в данном случае, согласен, немного косячно, в основном профит тот же, что и с папкой upload, это можно модифицировать, заменив соответствующие строки примерно на следующее
ln -s /home/projects/data/assets/ /home/lori/workspace/demo.lori/www/assets
По идее, вот это:

if (array_key_exists('HTTP_LORI_DEBUG', $_SERVER) and $_SERVER['HTTP_LORI_DEBUG'] == 'DEBUG IT, DEBUG!')

Можно заменить на:

if (getenv('HTTP_LORI_DEBUG') == 'DEBUG IT, DEBUG!')


А за статью спасибо.
В своих проектах конфигурационные данные, которые неизменны, а так же конфигурации модулей выношу в отдельные файлы.
Сливается все это в один посредством rquire и CMap::mergeArray();
По мне так удобно.
Если конфигурировать модули, редактируешь config/modules.php, если какие то настройки, затрагивающие все приложение (те же runtimePath, basePath и иже с ними) то config/general.php и далее по аналогии.

В итоге главный конфиг, который и подключается к проекту выглядит например так:

return CMap::mergeArray(
require_once(dirname(__FILE__).DIRECTORY_SEPARATOR.'database.php'),
CMap::mergeArray(
require_once(dirname(__FILE__).DIRECTORY_SEPARATOR.'modules.php'),
CMap::mergeArray(
require_once(dirname(__FILE__).DIRECTORY_SEPARATOR.'components.php'),
require_once(dirname(__FILE__).DIRECTORY_SEPARATOR.'general.php')
)
)
);
Спасибо за идею, положу в копилку, поэкспериментирую)
то какой не тривиальный (вроде предложенных блогов или адресной книги) сайт вам хотелось бы увидеть?

Предлагаю, тоже довольно тривиальное, но при этом покроет достаточно много аспектов — доска объявлений.
Как я понял у вас структура именно на один проект с devel и public версиями, или нет?
Пожалуйста, объясните, каким образом происходит переключение между разными проектами, если, допустим, что на базе ядра работает 2 проекта с разными индивидуальными фишками и дизайном (темами), а также, получается, разными конфигами.
Only those users with full accounts are able to leave comments. Log in, please.