Евгений Борисов
С нами с 17 декабря 2012; Место в рейтинге пользователей: #3347 минут назад
параметры из url и записывал бы в кукиПонятное дело, магии не существует. Надо JS написать который возьмёт параметры из url закодирует в JSON и запише...
Как вывести похожие товары по списку опций? 8
8 часов назад
Кстати, если кому интересно, mmxDatabase вроде как можно запустить и на MODX 2.x.
Сначала в консоли делаем так:
composer require mmx/databaseвыпол...
Новый тип дополнений: mmxDatabase и mmxForms 31
Сегодня в 11:45
Всем привет! Подскажите пожалуйста а можно ли сделать фильтр в 2 уровня и как это сделать? Т.е. например мне нужно сделать: домен/бренд-из-сео-фильтра...
Анонс SeoFilter - ЧПУ+SEO для mFilter2 и не только 120
Вчера в 15:27
Есть у кого-то идеи? или в данном случае через плагин и событие пробовать, или мсинк тупо всё обрезает?
Msync как записать html контент, а не обработанный без тегов? 1
Вчера в 12:15
воротите, что хотите. Вплоть до удаления исходников сайта, это уже на ваше усмотрение.
Это определённо очень важная возможность 😊
mmxFenom - нативная интеграция шаблонизатора 3
Вчера в 11:30
Управляя настройками mysql, можно задать параметр sql_mode пустым значением (после чего все заработает), но хостер такую возможность не дает… Есть ли ...
pdoTools и sql_mode=only_full_group_by - ошибки при работе PdoPage 1
Вчера в 10:27
<?php
$id = $modx->getOption('id', $scriptProperties, $modx->resource->id);
$field = $modx->getOption('field', $scriptProperties);
$tpl...
Вывод даты msTimeStamp полей MiniShop2: new, favorite, popular... 3
01 мая 2024, 21:40
$pdoTools = $modx->getParser()->pdoTools;
$data['count_products'] = count($data['products']);
$renderedHtml = $pdoTools->get...
Как передать переменные внутрь чанка из сниппета и заполнить с помощью fenom? 2
Я сейчас о программировании на процессорах. Нужна новая админка — бери, да пиши.
MODX Evo/Revo Сейчас привлекает многих тем, что можно использовать чужие наработки без проблем. А с новой админкой что? Опять проходить все круги ада — Tickets, miniShop и бла-бла-бла… Думаю это никому не нужно будет. Но, как бы не хотелось чего-то новенького да удобненького, большинство все равно будет пользоваться стареньким и привычненьким.
Опыт Evo тому пример. Я лично выступал инициатором реноваций, но всегда это заканчивалось неудачей. И так продолжалось до тех пор, пока я не написал 100% совместимый шлюз от DBAPI в Eloquent. Дальше стало проще — бек можно развивать вместе с админкой, но энтузиазма лично у меня уже не осталось.
Если кому интересно, то вот реализация для artisan под laravel gist.github.com/AgelxNash/0b6faaa7978e3456f3cbd3ef06b365da
Но по теме ветки комментариев. Мы начали разговор за реальные кейсы на GraphQL. Я понимаю, что тебе тема безопасности не важна, на SEO срать и т.д. Но если твой девиз хуяк-хуяк и в прод, то есть разработчики/студии которые стараются выпускать все-таки качественный со всех сторон продукт. И именно им в первую очередь будет познавательно узнать о реальных кейсах, а не каких-то абстрактных типо агрегирования нескольких API в один.
Но даже разбирая реальные кейсы, вместо накидывая путей решений ты тыкаешь носом в свои обрывки кода, отправляешь смотреть проекты и наработки. Но при этом на конструктивную критику ни в каком направлении не принимаешь. Если бы мы обсуждали абстрактные пути решения, статьи с того же хабра, сторонние репозитории и т.п., то диалог мог быть бы абсолютно другим. Скорее всего, мы бы поговорили за подходы к реализации как там сделано и как можно по другому. Какие плюсы и минусы выбранных реализаций и т.д. Но нет, ты тешишь свое ЧСВ показывая именно свои нарабокти, но не готов их обсуждать в негативном ключе. При этом пытаешься ущипнуть меня тем, что я якобы ничего не способен реализовать. Но не задумывался ли ты о том, что
Столько лет прошло, а ты так и не осознал мысль, что если кто-то способен найти твои ошибки, то значит этот кто-то знает больше твоего. Да, это не всегда так. Иногда это говорит о невнимательности разработчика, но этот случай явно не про тебя. Уж очень часто ты диалог заканчиваешь фразой «до безопасности доберусь, когда действительно понадобится».
Но в будущем, я все-таки думаю у Railt-а хорошие перспективы, т.к. код без жесткой завязки на фреймворк. А это значит, что его можно брать за основу не только в Laravel.
В любом случае, если бы я раньше увидел этот топик, то давно бы тебе показал это youtu.be/xETUOC4M4m4
И если бы обошлось без визгов, то мы бы конструктивно поговорили на тему ограничения прав доступа в GraphQL запросах. Затронули бы тему раскрытия путей /var/www/modxclub.ru/modxclub-3.0/ и еще много чего.
— показать, что GraphQL это не серебрянная пуля. И на реальных проектах все может оказаться несколько сложнее.
— Очередной раз подчеркнуть, что разбирая тонкости какой-то технологий, мы все дальше углубляемся в лес.
Хотя, если бы мы обсуждали не абстрактную вещь в стиле «смотрите какая крутая штука есть. на ней можно делать то и се», а разбирали реализацию GraphQL хотя бы для modx_site_content + TV, то такой материал вызвал бы
— намного больше интереса в сообществе
— позволил бы углубиться в тонкости технологии с пользой для CMS и т.п.
Про Go запрос был шутки ради. Но на всякий случай оставлю это тут github.com/gopherjs/gopherjs
На мой взгляд, агрегирование нескольких API в один, это задача частного уровня. А вот права доступа более чем насущная проблема, которая будет интересна большему кругу читателей.
github.com/VadimDez/Counter-Strike-JS
и
Одно и то же разными словами.
А насчет углубления в документацию, соглашусь с комментатором из соседнего топика modx.pro/development/18727#comment-112808 тем более,
есть свое сообщество graphql.org/community/ и много мануалов в сети.
Я ничего не имею против топиков не связанных с modx на этом сайте. Но на мой взгляд, эти топки не должны выходить за рамки вольного пересказа возможностей других технологий. Иначе сайт превратиться из сообщества modx в помойку с набором несвязанных между собой технических статей. Один только топик про minecraft это верх профильности и информационной кладези. Можно я рядом создам топик про сервера для Counter Strike?
Когда PHP + JS разрабатывается одним человеком, то тут выбирай что хочешь. Но когда это разные люди или даже комманды. То GraphQL позволяет им работать независимо друг от друга.
В общем я не говорю, что REST это плохо. Я говорю о том, что когда твое API выходит за рамки 2-3 методов, то GraphQL способен упростить жизнь как при разработке, так и в поддержке.
Например, раньше я документировал API через raml.org
Мне казалось это верх удобства. Но сейчас в моем арсенале появился еще один инструмент.
З.Ы. Похоже тема топика уже более чем раскрыта. Всем спасибо за внимание:-)
В общем получается такая картина, есть язык запросов — GraphQL. А есть серверная реализация этого языка запросов. Схема в общем случае на выходе одна и не важно чем и как ты ее генерируешь.
Если мы берем за аксионму тот факт, что GraphQL это чисто JS, а проект на PHP, то реализация API потребует абсолютно другого технологического стека. И бизнес логика сервисного слоя будет дублироваться на двух языках. Это приведет к удорожанию стоимости всего проекта. Одно дело, когда мы берем данные в сыром виде из базы. Другое дело, когда уже добавляется какая-то логика.
Ну или возьмем пример из топика. Что сделал ТС? Он подцепился к API modx.pro который разработал Василий и завернул ответ в GraphQL. И тут напрашивается резонный вопрос, а зачем нам этот промежуточный слой в виде уже существующего /assets/components/extras/action.php, если у нас есть доступ к коду и можно сразу сформировать GraphQL
Единственное, где может пригодится пример из топика — API к каким-то сотороним сервисам, к коду которых нет доступа, агрегирование нескольких API в один и т.п. Но все это задачи частного порядка.
А теперь откроем официальный сайт graphql.org/code/ и увидим серверную реализацию GraphQL на C#, Go, Java, PHP, Python, Ruby, etc… Для PHP указано аж 2 библиотеки. И одна из них webonyx/graphql-php взята за основу для Railt, который по своей сути является лишь синтаксическим сахаром для официального серверного пакета.
Так что кем бы ни был придуман GraphQL, но кидаться в омут npm пакетов и изучать шаманство в JS еще совсем не обязательно имея на руках проект PHP.