Новый ManagerManager
Привет! Для начала давайте знакомиться. Меня зовут Ильяс, я руководитель группы компаний DD Group и студии DivanDesign. 12 лет мы создаём сайты на (MODX)EvolutionCMS, от супер-маленьких и простых, до огромных и сложных. В определённый момент решили делиться своими наработками с общественностью и выложили часть в свой репозиторий (пока, к сожалению, там нет и половины всего). В числе прочих, развиваем плагин ManagerManager (не без помощи сообщества, конечно же). Здесь немало текста, но я искренне надеюсь, что вы дочитаете до конца ✌
Давно хочу кардинально переработать ManagerManager, так как его код просто морально устарел. Он разрабатывался так давно, что технологии программирования не выдерживают никакой критики :-) Мы начали работу над плагином лет 10 назад, а основа сделана была и того раньше! Развитие усложнялось ещё и тем, что сам ManagerManager содержит очень много дочерних плагинов (так называемые «виджеты», что по смыслу давно не верно).
Куда хотелось бы двигаться?
Сразу оговорюсь, что обратная совместимость должна быть сохранена если не полностью, то максимально близко к этому. Это может породить ряд компромиссных решений, но наша задача — инкапсулировать код для обратной совместимости.Удобство для разработчиков плагина
Это главная задача, ведь удобный, прозрачный и согласованный единой концепцией код позволит развивать продукт меньшими усилиями. Сейчас там всё плоско и разрозненно, сплошная коллекция антипаттернов программирования, у Стива Макконнела бы волосы зашевелились :-)Рассмотрим наиболее простые и понятные на текущий момент принципы:
- HTML и CSS всегда отдельно от PHP. Нельзя миксовать оформление с логикой даже под страхом смерти.
- JS, написанный прямо в PHP, допустим только в крайних случаях: когда там, условно, одна строчка и иначе никак. В основном же весь JS должен быть в отдельных файлах.
- Избегание дублирования кода любыми средствами.
- ООП. Комментарии, думаю, излишни.
- Компоненты системы («виджеты») не должны напрямую взаимодействовать с CMS, только через ядро плагина.
- Передача параметров по имени, а не по порядку (pass-by-name). Да, даже в PHP. Это повышает читабельность кода, а читабельность кода — наше всё.
- Противодействие не предусмотренному использованию ядра плагина и его компонентов. Никаких чёртовых глобальных переменных и прочих уязвимых для грязных хаков моментов. Использование недокументированных особенностей сторонними разработчиками так сильно вставляет палки в колёса развития продуктов, что даже описать сложно! Там столько костылей порождено из-за этого, что смотреть больно.
Конечно, этот список не претендует на полноту, сейчас он здесь лишь для того, чтобы передать вектор мыслей. Над этим ещё предстоит поработать в процессе, об этом ниже.
Жёсткий стиль кода
Для эффективной работы, разработчики не должны отвлекаться на всякую шелуху, не имеющую отношения к логике продукта. Нам нужен единый, тщательно описанный и жёсткий стиль кода, чтобы один программист не создавал «кочки», о которые будет запинаться другой.Представьте книгу, в которой каждое предложение набрано разной гарнитурой штифтов: Times New Roman соседствует с Comic Sans, Helvetica и ещё 500 другими. А теперь представьте, что каждое слово набрано разным размером шрифта. Ну и чтобы совсем было круто — каждая буква своим уникальным случайным цветом. Классно? Может я только что придумал произведение современного искусства, но читать эту книгу будет категорически неудобно. Ну ладно, читать. А теперь представьте, что над ней работают сразу 10 авторов и прямо сразу в процессе пишут со всем тем цирком, описанным выше. Спорим, они застрелятся раньше, чем выйдет книга? ;-)
У DD Group (моей компании) за 12 лет создан и по крупицам доработан стиль кода, связанный общей философией и часами горячих споров. К примеру, проработан в том числе общий принцип построения имён (переменных, методов, файлов, страниц документации и т. п.). Сразу хочу пресечь деструктивные дискуссии по этому поводу: стиль кода будет наш. Точка. Нет времени на бесполезные религиозные дискуссии с применением писькоизмерительных инструментов.
Документация для разработчиков
Чтобы все мы говорили на одном языке, а сердца наши бились в унисон — программистам нужна документация для программистов.Надо не лениться и подробно описывать всё на свете. Программисты склонны к высокому контексту и слабому документированию своих великих шедевров, так что стремление к максимализму в противоположном направлении — самое оно. И здесь я говорю не о комментариях в коде (о них будет в стиле кода), а об отдельной от кода документации.
Описываем внутреннюю структуру продукта и логику взаимодействия. Каждый класс, каждый метод, что к чему и почему. Все идеи, дух и философию продукта. А также изначальные компромиссы, проблемные моменты и хрупкие места.
Документация будет в формате Markdown.
Отдельный чат именно для программистов, работающих над плагином
Нужны эффективные коммуникации строго по теме, но чтобы не перегружать лишними сообщениями. Вход открыт всем желающим, но оффтоп будет нещадно удаляться.Пользователи — не программисты
Сейчас плагин написан программистами для программистов. Необходимость уметь программировать и писать PHP-код в правилах плагина — отстой. Всё должно настраиваться совершенно каузально, кликая мышечкой в интуитивно-понятные интерфейсы, попивая смузи и параллельно крася ногти за рулём. В идеале, для использования плагина не должна быть нужна документация вообще.Отказ от идеологии правил
В топку правила! Да, правила — это гибкость, но эта гибкость в 90% случаев не востребована, а проблем из-за неё много. Ну не нужны разные представления для одной и той же TV в разных шаблонах и у разных ролей — поддерживать это в долгосрочной перспективе становится больно. Ну заведи ты ещё одну TV и не парь мозг, зачем экономить на их количестве? Это экономия на спичках, выходящая боком.Ну ладно, а как тогда?
Почти сразу, те самые лет 10 назад, мы разработали модуль для редактирования правил ddMMEditor, но:- Это отдельная сущность, а люди не любят устанавливать кучу разных вещей и вникать в них. Да и правильно, не стоит плодить сущности без необходимости.
- Это всё равно те же правила MM, только с автозаполнением и прочим сахаром. Проще, чем правила в коде, но всё равно не достаточно.
- Создавался программистами без дизайнера. А без дизайнера нельзя.
Вместо этого мы должны интегрировать интерфейс настройки плагина прямо в CMS. Должно быть нативно и без лишних сущностей: создаёшь/редактируешь TV и прям там же ставишь галочку «Обязательно для заполнения» — всё, TV будет обязательна для заполнения, без единой строчки кода, без дурацких правил и лишних сложностей в виде ролей и разных шаблонов. Прямо там же выбираешь, что это не просто TV, а Яндекс.Карта, к примеру, там же настраиваешь количество колонок, ресайзы изображений и всё прочее. Что может быть проще, понятней и удобнее? Ну и всё в таком стиле, всё интегрировано в CMS, всё настраивается интуитивно, не требуя ни малейших навыков программирования.
Ещё раз напомню, что обратная совместимость с динозаврами должна быть сохранена, так что любители обмазаться коддингом должны быть довольны ;-)
Звучит неплохо, дайте два!
Полагаю, вы хотя бы примерно можете представить объём работы. Причём, характерные для Open Source постулаты «работает и ладно», «сделаем на скорую руку», «нам же никто не платит» — не допустимы. На первом этапе нужна тщательная профессиональная подготовка программистом, не младше сеньора и организатором: документация, проектирование, формулирование идей, организация работы и построение коммуникаций.Потянуть это кому-то одному ну просто не по силам. Все мы хотим кушать и жить, на одном энтузиазме и борьбе за идею далеко не уедешь, а окупить всё это дело одному разработчику или даже команде не возможно. Так что, дамы и господа, если это кому-то интересно, давайте кооперироваться.
Каков план?
- На текущий момент мы набросали сырой-пресырой концепт. Внимание, это точно не рабочий код, он толком не тестировался!
- Дальше надо протестировать текущий код, довести его до рабочего состояния в текущем виде. По возможности, пока что не вмешиваясь в код конкретных «виджетов». Пусть пока местами не совсем красиво и с кучей компромиссов, но это будет уже рабочий плагин с новой структурой ядра и старыми «виджетами».
- Затем надо подготовить документацию, описание стиля программирования и прочие организационные моменты.
- Далее перепилить все «виджеты», попутно дорабатывая структуру ядра плагина.
До этапа № 3 никто нам помочь программированием не сможет. Нужны стандарты и документация, что позволит далее подключиться без боли большому количеству людей на 4 этапе.
Но что сделать прямо сейчас?
Поддержать рублём
Сейчас мы вложили своих 70 тысяч рублей, но больше прямо сейчас не можем. Чтобы быстро дойти до 4 этапа, призываю вас поддержать проект рублём (там простая форма, можно отправить с карты любого банка). Сколько надо собрать денег? Да не знаю, честное слово ¯\_(ツ)_/¯Страна должна знать своих героев и чтобы подстегнуть интерес — все частные лица и компании, отдавшие свои кровные на поддержку общего дела будут «высечены в камне». По желанию, на страницах плагина (и в GitHub тоже) и будут размещены фотографии/логотипы, имена/названия и ссылки на всех доноров. Навсегда. То же самое будет во всех статьях по новому ManagerManager. Если вы разработчик или студия — это реклама и уважение сообщества. Если вы не разработчик, но ваш сайт на EvolutionCMS — то там скорее всего используется ManagerManager и мы вам тоже рады, это вклад в общее дело и выиграют от этого все. Для бизнеса несколько тысяч или даже десятков рублей — это копейки, а пользы будет много и навсегда: вашим людям будет проще работать, доработки сайта будут делаться быстрее и все вложенные средства окупятся слихвой.
Пожалуйста, при пожертвованиях подписывайтесь, чтобы я мог с вами связаться, поблагодарить и увековечить (в идеале — ссылку на контакт в Telegram, но подойдёт что угодно).
Если мы с вами добьёмся успеха, плагин ManagerManager навсегда останется бесплатным и открытым.
Распространить информацию
Если вы разработчик или студия — попробуйте замотивировать клиентов пожертвовать копейку на благое дело, ведь им это тоже выгодно! Доработки их сайтов станут дешевле. Скиньте ссылку на пост или просто скопируйте какую-то его часть, если так удобнее.Запостите ссылку на пост в соц. сетях, профессиональных сообществах, форумах, у себя на сайте — да где угодно.
Также можете смело копировать и распространять текст этого поста целиком или частично, в изначальном виде или с вашими комментариями — чувствуйте себя полностью свободно.
Помочь перевести пост на английский
Сам не имею возможности сделать этого, к сожалению, а сообщество у нас не всё русскоязычное. Свяжитесь со мной в Telegram (@Ronef).Выразить желание помочь с программированием в будущем
Постараюсь организовать всё так, чтобы всем участвующим в процессе было максимально просто и комфортно. Сейчас важно заявить о себе, чтобы мы чувствовали, что дело нужное и команда будет. Пишите мне в Telegram (@Ronef).Выразить желание помочь с тестированием будущего продукта
Нам будут нужны тесты, много и разных. Заявить о вашем желании быть бета-тестером нужно для того же — чтобы мотивировать разработчиков. Также пишите мне в Telegram (@Ronef).Если всё это зайдёт и сообщество нас поддержит — с радостью поспособствуем экстраполяции всего доброго и светлого на всю нашу любимую EvolutionCMS, от чего все только выиграют. Если конечно высокомерие, гордыня и интриги не помешают. Не хочу ни про кого говорить плохо, но, увы, сообщество сейчас — как дети малые. К примеру, один из ведущих разработчиков ни разу в жизни не использовал ни один наш продукт только потому, что они имеют префикс «DD» :-| Его это напрягает, блин. Вместо того, чтобы развивать совместно общими усилиями продукты, люди предпочитают изобретать велосипеды. Я вкладываю столько своих ресурсов и ресурсов команды на благо общественности, что хочу иметь возможность подписывать свои продукты и не считаю это нарциссизмом, а дурацкое ребяческое соперничество и отношения к коллегам, как к конкурентам, считаю глупостью и не дальновидностью, растлевающей сообщество. Очнитесь, нам нечего делить! Мы конкурируем не между собой, а с Битриксом, который сожрёт нас, не моргнув, пока мы тянем канат в 120 разных сторон. Да почти сожрал уже, EvolutionCMS знает полтора землекопа, а заказчиков приходится уговаривать. Вот оно, чего мы добились! Надеюсь, все мы можем повзрослеть и двигаться дальше, со своей стороны готов идти навстречу и совместными усилиями менять климат на позитивный лад. Прошу прощения, если кого обидел или чем-то задел, не этого я хотел добиться ✌
Может быть вообще интегрируем в итоге плагин прямо в CMS, если они будут готовы к совместной жизни (сейчас пока нет).
Почётные доноры
Благодаря этим прекрасным людям и компаниям плагин ManagerManager будет развиваться дальше. Для всех нас. Давайте дружно скажем искреннее человеческое спасибо людям, сознательность которых заслуживает похвалы!Первого донора, руководителя студии «Dva Kota» пришлось даже уговаривать дать разрешение на размещение этой благодарности, он говорил: «Ильяс, да не надо, я от души же! Не для рекламы же скинул благодарность, а потому что твои решения помогли мне заработать». Однако, я считаю, что сообщество должно знать своих героев в лицо!
Оригинал статьи на всякий случай.
46 комментариев
Ну сделали — молодцы, развиваете параллельно тот же функционал, который давно есть в MM. Хотя с моей точки зрения, куда как продуктивней было бы развивать MM совместно до правильной логики, а не тупо копировать его функционал. Просто пища к размышлению: Какая мотивация у меня, как у разработчика дополнения для Evo, его развивать, если разработчики движка говорят «надо выкинуть MM» и просто копируют все идеи, в которые я вкладывался и предоставлял сообществу совершенно бесплатно? Просто все мои старания обесценивают таким образом. И тут речь даже не про MM, а про общую температуру по больнице. Это не сильно здоровые отношения друг к другу, на мой взгляд. Хотите всё сделать сами, но лишь бы сами — да пожалуйста, мне бадаться с кем-то и в чём-то убеждать нет смысла.
Вот есть у меня уже 10 лет классные многоуровневые комментарии на аяксе (пример работы можно посмотреть там же у нас в репозитории: code.divandesign.biz/modx/managermanager/0.6.2#commentid=540). Чтобы выложить это всё в публичный доступ, причесать и написать документацию, а потом ответить на вопросы и помочь людям — надо вложить тысяч 30–50 минимум. А ради чего? Ради того, чтобы разработчики движка всё равно сказали: «Мы не будем пользоваться этим, потому что там префикс „DD“ (условно), а вместо этого возьмём и напишем то же самое»? Пффф, да мне даже пальцем шевелить не хочется от такого отношения.
Причём, таких примеров целый миллион, когда у нас уже было решение, оно было выложено в публичный доступ, с документацией, прмерами и всем прочим, а его не использовали сами же разработчики движка, потому что префикс «DD». К примеру, тот же сниппет «ddIf» появился раньше, чем его собрат «If». Вместо того, чтобы поддержать и развивать наше дополнение, взяли и сделали другое такое же. И таких примеров просто масса. Не поленитесь, изучите code.divandesign.ru/modx ради интереса.
И это я ещё не касаюсь того момента, когда предустановленных продуктов в CMS только росло и росло с каждой новой версией, а наш ни один не принимали, хотя тему я поднимал несколько раз. Потому что, блин, префикс «DD», понимаете? Потому что дурацкая ребяческая конкуренция и нежелание носа поднять дальше своих разработок: «Зачем мне ваши смотреть, я проще своё такое же напишу». Вот это убивает.
опять же, это не хейт, не «желчь» как ты писал. А всего лишь вид со стороны на большой текст в котором никаких конкретных планов, только мысли вслух. Опиши картинками) планами) и возможно сообщество подцепит идею ;) как это всегда делал Димка
Именно MM и был взят как идея и уже потом реализовалась в последних версиях. А как вы до этого решали эту проблему или желание сгруппировать?
Как понимаю, это типа ваша благодарность за то, что вам когда-то было удобно и хорошо.
Вот такое токсичное поведение и растлевает сообщество. Вместо того, чтобы поддерживать друг друга, помогать (или хотя бы тактично промолчать), мы токсим и убиваем мотивацию друг друга.
Для меня MM — незаменимый инструмент и я такой далеко не один. Не нужно вам — никто не заставляет же. С кем и о чём у вас там давно речь идёт — понятия не имею, как пользовался MM 100 лет, так и пользуюсь, наравне с кучей людей и таких речей ни с кем не вёл.
Желаю вам добра и поменьше желчи ✌
Во-вторых, все плагины, получается, — это костыли? :-) Кое-что добавили в Evo, но кое-чего и нет (Яндекс.Карты, множественные поля и т. п.). Да и не вижу смысла всё в ядро совать, принцип плагинов вполне себе хорош и гибок.
На счет бабок — дохлый номер( ребята на эво 2.0 спрашивали — голь полная(((
Но во-первых свяжись с Серегой, он дела новый интерфей, во вторых мне в личку напиши, я сейчас пишу новую cms на основе эвы, может помогут решения.
И да — ты крут!!!
И теперь вырисовывается явный разброд мнений, что же с этим делать дальше. Снова отдельный плагин или все же доработка того, о чем напрочь было забыто.
Думаю, на вопрос «Нужна ли Evo гибкая настройка ролей, включающая себя в том числе и настройку внешнего вида» — все ответят однозначно — ДА!
Важно ли какой при этом префикс будет у некоторых файлов? — однозначно НЕТ!
Я просто хочу, чтобы разработчики стали единой командой. И то, что одни не делают, но готовы сделать другие, стало бы возможным вопреки всем разногласиям. Иначе вы дружно похороните Evo.
И да как альтернатива данному топику написал вот этот: modx.im/blog/kraudfanding/5903.html
И с учетом некоторых вещей таких как скорость работы и отсутствия визуальных багов (когда мы видим как скрываются поля в ManagerManager) я в решении что по ссылке вижу больше перспектив, да и постарался описать почему.
+ Опять же разделение мух от котлет дает пользу: — не вижу смысла на 1 плагин вешать и работу с визуальной частью и с кастомными ТВ тем более что вторые давно реализованы из коробки. Это как минимум соответствует принципам SOLID
А что конкретно реализовано из коробки с кастомными ТВ? Может я что-то упустил, как из коробки делается вот такое:
skrinshoter.ru/s/290419/OUWAQdds?a
Единственный + только в наличии пакетной загрузки картинок, но когда много картинок логичней использовать SimpleGallery.
Еще раз повторюсь что логично отделять одно от другого это даст больше свободы. Никто не мешает все что есть в МанагерМанагер из кастомныхТв переделать в полноценные кастомныеТв.
МультиТВ — по многим причинам менее удобен, чем ManagerManager. Но это мое ИМХО. Я давно отказался от мультиТВ и мог бы расписать почему. А теперь, когда с ваших слов следует, что кастомные ТВ из коробки реализованы, мультиТВ даже не стоит упоминать.
Так что взамен? Как реализовать то, что на скрине «из коробки»? Я не понял. Или «из коробки» — это безальтернативный возврат к мультиТВ?
Кстати СимплГалери нормально работает и с манагерманагер и с темплатесЕдит ни разу проблем не встречал.
Так же напомню что никто принудительно не ломает манагерманагер. Да что говорить даже Дитто до сих пор работает хотя есть хорошая альтернатива.
Суть Ево это развитие без поломки обратной совместимости.
То что на скрине мне не нравится ибо там зачем то все в синих тонах а не в стиль админки. Ну а использовать как и использовали кто вам мешает поставить ММ если он вам так нужен?
Вобщем, я понял, «в коробке» в данный момент нет ничего, что сходу могло бы дать подобный функционал. Либо ставить старое, либо программировать.
Причем в конфигурации плагина указана только одна роль, для которой запускается этот плагин, но для всех остальных ролей она все равно отрисовывается, правда без содержимого.
— добавить в конфиг переменную
— проверять если роль которая не выводить то просто return;
Но проще ж говорить что плохое решение и не работает, вместо того что б потратить 5-10 минут и сделать что б работало
— одним опенсорсом сыт не будешь, поэтому нужно работать и логично что все поступающие задачи разными путями ставятся в приоритетности важности. Тоесть если клиент пишет о какой то задаче это на это выделяется куда больше внимания чем на просьбу по опенсорсу.
Так как задач разных много то те которые не важные то они не всегда попадают в список дел и в задачи на будущее, таким образом я банально не помню о том что кто то что то просил и перерывать половину сообщений как то делания нет.
Далее когда у меня есть время на опенсорс я первым делом решают те задачи которые ставил сам и после захожу на гитхаб и смотрю что бы еще сделать оттуда. Ибо я знаю что постоянно всем говорю что если вам что то нужно или где то есть баг то пишите на гитхаб.
Подводя итог:
— у меня будет больше времени на написание кода если все задачи будут в одном месте
— кто то еще кроме меня может поделится решением или дополнить информацию о баге
— нет необходимости мне следить за всеми каналами кудой могут написать( модхим, модхру, фб, вк, телеграм, слак, и тд )
— если не написали на гитхаб значит не так вам и надо.
Думаю любой автор опенсорса подпишется под этим.
Только у меня сложилось стойкое впечатление, что в отношении ММ есть нюансы.
Мне как пользователю без разницы, будет это ММ или TE. Главное, чтобы не вышло как у лебедя, рака и щуки.
prntscr.com/mz7ch3
prntscr.com/mz7cz5
перемещение, вкладки, порядок и прочее.
Но осталось ещё очень много:
Как встроить карту в TV для выбора места?
Как скрыть от отдельных пользователей секцию с TV
Да можно сделать свой отдельный плагин, который это реализует, но зачем, если есть готовый набор полезных решений.
Посмотрите весь список:
code.divandesign.ru/modx#tags=Plugins
Может и не стоит в новой версии повторять уже имеющийся функционал, но и того, что ещё нет в системе пока довольно много.
Да и сама мотивация, что кто-то делает что-то на благо системы должна поддерживаться, а не встречать претензии.
Вы скидываете скришоты последних возможностей движка, котоыре в MM были реализованы лет 10 назад и при этом обзываетесь костылями? Продолжайте в том же духе, просто копируйте всё, что есть в MM прямо в движок, а я постою в сторонке — не вопрос. Стараться что-то делать, чтобы потом тебя грязью поливали и твои решения костылями называли? Пффф, из бисера лучше украшения делать, чем метать его.
Удачи и всего доброго! Более не намерен отвечать ни на один ваш комментарий. Похоже, что разговаривать с вами не о чём.
Ильяс, пользуясь случаем — спасибо вам и «Диванам» за публичные решения и, самое главное, отличную документацию. Рад бы надонатить, да пока не складывается =)
Только за один типограф вам нужно памятник поставить! (ну и автору типографа, конечно, тоже)
Я думаю их больше, просто нет никакой рекламы. Все кто тут есть — зашли случайно и по сути — это единственный живой ресурс. Вся популяризация движка происходит внутри «эко системы» где и так одни фанаты, а во внешнем мире тишина.
Очень не удобно при нынешней системе с двоеточиями/палками добавлять новые столбцы в такие параметры, особенно если он не в конец, а в середину добавляются, и в сниппетах потом отсчитывать нумерацию этих разделителей вмето того, чтобы просто работать с ассоциативным массивом.
В принципе, использую этот компонент в оснвном по той причине, что успел в свое время встроть его в дофига сайтов. И заказчикам обычно нравится пакетное заполнение, плюс выглядит красиво.
mm_ddMultipleFields
JSON есть в планах и это будет раньше переработки ManagerManager, о которой написано в статье. Но пока руки не доходят. Можно придать ускорения донатом ;-) Если что — пишите в Telegram @Ronef.
ManagerManager
По поводу большой работы по ManagerManager, описанной в этой статье: к сожалению, пока что мы не почувствовали интерес сообщества к ней, было всего пара доноров. Да и руководитель Evolution CMS почти сразу после этого поста пишет пост «Долой ManagerManager», что как-то не мотивирует работать, если честно. Так что активную работу по задаче пока поставили на паузу, но не бросили совсем — занимаемся, но в пассивном режиме.
Переделали формат хранения mm_ddMultipleFields на JSON и ещё кое-чего в нём сделали.
Новая версия уже в ветке develop MM: github.com/DivanDesign/EvolutionCMS.plugins.ManagerManager/tree/develop.
Подробнее почитать, что сделали в mm_ddMultipleFields здесь: github.com/DivanDesign/EvolutionCMS.plugins.ManagerManager.mm_ddMultipleFields/blob/master/CHANGELOG_ru.md.
Если будут вопросы — задавайте в Телеграм-чате dd_code. Туда же автоматически приходят уведомления обо всех обновлениях наших продуктов.
* Структура сохраняемого JSON подробно описана в README.
* Для вывода рекомендуется использовать ddGetMultipleField >= 3.5.