Нет к сожалению нельзя. Совместимость с минишоп не нужна была. Вообще надо разбираться как сделать совместимость и возможна ли она вообще. Компонент писался на совместимость с переработанным Shopkeeper.
Ну вот я и говорю что есть только id ресурса (parent). Понятно что с помощью fenom можно в defaultBalloonContent воткнуть дополнительный сниппет и в нем все поля вытащить. Но все равно лишние запросы в базу. Метод в простыне :) лучше :) можно без доп запросов в базу обойтись :). Только вы компонент изменили и переработать немного нужно метод. Мне сейчас некогда да и особо незачем.
Посмотрел новую версию вашего компонента. Мне вот одно не понятно. Как в defaultBalloonContent попадают данные ресурса tv pagetitle и т.д. и попадают ли они вообще туда? По моему туда только parent( id ресурса) попадает. Без данных ресурса смысла в defaultBalloonContent никакого.
Ну вот стараешься вспоминаешь пишешь а в ответ «эта дикая простыня мне ни к чему» :). Я не видел вашего нового кода. Да и, думаю, не скоро увижу, но не факт что не придется снова с напильником пилить :). Я другого способа уменьшить число запросов в базу не знаю кроме как присоединять в основной запрос. Ну нужная заказчику задача сделана, а придется ли мне использовать ваш компонент и нужно ли будет его пилить поживем увидим. Успехов Вам :)
Компонент дорабатывается и это хорошо :). Единственно со времени публикации статьи было еще несколько важных правок. Только времени описать их не было. Опишу на скорую руку что помню, надеюсь, это вам поможет в совершенствовании YandexMaps2.
1. Вызов
не очень хорошая идея. Как выяснилось на каждый объект в результатах поиска приходиться более десятка вызовов в базу данных. Что, конечно, тормозит работу сайта. Более разумное решение присоединить все что можно к основному запросу и потом вытащить из него нужные данные.
Еще чтобы работал поиск как надо надо поправить ошибки в pdoTools
Файл core/components/pdotools/model/pdotools/pdofetch.class.php
Функция addSelects строка примерно 367:
Здесь поменял порядок присоединения таблиц чтоб tv присоединялись раньше чем все остальное. Иначе mySQL ругается на CSDistrict.id = TVdistrict.value. TVdistrict присоединяется позже и типо ему оно не известно. Надо чтоб лефтджоин с TVdistrict был раньше уже сделан.
Ну вот что помню :). Надеюсь это поможет вам и остальным разработчикам :)
$modx = new modX();
$modx->initialize('mgr');
$modx->getService('error','error.modError');
точно нужны? Я делал другой плагин копируя этот и у меня из-за них возникала проблема что не находит xpdo классы компонентов. Не понятно зачем нужна вообще здесь инициализация нового объекта $modx
В файле схемы были не правильно заданы типы полей phptype. Вместо text поставил string и все заработало. На рабочем сайте обновите компонент и проверяйте как там работает.
В emailqueue.mysql.schema.xml вместо этого
Здравствуйте! Вот чтоб именно пустое поле получилось вообще странно :(. Пока скачиваю Опенсервер новый. Попробую поставить PHP 7.2.00 и посмотреть.
Хм. Он 3 часа обещает скачиваться. Может все таки дадите доступ к вашему MODX?
Это к чему вообще? :) Каюсь по ссылке не досмотрел, но ругань все равно не понятная :)
Кстати а как через менеджер MIGX inputTV проставить? я только через правку JSON конфига сделал.
Редакция МОЖЕТ отклонить приложения, которые:
2.11 повторяют приложения которые уже есть в App Store, особенно если их там уже много, например: фонарики, Кама Сутры, пукающие приложения.
Хорошее правило, но явно не запрет прямых аналогов.
в лучшем случае авторы зарабатывают десятки тысяч в месяц и лучше пусть один автор получает денюжку но делает безупречный продукт и имеет стимул его совершенствовать
Прямо реклама монополии :). Всю жизнь учили, что конкуренция лучше, а тут прямым текстом монополия лучше :). Я отстал от жизни? Монополия в ИТ лучше?
Мне кажется, что монополия провоцирует не совершенствовать продукт, а просто сидеть и стричь денежки :).
Если вдруг на мой компонент появиться конкурент и продажи упадут вдвое, то я, скорее всего, увеличу стоимость компонента вдвое. В расчете на то, что конкуренту тоже надо отбивать вложения, и так как, сложный компонент дорого делать, то конкурент тоже подымет стоимость.
А чем вам эта идея не нравиться? Стандартным импортом минишоп пользуются. Если будет компонент который будет позволять им пользоваться без танцев в бубном, то им тоже будут пользоваться.
А по факту, я почти на 100% уверен, что если вы сделаете стоящий и сложный компонент, который пусть и содержит идеи других авторов но выполняет их на голову выше — модерация его одобрит, а сообщество похлопает
А я вот не уверен. В правилах четко написано никаких прямых аналогов. Значит никаких. А то что за произвол? Это понравилось одобрим, а это не одобрим. И вдруг стоящий и сложный компонент чуть чуть не дотянет и его не одобрят, а время то на сложный надо много :(.
Владельцы MODSTORE обычно сначала интересуются мнением авторов аналогичных платных дополнений. И если автор против нового компонента (обоснованно), то магазин отказывает в публикации. Это уже много раз обсуждалось.
Можно ссылки где это обсуждалось. Что-то я не верные слова в поиск забиваю.
Очень заинтересован, как можно ознакомиться с демо компонента?
Мой компонент UserTest. По крайней мере требовалось сделать статистику тестов. Сколько на что сдали и т.д. с диаграммами. Сейчас заказчик в отпуске и говорит не знает требуется ли еще статистика.
Вы в разработке этого компонента заинтересованы? Или в чем заинтересовались? :)
Есть и минусы и плюсы.
1 минус. Как в моем случае, нельзя просто дополнение выпустить. Надо еще и сам функционал компонента под статистику доработать.
2 минус. Клиентам 2 дополнения придется ставить.
3 минус. Функционал компонента может измениться и дополнение станет не совместимым. Если в одном компоненте, то там это отслеживаешь, чтоб компонент был полностью рабочим. А в дополнении хата не моя и не знаю что там твориться :).
1 плюс как вы сказали
автор отвечает на вопросы по своему функционалу, а вы по своему
2 плюс если клиенту не нужна статистика он ее просто может не покупать.
В целом мне было бы интересней и клиентам удобней в одном компоненте. Только админам Modstore под группы разработчиков переделывать магазин — это много работы. Наверно они на это не пойдут :(.
Понятие прямого аналога все таки нечеткое. Допустим компонент msImportExport. Например я сделаю просто кнопку в админке для импорта товаров через стандартный скрипт минишопа http://webcandy.ru/manuals/import-csv-minishop2/. Плюс доработаю на долгую обработку, чтоб не обрывало при импорте многих товаров. Это будет считаться прямым аналогом?
Здесь в
Вообще есть тема такая. У меня есть заказ на доработку моего компонента. Прикрутить статистику тестов. Доработка не идет. Не складывается. Мне было бы удобно найти разраба, который бы эту доработку сделал. Но права на компонент и деньги за него я терять не хочу. Мне было бы удобно, если в модсторе были бы группы разработчиков и оплата за компонент перечислялась каждому разрабу по договеренности. Например сейчас компонент стоит 1990р другой разраб делает статистику, получает деньги от заказчика доработки и говорит 200р ему от продаж компонента. Наценяем компонент на 200р и от продаж мне падает 1990 а ему 200р.
Некоторые разработчики перестают развивать свои компоненты. Некогда или интерес пропал. Вышеописанная идея как раз для них подойдет.
Открытое ПО как раз и ценно тем, что его дорабатывать может кто захочет. А запрет на прямые аналоги эту ценность прибивают.
1. Вызов
не очень хорошая идея. Как выяснилось на каждый объект в результатах поиска приходиться более десятка вызовов в базу данных. Что, конечно, тормозит работу сайта. Более разумное решение присоединить все что можно к основному запросу и потом вытащить из него нужные данные.
Присоединяем
и выбираем колонку с данными объектов карты «ym2Map»:«objects».
Чанк my.tpl.mSearch2.row
дебаем балун и выводим объекты карты в результаты поиска
Чанк tpl.mFilter2.outer3
Вытаскиваем из результатов поиска и выводим на карту.
Скрипт assets/components/yandexmaps2/js/web/default.js
Изменилась регулярка чтоб она работала в safary
Маштабировать и центрировать карту чтобы все объекты на нее влезали
И свой тип метки на карте
Еще чтобы работал поиск как надо надо поправить ошибки в pdoTools
Файл core/components/pdotools/model/pdotools/pdofetch.class.php
Функция addSelects строка примерно 367:
$fields = 'SQL_CALC_FOUND_ROWS '. implode(",",$fields); это чтобы в запрос не попадало SQL_CALC_FOUND_ROWS Arroy
Функция addJoins строка примерно 304
Здесь поменял порядок присоединения таблиц чтоб tv присоединялись раньше чем все остальное. Иначе mySQL ругается на CSDistrict.id = TVdistrict.value. TVdistrict присоединяется позже и типо ему оно не известно. Надо чтоб лефтджоин с TVdistrict был раньше уже сделан.
Ну вот что помню :). Надеюсь это поможет вам и остальным разработчикам :)
точно нужны? Я делал другой плагин копируя этот и у меня из-за них возникала проблема что не находит xpdo классы компонентов. Не понятно зачем нужна вообще здесь инициализация нового объекта $modx
В emailqueue.mysql.schema.xml вместо этого
сделал это
Я эти поля как в modExtra сделано так и делал.
Хм. Он 3 часа обещает скачиваться. Может все таки дадите доступ к вашему MODX?
Кстати а как через менеджер MIGX inputTV проставить? я только через правку JSON конфига сделал.
например https://www.youtube.com/watch?v=_CFCr_embNw
Я недавно делал migx внутри migxdb :)
Хорошее правило, но явно не запрет прямых аналогов.
Прямо реклама монополии :). Всю жизнь учили, что конкуренция лучше, а тут прямым текстом монополия лучше :). Я отстал от жизни? Монополия в ИТ лучше?
Мне кажется, что монополия провоцирует не совершенствовать продукт, а просто сидеть и стричь денежки :).
Если вдруг на мой компонент появиться конкурент и продажи упадут вдвое, то я, скорее всего, увеличу стоимость компонента вдвое. В расчете на то, что конкуренту тоже надо отбивать вложения, и так как, сложный компонент дорого делать, то конкурент тоже подымет стоимость.
А я вот не уверен. В правилах четко написано никаких прямых аналогов. Значит никаких. А то что за произвол? Это понравилось одобрим, а это не одобрим. И вдруг стоящий и сложный компонент чуть чуть не дотянет и его не одобрят, а время то на сложный надо много :(.
Вы в разработке этого компонента заинтересованы? Или в чем заинтересовались? :)
1 минус. Как в моем случае, нельзя просто дополнение выпустить. Надо еще и сам функционал компонента под статистику доработать.
2 минус. Клиентам 2 дополнения придется ставить.
3 минус. Функционал компонента может измениться и дополнение станет не совместимым. Если в одном компоненте, то там это отслеживаешь, чтоб компонент был полностью рабочим. А в дополнении хата не моя и не знаю что там твориться :).
1 плюс как вы сказали 2 плюс если клиенту не нужна статистика он ее просто может не покупать.
В целом мне было бы интересней и клиентам удобней в одном компоненте. Только админам Modstore под группы разработчиков переделывать магазин — это много работы. Наверно они на это не пойдут :(.
Здесь в а в msImportExport
Некоторые разработчики перестают развивать свои компоненты. Некогда или интерес пропал. Вышеописанная идея как раз для них подойдет.
Открытое ПО как раз и ценно тем, что его дорабатывать может кто захочет. А запрет на прямые аналоги эту ценность прибивают.