Shopunity в админке - это что такое?

http://easycaptures.com/fs/uploaded/1015/4418574651.png

Что это? Зачем мне это?
Где правило одного клика?

Не ищите в моих словах скрытого смысла, если я назвал CDN облаком так оно облаком и осталось (Content Delivery Network for Cloud Platform). Да?

 

Ну "1 клик" это образно говоря вы можете установить все файлы нажав одну кнопку. Конечно нужно дойти до этой кнопки - предварительная настройка. Это неизбежно. Можно назвать в "3 клика"))) наверное так будет правильнее.

Главная идея что рядовой пользователь не должен думать об FTP или о ZIP файлах. Его не должно волновать правильную ли он версию устанавливает и все ли файлы он закачал. В этом и заключаете единственная задача Shopunity.

Как Вы могли прочитать выше - я Вас не уговариваю. Я лишь отвечаю на Ваши вопросы) Видимо они у Вас все еще остаются.

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

Shopunity - это всего навсего дистрибутор пакетов. Его единственная задача установить модуль и все зависимости по инструкции которую задает сам разработчик. И точка. Все что сверху создается для удобства и не более.

Удачи!

 

Я еще раз повторяю, потому что не услышан.

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

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

Нет же.. вы сначала меня заставляете подключиться.
Рисунок вам в помощь.

 

Я Вас понял. Мы работаем над этим и возможно в ближайшее время некоторые вещи мы откроем для просмотра, которые не требуют данных юзера. Это вполне разумная идея - и кстати Вы уже сегодня можете увидеть все наши модули и связи зависимостей по адресу https://shopunity.net/marketplace - наверное подобное вы бы хотели видеть в самом модуле? Если да - то это уже в разработке.

 

Когда я веду беседу по теме, то я должен понимать, о чем я веду веду беседу, я уже давно это по несколько раз пересмотрел, в том числе и демо, и.. даже смотрел в ваш код.. (это отдельная тема)

зы
(это отдельная тема)
Не ломайте систему прав и путей oc23.. в угоду себя.
Вы же своим модулем нарушаете соглашения.

принято расширения иметь в extеnsion - значит они там должны быть. ТАМ и нигде иначе.

Вы наверное еще в тройку не смотрели, так там вообще ограничения на запись в папки. Тоже будете ломать?

 

С тройкой мы знакомы, и кстати мы те кто выбил необходимые права для разработчиков для папок system/vendor и PSR autoload. но это отдельная тема.

Наши модули все соблюдают правила опенкарта. До 3 не было ни слова о том что модули обязаны быть в папке Extension. Это новое требование которое Дениэл ввел для 3 чтобы упорядочить код и в новых версиях мы конечно планируем учесть это.

Опять таки к Shopunity это не имеет никакого отношения. Вы как разработчик в праве соблюдать эти правила или нет. На сегодняшний день Shopunity разработан под требования Opencart 2.x и по нашим требованиям.

Я могу вам детально объяснить по каждому нашему решению если хотите.

 

В 2.3 добавлено событие для совместимости папок. потому и нет таких жестких требований.
Не по теме разговор.

Имея собственный инсталятор, несложно разбросать свои собственный файлы по местам
И доступ к моделям, методам, языкам все делается, через два три метода, которые могут быть в вашем fw


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

 

Вы не ошиблись, мы действительно продвинутые

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

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

Тем не менее для пользователя это не несет никаких неудобств так как работа модулей от этого совершенно не зависит. Для разработчиков это так же не имеет никакого значения. Это исключительно пожелание Дениэла и в целом логичное хоть и болезненное. Поэтому он и сделал этот процесс в два этапа - 230 как деприкейтед а в 3 - как обязаловка)

 

А я кто? Т.е. имея за полсотни модулей я ниХто?

Да, это затратно, да это удвоение работы. Но я вышел из этого, но все время забываю, что имею такой инструмент.
Я имею один класс модуля
И второй "псевдокласс", который подключаю в зависимости от версии
Таким образом, я имею универсальные контроллер/модель

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

 

