Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Я бы еще engine, views, config вынес из www, оставил бы там только index.php и css+js
Честно говоря никаих нововведений здесь нет, так и советуют использовать yii сами разработчики.
Единственное, в вашем варианте непонятен сакральный смысл хранения тем внутри ядра фреймворка, в то время, как тема является частью проекта и, как правило, изменяется от проекта к проекту — это усложнит публикацию проекта на продакшн.
По поводу серии статей для новичков, я думаю, стоит написать. Когда сам впервые начинал с ним работать, то пока не расковырял все внутрености и не построил диаграмму классов принцип создание проекта отличного от стандартного блога был неизвестен.
Единственное, в вашем варианте непонятен сакральный смысл хранения тем внутри ядра фреймворка, в то время, как тема является частью проекта и, как правило, изменяется от проекта к проекту — это усложнит публикацию проекта на продакшн.
По поводу серии статей для новичков, я думаю, стоит написать. Когда сам впервые начинал с ним работать, то пока не расковырял все внутрености и не построил диаграмму классов принцип создание проекта отличного от стандартного блога был неизвестен.
Да, каюсь, проглядел — пора спать идти:). Тогда в принципе непонятен смысл идеи — отдельные конфигурации продакшн сервера и сервера разработки?
Ну теперь я точно спать:). Это ответ на этот коментарий
В основном это, плюс, на мой взгляд, достаточно удобная файловая организация.
Как дополнение, это можно использовать вообще для организации нескольких различных точек входа как на девел, так и на стейбл-серверах
Как дополнение, это можно использовать вообще для организации нескольких различных точек входа как на девел, так и на стейбл-серверах
Собственно так и надо. Еще хорошая практика добавлять фильтр по IP для дев режима, если у вас скажем дев версия в другой точке входа (у Simfony это app.php для продакшена и app_dev.php для дева)
У меня допустим при доступе с моего IP проект запускается в dev среде, тобиш обычный конфиг я расширяю dev настройками (дебаг панель и прочее).
К слову еще забавное решение скелета проекта под Yii — Phundament 3. Там реализована попытка разделения на пакеты. По сути та же идея что бандлы для симфони. Из плюшек — полностью модульная, независимые пути а так же по умолчанию поставляется twittter bootstrap. На данный момент это самая качественная реализация скелета проектов. Хоть и немного избыточная.
У меня допустим при доступе с моего IP проект запускается в dev среде, тобиш обычный конфиг я расширяю dev настройками (дебаг панель и прочее).
К слову еще забавное решение скелета проекта под Yii — Phundament 3. Там реализована попытка разделения на пакеты. По сути та же идея что бандлы для симфони. Из плюшек — полностью модульная, независимые пути а так же по умолчанию поставляется twittter bootstrap. На данный момент это самая качественная реализация скелета проектов. Хоть и немного избыточная.
Касательно цикла статей — если честно статей предостаточно. Даже книги есть. Так что написание проекта — это не то что нужно.
Мне по работе частенько приходилось поддерживать проекты на Yii, и ни в одном я не встретил использования конструктора форм. Хотя все эти вопросы уже довольно хорошо освещены в документации, но некоторые вопросы все-таки возникают.
К сожалению волею судьбы я больше не пишу под Yii (разочаровался пока. Жду вторую ветку, но судя по обсуждениям на форуме, особо нового ничего не будет). Приходится осваиваться с Symfony 2. А после нее Yii как-то кажется… уж слишком детским. Но все же как вторая ветка Иии выйдет — обязательно потыкаю.
Как по мне в Yii ужасна система маршрутизации, хотя это дело можно поправить ручками, расширить UrlManager.
Мне по работе частенько приходилось поддерживать проекты на Yii, и ни в одном я не встретил использования конструктора форм. Хотя все эти вопросы уже довольно хорошо освещены в документации, но некоторые вопросы все-таки возникают.
К сожалению волею судьбы я больше не пишу под Yii (разочаровался пока. Жду вторую ветку, но судя по обсуждениям на форуме, особо нового ничего не будет). Приходится осваиваться с Symfony 2. А после нее Yii как-то кажется… уж слишком детским. Но все же как вторая ветка Иии выйдет — обязательно потыкаю.
Как по мне в Yii ужасна система маршрутизации, хотя это дело можно поправить ручками, расширить UrlManager.
Симфония весьма себе громоздкая штука, если нужно развернуть какой-то небольшой проект, то, как мне кажется, лучше ею не заморачиваться) Особенно с ее генераторами кода и генераторами генераторов кода… Где-то тут была статья про фабрики фабрик фабрик фабрик инструментов, вот весьма в тему)
По поводу маршрутизации соглашусь, но с другой стороны, лучше — враг хорошего. Порой, когда надо сделать несколько фиксированных разделов, вроде '/shop/item<item_id:\d+>/buy' => 'shopcontroller/buyaction', то не хочется заморачиваться сколько-нибудь сложными конструкциями (что иногда весьма раздражало, например, в кохане).
Вопрос, конечно, в уровне разрабатываемого проекта
По поводу маршрутизации соглашусь, но с другой стороны, лучше — враг хорошего. Порой, когда надо сделать несколько фиксированных разделов, вроде '/shop/item<item_id:\d+>/buy' => 'shopcontroller/buyaction', то не хочется заморачиваться сколько-нибудь сложными конструкциями (что иногда весьма раздражало, например, в кохане).
Вопрос, конечно, в уровне разрабатываемого проекта
Мне казалось что генераторы генераторов это больше в сторону Yii, под симфони кодогенераторов особо нету. Есть генераторы сущностей, но это отдельная песня. Фабрики фабрик — тоже такого еще не видел — но может увижу. Как-то Фабьена тролили, мол симфони это java со значком доллара.
Однако что могу сказать — проработав 2 года с Yii, переход на симфони был тяжелым. Но сейчас я явно ощущаю что это уже другой уровень. Самая главная проблема Yii, да и PHP — низкий порог вхождения. А потому количество бесполезных/ужасно написанных расширений просто зашкаливает. Иногда ищешь что-то… находишь… и понимаешь что лучше самому написать, ибо это убожество использовать как-то не хочется. В симфони такое тоже встречается, но значительно реже.
Однако что могу сказать — проработав 2 года с Yii, переход на симфони был тяжелым. Но сейчас я явно ощущаю что это уже другой уровень. Самая главная проблема Yii, да и PHP — низкий порог вхождения. А потому количество бесполезных/ужасно написанных расширений просто зашкаливает. Иногда ищешь что-то… находишь… и понимаешь что лучше самому написать, ибо это убожество использовать как-то не хочется. В симфони такое тоже встречается, но значительно реже.
По поводу маршрутизации… ну я бы хотел допустим что бы маршруты отдельных модулей были прописаны непосредственно в модуле, а при подключении они бы включались в общий список правил. Тобиш ты подключаешь модуль, указываешь префикс, и на этом все. А то сейчас приходится все руками прописывать, и это не всегда удобно.
После подобных выкрутасов с Друпалом зарёкся использовать несколько не связанных «семантически» проектов на одном ядре. Лучше плавненько по одному обновлять. Хотя, конечно, если однотипных проектов десятки и сотни, то другие критерии. И то, пожалуй, просто бы заскриптовал обновление. Сейчас вообще проекты стараюсь по максимуму изолировать друг от друга, пожалуй из более-менее популярных способов осталось только с chroot разобраться или вообще в «облака» переехать.
А цикл статей был бы интересен.
А цикл статей был бы интересен.
Все же, Друпал это полноценная и весьма тяжелая CMS, так разделять ее, как те же фреймворки вроде Yii или Kohana, в основном себе дороже, если здесь весь процесс разделения находится в трех местах, то в друпале точек стыковки намного больше. Плюс, у друпала достаточно сложная система наследования шаблонов, с этим тоже надо как-то бороться.
Главной проблемой центрального ядра на множество проектов может быть тот случай, когда после какого-нибудь обновления версий, какая-нибудь недокументированная или новая штука может поменять логику работы существующих проектов, но на моей памяти таких ситуаций еще не было)
Главной проблемой центрального ядра на множество проектов может быть тот случай, когда после какого-нибудь обновления версий, какая-нибудь недокументированная или новая штука может поменять логику работы существующих проектов, но на моей памяти таких ситуаций еще не было)
Долго пытался понять реальную пользу, так и не понял, может не проснулся еще. С загрузкой конфига для dev/prod понятно, но такой подход наверное используется в каждом втором проекте. Раньше тоже по всякому меня структуру каталогов. Сейчас ограничиваюсь помещением повтороно используемых файлов в отдельный подкаталог extensions
Данный способ описывался больше для тех, кто хочет сделать именно распределенную, по тем или иным причинам, систему, где не надо заморачиваться с переносом проектов и рутиной при создании новых (достал, распаковал, выгрузил, переименовал, и так далее). В идеале, для этого пишется скрипт, где указывается название проекта (или, Как варинт, гит-репозиторий), на основе чего проект выкачивается конкретному пользователю и создается конкретная локальная девел-точка доступа к нему, и все.
Если общественности понравится, дополню статью описанным выше примером)
Если общественности понравится, дополню статью описанным выше примером)
Полезная статья для новичком, однако, замечу, что редактирование файлов ядра чревато большими проблемами. Если что-либо вас не устраивает в самом ядре- в помощь ООП.
Также стоит заметить, что в реальной ситуации, при работе с крупными проектами такой подход, по моему мнению, не самый удачный, так как часто приходится разносить проекты на разные сервера. В таком случае, при достаточном уровне финансирования больше подходит вариант с промежуточным сервером для тестирования+система контроля версий(я использую mercurial).В таком варианте можно уже на уровне .htpasswd настроить доступ+ ip.
Также стоит заметить, что в реальной ситуации, при работе с крупными проектами такой подход, по моему мнению, не самый удачный, так как часто приходится разносить проекты на разные сервера. В таком случае, при достаточном уровне финансирования больше подходит вариант с промежуточным сервером для тестирования+система контроля версий(я использую mercurial).В таком варианте можно уже на уровне .htpasswd настроить доступ+ ip.
svn:externals решает проблему использования различными проектами одних и тех же библиотек. Может быть не стоило настолько все усложнять.
P.S. юзать DIRECTORY_SEPARATOR реально круто, попробуйте:-)
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. Выглядит немного страшновато, зато довольно гибко
Для себя решил, что в 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:
— А если у меня в локальной сети развернута девел-локация, где, например, используется загрузка картинок/других файлов на сайт, и все это крутится на одной базе данных? Что делать моим коллегам, если я загрузил файл в некоторую структуру, а они его не увидят? Вот для этого случая и одно удаленное место.
По поводу assets, по теории Yii, в ней хранятся файлы, которые присоединяются так или иначе к проекту, а если я, например, использую какой-то js-скрипт или, например, css-reset в каждом из своих проектов, мне удобно, чтобы он у меня всегда присутствовал в одном месте и к нему был доступ. Мне это кажется логичным решением.
Да, особого смысла выносить runtime не было, но по поводу upload:
— А если у меня в локальной сети развернута девел-локация, где, например, используется загрузка картинок/других файлов на сайт, и все это крутится на одной базе данных? Что делать моим коллегам, если я загрузил файл в некоторую структуру, а они его не увидят? Вот для этого случая и одно удаленное место.
Не совсем понял вот это
Вы хотите, чтобы одни и те же файлы были доступны для нескольких приложений? Но тогда зачем класть assets в /home/projects/data/demo.lori/assets? Там же явно указано к какому проекту они принадлежат. Или я чего-то не понимаю? Сама идея сделать симлинк куда-то понятна.
Про uploads понятно, я предпочитаю иметь свою копию для девелопа (и базу) и чтобы тестовый сервер в локальной сети был тоже полноценным и независимым.
а если я, например, использую какой-то js-скрипт или, например, css-reset в каждом из своих проектов, мне удобно, чтобы он у меня всегда присутствовал в одном месте и к нему был доступ. Мне это кажется логичным решением.
Вы хотите, чтобы одни и те же файлы были доступны для нескольких приложений? Но тогда зачем класть assets в /home/projects/data/demo.lori/assets? Там же явно указано к какому проекту они принадлежат. Или я чего-то не понимаю? Сама идея сделать симлинк куда-то понятна.
Про uploads понятно, я предпочитаю иметь свою копию для девелопа (и базу) и чтобы тестовый сервер в локальной сети был тоже полноценным и независимым.
По идее, вот это:
Можно заменить на:
А за статью спасибо.
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')
)
)
);
Сливается все это в один посредством 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 проекта с разными индивидуальными фишками и дизайном (темами), а также, получается, разными конфигами.
Пожалуйста, объясните, каким образом происходит переключение между разными проектами, если, допустим, что на базе ядра работает 2 проекта с разными индивидуальными фишками и дизайном (темами), а также, получается, разными конфигами.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дискретные проекты Yii на основе общего ядра