Сергей Шлоков

Сергей Шлоков

С нами с 31 января 2013; Место в рейтинге пользователей: #14
Сергей Шлоков
Вчера в 15:25
0
url: «assets/main/data/infra-index.json»
Откуда взялся index? Вы парсите плейсхолдер «alias», а передаете «config», в котором нет никакого index.
Сергей Шлоков
14 августа 2019, 09:03
0
Ну и звёздочек у Slim на Github больше — а все знают, что это самое важное!
Двух мнений быть не может! ))

А админку какую-то готовую брал или сам пилил?
Сергей Шлоков
14 августа 2019, 08:42
0
Если не секрет, почему именно Slim. Не проще было бы взять родной для Eloquent Lumen?
Сергей Шлоков
14 августа 2019, 08:23
0
Ну или возьмем пример из топика. Что сделал ТС? Он подцепился к API modx.pro который разработал Василий и завернул ответ в GraphQL. И тут напрашивается резонный вопрос, а зачем нам этот промежуточный слой в виде уже существующего /assets/components/extras/action.php, если у нас есть доступ к коду и можно сразу сформировать GraphQL
Насколько я понимаю, доступа к коду как раз и нет. У него же нет другой точки входа с описанными схемами или доступа к БД напрямую. Поэтому и пришлось юзать что дали. Или есть? )

И одна из них webonyx/graphql-php взята за основу для Railt
Хотя сам Кирилл её не хвалит )
Сергей Шлоков
14 августа 2019, 08:16
0
Зацепил меня данный комментарий. Думал после видео что-нибудь кто-нибудь ответит, но нет)
Я ещё первое до конца не досмотрел. А второе вообще 3 часа. ))

Если мы берем за аксионму тот факт, что GraphQL это чисто JS, а проект на PHP, то реализация API потребует абсолютно другого технологического стека.
Я имел ввиду немного другое. Конечно не надо менять стеки. Я хотел сказать, что нет особой необходимости использовать GraphQL для PHP разработчиков. Если только у тебя не мега сервис с могущим API, как говорит Кирилл Несмеянов.Т.е.PHP разработчику вполне хватит REST-а.

А вот если посмотреть со стороны фронт разработчика, то ему GraphQL даёт больше плюшек. Он не знает ни схем, ни связей объектов в отличие от PHP разработчика (и любого другого бекэндера). И GraphQL даёт ему возможность самому строить запросы не зная этого.

Попробую пояснить мысль. Представим, что MODX — это сервис с API, как это изначально планировалось сделать в MODX3 — использовать Slim в качестве ядра и работать через API. Тогда можно подключать любую админку. Как мне кажется (!), тут GraphQL в качестве обёртки не нужен. Вполне хватит обычного REST-а.

П.С. Возможно, я говорю глупости. Просто ещё не до конца вкурил эту тему. :)
Сергей Шлоков
13 августа 2019, 20:19
0
Посмотрел. Заинтересовало. Но… GraphQL — это как бы альтернатива REST-у. Придумана фронтэндерами. Удобно. Но в экосистеме MODX я не встречал даже какой-то толковой наработки по RESTful. Поэтому GraphQL вряд ли будет востребован разработчиками, использующими MODX. И это не удивительно. Могу ошибаться, но скорее всего и в WP, Joomla и т.п. CMS такого тоже не увидишь. Это другой уровень.
В свете сказанного, GraphQL выглядит немного неуместно для PHP. Как и для любого другого серверного языка. А вот для JS самое оно. Фронтэндеру не нужно разбираться в связях и типах. Всё прописано в схемах.
Но это, как требует говорить Николай, чисто моё мнение.
Сергей Шлоков
13 августа 2019, 10:03
+4
У меня было бы желание, я мог бы полностью переписать админку MODX-а, и это было бы во много раз удобней и перспективней
Без ложной скромности замечу,
Я — гениальный человек!
А то что ничего не создал…
Так я был занят и болел.
(ещё пирожков)

