JController and its subclass usage overview/es

Prefacio

Debes estar familiarizado con el Patrón MVC de Joomla! antes de leer este artículo.

Introducción

En Joomla! 2.5 y 3.x, se agregaron muchas mejora al patrón MVC. Estas mejoras hacen, al desarrollador, la tarea más fácil. En Joomla! 1.5, sólo hay una clase Controlador con nombre JController. En Joomla! 2.5, se agregaron JControllerAdmin y JControllerForm como subclases de JControllerLegacy. Así que hay un uso diferente para estas tres clases en el desarrollo de componentes de Joomla! . Este es un modelo utilizado por la mayoría de los componentes principales de Joomla!, tales como com_content y com_banners.

		y más reciente
JController	JController (desde 2.5.5 se usa JControllerLegacy por compatibilidad)	JControllerLegacy
	JControllerAdmin	JControllerAdmin
	JControllerForm	JControllerForm
		JControllerBase (nuevo MVC)

Si miras en el código para el administrador de com_content, encontrarás que las clases del controlador se encuentran en dos lugares: la carpeta raíz y la carpeta de los controladores. En la carpeta raíz hay un archivo llamado 'controller.php', este es el controlador maestro del componente. Es una subclase directa de JControllerLegacy. En la carpeta de los controladores, hay muchos archivos con el nombre de acuerdo a las entidades en el componente por ejemplo, article y articles. Estos controladores son subclase tanto de JControllerAdmin como de JControllerForm.

Controlador maestro

El controlador maestro se encuentra en la carpeta raíz sólo es responsable de la visualización de la tarea. Esta es la tarea por defecto para JControllerLegacy. Si miras JControllerLegacy::getInstance en com_content/content.php, sólo el nombre del componente se pasa como parámetro. En JControllerLegacy, se utiliza la variable como tarea (a partir de la solicitud) para determinar la clase de que Controlador se va a cargar. Si la tarea de la variable contiene un punto (.), se supone que esta variable está en el formato controlador.tarea o controlador.método. Debes saber que la variable de la tarea especifica el método del controlador a ejecutar. Entonces en este caso, se carga la clase del controlador en la carpeta controllers y se vuelve a escribir la variable de la tarea con la variable real de la tarea. Si la tarea no contiene un punto (.), JControllerLegacy carga el controlador maestro que se encuentra en la carpeta raíz. Para simplificar, nos referiremos a los controladores en la carpeta 'controllers' como subcontroladores. Puedes ver que en el controlador maestro, que también se especifica una vista predeterminada. Si no hay ninguna variable de vista en la solicitud de la URL, esta va a ser utilizada. Así que en general, podemos concluir:

• Para utilizar el controlador maestro, especifica una variable de vista como el nombre de la vista para su uso o como valor predeterminado.
• El uso de un subcontrolador, se especifica la variabel de la tarea en la forma de controlador.tarea, claramente especificado CONTROLADOR_NOMBRE.CONTROLADOR_MÉTODO.

Podemos clasificar lo mostrado en dos tipos: la presentación de una lista de registros (vista de lista) y mostrar un registro de un ítem detallado al usuario (por ejemplo, formulario editar). Si nos fijamos en la vista de los artículos en com_content que muestra una lista de registros al usuario, podemos observar que en la barra de herramientas los botones se agregan de acuerdo a los derechos de usuario.

$JOOMLA_INSTALL/administrator/components/com_content/views/articles/view.html.php

 protected function addToolbar()
 {
   ...

   if (($canDo->get('core.edit')) || ($canDo->get('core.edit.own'))) {
     JToolBarHelper::editList('article.edit');
   }

   ...
  }

Por ejemplo, para editar un artículo la variable de la tarea será el article.edit. Esto hará que el subcontrolador article sea cargado y el método edicit sea ejecutado. Puedes tener una pregunta, esto significa que vamos a mostrar el formulario de edición al usuario. Eso es correcto! En general podemos hacer eso, pero en el componente principal de Joomla! 2.5, se establece el identificador de artículo a editar en la sesión del usuario y lo redirige a una URL como &view=article&layout=edit. Y esto será manejado por el controlador maestro y el formulario de edición será presentado al usuario. Así que en este caso, todo será manejado por el controlador maestro y las vistas necesarias.

• Si el nombre de una vista no está definido en la URL, la vista predeterminada se utiliza y una tarea predeterminada (mostrar) será ejecutada. La que se usa para mostrar una lista de registros. Por ejemplo, index.php?option=com_content.
• Si una vista es definida, pero la tarea no, el controlador maestro carga la vista especificada y ejecuta el método de visualización. Esto también se utiliza para mostrar una lista de registros. Por ejemplo, index.php?option=com_content&view=articles.
• Si una vista es especificada con una tarea (pero no en el formato de punto), el controlador maestro carga la vista especificada y ejecuta el método especificado por la tarea. Este caso se utiliza para mostrar el formulario de edición, o para presentar un ítem del registro de usuario. Un ejemplo es el index.php?option=com_content&view=article&layout=editar.

Cuando el controlador maestro crea una vista, normalmente carga un modelo con el mismo nombre que la vista y empuja el modelo en la vista. Entonces se llama al método de visualización de la vista. Haciendo esto, en la vista podemos obtener los datos a partir del modelo usando la función $this->get("Items"). En este caso, la vista buscará el método getItems en el modelo y lo ejecutará. Haciendo esto, podemos usar un controlador para mostrar todo tipo de información en el componente. Pero muchas vistas. Esto reduce la clase controlador y, por supuesto, reduce el código producido por el desarrollador.

Subcontroladores

Los subcontroladores se encargarán de todas las tareas CRUD. Para tareas tales como guardar, eliminar y publicar donde claramente no se necesita una vista, el subcontrolador sólo elimina o actualiza los registros y redirige al usuario a la vista de lista. En este caso, el usuario debe seleccionar al menos un elemento del registro, y se le suele dar el nombre del controlador en forma plural, como "articles.delete", "articles.publish_up" o "articles.publish_down". Este subcontrolador es generalmente heredado de JControllerAdmin que suprime el método de visualización de forma predeterminada.

El otro tipo de CRUD, tales como agregar o editar, a primera vista debe preparar los datos y presentar el formulario al usuario. Pero en el componente núcleo de Joomla! 2.5, no lo hicieron. Mirando este tipo de subcontroladores (por ejemplo ContentControllerArticle) uno puede ver que siempre se heredan de JControllerForm. Pero no es presentado al usuario en esta solicitud, sólo almacena el ítem (el ID del artículo) en la variable de sesión del usuario y la redirige a un controlador maestro. Como una variable de tarea que no se ha especificado, el método de visualización se ejecuta como una tarea predeterminada.

Por ejemplo: primera la solicitud procesada por el subcontrolador puede contener task=aricle.edit y cid[]=3. El subcontrolador creará una URL como "index.php?option=com_content&view=article&layout=edit " y redirige al usuario a un controlador maestro.