Airily Skeleton App

[TBIKC]

Что то на главной не заметно
При входе кидает на http://skeletonyiiapp/index.php?r=users

[yiijeka]

Хз, я там обновил, была проблема с загрузкой стилей и картинок на фронт.

Посмотри ещё, чтобы \protected\frontend\config\main.php был блок разкомментирован (75 строка):

Код: Выделить всё

'urlManager' => array(
  'urlFormat' => 'path',
  'showScriptName' => false,
  'urlSuffix' => '/',
  rules' => $params['url.rules']
),

[yiijeka]

По настройке url:
1. Нужны ЧУП для backend?
Находим в \protected\backend\config\main.php

Код: Выделить всё

'urlManager' => array(...), 

и разкоментируем его. Также поступаем и с кодом в \.htaccess

Код: Выделить всё

RewriteRule ^backend backend.php [L] 

2. Нужны ЧУП для frontend?
Находим в \protected\frontend\config\main.php

Код: Выделить всё

'urlManager' => array(...), 

и разкоментируем его. Также поступаем и с кодом в \.htaccess

Код: Выделить всё

RewriteCond %{REQUEST_FILENAME} !/(css|images|js)/
RewriteRule !backend(.*) index.php [L] 

Правила задаются в \protected\(backend|frontend)\config\params(-prod|local).php

[porcelanosa]

А есть какая-нибудь инструкция как сабмитить на Github -
Я сделал форк на github вашего репозитария.
Checkout на локальном сервере из своего форка.
И типа если я сейчас буду, что править, и коммитить, то как это потом к примеру предложить Вам в качестве улучшения.
Где-то в каком то проекте на github читала подробную инструкцию, но не могу найти - а по памяти дальше вышеприведенных двух действий не помню
UPD:
Может это важно. Я под windows - юзаю phpStorm

[TBIKC]

Что то я совсем запутался =)
Раскомментировал ЧПУ urlmanager в бэке и фронте и ничего не работает
в .ht найти не могу такие строчки )

[porcelanosa]

Что то я совсем запутался =)
Раскомментировал ЧПУ urlmanager в бэке и фронте и ничего не работает
в .ht найти не могу такие строчки )

У меня открывается и
http://skeleton.local/index.php и http://skeleton.local/index.php?r=site - еще не копалось, но похоже, где - то правила не убраны.
а авторизация на фронтэнде и бэкэнде раздельная.
Хорошо это или плохо не знаю. У меня в моем "скелете" так тоже сделано - но я просто не задумывалась над этим. Как получилось.

P.S> хороший афоризм пришел на ум. "У каждого программиста - есть свой скелет на GitHub"

[Koduc]

TODO list
- Инсталлятор подпилить под линуксы - пытается создавать папки, на которые у него явно нет прав и отваливается по ошибке..
- При инсталле не проверяет права на /common/config/params-prod.php - опять таки отваливается
- Не добавляет юзера в админке (404)
- Аналогичная проблема с правами в композере. Короче пришлось на весь проект кинуть 777
- Show site в админке ведет в корень сервера, а не в корень проекта

Веб-морда к композеру - интересно;) Но пилить это всё еще.. Работы непочатый край. Успехов в этом начинании!

[yiijeka]

@Koduc, спасибо. Всё учту и постараюсь исправить :)

@porcelanosa по поводу git, всё написано очень доходчиво тут http://git-scm.com/book/ru.
В двух словах по вашему поводу. Делаете форк, клонируете к себе свой форк, создаёте ветку, переходите на неё, делаете изменения, сохраняете, делаете коммит, заливаете на свой форк. Заходите на github свой форк, там есть вкладки по выбору веток, выбираете в той что вели разработку, нажимаете кнопку большую в dashboard "Pull Request" пишите комментарий к своим изменениям и отправляет, ждёте от меня подтверждения или комментариев. Если подтверждение проходит можно свою ветку, где велась разработка слить с master локальной веткой и повторять операцию заново.

@TBIKC обнови конфиги main и param, htaccess с офф репо, там все эти строчки имеются. И если вносить в конфиг свои настройки, то лучше создать param-local или main-local в тех же папках, что и prod настройки и в них уже дописывать свои правила и т.д. Просто сейчас всё сырое и конфиг может очень часто меняться.

И ещё раз спасибо вам большое всем :)

[porcelanosa]

@Koduc, спасибо. Всё учту и постараюсь исправить

@porcelanosa по поводу git, всё написано очень доходчиво тут http://git-scm.com/book/ru.
В двух словах по вашему поводу. Делаете форк, клонируете к себе свой форк, создаёте ветку, переходите на неё, делаете изменения, сохраняете, делаете коммит, заливаете на свой форк. Заходите на github свой форк, там есть вкладки по выбору веток, выбираете в той что вели разработку, нажимаете кнопку большую в dashboard "Pull Request" пишите комментарий к своим изменениям и отправляет, ждёте от меня подтверждения или комментариев. Если подтверждение проходит можно свою ветку, где велась разработка слить с master локальной веткой и повторять операцию заново.