Прошу прощения, я не фкусре) правда не знал - я на форуме буквально 3 дня.

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

Но пока решили отложить до момента когда устаканится "стандарт" у Дениэла. поэтому пока мы перевели только самые важные модули - остальные мы держим в "старом" стандарте. Ждем когда Дениэл окончательно определит стандарт и тогда будет разрабатывать порт на старые версии. Мы в целом рады порывам Дениэла организовать код - просто не хотим переделывать по несколько раз.

Кстати именно по этой причине мы портировали евенты на старые опенкарты.

Так что если Вам действительно будет интересно посмотреть как Shopunity может вам облегчить время на "раскидывание" по папкам - могу организовать экскурсию)

По Вашим замечаниям к упрощению регистрации действительно прислушаемся. Так что спасибо и приятного Вам дня.

 

Вы шутите?

Без лоха жизнь плоха. Так и у Даниеля.
Так и хочется закричать !!! Покажите Даниелю контртуктор запросов и отберите у него твиг

Какое устаканится.. Это если каждый день ( с версией) остаканиваться...

 

Ну зачем же так откровенно)))))))))))

 

Ну... как есть. Увы

Но вы хоть что-то слышите.

А ДК - все время меня закрывает без пояснений.

 

Да уж - нам то не знать. Но это его "фишка") К тому же он действительно отдается проекту. Не забрасывает его.

Но нас больше всего радует комьюнити - вокруг проекта очень много толковых программистов и со многими мы сотрудничаем.
Я думаю только общими усилиями можно повлиять на ход проекта. Если все выступят одним фронтом и аргументированно - то Дениэл идет на встречу.

Кстати ДК хоть и упрямый но прислушивается к аргументам. Не сразу но тем не менее)

 

Можно я вмешаюсь )) Я конечно не гуру, но мне кажется было бы лучше все ваши модули держать в пределах одной директории, например dreamvention т.е controller/extension/dreamvention/vash-modul/ итд model , admin ///
Это даст хоть какое то "быстрое" представление о зависимостях и прочих связях. Все же модули у вас не совсем обычные в стандартном представлении людей так как подтягиваемые зависимости могут только запутать. Вы например для одного модуля используете 15 зависимостей из которых используете 1% функционала. Это конечно удобно при разработке, но лично мне не нравится таскать лишнее. Видимо не нравится и потому, что до сих пор я не привык к композеру, который ради одной строки кода может подтянуть сотни мегабайт. В вашем случае в упрощенном варианте именно так и происходит.

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

 

Ну, не сам модуль, а ядро, оно-то и понятно..

Это и правильная мысль и не правильная - держать все в одном месте. Минус такого предложения - несоответствие стандартам - /extеnsion/module
Ведь доступ к фронту модуля - дефолтный.

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

Имея такую мощную систему и не делать хеллеров хотя бы для админки.. Но и это в принципе оправдано - переносимость и независимость

Но вот это.. то что меня убило наповал при первом знакомстве с ОС, конструкции след. вида

Код:

                                        <select name="filter_status" id="input-status" class="form-control">
                                          <option value="*"></option>
                                          <?php if ($filter_status) { ?>
                                          <option value="1" selected="selected"><?php echo $text_enabled; ?></option>
                                          <?php } else { ?>
                                          <option value="1"><?php echo $text_enabled; ?></option>
                                          <?php } ?>
                                          <?php if (!$filter_status && !is_null($filter_status)) { ?>
                                          <option value="0" selected="selected"><?php echo $text_disabled; ?></option>
                                          <?php } else { ?>
                                          <option value="0"><?php echo $text_disabled; ?></option>
                                          <?php } ?>
                                        </select>

А если там три? 10?
А тут в примере так вообще можно моск сломать, а есои можно мозг сломать, то как можно безболезненно оттестировать?


