Joomla Terminology: просмотр, компоновка, создание задачи и компонентов

Question

Я разработчик, и я очень уверен в шаблоне MVC и уже разработал много веб-приложений с нуля, используя php-инфраструктуру, такую ​​как symfony или yii.

Я немного смущен про joomla mvc и терминологию, и после многого поиска, прочитайте руководство по расширению книг Joomla, прочитайте на веб-сайте joomla, мои сомнения все еще существуют.

Что меня смущает структура компонента mvc и как мне нужно настроить «мой способ мыслить» о joomla mvc, чтобы делать вещи в стиле joomla.

В частности, я привык к аргументации с точки зрения контроллера/действия (например, в Symfony и фреймворка)

Таким образом, окончательный список всех моих WebAPP URL будет

controller1/action1 
controller1/action2 
controller1/action3 

controller2/action1 
controller2/action2 

Каждое действие контроллера будет определять, какой вид рендеринга и какой макет использовать для отображения вида. В частности, в этих рамках определение макета - это в точности среднее значение макета. И представление является «основной частью» страницы.

Таким образом, у меня есть представление со списком пользователей, и я могу поместить это представление в макет мобильного устройства или макет рабочего стола или создать представление для мобильных устройств и поместить его только в макет мобильного устройства и так далее.

Окончательный результат о структуре каталогов в моем веб-приложение что-то похожее на следующее:

controllers/ 
    controller1 
    controller2 
    controller3 
models/ 
    modelForTableA 
    modelForTableB 
views/ 
    controller1/ 
    viewForAction1 
    viewForAction2 
layouts/ 
    mobileLayout.php 
    desktopLayout.php 

и для меня очень ясно понять.

Итак, наконец, мои вопросы:

• как бы структура каталогов в Joomla?
• что в joomla определение вида, макета и задачи?

Мне нужно уточнить, что мне не нужно объяснять работу MVC в целом, но если бы я достиг такого же результата, как и раньше, как мне организовать мой код и мою работу?

Предположим, что я хочу создать компонент со следующим "URL"

userController/addUser 
userController/editUser 
userController/listUsers 
userController/viewUserDetail 

anotherController/addOperation 
anotherController/editOperation 
anotherController/myNonCrudOperation 

Спасибо очень

Answer 1

решил с этим. Я не могу удалить этот вопрос, потому что уже существует другой ответ. Может ли любой модератор закрыть или удалить это? Спасибо

https://joomla.stackexchange.com/questions/18774/joomla-terminology-view-layout-task-and-component-development/18799#18799

Answer 2

Малый прозрение,

1) Структура каталогов

controllers/ 
     controller1 
     controller2 
     controller3 
    models/ 
     modelForTableA 
     modelForTableB 
    views/ 
     layout1 

2) Вид и макет и задача

проверка этого answer

3) Подробнее о маршрутизации techniques с SEF.

Надеюсь, это поможет.

Answer 3

Маршрутизация в Joomla несколько отличается. URL-адреса SEF создаются из пунктов меню, которые, в свою очередь, указывают на комбинацию View/Layout.
Это приводит к тому, что контроллер не связан с конкретным представлением/компоновкой.

Приведем пример потока с приведенной в качестве примера функцией addUser; Я буду ссылаться на эти файлы (но вы будете иметь много больше):

/controllers/user.php 
/models/user.php 
/views/useradd/view.html.php 
/views/useradd/tmpl/default.php 
/views/useradd/tmpl/default.xml 
/controller.php 
/router.php 

Как вы можете увидеть макеты внутри tmpl папки для каждого вида.

router.php

Начнем с последнего файла: router.php определяет наш обычай SEF правила так, после того, как Joomla проходит вызов нашего компонента (обычно с Params ?option=com_componentname) мы можем захват и интерпретировать URL, как мы желаем. С этим немного сложно начать, но обеспечивает максимальную гибкость и мощность. Нам действительно не нужно реализовывать его вообще для этого простого примера: так что вернемся к нашей регистрации сейчас.

Первый шаг: показать форму «новый пользователь».

Обычно вы связываете это с пунктом меню, указывая на /views/useradd/tmpl/default.php; /views/useradd/tmpl/default.xml содержит определение макета, поэтому оно доступно в диспетчере меню. Очень часто для представления есть только один макет.

Элемент управления передается в представлении /views/useradd/view.html.php, и представление затем загружает экземпляр своей собственной модели (автоматически выбирается на основе имени представления, вы можете загружать другие модели, конечно) для сбора любых данных инициализации.

Вид затем отображает макет и представляет его пользователю. Ответственность компоновщика включает в себя генерирование формы соответствующей action (конечной точки) и маркеры безопасности в соответствующих случаях:

<form action="index.php?option=com_mycomponent"> 
<input type="hidden" task="user.save"> 
<?php echo JHtml::_('form.token');?> 

, как вы видите, что на самом деле не имеет значения, если вы хотите использовать <input или Params на URL, и вы можете чаще их смешивать.

форма взаимодействия

Для автозавершения форма может потребоваться вызвать некоторые методы контроллера бэкенд, то есть метод emailAvailable() в /controllers/user.php

Это не имеет смысла иметь такие функциональные индексируются, так что мы Вызовите метод непосредственно с кодом, отличным от SEF:

index.php?option=com_ourcomponent&task=user.emailAvailable 

, за которым следует любой другой параметр. Это будет работать как на получение, так и на пост.

emailAvailable() метод контроллера /controllers/user.php «s вернет json структуру и затем вызвать exit() как мы не хотим, чтобы CMS пнуть вовсе. Альтернативным решением является добавление параметра &format=json в вызов.

{"email":"johndoe@example.com", "available":true} 

Сохранение данных

Когда пользователь отправляет форму, обработку сначала обрабатывается контроллером, так как указано задача. (см. выше task=user.save). Joomla вызовет метод save() в контроллере /controllers/user.php.

На этот раз, однако, наш контроллер несет ответственность за возврат информации пользователю. После обработки данных он может выбрать повторную визуализацию формы регистрации, отображающей сообщение об ошибке, или страницу с благодарностью. В любом случае контроллер просто устанавливает перенаправление, позволяя Joomla обрабатывать рендеринг, когда это необходимо.

$this->setRedirect(JRoute::_('index.php?option=com_yourcomponent&view=useradd', false)); 

Больше контроля

Каждый раз, когда задача контроллера не указана, display() метод главного контроллера вызывается. Вы можете добавить туда свою логику.

Joomla запускает несколько событий во время рендеринга представления; они могут быть перехвачены системным плагином или - если вы добавите в вызовы другие плагины. Вы даже можете создавать свои собственные типы плагинов. Не пытайтесь создать экземпляр представления вручную с контроллера, поскольку это может препятствовать запуску плагина.