Спасибо - буду пробовать.

[lancecoder]

не помню где, но видел смотрел код - glob не совсем как бы правильно, не для всех ос так скажем
если у меня нет апача, мне мимо проходить?
если я не согласен с вашей структорой мне тоже мимо?
чем это расширение лучше простого использования компосера из КОНСОЛИ, если все модули заточены под КОНКРЕТНЫЙ проект

[yiijeka]

Про glod я что-то тоже слышал, но хз, посмотрю раз так :)

Ngix, если вы имеете в виду, пробовал, но так как мало опыта с ним, не получилось на нём запустить командные команды exec. Буду рад любой помощи.

Чем, конкретно не нравиться структура? Я ж просил любую критику. Если просто не нравиться, тогда да можете мимо ;) Мне кстати тоже не нравятся папки www во фронте и бэки, но пока не придумал куда их лучше засунуть.

Не могу понять, где я говорил, что модули нужно писать для конкретного проекта? С помощью композера закачать ЛЮБОЙ zip модуля и он будет работать, ЕСЛИ ОН НЕ ЗАТОЧЕН ДЛЯ КОНКРЕТНОГО проекта. Наоборот этот композер заставляет писать "идеальный" в понимании модуль, который потом можно обычным копированием перенести в любимый ваш проект, с пушистой структурой ;) Единственное ограничение - это имя zip файла, и если нужны таблицы с данными в бд, то их помещают в migrations/миграции. И + в том, что человеку не сильно разбирающемуся с запуском консольных команд, проще нажать одну кнопку, чтобы контролировать установленные модули :)

Спасибо, всеравно ;)

[lancecoder]

пример - я ставлю юзер модуль, он зависит от mysql db, т.е. при установке модуля подтягиваются модели? верно? или же модели будут в самом модуле? тогда как с другими ендами?
я ничего обидно не хотел сказать, просто замах большой, но пока не оправдан, и тут композер я считаю не совсем уместен, хотя, как я понимаю мы ждем его в Yii2, но по по сути он будет тянуть весь фреймворк целиком в vendor. Могу и ошибаться. Суть зависимостей которые нужно создать при реализации такого плана проекта это как минимум я считаю чтобы был выбор. Снова пример - я ставлю экшн авторизации, он автоматом тянет контроллер где есть логин\логаут, модуль, который в свою очередь тянет свои зависимости- к примеру компонент для работы с дб, необходимую модель, либо же это решается путем навешивания поведений через какойто универсальный адаптер. Фишка должна получится в чем - я посылаю запрос install user-mongodb/auth. Опять же чуть отклонюсь, если есть инстал, то нужно и работу конфига реализовать должным образом, где то хранить все эти связи что уже подтянуты, чтобы не повториятся, ну и удаление, переустановка и тому подобные вещи. Думаю что вам надо почитать про пакетные менеджеры, про (не знаю как правильно называются) кольцевые и древовидные зависимости и тогда желание связать композер думаю отпадет все без и чистое имхо. П.С. сам примерно тоже самое собираюсь делать, но для меня главным критерием здесь является работа в консоле. Как я это вижу:
/framework/
/installer/command/InstallCommand.php //extends WebappCommand
/installer/yiic.php

/installer/$ php yiic install app front

приложений я насчитал 5 типов -
фронт (где авторизация не обязательна)
бек (онли админ)
консоль для какихто кроновых задач
апи
воркер для геармана

многабукав наверно уже, но все же может ктото еще читает
структуру я предпочитаю ту что бойлерплейт (сори за транскрипцию) только чуть видоизмененную
/apps/front
/apps/back
/apps/worker
/apps/api
/common/command
/www <- public (assetst, image, css, index.php, backend.php, e.t.c)
комон тут по сути это консоль, но так же в ней лежат все общие какието вещи

Вернусь к первоначальному вопросу, если я ставлю во фронт какоето расширение, потом в бек мне оно же нужно, должен ли программист помнить об таких вещах или уж писать систему, которая действительно заменила всю эпопею с пакетами (модулями)

Рад любой критике, еще раз повторюсь это мое имхо

[porcelanosa]

ну у бойлерплейт так и есть -
Там можно добавить сколько угодно приложений - т.е. по умолчанию у них 2 приложения front и back - а дальше можно и front2 - и front-en добавить к примеру.
Бесит меня там, что надо лезть в конфиг апача - и прописывать для каждого приложения виртуальный хост и настройки
И к примеру у меня была проблема - я сохраняю картинки через фронт - а потом мне они нужны и в бэкэнде - Логично хранить в коммон - потому что иначе я их не получу
Пришлось создавать дополнительный домен i.site.ru под изображения.

