ygin - CMF/CMS система на yii

[mixa]

Привет!
У себя в компании мы писали свою систему для разработки сайтов и разных веб-сервисов, и когда появился yii, не смогли устоять и начали всё переписывать на yii.
Когда переписали, то возникла мысль что она может пригодиться кому-то ещё и решили выложить её в открытый доступ.

https://github.com/ygin-system/ygin

Сейчас пытаемся организовать документацию и обложить всё юнит-тестами.
Интересно выслушать мнение всех - замечания, пожелания, предложения и любую критику.

Быстроссылки:
демка (в контенте логин/пароль в админку): http://demo.ygin.ru
что есть по документации: http://www.ygin.ru/documentation/
инсталлятор: https://github.com/ygin-system/ygin-install
и ещё раз сами исходники: https://github.com/ygin-system/ygin

[Vladimir P]

При беглом просмотре админка ничотак, на выходных нужно будет глянуть ближе.

[yuran]

Выглядит внушительно, молодцы ребята, спасибо что выложили и поделились.

[xoma]

Отличный проект! Спасибо за исходники!

Подскажите удалось ли протестировать код юнит-тестами и какие сложности возникли ?

[mixa]

Спасибо за отзывы!

Подскажите удалось ли протестировать код юнит-тестами и какие сложности возникли ?

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

Поделюсь некоторыми любопытными моментами в реализации, интересно ваше мнение и критика.
В целом мы стараемся всё разбивать на yii-модули, чтоб функционал был более-менее обособлен и всё было в одном месте.
С другой стороны, стоит задача дать возможность разработчику переопределить любые компоненты модуля (контроллеры/вьюхи/модели).
И здесь нам немного не хватило возможностей yii - контроллеры и вьюхи переопределять можно, а вот с моделями есть сложность.
Например, если в модуле везде используется модель News, а на прикладном сайте понадобилось использовать свою модель MyNews, то придется по-большому счету переписывать весь модуль, заменяя везде News на MyNews.
Вместо этого мы используем свой механизм переопределения моделей. Достаточно в конфиге написать 'models' => array('News' => 'MyNews'). И теперь при вызове News::model() уже вернется модель MyNews.

Также, для полной обособленности модулей, мы в них храним роуты, а не напрямую в конфиге в urlManager.

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

[xoma]

Вместо этого мы используем свой механизм переопределения моделей. Достаточно в конфиге написать 'models' => array('News' => 'MyNews'). И теперь при вызове News::model() уже вернется модель MyNews

Это очень напоминает DI +IoC контейнер, не смотрели в сторону уже готовых решений ?

[mixa]

Вместо этого мы используем свой механизм переопределения моделей. Достаточно в конфиге написать 'models' => array('News' => 'MyNews'). И теперь при вызове News::model() уже вернется модель MyNews

Это очень напоминает DI +IoC контейнер, не смотрели в сторону уже готовых решений ?

Да, это очень похоже и если будет необходимость применения такой слабой связности в других местах, то можно будет применить готовые решения.
Для моделей же реализация получилась достаточно простая, поэтому сейчас всё самописно. Вот тут можно поглядеть реализацию: https://github.com/ygin-system/ygin/blo ... Record.php

[nizsheanez]

Реализация понятна и вроде удобна, но не надежна.
Модель созданная через new сломает подход.

Ну и не понравилось свойство $_isStart, пока не прочитаешь весь год не поймешь зачем он. Дайте ребенку хорошее имя.

Личные мысли:
Лично я за реализацию через код, а не через массивы. В том смысле, что в вашем да и любом DI мы теряем автокомплит, что не может не бесить. Лично я за фабричные методы, а вот где они будут написаны это вопрос открытый.

[mixa]

Реализация понятна и вроде удобна, но не надежна.
Модель созданная через new сломает подход.

Ну и не понравилось свойство $_isStart, пока не прочитаешь весь год не поймешь зачем он. Дайте ребенку хорошее имя.

Личные мысли:
Лично я за реализацию через код, а не через массивы. В том смысле, что в вашем да и любом DI мы теряем автокомплит, что не может не бесить. Лично я за фабричные методы, а вот где они будут написаны это вопрос открытый.

Да, с $_isStart схалтурили)

Но по сути с вами не соглашусь. Дело в том, что такое применение необходимо лишь внутри системы, когда стоит задача написать модуль, который можно будет переопределять.
При разработке сайта, когда необходимо переопределить модель, с ней уже работаем как обычно - через new или через Model::model().
Т.е. и автокомплит будет работать, и с new ничего не сломается.

[nizsheanez]

как это через new не сломается?

[mixa]

Тут стоит понимать специфику системы. В системе есть готовые модули, они представляют базовый функционал и в них new действительно НЕ используем.
Но с этими модулями напрямую работа и не идет, изменять их нельзя. Если есть необходимость расширить функционал базовых модулей, то переопределяем модели, контроллеры, вью и др. компоненты. И в них работаем уже напрямую с новыми моделями через new. Т.е. у разработчиков сайта на системе ygin не будет никаких проблем с автокомплитом и не надо вообще знать о каких-то магических методах.
Как-то так, надеюсь объяснил.

[nizsheanez]

1) Т.е. вы при переопределении модуля предлагаете переопределять все модели?

2) "new действительно НЕ используем" - уверены?)) Приведу пример: вам нужно запилить AciveDataProvider. Пишем:

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

new CActiveDataProvider('BaseModelClass');
 

