На сколько такое решение приемлимо?
В зависимости от проекта и выделенного времени варьируется и оценка.
Я бы оценил его как "Неудовлетворительный, находящийся на гране допустимного, но решающий исходный запрос".
Ваш подход может существовать, однако на Code review у нас бы его завернули с пометкой "Все переделать".
Есть ли какие то более правильные, гибкие архитектурные решения?
Вариантов на вкус и цвет, начиная от родного AJAX => 'Y' параметра в компоненте и его работы и заканчивая javascript rendering.
Замечательным вариантом было бы:
- Чтобы тег #orders-block рендерил компонент d6core:custom.order.list. Т.е. он был бы самодостаточным.
- Не создавалась бы отдельная страница под "ajax.php", а использовались бы контроллеры компонентов (хотя бы)
- Возвращалось как можно меньше данных, т.е. структуры данных, а не верстка.
Конечно интересует здесь и вопросы ИБ.
Контроллеры компонентов по-умолчанию имеют защиту от CSRF, а так же можно установить проверки на авторизацию (только от авторизованных пользователей), проверку на метод запроса (POST/GET), проверку на пользователя (передавать его в signedParams).
Почитайте про контроллеры, там много интересного написано.
Тогда вопрос, зачем делать такую обертку если я могу тупо тянуть данные из $_POST напрямую?
Например потому что при обработке запроса глобальный $_POST может поменять любой скрипт выполняющий до вашего, а HttpRequest содержит исходную информацию которая была отправлена на сервер.
Или потому что при обращении к несуществующему ключу $_POST выдается notice-сообщение, а HttpRequest корректно возвращает null.
Если ваша функция или метод работает с $_POST, то в случае объекта вы можете указать что ожидается HttpRequest и знать что придет именно параметры запроса и что там будут гарантированно методы getPost и т.п., а в случае с $_POST вам могут направить туда что угодно с какими угодно ключами.
