Добавить системные плагины Не принято

5

Приветствую!

Пробежался тут по перечню приложений в магазине WA и задумался... Поставил все в облаке - иконки приложений занимают 3 строки... Идем дальше. Всего в магазине WA на данный момент 33 приложения. При этом 17 из них, на мой субъективный взгляд, приложениями-то вовсе и не являются, т.к. не имеют своего функционала, а лишь расширяют функционал других приложений (тут формулировка может не совсем точна, но, надеюсь, понятно о чем речь). Идем дальше... Если отсортировать приложения в магазине WA по новизне (надеюсь, сортировка корректная), то увидим что из последних 20 (двадцати) приложений приложениями по своей сути являются только 3 (три). Вангую: приблизительно такое соотношение сохранится и в дальнейшем, что приведет в итоге к абсолютному бардаку в навигационной панели админской части.

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


21 комментарий

  • +2
    И я так и не увидел адекватного реального примера системного плагина.

    версия для слабовидящих например.

  • +1

    не забывай, что у системных плагинов нет UI. Ну, с оговорками, конечно некоторыми.

    Поэтому "Лок-сайт" например придется активировать-деактивировать написав еще и плагин, например, к Сайту.

    P.S. Хотя на самом деле есть такие приложения, которые как суслик. Их никто не видит, а они есть. :) Ну например приложение 'webasyst' которое по всем признакам приложение, со своим конфигом, но расположено в wa-system. :)

    • +1
      не забывай, что у системных плагинов нет UI. Ну, с оговорками, конечно некоторыми.

      А это, на мой взгляд, как раз из области "подумать и проработать"

      • +1

        а как у них может быть UI, если Smarty необязательно? Я тут делал на пробу приложение с php-шаблонами. Работает.

        • +1

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

          • +1

            Приложение, по идее, можно использовать как контейнер для общих библиотек. Но тогда надо от Вебассиста получить разрешение публиковать такие плагины, которые объявляют явную зависимость от других/нескольких приложений.

            Например "Фоторедактор"

            приложение пока интегрировано только с приложением Shop-Script 6

            ну это плагин для Shop-Script. Просто они расшарили библы и часть интерфейса для того. чтоб потом быстро встроить его к другим приложениям.

            Надо как сделать: скрытое приложение Фоторедактор (скрытое в смысле в верхнем меню не появляется) + плагин к Магазину, требующий установленного "Фоторедактора". + плагин к Фото, требующий установленного Фоторедактора.

            Хочешь за все деньги бери, хочешь только за приложение, хочешь наоборот -- за каждый плагин, а приложение бесплатно.

            Все это, в общем-то, в основном для облачников. На standalone можно напихать разных библиотек так, что они не будут при обновлении затирваться. И ваяй плагины, какие хочешь.

          • +1

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

          • +1

            Уже не раз об этом говорили, кроме описаных вами проблем, еще есть проблема с необходимостью дублировать плагины для разных приложений. А в ситуации если у меня свое приложение, но я хочу в нем использовать плагины (например оплаты и доставки) которых для него нет и не будет, так как оно не будет скорее всего опубликовано, что мне делать в таком случае? А если будет 20 приложений, что те же самые плагины оповещения нужно будет дублировать отдельно для всех этих приложений. Короче с моей стороны ситуация несколько бредовая, хотя на начальном этапе вебассист и шопскрипт очень интересно выглядят, но как только нужно расширить функционал, сразу начинается костылестроение.

            Мне кажется что создавая архитектуру WA проектировщики больше ориентировались на свое удобство нежели

            • +2

              Плагины оплаты и доставки как раз общие вообще-то для всех приложений, и они лежат даже в папке wa-plugins, а не внутри приложения магазин.
              Нет плагина оплаты только для Shop-Script, они все системные и их можно использовать в любых приложениях.

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

              • +1

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

                Плагины: кнопки вверх, мигалка, защита контента... и т.д. мне по всем плагинам пройтись? Да я понимаю, что например кнопка вверх и на плагин не тянет, можно добавить код в тему оформления. А где же мигалка для приложения хаб, где для него защита контента? А где мигалка для поддержки?

                А по поводу конструктивизма, давайте будем конструктивны взаимно) обратите внимание https://support.webasyst.ru/forum/7501/uluchshenie...

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

                P.P.S. Еще бы устанавливались сроки исправления ошибок в плагинах и приложениях вообще бы отлично было бы, не приходилось бы по 1,5 года оттягивать запуск магазина.

              • +1

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

                • +1

                  Джентльмены обычно верят друг-другу на слово (из известного анекдота) ;))

                • +1

                  Ну для начала приведите хотя бы один нормальный реальный пример системного приложения. Что оно будет делать?
                  Только не надо писать "посмотрите ваш магазин", давайте конкретнее, где нужен механизм системных плагинов и зачем?
                  Где по вашему будут настраиваться эти системные плагины и вообще что они должны уметь делать?
                  Вот прямо на примере какого-то приложения напишите что изменится и почему станет лучше, если оно переедет из приложения в некий системный плагин?
                  А то вы проблему обозначили, а дальше написали, сделайте что-нибудь, только непонятно что, как и зачем, а потом удивляетесь, что ваше предложение не принято.
                  Я уже неоднократно говорил, будьте конструктивны и тогда возможно, будет и диалог и какие-то результаты.



                  • +1

                    Ну хорошо, Александр... Может я действительно не прав, ограничившись лишь общим описанием. Вот мое видение всего этого дела.

                    Из нарисованных моей воспаленной фантазией проблем, выделю основные:

                    1. Путаница и неразбериха в терминологии: что есть плагин, что есть приложение
                    2. (скорее даже не 2 а 1.1) Не отсутствие, но проблема с логикой работы с фреймворком в целом.
                    3. Перегруженность панели управления админки при установке хотя бы трети того что есть в магазине.

                    Теперь по пунктам, но все в куче, перемешивая с ответами на поставленные вопросы.

                    Скриншот того что получается если установить все приложения приводить не буду, ибо желающие могут сами посмотреть: 3 строки кнопок. Ну там ведь невозможно ориентироваться... Берем некую Марьванну, и пытаемся ей объяснить что да как да почему: "Марьванна, если вы хотите работать с заказами, товарами - вот приложение Магазин, оно всем этим управляет. Когда у вас вышла ошеломляющая себяшечка, или в простонародье селфи - вот приложение Фото, оно позволяет публиковать ваше творчество. Хотите чтоб страждущие могли и ваше видео посмотреть? Диск вам в помощь! Если вдруг вам соседка чего интересного нашептала - Блог ваше все, ибо именно для этого и предназначен. Не уверены что это прочтут все подруги? Рассылки спасут мать русской демократии. А? Что вы говорите? Устроить голосование в Блоге какая кофточка вам больше к лицу? Не, тут не в Блог надо... Для этого есть отдельное приложение. Нет, у него нет своего интерфейса. Да, чтобы его увидели надо поменять шаблон. Где? Нет, не в самом приложении, в шаблоне Блога. Почему? Не пытайтесь понять, просто запомните." Утрирую? Безусловно. Но в этом и заключается проблема терминологии, функционала и расположения. В моем, осмелюсь предположить худо-бедно адекватном, представлении Приложение - это некая обособленная, независимая программная составляющая фреймворка, которая может обособленно, не завися ни от каких других приложений выполнять какую-то задачу. Не расширять функционал других приложений, а выполнять свою конкретную задачу. Еще проще: я могу установить только фреймворк и это одно приложение - и я получу результат. Конкретный результат, а не возможность его получения в рамках другого приложения, понимаете? Вот в этом, на мой субъективный взгляд, и заключается разница между приложением и плагином. В сложившейся же к данному моменту практике, разница заключается лишь в том, что работать с плагином можно в рамках одного приложения, а в приложении нет таких ограничений, хотя во всем остальном функционал может быть абсолютно идентичен. И это создает бардак в логике, а заодно и в панели управления админки. Собственно в написанном выше размазаны ответы на все ваши вопросы. Но если оставить суть, то:

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

                    Расположение и настройка. Позволю себе небольшое лирическое отступление... :) Александр, не чтоб конкретно вас упрекнуть, а просто обратить внимание на этот момент, не более. Вот вы выше писали:

                    Плагины оплаты и доставки как раз общие вообще-то для всех приложений, и они лежат даже в папке wa-plugins, а не внутри приложения магазин. Нет плагина оплаты только для Shop-Script, они все системные и их можно использовать в любых приложениях.

                    И вроде бы все верно написано, но... Берем свободно распространяемый фреймворк, устанавливаем. Вопрос: а как установить эти общие плагины? В инсталлере они недоступны... Хорошо. Берем триальную версию магазина, ставим, устанавливаем плагины. Но магазин-то триальный... По честному его сносим, встает следующий вопрос: а как настроить эти плагины? Интерфейсов-то нет... ;) Вот и получается, что проблема доступа к настройкам есть и сейчас, просто она не столь яркая и воспринимается как нечто само собой разумеющееся. (если я вдруг ошибся и доступ как к установке так и к настройке есть - прошу простить и рассказать)

                    Ну хорошо, давайте подумаем куда все это дело можно запихать... Мне кажется, из имеющихся на данный момент мест самое подходящее - инсталлер. Только вот какая-то беда с терминологией, которая может повлечь за собой беду с логикой. Ну правда ведь, чтобы настроить какой-то плагин надо лезть в инсталлятор.... Бред? Мне кажется, да, бред. Но позвольте... Мы сейчас в инсталлере помимо установки/удаления всяких прелестей можем также указать название компании, указать адрес сайта, основной EMail, включить debug mode, очистить кэш (который к инсталляции ПО имеет опосредованное отношение), и посмотреть версию Вебасист... Постойте... А что такое Вебасист? Можно облазить всю админку, но ответа на этот вопрос не найдете :) Так может и тут попросту вопрос терминологии? Может если инсталлер назвать не Инсталлером, а, навскидку, Фреймворком, то все встанет на свои места? Ну правда ведь, устанавливали мы фреймворк, и работаем в нем... И, вероятно, логично будет разместить тут помимо возможностей установки/удаления прикладного софта и системных настроек еще и настройки системных плагинов? Не только оплаты/доставки/sms, но и других, которые по сути-то своей плагинами и являются, но в силу технических ограничений попали в разряд приложений :)

                    Хорошо, копнем еще чуть глубже. Приходит Марьванна и глаголит: "А все ж путаюсь я... С кофточкой я определилась, но встал вопрос с юбочкой. Тогда-то я запомнила что мне делать надо, а нынче подзабыла. Куда ж мне идтить-то чтоб новое голосование в Блоге замутить?" И что ж получается? Получается если раньше ее слали на тулбар в псевдоприложение, то сейчас ваще хрен знает куда, в какой-то Фреймворк... Не комильфо? Не комильфо. Как быть? Вопрос занятный и неоднозначный. Допускаю, можно поступить с.о.: дублировать доступ к настройкам системных плагинов в окне с настройками плагинов конкретного приложения. Возможно, снабдить окна настроек системных плагинов соответствующим визуальным сопровождением, обращающем на себя внимание. При необходимости, выносить их в обособленное место (а-ля доставка/оплата в настройках Магазина). Да, вроде бы дублирование не есть хорошо. Но мы ж не буквоеды, и принимаем решение исходя из конкретных условий и ситуации. И, на мой субъективный взгляд, в данном случае такое дублирование вполне оправдано и допустимо. Это позволит конечному пользователю четко понимать в каких случаях к каким разделам фреймворка/приложения ему обращаться, где что искать и чем пользоваться.

                    В сложившейся же практике, имхо, грядет бардачокс как в интерфейсе, так и в понимании... :)

                    Ну как-то так :)

                    P.S. Приношу извинения автору приложения Голосование, которое, насколько я смог с ним ознакомиться, очень интересно, полезно и гибко! Упомянуто всуе исключительно из производственной необходимости :)

                    • 0

                      Я не видел приложения голосование, но вот как бы я его делал:
                      В самом приложении список голосований, возможность создать новое, отчёты и т.п.
                      Далее через хэндлеры сделал бы интеграцию с некоторыми приложениями, например, блог, чтобы можно прямо в блоге добавить голосование к посту.
                      Зачем же оно нужно как отдельные пункт меню в списке приложений?
                      Во-первых, можно создавать голосования, которые работают сами по себе и не привязаны ни к чему, во-вторых, угодно анализировать сразу все голосования в одном месте.
                      Так что это как раз приложение и не вижу тут никаких проблем с логикой.
                      Может кто-то занимается опросами и ему вообще ничего больше не надо.

                      Как я понял вы хотите просто взять и это голосование из списка приложений перенести в инсталлер.
                      И что же от этого поменяется? Я правда не понял, что от этого станет лучше? Только то, что в панели не будет иконки приложения голосование?

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

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

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

                      По поводу плагинов доставки и оплаты, разумеется в каждом приложении будет своя логика настройки этих плагинов, при этом код настройки можно взять из Shop-Script, для нормального разработчика это не проблема. В каком-то приложении, может вообще не быть доставки, но может быть оплата. Это решает разработчик приложения и он же делает где-то у себя внутри приложения раздел с настройками плагина, ничего там сложного нет. Мало того, в магазине есть понятие заказа, а в каком-то приложении может как-такого заказа не быть вообще. Да и callback в каждом приложении свой. Тут никак не обойтись без прослойки между плагином оплаты и приложением.

                      • +2

                        Я пишу плагин Дополнительные поля! Поля могут быть привязаны к страницам приложения сайт, магазин, хаб, фото - в общем везде где есть Экшен waPageActions.action.php.

                        Также для магазина поля еще используются для продуктов и категорий, для блога поля будут использованы для каждого отдельного блога и для страниц, для хаба тоже в отдельных хабах могут быть использованы Дополнительные поля.

                        Концепция такая: я хочу использовать хуки нескольких приложений!

                        Чтобы простому пользователю не пришлось вникать в такие понятия как хелперы, хендлеры и статические методы и он не ставил везде коды вывода сам!

                        Посмотрите на плагин дополнительные поля Лайт, там же код универсальный для любого приложения (для функционала страниц), куда не поставь плагин будет работать на любом приложении.

                        Допустим конфиг такой :

                        return array(
                            'name' => /*_wp*/('AdvancedFields'),
                            'description' => /*_wp*/('bla bla'),
                            'vendor'=>'ya',
                            'version'=>'9796.2.4',
                            'img'=>'img/fields.png',
                            'shop_settings' => true,
                            'site_settings' => true,
                            'blog_settings' => true,
                            'frontend'    => true,
                        
                            'handlers' => array(
                                'shop'=> array(
                                    'page_edit' => 'PageEdit',
                                    'page_delete' => 'PageDelete',
                                    'page_save' => 'PageSave',
                                    'product_edit' => 'productEdit',
                                    'product_delete' => 'productDelete',
                                    'product_save' => 'productSave',
                                    'category_edit' => 'categoryEdit',
                                    'category_delete' => 'categoryDelete',
                                    'category_save' => 'categorySave',
                                ),
                                'site'=> array(
                                    'page_edit' => 'PageEdit',
                                    'page_delete' => 'PageDelete',
                                    'page_save' => 'PageSave'
                                ),
                                'blog'=> array(
                                    'page_edit' => 'PageEdit',
                                    'page_delete' => 'PageDelete',
                                    'page_save' => 'PageSave',
                        
                                    'blog_edit' => 'blogEdit',
                                    'blog_delete' => 'blogDelete',
                                    'blog_save' => 'blogSave'
                                ),
                                'hub'=> array(
                                    'page_edit' => 'PageEdit',
                                    'page_delete' => 'PageDelete',
                                    'page_save' => 'PageSave',
                        
                                    'hub_edit' => 'hubEdit',
                                    'hub_delete' => 'hubDelete',
                                    'hub_save' => 'hubSave'
                                ),
                            ),
                        );


                        Соответственно этот плагин запрашиваться будет приложениями и если есть ячейка handlers['shop'], то магазин будет опрашивать хуки свои. и тд.

                        Плагины будут храниться в папке wa-plugins/system/ допустим.

                        Настройки плагина будут формироваться отдельно для всех приложений .

                      • +1

                        подведем промежуточные итоги.... Прошло 2.5 года. Приложений в маркете уже 57 (не считая unlisted), чтобы соблюсти паритет, берем опять те же 20 последних... И что видим? Из 20 последних опубликованных приложений на гордое звание Приложение претендуют лишь 2-3 (разработчик двух из них Webasyst).

                        Webasyst, вы еще не изменили свое мнение по этому вопросу? =)

                        Добавить комментарий

                        Чтобы добавить комментарий, зарегистрируйтесь или войдите