Сергей Шлоков
С нами с 31 января 2013; Место в рейтинге пользователей: #35 часов назад
Ну вот и правильная мысль, я же правильно понимаю, что все дополнения, что написаны на ms2 надо переписывать на ms3 многие авторы это не будут делать,...
MiniShop3 - 1.0.0-alpha 15
Вчера в 10:16
Посмотрел докумендацию Sendit.
и нашел то что искал, конечно надо будет писать побольше кода, но это то что надо, и очень гибко оказывается.
Спасибо...
Как кастомизировать сообщения после Регистрации на сайте? 3
28 ноября 2024, 18:01
Так делал на одном проекте, нужно было добавить поиск по полю pagetitle. Думаю, что можно и на TV переделать.
<?php
class myCustomFilter extends...
mFilter2 фильтрация tv 3
28 ноября 2024, 17:35
На ноде при запуске сервера можно большую часть проинициализировать. Например, прогрузить настройки, чанки и сниппеты в память и не лазить за ними в б...
Плюсы и минусы Vue и gtsAPI 18
27 ноября 2024, 19:13
Вообще можно завести допполе и при сохранении ресурса плагином писать в допполе разбирая pagetitle.
Модификатор сортировки pdoResources по pagetitle 7
27 ноября 2024, 12:36
Добрый день. Появилась новая ошибка: 27.11.2024 12:30:20 ERROR /www/site.ru/core/components/yasmartcaptcha/model/yasmartcaptcha.class.php 60
Reco...
YaSmartCaptcha - защитите ваши формы от спама умной капчей от Яндекс 6
Боюсь тебя расстроить, но MODX — это синтаксический сахар над PHP. Юзай последний. Не отказывайся от своих принципов.
Не используй. Сделай мне больно.
П.С. Только щас заметил, что мой коммент почему-то попал не в корень, а залетел в ответ на твой коммент. Видимо глаза уже подводят.
Лично я не вижу особой необходимости в объекте $_modx как ограничителе функциональности для безопасности. Этого нет ни в одном шаблонизаторе. Видимо никому не понадобилась такая фича. А вот как объект для работы со вьюхами (шаблонами, чанками, ресурсами) он хорош. Для правильной работы, если можно так выразится. И юзер $_modx->user там нужен! Хотя я бы сделал юзера отдельным объектом для удобства. Но считаю, что кэшменеджер тут лишний. Вот такое имхо. Но, как правильно сказал Павел, ты может делать что хочешь и как хочешь. Fenom позволяет юзать даже объект $modx. It's up to you.
А в cron удаляем кэш и парсим страницу сниппетом
Что важно! В данном случае сам сниппет на странице вызывается некэшированным. Поэтому кэш самой страницы обновлять не нужно. Только кэш сниппета!!! Обратите внимание, насколько код стал проще.
Функция snippet() сама проверит кэш. Если его нет, то выполнит указанный сниппет и результат сохранит в кэш. И не нужно вычислять все эти секунды. Cron каждую неделю будет обновлять кэш независимо от того, есть он или нет. Поэтому сниппет differenceBetweenDatesInSeconds не нужен. И даже вреден. Ибо делает ненужную работу для каждого запроса страницы.
П.С. И ещё совет. Не пихайте логику во вьюхи. Это бад практис! Перенесите логику в сниппет и вызывайте его на странице.
Два. Забейте в поиск «pdoresources modx» и получите нужные ответы. Можно глянуть доку. Тут нужно обратить внимание на параметр «parents». Подсказка —
Это нужно вызывать в шаблоне статей.
pdoMenu работает с данными уже ввиде дерева, а не с плоским списком. Проще всего реализовать такое через Fenom. К сожалению, из коробки сниппеты pdoTools не умеют работать сырыми данными. Попробуйте разобраться с таким решением. Дальше как два пальца…
Моё мнение — выделить на него одну минуту, сняв шляпу и помолчав. RIP.
В таком формате xPDO вставляется без обработки.
П.С, Это json массив с одной строкой.
Обрати внимание на метод $app->run();
В нём вызываются конкретные классы. Причем, если не указан конкретный реквест, то он определяется автоматически по установленным пакетам (я выше писал).
А мне безумно нравится. В пекло PHP 5. ))
Найн. Ю а ронг.
Интерфейсы дают малую связанность. Т.е. ты можешь подсунуть в метод любой класс, соответствующий определенным требованиям. За это как раз и отвечает интерфейс.
У того же Slim эти классы пробрасываются при инициализации приложения. В нем жестко прописана проверка наличия нескольких пакетов. Сначала свой пакет, потом Guzzle и ещё какие то. Не помню. Но можно и самому инстанциировать любой свой класс запроса или ответа. Главное, чтобы соответствовал интерфейсу. Иначе будет ошибка.
Тройка ещё не соответствует. Например, $response->toJson() не соответствует стандарту. А вот четверка поддерживает почти все текущие утвержденные стандарты. После тройки приходится привыкать. И всякие методы обработки запроса и ответа выносить на сервисный уровень.
Не обязательно расширять сервис ради проверки прав. Мы можем сделать любую проверку самостоятельно
Правильно говорить именно RESTful API, но в народе уже прижилось неправильное название REST API.