CKEditorproctoleha писал(а): ↑2018.01.10, 16:39 А вообще ткните меня в свежий актуальный визиги редактор, где картинки и файлы, из коробки, грузились бы не по адресу картинки, а с локальной ОС
Как правильно выложить свое приложение, если есть лицензионные ограничения
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
- proctoleha
- Сообщения: 298
- Зарегистрирован: 2016.07.10, 19:00
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
Вот тут https://github.com/MihailDev/yii2-ckeditor ? Виджет который коммитился последний раз три года назад? Пруф дайте пожалуйста на готовый виджет для свежего рабочего CKEditor4, в котором бы файлы и картинки грузились бы из коробки. Чтобы поставил и забыл.
Хороший ли, плохой, но у меня такой виджет для имперави редактора 2-ой версии работает уже не первый год. Файлы, картинки, грузит, по ctrl + s форму сохраняет, мусор из ФС убирает. Виджет, конечно, не редактор, но в тесной связке с ним.
Вот за что я не люблю линукс, так это за свои кривые, временами, руки
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
Тема про опен сорсproctoleha писал(а): ↑2018.01.10, 18:01Вот тут https://github.com/MihailDev/yii2-ckeditor ? Виджет который коммитился последний раз три года назад? Пруф дайте пожалуйста на готовый виджет для свежего рабочего CKEditor4, в котором бы файлы и картинки грузились бы из коробки. Чтобы поставил и забыл.
Хороший ли, плохой, но у меня такой виджет для имперави редактора 2-ой версии работает уже не первый год. Файлы, картинки, грузит, по ctrl + s форму сохраняет, мусор из ФС убирает. Виджет, конечно, не редактор, но в тесной связке с ним.
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
200 бачей? За что? Мухи и котлеты мы уже проходили.
Никаких новомодных штук не нужно для CMS. Для CMS вполне подходит AR - дёшево, гибко, и в случае с Yii, быстро. Остальное от лукавого.
Я недавно сам проектировал слои для своей старенькой недоCMS, думал, мол как красиво всё пишется, но... Сложности возникают чуть более быстро, чем сразу. Репозитории, DDD и т.п. не про CMS. Итог - AR, лучше и гибче пока не придумали. Да и конечному пользователю плевать, что у Вас там в коде. Главное результат.
Но вернусь к тому, как сказали выше, что CMS это типо не то. Так вот CMS никуда из реалий не денутся, т.к. простые проекты, или даже проекты с горящими сроками надо делать быстрее, и всякие обвязки писать не особо хочется. Да и поддерживать проекты, созданные в большей степени на одном продукте удобнее, как ни крути.
И да, сколько бы ни было хейтеров Yii, стоит принять то, что адептов Yii так же много, и фреймворк далеко не плох. Монолит не означает, что он плохой и нерасширяемый. Так что явно когда то появится достойная CMS на Yii, не боги же горшки обжигают.
Но... Хороший продукт на Yii, на мой взгляд, это только опенсорс и никак иначе.
Как то так. Я всё.
Никаких новомодных штук не нужно для CMS. Для CMS вполне подходит AR - дёшево, гибко, и в случае с Yii, быстро. Остальное от лукавого.
Я недавно сам проектировал слои для своей старенькой недоCMS, думал, мол как красиво всё пишется, но... Сложности возникают чуть более быстро, чем сразу. Репозитории, DDD и т.п. не про CMS. Итог - AR, лучше и гибче пока не придумали. Да и конечному пользователю плевать, что у Вас там в коде. Главное результат.
Но вернусь к тому, как сказали выше, что CMS это типо не то. Так вот CMS никуда из реалий не денутся, т.к. простые проекты, или даже проекты с горящими сроками надо делать быстрее, и всякие обвязки писать не особо хочется. Да и поддерживать проекты, созданные в большей степени на одном продукте удобнее, как ни крути.
И да, сколько бы ни было хейтеров Yii, стоит принять то, что адептов Yii так же много, и фреймворк далеко не плох. Монолит не означает, что он плохой и нерасширяемый. Так что явно когда то появится достойная CMS на Yii, не боги же горшки обжигают.
Но... Хороший продукт на Yii, на мой взгляд, это только опенсорс и никак иначе.
Как то так. Я всё.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
Я помню вы там целый зоопарк архитектурных цацек применить собирались.
Что из них при столкновении с практикой и реальными хотелками по функционалу сразу начало создавать трудности и превращать работу в разгадку пазлов, ну т.е. таких проблем, решение которых не нагуглишь легко?
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
Некоторые из цацек остались, такие как сервисный слой, сущности (правда на уровне AR), но пришлось отказаться от репозиториев в принципе. Дело в том, что для CMS нужно иметь гибкость в выборке, что не получилось сделать очень красиво (возможно это у меня не получилось). AR не могу назвать так же изящным решением, но для проекта, где нет чёткой структуры - такая реализация накладна по времени. Пазлов не было, просто есть факт, что изначально выбранный вариант не подошёл по ряду критериев, по мере роста стало тяжко это всё соединять воедино.maleks писал(а): ↑2018.01.15, 10:36 Я помню вы там целый зоопарк архитектурных цацек применить собирались.
Что из них при столкновении с практикой и реальными хотелками по функционалу сразу начало создавать трудности и превращать работу в разгадку пазлов, ну т.е. таких проблем, решение которых не нагуглишь легко?
А всё из-за чего (имхо)? А из-за того, что нормализованная структура реляционной БД довольно тяжело ложиться в рамки репозиториев. С денормализованной, как например в UMI и ей подобных, мне кажется несколько проще всё, хотя опять же не сахар. Если вы понимаете, о чём я - то сразу всё станет ясно.
Посему скажу так: слои по канонам и реляционка, лично в моём понимании и восприятии того, как это должно выглядеть - плохо укладываются в модели реляционной БД. Я либо отказываюсь от фишек БД (join в моём случае), или соглашаюсь, что для гибкости мне подойдёт AR.
Мне нравятся репозитории, всё лаконично, но по понятным причинам в данном проекте они попросту не подошли.
P.S.: стоит отметить то, что от репозиториев я полностью не отказался, просто они остались там, где они реально необходимы.
P.P.S.: и если гуглить всё то, что собрался реализовать в подобном продукте - то ничего хорошего (акромя собственного профита) из этого не выйдет.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
Похоже на то, что умения не хватило. Не встречал, чтобы "join" мешал использовать репозитории.
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
Я смотрю вы умелый. Что же. Думаю, что такой человек с "умением", как вы сможет мне помочь. Ну, если не секретно, то пожалуйста расскажите, хотя бы в кратце, как мне сделать фильтрацию: хочу получить список клиентов, которые оформили первый заказ минимум полгода назад, причём пользователи должны были зарегистрироваться по ивайту, который имеет тип "приглашение для близкого друга". Стоит учесть, что все 4 сущности имеют свои репозитории, и я хочу иметь возможность сменить хранилище каждого из них. Ах да, и главное - join, ну люблю я джойны и всё.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
Как я и предполагал, вам мешает вовсе не join, а "хочу иметь возможность сменить хранилище каждого из них".
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
Дак а при чём тут хранилище? Оно не должно влиять на API репозитория.
Нравится Yii? Давайте сделаем его лучше!.
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
А в чём смысл репозитория тогда? абстрагируемся над хранилищем, имея единый API.
Ну да. Из этого выливается момент, что в некоторых случаях репозитории могут не подойти. С возможностью смены хранилища у репозитория мы теряем возможность использования специфичных плюшек СУБД (пример выше). Посему можем получить оверхед, который просто не нужен для коробочного решения. Посему и считаю, что для CMS - AR довольно хорош и удобен, особенно реализация AR в Yii.
Если что-то не так понял - объясните пожалуйста.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
Ничего мы не теряем. Репозиторий:
1. Принимает объекты на входе, куда-то их сохраняет.
2. Даёт нам методы для получения одного или нескольких объектов.
Например:
Как мы реализуем интерфейс не важно. Можно в MySQL писать/читать, можно в файлы, можно в сторонний сервис через REST API.
1. Принимает объекты на входе, куда-то их сохраняет.
2. Даёт нам методы для получения одного или нескольких объектов.
Например:
Код: Выделить всё
interface ArticleRepository
{
public function saveArticle(Article $article): boolean;
public function getArticle($slug): Article;
public function getArticlesPage($page);
}
Нравится Yii? Давайте сделаем его лучше!.
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
Это понятно. Вопрос в другом. Получается, что меняя репозиторий для агрегата мы будем менять и репозитории всех сущностей из агрегата. Т.е. просто заменить репозиторий одной сущности мы не сможем по причине нахождения в нём специфичных запросов, вроде JOIN фильтрации по полям дочерних сущностей. Либо делать без Join в угоду гибкости в плане смены хранилища.samdark писал(а): ↑2018.01.18, 22:17 Ничего мы не теряем. Репозиторий:
1. Принимает объекты на входе, куда-то их сохраняет.
2. Даёт нам методы для получения одного или нескольких объектов.
Как мы реализуем интерфейс не важно. Можно в MySQL писать/читать, можно в файлы, можно в сторонний сервис через REST API.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
Не должно быть репозиториев для отдельных сущностей, если они не имеют смысла без агрегата.репозитории всех сущностей из агрегата
Нравится Yii? Давайте сделаем его лучше!.
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
Вот именно. Поэтому в экосистеме CMS репозитории могут не дать ожидаемого эффекта. А гибкость для CMS - это важная деталь.
Собственно о чём я и говорил выше про репозитории для сущностей пользователя, заказов и товаров. В CMS это могут быть самостоятельные сущности, т.к. разные модули: пользователи, каталог и магазин, которые могут существовать отдельно, ну как минимум 2 из них, по крайней мере. Поэтому будет 2 репозитория и для CMS их связать будет довольно тяжело и станет это лишним оверхедом.
Опять же если не прав - поправьте пожалуйста.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
Ну да. Всё так. К CMS простой DDD прикручивать нет никакого смысла.
Нравится Yii? Давайте сделаем его лучше!.
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: Как правильно выложить свое приложение, если есть лицензионные ограничения
Именно на этом я и обжёгся. В итоге оставил только командную шину и сервисы. С БД справляется прекрасно AR. Да и замечаю, что AR стали недолюбливать, считая, что всё по канонам должно быть. И приходим к тому, что CMS'кам просто не оставляют места в мире веб. А зря. Хорошая CMS уж явно не станет узким местом проекта, во всяком случае на большинстве типовых проектов. Скажем так, у CMS есть свой цикл жизни в проекте. И этот цикл вполне может быть бессрочным.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x