Так что не все хорошо в вашем королевстве.

 

Нет, видимо это не наш модуль вы пробовали. 777 КБ в сжатом виде и 3.1MБ без сжатия.

Ну для модулей есть своя схема - и модуль должен иметь контроллер в папке controller/extension/ - если глубже - Опенкарт его не подхватит. Но мы используем префиксы для того чтобы отличать свои модули- d_. Так что вы наши модули точно не пропустите.

Это не так. В основном мы выделяем библиотеки для того чтобы их не таскать из модуля в модуль. Например tinysort или bootstrap_switch - и мы используем эти библиотеки постоянно. Практически в каждом модуле. Но таскать их и дублировать у пользователя мы точно не хотим.
Перезаписывать же при установке нового модуля мы не можем - это противоречит нашим стандартам. поэтому выделили Депенденси.

Я могу перечислить те базовые вещи которым мы следуем:
1. Наши файлы никогда не перезаписывают другие при установке
2. Модули должны всегда быть доступы из раздела модулей. (ссылки допускаются)
3. Библиотеки должны быть в System/library и запускаться по autoload
4. У каждого модуля должен быть extension.json
5. У всех модулей есть версия согласно SEMVER
6. Все модули можно установить через Extension Installer.
есть еще но это база

Ну для этого вам достаточно изучить РЕПО той библиотеки которую подтягиваете. Опять так - Композер или NPM - это просто инструмент - а что он вам установит зависит исключительно от ВАС)

Вы немного не так воспринимаете то что мы делаем и я бы хотел акцентировать на этом внимание.
1. Shopunity и Dreamvention - это две разных вещи хоть и разработчики одни и теже.
2. Мы сделали shopunity чтобы упростить пользователю и себе жизнь. Люди не умеют устанавливать модули . через FTP. Они пугаются устанавливать обновления и так далее. И мы понимаем это. Устанавливали бы вы APP через блутуз на ваш iphone так же быстро как это можно через апстор. Людей это вообще не должно волновать. Им хочется просто установить и начать работать. Продавать.
3. Мы как разработчики модулей ИСПОЛЬЗУЕМ shopunity чтобы люди могли легко устанавливать наши модули. Shopunity не зависит от на наших модулей. В будущем мы откроем возможность регистрации разработчиков и любой сможет добавлять свои модули в систему и пользователи смогут точно так же устанавливать ваши модули как и наши.
4. Если вы разработаете библиотку или какой то модуль - и зальете в шопюнити - то мы можем тоже использовать его в своих разработках. У нас соблюдается SEMVER и поэтому мы можем строго определить какую из доступных версий вашей библиотеки мы хотим установить. (конечно могут быть конфликты модулей использующие разные версии поэтому у нас есть уведомления и ограничения по установке - но лучше просто соблюдать определенные правила и таких конфликтов не будет.)
5. Можно вообще не иметь зависимостей - вы можете просто создать модули и залить. И любой пользователь может его установить нажав 1 кнопку. Никаких зависимостей не будет так как вы их не определили в extension.json.

как вы видите - все зависит от разработчика и его правил. Система просто следует инструкции в extension.json.

В опенкарте много чего есть. И перечисление text_ из языковых файлов в контроллере и отсутствие h1 на странице категорий и много чего... в тоже время это одна из самых прозрачных и простых MVC с которой нам приходилось работать. Попробуйте мадженто или битрикс и сравните))

 

@dmitriyzhuk спасибо за развернутый ответ.

 

Не уговаривайте меня

Другие системы я обсуждать не хочу.

В данном топике мы говорим о вас..
echo select($name, id, $values)
где
function select($name, id, $values) {
$output = "<select name=".$name," id=$id"
foreach {
}
}

Да с одной сторны вроде не прозрачно, но скорость и уменьшение количества ошибок, как в валидации кода, так и в верстке.

 

не пойму - вы это у нас нашли? если да - то где именно - я проверю.