Как в личном кабинете создать виджет для приложения shop. (Инструкция)

ITFrogs

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

Давайте пошагово. Нажимаем...

Появляется панель управления виджетами. Пытаемся выбрать приложение:

Где я тут могу выбрать? Никак. Ребята забыли селекторы добавить. Но это не значит, что все не работает. У нас есть замечательная возможность хакнуть их систему и таки добавить свой виджет :)


Смотрим этот селектор в файрбаге.

Выбираем пункт "Редактировать HTML" и добавляем нужный пункт.

В моем случае это <option value="Shop">Магазин</option>

Теперь у нас есть нужный пункт:

Выбираем его и виджет добавляется как надо. К сожалению другого пути для добавления своего виджета в приложение пока нет. Да и зачем оно?.. И так не очень сложно.


1 октября 2015
  • Антон Перепелкин Webasyst 8 октября 2015 05:59

    Выбрать приложение для создания виджета уже можно функционалом по умолчанию.

  • ITFrogs 9 октября 2015 12:16

    Тем не менее, до публикации этой темы мне пришел отказ в публикации виджета по причине того, что он опубликован не от приложения shop. По этой же причине он не опубликован до сих пор. Наверное обиделись, что я эту тему создал.

  • Владислав Горлов Webasyst 9 октября 2015 12:49

    А сколько всего отказов было, не связанных с идентификатором приложения?

  • ITFrogs 9 октября 2015 12:56

    Все отказы были от недостатков документации. Например последний отказ по причине сползающей верстке в TV был до того, как у меня появилась возможность протестировать TV. Я задал фиксированные размеры блока виджета, а надо было делать резиновые, о чем неплохо было бы указать в документации. Про недостатки документации я тоже писал. Например то, что у каждого виджета свои настройки не очевидно. То, что у каждого виджета уникальный id тоже не очевидно. Как и многое другое.

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

  • Владислав Горлов Webasyst 9 октября 2015 13:42

    Повторюсь. Вопрос был простой. Сколько всего отказов было, не связанных с идентификатором приложения?

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

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

  • ITFrogs 9 октября 2015 14:05

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

    Все, у кого были неясности задавали вопросы и получали ответы.

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

    Сколько всего отказов было, не связанных с идентификатором приложения?

    Ну, судя по версии (1.0.4), всего отказов было 4. 4-1=3

    Но! Вы же проверяли виджет как системный. Он у вас не работал и вы не могли понять почему. Если бы вы сразу установили виджет для приложения shop, то он прошел бы с первого-второго раза. Т.е. получается, что изначально все проверки были заведомо обречены на провал из-за бага в админке.

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

  • Владислав Горлов Webasyst 9 октября 2015 14:26

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

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

    Исключения и благородства не получится: 150+ SQL запросов в вашем виджете для того, чтобы показать что Данные не найдены. Это очень много для магазина с несколькими десятками категорий и несколькими десятками заказов (а в сравнении со внутренними экранами аналитики это на порядок больше, при меньшей информационной отдаче).

    Поэтому поставьте себе задачей научиться использовать SQL в объеме, достаточном для такой аналитики. Почитайте про EXPLAIN, группировки, индексы, подзапросы. Сложный запрос зачастую лучше 100 запросов в цикле, а иногда, лучше сложный запрос разбить на несколько составных. В общем, изучайте. А до тех пор лучше не браться за этот класс задач.

  • ITFrogs 9 октября 2015 14:39

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

    И как узнать, что данные не найдены, если не искать их?

  • Владислав Горлов Webasyst 9 октября 2015 15:07

    Число запросов для получения групп id категорий:

    Q1=2N+1,

    где N - число категорий первого уровня. 1 запрос на получения категорий первого уровня. И по два запроса на получение подкатегорий для каждой из них (Потому что в цикле)

    Число запросов для получения сумм:

    Q2=N

    (причем, запросы не самые простые, говорящие о том, что про поле shop_order.paid_date вы не знаете, предпочитая JOIN, между делом злоупотребляя функциями преобразования времени)

    Итого:

    Q=3N+1

    Что расходится с числом N более, чем в 3 раза.

    Если не секрет, почему вы так не любите SQL сервера, что заставляете их считать для каждой попавшей в заказы записи о продукте это выражение

    UNIX_TIMESTAMP(o.datetime) > (UNIX_TIMESTAMP(NOW()) - 86400)

    А не просто

    o.paid_date NOT IS NULL AND o.datetime > 2015-10-08 22:00:00

    Всё это анализ виджета актуальной версии 1.0.4. Код первых версий еще хуже.

  • ITFrogs 9 октября 2015 15:33

    http://pastebin.com/EksgucTj

    Жалко что из вас все приходится клещами тянуть.

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

    И еще раз: Нужен форум для разработчиков!

  • Владислав Горлов Webasyst 9 октября 2015 15:52

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

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

    Форум для разработчиков есть. Вы, собственно, на нем и находитесь. Или вы не хотите публично спрашивать непонятные вам вещи?

  • ITFrogs 9 октября 2015 16:13

    Мне не стыдно обсуждать какие-то вещи публично. Я не претендую на истину в последней инстанции. Я человек и могу ошибаться. Это вы обижаетесь на каждый второй пост и пишете фразы типа 'опять ты за свое?' А я вот такой общительный, мне хочется общаться с умными людьми, учиться у них чему-то новому.


    Зы. А какое поле я не заметил. Морально уже приготовился посыпать голову пеплом

  • wa-apps.ru 9 октября 2015 17:47

    Позвольте вмешаться.
    То что сразу бросилось в глаза.
    Вот этот код:

    $categories = $cam->getByField('parent_id', 0, true);
    $cats = array();
    foreach ($categories as $key => $category) {
            $cats[$category['id']] = $category;
            $subs = $cam->getTree($category['id']);
            $cats[$category['id']]['subcategories'] = array_keys($subs);
            $cats[$category['id']]['count'] = 0;
    }

    можно переделать вот так:

    $cats = array();
    $rows = $cam->getFullTree();
    $parent_id = null;
    foreach ($rows as $row) {
    	if (!$row['depth']) {
    		$row['count'] = 0;
    		$row['subcategories'] = array($row['id']);
    		$cats[$row['id']] = $row;
    		$parent_id = $row['id'];
    	} else {
    		$cats[$parent_id]['subcategories'][] = $row['id'];
    	}
    }
    

    Результат будет тот же, только 2*N+1 SQL-запросов, где N - количество категорий первого уровня, превратились в 1 запрос.
    Разработчики Вебасиста не просто так ведь используют Nested Set для хранений дерева категорий...

    Дальше код переписывать не стал, иначе получится, что я перепишу основную часть виджета, а продавать это будет автор топика.

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







  • ITFrogs 9 октября 2015 18:49

    Я специально дал ссылку, чтобы узнать чужое видение ситуации. Критики я не боюсь и даже приветствую. Особенно когда она несет в себе здравые идеи.

    wa-apps.ru, спасибо за наводку :)

    Владислав, 2*N+1 тоже много? Есть идеи как еще сократить?

    upd. wa-apps.ru, в таком виде, как Вы представили, ничего не получится. Но все равно за идею обработки полного дерева спасибо. Сам бы до такого не догадался.

  • Syrnik.com 9 октября 2015 20:13

    Повыеживаться можн?

    Я бы кэшировал результат на день и сбрасывал бы кэш при обновлении лога операций (ну или по истечении суток он сам бы сбросился). Хотя над сроком жизни кэша подумать надо. Думаю, навдо вычислять, сколько до конца суток осталось и такой срок жизни и задавать.

    И вот еще, надо проверить конечн, но, кажется, верно. Если я правильно понял задание: посчитать количество продаж в штуках по корневым категориям за последние 30 дней?


    SELECT root_cat.id, root_cat.name, SUM(soi.quantity)
    FROM shop_order_items soi
      INNER JOIN shop_order so ON soi.order_id=so.id
      INNER JOIN shop_product sp ON soi.product_id=sp.id
      INNER JOIN shop_category sc ON sc.id=sp.category_id
      LEFT JOIN (
        SELECT scr.* FROM shop_category scr WHERE scr.parent_id=0
        ) root_cat 
        ON root_cat.left_key <= sc.left_key AND root_cat.right_key >= sc.right_key
    WHERE
        NOT ISNULL(root_cat.id) AND
        so.paid_date >= DATE_SUB(NOW(), INTERVAL 30 DAY ) AND
        so.paid_date <= NOW()
    GROUP BY root_cat.id
  • ITFrogs 10 октября 2015 06:55

    Сергей, вот это реально круто!

    Думал о чем-то таком, но потом решил, что, если воспользоваться родными безгрешными методами вебасист для получения корневых категорий, то они не усмотрят в этом sql запросов. :)



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