Comments 8
UFO just landed and posted this here
Из текста понятно, что тот самый файл ajax.php из папки модуля это:
Единственное необычное место это проверка, что запрос действительно пришёл через xmlhttprequest.
Если в проекте много ajax-запросов, то для них можно сделать единую точку входа, в которой делать общую проверку на ajax/не ajax, запускать фреймворк и передавать управление в нужные файлы.
- запуск фреймворка
- обработка запроса
- отдача ответа
Единственное необычное место это проверка, что запрос действительно пришёл через xmlhttprequest.
Если в проекте много ajax-запросов, то для них можно сделать единую точку входа, в которой делать общую проверку на ajax/не ajax, запускать фреймворк и передавать управление в нужные файлы.
так не получится, в joomla нет общей точки входа для ajax и её туда не впилить. Каждый модуль это отдельная сущьность которую администратор сайт может включать, выключать, удалять. Если вы сами впилите туда общую точку входа то ваш модуль будет работать только у вас и никто его не сможет установить
Я говорил скорее о проектах, где решения создаются конкретно под нужды проекта, а не о разработке универсальных расширений для JED.
Допустим, мы говорим про очень кастомные магазины. Основная логика (клиенты, заказы, товары, атрибуты) кочует как база из проекта в проект. Но в каждом из них сильно дорабатывается. В какой-то момент, становится понятно, что очень много действий выполняются аяксом. Действия эти, при чём, сильно разные, например работа с корзиной, сравнение товаров, фильтрация списков, пагинация и т.д. Следственно и точки входа получаются разные: где-то это вью компонента, где-то модули (почему-то), использующие апи компонентов. Когда таких точек накапливается много, становится удобно сделать одну точку входа с запуском фреймворка и фильтрацией входящих запросов (по white-листу, например) и передачей управления.
Допустим, мы говорим про очень кастомные магазины. Основная логика (клиенты, заказы, товары, атрибуты) кочует как база из проекта в проект. Но в каждом из них сильно дорабатывается. В какой-то момент, становится понятно, что очень много действий выполняются аяксом. Действия эти, при чём, сильно разные, например работа с корзиной, сравнение товаров, фильтрация списков, пагинация и т.д. Следственно и точки входа получаются разные: где-то это вью компонента, где-то модули (почему-то), использующие апи компонентов. Когда таких точек накапливается много, становится удобно сделать одну точку входа с запуском фреймворка и фильтрацией входящих запросов (по white-листу, например) и передачей управления.
то ваш модуль будет работать только у вас и никто его не сможет установитьТо, что нужно.
так не получится, в joomla нет общей точки входа для ajax и её туда не впилить.Вообще общая точка входа есть, она же и точка входа для обычных запросов — это index.php. CMS предоставляет возможность обращаться к контроллерам компонентов без рендеринга общего шаблона. Но топик не об этом, а о том, как принимать запросы к модулям, где такого механизма нет и это совершенно правильно. Гораздо логичнее выглядит ситуация, когда модули используют API компонентов для получения данных. И ещё более естественно это выглядит когда модули поступают так же и при ajax-запросах.
Речь идет о разработке модуля для системы и если вы это делаете то должны соблюсти все правила которые эта систме предъявляет к модулю. Для чего это надо? Для того, чтобы ваш модуль работал с этой системой и не зависел от её обновления и прочего прочего.
Если ваш модуль будет работать только на вашем сайте потмоу как вы наставляли костылей в index.php то зачем он вообще? Я против такого костылеписания, если вы работаете с системой делай все в том стиле который заложили разработчики.
К справке в joomla модуль прекрасно может общаться с системой через апи компонента — это да, но для этого надо реализовать это апи, опять же если компонент не ваш то править чужой — идея плоха ибо при обновлении придется все корректировать.
Разработка очень кастомных магазинов идет другими путями и я бы вообще в ней joomla не применял, да и вообще разработка кастомного продукта имеет свои особенности.
Если ваш модуль будет работать только на вашем сайте потмоу как вы наставляли костылей в index.php то зачем он вообще? Я против такого костылеписания, если вы работаете с системой делай все в том стиле который заложили разработчики.
К справке в joomla модуль прекрасно может общаться с системой через апи компонента — это да, но для этого надо реализовать это апи, опять же если компонент не ваш то править чужой — идея плоха ибо при обновлении придется все корректировать.
Разработка очень кастомных магазинов идет другими путями и я бы вообще в ней joomla не применял, да и вообще разработка кастомного продукта имеет свои особенности.
Текст до ката вызвал из памяти вступление к защищенному недавно диплому :) Лаконично
За статью спасибо, пригодится
За статью спасибо, пригодится
Слегка оффтоп:
Когда люди говорят об ajax в Joomla, всегда рассказывают про component.php и почти никогда про view.raw.php и view.json.php. Эти файлы в компонентах являются точками входа наравне с view.html.php. В Joomla есть несколько типов генерируемых документов, кроме JDocumentHTML есть так же JDocumentRaw и JDocumentJSON (и другие), и именно они бывают полезнее для обмена данными (а не HTML-кодом) между клиентом и сервером.
Это не в тему поста, но впечатление, что весь ajax в Joomla сводится к отдаче HTML-вывода компонента без общего шаблона сайта это не хорошо.
Когда люди говорят об ajax в Joomla, всегда рассказывают про component.php и почти никогда про view.raw.php и view.json.php. Эти файлы в компонентах являются точками входа наравне с view.html.php. В Joomla есть несколько типов генерируемых документов, кроме JDocumentHTML есть так же JDocumentRaw и JDocumentJSON (и другие), и именно они бывают полезнее для обмена данными (а не HTML-кодом) между клиентом и сервером.
Это не в тему поста, но впечатление, что весь ajax в Joomla сводится к отдаче HTML-вывода компонента без общего шаблона сайта это не хорошо.
Sign up to leave a comment.
AJAX в Joomla 2.5