и этот код внутри проходит через метод
https://github.com/yiisoft/yii/blob/mas ... r.php#L163
Оп! И мы прошли мимо вашего фабричного метода!
Понятно, что чинится через new CActiveDataProvider(BaseModelClass::model())
Но вы же понимаете, что таких неявных мест - полный фреймворк. Все такие нюансы будете в голове держать?
Просто хочется понять, что вы действительно до конца продумали чем может обернуться для вас отказ от new и подмена моделей.

3) Другой примерчик:

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

$db = new CActiveDataProvider(BaseModelClass::model()->scope1()->scope2());
$result = BaseModelClass:model()->findAll();
$data = $dp->getData();
 

Вроде бы мы имели в виду создание провайдера по отфильтрованных поусловиям scpe1() и scope2() записям.
А потом хотели получить все записи и положить в переменную $result.
Однако получится наоборот: в $result будут лежать отфильтрованные данные, а в $data НЕ отфильтрованные.
Конечно это не проблема вашего подхода, но вы подталкиваете писать именно так.

Но вроде ваш подход должен сработать ))

[mixa]

1) Т.е. вы при переопределении модуля предлагаете переопределять все модели?

Как раз нет, только если нужно что-то переопределить.

2) "new действительно НЕ используем" - уверены?)) Приведу пример: вам нужно запилить AciveDataProvider. Пишем:

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

new CActiveDataProvider('BaseModelClass');
 

и этот код внутри проходит через метод
https://github.com/yiisoft/yii/blob/mas ... r.php#L163
Оп! И мы прошли мимо вашего фабричного метода!
Понятно, что чинится через new CActiveDataProvider(BaseModelClass::model())
Но вы же понимаете, что таких неявных мест - полный фреймворк. Все такие нюансы будете в голове держать?
Просто хочется понять, что вы действительно до конца продумали чем может обернуться для вас отказ от new и подмена моделей.

3) Другой примерчик:

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

$db = new CActiveDataProvider(BaseModelClass::model()->scope1()->scope2());
$result = BaseModelClass:model()->findAll();
$data = $dp->getData();
 

Вроде бы мы имели в виду создание провайдера по отфильтрованных поусловиям scpe1() и scope2() записям.
А потом хотели получить все записи и положить в переменную $result.
Однако получится наоборот: в $result будут лежать отфильтрованные данные, а в $data НЕ отфильтрованные.
Конечно это не проблема вашего подхода, но вы подталкиваете писать именно так.

Но вроде ваш подход должен сработать ))

Кажется, мы друг друг до конца не понимаем)
В переопределенных компонентах должны использоваться уже напрямую новые модели. Если устраивают базовые, то базовые.
Исходные же модули мы осознанно пишем с поддержкой переопределения моделей и конструкции типа "new CActiveDataProvider('BaseModelClass');" не используем.

Проблема может быть в одном случае - если есть переопределенная модель, но разработчик делает вызов базовой модели.
Но это странный случай, ведь если разработчик переопределил модель, то он знает о ней и будет использовать её.

[nizsheanez]

ну я и говорю, что должно работать ))

[mixa]

Ещё в системе сделан доступ к консольным приложениям через браузер.
Хотя всё это и противоречит концепции консольных приложений, но на практике бывает невозможно получить доступ к консольке на обычных виртуальных хостингах.
А доступ нужен, чтобы например прогнать миграции и обновить систему. Это выполняется таким образом: domain.ru/yiic/migrate/
Вторым параметром передается имя команды и далее могут быть параметры.
Доступ через браузер доступен только в дебаг-режиме.

Ещё в системе есть специальный раздел для переопределения представлений.


Честно признаться, сложно запомнить как для виджетов и представлений должны располагаться файлы в теме.
Тут же видим все доступные представления/ресурсы и определяем какие должны быть скопированы в тему и т.о. переопределяем поведение по умолчанию.

Как обычно, буду рад за ваши замечания и критику =)

[SamePeople]

1 предложение - при установке можно сделать проверку на rw директорий чтобы не выпадали exception
2 Ошибка миграций:
PHP Error [1]

Fatal error: Nesting level too deep - recursive dependency? (/var/www/yandex.ru/htdocs/ygin/yii/logging/CLogFilter.php:100)

поставить не удалось


решение простое
проблема в миграциях и в длине ключей в таблицах da_files и da_object_parameters
ключи скорректировал миграции не трогал просто дампы залил всё встало

[IvanChe]

Уоу-уоу-уоу! Выглядит очень хорошо
Поставлю на ближайший проектик, попробую поработать. Давно ждал нечто подобное. Как сдам клиенту сайт на ней, отпишусь обязательно.

[slavik]

1 предложение - при установке можно сделать проверку на rw директорий чтобы не выпадали exception
2 Ошибка миграций:
PHP Error [1]

Fatal error: Nesting level too deep - recursive dependency? (/var/www/yandex.ru/htdocs/ygin/yii/logging/CLogFilter.php:100)

поставить не удалось


решение простое
проблема в миграциях и в длине ключей в таблицах da_files и da_object_parameters
ключи скорректировал миграции не трогал просто дампы залил всё встало

Добрый день. В PHP я новичок. Но очень хочется познакомиться с YGIN.

При установке выходит такая же ошибка.

Подскажите как решить эту проблему. Спасибо.

[Rustavely]

Добрый день. В PHP я новичок. Но очень хочется познакомиться с YGIN.

При установке выходит такая же ошибка.

Подскажите как решить эту проблему. Спасибо.

Привет. Попробуй дать права на запись для каталогов
site/assets
site/protected/runtime
site/protected/config

[slavik]

Права на запись стоят. Ошибка остаётся.