[yiijeka]

пример - я ставлю юзер модуль, он зависит от mysql db, т.е. при установке модуля подтягиваются модели? верно? или же модели будут в самом модуле? тогда как с другими ендами?

Я модуль воспринимаю как самодостаточную единицу. Очень часто просматривая тот или иной проект, нахожу модуль, пытаюсь себе установить, а он не ставится. А всё потому, что он требует кучу компонентов и моделей, которые лежат просто в папках protected/components ... Так какого этот модуль называется модулем, если он не самодостаточен? (философский вопрос ;) А используя composer, как бы заставляет закачал zip и он должен работать и быть сразу доступным, без шаманства. Определив конкретные правила для таких zip, можно переделать готовые пару модулей, чтобы потом можно было быстро создать тот же простой блог или витрину магазина....

Опять же чуть отклонюсь, если есть инстал, то нужно и работу конфига реализовать должным образом, где то хранить все эти связи что уже подтянуты, чтобы не повториятся, ну и удаление, переустановка и тому подобные вещи.

Composer создаёт сам файл настройки, папку кэша и др. В этом и прелесть его использования. Сейчас только zip модули можно и то они помещаются в backend. В будущем хочется сделать и для url путей, и выбор места установки....
Прочитал бегло про пакетные менеджеры =), "кольцевые и древовидные зависимости" не нашёл. Зачем мне делать велосипед с кучей классов, создавая пакетный менеджер, если composer.phar все функции пакетного менеджера выполняет?

Фишка должна получится в чем - я посылаю запрос install user-mongodb/auth.

Нужно очень много манны ;)

/www <- public (assetst, image, css, index.php, backend.php, e.t.c)

Меня вот мучает вопрос, плохо ли хранить всё от бекэнда, фронтенда и другое в одном месте, именно так?

структуру я предпочитаю ту что бойлерплейт (сори за транскрипцию) только чуть видоизмененную

Структура хорошая, но блин, опять же вопрос с совместным использование моделей, контроллеров.... Нормального мануала как используется всё это во разных частях (бэк, фронт) приложения я не встречал. И поэтому получается не нужно это всё и лучше использовать yii webapp и не мучатся, но хочется же все равно разделения %)

@porcelanosa
Поддерживаю, по этому поводу уже писал вам: что Yiibolierplate как бы подразумевает строгое разделение на backend и frontend. Т.е. код из бэка ничего не знает про код из фронта. Поэтому тут у меня и вопрос "плохо ли хранить всё от бекэнда, фронтенда и другое в одном месте, именно так?"

[Ramazan]

пример - я ставлю юзер модуль, он зависит от mysql db, т.е. при установке модуля подтягиваются модели? верно? или же модели будут в самом модуле? тогда как с другими ендами?

Я модуль воспринимаю как самодостаточную единицу. Очень часто просматривая тот или иной проект, нахожу модуль, пытаюсь себе установить, а он не ставится. А всё потому, что он требует кучу компонентов и моделей, которые лежат просто в папках protected/components ... Так какого этот модуль называется модулем, если он не самодостаточен? (философский вопрос А используя composer, как бы заставляет закачал zip и он должен работать и быть сразу доступным, без шаманства. Определив конкретные правила для таких zip, можно переделать готовые пару модулей, чтобы потом можно было быстро создать тот же простой блог или витрину магазина....

Ссылка на "самодостаточную единицу" правильная, только вот философский вопрос не совсем правильный.

На указанной странице в самом первом абзаце есть фраза "модуль не может использоваться сам по себе — только в составе приложения.", а модель User (id, email, password, salt...) расположенная в app/models или common/models является частью этого приложения, следовательно UserModule либо идёт своим путём и содержит модель UserOther (id, email, password, salt, firstname, lastname, registered, activated...), либо в его состав входит модель UserProfile (user_id (fk), firstname, lastname, registered, activated...) которая будет связана с "главной" моделью User (можно даже в UserModule::init() добавить User::model() -> addRelation('profile', array(...))), но об их [s]интимной[/s] связи, никто кроме UserModule ( и вложенных в него модулей ) не должен знать.
Если же на сайте, за пределами UserModule, выводиться информация, которая доступна только через UserProfile, то и эту модель надо переместить в app/models или common/models, если и та и другая модель нигде кроме как в UserModule не используется, то их смело можно кидать в директорию моделей этого модуля.

Composer тут лишний, т.к. если NewsModule используется модель Comments, но при этом комментарии больше нигде не отображаются, то эта модель должна поставляться с модулем, если нет то уже при установке модуля новостей, она должна быть в глобальной директории.