П.С. Извини, но мимо тёщиного дома… ))
Сергей Шлоков
12 августа 2019, 14:34
0
А как насчет этого?
Ого! Шаманы, мать их.
Сергей Шлоков
12 августа 2019, 10:15
0
А если пофантазировать, что могло бы тебя заставить вернкться на MODX?
Сергей Шлоков
12 августа 2019, 10:06
+1
сравнение == это беда не только PHP, но и JS.
Ты не понял. В js это «возможности», а в php — беда. )

Всё это субъективно. Меня эти «возможности» немного раздражают, но это не значит, что js отстой. В обычных языках тоже свои особенности. Но они как есть, так и будут.
Сергей Шлоков
09 августа 2019, 16:22
0
<Часто ли ты используешь сравнение с null?
Не часто, но бывает. Я мыслю по другому. я так программирую, что мне достаточно isset и isEmpty. И я не припомню случая, когда мне нужно было бы проверять на undefined. А вот в js это частенько приходилось делать. Это потому что я плохой программист или просто подход к языкам разный?
Сергей Шлоков
09 августа 2019, 16:04
0
3. instanceof.
4. typeof.

3 и 4 аналоги тоже есть в php, но я ими очень редко пользовался. В js повсеместно использую
Честно говоря непонятно, что ты этим хотел подчеркнуть. Ибо понять это можно как минус.
А я, например, часто пользуюсь функциями isInt, isArray и т.п. Не пойму, чем мы мериемся.

П.С. какая же это боль писать комменты с телефона.
Сергей Шлоков
09 августа 2019, 15:55
0
Еще один из примеров особенностей js.
Например, тип строки (Hello world) не совпадает с типом нового объекта String (new String('Hello world')). Это порой приводит к нежелательным последствиям, которые могут сбить с толку.
Вообще всё-таки некорректно сравнивать эти языки. У них разная история и предназначение. Если задаться целью, то ровно также можно найти миллион отличий между javascript и java, js и go, php и pyton. Только вот зачем? Js — уникальный скриптовый язык, который на данный момент невозможно ничем заменить в отличие от серверных, где альтернатив много. Но от этого он не становиться идеальным. Как раз наоборот
Столько этих «особенностей» нет ни в одном другом языке.
Сергей Шлоков
09 августа 2019, 10:44
+1
Возможно. Никогда не говори никогда. Но сейчас я не понимаю, почему описанные выше и ещё в тысячах статей выкрутасы в js это просто прикольные мелочи, а в php всё просто ужасно. Поэтому хочется пояснений, раскрывающих преимущества js. Ответ — когда-нибудь поймёшь, говорит только о субъективности. Никаких объективных причин нет.
Сергей Шлоков
09 августа 2019, 09:25
0
Так и я про то же. Но почему-то жуть на php. Есть сайты с задачками для js именно про эти особенности.
Сергей Шлоков
08 августа 2019, 19:06
+1
Спасибо за статью. Глубоко ещё не вчитывался. Но так как она в векторе моего интереса, то мне уже интересно.
Сергей Шлоков
08 августа 2019, 19:02
0
Просто для меня это заявление звучит противоречиво.
Говориться, что на JS приходится более внимательно работать с типами и условиями. Т.е. он менее требователен и типизирован. Что в дальнейшем может приводить к ошибкам. И следом идет
Я порой офигеваю от того, что я делал раньше на PHP. Жжжуть…
Т.е. всё наоборот.

Поэтому и просил уточнить.

П.С. А TS — это typescript?
Сергей Шлоков
08 августа 2019, 18:30
0
Вот это неоспоримый факт! Я порой офигеваю от того, что я делал раньше на PHP. Жжжуть…
А можно уточнить в чём неоспоримость? Оба языка вроде как с динамической типизацией? А с PHP 7 появилась статическая типизация.