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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Число запросов для получения групп 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. Код первых версий еще хуже.

http://pastebin.com/EksgucTj

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

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

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

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

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

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

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

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

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

$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 в сети хорошие есть.

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

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

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

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

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

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

И вот еще, надо проверить конечн, но, кажется, верно. Если я правильно понял задание: посчитать количество продаж в штуках по корневым категориям за последние 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

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

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