К слову: мы используем, и кейс не один. К примеру, не так давно на минишопе использовали. Обратился клиент, который у себя на сайте сам настроил различные скидки для различных групп пользователей с помощью msDiscount, и оставалось только при оформлении заказа (а точнее при переводе его в конечный статус) подсчитывать сумму всех заказов клиента и в зависимости от пороговых показателей закинуть его в ту или иную группу. Вот это совсем не сложно было реализовать с помощью userKarma. Вообще в msDiscount есть свой механизм добавления пользователей в группы в зависимости от суммы заказов, но у него есть минус — он не выкидывает из групп. То есть если есть несколько групп прогресса, то пользователь проходя все эти группы, во всех этих группах и останется. А userKarma умеет в том числе и выкидывать из указанных групп, при чем как при превышении максимальных пороговых показателей, так и недостижении минимальных.
Подтверждаю. Пруфф вряд ли найду (на сколько помню, это на старом официальном MODX-форуме обсуждалось), но об этом действительно говорили. Кстати, в своей практике имел конфликт своего modRedirect с Redirector Шона МакКормика, он так же использовал класс modRedirect. К фатальным ошибкам это не привело, а вот логических схватил с лихвой (когда писаться все стало совсем в другую таблицу).
Ну и еще в своей практике по-моему с modEvent сконфликтовал.
P.S. Сорри, да, я тоже этим грешу. Но пытаюсь исправляться.
Как я и писал, переводить из групп в группы можно по любым показателям (опять-таки, это решается плагинами). Кому нужны специфические плагины, за отдельную плату они обсуждаются. Просто, видимо, далеко не всем это понятно.
Второе: как я и говорил, на основе этих технологий был разработан прототип другого, более гибкого компонента, который позволяет настраивать более гибкие автоматические модификации. Надеюсь, когда-нибудь доберусь до него и допишу. Пока же есть более важные задачи.
Слушать что, бесконечные оскорбления и фантазии? Это первый комментарий, где ты как более опытный товарищ помог решить проблему.
Это уже кто что хочет видеть и что видит. Я много раз тебе писал годные советы (можешь пробежаться по старым комментам, сейчас у тебя опыта больше, ты можешь заметить то, чего раньше не замечал).
И я много раз говорил: меньше обращайте внимания на эмоции, больше на суть. Ребят в своей команде я еще не так отчитываю.
Они мой безобидный PR для отображения используемой памяти принять уже год не могут. А уж про PR с лейаутом и мечтать нечего. Они только критические PR принимают. Видимо интереса ко второй ветке у них уже нет.
У меня тоже 3 открытых PR и больше половины из трех десятков закрытых не принято (хотя есть критичные, баги с которым до сих пор проявляются). А что делать? Все равно приходится отправлять.
Если ты не понял зачем, может тогда ты себя переоцениваешь?
Нет, это я тебя переоценил. Не думал, что ты до такого еще более мощного хардкода дойдешь… Все это ради того, чтобы добавить возможность регион в ExtJS-лейауте менять и кастомные JS-ки добавлять? Не кажется, что это слишком? Нельзя такое оправдывать словами «Конфликты приложений существовали до меня и будут существовать после». Не кажется, что надо все-таки какое-то более мягкое решение искать?
Ладно, это лирика. Я так понял, подмену в контроллере ты делаешь для того, чтобы можно было дерево документов справа выводить через кастомный JS-layout?
ОК, тогда такое решение, для примера:
Замена через регулярки, конечно, жестко, но в твоем случае это меньший хардкод, чем было. И в таком случае дерево справа выводится, и modxSDK работает.
А теперь интересное: я так понял, при включенной JS-компрессии в админке у тебя эта штука не работает? Ведь ты вклиниваешься только в блоке отключенной компрессии. Поэтому я и добавил проверку включена ли компрессия. Включаем компрессию, и уже кастомный JS отсутствует, и функционал не работает.
Не работает и без моих модификаций (без них только еще и modxSDK работать перестает).
Правда тут сложнее становится? Надо в компрессированный JS-файл вклиниться, а это уже гораздо сложнее и простой регулярочкой сложно, а главное — глупо. Поэтому ищем более правильное решение, а именно расширение самого MODx.Layout. Вот тебе такой расширяющий Layout.
И здесь сразу несколько плюсов:
1. Это работает теперь в том числе и на включенной компрессии.
2. Это не перетирает чужие кастомные скрипты.
3. Это не ломает чужие лейауты (сейчас, если кто-то переопределит на свой лад modx-layout, свой код его затрет).
4. Гораздо меньше кода (что обслуживать легче).
5. БОльшая обратная совместимость (не придется отслеживать версию MODX-а в случае, если в новой версии MODX-а будут изменения на уровне твоего текущего переопределенного блока контроллера).
В общем, если ты хочешь писать правильные компоненты, во-первых, меньше огрызайся и больше слушай других, а во-вторых, научись хотеть писать правильный код. У тебя есть мышление, но нет правильного взгляда на такие вещи.
P.S. А еще лучше пуллреквест бы в MODX отправил. Там вопрос в двух строчках.
Что-то мне это напоминает. Вторая часть Марлезонского балета? Василий тогда уже всё сказал. Повторяться не буду.
Я бы тебе советовал это перечитать, и еще не раз. Вот я там писал:
Нафига вот так вот переписывать всю систему?
А еще я, было дело, спрашивал «Нафига в минишопе контроллеры так все переписывать?».
Короче, ты тоже, смотрю, любитель все попереписывать. Вот в админтулс ты нафига вот это переписал вот этим.
Ты бы не только мои мемуары читал, но и в код подсматривал. К примеру, у меня в modxSDK этот момент был реализован вот так.
Знаешь к чему я это все? Ты вот кичишься своим гениальным кодом, и совершенно никого не слушаешь. Написал что-то лично свое, что ломает работу других компонентов. Вот очередная жалоба поступила. Ты считаешь, это профессионально?
Вот так выглядел диалог по этой проблеме:
Ты не ориентируйся на количество здесь плюсов тебе и минусов мне. Я не на своем поле. Глобально же большинство твоих компонентов вызывают у нормальных программистов реакцию от легкой усмешки до дикого ржача. Сколько раз я слышал «Коля, перепиши ты этот oneBooking! Там под капотом ппц! А альтернативы пока не написали».
В общем, если ты в кафе или театре, возвращайся, больше учись, а то так и будешь писать код для новичков. А ведь наверняка мечтаешь о признании и среди опытных программистов.
Не надо на девушек переходить и т.п. Поверь, у меня с этим нормально. И отдыхал я целых три дня.
Я тоже все сказал. И не говорю, что ты должен поступить именно так. Тебе решать. Я просто высказал свое мнение. А высказал, просто потому что жалко, что имеющийся потенциал идет немного не в том русле. Но может ты когда-нибудь поймешь это.
Почитал мнения остальных. Могу ошибаться, но в целом они сходятся в том, что полезно для подсматривания (откуда что берется), и документацию почитать полезно. Так вот, может тебе все-таки не хелперы эти писать, а все-таки статьи и документацию по работе с API. Вот серьезно. Смотри, вот ты пишешь:
parents()
Выводит id родителей ресурса для указанного уровня в виде массива.
Во-первых, люди будут больше понимать основы MODX-а.
Во-вторых, это работать будет везде, без установки всяких дополнительных библиотек. Да, на своем частном проекте можно поставить допбиблиотеку. А если вопрос стоит в переносимости кода? Написать свой компонент и требовать, чтобы все ставили допкомпонент для его работы? Я понимаю это в случае с pdoTools и modxSite компонентами, там код обширный. Но просто ради синтаксического сахара, согласись, оно того не стоит.
А покопать MODX было бы и тебе полезно (и наверняка интересно). К примеру, ты знал, что ::getOption() есть не только у MODx, но и у xPDOObject? У любого. Это очень полезный механизм. Зачем это бывает нужно? Например, в одном сниппете установил $modx->resource->setOption($key, $value), а в другом перехватил $modx->resource->getOption($key, $value). И точно знаешь, что это нигде больше не перехватится и не перетрется. А то бывает в одном сниппете устанавливаешь $modx->setPlaceholder(), и тут же где-то в другом месте его перетирают, просто потому что это слишком глобально и имя переменной не уникальное использовал.
Ну и согласись, просто из-за того, что API слишком обширное, лень тобою обуяла, и ты местами просто не в полной мере функционал поддержал. К примеру, config(). Ты не стал здесь расширять MODx-метод, мы просто переписал на свой лад, дав возможность получать только текущие конфиги объекта $modx. Но родной MODx-овый метод поддерживает 4 параметра. Один из них — «значение по умолчанию», поддержку которого ты не перенес в свой метод. Таким образом ты не только добавил лишние сущности, но и обеднил функционал. Не надо так.
Функцию email() вообще практически как есть взял из modUser::sendEmail(). Знаешь как я иногда делаю, когда хочу отправить мыло на произвольные емейл?
В общем, это мое личное мнение. Понятно дело, тебе решать что делать, и народу решать что принимать и что изучать. Скажу только, напоследок, что я вижу много ненужных сторонних псевдотехнологий, и очень мало, касающегося самого MODX-а. То, что ты написал, не будет работать без самого MODX-а. То есть прежде, чем написать это, ты изучал MODX. Но вместо того, чтобы научить других полученным знаниям, ты придумываешь и впариваешь всем вот этот свой синтаксический сахар. И все это для того, чтобы всеобщее внимание сосредотачивалось на тебе. Почему ты все оцениваешь в количестве скаченных твоих компонентов? Зачем? Если никто не будет качать твои компоненты, то у тебя самооценка понизится? Мои компоненты практически никто сейчас не качает. Ну и что? Я все равно знаю больше тебя в MODX. Не хочешь ли и ты реально знать больше в MODX, вместо того, чтобы писать компоненты, которые и скачают только те, кто знает значительно меньше тебя. Я говорил тебе подобное больше года назад, и вот опять говорю. Подумай над этим.
Сорри, что вмешиваюсь, но все-таки… Зачем все это? Нет, ну серьезно? user_id() чтобы вернуть $modx->user->id? Не проще ли просто запомнить $modx->user->id? Даже тело функции как бы намекает…
Вероятность того, что объект $modx->user будет отсутствовать — практически нулевая, потому что при инициализации MODX в любом случае создает этот объект, даже если пользователь не авторизован. А если этого не произойдет, то все развалится нафиг фатальной ошибкой.
children() как альтернатива $modx->getChildIds()? И прочее в том же духе? Это все напоминает попытки русских отучить от вилки и ложки, потому что палочками тоже можно кушать. Еще раз сорри, но более бесполезного материала не видел давно. Ты же способен на большее. Зачем писать такое?
Там дофига делов. Коротко: в момент инициализации страницы управления пользователями добавляется еще один JS с гридом, расширяющим MODX-овый грид пользователей, и регистрируется новый компонент поверх старого
Ext.reg('modx-grid-user',UserKarmaGrid);
Иван, спасибо на добром слове :)
Я, в свою очередь, новичкам постоянно советую уроки Ильи Уткина ilyaut.ru/xpdo/. Формат более подходящий, и написано все важное.
Сорри, у меня такого нет. Когда-то было собственных несколько уроков по ExtJS, но похоронил.
В любом случае, учите ExtJS (на нем админка написана (морда)), PHP, SQL, xPDO. Особо простого пути здесь нет. Одно дело использовать чужие компоненты, другое дело — писать их.
Очень хороший материал у Ильи Уткина собран. Там и xPDO, и ExtJS. Если этого мало, то можно вообще завязывать с самообучением.
Добрый день.
Это вопрос или утверждение? Если вопрос, то здесь скриншотов довольно много. Уточню, что этот компонент не добавит вам скорости там, где ее нет. Он просто позволяет не терять ее там, где обычно теряется. Поэтому, если у вас сайт медленно отдает страницы даже из кеша, он не прибавит им скорости.
К слову: мы используем, и кейс не один. К примеру, не так давно на минишопе использовали. Обратился клиент, который у себя на сайте сам настроил различные скидки для различных групп пользователей с помощью msDiscount, и оставалось только при оформлении заказа (а точнее при переводе его в конечный статус) подсчитывать сумму всех заказов клиента и в зависимости от пороговых показателей закинуть его в ту или иную группу. Вот это совсем не сложно было реализовать с помощью userKarma. Вообще в msDiscount есть свой механизм добавления пользователей в группы в зависимости от суммы заказов, но у него есть минус — он не выкидывает из групп. То есть если есть несколько групп прогресса, то пользователь проходя все эти группы, во всех этих группах и останется. А userKarma умеет в том числе и выкидывать из указанных групп, при чем как при превышении максимальных пороговых показателей, так и недостижении минимальных.
Ну и еще в своей практике по-моему с modEvent сконфликтовал.
P.S. Сорри, да, я тоже этим грешу. Но пытаюсь исправляться.
Второе: как я и говорил, на основе этих технологий был разработан прототип другого, более гибкого компонента, который позволяет настраивать более гибкие автоматические модификации. Надеюсь, когда-нибудь доберусь до него и допишу. Пока же есть более важные задачи.
Ту же самую ошибку допустил. Тогда меня с этим разве что danyaPostfactum мог поправить, он всегда в JS был очень силен.
Это уже кто что хочет видеть и что видит. Я много раз тебе писал годные советы (можешь пробежаться по старым комментам, сейчас у тебя опыта больше, ты можешь заметить то, чего раньше не замечал).
И я много раз говорил: меньше обращайте внимания на эмоции, больше на суть. Ребят в своей команде я еще не так отчитываю.
У меня тоже 3 открытых PR и больше половины из трех десятков закрытых не принято (хотя есть критичные, баги с которым до сих пор проявляются). А что делать? Все равно приходится отправлять.
Ладно, это лирика. Я так понял, подмену в контроллере ты делаешь для того, чтобы можно было дерево документов справа выводить через кастомный JS-layout?
ОК, тогда такое решение, для примера:
Замена через регулярки, конечно, жестко, но в твоем случае это меньший хардкод, чем было. И в таком случае дерево справа выводится, и modxSDK работает.
А теперь интересное: я так понял, при включенной JS-компрессии в админке у тебя эта штука не работает? Ведь ты вклиниваешься только в блоке отключенной компрессии. Поэтому я и добавил проверку включена ли компрессия. Включаем компрессию, и уже кастомный JS отсутствует, и функционал не работает.
Не работает и без моих модификаций (без них только еще и modxSDK работать перестает).
Правда тут сложнее становится? Надо в компрессированный JS-файл вклиниться, а это уже гораздо сложнее и простой регулярочкой сложно, а главное — глупо. Поэтому ищем более правильное решение, а именно расширение самого MODx.Layout. Вот тебе такой расширяющий Layout.
Согласись, 90 строк лучше 420-ти?
А в классе твоем итоговый код будет таким:
И здесь сразу несколько плюсов:
1. Это работает теперь в том числе и на включенной компрессии.
2. Это не перетирает чужие кастомные скрипты.
3. Это не ломает чужие лейауты (сейчас, если кто-то переопределит на свой лад modx-layout, свой код его затрет).
4. Гораздо меньше кода (что обслуживать легче).
5. БОльшая обратная совместимость (не придется отслеживать версию MODX-а в случае, если в новой версии MODX-а будут изменения на уровне твоего текущего переопределенного блока контроллера).
В общем, если ты хочешь писать правильные компоненты, во-первых, меньше огрызайся и больше слушай других, а во-вторых, научись хотеть писать правильный код. У тебя есть мышление, но нет правильного взгляда на такие вещи.
P.S. А еще лучше пуллреквест бы в MODX отправил. Там вопрос в двух строчках.
А еще я, было дело, спрашивал «Нафига в минишопе контроллеры так все переписывать?».
Короче, ты тоже, смотрю, любитель все попереписывать. Вот в админтулс ты нафига вот это переписал вот этим.
Ты бы не только мои мемуары читал, но и в код подсматривал. К примеру, у меня в modxSDK этот момент был реализован вот так.
Знаешь к чему я это все? Ты вот кичишься своим гениальным кодом, и совершенно никого не слушаешь. Написал что-то лично свое, что ломает работу других компонентов. Вот очередная жалоба поступила. Ты считаешь, это профессионально?
Вот так выглядел диалог по этой проблеме:
Ты не ориентируйся на количество здесь плюсов тебе и минусов мне. Я не на своем поле. Глобально же большинство твоих компонентов вызывают у нормальных программистов реакцию от легкой усмешки до дикого ржача. Сколько раз я слышал «Коля, перепиши ты этот oneBooking! Там под капотом ппц! А альтернативы пока не написали».
В общем, если ты в кафе или театре, возвращайся, больше учись, а то так и будешь писать код для новичков. А ведь наверняка мечтаешь о признании и среди опытных программистов.
P.S. отправил тебе PR.
P.P.S. хочешь ответить? Лучше отправь мне парочку ответных годных PR куда-нибудь.
Я тоже все сказал. И не говорю, что ты должен поступить именно так. Тебе решать. Я просто высказал свое мнение. А высказал, просто потому что жалко, что имеющийся потенциал идет немного не в том русле. Но может ты когда-нибудь поймешь это.
А теперь то же самое на чистом MODX:
Во-первых, люди будут больше понимать основы MODX-а.
Во-вторых, это работать будет везде, без установки всяких дополнительных библиотек. Да, на своем частном проекте можно поставить допбиблиотеку. А если вопрос стоит в переносимости кода? Написать свой компонент и требовать, чтобы все ставили допкомпонент для его работы? Я понимаю это в случае с pdoTools и modxSite компонентами, там код обширный. Но просто ради синтаксического сахара, согласись, оно того не стоит.
А покопать MODX было бы и тебе полезно (и наверняка интересно). К примеру, ты знал, что ::getOption() есть не только у MODx, но и у xPDOObject? У любого. Это очень полезный механизм. Зачем это бывает нужно? Например, в одном сниппете установил $modx->resource->setOption($key, $value), а в другом перехватил $modx->resource->getOption($key, $value). И точно знаешь, что это нигде больше не перехватится и не перетрется. А то бывает в одном сниппете устанавливаешь $modx->setPlaceholder(), и тут же где-то в другом месте его перетирают, просто потому что это слишком глобально и имя переменной не уникальное использовал.
Ну и согласись, просто из-за того, что API слишком обширное, лень тобою обуяла, и ты местами просто не в полной мере функционал поддержал. К примеру, config(). Ты не стал здесь расширять MODx-метод, мы просто переписал на свой лад, дав возможность получать только текущие конфиги объекта $modx. Но родной MODx-овый метод поддерживает 4 параметра. Один из них — «значение по умолчанию», поддержку которого ты не перенес в свой метод. Таким образом ты не только добавил лишние сущности, но и обеднил функционал. Не надо так.
Функцию email() вообще практически как есть взял из modUser::sendEmail(). Знаешь как я иногда делаю, когда хочу отправить мыло на произвольные емейл?
И никаких лишних библиотек.
В общем, это мое личное мнение. Понятно дело, тебе решать что делать, и народу решать что принимать и что изучать. Скажу только, напоследок, что я вижу много ненужных сторонних псевдотехнологий, и очень мало, касающегося самого MODX-а. То, что ты написал, не будет работать без самого MODX-а. То есть прежде, чем написать это, ты изучал MODX. Но вместо того, чтобы научить других полученным знаниям, ты придумываешь и впариваешь всем вот этот свой синтаксический сахар. И все это для того, чтобы всеобщее внимание сосредотачивалось на тебе. Почему ты все оцениваешь в количестве скаченных твоих компонентов? Зачем? Если никто не будет качать твои компоненты, то у тебя самооценка понизится? Мои компоненты практически никто сейчас не качает. Ну и что? Я все равно знаю больше тебя в MODX. Не хочешь ли и ты реально знать больше в MODX, вместо того, чтобы писать компоненты, которые и скачают только те, кто знает значительно меньше тебя. Я говорил тебе подобное больше года назад, и вот опять говорю. Подумай над этим.
Вероятность того, что объект $modx->user будет отсутствовать — практически нулевая, потому что при инициализации MODX в любом случае создает этот объект, даже если пользователь не авторизован. А если этого не произойдет, то все развалится нафиг фатальной ошибкой.
children() как альтернатива $modx->getChildIds()? И прочее в том же духе? Это все напоминает попытки русских отучить от вилки и ложки, потому что палочками тоже можно кушать. Еще раз сорри, но более бесполезного материала не видел давно. Ты же способен на большее. Зачем писать такое?
P.S. Здесь одинарные кавычки явно лишние.
Ext.reg('modx-grid-user',UserKarmaGrid);
Я, в свою очередь, новичкам постоянно советую уроки Ильи Уткина ilyaut.ru/xpdo/. Формат более подходящий, и написано все важное.
В любом случае, учите ExtJS (на нем админка написана (морда)), PHP, SQL, xPDO. Особо простого пути здесь нет. Одно дело использовать чужие компоненты, другое дело — писать их.
Очень хороший материал у Ильи Уткина собран. Там и xPDO, и ExtJS. Если этого мало, то можно вообще завязывать с самообучением.
Это вопрос или утверждение? Если вопрос, то здесь скриншотов довольно много. Уточню, что этот компонент не добавит вам скорости там, где ее нет. Он просто позволяет не терять ее там, где обычно теряется. Поэтому, если у вас сайт медленно отдает страницы даже из кеша, он не прибавит им скорости.