Joomla! Documentation - User contributions [en]

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/Page display title/it

2023-05-27T13:35:05Z

Ing Pulizzi:

J3.x:Sviluppo di un Componente MVC / Aggiornamento a Joomla 4

J3.x:Developing an MVC Component/Upgrading to Joomla4/it

2023-05-27T12:48:26Z

Ing Pulizzi: Created page with "===Caricamento automatico della classe=== Joomla utilizza il meccanismo PHP per [https://www.php.net/manual/en/language.oop5.autoload.php Classi di caricamento automatico] e..."

<noinclude><languages /></noinclude>

{{:J3.1:Developing an MVC Component/it}}
Questo passaggio copre ciò che è coinvolto nell'aggiornamento del codice del tutorial per allinearlo con la versione 4 di Joomla.

== Introduzione ==
Questa pagina descrive i principali aspetti relativi allo sviluppo dei componenti che sono stati introdotti in Joomla 4 e descrive in dettaglio cosa è stato modificato nel codice del tutorial per allinearsi con v4.

Non è pratico dettagliare tutte le modifiche al codice sulla pagina Web come è stato fatto per i passaggi precedenti dell'esercitazione. Invece puoi trovare il codice come repository github su [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial Joomla 4 Tutorial code], e puoi confrontarlo con il codice del passaggio precedente del tutorial (Adding Custom Fields) su [https://github.com/robbiejackson/Joomla-3-MVC-Tutorial Joomla 3 MVC code]. Il codice di Joomla 4 replica tutte le funzionalità del codice di Joomla 3, con l'eccezione dell'implementazione dell'icona del piccolo pinguino introdotta in [[S:MyLanguage/J3.2:Developing an MVC Component/Adding decorations to the backend|Aggiunta di decorazioni al backend]] (che non è così rilevante data la modifica dell'interfaccia utente in Joomla 4 Administrator) e l'uso di un plug-in CAPTCHA ([[J3.x:Developing an MVC Component/Adding a frontend form|Adding a frontend form]] ). Probabilmente troverai utile avere a portata di mano questo codice Joomla 4 a cui fare riferimento mentre leggi questa pagina.

Il codice per questo passaggio è stato sviluppato seguendo ciascuno dei precedenti passaggi del tutorial e cercando di far funzionare ogni passaggio con Joomla 4.2.5. Poiché Joomla 4 si sta ancora evolvendo abbastanza velocemente, è possibile che alcuni aspetti qui citati vengano modificati durante la vita di Joomla 4. Sentiti libero di correggere gli aspetti in questa pagina e creare richieste pull su [https://github.com/robbiejackson /Joomla-4-MVC-Tutorial Joomla 4 github repository].

Se stai installando il codice del tutorial di Joomla 4 su una nuova istanza di Joomla, dovrai configurare la tua istanza per renderla multilingue e aggiungere le voci di menu nascoste di Ajax come descritto nel passaggio [[J3.x:Developing an MVC Component/ Utilizzo del filtro della lingua |Utilizzo del filtro della lingua]]. Assicurati inoltre che ogni record helloworld abbia una categoria valida.

=== Ulteriori letture ===
Puoi trovare [https://blog.astrid-guenther.de/en/der-weg-zu-joomla4-erweiterungen/ qui] un tutorial per lo sviluppo dei componenti di Joomla 4, simile a questo Joomla 3, e alcuni eccellenti Joomla 4 è disponibile anche la documentazione [https://www.dionysopoulos.me/book.html qui]. Entrambi questi riferimenti includono descrizioni degli impatti di Joomla 4 sullo sviluppo di altri tipi di estensioni Joomla (plugin, moduli e modelli), che non sono trattati qui.

Questo passaggio non copre tutto ciò che è necessario per aggiornare un componente da Joomla 3 a Joomla 4, solo gli aspetti coperti dal codice del tutorial. Se stai aggiornando il tuo componente Joomla 3, potresti trovare utile esaminare [[Potenziali problemi di compatibilità con le versioni precedenti in Joomla 4]].

== NameSpace ==
===NameSpace dei nomi dei componenti===
I NameSpace delle classi che utilizza la [https://www.php-fig.org/psr/psr-4/ PSR-4 recommendation] è stato gradualmente introdotto durante le versioni di Joomla 3 e con Joomla 4 è praticamente tutto con NameSpace

Ora è previsto che anche le estensioni di Joomla utilizzino i NameSpace di base per l'estensione definito nel suo file XML manifest. I componenti di Joomla usano uno NameSpace della forma <tt>Joomla\Component\<Nome componente></tt> es. <tt>Joomla\Component\Content</tt>, quindi seguendo questo schema ho dato una base al codice del tutorial spazio dei nomi di <tt>Robbie\Component\Helloworld</tt>. Ecco la riga nel file manifest helloworld.xml:

<namespace path="src">Robbie\Component\Helloworld</namespace>

(L'attributo <tt>path="src"</tt> indica che si aspetterà che le classi si trovino nella sottocartella <tt>src</tt>.)

Questo in realtà crea 2 prefissi dello spazio dei nomi, che puntano a cartelle specifiche nella nostra struttura di sviluppo helloworld e nella nostra istanza joomla live:

<tt>Robbie\Component\Helloworld\Administrator</tt> – punterà ad administrator/components/com_helloworld/src sull'istanza live ed è associato ad admin/src nella nostra area di sviluppo.

<tt>Robbie\Component\Helloworld\Site</tt> – punterà a components/com_helloworld/src sull'istanza live ed è associato a site/src nella nostra area di sviluppo.

Quindi Joomla ora si aspetta che tutti i nomi delle classi vengano trovati in quelle directory di base, con il nome del file che corrisponde al nome della classe e il nome della classe completo che corrisponde al percorso, ad esempio

<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> si troverà in
administrator/components/com_helloworld/src/Controller/DisplayController.php

<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> si troverà in
components/com_helloworld/src/Model/CategoryModel.php

'''Nota che le lettere maiuscole sono importanti nei namespace, nei nomi delle classi e nei nomi dei percorsi!'''

Quando Joomla 3 ha voluto chiamare le funzioni nel tuo componente, ha cercato determinati nomi di file in cartelle particolari e ha verificato che il nome della classe in quel file corrispondesse a quello previsto.

In Joomla 4 genera il nome completo della classe che vuole trovare, quindi cerca di trovarlo nella posizione in cui la raccomandazione PSR-4 lo aspetterebbe.

Quindi il namespace che specifichi nei tuoi file di classe deve essere allineato con il percorso del tuo file PHP, sotto la cartella di base <tt>src</tt> nel prefisso del tuo namespace.

Si noti in particolare come sono ora organizzati i file della classe <tt>View</tt>.

Inoltre, se usi una delle classi predefinite di PHP (ad es. <tt>Exception</tt>) nel tuo codice, aggiungi una barra rovesciata prima di essa (ad es. <tt>\Exception</tt>), altrimenti PHP cercherà di trovare nel tuo spazio dei nomi.

Se utilizzi definizioni di campi o regole personalizzate nei tuoi file xml del modulo, devi indicare a PHP quale prefisso dello spazio dei nomi utilizzare per cercarli, ad esempio in <tt>site/forms/add-form.xml</tt>:

addruleprefix="Robbie\Component\Helloworld\Administrator\Rule"
addfieldprefix="Robbie\Component\Helloworld\Administrator\Field"

e anche in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> dove le associazioni vengono aggiunte dinamicamente al modulo per formare il campo di tipo <tt>modal_helloworld</tt> personalizzato:

$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');

===Caricamento automatico della classe===
Joomla utilizza il meccanismo PHP per [https://www.php.net/manual/en/language.oop5.autoload.php Classi di caricamento automatico] e all'avvio registra una serie di caricatori automatici, funzioni che vengono chiamate quando PHP non riesce a trovare una data classe. In particolare la funzione di Joomla PSR-4 autoloader (in <tt>libraries/loader.php</tt>) è responsabile della ricerca di classi di estensioni Joomla il cui codice si trova nei file sorgente che sono organizzati secondo la raccomandazione PSR-4. (Le classi della libreria Joomla vengono caricate automaticamente utilizzando un caricatore automatico diverso – vedi <tt>libraries/vendor/composer/autoload_static.php</tt>).

<div lang="en" dir="ltr" class="mw-content-ltr">
You can see the namespace prefixes of extensions on the Joomla instance by looking at <tt>administrator/cache/autoload_psr4.php</tt>. (These namespace strings have double backslashes, but in PHP they're the [https://stackoverflow.com/questions/25459197/single-or-double-slash-when-using-php-namespace same strings as those with single backslashes]). This is generated by Joomla looking through the component, module and plugin directories to find each extension's manifest file, and then processing these xml files to extract the <tt><namespace></tt> element – quite a lot of work, which is why it's cached I guess!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider what happens when Joomla wants our admin HelloworldController class. It might have something like
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$classname = 'Robbie\Component\Helloworld\Administrator\Controller\HelloworldController'
if (!class_exists($classname)) { …
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Assuming PHP doesn't already know about this class, the <tt>class_exists</tt> function will result in the classname being passed to the registered autoload function(s). The PSR-4 autoloader will then:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# go through its array of namespaces to try and match <tt>$classname</tt> from the start of the string.
# find 'Robbie\Component\Helloworld\Administrator' as a match
# see that this maps to "administrator/components/com_helloworld/src"
# extract the remainder of the classname: 'Controller\HelloworldController'
# treat this as the path down to the class file
# and so look for "administrator/components/com_helloworld/src/Controller/HelloworldController.php"
# check that in this file there's actually a class with that namespace + class name.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So in this way Joomla can go from a fully qualified class name to find the source code for that class. This makes it easier for us too when the core Joomla code is looking for one of our classes. We still need to know what class it's looking for, but once we know that, we know what we should call our class and where we should save the source code for it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Joomla Library classes===
Originally Joomla's core classes (beginning with a capital J) were global classes. Over the Joomla 3 versions and into Joomla 4 these migrated to their namespaced equivalents, but the original global classnames were still available as Joomla registered them as aliases (in the <tt>libraries/classmap.php</tt> file).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In a Joomla 4 extension you can still use these global classnames, except that in a namespaced file you'd have to prefix the name with a backslash to indicate a global class rather than one in your namespace (eg <tt>\JFactory</tt> instead of <tt>JFactory</tt>).
However it's pretty definite that the aliases will disappear at some stage, so the upgrade to Joomla 4 seems an appropriate opportunity to replace all your component's calls to the global JSomething classes to the namespaced equivalents. This involves adding the appropriate <tt>use</tt> statements, and all this has been done in the tutorial code. A useful mapping between the two can be found [https://github.com/nikosdion/joomlatypehints/blob/main/JoomlaObsoleteClasses.md here], where the new qualified classname can be copied and pasted into a <tt>use</tt> statement in your PHP file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
With reference to the [https://api.joomla.org/ Joomla API Documentation] there are 2 Joomla library namespaces:
* Joomla CMS classes – have namespaces <tt>Joomla\CMS\Something</tt> – are found under <tt>libraries/src/Something</tt>
* Joomla Framework classes – have namespaces <tt>Joomla\Something</tt> – are found under <tt>libraries/vendor/joomla/something/src</tt>
So a big advantage of namespacing is that you can immediately determine from the fully qualified class name in a PHP <tt>use</tt> statement where the source for that class exists in the <tt>libraries</tt> directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
On the other hand class names which aren't fully qualified don't have to be unique, eg <tt>MVCFactory</tt>
* occurs as <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in <tt>libraries/src/Extension/Service/Provider/MVCFactory.php</tt>
* occurs as <tt>Joomla\CMS\MVC\Factory\MVCFactory</tt> in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>
so sometimes you have to be careful to examine the <tt>use</tt> statement to identify the right class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly our FormModel class in <tt>site/src/Model/FormModel.php</tt> can have the same FormModel classname as the Joomla FormModel in <tt>libraries/src/MVC/Model/FormModel.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The API documentation gives the methods available in each of the [https://api.joomla.org/cms-4/namespaces/joomla.html Joomla CMS] and [https://api.joomla.org/framework-2/namespaces/joomla.html Framework] classes, but just be aware that a Joomla CMS class may extend a Framework class, and in this case some methods may not be visible under the Joomla CMS documentation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For example, <tt>$app->setHeader()</tt> which is used to set the HTTP response code is not listed under the [https://api.joomla.org/cms-4/classes/Joomla-CMS-Application-CMSApplication.html CMS Application class API], but is available as a method because it inherits from the Framework class [https://api.joomla.org/framework-2/classes/Joomla-Application-AbstractWebApplication.html AbstractWebApplication].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Vendor Namespaces===
These are also in <tt>libraries/vendor</tt>, eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Psr\Container\ContainerInterface;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
refers to <tt>libraries/vendor/psr/Container/src/ContainerInterface.php</tt>. However there are few of these in the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other File Rearrangements===
With all of the namespaced classes moving under the src directories, the <tt>tmpl</tt> layout files and <tt>form</tt> xml files have been moved out into their own directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Extension and Dispatcher classes ==
===Extension===
In Joomla 3 the point where the Joomla core handed over to your component code was when it ran your <tt>helloworld.php</tt> code; if it was the frontend it ran your site <tt>helloworld.php</tt> code, or if was the backend it ran your admin <tt>helloworld.php</tt> code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the entry point into your component code is your Extension class, both for site and admin, found in <tt>admin/src/Extension/HelloworldComponent.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When the Joomla core application wants to start executing the component code it creates an instance of <tt>HelloworldComponent</tt>, just to get a handle on the component code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly (as described below) other Joomla classes such as Router or Categories need to call certain Helloworld methods (eg custom router functions). In Joomla 3 these methods were written in certain Helper files etc. In Joomla 4 the principle is that the component creates an instance of the <tt>HelloworldComponent</tt> Extension class, and calls the required methods on that instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This Extension class isn't anything like a big container class for the component, it's more like a glue class, providing a way in to the Helloworld component, enabling the Joomla core and other components call the methods which they want to call.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla core wants to execute the component code, the key method it is looking for in your <tt>Extension</tt> instance is <tt>getDispatcher</tt>, and it expects to get back a <tt>Dispatcher</tt> instance. The <tt>HelloworldComponent</tt> extends <tt>MVCComponent</tt>, which in turn extends <tt>Component</tt>, and it is this class which defines <tt>getDispatcher</tt> for us.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Dispatcher===
When Joomla wants to run the Hello World component, it gets the <tt>Dispatcher</tt> instance as described above and then calls the <tt>dispatch</tt> method on it. It is this <tt>dispatch</tt> function which replaces the functionality in the admin and site <tt>helloworld.php</tt> files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's look at the main lines of code in our Joomla 3 admin <tt>helloworld.php</tt> file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="site/views/form/view.html.php">
<syntaxhighlight lang="php">
if (!JFactory::getUser()->authorise('core.manage', 'com_helloworld'))
{
throw new Exception(JText::_('JERROR_ALERTNOAUTHOR'));
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Get an instance of the controller
$controller = JControllerLegacy::getInstance('HelloWorld');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Execute the Request task method
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Redirect if set by the controller
$controller->redirect();
</syntaxhighlight>
</span>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code
* performs some permissions checks
* instantiates the appropriate Helloworld controller
* executes the appropriate method in that controller
* implements any redirect set by the controller
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Model-View-Controller]] for further details of how this works in Joomla 3. The second and third steps used the <tt>task</tt> parameter within the URL query to determine the correct controller class to instantiate and method to call. If no <tt>task</tt> parameter was present then it instantiated the controller in <tt>controller.php</tt> and called the <tt>display</tt> method. Otherwise it instantiated one of the controllers in the <tt>controllers</tt> subfolder (eg <tt>controllers/helloworld.php</tt>) and called the appropriate method on it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>ComponentDispatcher::dispatch</tt> method (in <tt>libraries/src/Dispatcher/ComponentDispatcher.php</tt>) now provides this functionality, but in a nicer way. After checking the permissions it uses the <tt>task</tt> by considering its parts as <tt><controller type>.<method></tt> (taking 'display' as default if either part is missing). It will then pass control to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* an instance of the class <Controller type>Controller
* calling the function <method>
* using the admin or site controller, as appropriate
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In this way the naming of the controllers is consistent - we have DisplayController, HelloworldController and HelloworldsController, all in the same folder.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Dispatcher class can thus be considered as providing some 'routing - execution' functionality, enabling us to find the right controller and function within that controller, and it is cleaner to have this in a separate class rather than in the <tt>JControllerLegacy</tt> class as it was in Joomla 3.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Since the Hello World tutorial uses the standard Joomla pattern for selecting the class and method based on the <tt>task</tt> and has the same permissions checks, we can use the <tt>dispatch</tt> code as it stands in <tt>ComponentDispatcher</tt>, and don't need to define a special class of our own.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Factory classes ==
In Joomla 3 many classes had static <tt>getInstance</tt> methods which returned an instance of that class, configured with the parameters passed to <tt>getInstance</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the <tt>getInstance</tt> methods have been deprecated in favour of using Factory classes. The preferred mechanism is now to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* get an instance of the appropriate Factory class (how we do that is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below)
* call the <tt>createSomething()</tt> method of the Factory class with relevant parameter values to generate an instance of the Something class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===MVC Factory===
In this section the <tt>MVCFactory</tt> class refers to the one in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory class will instantiate Controller, View, Model and Table instances on our behalf, and it does this by generating the classname of the class and then calling <tt>new</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The way it works is as follows:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Each component gets an individual MVCFactory instance which is constructed passing the component's namespace as a parameter (so in our case 'Robbie\Component\Helloworld'). (How this MVCFactory instance is created is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below).
# The MVCFactory createController / createView / createModel / createTable function is then called, passing the name of the Controller / Model / View / Table and the prefix (which specifies whether the administrator or site class is required).
# The create function forms the classname from this data and calls <tt>new</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory create functions just form the classname from the parameters they're passed. The intelligence for working out what name and prefix should be used to form the appropriate classes for an incoming HTTP request is
* in the dispatcher code for defining the controller to use
* in the controller for the view and model
* in the model for the table
and, for example, the names of the classes created for a request with URL query <tt>?option=com_helloworld&view=viewname</tt> and no <tt>task</tt> parameter will be
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<namespace>\Controller\DisplayController
<namespace>\View\Viewname\HtmlView
<namespace>\Model\ViewnameModel
<namespace>\Table\ViewnameTable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you need an alternative name then you can override the appropriate getView, getModel or getTable function – as for example was done in the [[J3.x:Developing an MVC Component/Adding Custom Fields#Front-end_Form|Adding Custom Fields step, frontend Form section]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So from the outside this is pretty much the same as in Joomla 3. However, note that the <tt>$prefix</tt> parameter in calls to <tt>getModel</tt> etc is subtly different
* in Joomla 3 this referred to a prefix to be applied to the classname – in the tutorial code we used 'HelloWorldTable' as the prefix part of the 'HelloWorldTableHelloWorld' classname.
* in Joomla 4 this refers to a prefix higher up the classname path, and should be set to either 'Site' or 'Administrator' (the capital letter at the start is optional), depending on whether you want the class under 'Robbie\Component\Helloworld\Site' or 'Robbie\Component\Helloworld\Administrator'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVC Factory class is now the Joomla recommended way to create the controller, view, model and table classes, by using the eg <tt>getModel()</tt> method, and the use of <tt>getInstance()</tt> for these classes is now deprecated. However, the use of these functions is restricted:
* in the controller class you can call <tt>$this->getView($viewname, $viewtype, $prefix, $config)</tt> to create a view and <tt>$this->getModel($modelname, $prefix, $config)</tt> to create a model.
* in the view class you can call <tt>$this->getModel($modelname)</tt>, but only for models which the controller has previously defined using <tt>$view->setModel($modelname, $default)</tt>. It doesn't create a new model instance.
* in the model class you can call <tt>$this->getTable($tableclass, $prefix, $options)</tt> to create a table instance. Controllers and views can access the table classes in this way, by going via a model.
These restrictions do have an impact on moving away from using <tt>getInstance()</tt>, and indeed in Joomla 4.2.6 you will still find several <tt>getInstance()</tt> calls within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Factory Classes===
Several other Factory classes have been introduced in Joomla 4, enabling you to get instances of core classes such as Form, User, CacheController, etc, usually by calling a createSomething function on the Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Associated with the Factory class is a FactoryInterface, a PHP Interface which specifies the key functions which the Factory class must implement. For example, with <tt>libraries/src/Categories</tt> we have:
* CategoryFactoryInterface – which specifies the <tt>createCategory</tt> function
* CategoryFactory implements CategoryFactoryInterface – which provides the <tt>createCategory</tt> function.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Dependency Injection ==
===Overview===
The DI container is one of the significant new additions to Joomla 4. It's basically a repository of key-value pairs where:
* the key is a string which is the name of a class or interface
* the value is an instance of the relevant class, or a function that returns an instance of that class.
You put things into the container using <tt>set()</tt> passing:
* the class name or interface name
* a function which returns an instance of the class (or an instance of the class)
* a boolean defining whether the class instance may be shared or not
* a boolean defining whether this entry into the DI container is protected or not (an error will be raised if you try to overwrite a protected entry by calling <tt>set()</tt> again using the same key).
The function <tt>share()</tt> is basically the same as <tt>set()</tt> with the <tt>shared</tt> boolean set to true.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You get things out of the container by calling <tt>get()</tt> passing the key of the resource you want. The container will
* find the key in the container
* if the value isn't already a class instance, then it will run the associated function to generate an instance of the class
* if the resource is shared, it will store the class instance, so that on subsequent invocations of <tt>get()</tt> it can just return the instance
* return the class instance to you
You can also define aliases for each key in the container, which means that you call <tt>get()</tt> passing either the key or an alias of the key.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The DI container is initialised in <tt>library/src/Factory.php createContainer()</tt> which results in the <tt>register()</tt> function being called in each of the class files in <tt>libraries/src/Service/Provider</tt>. By looking through those files you can see what gets put into the DI container upon initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===JConfig Example===
Let's consider the example of JConfig which holds the system global configuration. If you look inside <tt>libraries/src/Service/Provider/Config.php</tt> then you'll see the <tt>register()</tt> function and that it stores in the DI container a resource with:
* key = 'JConfig'
* value = an anonymous function - which loads what's in <tt>configuration.php</tt> into a <tt>Registry</tt> object, and returns it
* shared flag = true (because the <tt>share()</tt> function is used)
* protected flag = true
Then when you do
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$config = $container->get('JConfig');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will run the anonymous function and return the Registry object to you. As the 'shared' boolean is set it will also store a copy of the class instance locally in the container to be returned on subsequent calls of <tt>get('JConfig')</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Justification===
What's the point of all this?
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The advantage of dependency injection is that it allows classes to be easily mocked for testing. The file <tt>libraries/src/Service/Provider/Config.php</tt> can be replaced to return to a DI container <tt>get()</tt> call a mock class instead of the usual <tt>JConfig</tt>. This is in comparison to Joomla 3 where <tt>Factory::getConfig()</tt> code directly reads the <tt>configuration.php</tt> into a Registry structure and returns it – which makes it harder to mock.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The [https://api.joomla.org/cms-4/classes/Joomla-CMS-Factory.html Factory API] has several functions which are marked as deprecated with advice to get the object from the DI container instead.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Several of the other Factory classes (eg Form, Language, Menu, User) are in the DI container – so that we can get an instance of them via eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Factory::getContainer()->get('Joomla\CMS\Toolbar\ToolbarFactoryInterface')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to get a Toolbar instance. However, this only works for singleton classes which aren't specific to the needs of a particular extension. We'll see shortly how to make it work for class instances which need to be specific to a component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As indicated above, Joomla is moving away from using the class static <tt>getInstance()</tt> functions. We can see now that this is not only because it's more pure from an object oriented perspective. But also creating class instances from the DI container, or from Factory objects which are obtained from the DI container, builds in the dependency injection which allows classes to be more easily mocked, and hence more easily tested.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==services/provider.php==
We're now finally in a good position to understand what's happening in our services/provider.php file, and we'll explore this by walking through what happens whenever this line in libraries/src/Component/ComponentHelper.php <tt>renderComponent</tt> is run:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is run whenever Joomla has worked out which component is to be run on the requested web page, and it wants to run that component to capture its output.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 1 Create Child DI Container===
Joomla first creates another DI container (initially empty) just for this component, and links it to the main DI container via a parent field in the child DI container structure.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Now whenever <tt>set()</tt> is called on this DI container the key-value pair is inserted into the child container. Whenever <tt>get()</tt> is called on it, the resource is obtained from the child container, but if it's not found there then the parent container is searched also.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 2 Run register() in provider.php===
Next we encounter these lines (in <tt>libraries/src/Extension/ExtensionManagerTrait.php</tt>), where <tt>$path</tt> contains the path of our helloworld admin/services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$provider = require_once $path;
// Check if the extension supports the service provider interface
if ($provider instanceof ServiceProviderInterface) {
$provider->register($container);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here we see 3 things:
# our provider.php should return some object (so that <tt>$provider</tt> gets set to something)
# what is returned should implement ServiceProviderInterface (you can see in <tt>libraries/vendor/joomla/di/src/ServiceProviderInterface.php</tt> what is expected)
# the code then runs the <tt>register</tt> function on that object, passing as a parameter the child DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider a minimal version of our provider.php file. This would actually support steps in the Joomla 3 tutorial up to and including the [[J3.x:Developing an MVC Component/Adding AJAX|Adding Ajax step]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {

public function register(Container $container): void
{
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
}
};
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As you can see from the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
this file does indeed return something – it returns an instance of an anonymous class, one that implements <tt>ServiceProviderInterface</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it's not sufficient to just provide the <tt>register</tt> function in the class, we also need to explicity state that the class implements <tt>ServiceProviderInterface</tt>. This now happens in several places in Joomla, so if you're debugging your component and wondering why a function you expect to be called isn't being called, then check to make sure that you don't have to explicitly add the appropriate <tt>implements <Interface></tt> clause to your class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Next we look at the 3 lines in the <tt>register</tt> function
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3a Registering our MVC Factory===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here our <tt>MVCFactory</tt> refers to <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in libraries/src/Extension/Service/Provider/MVCFactory.php, and you should have a look at this file. This is a file similar to our provider.php file, but it's a named class, and it doesn't return anything. When we do:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
new MVCFactory('\\Robbie\\Component\\Helloworld')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it creates an instance of this class, and in the constructor it stores locally in <tt>$this->namespace</tt> our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>registerServiceProvider</tt> function then calls the <tt>register</tt> function of this instance, which runs (in its minimalist form):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
MVCFactoryInterface::class,
function (Container $container) {
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
return $factory;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So what gets entered into our child DI container is a key-value pair with:
* key = MVCFactoryInterface::class (this is just a shorthand form to obtain a string of the fully qualified name – ie 'Joomla\CMS\MVC\Factory\MVCFactoryInterface')
* value = a function which returns an instance of <tt>\Joomla\CMS\MVC\Factory\MVCFactory</tt>.
This is our MVCFactory class which generates our Controllers, Views, Models and Tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Notice that we're passing our namespace as a parameter <tt>$this->namespace</tt>. Because this function is a closure, this variable will still be available when we run this function later, and when the MVCFactory class is instantiated the namespace will be passed into the constructor, stored locally, and then subsequently used to form the fully qualified names of our Controllers, View, etc. So this is how we get instantiated the MVCFactory class which is specific to our component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3b Registering the Dispatcher Factory===
Careful: ComponentDispatcherFactory refers to two different classes here!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This ComponentDispatcherFactory is Joomla\CMS\Extension\Service\Provider\ComponentDispatcherFactory in libraries/src/Extension/Service/Provider/ComponentDispatcherFactory.php. Similar to the above, the ComponentDispatcherFactory service provider class stores locally our namespace, and then when <tt>register</tt> is called it executes:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentDispatcherFactoryInterface::class,
function (Container $container) {
return new \Joomla\CMS\Dispatcher\ComponentDispatcherFactory($this->namespace,$container->get(MVCFactoryInterface::class));
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so a second entry is added to the child DI container with:
* key = ComponentDispatcherFactoryInterface::class
* value = a function which returns an instance of the ComponentDispatcherFactory (the other ComponentDispatcherFactory class!), where the class constructor will be passed the namespace ('\\Robbie\\Component\\Helloworld') and an MVCFactory instance, retrieved from the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that the code
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->get(MVCFactoryInterface::class)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
will get from the container an entry with key = 'Joomla\CMS\MVC\Factory\MVCFactoryInterface' – which is what we entered into the container in step 3a – and will run the function associated with this key, and then return the object which this function returns. This returned object will be an instance of '\Joomla\CMS\MVC\Factory\MVCFactory', constructed using our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3c Including the Extension===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will put into the child DI container a key-value pair with
* key = ComponentInterface::class
* value = the function which will create an instance of our <tt>HelloworldComponent</tt> (ie our Extension class), and pass into the constructor an instance of the ComponentDispatcherFactory class, retrieving what was entered into the child DI container in Step 3b.
It will call <tt>$container->get(MVCFactoryInterface::class)</tt>, getting an MVC Factory instance from what was entered into the DI container in Step 3a.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It will then associate our component with this MVC Factory instance via the <tt>setMVCFactory</tt> call. Significantly this will then allow our component to access this instance later, via a call to <tt>getMVCFactory</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3 Summary===
We have now got 3 entries in our child DI container, keyed by
* key = MVCFactoryInterface::class, value is a function returning an MVCFactory instance
* key = ComponentDispatcherFactoryInterface::class, value is a function returning a ComponentDispatcherFactory instance
* key = ComponentInterface::class, value is a function returning our HelloworldComponent, an instance of our Extension class.
The important aspect is that these entries are all aware of our namespace '\Robbie\Component\Helloworld' and will return instances of these classes which are specific to our Helloworld component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 4 Retrieving from the DI Container===
Joomla will then execute the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $container->get($type);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
where <tt>$type</tt> contains 'Joomla\CMS\Extension\ComponentInterface'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This starts the process of retrieving from the DI container the 3 entries which we put in, and will run our code in services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We end up with a HelloworldComponent instance, which has:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. a ComponentDispatcherFactory instance passed into the constructor, and which is saved locally by the constructor code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function __construct(ComponentDispatcherFactoryInterface $dispatcherFactory)
{
$this->dispatcherFactory = $dispatcherFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This code is in libraries/src/Extension/Component.php, in the class which our HelloworldComponent extends, via the class MVCComponent).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. an MVC Factory instance, stored by the HelloworldComponent <tt>setMVCFactory</tt> call
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 5 Call boot() on our Component===
Joomla calls:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
if ($extension instanceof BootableExtensionInterface) {
$extension->boot($container);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will call <tt>boot</tt> within our HelloworldComponent, and allows us to perform some initialisation within our component. We'll return to this later, in the section on [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#HTML_Snippets|HTML snippets]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note again that Joomla checks that our HelloworldComponent class implements BootableExtensionInterface before calling <tt>boot</tt>. It's not sufficient to just provide the <tt>boot</tt> function, we have to explicitly declare that our HelloworldComponent implements the interface.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 6 Get the Dispatcher===
Returning to our key line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
we have now accomplished the first part <tt>bootComponent($option)</tt>, and this has returned our HelloworldComponent instance. Now we call <tt>getDispatcher($app)</tt> on this instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This code is also in libraries/src/Extension/Component.php, in the Component class which our HelloworldComponent extends:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function getDispatcher(CMSApplicationInterface $application): DispatcherInterface
{
return $this->dispatcherFactory->createDispatcher($application);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We call <tt>createDispatcher</tt> on our ComponentDispatcherFactory class instance which we saved in Step 4. This code is in libraries/src/Dispatcher/ComponentDispatcherFactory.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createDispatcher(CMSApplicationInterface $application, Input $input = null): DispatcherInterface
{
$name = ucfirst($application->getName());

$className = '\\' . trim($this->namespace, '\\') . '\\' . $name . '\\Dispatcher\\Dispatcher';

if (!class_exists($className)) {
if ($application->isClient('api')) {
$className = ApiDispatcher::class;
} else {
$className = ComponentDispatcher::class;
}
}

return new $className($application, $input ?: $application->input, $this->mvcFactory);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code checks if we have our own Dispatcher class (our Helloworld tutorial doesn't, but <tt>com_users</tt> for example has its own). So it creates a <tt>ComponentDispatcher</tt> instance, and passes into its constructor the MVC Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that this ComponentDispatcherFactory instance is what was instantiated when it was retrieved from our child DI Container (from being inserted in step 3b), and hence it already knows about our namespace, and has a pointer to our MVCFactory class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 7 call dispatch()===
This is the final aspect to our line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We're now back to what was described in the Dispatcher section above, except that now we can see that this Dispatcher instance has a pointer to our MVC Factory instance (which knows about our namespace prefix), so when the Dispatcher code wants to create a Controller it can use that MVC Factory instance to instantiate it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's been a long and tortuous journey to get here, but the significant thing is that all of our key class instances have been obtained via the DI Container. If we want to mock out any of those classes for testing then all we need to do is replace the relevant services/provider file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Javascript and the Web Asset Manager ==
The web asset manager has been introduced in Joomla 4 and is well documented [[J4.x:Web_Assets|here]]. It provides a much-improved means of managing JS and CSS resources, and a framework for handling their dependencies.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Component Javascript and CSS files should now be stored in the <tt>media</tt> folder, and the Web Asset Manager used to register them and output them on specific web pages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following assets have been registered in the tutorial <tt>joomla.asset.json</tt>, and you should have a look at that file now.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.validate-greeting===
This is the code for client validation of the helloworld greeting field using a regex, and it is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it is dependent upon jQuery and the Joomla <tt>form.validator</tt> script, so those both get included as dependencies.
If we didn't have specific validation on our form then we would need to include explicitly the <tt>form.validator</tt> script in order for the basic Joomla field validation to be included, eg in the tmpl file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->document->getWebAssetManager()->useScript('form.validate');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that this requires us to have a <tt>class="form-validate"</tt> on the </tt><form></tt> html element.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.fix-permissions-ajax-call===
This is the code which copies the value from the greeting field into the title field, so that the Ajax calls setting the permissions work correctly. The js code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.enable-tooltips===
This is the code which enables bootstrap tooltips to operate, including allowing them to include html code. It's used to display the image as a tooltip within the admin <tt>helloworlds</tt> view.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.openstreetmap===
This is defined as a preset, comprising the helloworld js and css code for the map display, as well as the dependency named 'com_helloworld.openlayers' relating to the openlayers CSS and js code. The code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.admin-helloworlds-modal===
This is the js code for selecting an individual helloworld record within a modal, and passing its details to the form in the main window. Its code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===submitbutton.js===
In the Joomla 3 code we introduced in [[Special:MyLanguage/J3.2:Developing_an_MVC_Component/Adding_verifications|Adding Verifications]] a js file which controlled when the form was submitted. It differentiated between buttons such as <tt>Save</tt> (which submitted the form) and <tt>Cancel</tt> (which didn't).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 there is a more sophisticated version of <tt>Joomla.submitbutton</tt> (found in media/system/js/core.js) which uses the CSS classes which the Toolbar functionality sets on the buttons to determine whether the form should be submitted or not. And you can override whether the validation is performed by adding a third parameter to the <tt>submitbutton</tt> js call. For example, to avoid validation being performed when a button is clicked you can set on the button element:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
onclick="Joomla.submitbutton('controller.method', '', false)"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As this is sufficient for what we need in the tutorial, the custom <tt>submitbutton.js</tt> has been removed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Interaction with other components ==
The way that Joomla interacts with components has changed in Joomla 4. In general the Joomla functionality will boot the component using something like:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $app->bootComponent($option);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and in our case this will return an instance of the <tt>HelloworldComponent</tt> class. It will then try to call certain methods on our extension object, as described below.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_categories===
In the backend the helloworld functionality can display to the administrator
* the view of the helloworld messages
* the view of the helloworld categories
The categories view is generated by <tt>com_categories</tt>, and in Joomla 4 these component categories views display the number of component records there are for each of the possible published status values. To do this the categories component executes the following code (in administrator/components/com_categories/src/Model/CategoriesModel.php):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof CategoryServiceInterface) {
$component->countItems($items, $section);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So our HelloworldComponent must:
* declare that it implements <tt>CategoryServiceInterface</tt>
* provide an implementation of <tt>countItems</tt>
We provide <tt>countItems</tt> by using a trait in libraries/src/Categories/CategoryServiceTrait.php, which (with the assistance of a helper function) does the query on our behalf. We just need to tell it:
* the name of our table – in the callback <tt>getTableNameForSection</tt>
* the database field in which we hold the published status – in <tt>getStateColumnForSection</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_associations===
Remember that <tt>com_associations</tt> is the component which is run whenever you click on Multilingual Associations in the admin backend.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Under Joomla 3 we provided an associations helper file as described in [[J3.x:Multilingual Associations/Developers|Multilingual Associations/Developers]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the helper file remains basically the same, but <tt>com_associations</tt> primarily tries to find the helper file via the extension class; here's the code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($extensionName);
if ($component instanceof AssociationServiceInterface) {
return $component->getAssociationsExtension();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's expecting that:
* the extension (HelloworldComponent in our case) implements <tt>AssociationServiceInterface</tt>
* its <tt>getAssociationsExtension</tt> method returns the helper class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The easiest thing would be just to code <tt>getAssociationsMethod</tt> and get it to return <tt>new AssociationsHelper</tt>. However, we follow the Joomla 4 principle of putting key classes into the Dependency Injection container, and retrieving them later, by having the following code in our services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(AssociationExtensionInterface::class, new AssociationsHelper());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The above line puts a key-value pair into our child DI container
* key = 'Joomla\CMS\Association\AssociationExtensionInterface'
* value is an instance of our <tt>AssociationsHelper</tt> class.
We then retrieve it later and use the setter:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setAssociationExtension($container->get(AssociationExtensionInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so that whenever
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getAssociationExtension()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
is called it returns the <tt>AssociationsHelper</tt> class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_fields===
<tt>com_fields</tt> is the component which is run when an administrator clicks on the Fields or Field Groups menuitem within the backend, and this functionality was included in the [[J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Adding Custom Fields]] tutorial step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>com_fields</tt> component stores the custom fields and field groups for all components in the database tables <tt>#__fields</tt> and <tt>#__fields_groups</tt>, and these tables are partitioned into "sections", one section per component. For our helloworld component the section is named "helloworld".
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within the section we have 2 "contexts" – one for the helloworld messages (called "com_helloworld.helloworld") and one for the helloworld categories (called "com_helloworld.categories"). This enables us to define custom fields for both our helloworld records and helloworld category records.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When <tt>com_fields</tt> runs it checks both the section and contexts at various times. For example, when an admin selects Helloworld / Fields on the backend then <tt>com_fields</tt> checks the section which was defined in the menuitem in the manifest file (see [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Sidebar|below]]). Here's the code in administrator/components/com_fields/src/Helpers/FieldsHelper <tt>extract</tt> function:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
$newSection = $component->validateSection($parts[1], $item);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And when <tt>com_fields</tt> wants to display the little dropdown menu of contexts (to allow the administrator to set custom fields on either helloworld items or categories) it calls (in administrator/components/com_fields/src/Fields/FieldcontextsField.php <tt>getOptions()</tt>):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
return $component->getContexts();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So it's clear that our component extension class must :
* implement <tt>FieldsServiceInterface</tt>
* provide the <tt>validateSection</tt> and <tt>getContexts</tt> methods
So in upgrading to Joomla 4 we've just moved those two methods from the helper file to the extension class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Router===
The Joomla router will access our custom router code:
* whenever it wants to parse an SEF route which it has identified as belonging to <tt>com_helloworld</tt>
* whenever it wants to build an SEF route from a call to <tt>Route::_()</tt> where the option = "com_helloworld".
To find our custom router it will:
* boot the <tt>com_helloworld</tt> extension
* check that the extension implements <tt>RouterServiceInterface</tt>
* call <tt>createRouter</tt> on our extension instance
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In our services/provider.php file we have (careful again - 2 different RouterFactory classes!):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new RouterFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which from libraries/src/Extension/Service/Provider/RouterFactory.php puts into our child DI container an entry with:
* key = "Joomla\CMS\Component\Router\RouterFactoryInterface"
* value is a <tt>\Joomla\CMS\Component\Router\RouterFactory</tt> instance, constructed with our namespace
We then retrieve this in the line in our services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setRouterFactory($container->get(RouterFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And then within our extension class we have
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use RouterServiceTrait;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which includes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function setRouterFactory(RouterFactoryInterface $routerFactory)
{
$this->routerFactory = $routerFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which stores the <tt>routerFactory</tt> locally and
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return $this->routerFactory->createRouter($application, $menu);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which provides our extension's <tt>createRouter</tt> call that the Joomla Router expects.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>routerFactory::createRouter</tt> method is in libraries/src/Component/Router/RouterFactory.php. It looks for a class in our site namespace </tt>Robbie\Component\Helloworld\Site\Service\Router</tt> which is in our site/src/Service/Router.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
At this stage we have a choice, we can either:
* provide a traditional custom router, with the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions, or
* use the more modern <tt>RouterView</tt> mechanism.
By default in the upgraded tutorial code the Router View option has been coded in the Router.php file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====RouterView====
In the <tt>RouterView</tt> case the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions are in the <tt>RouterView</tt> class which we extend, and we provide
* a constructor with router view configuration
* methods <tt>getHelloworldId</tt> and <tt>getCategoryId</tt> which are used to obtain from the SEF segment the <tt>id=</tt> and <tt>catid=</tt> parts of the internal URL
* methods <tt>getHelloworldSegment</tt> and <tt>getCategorySegment</tt> which are used to generate segments for the SEF URLs based on the <tt>id=</tt> and <tt>catid=</tt> parts within the <tt>Route::_()</tt> parameter.
Unfortunately there doesn't seem to be a good guide to configuring the RouterView class. There is some documentation available [https://www.dionysopoulos.me/book/com-router-routerview.html here].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the helloworld tutorial we have 3 views
* a view which displays a single helloworld record
* a view which displays a single helloworld category, and the helloworld records associated with it
* a view which displays the frontend form
So we need 3 Router Views associated with these.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'form' view doesn't have an associated id or catid so it's just a fixed URL, and the router just has to convert between the alias of the form menuitem and the Itemid / view parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'category' view has an associated id (of the category record), and an SEF URL will use the category path down the Categories Nested Set table structure, hence <tt>setNestable()</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'helloworld' view has an associated id (of the helloworld record), and in an SEF URL in the category view the helloworld record alias is added to the category path (hence <tt>setParent()</tt>). But although the helloworld records use a Nested Table structure in the database, the URLs just include the alias of the single record, and so <tt>setNestable()</tt> is not used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There doesn't seem to be a way to configure an additional SEF URL scheme which just displays a helloworld segment, without a category segment.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====Traditional Router====
To use the traditional router in the tutorial code you should uncomment the function in the extension class:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return new TraditionalRouter($application, $menu, $this->categoryFactory, $this->getDatabase());
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will cause the code in site/src/Service/TraditionalRouter.php to be used. However, changes in the Joomla 4 router mean that the interaction between it and the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> methods have changed. This requires significant changes to the <tt>preprocess</tt> and <tt>build</tt> methods, but only a minor change to <tt>parse</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. Previously Joomla injected into the <tt>$query</tt> parameters the <tt>Itemid</tt> of the active menuitem (ie the id of the menuitem the user is currently on). This meant that we had to change the <tt>Itemid</tt> for links generated by the Language Switcher module (which generates the flags for switching between languages), and these links being associated with a different language would obviously use a different <tt>Itemid</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 you get an <tt>Itemid</tt> in the <tt>$query</tt> parameters only if you specified an <tt>Itemid</tt> in the <tt>Route::_()</tt> call. For others you have to work out which menuitem to use yourself, by using the Joomla menu/menuitems API to find details of the configured menuitems, and work out which to use based on the other <tt>$query</tt> parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You do this in the <tt>preprocess</tt> method, and then the <tt>Itemid</tt> you set will be passed in the <tt>$query</tt> parameters to the <tt>build</tt> method.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. In some instances the <tt>Route::_()</tt> URL you're generating matches exactly one of the configured menuitems on the site. In this case the <tt>$query</tt> parameters will match those in the menuitem <tt>"query"</tt> array, and you have to remove explicitly remove the 'view', 'id' and 'catid' parameters so that they don't appear as URL query parameters after the normal SEF URL of the menuitem.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
3. The custom router will be used to build the URLs for the helloworld menuitems shown in menus on the page. For these the <tt>$query</tt> parameters will have the view / id / catid associated with those menuitems. Note that even if you remove these in your <tt>preprocess</tt> method, Joomla will inject them again into the <tt>$query</tt> array when it's passed to your <tt>build</tt> method, so you'll have to remove them again there!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
4. In the <tt>parse</tt> method you now have to unset the <tt>$segments</tt>, or else Joomla will return an HTTP 404 (page not found). Otherwise <tt>parse</tt> works as before.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
5. I've implemented <tt>build</tt> only for when Multilanguage is enabled on the site. If it's not enabled an empty <tt>$segments</tt> array is just returned, without doing unset on any of the <tt>$query</tt> parameters, so these will appear as URL parameters after the SEF URL. Also it's not coded properly to deal with items which have language set to <tt>*</tt>. These include helloworld records, categories or menuitems (eg the helloworld form).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that the <tt>categoryFactory</tt> is also now passed to the router. This is so that it can be used instead of <tt>Categories::getInstance()</tt> to get access to the Categories API calls.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_tags===
Whenever we setup a Tags Menu Item Type which displays items having a given tag or tags, then <tt>com_tags</tt> displays those items as links, and uses route helper functions to generate the URL parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The route helpers <tt>com_tags</tt> expects to find loaded into the data of the <tt>#__content_types</tt> table, in the router field, and these have been set to:
* For links to helloworld items: 'HelloworldHelperRoute::getHelloworldRoute'
* For links to helloworld categories: 'HelloworldHelperRoute::getCategoryRoute'
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, <tt>com_tags</tt> doesn't boot the helloworld extension to get access to these, but rather seeks to find them in site/helpers/route.php, so that's where they continue to be.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(We also had a <tt>getCategoryRoute</tt> which was used by <tt>com_categories</tt> in administrator/components/com_categories/src/Helper/CategoryAssociationHelper. When a category was displayed on the frontend then the Language Switcher module (now Language Filter) used this function to generate the links to the Associated Categories. Our <tt>getCategoryRoute</tt> previously was necessary to insert the <tt>lang=<language tag></tt> parameter into the link URL, but since [https://github.com/joomla/joomla-cms/pull/39358 this change] the calling function inserts the <tt>lang</tt> parameter itself, so our <tt>getCategoryRoute</tt> function for this purposes is superfluous.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Deprecated APIs ==
With Joomla 4 there are a number of methods which are deprecated, with a view to removing them in Joomla 5.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Factory Methods===
Many of the <tt>Factory</tt> methods for getting singleton classes have been deprecated in favour of getting these classes via the DI container, and it appears that only class instances which should be obtained via Factory methods are:
* the Application – <tt>Factory::getApplication()</tt>
* the DI container – <tt>Factory::getContainer()</tt>
Here is a list of what has been changed in the tutorial code. Note that with some calls there are variants available, through the aliases defined in the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDbo'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\Database\DatabaseInterface;
...
$db = Factory::getContainer()->get(DatabaseInterface::class);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, in many classes the database instance is more easily (and efficiently) returned via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$db = $this->getDatabase();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is available in Model classes, custom field definitions, etc.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getUser();'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get the current user use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = Factory::getApplication()->getIdentity()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get a different user (whose id you know):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\User\UserFactoryInterface;
...
$user = Factory::getContainer()->get(UserFactoryInterface::class)->loadUserById($userid);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within models which extend Joomla\CMS\MVC\Model\BaseDatabaseModel and views which extend Joomla\CMS\MVC\View\HtmlView you can also use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = $this->getCurrentUser()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDocument()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication()->getDocument()</tt>, or within a View you can use <tt>$this->document</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getConfig()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Two options have been used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->getConfig()</tt> – returns a Registry object containing all the configuration values
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->get('access')</tt> – returns the value of the 'access' configuration parameter
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getLanguage()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication->getLanguage()</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JFactory::getCache('com_example', <type>)'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Cache\CacheControllerFactoryInterface;
...
Factory::getContainer()->get(CacheControllerFactoryInterface::class)->createCacheController(<type>)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated getInstance Methods===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general <tt>getInstance()</tt> calls have been deprecated in favour of obtaining the instance, either via a factory class or via the DI container. For example, within a controller you can use <tt>getModel()</tt> repeatedly to get different models (passing the relevant model names), which results in the MVCFactory class creating the Model classes.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there are currently some problems with replacing some getInstance calls. I expect that the Joomla team will resolve these issues over the course of the Joomla 4 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Categories::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is deprecated with a notice: "Use the ComponentInterface to get the categories". This means that we should get the category factory instance via the DI container. This is done in our services/provider.php by the lines:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Extension\Service\Provider\CategoryFactory;
...
$container->registerServiceProvider(new CategoryFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to put into our child DI container the closure which will create a Joomla\CMS\Categories\CategoryFactory instance, constructed with our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when our HelloworldComponent (Extension) instance is created:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We can then use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getCategoryFactory()->createCategory();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to create our Categories object, and in this way get access to the Categories APIs.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This createCategory method creates the instance by looking for the \\Site\\Service\\Category class within our namespace. The constructor in our class sets our extension ('com_helloworld') and table ('#__helloworld') and calls the parent Categories constructor with these options).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this means that the section of our code where we want to use the Categories APIs must have a pointer to a CategoryFactory instance. In the tutorial code for Joomla 3 there are 2 places where <tt>Categories::getInstance</tt> is used:
* in the custom router code, to handle building and parsing of the category parts of the SEF URL
* in the site category model, where the Categories APIs are used to obtain details of categories to display on the page.
For the custom router code, the CategoryFactory instance is passed as a parameter to the TraditionalRouter constructor so that it can be used there.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, the site category model is instantiated by the MVCFactory instance, and it doesn't make available a CategoryFactory instance. So in this category model the calls to <tt>Categories::getInstance()</tt> have been left, and you can still find a number of calls to <tt>Categories::getInstance</tt> within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Categories::getInstance()</tt> itself solves the problem of access to a CategoryFactory instance by rebooting our component again to get a pointer to our Extension instance, and thus to the category factory instance. However, this involves a lot of work, so <tt>getInstance</tt> caches locally the Categories instances and just returns one of them if it can.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Pushing the CategoryFactory to the model'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there is a way to get access to the CategoryFactory instance, by defining your own MVCFactory class, and pushing the instance down through it to the model. Here's how you can go about it:
* Define your own SuperMVCFactory class, which extends the Joomla Joomla\CMS\MVC\Factory\MVCFactory class, but which has a means of storing a CategoryFactory instance. Use the CategoryServiceTrait in libraries/src/Categories/CategoryServiceTrait.php
* Create your own version of the file libraries/src/Extension/Service/Provider/MVCFactory.php, which is the 'provider.php' like file for MVCFactory, but change it so that:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
becomes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new <namespace>\SuperMVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and include
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla creates a model such as CategoryModel it passes in its constructor the MVCFactory instance (so that the model can call createTable on it), so you can access it via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will return your SuperMVCFactory instance. So in this way within the model you can access the CategoryFactory, and use it to create the Categories instance via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()->getCategory() (from the CategoryServiceTrait)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you can get this working you can congratulate yourself on a good understanding of Joomla namespacing and dependency injection! A similar approach to address a similar problem is described [https://www.dionysopoulos.me/book/com-router-push-dependencies.html here]. If you get stuck you can always view the solution by viewing the github tutorial code selecting the branch [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial/tree/push-category-factory-to-mvc push-category-factory-to-mvc].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Table::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There are a couple of calls to <tt>Table::getInstance()</tt> within admin/src/Helper/AssociationsHelper.php in <tt>getItem()</tt>:
* <tt>Table::getInstance('Helloworld', 'Robbie\\Component\\Helloworld\\Administrator\\Table\\')</tt> to get an instance of our HelloworldTable class.
* <tt>Table::getInstance('Category')</tt> to get an instance of the Category table in libraries/src/Table/Category.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We could actually arrange for the AssociationsHelper class to get injected with the MVCFactory instance, so that the HelloworldTable class could be instantiated by it. However, we couldn't use the helloworld MVCFactory instance to create the Category table instance, as it's not in the helloworld namespace, and our MVCFactory instance creates table instances within our namespace only.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Toolbar::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The tutorial code uses <tt>Toolbar::getInstance()</tt> to get a Toolbar instance onto which it can attach the batch button in the helloworlds form. The Toolbar API documentation seems to suggest that we should replace
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Toolbar::getInstance('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
with
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this currently won't work. The problem is that all the other Joomla code uses <tt>getInstance('toolbar')</tt> to access the Toolbar class, including the code in administrator/modules/mod_toolbar/mod_toolbar.php which renders the toolbar. The <tt>getInstance</tt> method keeps track of the Toolbar instances in a local static variable <tt>$instances</tt>, and returns the same Toolbar instance on repeated invocations.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you use the second approach above you will get a Toolbar instance, but it won't be the same Toolbar instance as is stored in the <tt>$instances</tt> variable. It won't then be picked up by the Toolbar module, and so won't be rendered on the form.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Error Handling===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead of
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
JError::raiseError(500, implode('<br />', $errors));
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
you should throw an exception, using or extending one of the standard [https://www.php.net/manual/en/spl.exceptions.php PHP exceptions], eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
throw new \Exception(implode("\n", $errors), 500);
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===jimport===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
jimport is no longer necessary in order to get access to Path or File classes. All of the Joomla classes are found by the autoloader.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Methods related to Javascript===
'''JHtml::_('behavior.framework');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general, the use of JHtml::_('behavior.xxx') is now obsolete, and calls using this have been removed in the tutorial code. The 'behavior.framework' call referred to including jQuery. Where jQuery is necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.formvalidator');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by the <tt>form.validate</tt> javascript asset, and where necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It can also be included directly using the web asset manager:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$wa->useScript('form.validate')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.tooltip')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This no longer exists, and tooltips don't seem to be enabled by default in Joomla 4. This is replaced by the code in media/js/enable-tooltips.js.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('formbehavior.chosen')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The chosen js library seems to be no longer used, and using it will cause formatting issues if you include it in your tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''sortable'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The sortable js library provided the ability in the helloworlds view to drag rows up and down to change the ordering of the records. This has been replaced in Joomla 4 by the draggable library. To enable it you have to set:
* <tt>HTMLHelper::_('draggablelist.draggable');</tt>
* on your <tt><tbody></tt> element define the table in which dragging occurs and the URL of the Ajax call to set the ordering:
<source lang="php">
<tbody<?php if ($saveOrder) : ?> class="js-draggable" data-url="<?php echo $saveOrderingUrl; ?>" data-direction="<?php echo strtolower($listDirn); ?>" data-nested="true"
<?php endif; ?>>
</source>
* on your <tt>tr</tt> element within your <tt><tbody></tt> define the group of records in which dragging occurs (by category below):
<source lang="php">
<tr class="row<?php echo $i % 2; ?>" data-draggable-group="<?php echo $row->catid; ?>">
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==HTML Snippets==
There are two places in the tutorial where reusable snippets of HTML have beeen defined:
* For displaying the item associations in the helloworlds view:
* For displaying the position latitude and longitude fields within the batch options in the helloworlds view
These used different approaches:
* the item associations display was coded in an html helper file in admin/helpers/html/helloworlds.php and accessed via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JHtml::_('helloworlds.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
in the helloworlds tmpl file. (Although it did use a common joomla layout file underneath).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* the position field was coded as a layout in layouts/position.php, and rendered using
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JLayoutHelper::render('position', array());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When should you use one approach rather than the other? A significant difference is that layouts are designed so that an administrator can override them, via the Templates / Details and File functionality. So, for example, an administrator could change the position to show the longitude before the latitude. So it's more appropriate for layouts to focus on the html elements rather than functional logic, and particularly if you would want to allow an administrator to override the layout.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The layouts functionality in Joomla 4 hasn't changed significantly. One correction which has been made in the updated tutorial code has been to include the position.php file in a subfolder of layouts, ie in admin/layouts/helloworld/position.php rather than admin/layouts/position.php. It appears that in the Templates / Details and Files / Create Overrides tab the <tt>com_helloworld</tt> layout appears only if it's in a subfolder of /layouts.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>JHtml::_()</tt> approach has changed in Joomla 4. Rather than Joomla having to look for a helper file when it encounters something it doesn't recognise, it's expected that you should register such classes beforehand, and you do this by obtaining an instance of the Joomla\CMS\HTML\Registry class (it's a singleton class) and then calling <tt>register</tt> on it, passing
* the key you want to use
* an instance of your class
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Joomla pattern is to put the code in a file admin/src/Service/HTML/AdministratorService.php, and we have to ensure that our key won't be used elsewhere within Joomla, so in the tutorial we've used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Robbie\Component\Helloworld\Administrator\Service\HTML\AdministratorService;
...
register('helloworldadministrator', new AdministratorService)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when we call:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo HTMLHelper::_('helloworldadministrator.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will result in Joomla calling the <tt>association</tt> method in our class, passing the <tt>$row->id</tt> parameter.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We should get the Joomla\CMS\HTML\Registry class from the Dependency Injection container. Joomla components generally do this via their services/provider.php file, and then call <tt>register</tt> within the extension's <tt>boot</tt> function, described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Step_5_Call_boot.28.29_on_our_Component|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The extension uses HTMLRegistryAwareTrait which contains <tt>setRegistry</tt> and <tt>getRegistry methods</tt>. In services/provider.php there is:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\HTML\Registry;
...
$component->setRegistry($container->get(Registry::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets 'Joomla\CMS\HTML\Registry' out of the DI container and stores it within the
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
private $registry;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
variable of the HTMLRegistryAwareTrait included in the extension.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the <tt>boot</tt> function it calls
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getRegistry()->register('helloworldadministrator', new AdministratorService);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets the registry and calls <tt>register</tt> as required.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that <tt>boot</tt> is called whenever Joomla dispatches <tt>com_helloworld</tt>, both for the site and administrator, so it would make sense to check the Application <tt>isClient</tt> before deciding whether to register the HTML Helper service or not. This hasn't been included in the tutorial code though.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==User Interface Changes==
Joomla 4 introduced new templates, atum on administrator and cassiopeia on site, and in particular the administrator is built upon some UI rearrangements which affect the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Sidebar===
In Joomla 3 each component incorporated a sidebar which we coded in the <tt>addSubmenu</tt> function in admin/helpers/helloworld.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the administrator menu is in a vertical panel on the left hand side, and the Hello World submenu is built from entries in the helloworld.xml manifest file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<administration>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<submenu>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<menu link="option=com_categories&extension=com_helloworld">COM_HELLOWORLD_CATEGORIES</menu>
<menu link="option=com_fields&view=fields&context=com_helloworld.helloworld">MOD_MENU_FIELDS</menu>
<menu link="option=com_fields&view=groups&context=com_helloworld.helloworld">MOD_MENU_FIELDS_GROUP</menu>
</submenu>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===CSS Classes===
In several places the CSS classes defined in the html elements have been changed in Joomla 4. For example, for general layout the classes now align with the [https://getbootstrap.com/docs/3.4/css/ Bootstrap CSS Classes], and classes such as <tt>row-fluid</tt> and <tt>span3</tt> which were prominent in Joomla 3 have disappeared. If you're upgrading a Joomla 3 component then it's probably best (on the back-end at least) to find a similar Joomla component and use the overall html structure and css classes within its tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the tutorial code those classes which are specifically used by Bootstrap have been changed from eg 'data-target' to 'data-bs-target', and it has been necessary to change these to enable the functionality to work.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, not all of CSS class changes affecting solely the presentation have been reflected in the updated tutorial code. For example, in the <tt>helloworlds</tt> view, showing the list of helloworld messages, the display of the associations is different from that of other Joomla components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Fonts===
In Joomla 3 [[J3.x:Joomla_Standard_Icomoon_Fonts|Icomoon Fonts]] were used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 Font Awesome's free icons are used, and you can see what is available on their [https://fontawesome.com/v5/cheatsheet cheatsheet]. The icons are implemented using CSS pseudo-elements, as described [https://fontawesome.com/v5/docs/web/advanced/css-pseudo-elements here]. Basically they convert a CSS class into html content, namely a unicode value in the private use range. A couple of these have been implemented in the frontend form, in the Save and Cancel buttons, for example:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>span class="icon-cancel">/span <?php echo Text::_('JCANCEL') ?></tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(with angle brackets removed from the <tt>span</tt> tags to stop the icon just being displayed by the browser).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This class is defined in media/system/css/joomla-fontawesome.css (where you can find the list of icon classes supported):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
.icon-cancel:before {
content: "\f00d";
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so this includes in front of the text the unicode character <tt>f00d</tt>, which you can see on the cheatsheet as "times", and displayed as <span class="icon-cancel"></span>. You can also use <tt>fa-</tt> plus the icon name on the font awesome cheatsheet page. If you use Icomoon icon names in your code which you run under Joomla 4, then the icon displayed will be a Font Awesome icon (if there's one with the same name) or it will use a mapping which the Joomla team have defined to display a Font Awesome icon which resembles the Icomoon one.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Buttons and Links===
An accessibility principle is that <tt><a></tt> html elements should be used for links to other web pages, and <tt><button></tt> elements should be used for actions, eg on a form. To align with this, the <tt><a></tt> elements in the helloworld modal field (defined in admin/src/Field/Modal/Helloworld.php) have been changed to <tt><button></tt> elements. These are the Select and Clear buttons displayed when choosing a Helloworld record for a menuitem pointing to a Helloworld message. (The buttons also include fontawesome icons, by the way).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This change was actually made in Joomla in one of the Joomla 3 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Categories View===
In the Categories view of standard Joomla components there now appears columns which show for each category the number of items, split by published status. This is populated by <tt>com_categories</tt> calling each extension's <tt>countItems</tt> function, as described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_categories|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Miscellaneous Changes==
===Version History===
In Joomla 3 the tutorial code used the <tt>JTableObserver</tt> functionality to copy relevant changes from the Helloworld and Categories tables into the UCM tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it uses a plugin mechanism to subscribe to Table events 'onTableAfterStore' and 'onTableBeforeDelete'. The plugin can be found in plugins/behaviour/versionable, and it is activated by Joomla as part of its application initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The copying of fields from the table works roughly the same way as before, except that the name of the table where the versions are stored is now <tt>#__history</tt>, so the entries which have to be inserted into the <tt>#__content_types</tt> table are fairly similar. Because the folders in which forms are stored has changed in Joomla 4, the 'formFile' parameter is different (remember that this is where Joomla gets the field labels in order to display the Preview within the Versions modal window, otherwise just the names of the database columns will be output).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here's a summary of what needs to be done to enable versioning under Joomla 4. The Versioning Traits and Interface definitions are found in libraries/src/Versioning:
* Enter data into content_types database table
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Storing the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The Table class must implement VersionableTableInterface and provide <tt>getTypeAlias()</tt>, which returns 'com_helloworld.helloworld'. This type alias + the helloworld record id is used as the key to identify versions in the <tt>#__history</tt> table.
* Define <tt>save_history</tt> and <tt>history_limit</tt> options in config.php, and ensure these are both set.
* Add a <tt>version_note</tt> field into the output of the edit view's tmpl file (admin/tmpl/helloworld/edit.php).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Viewing and Restoring the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit Controller (admin/src/Controller/HelloworldController.php) should <tt>use VersionableControllerTrait</tt>.
* The edit Model (admin/src/Model/HelloworldModel.php) should <tt>use VersionableModelTrait</tt> and include a variable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public $typeAlias = 'com_helloworld.helloworld';
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit View (admin/src/View/Helloworld/HtmlView.php) – should display the Versions toolbar button if global config has <tt>save_history</tt> on.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Joomla 4 allows us to have different history version limits for helloworld items and categories, and this has been used in the configuration definition in admin/config.xml.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Setting Configuration Parameters in Install Script===
As you may remember, global configuration parameters relating to the Hello World component are defined in admin/config.xml and stored in the <tt>#__extensions</tt> table, in a JSON string in the params field of the record relating to <tt>com_helloworld</tt>. This means that when the component is first installed the params are not set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So, for example, even if the <tt>save_history</tt> is defined in config.xml to default to true, the versions won't be saved until an administrator actively saves the configuration parameters, because the Joomla versioning code assumes <tt>save_history</tt> to be false if it's not explicitly set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For this reason it makes sense to set any default configuration parameters in the install script.php, in the <tt>postflight</tt> method, and that has been done in this step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Tags===
Like version history, tags functionality has been changed to use a plugin – in plugins/behaviour/taggable – rather than the <tt>JTableObserver</tt> approach.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To enable tags the component table must implement TaggableTableInterface (in libraries/src/Tag), and provide the <tt>getTypeAlias()</tt> which is common to the Versioning functionality.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Whenever <tt>com_tags</tt> outputs helloworld messages or categories relating to a tag it displays them as links, and looks in the site/helpers/route.php file to find the route functions (as described above in [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_tags|com_tags]]). The class and method in this file must match the 'router' field within the data entered into the <tt>#__content_types</tt> table.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===media files===
Under Joomla 4 all of the media files are stored in the /media folder; these include javascript and css files (scss files too), as well as images such as the little flag symbols shown in the language switcher. Extensions being developed should store all of the js and css files in their /media folder, and then when the extension is installed these files are put under the extension's folder under the /media folder of the Joomla instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Patches==
Some bugs in Joomla were discovered during the course of updating the tutorial code to work under Joomla 4. If you find something doesn't work then make sure you're on at least Joomla 4.2.6 and check if you need one of the following patches:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
CategoryAssociationHelper.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39358/files
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
MediaField.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/issues/39203
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Category restore
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39474
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Contributors ==
*[[User:Robbiej|Robbie Jackson]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Prev: Adding Custom Fields|class=expand success}}</div>
</div>
</div>

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/29/it

2023-05-27T12:48:19Z

===Caricamento automatico della classe===
Joomla utilizza il meccanismo PHP per [https://www.php.net/manual/en/language.oop5.autoload.php Classi di caricamento automatico] e all'avvio registra una serie di caricatori automatici, funzioni che vengono chiamate quando PHP non riesce a trovare una data classe. In particolare la funzione di Joomla PSR-4 autoloader (in <tt>libraries/loader.php</tt>) è responsabile della ricerca di classi di estensioni Joomla il cui codice si trova nei file sorgente che sono organizzati secondo la raccomandazione PSR-4. (Le classi della libreria Joomla vengono caricate automaticamente utilizzando un caricatore automatico diverso – vedi <tt>libraries/vendor/composer/autoload_static.php</tt>).

J3.x:Developing an MVC Component/Upgrading to Joomla4/it

2023-05-27T12:47:30Z

Ing Pulizzi: Created page with "e anche in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> dove le associazioni vengono aggiunte dinamicamente al modulo per formare il campo di tipo <tt>modal_hellow..."

<noinclude><languages /></noinclude>

{{:J3.1:Developing an MVC Component/it}}
Questo passaggio copre ciò che è coinvolto nell'aggiornamento del codice del tutorial per allinearlo con la versione 4 di Joomla.

== Introduzione ==
Questa pagina descrive i principali aspetti relativi allo sviluppo dei componenti che sono stati introdotti in Joomla 4 e descrive in dettaglio cosa è stato modificato nel codice del tutorial per allinearsi con v4.

Non è pratico dettagliare tutte le modifiche al codice sulla pagina Web come è stato fatto per i passaggi precedenti dell'esercitazione. Invece puoi trovare il codice come repository github su [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial Joomla 4 Tutorial code], e puoi confrontarlo con il codice del passaggio precedente del tutorial (Adding Custom Fields) su [https://github.com/robbiejackson/Joomla-3-MVC-Tutorial Joomla 3 MVC code]. Il codice di Joomla 4 replica tutte le funzionalità del codice di Joomla 3, con l'eccezione dell'implementazione dell'icona del piccolo pinguino introdotta in [[S:MyLanguage/J3.2:Developing an MVC Component/Adding decorations to the backend|Aggiunta di decorazioni al backend]] (che non è così rilevante data la modifica dell'interfaccia utente in Joomla 4 Administrator) e l'uso di un plug-in CAPTCHA ([[J3.x:Developing an MVC Component/Adding a frontend form|Adding a frontend form]] ). Probabilmente troverai utile avere a portata di mano questo codice Joomla 4 a cui fare riferimento mentre leggi questa pagina.

Il codice per questo passaggio è stato sviluppato seguendo ciascuno dei precedenti passaggi del tutorial e cercando di far funzionare ogni passaggio con Joomla 4.2.5. Poiché Joomla 4 si sta ancora evolvendo abbastanza velocemente, è possibile che alcuni aspetti qui citati vengano modificati durante la vita di Joomla 4. Sentiti libero di correggere gli aspetti in questa pagina e creare richieste pull su [https://github.com/robbiejackson /Joomla-4-MVC-Tutorial Joomla 4 github repository].

Se stai installando il codice del tutorial di Joomla 4 su una nuova istanza di Joomla, dovrai configurare la tua istanza per renderla multilingue e aggiungere le voci di menu nascoste di Ajax come descritto nel passaggio [[J3.x:Developing an MVC Component/ Utilizzo del filtro della lingua |Utilizzo del filtro della lingua]]. Assicurati inoltre che ogni record helloworld abbia una categoria valida.

=== Ulteriori letture ===
Puoi trovare [https://blog.astrid-guenther.de/en/der-weg-zu-joomla4-erweiterungen/ qui] un tutorial per lo sviluppo dei componenti di Joomla 4, simile a questo Joomla 3, e alcuni eccellenti Joomla 4 è disponibile anche la documentazione [https://www.dionysopoulos.me/book.html qui]. Entrambi questi riferimenti includono descrizioni degli impatti di Joomla 4 sullo sviluppo di altri tipi di estensioni Joomla (plugin, moduli e modelli), che non sono trattati qui.

Questo passaggio non copre tutto ciò che è necessario per aggiornare un componente da Joomla 3 a Joomla 4, solo gli aspetti coperti dal codice del tutorial. Se stai aggiornando il tuo componente Joomla 3, potresti trovare utile esaminare [[Potenziali problemi di compatibilità con le versioni precedenti in Joomla 4]].

== NameSpace ==
===NameSpace dei nomi dei componenti===
I NameSpace delle classi che utilizza la [https://www.php-fig.org/psr/psr-4/ PSR-4 recommendation] è stato gradualmente introdotto durante le versioni di Joomla 3 e con Joomla 4 è praticamente tutto con NameSpace

Ora è previsto che anche le estensioni di Joomla utilizzino i NameSpace di base per l'estensione definito nel suo file XML manifest. I componenti di Joomla usano uno NameSpace della forma <tt>Joomla\Component\<Nome componente></tt> es. <tt>Joomla\Component\Content</tt>, quindi seguendo questo schema ho dato una base al codice del tutorial spazio dei nomi di <tt>Robbie\Component\Helloworld</tt>. Ecco la riga nel file manifest helloworld.xml:

<namespace path="src">Robbie\Component\Helloworld</namespace>

(L'attributo <tt>path="src"</tt> indica che si aspetterà che le classi si trovino nella sottocartella <tt>src</tt>.)

Questo in realtà crea 2 prefissi dello spazio dei nomi, che puntano a cartelle specifiche nella nostra struttura di sviluppo helloworld e nella nostra istanza joomla live:

<tt>Robbie\Component\Helloworld\Administrator</tt> – punterà ad administrator/components/com_helloworld/src sull'istanza live ed è associato ad admin/src nella nostra area di sviluppo.

<tt>Robbie\Component\Helloworld\Site</tt> – punterà a components/com_helloworld/src sull'istanza live ed è associato a site/src nella nostra area di sviluppo.

Quindi Joomla ora si aspetta che tutti i nomi delle classi vengano trovati in quelle directory di base, con il nome del file che corrisponde al nome della classe e il nome della classe completo che corrisponde al percorso, ad esempio

<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> si troverà in
administrator/components/com_helloworld/src/Controller/DisplayController.php

<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> si troverà in
components/com_helloworld/src/Model/CategoryModel.php

'''Nota che le lettere maiuscole sono importanti nei namespace, nei nomi delle classi e nei nomi dei percorsi!'''

Quando Joomla 3 ha voluto chiamare le funzioni nel tuo componente, ha cercato determinati nomi di file in cartelle particolari e ha verificato che il nome della classe in quel file corrispondesse a quello previsto.

In Joomla 4 genera il nome completo della classe che vuole trovare, quindi cerca di trovarlo nella posizione in cui la raccomandazione PSR-4 lo aspetterebbe.

Quindi il namespace che specifichi nei tuoi file di classe deve essere allineato con il percorso del tuo file PHP, sotto la cartella di base <tt>src</tt> nel prefisso del tuo namespace.

Si noti in particolare come sono ora organizzati i file della classe <tt>View</tt>.

Inoltre, se usi una delle classi predefinite di PHP (ad es. <tt>Exception</tt>) nel tuo codice, aggiungi una barra rovesciata prima di essa (ad es. <tt>\Exception</tt>), altrimenti PHP cercherà di trovare nel tuo spazio dei nomi.

Se utilizzi definizioni di campi o regole personalizzate nei tuoi file xml del modulo, devi indicare a PHP quale prefisso dello spazio dei nomi utilizzare per cercarli, ad esempio in <tt>site/forms/add-form.xml</tt>:

addruleprefix="Robbie\Component\Helloworld\Administrator\Rule"
addfieldprefix="Robbie\Component\Helloworld\Administrator\Field"

e anche in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> dove le associazioni vengono aggiunte dinamicamente al modulo per formare il campo di tipo <tt>modal_helloworld</tt> personalizzato:

$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');

<div lang="en" dir="ltr" class="mw-content-ltr">
===Class Autoloading===
Joomla uses the PHP mechanism for [https://www.php.net/manual/en/language.oop5.autoload.php Autoloading Classes] and on startup registers a number of autoloaders – functions which get called when PHP can't find a given class. In particular the Joomla PSR-4 autoloader function (in <tt>libraries/loader.php</tt>) is responsible for finding classes of Joomla extensions whose code is in source files which are organised according to the PSR-4 recommendation. (Joomla library classes are autoloaded using a different autoloader – see <tt>libraries/vendor/composer/autoload_static.php</tt>).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can see the namespace prefixes of extensions on the Joomla instance by looking at <tt>administrator/cache/autoload_psr4.php</tt>. (These namespace strings have double backslashes, but in PHP they're the [https://stackoverflow.com/questions/25459197/single-or-double-slash-when-using-php-namespace same strings as those with single backslashes]). This is generated by Joomla looking through the component, module and plugin directories to find each extension's manifest file, and then processing these xml files to extract the <tt><namespace></tt> element – quite a lot of work, which is why it's cached I guess!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider what happens when Joomla wants our admin HelloworldController class. It might have something like
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$classname = 'Robbie\Component\Helloworld\Administrator\Controller\HelloworldController'
if (!class_exists($classname)) { …
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Assuming PHP doesn't already know about this class, the <tt>class_exists</tt> function will result in the classname being passed to the registered autoload function(s). The PSR-4 autoloader will then:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# go through its array of namespaces to try and match <tt>$classname</tt> from the start of the string.
# find 'Robbie\Component\Helloworld\Administrator' as a match
# see that this maps to "administrator/components/com_helloworld/src"
# extract the remainder of the classname: 'Controller\HelloworldController'
# treat this as the path down to the class file
# and so look for "administrator/components/com_helloworld/src/Controller/HelloworldController.php"
# check that in this file there's actually a class with that namespace + class name.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So in this way Joomla can go from a fully qualified class name to find the source code for that class. This makes it easier for us too when the core Joomla code is looking for one of our classes. We still need to know what class it's looking for, but once we know that, we know what we should call our class and where we should save the source code for it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Joomla Library classes===
Originally Joomla's core classes (beginning with a capital J) were global classes. Over the Joomla 3 versions and into Joomla 4 these migrated to their namespaced equivalents, but the original global classnames were still available as Joomla registered them as aliases (in the <tt>libraries/classmap.php</tt> file).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In a Joomla 4 extension you can still use these global classnames, except that in a namespaced file you'd have to prefix the name with a backslash to indicate a global class rather than one in your namespace (eg <tt>\JFactory</tt> instead of <tt>JFactory</tt>).
However it's pretty definite that the aliases will disappear at some stage, so the upgrade to Joomla 4 seems an appropriate opportunity to replace all your component's calls to the global JSomething classes to the namespaced equivalents. This involves adding the appropriate <tt>use</tt> statements, and all this has been done in the tutorial code. A useful mapping between the two can be found [https://github.com/nikosdion/joomlatypehints/blob/main/JoomlaObsoleteClasses.md here], where the new qualified classname can be copied and pasted into a <tt>use</tt> statement in your PHP file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
With reference to the [https://api.joomla.org/ Joomla API Documentation] there are 2 Joomla library namespaces:
* Joomla CMS classes – have namespaces <tt>Joomla\CMS\Something</tt> – are found under <tt>libraries/src/Something</tt>
* Joomla Framework classes – have namespaces <tt>Joomla\Something</tt> – are found under <tt>libraries/vendor/joomla/something/src</tt>
So a big advantage of namespacing is that you can immediately determine from the fully qualified class name in a PHP <tt>use</tt> statement where the source for that class exists in the <tt>libraries</tt> directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
On the other hand class names which aren't fully qualified don't have to be unique, eg <tt>MVCFactory</tt>
* occurs as <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in <tt>libraries/src/Extension/Service/Provider/MVCFactory.php</tt>
* occurs as <tt>Joomla\CMS\MVC\Factory\MVCFactory</tt> in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>
so sometimes you have to be careful to examine the <tt>use</tt> statement to identify the right class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly our FormModel class in <tt>site/src/Model/FormModel.php</tt> can have the same FormModel classname as the Joomla FormModel in <tt>libraries/src/MVC/Model/FormModel.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The API documentation gives the methods available in each of the [https://api.joomla.org/cms-4/namespaces/joomla.html Joomla CMS] and [https://api.joomla.org/framework-2/namespaces/joomla.html Framework] classes, but just be aware that a Joomla CMS class may extend a Framework class, and in this case some methods may not be visible under the Joomla CMS documentation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For example, <tt>$app->setHeader()</tt> which is used to set the HTTP response code is not listed under the [https://api.joomla.org/cms-4/classes/Joomla-CMS-Application-CMSApplication.html CMS Application class API], but is available as a method because it inherits from the Framework class [https://api.joomla.org/framework-2/classes/Joomla-Application-AbstractWebApplication.html AbstractWebApplication].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Vendor Namespaces===
These are also in <tt>libraries/vendor</tt>, eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Psr\Container\ContainerInterface;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
refers to <tt>libraries/vendor/psr/Container/src/ContainerInterface.php</tt>. However there are few of these in the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other File Rearrangements===
With all of the namespaced classes moving under the src directories, the <tt>tmpl</tt> layout files and <tt>form</tt> xml files have been moved out into their own directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Extension and Dispatcher classes ==
===Extension===
In Joomla 3 the point where the Joomla core handed over to your component code was when it ran your <tt>helloworld.php</tt> code; if it was the frontend it ran your site <tt>helloworld.php</tt> code, or if was the backend it ran your admin <tt>helloworld.php</tt> code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the entry point into your component code is your Extension class, both for site and admin, found in <tt>admin/src/Extension/HelloworldComponent.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When the Joomla core application wants to start executing the component code it creates an instance of <tt>HelloworldComponent</tt>, just to get a handle on the component code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly (as described below) other Joomla classes such as Router or Categories need to call certain Helloworld methods (eg custom router functions). In Joomla 3 these methods were written in certain Helper files etc. In Joomla 4 the principle is that the component creates an instance of the <tt>HelloworldComponent</tt> Extension class, and calls the required methods on that instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This Extension class isn't anything like a big container class for the component, it's more like a glue class, providing a way in to the Helloworld component, enabling the Joomla core and other components call the methods which they want to call.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla core wants to execute the component code, the key method it is looking for in your <tt>Extension</tt> instance is <tt>getDispatcher</tt>, and it expects to get back a <tt>Dispatcher</tt> instance. The <tt>HelloworldComponent</tt> extends <tt>MVCComponent</tt>, which in turn extends <tt>Component</tt>, and it is this class which defines <tt>getDispatcher</tt> for us.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Dispatcher===
When Joomla wants to run the Hello World component, it gets the <tt>Dispatcher</tt> instance as described above and then calls the <tt>dispatch</tt> method on it. It is this <tt>dispatch</tt> function which replaces the functionality in the admin and site <tt>helloworld.php</tt> files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's look at the main lines of code in our Joomla 3 admin <tt>helloworld.php</tt> file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="site/views/form/view.html.php">
<syntaxhighlight lang="php">
if (!JFactory::getUser()->authorise('core.manage', 'com_helloworld'))
{
throw new Exception(JText::_('JERROR_ALERTNOAUTHOR'));
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Get an instance of the controller
$controller = JControllerLegacy::getInstance('HelloWorld');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Execute the Request task method
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Redirect if set by the controller
$controller->redirect();
</syntaxhighlight>
</span>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code
* performs some permissions checks
* instantiates the appropriate Helloworld controller
* executes the appropriate method in that controller
* implements any redirect set by the controller
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Model-View-Controller]] for further details of how this works in Joomla 3. The second and third steps used the <tt>task</tt> parameter within the URL query to determine the correct controller class to instantiate and method to call. If no <tt>task</tt> parameter was present then it instantiated the controller in <tt>controller.php</tt> and called the <tt>display</tt> method. Otherwise it instantiated one of the controllers in the <tt>controllers</tt> subfolder (eg <tt>controllers/helloworld.php</tt>) and called the appropriate method on it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>ComponentDispatcher::dispatch</tt> method (in <tt>libraries/src/Dispatcher/ComponentDispatcher.php</tt>) now provides this functionality, but in a nicer way. After checking the permissions it uses the <tt>task</tt> by considering its parts as <tt><controller type>.<method></tt> (taking 'display' as default if either part is missing). It will then pass control to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* an instance of the class <Controller type>Controller
* calling the function <method>
* using the admin or site controller, as appropriate
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In this way the naming of the controllers is consistent - we have DisplayController, HelloworldController and HelloworldsController, all in the same folder.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Dispatcher class can thus be considered as providing some 'routing - execution' functionality, enabling us to find the right controller and function within that controller, and it is cleaner to have this in a separate class rather than in the <tt>JControllerLegacy</tt> class as it was in Joomla 3.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Since the Hello World tutorial uses the standard Joomla pattern for selecting the class and method based on the <tt>task</tt> and has the same permissions checks, we can use the <tt>dispatch</tt> code as it stands in <tt>ComponentDispatcher</tt>, and don't need to define a special class of our own.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Factory classes ==
In Joomla 3 many classes had static <tt>getInstance</tt> methods which returned an instance of that class, configured with the parameters passed to <tt>getInstance</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the <tt>getInstance</tt> methods have been deprecated in favour of using Factory classes. The preferred mechanism is now to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* get an instance of the appropriate Factory class (how we do that is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below)
* call the <tt>createSomething()</tt> method of the Factory class with relevant parameter values to generate an instance of the Something class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===MVC Factory===
In this section the <tt>MVCFactory</tt> class refers to the one in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory class will instantiate Controller, View, Model and Table instances on our behalf, and it does this by generating the classname of the class and then calling <tt>new</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The way it works is as follows:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Each component gets an individual MVCFactory instance which is constructed passing the component's namespace as a parameter (so in our case 'Robbie\Component\Helloworld'). (How this MVCFactory instance is created is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below).
# The MVCFactory createController / createView / createModel / createTable function is then called, passing the name of the Controller / Model / View / Table and the prefix (which specifies whether the administrator or site class is required).
# The create function forms the classname from this data and calls <tt>new</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory create functions just form the classname from the parameters they're passed. The intelligence for working out what name and prefix should be used to form the appropriate classes for an incoming HTTP request is
* in the dispatcher code for defining the controller to use
* in the controller for the view and model
* in the model for the table
and, for example, the names of the classes created for a request with URL query <tt>?option=com_helloworld&view=viewname</tt> and no <tt>task</tt> parameter will be
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<namespace>\Controller\DisplayController
<namespace>\View\Viewname\HtmlView
<namespace>\Model\ViewnameModel
<namespace>\Table\ViewnameTable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you need an alternative name then you can override the appropriate getView, getModel or getTable function – as for example was done in the [[J3.x:Developing an MVC Component/Adding Custom Fields#Front-end_Form|Adding Custom Fields step, frontend Form section]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So from the outside this is pretty much the same as in Joomla 3. However, note that the <tt>$prefix</tt> parameter in calls to <tt>getModel</tt> etc is subtly different
* in Joomla 3 this referred to a prefix to be applied to the classname – in the tutorial code we used 'HelloWorldTable' as the prefix part of the 'HelloWorldTableHelloWorld' classname.
* in Joomla 4 this refers to a prefix higher up the classname path, and should be set to either 'Site' or 'Administrator' (the capital letter at the start is optional), depending on whether you want the class under 'Robbie\Component\Helloworld\Site' or 'Robbie\Component\Helloworld\Administrator'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVC Factory class is now the Joomla recommended way to create the controller, view, model and table classes, by using the eg <tt>getModel()</tt> method, and the use of <tt>getInstance()</tt> for these classes is now deprecated. However, the use of these functions is restricted:
* in the controller class you can call <tt>$this->getView($viewname, $viewtype, $prefix, $config)</tt> to create a view and <tt>$this->getModel($modelname, $prefix, $config)</tt> to create a model.
* in the view class you can call <tt>$this->getModel($modelname)</tt>, but only for models which the controller has previously defined using <tt>$view->setModel($modelname, $default)</tt>. It doesn't create a new model instance.
* in the model class you can call <tt>$this->getTable($tableclass, $prefix, $options)</tt> to create a table instance. Controllers and views can access the table classes in this way, by going via a model.
These restrictions do have an impact on moving away from using <tt>getInstance()</tt>, and indeed in Joomla 4.2.6 you will still find several <tt>getInstance()</tt> calls within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Factory Classes===
Several other Factory classes have been introduced in Joomla 4, enabling you to get instances of core classes such as Form, User, CacheController, etc, usually by calling a createSomething function on the Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Associated with the Factory class is a FactoryInterface, a PHP Interface which specifies the key functions which the Factory class must implement. For example, with <tt>libraries/src/Categories</tt> we have:
* CategoryFactoryInterface – which specifies the <tt>createCategory</tt> function
* CategoryFactory implements CategoryFactoryInterface – which provides the <tt>createCategory</tt> function.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Dependency Injection ==
===Overview===
The DI container is one of the significant new additions to Joomla 4. It's basically a repository of key-value pairs where:
* the key is a string which is the name of a class or interface
* the value is an instance of the relevant class, or a function that returns an instance of that class.
You put things into the container using <tt>set()</tt> passing:
* the class name or interface name
* a function which returns an instance of the class (or an instance of the class)
* a boolean defining whether the class instance may be shared or not
* a boolean defining whether this entry into the DI container is protected or not (an error will be raised if you try to overwrite a protected entry by calling <tt>set()</tt> again using the same key).
The function <tt>share()</tt> is basically the same as <tt>set()</tt> with the <tt>shared</tt> boolean set to true.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You get things out of the container by calling <tt>get()</tt> passing the key of the resource you want. The container will
* find the key in the container
* if the value isn't already a class instance, then it will run the associated function to generate an instance of the class
* if the resource is shared, it will store the class instance, so that on subsequent invocations of <tt>get()</tt> it can just return the instance
* return the class instance to you
You can also define aliases for each key in the container, which means that you call <tt>get()</tt> passing either the key or an alias of the key.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The DI container is initialised in <tt>library/src/Factory.php createContainer()</tt> which results in the <tt>register()</tt> function being called in each of the class files in <tt>libraries/src/Service/Provider</tt>. By looking through those files you can see what gets put into the DI container upon initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===JConfig Example===
Let's consider the example of JConfig which holds the system global configuration. If you look inside <tt>libraries/src/Service/Provider/Config.php</tt> then you'll see the <tt>register()</tt> function and that it stores in the DI container a resource with:
* key = 'JConfig'
* value = an anonymous function - which loads what's in <tt>configuration.php</tt> into a <tt>Registry</tt> object, and returns it
* shared flag = true (because the <tt>share()</tt> function is used)
* protected flag = true
Then when you do
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$config = $container->get('JConfig');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will run the anonymous function and return the Registry object to you. As the 'shared' boolean is set it will also store a copy of the class instance locally in the container to be returned on subsequent calls of <tt>get('JConfig')</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Justification===
What's the point of all this?
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The advantage of dependency injection is that it allows classes to be easily mocked for testing. The file <tt>libraries/src/Service/Provider/Config.php</tt> can be replaced to return to a DI container <tt>get()</tt> call a mock class instead of the usual <tt>JConfig</tt>. This is in comparison to Joomla 3 where <tt>Factory::getConfig()</tt> code directly reads the <tt>configuration.php</tt> into a Registry structure and returns it – which makes it harder to mock.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The [https://api.joomla.org/cms-4/classes/Joomla-CMS-Factory.html Factory API] has several functions which are marked as deprecated with advice to get the object from the DI container instead.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Several of the other Factory classes (eg Form, Language, Menu, User) are in the DI container – so that we can get an instance of them via eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Factory::getContainer()->get('Joomla\CMS\Toolbar\ToolbarFactoryInterface')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to get a Toolbar instance. However, this only works for singleton classes which aren't specific to the needs of a particular extension. We'll see shortly how to make it work for class instances which need to be specific to a component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As indicated above, Joomla is moving away from using the class static <tt>getInstance()</tt> functions. We can see now that this is not only because it's more pure from an object oriented perspective. But also creating class instances from the DI container, or from Factory objects which are obtained from the DI container, builds in the dependency injection which allows classes to be more easily mocked, and hence more easily tested.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==services/provider.php==
We're now finally in a good position to understand what's happening in our services/provider.php file, and we'll explore this by walking through what happens whenever this line in libraries/src/Component/ComponentHelper.php <tt>renderComponent</tt> is run:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is run whenever Joomla has worked out which component is to be run on the requested web page, and it wants to run that component to capture its output.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 1 Create Child DI Container===
Joomla first creates another DI container (initially empty) just for this component, and links it to the main DI container via a parent field in the child DI container structure.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Now whenever <tt>set()</tt> is called on this DI container the key-value pair is inserted into the child container. Whenever <tt>get()</tt> is called on it, the resource is obtained from the child container, but if it's not found there then the parent container is searched also.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 2 Run register() in provider.php===
Next we encounter these lines (in <tt>libraries/src/Extension/ExtensionManagerTrait.php</tt>), where <tt>$path</tt> contains the path of our helloworld admin/services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$provider = require_once $path;
// Check if the extension supports the service provider interface
if ($provider instanceof ServiceProviderInterface) {
$provider->register($container);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here we see 3 things:
# our provider.php should return some object (so that <tt>$provider</tt> gets set to something)
# what is returned should implement ServiceProviderInterface (you can see in <tt>libraries/vendor/joomla/di/src/ServiceProviderInterface.php</tt> what is expected)
# the code then runs the <tt>register</tt> function on that object, passing as a parameter the child DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider a minimal version of our provider.php file. This would actually support steps in the Joomla 3 tutorial up to and including the [[J3.x:Developing an MVC Component/Adding AJAX|Adding Ajax step]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {

public function register(Container $container): void
{
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
}
};
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As you can see from the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
this file does indeed return something – it returns an instance of an anonymous class, one that implements <tt>ServiceProviderInterface</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it's not sufficient to just provide the <tt>register</tt> function in the class, we also need to explicity state that the class implements <tt>ServiceProviderInterface</tt>. This now happens in several places in Joomla, so if you're debugging your component and wondering why a function you expect to be called isn't being called, then check to make sure that you don't have to explicitly add the appropriate <tt>implements <Interface></tt> clause to your class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Next we look at the 3 lines in the <tt>register</tt> function
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3a Registering our MVC Factory===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here our <tt>MVCFactory</tt> refers to <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in libraries/src/Extension/Service/Provider/MVCFactory.php, and you should have a look at this file. This is a file similar to our provider.php file, but it's a named class, and it doesn't return anything. When we do:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
new MVCFactory('\\Robbie\\Component\\Helloworld')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it creates an instance of this class, and in the constructor it stores locally in <tt>$this->namespace</tt> our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>registerServiceProvider</tt> function then calls the <tt>register</tt> function of this instance, which runs (in its minimalist form):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
MVCFactoryInterface::class,
function (Container $container) {
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
return $factory;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So what gets entered into our child DI container is a key-value pair with:
* key = MVCFactoryInterface::class (this is just a shorthand form to obtain a string of the fully qualified name – ie 'Joomla\CMS\MVC\Factory\MVCFactoryInterface')
* value = a function which returns an instance of <tt>\Joomla\CMS\MVC\Factory\MVCFactory</tt>.
This is our MVCFactory class which generates our Controllers, Views, Models and Tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Notice that we're passing our namespace as a parameter <tt>$this->namespace</tt>. Because this function is a closure, this variable will still be available when we run this function later, and when the MVCFactory class is instantiated the namespace will be passed into the constructor, stored locally, and then subsequently used to form the fully qualified names of our Controllers, View, etc. So this is how we get instantiated the MVCFactory class which is specific to our component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3b Registering the Dispatcher Factory===
Careful: ComponentDispatcherFactory refers to two different classes here!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This ComponentDispatcherFactory is Joomla\CMS\Extension\Service\Provider\ComponentDispatcherFactory in libraries/src/Extension/Service/Provider/ComponentDispatcherFactory.php. Similar to the above, the ComponentDispatcherFactory service provider class stores locally our namespace, and then when <tt>register</tt> is called it executes:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentDispatcherFactoryInterface::class,
function (Container $container) {
return new \Joomla\CMS\Dispatcher\ComponentDispatcherFactory($this->namespace,$container->get(MVCFactoryInterface::class));
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so a second entry is added to the child DI container with:
* key = ComponentDispatcherFactoryInterface::class
* value = a function which returns an instance of the ComponentDispatcherFactory (the other ComponentDispatcherFactory class!), where the class constructor will be passed the namespace ('\\Robbie\\Component\\Helloworld') and an MVCFactory instance, retrieved from the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that the code
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->get(MVCFactoryInterface::class)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
will get from the container an entry with key = 'Joomla\CMS\MVC\Factory\MVCFactoryInterface' – which is what we entered into the container in step 3a – and will run the function associated with this key, and then return the object which this function returns. This returned object will be an instance of '\Joomla\CMS\MVC\Factory\MVCFactory', constructed using our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3c Including the Extension===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will put into the child DI container a key-value pair with
* key = ComponentInterface::class
* value = the function which will create an instance of our <tt>HelloworldComponent</tt> (ie our Extension class), and pass into the constructor an instance of the ComponentDispatcherFactory class, retrieving what was entered into the child DI container in Step 3b.
It will call <tt>$container->get(MVCFactoryInterface::class)</tt>, getting an MVC Factory instance from what was entered into the DI container in Step 3a.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It will then associate our component with this MVC Factory instance via the <tt>setMVCFactory</tt> call. Significantly this will then allow our component to access this instance later, via a call to <tt>getMVCFactory</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3 Summary===
We have now got 3 entries in our child DI container, keyed by
* key = MVCFactoryInterface::class, value is a function returning an MVCFactory instance
* key = ComponentDispatcherFactoryInterface::class, value is a function returning a ComponentDispatcherFactory instance
* key = ComponentInterface::class, value is a function returning our HelloworldComponent, an instance of our Extension class.
The important aspect is that these entries are all aware of our namespace '\Robbie\Component\Helloworld' and will return instances of these classes which are specific to our Helloworld component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 4 Retrieving from the DI Container===
Joomla will then execute the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $container->get($type);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
where <tt>$type</tt> contains 'Joomla\CMS\Extension\ComponentInterface'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This starts the process of retrieving from the DI container the 3 entries which we put in, and will run our code in services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We end up with a HelloworldComponent instance, which has:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. a ComponentDispatcherFactory instance passed into the constructor, and which is saved locally by the constructor code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function __construct(ComponentDispatcherFactoryInterface $dispatcherFactory)
{
$this->dispatcherFactory = $dispatcherFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This code is in libraries/src/Extension/Component.php, in the class which our HelloworldComponent extends, via the class MVCComponent).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. an MVC Factory instance, stored by the HelloworldComponent <tt>setMVCFactory</tt> call
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 5 Call boot() on our Component===
Joomla calls:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
if ($extension instanceof BootableExtensionInterface) {
$extension->boot($container);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will call <tt>boot</tt> within our HelloworldComponent, and allows us to perform some initialisation within our component. We'll return to this later, in the section on [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#HTML_Snippets|HTML snippets]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note again that Joomla checks that our HelloworldComponent class implements BootableExtensionInterface before calling <tt>boot</tt>. It's not sufficient to just provide the <tt>boot</tt> function, we have to explicitly declare that our HelloworldComponent implements the interface.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 6 Get the Dispatcher===
Returning to our key line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
we have now accomplished the first part <tt>bootComponent($option)</tt>, and this has returned our HelloworldComponent instance. Now we call <tt>getDispatcher($app)</tt> on this instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This code is also in libraries/src/Extension/Component.php, in the Component class which our HelloworldComponent extends:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function getDispatcher(CMSApplicationInterface $application): DispatcherInterface
{
return $this->dispatcherFactory->createDispatcher($application);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We call <tt>createDispatcher</tt> on our ComponentDispatcherFactory class instance which we saved in Step 4. This code is in libraries/src/Dispatcher/ComponentDispatcherFactory.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createDispatcher(CMSApplicationInterface $application, Input $input = null): DispatcherInterface
{
$name = ucfirst($application->getName());

$className = '\\' . trim($this->namespace, '\\') . '\\' . $name . '\\Dispatcher\\Dispatcher';

if (!class_exists($className)) {
if ($application->isClient('api')) {
$className = ApiDispatcher::class;
} else {
$className = ComponentDispatcher::class;
}
}

return new $className($application, $input ?: $application->input, $this->mvcFactory);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code checks if we have our own Dispatcher class (our Helloworld tutorial doesn't, but <tt>com_users</tt> for example has its own). So it creates a <tt>ComponentDispatcher</tt> instance, and passes into its constructor the MVC Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that this ComponentDispatcherFactory instance is what was instantiated when it was retrieved from our child DI Container (from being inserted in step 3b), and hence it already knows about our namespace, and has a pointer to our MVCFactory class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 7 call dispatch()===
This is the final aspect to our line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We're now back to what was described in the Dispatcher section above, except that now we can see that this Dispatcher instance has a pointer to our MVC Factory instance (which knows about our namespace prefix), so when the Dispatcher code wants to create a Controller it can use that MVC Factory instance to instantiate it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's been a long and tortuous journey to get here, but the significant thing is that all of our key class instances have been obtained via the DI Container. If we want to mock out any of those classes for testing then all we need to do is replace the relevant services/provider file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Javascript and the Web Asset Manager ==
The web asset manager has been introduced in Joomla 4 and is well documented [[J4.x:Web_Assets|here]]. It provides a much-improved means of managing JS and CSS resources, and a framework for handling their dependencies.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Component Javascript and CSS files should now be stored in the <tt>media</tt> folder, and the Web Asset Manager used to register them and output them on specific web pages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following assets have been registered in the tutorial <tt>joomla.asset.json</tt>, and you should have a look at that file now.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.validate-greeting===
This is the code for client validation of the helloworld greeting field using a regex, and it is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it is dependent upon jQuery and the Joomla <tt>form.validator</tt> script, so those both get included as dependencies.
If we didn't have specific validation on our form then we would need to include explicitly the <tt>form.validator</tt> script in order for the basic Joomla field validation to be included, eg in the tmpl file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->document->getWebAssetManager()->useScript('form.validate');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that this requires us to have a <tt>class="form-validate"</tt> on the </tt><form></tt> html element.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.fix-permissions-ajax-call===
This is the code which copies the value from the greeting field into the title field, so that the Ajax calls setting the permissions work correctly. The js code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.enable-tooltips===
This is the code which enables bootstrap tooltips to operate, including allowing them to include html code. It's used to display the image as a tooltip within the admin <tt>helloworlds</tt> view.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.openstreetmap===
This is defined as a preset, comprising the helloworld js and css code for the map display, as well as the dependency named 'com_helloworld.openlayers' relating to the openlayers CSS and js code. The code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.admin-helloworlds-modal===
This is the js code for selecting an individual helloworld record within a modal, and passing its details to the form in the main window. Its code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===submitbutton.js===
In the Joomla 3 code we introduced in [[Special:MyLanguage/J3.2:Developing_an_MVC_Component/Adding_verifications|Adding Verifications]] a js file which controlled when the form was submitted. It differentiated between buttons such as <tt>Save</tt> (which submitted the form) and <tt>Cancel</tt> (which didn't).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 there is a more sophisticated version of <tt>Joomla.submitbutton</tt> (found in media/system/js/core.js) which uses the CSS classes which the Toolbar functionality sets on the buttons to determine whether the form should be submitted or not. And you can override whether the validation is performed by adding a third parameter to the <tt>submitbutton</tt> js call. For example, to avoid validation being performed when a button is clicked you can set on the button element:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
onclick="Joomla.submitbutton('controller.method', '', false)"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As this is sufficient for what we need in the tutorial, the custom <tt>submitbutton.js</tt> has been removed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Interaction with other components ==
The way that Joomla interacts with components has changed in Joomla 4. In general the Joomla functionality will boot the component using something like:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $app->bootComponent($option);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and in our case this will return an instance of the <tt>HelloworldComponent</tt> class. It will then try to call certain methods on our extension object, as described below.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_categories===
In the backend the helloworld functionality can display to the administrator
* the view of the helloworld messages
* the view of the helloworld categories
The categories view is generated by <tt>com_categories</tt>, and in Joomla 4 these component categories views display the number of component records there are for each of the possible published status values. To do this the categories component executes the following code (in administrator/components/com_categories/src/Model/CategoriesModel.php):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof CategoryServiceInterface) {
$component->countItems($items, $section);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So our HelloworldComponent must:
* declare that it implements <tt>CategoryServiceInterface</tt>
* provide an implementation of <tt>countItems</tt>
We provide <tt>countItems</tt> by using a trait in libraries/src/Categories/CategoryServiceTrait.php, which (with the assistance of a helper function) does the query on our behalf. We just need to tell it:
* the name of our table – in the callback <tt>getTableNameForSection</tt>
* the database field in which we hold the published status – in <tt>getStateColumnForSection</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_associations===
Remember that <tt>com_associations</tt> is the component which is run whenever you click on Multilingual Associations in the admin backend.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Under Joomla 3 we provided an associations helper file as described in [[J3.x:Multilingual Associations/Developers|Multilingual Associations/Developers]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the helper file remains basically the same, but <tt>com_associations</tt> primarily tries to find the helper file via the extension class; here's the code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($extensionName);
if ($component instanceof AssociationServiceInterface) {
return $component->getAssociationsExtension();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's expecting that:
* the extension (HelloworldComponent in our case) implements <tt>AssociationServiceInterface</tt>
* its <tt>getAssociationsExtension</tt> method returns the helper class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The easiest thing would be just to code <tt>getAssociationsMethod</tt> and get it to return <tt>new AssociationsHelper</tt>. However, we follow the Joomla 4 principle of putting key classes into the Dependency Injection container, and retrieving them later, by having the following code in our services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(AssociationExtensionInterface::class, new AssociationsHelper());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The above line puts a key-value pair into our child DI container
* key = 'Joomla\CMS\Association\AssociationExtensionInterface'
* value is an instance of our <tt>AssociationsHelper</tt> class.
We then retrieve it later and use the setter:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setAssociationExtension($container->get(AssociationExtensionInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so that whenever
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getAssociationExtension()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
is called it returns the <tt>AssociationsHelper</tt> class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_fields===
<tt>com_fields</tt> is the component which is run when an administrator clicks on the Fields or Field Groups menuitem within the backend, and this functionality was included in the [[J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Adding Custom Fields]] tutorial step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>com_fields</tt> component stores the custom fields and field groups for all components in the database tables <tt>#__fields</tt> and <tt>#__fields_groups</tt>, and these tables are partitioned into "sections", one section per component. For our helloworld component the section is named "helloworld".
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within the section we have 2 "contexts" – one for the helloworld messages (called "com_helloworld.helloworld") and one for the helloworld categories (called "com_helloworld.categories"). This enables us to define custom fields for both our helloworld records and helloworld category records.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When <tt>com_fields</tt> runs it checks both the section and contexts at various times. For example, when an admin selects Helloworld / Fields on the backend then <tt>com_fields</tt> checks the section which was defined in the menuitem in the manifest file (see [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Sidebar|below]]). Here's the code in administrator/components/com_fields/src/Helpers/FieldsHelper <tt>extract</tt> function:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
$newSection = $component->validateSection($parts[1], $item);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And when <tt>com_fields</tt> wants to display the little dropdown menu of contexts (to allow the administrator to set custom fields on either helloworld items or categories) it calls (in administrator/components/com_fields/src/Fields/FieldcontextsField.php <tt>getOptions()</tt>):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
return $component->getContexts();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So it's clear that our component extension class must :
* implement <tt>FieldsServiceInterface</tt>
* provide the <tt>validateSection</tt> and <tt>getContexts</tt> methods
So in upgrading to Joomla 4 we've just moved those two methods from the helper file to the extension class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Router===
The Joomla router will access our custom router code:
* whenever it wants to parse an SEF route which it has identified as belonging to <tt>com_helloworld</tt>
* whenever it wants to build an SEF route from a call to <tt>Route::_()</tt> where the option = "com_helloworld".
To find our custom router it will:
* boot the <tt>com_helloworld</tt> extension
* check that the extension implements <tt>RouterServiceInterface</tt>
* call <tt>createRouter</tt> on our extension instance
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In our services/provider.php file we have (careful again - 2 different RouterFactory classes!):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new RouterFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which from libraries/src/Extension/Service/Provider/RouterFactory.php puts into our child DI container an entry with:
* key = "Joomla\CMS\Component\Router\RouterFactoryInterface"
* value is a <tt>\Joomla\CMS\Component\Router\RouterFactory</tt> instance, constructed with our namespace
We then retrieve this in the line in our services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setRouterFactory($container->get(RouterFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And then within our extension class we have
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use RouterServiceTrait;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which includes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function setRouterFactory(RouterFactoryInterface $routerFactory)
{
$this->routerFactory = $routerFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which stores the <tt>routerFactory</tt> locally and
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return $this->routerFactory->createRouter($application, $menu);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which provides our extension's <tt>createRouter</tt> call that the Joomla Router expects.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>routerFactory::createRouter</tt> method is in libraries/src/Component/Router/RouterFactory.php. It looks for a class in our site namespace </tt>Robbie\Component\Helloworld\Site\Service\Router</tt> which is in our site/src/Service/Router.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
At this stage we have a choice, we can either:
* provide a traditional custom router, with the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions, or
* use the more modern <tt>RouterView</tt> mechanism.
By default in the upgraded tutorial code the Router View option has been coded in the Router.php file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====RouterView====
In the <tt>RouterView</tt> case the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions are in the <tt>RouterView</tt> class which we extend, and we provide
* a constructor with router view configuration
* methods <tt>getHelloworldId</tt> and <tt>getCategoryId</tt> which are used to obtain from the SEF segment the <tt>id=</tt> and <tt>catid=</tt> parts of the internal URL
* methods <tt>getHelloworldSegment</tt> and <tt>getCategorySegment</tt> which are used to generate segments for the SEF URLs based on the <tt>id=</tt> and <tt>catid=</tt> parts within the <tt>Route::_()</tt> parameter.
Unfortunately there doesn't seem to be a good guide to configuring the RouterView class. There is some documentation available [https://www.dionysopoulos.me/book/com-router-routerview.html here].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the helloworld tutorial we have 3 views
* a view which displays a single helloworld record
* a view which displays a single helloworld category, and the helloworld records associated with it
* a view which displays the frontend form
So we need 3 Router Views associated with these.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'form' view doesn't have an associated id or catid so it's just a fixed URL, and the router just has to convert between the alias of the form menuitem and the Itemid / view parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'category' view has an associated id (of the category record), and an SEF URL will use the category path down the Categories Nested Set table structure, hence <tt>setNestable()</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'helloworld' view has an associated id (of the helloworld record), and in an SEF URL in the category view the helloworld record alias is added to the category path (hence <tt>setParent()</tt>). But although the helloworld records use a Nested Table structure in the database, the URLs just include the alias of the single record, and so <tt>setNestable()</tt> is not used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There doesn't seem to be a way to configure an additional SEF URL scheme which just displays a helloworld segment, without a category segment.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====Traditional Router====
To use the traditional router in the tutorial code you should uncomment the function in the extension class:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return new TraditionalRouter($application, $menu, $this->categoryFactory, $this->getDatabase());
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will cause the code in site/src/Service/TraditionalRouter.php to be used. However, changes in the Joomla 4 router mean that the interaction between it and the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> methods have changed. This requires significant changes to the <tt>preprocess</tt> and <tt>build</tt> methods, but only a minor change to <tt>parse</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. Previously Joomla injected into the <tt>$query</tt> parameters the <tt>Itemid</tt> of the active menuitem (ie the id of the menuitem the user is currently on). This meant that we had to change the <tt>Itemid</tt> for links generated by the Language Switcher module (which generates the flags for switching between languages), and these links being associated with a different language would obviously use a different <tt>Itemid</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 you get an <tt>Itemid</tt> in the <tt>$query</tt> parameters only if you specified an <tt>Itemid</tt> in the <tt>Route::_()</tt> call. For others you have to work out which menuitem to use yourself, by using the Joomla menu/menuitems API to find details of the configured menuitems, and work out which to use based on the other <tt>$query</tt> parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You do this in the <tt>preprocess</tt> method, and then the <tt>Itemid</tt> you set will be passed in the <tt>$query</tt> parameters to the <tt>build</tt> method.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. In some instances the <tt>Route::_()</tt> URL you're generating matches exactly one of the configured menuitems on the site. In this case the <tt>$query</tt> parameters will match those in the menuitem <tt>"query"</tt> array, and you have to remove explicitly remove the 'view', 'id' and 'catid' parameters so that they don't appear as URL query parameters after the normal SEF URL of the menuitem.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
3. The custom router will be used to build the URLs for the helloworld menuitems shown in menus on the page. For these the <tt>$query</tt> parameters will have the view / id / catid associated with those menuitems. Note that even if you remove these in your <tt>preprocess</tt> method, Joomla will inject them again into the <tt>$query</tt> array when it's passed to your <tt>build</tt> method, so you'll have to remove them again there!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
4. In the <tt>parse</tt> method you now have to unset the <tt>$segments</tt>, or else Joomla will return an HTTP 404 (page not found). Otherwise <tt>parse</tt> works as before.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
5. I've implemented <tt>build</tt> only for when Multilanguage is enabled on the site. If it's not enabled an empty <tt>$segments</tt> array is just returned, without doing unset on any of the <tt>$query</tt> parameters, so these will appear as URL parameters after the SEF URL. Also it's not coded properly to deal with items which have language set to <tt>*</tt>. These include helloworld records, categories or menuitems (eg the helloworld form).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that the <tt>categoryFactory</tt> is also now passed to the router. This is so that it can be used instead of <tt>Categories::getInstance()</tt> to get access to the Categories API calls.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_tags===
Whenever we setup a Tags Menu Item Type which displays items having a given tag or tags, then <tt>com_tags</tt> displays those items as links, and uses route helper functions to generate the URL parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The route helpers <tt>com_tags</tt> expects to find loaded into the data of the <tt>#__content_types</tt> table, in the router field, and these have been set to:
* For links to helloworld items: 'HelloworldHelperRoute::getHelloworldRoute'
* For links to helloworld categories: 'HelloworldHelperRoute::getCategoryRoute'
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, <tt>com_tags</tt> doesn't boot the helloworld extension to get access to these, but rather seeks to find them in site/helpers/route.php, so that's where they continue to be.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(We also had a <tt>getCategoryRoute</tt> which was used by <tt>com_categories</tt> in administrator/components/com_categories/src/Helper/CategoryAssociationHelper. When a category was displayed on the frontend then the Language Switcher module (now Language Filter) used this function to generate the links to the Associated Categories. Our <tt>getCategoryRoute</tt> previously was necessary to insert the <tt>lang=<language tag></tt> parameter into the link URL, but since [https://github.com/joomla/joomla-cms/pull/39358 this change] the calling function inserts the <tt>lang</tt> parameter itself, so our <tt>getCategoryRoute</tt> function for this purposes is superfluous.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Deprecated APIs ==
With Joomla 4 there are a number of methods which are deprecated, with a view to removing them in Joomla 5.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Factory Methods===
Many of the <tt>Factory</tt> methods for getting singleton classes have been deprecated in favour of getting these classes via the DI container, and it appears that only class instances which should be obtained via Factory methods are:
* the Application – <tt>Factory::getApplication()</tt>
* the DI container – <tt>Factory::getContainer()</tt>
Here is a list of what has been changed in the tutorial code. Note that with some calls there are variants available, through the aliases defined in the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDbo'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\Database\DatabaseInterface;
...
$db = Factory::getContainer()->get(DatabaseInterface::class);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, in many classes the database instance is more easily (and efficiently) returned via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$db = $this->getDatabase();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is available in Model classes, custom field definitions, etc.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getUser();'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get the current user use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = Factory::getApplication()->getIdentity()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get a different user (whose id you know):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\User\UserFactoryInterface;
...
$user = Factory::getContainer()->get(UserFactoryInterface::class)->loadUserById($userid);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within models which extend Joomla\CMS\MVC\Model\BaseDatabaseModel and views which extend Joomla\CMS\MVC\View\HtmlView you can also use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = $this->getCurrentUser()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDocument()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication()->getDocument()</tt>, or within a View you can use <tt>$this->document</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getConfig()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Two options have been used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->getConfig()</tt> – returns a Registry object containing all the configuration values
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->get('access')</tt> – returns the value of the 'access' configuration parameter
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getLanguage()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication->getLanguage()</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JFactory::getCache('com_example', <type>)'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Cache\CacheControllerFactoryInterface;
...
Factory::getContainer()->get(CacheControllerFactoryInterface::class)->createCacheController(<type>)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated getInstance Methods===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general <tt>getInstance()</tt> calls have been deprecated in favour of obtaining the instance, either via a factory class or via the DI container. For example, within a controller you can use <tt>getModel()</tt> repeatedly to get different models (passing the relevant model names), which results in the MVCFactory class creating the Model classes.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there are currently some problems with replacing some getInstance calls. I expect that the Joomla team will resolve these issues over the course of the Joomla 4 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Categories::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is deprecated with a notice: "Use the ComponentInterface to get the categories". This means that we should get the category factory instance via the DI container. This is done in our services/provider.php by the lines:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Extension\Service\Provider\CategoryFactory;
...
$container->registerServiceProvider(new CategoryFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to put into our child DI container the closure which will create a Joomla\CMS\Categories\CategoryFactory instance, constructed with our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when our HelloworldComponent (Extension) instance is created:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We can then use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getCategoryFactory()->createCategory();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to create our Categories object, and in this way get access to the Categories APIs.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This createCategory method creates the instance by looking for the \\Site\\Service\\Category class within our namespace. The constructor in our class sets our extension ('com_helloworld') and table ('#__helloworld') and calls the parent Categories constructor with these options).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this means that the section of our code where we want to use the Categories APIs must have a pointer to a CategoryFactory instance. In the tutorial code for Joomla 3 there are 2 places where <tt>Categories::getInstance</tt> is used:
* in the custom router code, to handle building and parsing of the category parts of the SEF URL
* in the site category model, where the Categories APIs are used to obtain details of categories to display on the page.
For the custom router code, the CategoryFactory instance is passed as a parameter to the TraditionalRouter constructor so that it can be used there.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, the site category model is instantiated by the MVCFactory instance, and it doesn't make available a CategoryFactory instance. So in this category model the calls to <tt>Categories::getInstance()</tt> have been left, and you can still find a number of calls to <tt>Categories::getInstance</tt> within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Categories::getInstance()</tt> itself solves the problem of access to a CategoryFactory instance by rebooting our component again to get a pointer to our Extension instance, and thus to the category factory instance. However, this involves a lot of work, so <tt>getInstance</tt> caches locally the Categories instances and just returns one of them if it can.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Pushing the CategoryFactory to the model'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there is a way to get access to the CategoryFactory instance, by defining your own MVCFactory class, and pushing the instance down through it to the model. Here's how you can go about it:
* Define your own SuperMVCFactory class, which extends the Joomla Joomla\CMS\MVC\Factory\MVCFactory class, but which has a means of storing a CategoryFactory instance. Use the CategoryServiceTrait in libraries/src/Categories/CategoryServiceTrait.php
* Create your own version of the file libraries/src/Extension/Service/Provider/MVCFactory.php, which is the 'provider.php' like file for MVCFactory, but change it so that:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
becomes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new <namespace>\SuperMVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and include
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla creates a model such as CategoryModel it passes in its constructor the MVCFactory instance (so that the model can call createTable on it), so you can access it via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will return your SuperMVCFactory instance. So in this way within the model you can access the CategoryFactory, and use it to create the Categories instance via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()->getCategory() (from the CategoryServiceTrait)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you can get this working you can congratulate yourself on a good understanding of Joomla namespacing and dependency injection! A similar approach to address a similar problem is described [https://www.dionysopoulos.me/book/com-router-push-dependencies.html here]. If you get stuck you can always view the solution by viewing the github tutorial code selecting the branch [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial/tree/push-category-factory-to-mvc push-category-factory-to-mvc].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Table::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There are a couple of calls to <tt>Table::getInstance()</tt> within admin/src/Helper/AssociationsHelper.php in <tt>getItem()</tt>:
* <tt>Table::getInstance('Helloworld', 'Robbie\\Component\\Helloworld\\Administrator\\Table\\')</tt> to get an instance of our HelloworldTable class.
* <tt>Table::getInstance('Category')</tt> to get an instance of the Category table in libraries/src/Table/Category.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We could actually arrange for the AssociationsHelper class to get injected with the MVCFactory instance, so that the HelloworldTable class could be instantiated by it. However, we couldn't use the helloworld MVCFactory instance to create the Category table instance, as it's not in the helloworld namespace, and our MVCFactory instance creates table instances within our namespace only.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Toolbar::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The tutorial code uses <tt>Toolbar::getInstance()</tt> to get a Toolbar instance onto which it can attach the batch button in the helloworlds form. The Toolbar API documentation seems to suggest that we should replace
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Toolbar::getInstance('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
with
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this currently won't work. The problem is that all the other Joomla code uses <tt>getInstance('toolbar')</tt> to access the Toolbar class, including the code in administrator/modules/mod_toolbar/mod_toolbar.php which renders the toolbar. The <tt>getInstance</tt> method keeps track of the Toolbar instances in a local static variable <tt>$instances</tt>, and returns the same Toolbar instance on repeated invocations.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you use the second approach above you will get a Toolbar instance, but it won't be the same Toolbar instance as is stored in the <tt>$instances</tt> variable. It won't then be picked up by the Toolbar module, and so won't be rendered on the form.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Error Handling===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead of
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
JError::raiseError(500, implode('<br />', $errors));
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
you should throw an exception, using or extending one of the standard [https://www.php.net/manual/en/spl.exceptions.php PHP exceptions], eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
throw new \Exception(implode("\n", $errors), 500);
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===jimport===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
jimport is no longer necessary in order to get access to Path or File classes. All of the Joomla classes are found by the autoloader.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Methods related to Javascript===
'''JHtml::_('behavior.framework');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general, the use of JHtml::_('behavior.xxx') is now obsolete, and calls using this have been removed in the tutorial code. The 'behavior.framework' call referred to including jQuery. Where jQuery is necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.formvalidator');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by the <tt>form.validate</tt> javascript asset, and where necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It can also be included directly using the web asset manager:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$wa->useScript('form.validate')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.tooltip')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This no longer exists, and tooltips don't seem to be enabled by default in Joomla 4. This is replaced by the code in media/js/enable-tooltips.js.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('formbehavior.chosen')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The chosen js library seems to be no longer used, and using it will cause formatting issues if you include it in your tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''sortable'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The sortable js library provided the ability in the helloworlds view to drag rows up and down to change the ordering of the records. This has been replaced in Joomla 4 by the draggable library. To enable it you have to set:
* <tt>HTMLHelper::_('draggablelist.draggable');</tt>
* on your <tt><tbody></tt> element define the table in which dragging occurs and the URL of the Ajax call to set the ordering:
<source lang="php">
<tbody<?php if ($saveOrder) : ?> class="js-draggable" data-url="<?php echo $saveOrderingUrl; ?>" data-direction="<?php echo strtolower($listDirn); ?>" data-nested="true"
<?php endif; ?>>
</source>
* on your <tt>tr</tt> element within your <tt><tbody></tt> define the group of records in which dragging occurs (by category below):
<source lang="php">
<tr class="row<?php echo $i % 2; ?>" data-draggable-group="<?php echo $row->catid; ?>">
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==HTML Snippets==
There are two places in the tutorial where reusable snippets of HTML have beeen defined:
* For displaying the item associations in the helloworlds view:
* For displaying the position latitude and longitude fields within the batch options in the helloworlds view
These used different approaches:
* the item associations display was coded in an html helper file in admin/helpers/html/helloworlds.php and accessed via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JHtml::_('helloworlds.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
in the helloworlds tmpl file. (Although it did use a common joomla layout file underneath).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* the position field was coded as a layout in layouts/position.php, and rendered using
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JLayoutHelper::render('position', array());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When should you use one approach rather than the other? A significant difference is that layouts are designed so that an administrator can override them, via the Templates / Details and File functionality. So, for example, an administrator could change the position to show the longitude before the latitude. So it's more appropriate for layouts to focus on the html elements rather than functional logic, and particularly if you would want to allow an administrator to override the layout.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The layouts functionality in Joomla 4 hasn't changed significantly. One correction which has been made in the updated tutorial code has been to include the position.php file in a subfolder of layouts, ie in admin/layouts/helloworld/position.php rather than admin/layouts/position.php. It appears that in the Templates / Details and Files / Create Overrides tab the <tt>com_helloworld</tt> layout appears only if it's in a subfolder of /layouts.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>JHtml::_()</tt> approach has changed in Joomla 4. Rather than Joomla having to look for a helper file when it encounters something it doesn't recognise, it's expected that you should register such classes beforehand, and you do this by obtaining an instance of the Joomla\CMS\HTML\Registry class (it's a singleton class) and then calling <tt>register</tt> on it, passing
* the key you want to use
* an instance of your class
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Joomla pattern is to put the code in a file admin/src/Service/HTML/AdministratorService.php, and we have to ensure that our key won't be used elsewhere within Joomla, so in the tutorial we've used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Robbie\Component\Helloworld\Administrator\Service\HTML\AdministratorService;
...
register('helloworldadministrator', new AdministratorService)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when we call:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo HTMLHelper::_('helloworldadministrator.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will result in Joomla calling the <tt>association</tt> method in our class, passing the <tt>$row->id</tt> parameter.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We should get the Joomla\CMS\HTML\Registry class from the Dependency Injection container. Joomla components generally do this via their services/provider.php file, and then call <tt>register</tt> within the extension's <tt>boot</tt> function, described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Step_5_Call_boot.28.29_on_our_Component|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The extension uses HTMLRegistryAwareTrait which contains <tt>setRegistry</tt> and <tt>getRegistry methods</tt>. In services/provider.php there is:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\HTML\Registry;
...
$component->setRegistry($container->get(Registry::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets 'Joomla\CMS\HTML\Registry' out of the DI container and stores it within the
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
private $registry;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
variable of the HTMLRegistryAwareTrait included in the extension.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the <tt>boot</tt> function it calls
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getRegistry()->register('helloworldadministrator', new AdministratorService);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets the registry and calls <tt>register</tt> as required.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that <tt>boot</tt> is called whenever Joomla dispatches <tt>com_helloworld</tt>, both for the site and administrator, so it would make sense to check the Application <tt>isClient</tt> before deciding whether to register the HTML Helper service or not. This hasn't been included in the tutorial code though.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==User Interface Changes==
Joomla 4 introduced new templates, atum on administrator and cassiopeia on site, and in particular the administrator is built upon some UI rearrangements which affect the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Sidebar===
In Joomla 3 each component incorporated a sidebar which we coded in the <tt>addSubmenu</tt> function in admin/helpers/helloworld.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the administrator menu is in a vertical panel on the left hand side, and the Hello World submenu is built from entries in the helloworld.xml manifest file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<administration>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<submenu>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<menu link="option=com_categories&extension=com_helloworld">COM_HELLOWORLD_CATEGORIES</menu>
<menu link="option=com_fields&view=fields&context=com_helloworld.helloworld">MOD_MENU_FIELDS</menu>
<menu link="option=com_fields&view=groups&context=com_helloworld.helloworld">MOD_MENU_FIELDS_GROUP</menu>
</submenu>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===CSS Classes===
In several places the CSS classes defined in the html elements have been changed in Joomla 4. For example, for general layout the classes now align with the [https://getbootstrap.com/docs/3.4/css/ Bootstrap CSS Classes], and classes such as <tt>row-fluid</tt> and <tt>span3</tt> which were prominent in Joomla 3 have disappeared. If you're upgrading a Joomla 3 component then it's probably best (on the back-end at least) to find a similar Joomla component and use the overall html structure and css classes within its tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the tutorial code those classes which are specifically used by Bootstrap have been changed from eg 'data-target' to 'data-bs-target', and it has been necessary to change these to enable the functionality to work.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, not all of CSS class changes affecting solely the presentation have been reflected in the updated tutorial code. For example, in the <tt>helloworlds</tt> view, showing the list of helloworld messages, the display of the associations is different from that of other Joomla components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Fonts===
In Joomla 3 [[J3.x:Joomla_Standard_Icomoon_Fonts|Icomoon Fonts]] were used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 Font Awesome's free icons are used, and you can see what is available on their [https://fontawesome.com/v5/cheatsheet cheatsheet]. The icons are implemented using CSS pseudo-elements, as described [https://fontawesome.com/v5/docs/web/advanced/css-pseudo-elements here]. Basically they convert a CSS class into html content, namely a unicode value in the private use range. A couple of these have been implemented in the frontend form, in the Save and Cancel buttons, for example:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>span class="icon-cancel">/span <?php echo Text::_('JCANCEL') ?></tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(with angle brackets removed from the <tt>span</tt> tags to stop the icon just being displayed by the browser).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This class is defined in media/system/css/joomla-fontawesome.css (where you can find the list of icon classes supported):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
.icon-cancel:before {
content: "\f00d";
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so this includes in front of the text the unicode character <tt>f00d</tt>, which you can see on the cheatsheet as "times", and displayed as <span class="icon-cancel"></span>. You can also use <tt>fa-</tt> plus the icon name on the font awesome cheatsheet page. If you use Icomoon icon names in your code which you run under Joomla 4, then the icon displayed will be a Font Awesome icon (if there's one with the same name) or it will use a mapping which the Joomla team have defined to display a Font Awesome icon which resembles the Icomoon one.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Buttons and Links===
An accessibility principle is that <tt><a></tt> html elements should be used for links to other web pages, and <tt><button></tt> elements should be used for actions, eg on a form. To align with this, the <tt><a></tt> elements in the helloworld modal field (defined in admin/src/Field/Modal/Helloworld.php) have been changed to <tt><button></tt> elements. These are the Select and Clear buttons displayed when choosing a Helloworld record for a menuitem pointing to a Helloworld message. (The buttons also include fontawesome icons, by the way).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This change was actually made in Joomla in one of the Joomla 3 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Categories View===
In the Categories view of standard Joomla components there now appears columns which show for each category the number of items, split by published status. This is populated by <tt>com_categories</tt> calling each extension's <tt>countItems</tt> function, as described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_categories|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Miscellaneous Changes==
===Version History===
In Joomla 3 the tutorial code used the <tt>JTableObserver</tt> functionality to copy relevant changes from the Helloworld and Categories tables into the UCM tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it uses a plugin mechanism to subscribe to Table events 'onTableAfterStore' and 'onTableBeforeDelete'. The plugin can be found in plugins/behaviour/versionable, and it is activated by Joomla as part of its application initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The copying of fields from the table works roughly the same way as before, except that the name of the table where the versions are stored is now <tt>#__history</tt>, so the entries which have to be inserted into the <tt>#__content_types</tt> table are fairly similar. Because the folders in which forms are stored has changed in Joomla 4, the 'formFile' parameter is different (remember that this is where Joomla gets the field labels in order to display the Preview within the Versions modal window, otherwise just the names of the database columns will be output).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here's a summary of what needs to be done to enable versioning under Joomla 4. The Versioning Traits and Interface definitions are found in libraries/src/Versioning:
* Enter data into content_types database table
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Storing the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The Table class must implement VersionableTableInterface and provide <tt>getTypeAlias()</tt>, which returns 'com_helloworld.helloworld'. This type alias + the helloworld record id is used as the key to identify versions in the <tt>#__history</tt> table.
* Define <tt>save_history</tt> and <tt>history_limit</tt> options in config.php, and ensure these are both set.
* Add a <tt>version_note</tt> field into the output of the edit view's tmpl file (admin/tmpl/helloworld/edit.php).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Viewing and Restoring the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit Controller (admin/src/Controller/HelloworldController.php) should <tt>use VersionableControllerTrait</tt>.
* The edit Model (admin/src/Model/HelloworldModel.php) should <tt>use VersionableModelTrait</tt> and include a variable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public $typeAlias = 'com_helloworld.helloworld';
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit View (admin/src/View/Helloworld/HtmlView.php) – should display the Versions toolbar button if global config has <tt>save_history</tt> on.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Joomla 4 allows us to have different history version limits for helloworld items and categories, and this has been used in the configuration definition in admin/config.xml.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Setting Configuration Parameters in Install Script===
As you may remember, global configuration parameters relating to the Hello World component are defined in admin/config.xml and stored in the <tt>#__extensions</tt> table, in a JSON string in the params field of the record relating to <tt>com_helloworld</tt>. This means that when the component is first installed the params are not set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So, for example, even if the <tt>save_history</tt> is defined in config.xml to default to true, the versions won't be saved until an administrator actively saves the configuration parameters, because the Joomla versioning code assumes <tt>save_history</tt> to be false if it's not explicitly set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For this reason it makes sense to set any default configuration parameters in the install script.php, in the <tt>postflight</tt> method, and that has been done in this step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Tags===
Like version history, tags functionality has been changed to use a plugin – in plugins/behaviour/taggable – rather than the <tt>JTableObserver</tt> approach.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To enable tags the component table must implement TaggableTableInterface (in libraries/src/Tag), and provide the <tt>getTypeAlias()</tt> which is common to the Versioning functionality.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Whenever <tt>com_tags</tt> outputs helloworld messages or categories relating to a tag it displays them as links, and looks in the site/helpers/route.php file to find the route functions (as described above in [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_tags|com_tags]]). The class and method in this file must match the 'router' field within the data entered into the <tt>#__content_types</tt> table.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===media files===
Under Joomla 4 all of the media files are stored in the /media folder; these include javascript and css files (scss files too), as well as images such as the little flag symbols shown in the language switcher. Extensions being developed should store all of the js and css files in their /media folder, and then when the extension is installed these files are put under the extension's folder under the /media folder of the Joomla instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Patches==
Some bugs in Joomla were discovered during the course of updating the tutorial code to work under Joomla 4. If you find something doesn't work then make sure you're on at least Joomla 4.2.6 and check if you need one of the following patches:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
CategoryAssociationHelper.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39358/files
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
MediaField.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/issues/39203
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Category restore
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39474
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Contributors ==
*[[User:Robbiej|Robbie Jackson]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Prev: Adding Custom Fields|class=expand success}}</div>
</div>
</div>

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/28/it

2023-05-27T12:47:23Z

Ing Pulizzi: Created page with "$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');"

$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/27/it

2023-05-27T12:47:16Z

e anche in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> dove le associazioni vengono aggiunte dinamicamente al modulo per formare il campo di tipo <tt>modal_helloworld</tt> personalizzato:

J3.x:Developing an MVC Component/Upgrading to Joomla4/it

2023-05-27T12:47:05Z

Ing Pulizzi: Created page with "addruleprefix="Robbie\Component\Helloworld\Administrator\Rule" addfieldprefix="Robbie\Component\Helloworld\Administrator\Field""

<noinclude><languages /></noinclude>

{{:J3.1:Developing an MVC Component/it}}
Questo passaggio copre ciò che è coinvolto nell'aggiornamento del codice del tutorial per allinearlo con la versione 4 di Joomla.

== Introduzione ==
Questa pagina descrive i principali aspetti relativi allo sviluppo dei componenti che sono stati introdotti in Joomla 4 e descrive in dettaglio cosa è stato modificato nel codice del tutorial per allinearsi con v4.

Non è pratico dettagliare tutte le modifiche al codice sulla pagina Web come è stato fatto per i passaggi precedenti dell'esercitazione. Invece puoi trovare il codice come repository github su [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial Joomla 4 Tutorial code], e puoi confrontarlo con il codice del passaggio precedente del tutorial (Adding Custom Fields) su [https://github.com/robbiejackson/Joomla-3-MVC-Tutorial Joomla 3 MVC code]. Il codice di Joomla 4 replica tutte le funzionalità del codice di Joomla 3, con l'eccezione dell'implementazione dell'icona del piccolo pinguino introdotta in [[S:MyLanguage/J3.2:Developing an MVC Component/Adding decorations to the backend|Aggiunta di decorazioni al backend]] (che non è così rilevante data la modifica dell'interfaccia utente in Joomla 4 Administrator) e l'uso di un plug-in CAPTCHA ([[J3.x:Developing an MVC Component/Adding a frontend form|Adding a frontend form]] ). Probabilmente troverai utile avere a portata di mano questo codice Joomla 4 a cui fare riferimento mentre leggi questa pagina.

Il codice per questo passaggio è stato sviluppato seguendo ciascuno dei precedenti passaggi del tutorial e cercando di far funzionare ogni passaggio con Joomla 4.2.5. Poiché Joomla 4 si sta ancora evolvendo abbastanza velocemente, è possibile che alcuni aspetti qui citati vengano modificati durante la vita di Joomla 4. Sentiti libero di correggere gli aspetti in questa pagina e creare richieste pull su [https://github.com/robbiejackson /Joomla-4-MVC-Tutorial Joomla 4 github repository].

Se stai installando il codice del tutorial di Joomla 4 su una nuova istanza di Joomla, dovrai configurare la tua istanza per renderla multilingue e aggiungere le voci di menu nascoste di Ajax come descritto nel passaggio [[J3.x:Developing an MVC Component/ Utilizzo del filtro della lingua |Utilizzo del filtro della lingua]]. Assicurati inoltre che ogni record helloworld abbia una categoria valida.

=== Ulteriori letture ===
Puoi trovare [https://blog.astrid-guenther.de/en/der-weg-zu-joomla4-erweiterungen/ qui] un tutorial per lo sviluppo dei componenti di Joomla 4, simile a questo Joomla 3, e alcuni eccellenti Joomla 4 è disponibile anche la documentazione [https://www.dionysopoulos.me/book.html qui]. Entrambi questi riferimenti includono descrizioni degli impatti di Joomla 4 sullo sviluppo di altri tipi di estensioni Joomla (plugin, moduli e modelli), che non sono trattati qui.

Questo passaggio non copre tutto ciò che è necessario per aggiornare un componente da Joomla 3 a Joomla 4, solo gli aspetti coperti dal codice del tutorial. Se stai aggiornando il tuo componente Joomla 3, potresti trovare utile esaminare [[Potenziali problemi di compatibilità con le versioni precedenti in Joomla 4]].

== NameSpace ==
===NameSpace dei nomi dei componenti===
I NameSpace delle classi che utilizza la [https://www.php-fig.org/psr/psr-4/ PSR-4 recommendation] è stato gradualmente introdotto durante le versioni di Joomla 3 e con Joomla 4 è praticamente tutto con NameSpace

Ora è previsto che anche le estensioni di Joomla utilizzino i NameSpace di base per l'estensione definito nel suo file XML manifest. I componenti di Joomla usano uno NameSpace della forma <tt>Joomla\Component\<Nome componente></tt> es. <tt>Joomla\Component\Content</tt>, quindi seguendo questo schema ho dato una base al codice del tutorial spazio dei nomi di <tt>Robbie\Component\Helloworld</tt>. Ecco la riga nel file manifest helloworld.xml:

<namespace path="src">Robbie\Component\Helloworld</namespace>

(L'attributo <tt>path="src"</tt> indica che si aspetterà che le classi si trovino nella sottocartella <tt>src</tt>.)

Questo in realtà crea 2 prefissi dello spazio dei nomi, che puntano a cartelle specifiche nella nostra struttura di sviluppo helloworld e nella nostra istanza joomla live:

<tt>Robbie\Component\Helloworld\Administrator</tt> – punterà ad administrator/components/com_helloworld/src sull'istanza live ed è associato ad admin/src nella nostra area di sviluppo.

<tt>Robbie\Component\Helloworld\Site</tt> – punterà a components/com_helloworld/src sull'istanza live ed è associato a site/src nella nostra area di sviluppo.

Quindi Joomla ora si aspetta che tutti i nomi delle classi vengano trovati in quelle directory di base, con il nome del file che corrisponde al nome della classe e il nome della classe completo che corrisponde al percorso, ad esempio

<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> si troverà in
administrator/components/com_helloworld/src/Controller/DisplayController.php

<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> si troverà in
components/com_helloworld/src/Model/CategoryModel.php

'''Nota che le lettere maiuscole sono importanti nei namespace, nei nomi delle classi e nei nomi dei percorsi!'''

Quando Joomla 3 ha voluto chiamare le funzioni nel tuo componente, ha cercato determinati nomi di file in cartelle particolari e ha verificato che il nome della classe in quel file corrispondesse a quello previsto.

In Joomla 4 genera il nome completo della classe che vuole trovare, quindi cerca di trovarlo nella posizione in cui la raccomandazione PSR-4 lo aspetterebbe.

Quindi il namespace che specifichi nei tuoi file di classe deve essere allineato con il percorso del tuo file PHP, sotto la cartella di base <tt>src</tt> nel prefisso del tuo namespace.

Si noti in particolare come sono ora organizzati i file della classe <tt>View</tt>.

Inoltre, se usi una delle classi predefinite di PHP (ad es. <tt>Exception</tt>) nel tuo codice, aggiungi una barra rovesciata prima di essa (ad es. <tt>\Exception</tt>), altrimenti PHP cercherà di trovare nel tuo spazio dei nomi.

Se utilizzi definizioni di campi o regole personalizzate nei tuoi file xml del modulo, devi indicare a PHP quale prefisso dello spazio dei nomi utilizzare per cercarli, ad esempio in <tt>site/forms/add-form.xml</tt>:

addruleprefix="Robbie\Component\Helloworld\Administrator\Rule"
addfieldprefix="Robbie\Component\Helloworld\Administrator\Field"

<div lang="en" dir="ltr" class="mw-content-ltr">
and also in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> where the associations are added into the form dynamically to form the custom <tt>modal_helloworld</tt> type field:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Class Autoloading===
Joomla uses the PHP mechanism for [https://www.php.net/manual/en/language.oop5.autoload.php Autoloading Classes] and on startup registers a number of autoloaders – functions which get called when PHP can't find a given class. In particular the Joomla PSR-4 autoloader function (in <tt>libraries/loader.php</tt>) is responsible for finding classes of Joomla extensions whose code is in source files which are organised according to the PSR-4 recommendation. (Joomla library classes are autoloaded using a different autoloader – see <tt>libraries/vendor/composer/autoload_static.php</tt>).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can see the namespace prefixes of extensions on the Joomla instance by looking at <tt>administrator/cache/autoload_psr4.php</tt>. (These namespace strings have double backslashes, but in PHP they're the [https://stackoverflow.com/questions/25459197/single-or-double-slash-when-using-php-namespace same strings as those with single backslashes]). This is generated by Joomla looking through the component, module and plugin directories to find each extension's manifest file, and then processing these xml files to extract the <tt><namespace></tt> element – quite a lot of work, which is why it's cached I guess!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider what happens when Joomla wants our admin HelloworldController class. It might have something like
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$classname = 'Robbie\Component\Helloworld\Administrator\Controller\HelloworldController'
if (!class_exists($classname)) { …
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Assuming PHP doesn't already know about this class, the <tt>class_exists</tt> function will result in the classname being passed to the registered autoload function(s). The PSR-4 autoloader will then:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# go through its array of namespaces to try and match <tt>$classname</tt> from the start of the string.
# find 'Robbie\Component\Helloworld\Administrator' as a match
# see that this maps to "administrator/components/com_helloworld/src"
# extract the remainder of the classname: 'Controller\HelloworldController'
# treat this as the path down to the class file
# and so look for "administrator/components/com_helloworld/src/Controller/HelloworldController.php"
# check that in this file there's actually a class with that namespace + class name.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So in this way Joomla can go from a fully qualified class name to find the source code for that class. This makes it easier for us too when the core Joomla code is looking for one of our classes. We still need to know what class it's looking for, but once we know that, we know what we should call our class and where we should save the source code for it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Joomla Library classes===
Originally Joomla's core classes (beginning with a capital J) were global classes. Over the Joomla 3 versions and into Joomla 4 these migrated to their namespaced equivalents, but the original global classnames were still available as Joomla registered them as aliases (in the <tt>libraries/classmap.php</tt> file).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In a Joomla 4 extension you can still use these global classnames, except that in a namespaced file you'd have to prefix the name with a backslash to indicate a global class rather than one in your namespace (eg <tt>\JFactory</tt> instead of <tt>JFactory</tt>).
However it's pretty definite that the aliases will disappear at some stage, so the upgrade to Joomla 4 seems an appropriate opportunity to replace all your component's calls to the global JSomething classes to the namespaced equivalents. This involves adding the appropriate <tt>use</tt> statements, and all this has been done in the tutorial code. A useful mapping between the two can be found [https://github.com/nikosdion/joomlatypehints/blob/main/JoomlaObsoleteClasses.md here], where the new qualified classname can be copied and pasted into a <tt>use</tt> statement in your PHP file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
With reference to the [https://api.joomla.org/ Joomla API Documentation] there are 2 Joomla library namespaces:
* Joomla CMS classes – have namespaces <tt>Joomla\CMS\Something</tt> – are found under <tt>libraries/src/Something</tt>
* Joomla Framework classes – have namespaces <tt>Joomla\Something</tt> – are found under <tt>libraries/vendor/joomla/something/src</tt>
So a big advantage of namespacing is that you can immediately determine from the fully qualified class name in a PHP <tt>use</tt> statement where the source for that class exists in the <tt>libraries</tt> directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
On the other hand class names which aren't fully qualified don't have to be unique, eg <tt>MVCFactory</tt>
* occurs as <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in <tt>libraries/src/Extension/Service/Provider/MVCFactory.php</tt>
* occurs as <tt>Joomla\CMS\MVC\Factory\MVCFactory</tt> in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>
so sometimes you have to be careful to examine the <tt>use</tt> statement to identify the right class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly our FormModel class in <tt>site/src/Model/FormModel.php</tt> can have the same FormModel classname as the Joomla FormModel in <tt>libraries/src/MVC/Model/FormModel.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The API documentation gives the methods available in each of the [https://api.joomla.org/cms-4/namespaces/joomla.html Joomla CMS] and [https://api.joomla.org/framework-2/namespaces/joomla.html Framework] classes, but just be aware that a Joomla CMS class may extend a Framework class, and in this case some methods may not be visible under the Joomla CMS documentation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For example, <tt>$app->setHeader()</tt> which is used to set the HTTP response code is not listed under the [https://api.joomla.org/cms-4/classes/Joomla-CMS-Application-CMSApplication.html CMS Application class API], but is available as a method because it inherits from the Framework class [https://api.joomla.org/framework-2/classes/Joomla-Application-AbstractWebApplication.html AbstractWebApplication].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Vendor Namespaces===
These are also in <tt>libraries/vendor</tt>, eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Psr\Container\ContainerInterface;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
refers to <tt>libraries/vendor/psr/Container/src/ContainerInterface.php</tt>. However there are few of these in the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other File Rearrangements===
With all of the namespaced classes moving under the src directories, the <tt>tmpl</tt> layout files and <tt>form</tt> xml files have been moved out into their own directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Extension and Dispatcher classes ==
===Extension===
In Joomla 3 the point where the Joomla core handed over to your component code was when it ran your <tt>helloworld.php</tt> code; if it was the frontend it ran your site <tt>helloworld.php</tt> code, or if was the backend it ran your admin <tt>helloworld.php</tt> code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the entry point into your component code is your Extension class, both for site and admin, found in <tt>admin/src/Extension/HelloworldComponent.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When the Joomla core application wants to start executing the component code it creates an instance of <tt>HelloworldComponent</tt>, just to get a handle on the component code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly (as described below) other Joomla classes such as Router or Categories need to call certain Helloworld methods (eg custom router functions). In Joomla 3 these methods were written in certain Helper files etc. In Joomla 4 the principle is that the component creates an instance of the <tt>HelloworldComponent</tt> Extension class, and calls the required methods on that instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This Extension class isn't anything like a big container class for the component, it's more like a glue class, providing a way in to the Helloworld component, enabling the Joomla core and other components call the methods which they want to call.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla core wants to execute the component code, the key method it is looking for in your <tt>Extension</tt> instance is <tt>getDispatcher</tt>, and it expects to get back a <tt>Dispatcher</tt> instance. The <tt>HelloworldComponent</tt> extends <tt>MVCComponent</tt>, which in turn extends <tt>Component</tt>, and it is this class which defines <tt>getDispatcher</tt> for us.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Dispatcher===
When Joomla wants to run the Hello World component, it gets the <tt>Dispatcher</tt> instance as described above and then calls the <tt>dispatch</tt> method on it. It is this <tt>dispatch</tt> function which replaces the functionality in the admin and site <tt>helloworld.php</tt> files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's look at the main lines of code in our Joomla 3 admin <tt>helloworld.php</tt> file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="site/views/form/view.html.php">
<syntaxhighlight lang="php">
if (!JFactory::getUser()->authorise('core.manage', 'com_helloworld'))
{
throw new Exception(JText::_('JERROR_ALERTNOAUTHOR'));
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Get an instance of the controller
$controller = JControllerLegacy::getInstance('HelloWorld');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Execute the Request task method
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Redirect if set by the controller
$controller->redirect();
</syntaxhighlight>
</span>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code
* performs some permissions checks
* instantiates the appropriate Helloworld controller
* executes the appropriate method in that controller
* implements any redirect set by the controller
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Model-View-Controller]] for further details of how this works in Joomla 3. The second and third steps used the <tt>task</tt> parameter within the URL query to determine the correct controller class to instantiate and method to call. If no <tt>task</tt> parameter was present then it instantiated the controller in <tt>controller.php</tt> and called the <tt>display</tt> method. Otherwise it instantiated one of the controllers in the <tt>controllers</tt> subfolder (eg <tt>controllers/helloworld.php</tt>) and called the appropriate method on it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>ComponentDispatcher::dispatch</tt> method (in <tt>libraries/src/Dispatcher/ComponentDispatcher.php</tt>) now provides this functionality, but in a nicer way. After checking the permissions it uses the <tt>task</tt> by considering its parts as <tt><controller type>.<method></tt> (taking 'display' as default if either part is missing). It will then pass control to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* an instance of the class <Controller type>Controller
* calling the function <method>
* using the admin or site controller, as appropriate
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In this way the naming of the controllers is consistent - we have DisplayController, HelloworldController and HelloworldsController, all in the same folder.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Dispatcher class can thus be considered as providing some 'routing - execution' functionality, enabling us to find the right controller and function within that controller, and it is cleaner to have this in a separate class rather than in the <tt>JControllerLegacy</tt> class as it was in Joomla 3.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Since the Hello World tutorial uses the standard Joomla pattern for selecting the class and method based on the <tt>task</tt> and has the same permissions checks, we can use the <tt>dispatch</tt> code as it stands in <tt>ComponentDispatcher</tt>, and don't need to define a special class of our own.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Factory classes ==
In Joomla 3 many classes had static <tt>getInstance</tt> methods which returned an instance of that class, configured with the parameters passed to <tt>getInstance</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the <tt>getInstance</tt> methods have been deprecated in favour of using Factory classes. The preferred mechanism is now to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* get an instance of the appropriate Factory class (how we do that is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below)
* call the <tt>createSomething()</tt> method of the Factory class with relevant parameter values to generate an instance of the Something class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===MVC Factory===
In this section the <tt>MVCFactory</tt> class refers to the one in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory class will instantiate Controller, View, Model and Table instances on our behalf, and it does this by generating the classname of the class and then calling <tt>new</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The way it works is as follows:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Each component gets an individual MVCFactory instance which is constructed passing the component's namespace as a parameter (so in our case 'Robbie\Component\Helloworld'). (How this MVCFactory instance is created is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below).
# The MVCFactory createController / createView / createModel / createTable function is then called, passing the name of the Controller / Model / View / Table and the prefix (which specifies whether the administrator or site class is required).
# The create function forms the classname from this data and calls <tt>new</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory create functions just form the classname from the parameters they're passed. The intelligence for working out what name and prefix should be used to form the appropriate classes for an incoming HTTP request is
* in the dispatcher code for defining the controller to use
* in the controller for the view and model
* in the model for the table
and, for example, the names of the classes created for a request with URL query <tt>?option=com_helloworld&view=viewname</tt> and no <tt>task</tt> parameter will be
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<namespace>\Controller\DisplayController
<namespace>\View\Viewname\HtmlView
<namespace>\Model\ViewnameModel
<namespace>\Table\ViewnameTable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you need an alternative name then you can override the appropriate getView, getModel or getTable function – as for example was done in the [[J3.x:Developing an MVC Component/Adding Custom Fields#Front-end_Form|Adding Custom Fields step, frontend Form section]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So from the outside this is pretty much the same as in Joomla 3. However, note that the <tt>$prefix</tt> parameter in calls to <tt>getModel</tt> etc is subtly different
* in Joomla 3 this referred to a prefix to be applied to the classname – in the tutorial code we used 'HelloWorldTable' as the prefix part of the 'HelloWorldTableHelloWorld' classname.
* in Joomla 4 this refers to a prefix higher up the classname path, and should be set to either 'Site' or 'Administrator' (the capital letter at the start is optional), depending on whether you want the class under 'Robbie\Component\Helloworld\Site' or 'Robbie\Component\Helloworld\Administrator'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVC Factory class is now the Joomla recommended way to create the controller, view, model and table classes, by using the eg <tt>getModel()</tt> method, and the use of <tt>getInstance()</tt> for these classes is now deprecated. However, the use of these functions is restricted:
* in the controller class you can call <tt>$this->getView($viewname, $viewtype, $prefix, $config)</tt> to create a view and <tt>$this->getModel($modelname, $prefix, $config)</tt> to create a model.
* in the view class you can call <tt>$this->getModel($modelname)</tt>, but only for models which the controller has previously defined using <tt>$view->setModel($modelname, $default)</tt>. It doesn't create a new model instance.
* in the model class you can call <tt>$this->getTable($tableclass, $prefix, $options)</tt> to create a table instance. Controllers and views can access the table classes in this way, by going via a model.
These restrictions do have an impact on moving away from using <tt>getInstance()</tt>, and indeed in Joomla 4.2.6 you will still find several <tt>getInstance()</tt> calls within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Factory Classes===
Several other Factory classes have been introduced in Joomla 4, enabling you to get instances of core classes such as Form, User, CacheController, etc, usually by calling a createSomething function on the Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Associated with the Factory class is a FactoryInterface, a PHP Interface which specifies the key functions which the Factory class must implement. For example, with <tt>libraries/src/Categories</tt> we have:
* CategoryFactoryInterface – which specifies the <tt>createCategory</tt> function
* CategoryFactory implements CategoryFactoryInterface – which provides the <tt>createCategory</tt> function.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Dependency Injection ==
===Overview===
The DI container is one of the significant new additions to Joomla 4. It's basically a repository of key-value pairs where:
* the key is a string which is the name of a class or interface
* the value is an instance of the relevant class, or a function that returns an instance of that class.
You put things into the container using <tt>set()</tt> passing:
* the class name or interface name
* a function which returns an instance of the class (or an instance of the class)
* a boolean defining whether the class instance may be shared or not
* a boolean defining whether this entry into the DI container is protected or not (an error will be raised if you try to overwrite a protected entry by calling <tt>set()</tt> again using the same key).
The function <tt>share()</tt> is basically the same as <tt>set()</tt> with the <tt>shared</tt> boolean set to true.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You get things out of the container by calling <tt>get()</tt> passing the key of the resource you want. The container will
* find the key in the container
* if the value isn't already a class instance, then it will run the associated function to generate an instance of the class
* if the resource is shared, it will store the class instance, so that on subsequent invocations of <tt>get()</tt> it can just return the instance
* return the class instance to you
You can also define aliases for each key in the container, which means that you call <tt>get()</tt> passing either the key or an alias of the key.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The DI container is initialised in <tt>library/src/Factory.php createContainer()</tt> which results in the <tt>register()</tt> function being called in each of the class files in <tt>libraries/src/Service/Provider</tt>. By looking through those files you can see what gets put into the DI container upon initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===JConfig Example===
Let's consider the example of JConfig which holds the system global configuration. If you look inside <tt>libraries/src/Service/Provider/Config.php</tt> then you'll see the <tt>register()</tt> function and that it stores in the DI container a resource with:
* key = 'JConfig'
* value = an anonymous function - which loads what's in <tt>configuration.php</tt> into a <tt>Registry</tt> object, and returns it
* shared flag = true (because the <tt>share()</tt> function is used)
* protected flag = true
Then when you do
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$config = $container->get('JConfig');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will run the anonymous function and return the Registry object to you. As the 'shared' boolean is set it will also store a copy of the class instance locally in the container to be returned on subsequent calls of <tt>get('JConfig')</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Justification===
What's the point of all this?
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The advantage of dependency injection is that it allows classes to be easily mocked for testing. The file <tt>libraries/src/Service/Provider/Config.php</tt> can be replaced to return to a DI container <tt>get()</tt> call a mock class instead of the usual <tt>JConfig</tt>. This is in comparison to Joomla 3 where <tt>Factory::getConfig()</tt> code directly reads the <tt>configuration.php</tt> into a Registry structure and returns it – which makes it harder to mock.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The [https://api.joomla.org/cms-4/classes/Joomla-CMS-Factory.html Factory API] has several functions which are marked as deprecated with advice to get the object from the DI container instead.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Several of the other Factory classes (eg Form, Language, Menu, User) are in the DI container – so that we can get an instance of them via eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Factory::getContainer()->get('Joomla\CMS\Toolbar\ToolbarFactoryInterface')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to get a Toolbar instance. However, this only works for singleton classes which aren't specific to the needs of a particular extension. We'll see shortly how to make it work for class instances which need to be specific to a component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As indicated above, Joomla is moving away from using the class static <tt>getInstance()</tt> functions. We can see now that this is not only because it's more pure from an object oriented perspective. But also creating class instances from the DI container, or from Factory objects which are obtained from the DI container, builds in the dependency injection which allows classes to be more easily mocked, and hence more easily tested.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==services/provider.php==
We're now finally in a good position to understand what's happening in our services/provider.php file, and we'll explore this by walking through what happens whenever this line in libraries/src/Component/ComponentHelper.php <tt>renderComponent</tt> is run:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is run whenever Joomla has worked out which component is to be run on the requested web page, and it wants to run that component to capture its output.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 1 Create Child DI Container===
Joomla first creates another DI container (initially empty) just for this component, and links it to the main DI container via a parent field in the child DI container structure.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Now whenever <tt>set()</tt> is called on this DI container the key-value pair is inserted into the child container. Whenever <tt>get()</tt> is called on it, the resource is obtained from the child container, but if it's not found there then the parent container is searched also.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 2 Run register() in provider.php===
Next we encounter these lines (in <tt>libraries/src/Extension/ExtensionManagerTrait.php</tt>), where <tt>$path</tt> contains the path of our helloworld admin/services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$provider = require_once $path;
// Check if the extension supports the service provider interface
if ($provider instanceof ServiceProviderInterface) {
$provider->register($container);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here we see 3 things:
# our provider.php should return some object (so that <tt>$provider</tt> gets set to something)
# what is returned should implement ServiceProviderInterface (you can see in <tt>libraries/vendor/joomla/di/src/ServiceProviderInterface.php</tt> what is expected)
# the code then runs the <tt>register</tt> function on that object, passing as a parameter the child DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider a minimal version of our provider.php file. This would actually support steps in the Joomla 3 tutorial up to and including the [[J3.x:Developing an MVC Component/Adding AJAX|Adding Ajax step]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {

public function register(Container $container): void
{
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
}
};
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As you can see from the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
this file does indeed return something – it returns an instance of an anonymous class, one that implements <tt>ServiceProviderInterface</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it's not sufficient to just provide the <tt>register</tt> function in the class, we also need to explicity state that the class implements <tt>ServiceProviderInterface</tt>. This now happens in several places in Joomla, so if you're debugging your component and wondering why a function you expect to be called isn't being called, then check to make sure that you don't have to explicitly add the appropriate <tt>implements <Interface></tt> clause to your class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Next we look at the 3 lines in the <tt>register</tt> function
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3a Registering our MVC Factory===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here our <tt>MVCFactory</tt> refers to <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in libraries/src/Extension/Service/Provider/MVCFactory.php, and you should have a look at this file. This is a file similar to our provider.php file, but it's a named class, and it doesn't return anything. When we do:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
new MVCFactory('\\Robbie\\Component\\Helloworld')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it creates an instance of this class, and in the constructor it stores locally in <tt>$this->namespace</tt> our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>registerServiceProvider</tt> function then calls the <tt>register</tt> function of this instance, which runs (in its minimalist form):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
MVCFactoryInterface::class,
function (Container $container) {
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
return $factory;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So what gets entered into our child DI container is a key-value pair with:
* key = MVCFactoryInterface::class (this is just a shorthand form to obtain a string of the fully qualified name – ie 'Joomla\CMS\MVC\Factory\MVCFactoryInterface')
* value = a function which returns an instance of <tt>\Joomla\CMS\MVC\Factory\MVCFactory</tt>.
This is our MVCFactory class which generates our Controllers, Views, Models and Tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Notice that we're passing our namespace as a parameter <tt>$this->namespace</tt>. Because this function is a closure, this variable will still be available when we run this function later, and when the MVCFactory class is instantiated the namespace will be passed into the constructor, stored locally, and then subsequently used to form the fully qualified names of our Controllers, View, etc. So this is how we get instantiated the MVCFactory class which is specific to our component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3b Registering the Dispatcher Factory===
Careful: ComponentDispatcherFactory refers to two different classes here!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This ComponentDispatcherFactory is Joomla\CMS\Extension\Service\Provider\ComponentDispatcherFactory in libraries/src/Extension/Service/Provider/ComponentDispatcherFactory.php. Similar to the above, the ComponentDispatcherFactory service provider class stores locally our namespace, and then when <tt>register</tt> is called it executes:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentDispatcherFactoryInterface::class,
function (Container $container) {
return new \Joomla\CMS\Dispatcher\ComponentDispatcherFactory($this->namespace,$container->get(MVCFactoryInterface::class));
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so a second entry is added to the child DI container with:
* key = ComponentDispatcherFactoryInterface::class
* value = a function which returns an instance of the ComponentDispatcherFactory (the other ComponentDispatcherFactory class!), where the class constructor will be passed the namespace ('\\Robbie\\Component\\Helloworld') and an MVCFactory instance, retrieved from the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that the code
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->get(MVCFactoryInterface::class)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
will get from the container an entry with key = 'Joomla\CMS\MVC\Factory\MVCFactoryInterface' – which is what we entered into the container in step 3a – and will run the function associated with this key, and then return the object which this function returns. This returned object will be an instance of '\Joomla\CMS\MVC\Factory\MVCFactory', constructed using our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3c Including the Extension===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will put into the child DI container a key-value pair with
* key = ComponentInterface::class
* value = the function which will create an instance of our <tt>HelloworldComponent</tt> (ie our Extension class), and pass into the constructor an instance of the ComponentDispatcherFactory class, retrieving what was entered into the child DI container in Step 3b.
It will call <tt>$container->get(MVCFactoryInterface::class)</tt>, getting an MVC Factory instance from what was entered into the DI container in Step 3a.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It will then associate our component with this MVC Factory instance via the <tt>setMVCFactory</tt> call. Significantly this will then allow our component to access this instance later, via a call to <tt>getMVCFactory</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3 Summary===
We have now got 3 entries in our child DI container, keyed by
* key = MVCFactoryInterface::class, value is a function returning an MVCFactory instance
* key = ComponentDispatcherFactoryInterface::class, value is a function returning a ComponentDispatcherFactory instance
* key = ComponentInterface::class, value is a function returning our HelloworldComponent, an instance of our Extension class.
The important aspect is that these entries are all aware of our namespace '\Robbie\Component\Helloworld' and will return instances of these classes which are specific to our Helloworld component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 4 Retrieving from the DI Container===
Joomla will then execute the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $container->get($type);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
where <tt>$type</tt> contains 'Joomla\CMS\Extension\ComponentInterface'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This starts the process of retrieving from the DI container the 3 entries which we put in, and will run our code in services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We end up with a HelloworldComponent instance, which has:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. a ComponentDispatcherFactory instance passed into the constructor, and which is saved locally by the constructor code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function __construct(ComponentDispatcherFactoryInterface $dispatcherFactory)
{
$this->dispatcherFactory = $dispatcherFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This code is in libraries/src/Extension/Component.php, in the class which our HelloworldComponent extends, via the class MVCComponent).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. an MVC Factory instance, stored by the HelloworldComponent <tt>setMVCFactory</tt> call
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 5 Call boot() on our Component===
Joomla calls:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
if ($extension instanceof BootableExtensionInterface) {
$extension->boot($container);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will call <tt>boot</tt> within our HelloworldComponent, and allows us to perform some initialisation within our component. We'll return to this later, in the section on [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#HTML_Snippets|HTML snippets]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note again that Joomla checks that our HelloworldComponent class implements BootableExtensionInterface before calling <tt>boot</tt>. It's not sufficient to just provide the <tt>boot</tt> function, we have to explicitly declare that our HelloworldComponent implements the interface.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 6 Get the Dispatcher===
Returning to our key line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
we have now accomplished the first part <tt>bootComponent($option)</tt>, and this has returned our HelloworldComponent instance. Now we call <tt>getDispatcher($app)</tt> on this instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This code is also in libraries/src/Extension/Component.php, in the Component class which our HelloworldComponent extends:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function getDispatcher(CMSApplicationInterface $application): DispatcherInterface
{
return $this->dispatcherFactory->createDispatcher($application);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We call <tt>createDispatcher</tt> on our ComponentDispatcherFactory class instance which we saved in Step 4. This code is in libraries/src/Dispatcher/ComponentDispatcherFactory.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createDispatcher(CMSApplicationInterface $application, Input $input = null): DispatcherInterface
{
$name = ucfirst($application->getName());

$className = '\\' . trim($this->namespace, '\\') . '\\' . $name . '\\Dispatcher\\Dispatcher';

if (!class_exists($className)) {
if ($application->isClient('api')) {
$className = ApiDispatcher::class;
} else {
$className = ComponentDispatcher::class;
}
}

return new $className($application, $input ?: $application->input, $this->mvcFactory);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code checks if we have our own Dispatcher class (our Helloworld tutorial doesn't, but <tt>com_users</tt> for example has its own). So it creates a <tt>ComponentDispatcher</tt> instance, and passes into its constructor the MVC Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that this ComponentDispatcherFactory instance is what was instantiated when it was retrieved from our child DI Container (from being inserted in step 3b), and hence it already knows about our namespace, and has a pointer to our MVCFactory class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 7 call dispatch()===
This is the final aspect to our line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We're now back to what was described in the Dispatcher section above, except that now we can see that this Dispatcher instance has a pointer to our MVC Factory instance (which knows about our namespace prefix), so when the Dispatcher code wants to create a Controller it can use that MVC Factory instance to instantiate it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's been a long and tortuous journey to get here, but the significant thing is that all of our key class instances have been obtained via the DI Container. If we want to mock out any of those classes for testing then all we need to do is replace the relevant services/provider file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Javascript and the Web Asset Manager ==
The web asset manager has been introduced in Joomla 4 and is well documented [[J4.x:Web_Assets|here]]. It provides a much-improved means of managing JS and CSS resources, and a framework for handling their dependencies.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Component Javascript and CSS files should now be stored in the <tt>media</tt> folder, and the Web Asset Manager used to register them and output them on specific web pages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following assets have been registered in the tutorial <tt>joomla.asset.json</tt>, and you should have a look at that file now.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.validate-greeting===
This is the code for client validation of the helloworld greeting field using a regex, and it is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it is dependent upon jQuery and the Joomla <tt>form.validator</tt> script, so those both get included as dependencies.
If we didn't have specific validation on our form then we would need to include explicitly the <tt>form.validator</tt> script in order for the basic Joomla field validation to be included, eg in the tmpl file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->document->getWebAssetManager()->useScript('form.validate');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that this requires us to have a <tt>class="form-validate"</tt> on the </tt><form></tt> html element.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.fix-permissions-ajax-call===
This is the code which copies the value from the greeting field into the title field, so that the Ajax calls setting the permissions work correctly. The js code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.enable-tooltips===
This is the code which enables bootstrap tooltips to operate, including allowing them to include html code. It's used to display the image as a tooltip within the admin <tt>helloworlds</tt> view.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.openstreetmap===
This is defined as a preset, comprising the helloworld js and css code for the map display, as well as the dependency named 'com_helloworld.openlayers' relating to the openlayers CSS and js code. The code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.admin-helloworlds-modal===
This is the js code for selecting an individual helloworld record within a modal, and passing its details to the form in the main window. Its code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===submitbutton.js===
In the Joomla 3 code we introduced in [[Special:MyLanguage/J3.2:Developing_an_MVC_Component/Adding_verifications|Adding Verifications]] a js file which controlled when the form was submitted. It differentiated between buttons such as <tt>Save</tt> (which submitted the form) and <tt>Cancel</tt> (which didn't).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 there is a more sophisticated version of <tt>Joomla.submitbutton</tt> (found in media/system/js/core.js) which uses the CSS classes which the Toolbar functionality sets on the buttons to determine whether the form should be submitted or not. And you can override whether the validation is performed by adding a third parameter to the <tt>submitbutton</tt> js call. For example, to avoid validation being performed when a button is clicked you can set on the button element:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
onclick="Joomla.submitbutton('controller.method', '', false)"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As this is sufficient for what we need in the tutorial, the custom <tt>submitbutton.js</tt> has been removed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Interaction with other components ==
The way that Joomla interacts with components has changed in Joomla 4. In general the Joomla functionality will boot the component using something like:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $app->bootComponent($option);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and in our case this will return an instance of the <tt>HelloworldComponent</tt> class. It will then try to call certain methods on our extension object, as described below.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_categories===
In the backend the helloworld functionality can display to the administrator
* the view of the helloworld messages
* the view of the helloworld categories
The categories view is generated by <tt>com_categories</tt>, and in Joomla 4 these component categories views display the number of component records there are for each of the possible published status values. To do this the categories component executes the following code (in administrator/components/com_categories/src/Model/CategoriesModel.php):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof CategoryServiceInterface) {
$component->countItems($items, $section);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So our HelloworldComponent must:
* declare that it implements <tt>CategoryServiceInterface</tt>
* provide an implementation of <tt>countItems</tt>
We provide <tt>countItems</tt> by using a trait in libraries/src/Categories/CategoryServiceTrait.php, which (with the assistance of a helper function) does the query on our behalf. We just need to tell it:
* the name of our table – in the callback <tt>getTableNameForSection</tt>
* the database field in which we hold the published status – in <tt>getStateColumnForSection</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_associations===
Remember that <tt>com_associations</tt> is the component which is run whenever you click on Multilingual Associations in the admin backend.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Under Joomla 3 we provided an associations helper file as described in [[J3.x:Multilingual Associations/Developers|Multilingual Associations/Developers]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the helper file remains basically the same, but <tt>com_associations</tt> primarily tries to find the helper file via the extension class; here's the code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($extensionName);
if ($component instanceof AssociationServiceInterface) {
return $component->getAssociationsExtension();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's expecting that:
* the extension (HelloworldComponent in our case) implements <tt>AssociationServiceInterface</tt>
* its <tt>getAssociationsExtension</tt> method returns the helper class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The easiest thing would be just to code <tt>getAssociationsMethod</tt> and get it to return <tt>new AssociationsHelper</tt>. However, we follow the Joomla 4 principle of putting key classes into the Dependency Injection container, and retrieving them later, by having the following code in our services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(AssociationExtensionInterface::class, new AssociationsHelper());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The above line puts a key-value pair into our child DI container
* key = 'Joomla\CMS\Association\AssociationExtensionInterface'
* value is an instance of our <tt>AssociationsHelper</tt> class.
We then retrieve it later and use the setter:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setAssociationExtension($container->get(AssociationExtensionInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so that whenever
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getAssociationExtension()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
is called it returns the <tt>AssociationsHelper</tt> class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_fields===
<tt>com_fields</tt> is the component which is run when an administrator clicks on the Fields or Field Groups menuitem within the backend, and this functionality was included in the [[J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Adding Custom Fields]] tutorial step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>com_fields</tt> component stores the custom fields and field groups for all components in the database tables <tt>#__fields</tt> and <tt>#__fields_groups</tt>, and these tables are partitioned into "sections", one section per component. For our helloworld component the section is named "helloworld".
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within the section we have 2 "contexts" – one for the helloworld messages (called "com_helloworld.helloworld") and one for the helloworld categories (called "com_helloworld.categories"). This enables us to define custom fields for both our helloworld records and helloworld category records.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When <tt>com_fields</tt> runs it checks both the section and contexts at various times. For example, when an admin selects Helloworld / Fields on the backend then <tt>com_fields</tt> checks the section which was defined in the menuitem in the manifest file (see [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Sidebar|below]]). Here's the code in administrator/components/com_fields/src/Helpers/FieldsHelper <tt>extract</tt> function:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
$newSection = $component->validateSection($parts[1], $item);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And when <tt>com_fields</tt> wants to display the little dropdown menu of contexts (to allow the administrator to set custom fields on either helloworld items or categories) it calls (in administrator/components/com_fields/src/Fields/FieldcontextsField.php <tt>getOptions()</tt>):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
return $component->getContexts();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So it's clear that our component extension class must :
* implement <tt>FieldsServiceInterface</tt>
* provide the <tt>validateSection</tt> and <tt>getContexts</tt> methods
So in upgrading to Joomla 4 we've just moved those two methods from the helper file to the extension class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Router===
The Joomla router will access our custom router code:
* whenever it wants to parse an SEF route which it has identified as belonging to <tt>com_helloworld</tt>
* whenever it wants to build an SEF route from a call to <tt>Route::_()</tt> where the option = "com_helloworld".
To find our custom router it will:
* boot the <tt>com_helloworld</tt> extension
* check that the extension implements <tt>RouterServiceInterface</tt>
* call <tt>createRouter</tt> on our extension instance
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In our services/provider.php file we have (careful again - 2 different RouterFactory classes!):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new RouterFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which from libraries/src/Extension/Service/Provider/RouterFactory.php puts into our child DI container an entry with:
* key = "Joomla\CMS\Component\Router\RouterFactoryInterface"
* value is a <tt>\Joomla\CMS\Component\Router\RouterFactory</tt> instance, constructed with our namespace
We then retrieve this in the line in our services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setRouterFactory($container->get(RouterFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And then within our extension class we have
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use RouterServiceTrait;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which includes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function setRouterFactory(RouterFactoryInterface $routerFactory)
{
$this->routerFactory = $routerFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which stores the <tt>routerFactory</tt> locally and
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return $this->routerFactory->createRouter($application, $menu);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which provides our extension's <tt>createRouter</tt> call that the Joomla Router expects.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>routerFactory::createRouter</tt> method is in libraries/src/Component/Router/RouterFactory.php. It looks for a class in our site namespace </tt>Robbie\Component\Helloworld\Site\Service\Router</tt> which is in our site/src/Service/Router.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
At this stage we have a choice, we can either:
* provide a traditional custom router, with the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions, or
* use the more modern <tt>RouterView</tt> mechanism.
By default in the upgraded tutorial code the Router View option has been coded in the Router.php file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====RouterView====
In the <tt>RouterView</tt> case the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions are in the <tt>RouterView</tt> class which we extend, and we provide
* a constructor with router view configuration
* methods <tt>getHelloworldId</tt> and <tt>getCategoryId</tt> which are used to obtain from the SEF segment the <tt>id=</tt> and <tt>catid=</tt> parts of the internal URL
* methods <tt>getHelloworldSegment</tt> and <tt>getCategorySegment</tt> which are used to generate segments for the SEF URLs based on the <tt>id=</tt> and <tt>catid=</tt> parts within the <tt>Route::_()</tt> parameter.
Unfortunately there doesn't seem to be a good guide to configuring the RouterView class. There is some documentation available [https://www.dionysopoulos.me/book/com-router-routerview.html here].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the helloworld tutorial we have 3 views
* a view which displays a single helloworld record
* a view which displays a single helloworld category, and the helloworld records associated with it
* a view which displays the frontend form
So we need 3 Router Views associated with these.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'form' view doesn't have an associated id or catid so it's just a fixed URL, and the router just has to convert between the alias of the form menuitem and the Itemid / view parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'category' view has an associated id (of the category record), and an SEF URL will use the category path down the Categories Nested Set table structure, hence <tt>setNestable()</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'helloworld' view has an associated id (of the helloworld record), and in an SEF URL in the category view the helloworld record alias is added to the category path (hence <tt>setParent()</tt>). But although the helloworld records use a Nested Table structure in the database, the URLs just include the alias of the single record, and so <tt>setNestable()</tt> is not used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There doesn't seem to be a way to configure an additional SEF URL scheme which just displays a helloworld segment, without a category segment.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====Traditional Router====
To use the traditional router in the tutorial code you should uncomment the function in the extension class:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return new TraditionalRouter($application, $menu, $this->categoryFactory, $this->getDatabase());
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will cause the code in site/src/Service/TraditionalRouter.php to be used. However, changes in the Joomla 4 router mean that the interaction between it and the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> methods have changed. This requires significant changes to the <tt>preprocess</tt> and <tt>build</tt> methods, but only a minor change to <tt>parse</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. Previously Joomla injected into the <tt>$query</tt> parameters the <tt>Itemid</tt> of the active menuitem (ie the id of the menuitem the user is currently on). This meant that we had to change the <tt>Itemid</tt> for links generated by the Language Switcher module (which generates the flags for switching between languages), and these links being associated with a different language would obviously use a different <tt>Itemid</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 you get an <tt>Itemid</tt> in the <tt>$query</tt> parameters only if you specified an <tt>Itemid</tt> in the <tt>Route::_()</tt> call. For others you have to work out which menuitem to use yourself, by using the Joomla menu/menuitems API to find details of the configured menuitems, and work out which to use based on the other <tt>$query</tt> parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You do this in the <tt>preprocess</tt> method, and then the <tt>Itemid</tt> you set will be passed in the <tt>$query</tt> parameters to the <tt>build</tt> method.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. In some instances the <tt>Route::_()</tt> URL you're generating matches exactly one of the configured menuitems on the site. In this case the <tt>$query</tt> parameters will match those in the menuitem <tt>"query"</tt> array, and you have to remove explicitly remove the 'view', 'id' and 'catid' parameters so that they don't appear as URL query parameters after the normal SEF URL of the menuitem.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
3. The custom router will be used to build the URLs for the helloworld menuitems shown in menus on the page. For these the <tt>$query</tt> parameters will have the view / id / catid associated with those menuitems. Note that even if you remove these in your <tt>preprocess</tt> method, Joomla will inject them again into the <tt>$query</tt> array when it's passed to your <tt>build</tt> method, so you'll have to remove them again there!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
4. In the <tt>parse</tt> method you now have to unset the <tt>$segments</tt>, or else Joomla will return an HTTP 404 (page not found). Otherwise <tt>parse</tt> works as before.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
5. I've implemented <tt>build</tt> only for when Multilanguage is enabled on the site. If it's not enabled an empty <tt>$segments</tt> array is just returned, without doing unset on any of the <tt>$query</tt> parameters, so these will appear as URL parameters after the SEF URL. Also it's not coded properly to deal with items which have language set to <tt>*</tt>. These include helloworld records, categories or menuitems (eg the helloworld form).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that the <tt>categoryFactory</tt> is also now passed to the router. This is so that it can be used instead of <tt>Categories::getInstance()</tt> to get access to the Categories API calls.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_tags===
Whenever we setup a Tags Menu Item Type which displays items having a given tag or tags, then <tt>com_tags</tt> displays those items as links, and uses route helper functions to generate the URL parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The route helpers <tt>com_tags</tt> expects to find loaded into the data of the <tt>#__content_types</tt> table, in the router field, and these have been set to:
* For links to helloworld items: 'HelloworldHelperRoute::getHelloworldRoute'
* For links to helloworld categories: 'HelloworldHelperRoute::getCategoryRoute'
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, <tt>com_tags</tt> doesn't boot the helloworld extension to get access to these, but rather seeks to find them in site/helpers/route.php, so that's where they continue to be.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(We also had a <tt>getCategoryRoute</tt> which was used by <tt>com_categories</tt> in administrator/components/com_categories/src/Helper/CategoryAssociationHelper. When a category was displayed on the frontend then the Language Switcher module (now Language Filter) used this function to generate the links to the Associated Categories. Our <tt>getCategoryRoute</tt> previously was necessary to insert the <tt>lang=<language tag></tt> parameter into the link URL, but since [https://github.com/joomla/joomla-cms/pull/39358 this change] the calling function inserts the <tt>lang</tt> parameter itself, so our <tt>getCategoryRoute</tt> function for this purposes is superfluous.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Deprecated APIs ==
With Joomla 4 there are a number of methods which are deprecated, with a view to removing them in Joomla 5.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Factory Methods===
Many of the <tt>Factory</tt> methods for getting singleton classes have been deprecated in favour of getting these classes via the DI container, and it appears that only class instances which should be obtained via Factory methods are:
* the Application – <tt>Factory::getApplication()</tt>
* the DI container – <tt>Factory::getContainer()</tt>
Here is a list of what has been changed in the tutorial code. Note that with some calls there are variants available, through the aliases defined in the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDbo'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\Database\DatabaseInterface;
...
$db = Factory::getContainer()->get(DatabaseInterface::class);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, in many classes the database instance is more easily (and efficiently) returned via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$db = $this->getDatabase();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is available in Model classes, custom field definitions, etc.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getUser();'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get the current user use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = Factory::getApplication()->getIdentity()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get a different user (whose id you know):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\User\UserFactoryInterface;
...
$user = Factory::getContainer()->get(UserFactoryInterface::class)->loadUserById($userid);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within models which extend Joomla\CMS\MVC\Model\BaseDatabaseModel and views which extend Joomla\CMS\MVC\View\HtmlView you can also use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = $this->getCurrentUser()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDocument()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication()->getDocument()</tt>, or within a View you can use <tt>$this->document</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getConfig()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Two options have been used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->getConfig()</tt> – returns a Registry object containing all the configuration values
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->get('access')</tt> – returns the value of the 'access' configuration parameter
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getLanguage()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication->getLanguage()</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JFactory::getCache('com_example', <type>)'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Cache\CacheControllerFactoryInterface;
...
Factory::getContainer()->get(CacheControllerFactoryInterface::class)->createCacheController(<type>)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated getInstance Methods===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general <tt>getInstance()</tt> calls have been deprecated in favour of obtaining the instance, either via a factory class or via the DI container. For example, within a controller you can use <tt>getModel()</tt> repeatedly to get different models (passing the relevant model names), which results in the MVCFactory class creating the Model classes.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there are currently some problems with replacing some getInstance calls. I expect that the Joomla team will resolve these issues over the course of the Joomla 4 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Categories::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is deprecated with a notice: "Use the ComponentInterface to get the categories". This means that we should get the category factory instance via the DI container. This is done in our services/provider.php by the lines:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Extension\Service\Provider\CategoryFactory;
...
$container->registerServiceProvider(new CategoryFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to put into our child DI container the closure which will create a Joomla\CMS\Categories\CategoryFactory instance, constructed with our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when our HelloworldComponent (Extension) instance is created:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We can then use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getCategoryFactory()->createCategory();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to create our Categories object, and in this way get access to the Categories APIs.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This createCategory method creates the instance by looking for the \\Site\\Service\\Category class within our namespace. The constructor in our class sets our extension ('com_helloworld') and table ('#__helloworld') and calls the parent Categories constructor with these options).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this means that the section of our code where we want to use the Categories APIs must have a pointer to a CategoryFactory instance. In the tutorial code for Joomla 3 there are 2 places where <tt>Categories::getInstance</tt> is used:
* in the custom router code, to handle building and parsing of the category parts of the SEF URL
* in the site category model, where the Categories APIs are used to obtain details of categories to display on the page.
For the custom router code, the CategoryFactory instance is passed as a parameter to the TraditionalRouter constructor so that it can be used there.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, the site category model is instantiated by the MVCFactory instance, and it doesn't make available a CategoryFactory instance. So in this category model the calls to <tt>Categories::getInstance()</tt> have been left, and you can still find a number of calls to <tt>Categories::getInstance</tt> within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Categories::getInstance()</tt> itself solves the problem of access to a CategoryFactory instance by rebooting our component again to get a pointer to our Extension instance, and thus to the category factory instance. However, this involves a lot of work, so <tt>getInstance</tt> caches locally the Categories instances and just returns one of them if it can.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Pushing the CategoryFactory to the model'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there is a way to get access to the CategoryFactory instance, by defining your own MVCFactory class, and pushing the instance down through it to the model. Here's how you can go about it:
* Define your own SuperMVCFactory class, which extends the Joomla Joomla\CMS\MVC\Factory\MVCFactory class, but which has a means of storing a CategoryFactory instance. Use the CategoryServiceTrait in libraries/src/Categories/CategoryServiceTrait.php
* Create your own version of the file libraries/src/Extension/Service/Provider/MVCFactory.php, which is the 'provider.php' like file for MVCFactory, but change it so that:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
becomes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new <namespace>\SuperMVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and include
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla creates a model such as CategoryModel it passes in its constructor the MVCFactory instance (so that the model can call createTable on it), so you can access it via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will return your SuperMVCFactory instance. So in this way within the model you can access the CategoryFactory, and use it to create the Categories instance via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()->getCategory() (from the CategoryServiceTrait)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you can get this working you can congratulate yourself on a good understanding of Joomla namespacing and dependency injection! A similar approach to address a similar problem is described [https://www.dionysopoulos.me/book/com-router-push-dependencies.html here]. If you get stuck you can always view the solution by viewing the github tutorial code selecting the branch [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial/tree/push-category-factory-to-mvc push-category-factory-to-mvc].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Table::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There are a couple of calls to <tt>Table::getInstance()</tt> within admin/src/Helper/AssociationsHelper.php in <tt>getItem()</tt>:
* <tt>Table::getInstance('Helloworld', 'Robbie\\Component\\Helloworld\\Administrator\\Table\\')</tt> to get an instance of our HelloworldTable class.
* <tt>Table::getInstance('Category')</tt> to get an instance of the Category table in libraries/src/Table/Category.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We could actually arrange for the AssociationsHelper class to get injected with the MVCFactory instance, so that the HelloworldTable class could be instantiated by it. However, we couldn't use the helloworld MVCFactory instance to create the Category table instance, as it's not in the helloworld namespace, and our MVCFactory instance creates table instances within our namespace only.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Toolbar::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The tutorial code uses <tt>Toolbar::getInstance()</tt> to get a Toolbar instance onto which it can attach the batch button in the helloworlds form. The Toolbar API documentation seems to suggest that we should replace
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Toolbar::getInstance('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
with
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this currently won't work. The problem is that all the other Joomla code uses <tt>getInstance('toolbar')</tt> to access the Toolbar class, including the code in administrator/modules/mod_toolbar/mod_toolbar.php which renders the toolbar. The <tt>getInstance</tt> method keeps track of the Toolbar instances in a local static variable <tt>$instances</tt>, and returns the same Toolbar instance on repeated invocations.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you use the second approach above you will get a Toolbar instance, but it won't be the same Toolbar instance as is stored in the <tt>$instances</tt> variable. It won't then be picked up by the Toolbar module, and so won't be rendered on the form.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Error Handling===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead of
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
JError::raiseError(500, implode('<br />', $errors));
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
you should throw an exception, using or extending one of the standard [https://www.php.net/manual/en/spl.exceptions.php PHP exceptions], eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
throw new \Exception(implode("\n", $errors), 500);
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===jimport===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
jimport is no longer necessary in order to get access to Path or File classes. All of the Joomla classes are found by the autoloader.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Methods related to Javascript===
'''JHtml::_('behavior.framework');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general, the use of JHtml::_('behavior.xxx') is now obsolete, and calls using this have been removed in the tutorial code. The 'behavior.framework' call referred to including jQuery. Where jQuery is necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.formvalidator');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by the <tt>form.validate</tt> javascript asset, and where necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It can also be included directly using the web asset manager:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$wa->useScript('form.validate')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.tooltip')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This no longer exists, and tooltips don't seem to be enabled by default in Joomla 4. This is replaced by the code in media/js/enable-tooltips.js.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('formbehavior.chosen')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The chosen js library seems to be no longer used, and using it will cause formatting issues if you include it in your tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''sortable'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The sortable js library provided the ability in the helloworlds view to drag rows up and down to change the ordering of the records. This has been replaced in Joomla 4 by the draggable library. To enable it you have to set:
* <tt>HTMLHelper::_('draggablelist.draggable');</tt>
* on your <tt><tbody></tt> element define the table in which dragging occurs and the URL of the Ajax call to set the ordering:
<source lang="php">
<tbody<?php if ($saveOrder) : ?> class="js-draggable" data-url="<?php echo $saveOrderingUrl; ?>" data-direction="<?php echo strtolower($listDirn); ?>" data-nested="true"
<?php endif; ?>>
</source>
* on your <tt>tr</tt> element within your <tt><tbody></tt> define the group of records in which dragging occurs (by category below):
<source lang="php">
<tr class="row<?php echo $i % 2; ?>" data-draggable-group="<?php echo $row->catid; ?>">
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==HTML Snippets==
There are two places in the tutorial where reusable snippets of HTML have beeen defined:
* For displaying the item associations in the helloworlds view:
* For displaying the position latitude and longitude fields within the batch options in the helloworlds view
These used different approaches:
* the item associations display was coded in an html helper file in admin/helpers/html/helloworlds.php and accessed via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JHtml::_('helloworlds.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
in the helloworlds tmpl file. (Although it did use a common joomla layout file underneath).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* the position field was coded as a layout in layouts/position.php, and rendered using
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JLayoutHelper::render('position', array());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When should you use one approach rather than the other? A significant difference is that layouts are designed so that an administrator can override them, via the Templates / Details and File functionality. So, for example, an administrator could change the position to show the longitude before the latitude. So it's more appropriate for layouts to focus on the html elements rather than functional logic, and particularly if you would want to allow an administrator to override the layout.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The layouts functionality in Joomla 4 hasn't changed significantly. One correction which has been made in the updated tutorial code has been to include the position.php file in a subfolder of layouts, ie in admin/layouts/helloworld/position.php rather than admin/layouts/position.php. It appears that in the Templates / Details and Files / Create Overrides tab the <tt>com_helloworld</tt> layout appears only if it's in a subfolder of /layouts.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>JHtml::_()</tt> approach has changed in Joomla 4. Rather than Joomla having to look for a helper file when it encounters something it doesn't recognise, it's expected that you should register such classes beforehand, and you do this by obtaining an instance of the Joomla\CMS\HTML\Registry class (it's a singleton class) and then calling <tt>register</tt> on it, passing
* the key you want to use
* an instance of your class
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Joomla pattern is to put the code in a file admin/src/Service/HTML/AdministratorService.php, and we have to ensure that our key won't be used elsewhere within Joomla, so in the tutorial we've used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Robbie\Component\Helloworld\Administrator\Service\HTML\AdministratorService;
...
register('helloworldadministrator', new AdministratorService)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when we call:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo HTMLHelper::_('helloworldadministrator.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will result in Joomla calling the <tt>association</tt> method in our class, passing the <tt>$row->id</tt> parameter.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We should get the Joomla\CMS\HTML\Registry class from the Dependency Injection container. Joomla components generally do this via their services/provider.php file, and then call <tt>register</tt> within the extension's <tt>boot</tt> function, described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Step_5_Call_boot.28.29_on_our_Component|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The extension uses HTMLRegistryAwareTrait which contains <tt>setRegistry</tt> and <tt>getRegistry methods</tt>. In services/provider.php there is:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\HTML\Registry;
...
$component->setRegistry($container->get(Registry::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets 'Joomla\CMS\HTML\Registry' out of the DI container and stores it within the
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
private $registry;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
variable of the HTMLRegistryAwareTrait included in the extension.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the <tt>boot</tt> function it calls
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getRegistry()->register('helloworldadministrator', new AdministratorService);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets the registry and calls <tt>register</tt> as required.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that <tt>boot</tt> is called whenever Joomla dispatches <tt>com_helloworld</tt>, both for the site and administrator, so it would make sense to check the Application <tt>isClient</tt> before deciding whether to register the HTML Helper service or not. This hasn't been included in the tutorial code though.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==User Interface Changes==
Joomla 4 introduced new templates, atum on administrator and cassiopeia on site, and in particular the administrator is built upon some UI rearrangements which affect the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Sidebar===
In Joomla 3 each component incorporated a sidebar which we coded in the <tt>addSubmenu</tt> function in admin/helpers/helloworld.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the administrator menu is in a vertical panel on the left hand side, and the Hello World submenu is built from entries in the helloworld.xml manifest file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<administration>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<submenu>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<menu link="option=com_categories&extension=com_helloworld">COM_HELLOWORLD_CATEGORIES</menu>
<menu link="option=com_fields&view=fields&context=com_helloworld.helloworld">MOD_MENU_FIELDS</menu>
<menu link="option=com_fields&view=groups&context=com_helloworld.helloworld">MOD_MENU_FIELDS_GROUP</menu>
</submenu>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===CSS Classes===
In several places the CSS classes defined in the html elements have been changed in Joomla 4. For example, for general layout the classes now align with the [https://getbootstrap.com/docs/3.4/css/ Bootstrap CSS Classes], and classes such as <tt>row-fluid</tt> and <tt>span3</tt> which were prominent in Joomla 3 have disappeared. If you're upgrading a Joomla 3 component then it's probably best (on the back-end at least) to find a similar Joomla component and use the overall html structure and css classes within its tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the tutorial code those classes which are specifically used by Bootstrap have been changed from eg 'data-target' to 'data-bs-target', and it has been necessary to change these to enable the functionality to work.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, not all of CSS class changes affecting solely the presentation have been reflected in the updated tutorial code. For example, in the <tt>helloworlds</tt> view, showing the list of helloworld messages, the display of the associations is different from that of other Joomla components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Fonts===
In Joomla 3 [[J3.x:Joomla_Standard_Icomoon_Fonts|Icomoon Fonts]] were used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 Font Awesome's free icons are used, and you can see what is available on their [https://fontawesome.com/v5/cheatsheet cheatsheet]. The icons are implemented using CSS pseudo-elements, as described [https://fontawesome.com/v5/docs/web/advanced/css-pseudo-elements here]. Basically they convert a CSS class into html content, namely a unicode value in the private use range. A couple of these have been implemented in the frontend form, in the Save and Cancel buttons, for example:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>span class="icon-cancel">/span <?php echo Text::_('JCANCEL') ?></tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(with angle brackets removed from the <tt>span</tt> tags to stop the icon just being displayed by the browser).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This class is defined in media/system/css/joomla-fontawesome.css (where you can find the list of icon classes supported):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
.icon-cancel:before {
content: "\f00d";
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so this includes in front of the text the unicode character <tt>f00d</tt>, which you can see on the cheatsheet as "times", and displayed as <span class="icon-cancel"></span>. You can also use <tt>fa-</tt> plus the icon name on the font awesome cheatsheet page. If you use Icomoon icon names in your code which you run under Joomla 4, then the icon displayed will be a Font Awesome icon (if there's one with the same name) or it will use a mapping which the Joomla team have defined to display a Font Awesome icon which resembles the Icomoon one.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Buttons and Links===
An accessibility principle is that <tt><a></tt> html elements should be used for links to other web pages, and <tt><button></tt> elements should be used for actions, eg on a form. To align with this, the <tt><a></tt> elements in the helloworld modal field (defined in admin/src/Field/Modal/Helloworld.php) have been changed to <tt><button></tt> elements. These are the Select and Clear buttons displayed when choosing a Helloworld record for a menuitem pointing to a Helloworld message. (The buttons also include fontawesome icons, by the way).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This change was actually made in Joomla in one of the Joomla 3 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Categories View===
In the Categories view of standard Joomla components there now appears columns which show for each category the number of items, split by published status. This is populated by <tt>com_categories</tt> calling each extension's <tt>countItems</tt> function, as described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_categories|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Miscellaneous Changes==
===Version History===
In Joomla 3 the tutorial code used the <tt>JTableObserver</tt> functionality to copy relevant changes from the Helloworld and Categories tables into the UCM tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it uses a plugin mechanism to subscribe to Table events 'onTableAfterStore' and 'onTableBeforeDelete'. The plugin can be found in plugins/behaviour/versionable, and it is activated by Joomla as part of its application initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The copying of fields from the table works roughly the same way as before, except that the name of the table where the versions are stored is now <tt>#__history</tt>, so the entries which have to be inserted into the <tt>#__content_types</tt> table are fairly similar. Because the folders in which forms are stored has changed in Joomla 4, the 'formFile' parameter is different (remember that this is where Joomla gets the field labels in order to display the Preview within the Versions modal window, otherwise just the names of the database columns will be output).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here's a summary of what needs to be done to enable versioning under Joomla 4. The Versioning Traits and Interface definitions are found in libraries/src/Versioning:
* Enter data into content_types database table
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Storing the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The Table class must implement VersionableTableInterface and provide <tt>getTypeAlias()</tt>, which returns 'com_helloworld.helloworld'. This type alias + the helloworld record id is used as the key to identify versions in the <tt>#__history</tt> table.
* Define <tt>save_history</tt> and <tt>history_limit</tt> options in config.php, and ensure these are both set.
* Add a <tt>version_note</tt> field into the output of the edit view's tmpl file (admin/tmpl/helloworld/edit.php).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Viewing and Restoring the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit Controller (admin/src/Controller/HelloworldController.php) should <tt>use VersionableControllerTrait</tt>.
* The edit Model (admin/src/Model/HelloworldModel.php) should <tt>use VersionableModelTrait</tt> and include a variable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public $typeAlias = 'com_helloworld.helloworld';
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit View (admin/src/View/Helloworld/HtmlView.php) – should display the Versions toolbar button if global config has <tt>save_history</tt> on.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Joomla 4 allows us to have different history version limits for helloworld items and categories, and this has been used in the configuration definition in admin/config.xml.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Setting Configuration Parameters in Install Script===
As you may remember, global configuration parameters relating to the Hello World component are defined in admin/config.xml and stored in the <tt>#__extensions</tt> table, in a JSON string in the params field of the record relating to <tt>com_helloworld</tt>. This means that when the component is first installed the params are not set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So, for example, even if the <tt>save_history</tt> is defined in config.xml to default to true, the versions won't be saved until an administrator actively saves the configuration parameters, because the Joomla versioning code assumes <tt>save_history</tt> to be false if it's not explicitly set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For this reason it makes sense to set any default configuration parameters in the install script.php, in the <tt>postflight</tt> method, and that has been done in this step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Tags===
Like version history, tags functionality has been changed to use a plugin – in plugins/behaviour/taggable – rather than the <tt>JTableObserver</tt> approach.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To enable tags the component table must implement TaggableTableInterface (in libraries/src/Tag), and provide the <tt>getTypeAlias()</tt> which is common to the Versioning functionality.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Whenever <tt>com_tags</tt> outputs helloworld messages or categories relating to a tag it displays them as links, and looks in the site/helpers/route.php file to find the route functions (as described above in [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_tags|com_tags]]). The class and method in this file must match the 'router' field within the data entered into the <tt>#__content_types</tt> table.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===media files===
Under Joomla 4 all of the media files are stored in the /media folder; these include javascript and css files (scss files too), as well as images such as the little flag symbols shown in the language switcher. Extensions being developed should store all of the js and css files in their /media folder, and then when the extension is installed these files are put under the extension's folder under the /media folder of the Joomla instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Patches==
Some bugs in Joomla were discovered during the course of updating the tutorial code to work under Joomla 4. If you find something doesn't work then make sure you're on at least Joomla 4.2.6 and check if you need one of the following patches:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
CategoryAssociationHelper.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39358/files
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
MediaField.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/issues/39203
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Category restore
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39474
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Contributors ==
*[[User:Robbiej|Robbie Jackson]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Prev: Adding Custom Fields|class=expand success}}</div>
</div>
</div>

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/26/it

2023-05-27T12:46:58Z

Ing Pulizzi: Created page with "addruleprefix="Robbie\Component\Helloworld\Administrator\Rule" addfieldprefix="Robbie\Component\Helloworld\Administrator\Field""

addruleprefix="Robbie\Component\Helloworld\Administrator\Rule"
addfieldprefix="Robbie\Component\Helloworld\Administrator\Field"

J3.x:Developing an MVC Component/Upgrading to Joomla4/it

2023-05-27T12:46:36Z

Ing Pulizzi: Created page with "Se utilizzi definizioni di campi o regole personalizzate nei tuoi file xml del modulo, devi indicare a PHP quale prefisso dello spazio dei nomi utilizzare per cercarli, ad ese..."

<noinclude><languages /></noinclude>

{{:J3.1:Developing an MVC Component/it}}
Questo passaggio copre ciò che è coinvolto nell'aggiornamento del codice del tutorial per allinearlo con la versione 4 di Joomla.

== Introduzione ==
Questa pagina descrive i principali aspetti relativi allo sviluppo dei componenti che sono stati introdotti in Joomla 4 e descrive in dettaglio cosa è stato modificato nel codice del tutorial per allinearsi con v4.

Non è pratico dettagliare tutte le modifiche al codice sulla pagina Web come è stato fatto per i passaggi precedenti dell'esercitazione. Invece puoi trovare il codice come repository github su [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial Joomla 4 Tutorial code], e puoi confrontarlo con il codice del passaggio precedente del tutorial (Adding Custom Fields) su [https://github.com/robbiejackson/Joomla-3-MVC-Tutorial Joomla 3 MVC code]. Il codice di Joomla 4 replica tutte le funzionalità del codice di Joomla 3, con l'eccezione dell'implementazione dell'icona del piccolo pinguino introdotta in [[S:MyLanguage/J3.2:Developing an MVC Component/Adding decorations to the backend|Aggiunta di decorazioni al backend]] (che non è così rilevante data la modifica dell'interfaccia utente in Joomla 4 Administrator) e l'uso di un plug-in CAPTCHA ([[J3.x:Developing an MVC Component/Adding a frontend form|Adding a frontend form]] ). Probabilmente troverai utile avere a portata di mano questo codice Joomla 4 a cui fare riferimento mentre leggi questa pagina.

Il codice per questo passaggio è stato sviluppato seguendo ciascuno dei precedenti passaggi del tutorial e cercando di far funzionare ogni passaggio con Joomla 4.2.5. Poiché Joomla 4 si sta ancora evolvendo abbastanza velocemente, è possibile che alcuni aspetti qui citati vengano modificati durante la vita di Joomla 4. Sentiti libero di correggere gli aspetti in questa pagina e creare richieste pull su [https://github.com/robbiejackson /Joomla-4-MVC-Tutorial Joomla 4 github repository].

Se stai installando il codice del tutorial di Joomla 4 su una nuova istanza di Joomla, dovrai configurare la tua istanza per renderla multilingue e aggiungere le voci di menu nascoste di Ajax come descritto nel passaggio [[J3.x:Developing an MVC Component/ Utilizzo del filtro della lingua |Utilizzo del filtro della lingua]]. Assicurati inoltre che ogni record helloworld abbia una categoria valida.

=== Ulteriori letture ===
Puoi trovare [https://blog.astrid-guenther.de/en/der-weg-zu-joomla4-erweiterungen/ qui] un tutorial per lo sviluppo dei componenti di Joomla 4, simile a questo Joomla 3, e alcuni eccellenti Joomla 4 è disponibile anche la documentazione [https://www.dionysopoulos.me/book.html qui]. Entrambi questi riferimenti includono descrizioni degli impatti di Joomla 4 sullo sviluppo di altri tipi di estensioni Joomla (plugin, moduli e modelli), che non sono trattati qui.

Questo passaggio non copre tutto ciò che è necessario per aggiornare un componente da Joomla 3 a Joomla 4, solo gli aspetti coperti dal codice del tutorial. Se stai aggiornando il tuo componente Joomla 3, potresti trovare utile esaminare [[Potenziali problemi di compatibilità con le versioni precedenti in Joomla 4]].

== NameSpace ==
===NameSpace dei nomi dei componenti===
I NameSpace delle classi che utilizza la [https://www.php-fig.org/psr/psr-4/ PSR-4 recommendation] è stato gradualmente introdotto durante le versioni di Joomla 3 e con Joomla 4 è praticamente tutto con NameSpace

Ora è previsto che anche le estensioni di Joomla utilizzino i NameSpace di base per l'estensione definito nel suo file XML manifest. I componenti di Joomla usano uno NameSpace della forma <tt>Joomla\Component\<Nome componente></tt> es. <tt>Joomla\Component\Content</tt>, quindi seguendo questo schema ho dato una base al codice del tutorial spazio dei nomi di <tt>Robbie\Component\Helloworld</tt>. Ecco la riga nel file manifest helloworld.xml:

<namespace path="src">Robbie\Component\Helloworld</namespace>

(L'attributo <tt>path="src"</tt> indica che si aspetterà che le classi si trovino nella sottocartella <tt>src</tt>.)

Questo in realtà crea 2 prefissi dello spazio dei nomi, che puntano a cartelle specifiche nella nostra struttura di sviluppo helloworld e nella nostra istanza joomla live:

<tt>Robbie\Component\Helloworld\Administrator</tt> – punterà ad administrator/components/com_helloworld/src sull'istanza live ed è associato ad admin/src nella nostra area di sviluppo.

<tt>Robbie\Component\Helloworld\Site</tt> – punterà a components/com_helloworld/src sull'istanza live ed è associato a site/src nella nostra area di sviluppo.

Quindi Joomla ora si aspetta che tutti i nomi delle classi vengano trovati in quelle directory di base, con il nome del file che corrisponde al nome della classe e il nome della classe completo che corrisponde al percorso, ad esempio

<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> si troverà in
administrator/components/com_helloworld/src/Controller/DisplayController.php

<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> si troverà in
components/com_helloworld/src/Model/CategoryModel.php

'''Nota che le lettere maiuscole sono importanti nei namespace, nei nomi delle classi e nei nomi dei percorsi!'''

Quando Joomla 3 ha voluto chiamare le funzioni nel tuo componente, ha cercato determinati nomi di file in cartelle particolari e ha verificato che il nome della classe in quel file corrispondesse a quello previsto.

In Joomla 4 genera il nome completo della classe che vuole trovare, quindi cerca di trovarlo nella posizione in cui la raccomandazione PSR-4 lo aspetterebbe.

Quindi il namespace che specifichi nei tuoi file di classe deve essere allineato con il percorso del tuo file PHP, sotto la cartella di base <tt>src</tt> nel prefisso del tuo namespace.

Si noti in particolare come sono ora organizzati i file della classe <tt>View</tt>.

Inoltre, se usi una delle classi predefinite di PHP (ad es. <tt>Exception</tt>) nel tuo codice, aggiungi una barra rovesciata prima di essa (ad es. <tt>\Exception</tt>), altrimenti PHP cercherà di trovare nel tuo spazio dei nomi.

Se utilizzi definizioni di campi o regole personalizzate nei tuoi file xml del modulo, devi indicare a PHP quale prefisso dello spazio dei nomi utilizzare per cercarli, ad esempio in <tt>site/forms/add-form.xml</tt>:

<div lang="en" dir="ltr" class="mw-content-ltr">
addruleprefix="Robbie\Component\Helloworld\Administrator\Rule"
addfieldprefix="Robbie\Component\Helloworld\Administrator\Field"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and also in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> where the associations are added into the form dynamically to form the custom <tt>modal_helloworld</tt> type field:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Class Autoloading===
Joomla uses the PHP mechanism for [https://www.php.net/manual/en/language.oop5.autoload.php Autoloading Classes] and on startup registers a number of autoloaders – functions which get called when PHP can't find a given class. In particular the Joomla PSR-4 autoloader function (in <tt>libraries/loader.php</tt>) is responsible for finding classes of Joomla extensions whose code is in source files which are organised according to the PSR-4 recommendation. (Joomla library classes are autoloaded using a different autoloader – see <tt>libraries/vendor/composer/autoload_static.php</tt>).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can see the namespace prefixes of extensions on the Joomla instance by looking at <tt>administrator/cache/autoload_psr4.php</tt>. (These namespace strings have double backslashes, but in PHP they're the [https://stackoverflow.com/questions/25459197/single-or-double-slash-when-using-php-namespace same strings as those with single backslashes]). This is generated by Joomla looking through the component, module and plugin directories to find each extension's manifest file, and then processing these xml files to extract the <tt><namespace></tt> element – quite a lot of work, which is why it's cached I guess!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider what happens when Joomla wants our admin HelloworldController class. It might have something like
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$classname = 'Robbie\Component\Helloworld\Administrator\Controller\HelloworldController'
if (!class_exists($classname)) { …
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Assuming PHP doesn't already know about this class, the <tt>class_exists</tt> function will result in the classname being passed to the registered autoload function(s). The PSR-4 autoloader will then:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# go through its array of namespaces to try and match <tt>$classname</tt> from the start of the string.
# find 'Robbie\Component\Helloworld\Administrator' as a match
# see that this maps to "administrator/components/com_helloworld/src"
# extract the remainder of the classname: 'Controller\HelloworldController'
# treat this as the path down to the class file
# and so look for "administrator/components/com_helloworld/src/Controller/HelloworldController.php"
# check that in this file there's actually a class with that namespace + class name.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So in this way Joomla can go from a fully qualified class name to find the source code for that class. This makes it easier for us too when the core Joomla code is looking for one of our classes. We still need to know what class it's looking for, but once we know that, we know what we should call our class and where we should save the source code for it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Joomla Library classes===
Originally Joomla's core classes (beginning with a capital J) were global classes. Over the Joomla 3 versions and into Joomla 4 these migrated to their namespaced equivalents, but the original global classnames were still available as Joomla registered them as aliases (in the <tt>libraries/classmap.php</tt> file).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In a Joomla 4 extension you can still use these global classnames, except that in a namespaced file you'd have to prefix the name with a backslash to indicate a global class rather than one in your namespace (eg <tt>\JFactory</tt> instead of <tt>JFactory</tt>).
However it's pretty definite that the aliases will disappear at some stage, so the upgrade to Joomla 4 seems an appropriate opportunity to replace all your component's calls to the global JSomething classes to the namespaced equivalents. This involves adding the appropriate <tt>use</tt> statements, and all this has been done in the tutorial code. A useful mapping between the two can be found [https://github.com/nikosdion/joomlatypehints/blob/main/JoomlaObsoleteClasses.md here], where the new qualified classname can be copied and pasted into a <tt>use</tt> statement in your PHP file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
With reference to the [https://api.joomla.org/ Joomla API Documentation] there are 2 Joomla library namespaces:
* Joomla CMS classes – have namespaces <tt>Joomla\CMS\Something</tt> – are found under <tt>libraries/src/Something</tt>
* Joomla Framework classes – have namespaces <tt>Joomla\Something</tt> – are found under <tt>libraries/vendor/joomla/something/src</tt>
So a big advantage of namespacing is that you can immediately determine from the fully qualified class name in a PHP <tt>use</tt> statement where the source for that class exists in the <tt>libraries</tt> directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
On the other hand class names which aren't fully qualified don't have to be unique, eg <tt>MVCFactory</tt>
* occurs as <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in <tt>libraries/src/Extension/Service/Provider/MVCFactory.php</tt>
* occurs as <tt>Joomla\CMS\MVC\Factory\MVCFactory</tt> in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>
so sometimes you have to be careful to examine the <tt>use</tt> statement to identify the right class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly our FormModel class in <tt>site/src/Model/FormModel.php</tt> can have the same FormModel classname as the Joomla FormModel in <tt>libraries/src/MVC/Model/FormModel.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The API documentation gives the methods available in each of the [https://api.joomla.org/cms-4/namespaces/joomla.html Joomla CMS] and [https://api.joomla.org/framework-2/namespaces/joomla.html Framework] classes, but just be aware that a Joomla CMS class may extend a Framework class, and in this case some methods may not be visible under the Joomla CMS documentation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For example, <tt>$app->setHeader()</tt> which is used to set the HTTP response code is not listed under the [https://api.joomla.org/cms-4/classes/Joomla-CMS-Application-CMSApplication.html CMS Application class API], but is available as a method because it inherits from the Framework class [https://api.joomla.org/framework-2/classes/Joomla-Application-AbstractWebApplication.html AbstractWebApplication].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Vendor Namespaces===
These are also in <tt>libraries/vendor</tt>, eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Psr\Container\ContainerInterface;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
refers to <tt>libraries/vendor/psr/Container/src/ContainerInterface.php</tt>. However there are few of these in the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other File Rearrangements===
With all of the namespaced classes moving under the src directories, the <tt>tmpl</tt> layout files and <tt>form</tt> xml files have been moved out into their own directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Extension and Dispatcher classes ==
===Extension===
In Joomla 3 the point where the Joomla core handed over to your component code was when it ran your <tt>helloworld.php</tt> code; if it was the frontend it ran your site <tt>helloworld.php</tt> code, or if was the backend it ran your admin <tt>helloworld.php</tt> code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the entry point into your component code is your Extension class, both for site and admin, found in <tt>admin/src/Extension/HelloworldComponent.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When the Joomla core application wants to start executing the component code it creates an instance of <tt>HelloworldComponent</tt>, just to get a handle on the component code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly (as described below) other Joomla classes such as Router or Categories need to call certain Helloworld methods (eg custom router functions). In Joomla 3 these methods were written in certain Helper files etc. In Joomla 4 the principle is that the component creates an instance of the <tt>HelloworldComponent</tt> Extension class, and calls the required methods on that instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This Extension class isn't anything like a big container class for the component, it's more like a glue class, providing a way in to the Helloworld component, enabling the Joomla core and other components call the methods which they want to call.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla core wants to execute the component code, the key method it is looking for in your <tt>Extension</tt> instance is <tt>getDispatcher</tt>, and it expects to get back a <tt>Dispatcher</tt> instance. The <tt>HelloworldComponent</tt> extends <tt>MVCComponent</tt>, which in turn extends <tt>Component</tt>, and it is this class which defines <tt>getDispatcher</tt> for us.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Dispatcher===
When Joomla wants to run the Hello World component, it gets the <tt>Dispatcher</tt> instance as described above and then calls the <tt>dispatch</tt> method on it. It is this <tt>dispatch</tt> function which replaces the functionality in the admin and site <tt>helloworld.php</tt> files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's look at the main lines of code in our Joomla 3 admin <tt>helloworld.php</tt> file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="site/views/form/view.html.php">
<syntaxhighlight lang="php">
if (!JFactory::getUser()->authorise('core.manage', 'com_helloworld'))
{
throw new Exception(JText::_('JERROR_ALERTNOAUTHOR'));
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Get an instance of the controller
$controller = JControllerLegacy::getInstance('HelloWorld');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Execute the Request task method
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Redirect if set by the controller
$controller->redirect();
</syntaxhighlight>
</span>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code
* performs some permissions checks
* instantiates the appropriate Helloworld controller
* executes the appropriate method in that controller
* implements any redirect set by the controller
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Model-View-Controller]] for further details of how this works in Joomla 3. The second and third steps used the <tt>task</tt> parameter within the URL query to determine the correct controller class to instantiate and method to call. If no <tt>task</tt> parameter was present then it instantiated the controller in <tt>controller.php</tt> and called the <tt>display</tt> method. Otherwise it instantiated one of the controllers in the <tt>controllers</tt> subfolder (eg <tt>controllers/helloworld.php</tt>) and called the appropriate method on it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>ComponentDispatcher::dispatch</tt> method (in <tt>libraries/src/Dispatcher/ComponentDispatcher.php</tt>) now provides this functionality, but in a nicer way. After checking the permissions it uses the <tt>task</tt> by considering its parts as <tt><controller type>.<method></tt> (taking 'display' as default if either part is missing). It will then pass control to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* an instance of the class <Controller type>Controller
* calling the function <method>
* using the admin or site controller, as appropriate
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In this way the naming of the controllers is consistent - we have DisplayController, HelloworldController and HelloworldsController, all in the same folder.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Dispatcher class can thus be considered as providing some 'routing - execution' functionality, enabling us to find the right controller and function within that controller, and it is cleaner to have this in a separate class rather than in the <tt>JControllerLegacy</tt> class as it was in Joomla 3.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Since the Hello World tutorial uses the standard Joomla pattern for selecting the class and method based on the <tt>task</tt> and has the same permissions checks, we can use the <tt>dispatch</tt> code as it stands in <tt>ComponentDispatcher</tt>, and don't need to define a special class of our own.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Factory classes ==
In Joomla 3 many classes had static <tt>getInstance</tt> methods which returned an instance of that class, configured with the parameters passed to <tt>getInstance</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the <tt>getInstance</tt> methods have been deprecated in favour of using Factory classes. The preferred mechanism is now to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* get an instance of the appropriate Factory class (how we do that is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below)
* call the <tt>createSomething()</tt> method of the Factory class with relevant parameter values to generate an instance of the Something class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===MVC Factory===
In this section the <tt>MVCFactory</tt> class refers to the one in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory class will instantiate Controller, View, Model and Table instances on our behalf, and it does this by generating the classname of the class and then calling <tt>new</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The way it works is as follows:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Each component gets an individual MVCFactory instance which is constructed passing the component's namespace as a parameter (so in our case 'Robbie\Component\Helloworld'). (How this MVCFactory instance is created is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below).
# The MVCFactory createController / createView / createModel / createTable function is then called, passing the name of the Controller / Model / View / Table and the prefix (which specifies whether the administrator or site class is required).
# The create function forms the classname from this data and calls <tt>new</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory create functions just form the classname from the parameters they're passed. The intelligence for working out what name and prefix should be used to form the appropriate classes for an incoming HTTP request is
* in the dispatcher code for defining the controller to use
* in the controller for the view and model
* in the model for the table
and, for example, the names of the classes created for a request with URL query <tt>?option=com_helloworld&view=viewname</tt> and no <tt>task</tt> parameter will be
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<namespace>\Controller\DisplayController
<namespace>\View\Viewname\HtmlView
<namespace>\Model\ViewnameModel
<namespace>\Table\ViewnameTable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you need an alternative name then you can override the appropriate getView, getModel or getTable function – as for example was done in the [[J3.x:Developing an MVC Component/Adding Custom Fields#Front-end_Form|Adding Custom Fields step, frontend Form section]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So from the outside this is pretty much the same as in Joomla 3. However, note that the <tt>$prefix</tt> parameter in calls to <tt>getModel</tt> etc is subtly different
* in Joomla 3 this referred to a prefix to be applied to the classname – in the tutorial code we used 'HelloWorldTable' as the prefix part of the 'HelloWorldTableHelloWorld' classname.
* in Joomla 4 this refers to a prefix higher up the classname path, and should be set to either 'Site' or 'Administrator' (the capital letter at the start is optional), depending on whether you want the class under 'Robbie\Component\Helloworld\Site' or 'Robbie\Component\Helloworld\Administrator'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVC Factory class is now the Joomla recommended way to create the controller, view, model and table classes, by using the eg <tt>getModel()</tt> method, and the use of <tt>getInstance()</tt> for these classes is now deprecated. However, the use of these functions is restricted:
* in the controller class you can call <tt>$this->getView($viewname, $viewtype, $prefix, $config)</tt> to create a view and <tt>$this->getModel($modelname, $prefix, $config)</tt> to create a model.
* in the view class you can call <tt>$this->getModel($modelname)</tt>, but only for models which the controller has previously defined using <tt>$view->setModel($modelname, $default)</tt>. It doesn't create a new model instance.
* in the model class you can call <tt>$this->getTable($tableclass, $prefix, $options)</tt> to create a table instance. Controllers and views can access the table classes in this way, by going via a model.
These restrictions do have an impact on moving away from using <tt>getInstance()</tt>, and indeed in Joomla 4.2.6 you will still find several <tt>getInstance()</tt> calls within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Factory Classes===
Several other Factory classes have been introduced in Joomla 4, enabling you to get instances of core classes such as Form, User, CacheController, etc, usually by calling a createSomething function on the Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Associated with the Factory class is a FactoryInterface, a PHP Interface which specifies the key functions which the Factory class must implement. For example, with <tt>libraries/src/Categories</tt> we have:
* CategoryFactoryInterface – which specifies the <tt>createCategory</tt> function
* CategoryFactory implements CategoryFactoryInterface – which provides the <tt>createCategory</tt> function.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Dependency Injection ==
===Overview===
The DI container is one of the significant new additions to Joomla 4. It's basically a repository of key-value pairs where:
* the key is a string which is the name of a class or interface
* the value is an instance of the relevant class, or a function that returns an instance of that class.
You put things into the container using <tt>set()</tt> passing:
* the class name or interface name
* a function which returns an instance of the class (or an instance of the class)
* a boolean defining whether the class instance may be shared or not
* a boolean defining whether this entry into the DI container is protected or not (an error will be raised if you try to overwrite a protected entry by calling <tt>set()</tt> again using the same key).
The function <tt>share()</tt> is basically the same as <tt>set()</tt> with the <tt>shared</tt> boolean set to true.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You get things out of the container by calling <tt>get()</tt> passing the key of the resource you want. The container will
* find the key in the container
* if the value isn't already a class instance, then it will run the associated function to generate an instance of the class
* if the resource is shared, it will store the class instance, so that on subsequent invocations of <tt>get()</tt> it can just return the instance
* return the class instance to you
You can also define aliases for each key in the container, which means that you call <tt>get()</tt> passing either the key or an alias of the key.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The DI container is initialised in <tt>library/src/Factory.php createContainer()</tt> which results in the <tt>register()</tt> function being called in each of the class files in <tt>libraries/src/Service/Provider</tt>. By looking through those files you can see what gets put into the DI container upon initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===JConfig Example===
Let's consider the example of JConfig which holds the system global configuration. If you look inside <tt>libraries/src/Service/Provider/Config.php</tt> then you'll see the <tt>register()</tt> function and that it stores in the DI container a resource with:
* key = 'JConfig'
* value = an anonymous function - which loads what's in <tt>configuration.php</tt> into a <tt>Registry</tt> object, and returns it
* shared flag = true (because the <tt>share()</tt> function is used)
* protected flag = true
Then when you do
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$config = $container->get('JConfig');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will run the anonymous function and return the Registry object to you. As the 'shared' boolean is set it will also store a copy of the class instance locally in the container to be returned on subsequent calls of <tt>get('JConfig')</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Justification===
What's the point of all this?
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The advantage of dependency injection is that it allows classes to be easily mocked for testing. The file <tt>libraries/src/Service/Provider/Config.php</tt> can be replaced to return to a DI container <tt>get()</tt> call a mock class instead of the usual <tt>JConfig</tt>. This is in comparison to Joomla 3 where <tt>Factory::getConfig()</tt> code directly reads the <tt>configuration.php</tt> into a Registry structure and returns it – which makes it harder to mock.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The [https://api.joomla.org/cms-4/classes/Joomla-CMS-Factory.html Factory API] has several functions which are marked as deprecated with advice to get the object from the DI container instead.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Several of the other Factory classes (eg Form, Language, Menu, User) are in the DI container – so that we can get an instance of them via eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Factory::getContainer()->get('Joomla\CMS\Toolbar\ToolbarFactoryInterface')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to get a Toolbar instance. However, this only works for singleton classes which aren't specific to the needs of a particular extension. We'll see shortly how to make it work for class instances which need to be specific to a component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As indicated above, Joomla is moving away from using the class static <tt>getInstance()</tt> functions. We can see now that this is not only because it's more pure from an object oriented perspective. But also creating class instances from the DI container, or from Factory objects which are obtained from the DI container, builds in the dependency injection which allows classes to be more easily mocked, and hence more easily tested.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==services/provider.php==
We're now finally in a good position to understand what's happening in our services/provider.php file, and we'll explore this by walking through what happens whenever this line in libraries/src/Component/ComponentHelper.php <tt>renderComponent</tt> is run:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is run whenever Joomla has worked out which component is to be run on the requested web page, and it wants to run that component to capture its output.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 1 Create Child DI Container===
Joomla first creates another DI container (initially empty) just for this component, and links it to the main DI container via a parent field in the child DI container structure.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Now whenever <tt>set()</tt> is called on this DI container the key-value pair is inserted into the child container. Whenever <tt>get()</tt> is called on it, the resource is obtained from the child container, but if it's not found there then the parent container is searched also.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 2 Run register() in provider.php===
Next we encounter these lines (in <tt>libraries/src/Extension/ExtensionManagerTrait.php</tt>), where <tt>$path</tt> contains the path of our helloworld admin/services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$provider = require_once $path;
// Check if the extension supports the service provider interface
if ($provider instanceof ServiceProviderInterface) {
$provider->register($container);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here we see 3 things:
# our provider.php should return some object (so that <tt>$provider</tt> gets set to something)
# what is returned should implement ServiceProviderInterface (you can see in <tt>libraries/vendor/joomla/di/src/ServiceProviderInterface.php</tt> what is expected)
# the code then runs the <tt>register</tt> function on that object, passing as a parameter the child DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider a minimal version of our provider.php file. This would actually support steps in the Joomla 3 tutorial up to and including the [[J3.x:Developing an MVC Component/Adding AJAX|Adding Ajax step]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {

public function register(Container $container): void
{
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
}
};
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As you can see from the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
this file does indeed return something – it returns an instance of an anonymous class, one that implements <tt>ServiceProviderInterface</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it's not sufficient to just provide the <tt>register</tt> function in the class, we also need to explicity state that the class implements <tt>ServiceProviderInterface</tt>. This now happens in several places in Joomla, so if you're debugging your component and wondering why a function you expect to be called isn't being called, then check to make sure that you don't have to explicitly add the appropriate <tt>implements <Interface></tt> clause to your class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Next we look at the 3 lines in the <tt>register</tt> function
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3a Registering our MVC Factory===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here our <tt>MVCFactory</tt> refers to <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in libraries/src/Extension/Service/Provider/MVCFactory.php, and you should have a look at this file. This is a file similar to our provider.php file, but it's a named class, and it doesn't return anything. When we do:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
new MVCFactory('\\Robbie\\Component\\Helloworld')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it creates an instance of this class, and in the constructor it stores locally in <tt>$this->namespace</tt> our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>registerServiceProvider</tt> function then calls the <tt>register</tt> function of this instance, which runs (in its minimalist form):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
MVCFactoryInterface::class,
function (Container $container) {
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
return $factory;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So what gets entered into our child DI container is a key-value pair with:
* key = MVCFactoryInterface::class (this is just a shorthand form to obtain a string of the fully qualified name – ie 'Joomla\CMS\MVC\Factory\MVCFactoryInterface')
* value = a function which returns an instance of <tt>\Joomla\CMS\MVC\Factory\MVCFactory</tt>.
This is our MVCFactory class which generates our Controllers, Views, Models and Tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Notice that we're passing our namespace as a parameter <tt>$this->namespace</tt>. Because this function is a closure, this variable will still be available when we run this function later, and when the MVCFactory class is instantiated the namespace will be passed into the constructor, stored locally, and then subsequently used to form the fully qualified names of our Controllers, View, etc. So this is how we get instantiated the MVCFactory class which is specific to our component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3b Registering the Dispatcher Factory===
Careful: ComponentDispatcherFactory refers to two different classes here!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This ComponentDispatcherFactory is Joomla\CMS\Extension\Service\Provider\ComponentDispatcherFactory in libraries/src/Extension/Service/Provider/ComponentDispatcherFactory.php. Similar to the above, the ComponentDispatcherFactory service provider class stores locally our namespace, and then when <tt>register</tt> is called it executes:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentDispatcherFactoryInterface::class,
function (Container $container) {
return new \Joomla\CMS\Dispatcher\ComponentDispatcherFactory($this->namespace,$container->get(MVCFactoryInterface::class));
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so a second entry is added to the child DI container with:
* key = ComponentDispatcherFactoryInterface::class
* value = a function which returns an instance of the ComponentDispatcherFactory (the other ComponentDispatcherFactory class!), where the class constructor will be passed the namespace ('\\Robbie\\Component\\Helloworld') and an MVCFactory instance, retrieved from the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that the code
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->get(MVCFactoryInterface::class)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
will get from the container an entry with key = 'Joomla\CMS\MVC\Factory\MVCFactoryInterface' – which is what we entered into the container in step 3a – and will run the function associated with this key, and then return the object which this function returns. This returned object will be an instance of '\Joomla\CMS\MVC\Factory\MVCFactory', constructed using our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3c Including the Extension===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will put into the child DI container a key-value pair with
* key = ComponentInterface::class
* value = the function which will create an instance of our <tt>HelloworldComponent</tt> (ie our Extension class), and pass into the constructor an instance of the ComponentDispatcherFactory class, retrieving what was entered into the child DI container in Step 3b.
It will call <tt>$container->get(MVCFactoryInterface::class)</tt>, getting an MVC Factory instance from what was entered into the DI container in Step 3a.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It will then associate our component with this MVC Factory instance via the <tt>setMVCFactory</tt> call. Significantly this will then allow our component to access this instance later, via a call to <tt>getMVCFactory</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3 Summary===
We have now got 3 entries in our child DI container, keyed by
* key = MVCFactoryInterface::class, value is a function returning an MVCFactory instance
* key = ComponentDispatcherFactoryInterface::class, value is a function returning a ComponentDispatcherFactory instance
* key = ComponentInterface::class, value is a function returning our HelloworldComponent, an instance of our Extension class.
The important aspect is that these entries are all aware of our namespace '\Robbie\Component\Helloworld' and will return instances of these classes which are specific to our Helloworld component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 4 Retrieving from the DI Container===
Joomla will then execute the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $container->get($type);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
where <tt>$type</tt> contains 'Joomla\CMS\Extension\ComponentInterface'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This starts the process of retrieving from the DI container the 3 entries which we put in, and will run our code in services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We end up with a HelloworldComponent instance, which has:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. a ComponentDispatcherFactory instance passed into the constructor, and which is saved locally by the constructor code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function __construct(ComponentDispatcherFactoryInterface $dispatcherFactory)
{
$this->dispatcherFactory = $dispatcherFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This code is in libraries/src/Extension/Component.php, in the class which our HelloworldComponent extends, via the class MVCComponent).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. an MVC Factory instance, stored by the HelloworldComponent <tt>setMVCFactory</tt> call
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 5 Call boot() on our Component===
Joomla calls:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
if ($extension instanceof BootableExtensionInterface) {
$extension->boot($container);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will call <tt>boot</tt> within our HelloworldComponent, and allows us to perform some initialisation within our component. We'll return to this later, in the section on [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#HTML_Snippets|HTML snippets]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note again that Joomla checks that our HelloworldComponent class implements BootableExtensionInterface before calling <tt>boot</tt>. It's not sufficient to just provide the <tt>boot</tt> function, we have to explicitly declare that our HelloworldComponent implements the interface.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 6 Get the Dispatcher===
Returning to our key line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
we have now accomplished the first part <tt>bootComponent($option)</tt>, and this has returned our HelloworldComponent instance. Now we call <tt>getDispatcher($app)</tt> on this instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This code is also in libraries/src/Extension/Component.php, in the Component class which our HelloworldComponent extends:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function getDispatcher(CMSApplicationInterface $application): DispatcherInterface
{
return $this->dispatcherFactory->createDispatcher($application);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We call <tt>createDispatcher</tt> on our ComponentDispatcherFactory class instance which we saved in Step 4. This code is in libraries/src/Dispatcher/ComponentDispatcherFactory.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createDispatcher(CMSApplicationInterface $application, Input $input = null): DispatcherInterface
{
$name = ucfirst($application->getName());

$className = '\\' . trim($this->namespace, '\\') . '\\' . $name . '\\Dispatcher\\Dispatcher';

if (!class_exists($className)) {
if ($application->isClient('api')) {
$className = ApiDispatcher::class;
} else {
$className = ComponentDispatcher::class;
}
}

return new $className($application, $input ?: $application->input, $this->mvcFactory);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code checks if we have our own Dispatcher class (our Helloworld tutorial doesn't, but <tt>com_users</tt> for example has its own). So it creates a <tt>ComponentDispatcher</tt> instance, and passes into its constructor the MVC Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that this ComponentDispatcherFactory instance is what was instantiated when it was retrieved from our child DI Container (from being inserted in step 3b), and hence it already knows about our namespace, and has a pointer to our MVCFactory class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 7 call dispatch()===
This is the final aspect to our line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We're now back to what was described in the Dispatcher section above, except that now we can see that this Dispatcher instance has a pointer to our MVC Factory instance (which knows about our namespace prefix), so when the Dispatcher code wants to create a Controller it can use that MVC Factory instance to instantiate it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's been a long and tortuous journey to get here, but the significant thing is that all of our key class instances have been obtained via the DI Container. If we want to mock out any of those classes for testing then all we need to do is replace the relevant services/provider file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Javascript and the Web Asset Manager ==
The web asset manager has been introduced in Joomla 4 and is well documented [[J4.x:Web_Assets|here]]. It provides a much-improved means of managing JS and CSS resources, and a framework for handling their dependencies.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Component Javascript and CSS files should now be stored in the <tt>media</tt> folder, and the Web Asset Manager used to register them and output them on specific web pages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following assets have been registered in the tutorial <tt>joomla.asset.json</tt>, and you should have a look at that file now.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.validate-greeting===
This is the code for client validation of the helloworld greeting field using a regex, and it is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it is dependent upon jQuery and the Joomla <tt>form.validator</tt> script, so those both get included as dependencies.
If we didn't have specific validation on our form then we would need to include explicitly the <tt>form.validator</tt> script in order for the basic Joomla field validation to be included, eg in the tmpl file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->document->getWebAssetManager()->useScript('form.validate');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that this requires us to have a <tt>class="form-validate"</tt> on the </tt><form></tt> html element.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.fix-permissions-ajax-call===
This is the code which copies the value from the greeting field into the title field, so that the Ajax calls setting the permissions work correctly. The js code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.enable-tooltips===
This is the code which enables bootstrap tooltips to operate, including allowing them to include html code. It's used to display the image as a tooltip within the admin <tt>helloworlds</tt> view.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.openstreetmap===
This is defined as a preset, comprising the helloworld js and css code for the map display, as well as the dependency named 'com_helloworld.openlayers' relating to the openlayers CSS and js code. The code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.admin-helloworlds-modal===
This is the js code for selecting an individual helloworld record within a modal, and passing its details to the form in the main window. Its code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===submitbutton.js===
In the Joomla 3 code we introduced in [[Special:MyLanguage/J3.2:Developing_an_MVC_Component/Adding_verifications|Adding Verifications]] a js file which controlled when the form was submitted. It differentiated between buttons such as <tt>Save</tt> (which submitted the form) and <tt>Cancel</tt> (which didn't).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 there is a more sophisticated version of <tt>Joomla.submitbutton</tt> (found in media/system/js/core.js) which uses the CSS classes which the Toolbar functionality sets on the buttons to determine whether the form should be submitted or not. And you can override whether the validation is performed by adding a third parameter to the <tt>submitbutton</tt> js call. For example, to avoid validation being performed when a button is clicked you can set on the button element:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
onclick="Joomla.submitbutton('controller.method', '', false)"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As this is sufficient for what we need in the tutorial, the custom <tt>submitbutton.js</tt> has been removed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Interaction with other components ==
The way that Joomla interacts with components has changed in Joomla 4. In general the Joomla functionality will boot the component using something like:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $app->bootComponent($option);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and in our case this will return an instance of the <tt>HelloworldComponent</tt> class. It will then try to call certain methods on our extension object, as described below.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_categories===
In the backend the helloworld functionality can display to the administrator
* the view of the helloworld messages
* the view of the helloworld categories
The categories view is generated by <tt>com_categories</tt>, and in Joomla 4 these component categories views display the number of component records there are for each of the possible published status values. To do this the categories component executes the following code (in administrator/components/com_categories/src/Model/CategoriesModel.php):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof CategoryServiceInterface) {
$component->countItems($items, $section);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So our HelloworldComponent must:
* declare that it implements <tt>CategoryServiceInterface</tt>
* provide an implementation of <tt>countItems</tt>
We provide <tt>countItems</tt> by using a trait in libraries/src/Categories/CategoryServiceTrait.php, which (with the assistance of a helper function) does the query on our behalf. We just need to tell it:
* the name of our table – in the callback <tt>getTableNameForSection</tt>
* the database field in which we hold the published status – in <tt>getStateColumnForSection</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_associations===
Remember that <tt>com_associations</tt> is the component which is run whenever you click on Multilingual Associations in the admin backend.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Under Joomla 3 we provided an associations helper file as described in [[J3.x:Multilingual Associations/Developers|Multilingual Associations/Developers]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the helper file remains basically the same, but <tt>com_associations</tt> primarily tries to find the helper file via the extension class; here's the code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($extensionName);
if ($component instanceof AssociationServiceInterface) {
return $component->getAssociationsExtension();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's expecting that:
* the extension (HelloworldComponent in our case) implements <tt>AssociationServiceInterface</tt>
* its <tt>getAssociationsExtension</tt> method returns the helper class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The easiest thing would be just to code <tt>getAssociationsMethod</tt> and get it to return <tt>new AssociationsHelper</tt>. However, we follow the Joomla 4 principle of putting key classes into the Dependency Injection container, and retrieving them later, by having the following code in our services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(AssociationExtensionInterface::class, new AssociationsHelper());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The above line puts a key-value pair into our child DI container
* key = 'Joomla\CMS\Association\AssociationExtensionInterface'
* value is an instance of our <tt>AssociationsHelper</tt> class.
We then retrieve it later and use the setter:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setAssociationExtension($container->get(AssociationExtensionInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so that whenever
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getAssociationExtension()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
is called it returns the <tt>AssociationsHelper</tt> class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_fields===
<tt>com_fields</tt> is the component which is run when an administrator clicks on the Fields or Field Groups menuitem within the backend, and this functionality was included in the [[J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Adding Custom Fields]] tutorial step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>com_fields</tt> component stores the custom fields and field groups for all components in the database tables <tt>#__fields</tt> and <tt>#__fields_groups</tt>, and these tables are partitioned into "sections", one section per component. For our helloworld component the section is named "helloworld".
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within the section we have 2 "contexts" – one for the helloworld messages (called "com_helloworld.helloworld") and one for the helloworld categories (called "com_helloworld.categories"). This enables us to define custom fields for both our helloworld records and helloworld category records.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When <tt>com_fields</tt> runs it checks both the section and contexts at various times. For example, when an admin selects Helloworld / Fields on the backend then <tt>com_fields</tt> checks the section which was defined in the menuitem in the manifest file (see [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Sidebar|below]]). Here's the code in administrator/components/com_fields/src/Helpers/FieldsHelper <tt>extract</tt> function:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
$newSection = $component->validateSection($parts[1], $item);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And when <tt>com_fields</tt> wants to display the little dropdown menu of contexts (to allow the administrator to set custom fields on either helloworld items or categories) it calls (in administrator/components/com_fields/src/Fields/FieldcontextsField.php <tt>getOptions()</tt>):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
return $component->getContexts();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So it's clear that our component extension class must :
* implement <tt>FieldsServiceInterface</tt>
* provide the <tt>validateSection</tt> and <tt>getContexts</tt> methods
So in upgrading to Joomla 4 we've just moved those two methods from the helper file to the extension class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Router===
The Joomla router will access our custom router code:
* whenever it wants to parse an SEF route which it has identified as belonging to <tt>com_helloworld</tt>
* whenever it wants to build an SEF route from a call to <tt>Route::_()</tt> where the option = "com_helloworld".
To find our custom router it will:
* boot the <tt>com_helloworld</tt> extension
* check that the extension implements <tt>RouterServiceInterface</tt>
* call <tt>createRouter</tt> on our extension instance
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In our services/provider.php file we have (careful again - 2 different RouterFactory classes!):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new RouterFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which from libraries/src/Extension/Service/Provider/RouterFactory.php puts into our child DI container an entry with:
* key = "Joomla\CMS\Component\Router\RouterFactoryInterface"
* value is a <tt>\Joomla\CMS\Component\Router\RouterFactory</tt> instance, constructed with our namespace
We then retrieve this in the line in our services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setRouterFactory($container->get(RouterFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And then within our extension class we have
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use RouterServiceTrait;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which includes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function setRouterFactory(RouterFactoryInterface $routerFactory)
{
$this->routerFactory = $routerFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which stores the <tt>routerFactory</tt> locally and
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return $this->routerFactory->createRouter($application, $menu);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which provides our extension's <tt>createRouter</tt> call that the Joomla Router expects.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>routerFactory::createRouter</tt> method is in libraries/src/Component/Router/RouterFactory.php. It looks for a class in our site namespace </tt>Robbie\Component\Helloworld\Site\Service\Router</tt> which is in our site/src/Service/Router.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
At this stage we have a choice, we can either:
* provide a traditional custom router, with the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions, or
* use the more modern <tt>RouterView</tt> mechanism.
By default in the upgraded tutorial code the Router View option has been coded in the Router.php file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====RouterView====
In the <tt>RouterView</tt> case the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions are in the <tt>RouterView</tt> class which we extend, and we provide
* a constructor with router view configuration
* methods <tt>getHelloworldId</tt> and <tt>getCategoryId</tt> which are used to obtain from the SEF segment the <tt>id=</tt> and <tt>catid=</tt> parts of the internal URL
* methods <tt>getHelloworldSegment</tt> and <tt>getCategorySegment</tt> which are used to generate segments for the SEF URLs based on the <tt>id=</tt> and <tt>catid=</tt> parts within the <tt>Route::_()</tt> parameter.
Unfortunately there doesn't seem to be a good guide to configuring the RouterView class. There is some documentation available [https://www.dionysopoulos.me/book/com-router-routerview.html here].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the helloworld tutorial we have 3 views
* a view which displays a single helloworld record
* a view which displays a single helloworld category, and the helloworld records associated with it
* a view which displays the frontend form
So we need 3 Router Views associated with these.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'form' view doesn't have an associated id or catid so it's just a fixed URL, and the router just has to convert between the alias of the form menuitem and the Itemid / view parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'category' view has an associated id (of the category record), and an SEF URL will use the category path down the Categories Nested Set table structure, hence <tt>setNestable()</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'helloworld' view has an associated id (of the helloworld record), and in an SEF URL in the category view the helloworld record alias is added to the category path (hence <tt>setParent()</tt>). But although the helloworld records use a Nested Table structure in the database, the URLs just include the alias of the single record, and so <tt>setNestable()</tt> is not used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There doesn't seem to be a way to configure an additional SEF URL scheme which just displays a helloworld segment, without a category segment.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====Traditional Router====
To use the traditional router in the tutorial code you should uncomment the function in the extension class:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return new TraditionalRouter($application, $menu, $this->categoryFactory, $this->getDatabase());
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will cause the code in site/src/Service/TraditionalRouter.php to be used. However, changes in the Joomla 4 router mean that the interaction between it and the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> methods have changed. This requires significant changes to the <tt>preprocess</tt> and <tt>build</tt> methods, but only a minor change to <tt>parse</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. Previously Joomla injected into the <tt>$query</tt> parameters the <tt>Itemid</tt> of the active menuitem (ie the id of the menuitem the user is currently on). This meant that we had to change the <tt>Itemid</tt> for links generated by the Language Switcher module (which generates the flags for switching between languages), and these links being associated with a different language would obviously use a different <tt>Itemid</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 you get an <tt>Itemid</tt> in the <tt>$query</tt> parameters only if you specified an <tt>Itemid</tt> in the <tt>Route::_()</tt> call. For others you have to work out which menuitem to use yourself, by using the Joomla menu/menuitems API to find details of the configured menuitems, and work out which to use based on the other <tt>$query</tt> parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You do this in the <tt>preprocess</tt> method, and then the <tt>Itemid</tt> you set will be passed in the <tt>$query</tt> parameters to the <tt>build</tt> method.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. In some instances the <tt>Route::_()</tt> URL you're generating matches exactly one of the configured menuitems on the site. In this case the <tt>$query</tt> parameters will match those in the menuitem <tt>"query"</tt> array, and you have to remove explicitly remove the 'view', 'id' and 'catid' parameters so that they don't appear as URL query parameters after the normal SEF URL of the menuitem.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
3. The custom router will be used to build the URLs for the helloworld menuitems shown in menus on the page. For these the <tt>$query</tt> parameters will have the view / id / catid associated with those menuitems. Note that even if you remove these in your <tt>preprocess</tt> method, Joomla will inject them again into the <tt>$query</tt> array when it's passed to your <tt>build</tt> method, so you'll have to remove them again there!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
4. In the <tt>parse</tt> method you now have to unset the <tt>$segments</tt>, or else Joomla will return an HTTP 404 (page not found). Otherwise <tt>parse</tt> works as before.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
5. I've implemented <tt>build</tt> only for when Multilanguage is enabled on the site. If it's not enabled an empty <tt>$segments</tt> array is just returned, without doing unset on any of the <tt>$query</tt> parameters, so these will appear as URL parameters after the SEF URL. Also it's not coded properly to deal with items which have language set to <tt>*</tt>. These include helloworld records, categories or menuitems (eg the helloworld form).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that the <tt>categoryFactory</tt> is also now passed to the router. This is so that it can be used instead of <tt>Categories::getInstance()</tt> to get access to the Categories API calls.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_tags===
Whenever we setup a Tags Menu Item Type which displays items having a given tag or tags, then <tt>com_tags</tt> displays those items as links, and uses route helper functions to generate the URL parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The route helpers <tt>com_tags</tt> expects to find loaded into the data of the <tt>#__content_types</tt> table, in the router field, and these have been set to:
* For links to helloworld items: 'HelloworldHelperRoute::getHelloworldRoute'
* For links to helloworld categories: 'HelloworldHelperRoute::getCategoryRoute'
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, <tt>com_tags</tt> doesn't boot the helloworld extension to get access to these, but rather seeks to find them in site/helpers/route.php, so that's where they continue to be.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(We also had a <tt>getCategoryRoute</tt> which was used by <tt>com_categories</tt> in administrator/components/com_categories/src/Helper/CategoryAssociationHelper. When a category was displayed on the frontend then the Language Switcher module (now Language Filter) used this function to generate the links to the Associated Categories. Our <tt>getCategoryRoute</tt> previously was necessary to insert the <tt>lang=<language tag></tt> parameter into the link URL, but since [https://github.com/joomla/joomla-cms/pull/39358 this change] the calling function inserts the <tt>lang</tt> parameter itself, so our <tt>getCategoryRoute</tt> function for this purposes is superfluous.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Deprecated APIs ==
With Joomla 4 there are a number of methods which are deprecated, with a view to removing them in Joomla 5.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Factory Methods===
Many of the <tt>Factory</tt> methods for getting singleton classes have been deprecated in favour of getting these classes via the DI container, and it appears that only class instances which should be obtained via Factory methods are:
* the Application – <tt>Factory::getApplication()</tt>
* the DI container – <tt>Factory::getContainer()</tt>
Here is a list of what has been changed in the tutorial code. Note that with some calls there are variants available, through the aliases defined in the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDbo'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\Database\DatabaseInterface;
...
$db = Factory::getContainer()->get(DatabaseInterface::class);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, in many classes the database instance is more easily (and efficiently) returned via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$db = $this->getDatabase();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is available in Model classes, custom field definitions, etc.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getUser();'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get the current user use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = Factory::getApplication()->getIdentity()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get a different user (whose id you know):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\User\UserFactoryInterface;
...
$user = Factory::getContainer()->get(UserFactoryInterface::class)->loadUserById($userid);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within models which extend Joomla\CMS\MVC\Model\BaseDatabaseModel and views which extend Joomla\CMS\MVC\View\HtmlView you can also use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = $this->getCurrentUser()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDocument()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication()->getDocument()</tt>, or within a View you can use <tt>$this->document</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getConfig()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Two options have been used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->getConfig()</tt> – returns a Registry object containing all the configuration values
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->get('access')</tt> – returns the value of the 'access' configuration parameter
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getLanguage()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication->getLanguage()</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JFactory::getCache('com_example', <type>)'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Cache\CacheControllerFactoryInterface;
...
Factory::getContainer()->get(CacheControllerFactoryInterface::class)->createCacheController(<type>)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated getInstance Methods===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general <tt>getInstance()</tt> calls have been deprecated in favour of obtaining the instance, either via a factory class or via the DI container. For example, within a controller you can use <tt>getModel()</tt> repeatedly to get different models (passing the relevant model names), which results in the MVCFactory class creating the Model classes.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there are currently some problems with replacing some getInstance calls. I expect that the Joomla team will resolve these issues over the course of the Joomla 4 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Categories::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is deprecated with a notice: "Use the ComponentInterface to get the categories". This means that we should get the category factory instance via the DI container. This is done in our services/provider.php by the lines:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Extension\Service\Provider\CategoryFactory;
...
$container->registerServiceProvider(new CategoryFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to put into our child DI container the closure which will create a Joomla\CMS\Categories\CategoryFactory instance, constructed with our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when our HelloworldComponent (Extension) instance is created:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We can then use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getCategoryFactory()->createCategory();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to create our Categories object, and in this way get access to the Categories APIs.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This createCategory method creates the instance by looking for the \\Site\\Service\\Category class within our namespace. The constructor in our class sets our extension ('com_helloworld') and table ('#__helloworld') and calls the parent Categories constructor with these options).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this means that the section of our code where we want to use the Categories APIs must have a pointer to a CategoryFactory instance. In the tutorial code for Joomla 3 there are 2 places where <tt>Categories::getInstance</tt> is used:
* in the custom router code, to handle building and parsing of the category parts of the SEF URL
* in the site category model, where the Categories APIs are used to obtain details of categories to display on the page.
For the custom router code, the CategoryFactory instance is passed as a parameter to the TraditionalRouter constructor so that it can be used there.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, the site category model is instantiated by the MVCFactory instance, and it doesn't make available a CategoryFactory instance. So in this category model the calls to <tt>Categories::getInstance()</tt> have been left, and you can still find a number of calls to <tt>Categories::getInstance</tt> within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Categories::getInstance()</tt> itself solves the problem of access to a CategoryFactory instance by rebooting our component again to get a pointer to our Extension instance, and thus to the category factory instance. However, this involves a lot of work, so <tt>getInstance</tt> caches locally the Categories instances and just returns one of them if it can.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Pushing the CategoryFactory to the model'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there is a way to get access to the CategoryFactory instance, by defining your own MVCFactory class, and pushing the instance down through it to the model. Here's how you can go about it:
* Define your own SuperMVCFactory class, which extends the Joomla Joomla\CMS\MVC\Factory\MVCFactory class, but which has a means of storing a CategoryFactory instance. Use the CategoryServiceTrait in libraries/src/Categories/CategoryServiceTrait.php
* Create your own version of the file libraries/src/Extension/Service/Provider/MVCFactory.php, which is the 'provider.php' like file for MVCFactory, but change it so that:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
becomes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new <namespace>\SuperMVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and include
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla creates a model such as CategoryModel it passes in its constructor the MVCFactory instance (so that the model can call createTable on it), so you can access it via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will return your SuperMVCFactory instance. So in this way within the model you can access the CategoryFactory, and use it to create the Categories instance via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()->getCategory() (from the CategoryServiceTrait)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you can get this working you can congratulate yourself on a good understanding of Joomla namespacing and dependency injection! A similar approach to address a similar problem is described [https://www.dionysopoulos.me/book/com-router-push-dependencies.html here]. If you get stuck you can always view the solution by viewing the github tutorial code selecting the branch [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial/tree/push-category-factory-to-mvc push-category-factory-to-mvc].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Table::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There are a couple of calls to <tt>Table::getInstance()</tt> within admin/src/Helper/AssociationsHelper.php in <tt>getItem()</tt>:
* <tt>Table::getInstance('Helloworld', 'Robbie\\Component\\Helloworld\\Administrator\\Table\\')</tt> to get an instance of our HelloworldTable class.
* <tt>Table::getInstance('Category')</tt> to get an instance of the Category table in libraries/src/Table/Category.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We could actually arrange for the AssociationsHelper class to get injected with the MVCFactory instance, so that the HelloworldTable class could be instantiated by it. However, we couldn't use the helloworld MVCFactory instance to create the Category table instance, as it's not in the helloworld namespace, and our MVCFactory instance creates table instances within our namespace only.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Toolbar::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The tutorial code uses <tt>Toolbar::getInstance()</tt> to get a Toolbar instance onto which it can attach the batch button in the helloworlds form. The Toolbar API documentation seems to suggest that we should replace
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Toolbar::getInstance('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
with
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this currently won't work. The problem is that all the other Joomla code uses <tt>getInstance('toolbar')</tt> to access the Toolbar class, including the code in administrator/modules/mod_toolbar/mod_toolbar.php which renders the toolbar. The <tt>getInstance</tt> method keeps track of the Toolbar instances in a local static variable <tt>$instances</tt>, and returns the same Toolbar instance on repeated invocations.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you use the second approach above you will get a Toolbar instance, but it won't be the same Toolbar instance as is stored in the <tt>$instances</tt> variable. It won't then be picked up by the Toolbar module, and so won't be rendered on the form.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Error Handling===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead of
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
JError::raiseError(500, implode('<br />', $errors));
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
you should throw an exception, using or extending one of the standard [https://www.php.net/manual/en/spl.exceptions.php PHP exceptions], eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
throw new \Exception(implode("\n", $errors), 500);
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===jimport===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
jimport is no longer necessary in order to get access to Path or File classes. All of the Joomla classes are found by the autoloader.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Methods related to Javascript===
'''JHtml::_('behavior.framework');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general, the use of JHtml::_('behavior.xxx') is now obsolete, and calls using this have been removed in the tutorial code. The 'behavior.framework' call referred to including jQuery. Where jQuery is necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.formvalidator');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by the <tt>form.validate</tt> javascript asset, and where necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It can also be included directly using the web asset manager:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$wa->useScript('form.validate')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.tooltip')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This no longer exists, and tooltips don't seem to be enabled by default in Joomla 4. This is replaced by the code in media/js/enable-tooltips.js.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('formbehavior.chosen')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The chosen js library seems to be no longer used, and using it will cause formatting issues if you include it in your tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''sortable'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The sortable js library provided the ability in the helloworlds view to drag rows up and down to change the ordering of the records. This has been replaced in Joomla 4 by the draggable library. To enable it you have to set:
* <tt>HTMLHelper::_('draggablelist.draggable');</tt>
* on your <tt><tbody></tt> element define the table in which dragging occurs and the URL of the Ajax call to set the ordering:
<source lang="php">
<tbody<?php if ($saveOrder) : ?> class="js-draggable" data-url="<?php echo $saveOrderingUrl; ?>" data-direction="<?php echo strtolower($listDirn); ?>" data-nested="true"
<?php endif; ?>>
</source>
* on your <tt>tr</tt> element within your <tt><tbody></tt> define the group of records in which dragging occurs (by category below):
<source lang="php">
<tr class="row<?php echo $i % 2; ?>" data-draggable-group="<?php echo $row->catid; ?>">
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==HTML Snippets==
There are two places in the tutorial where reusable snippets of HTML have beeen defined:
* For displaying the item associations in the helloworlds view:
* For displaying the position latitude and longitude fields within the batch options in the helloworlds view
These used different approaches:
* the item associations display was coded in an html helper file in admin/helpers/html/helloworlds.php and accessed via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JHtml::_('helloworlds.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
in the helloworlds tmpl file. (Although it did use a common joomla layout file underneath).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* the position field was coded as a layout in layouts/position.php, and rendered using
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JLayoutHelper::render('position', array());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When should you use one approach rather than the other? A significant difference is that layouts are designed so that an administrator can override them, via the Templates / Details and File functionality. So, for example, an administrator could change the position to show the longitude before the latitude. So it's more appropriate for layouts to focus on the html elements rather than functional logic, and particularly if you would want to allow an administrator to override the layout.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The layouts functionality in Joomla 4 hasn't changed significantly. One correction which has been made in the updated tutorial code has been to include the position.php file in a subfolder of layouts, ie in admin/layouts/helloworld/position.php rather than admin/layouts/position.php. It appears that in the Templates / Details and Files / Create Overrides tab the <tt>com_helloworld</tt> layout appears only if it's in a subfolder of /layouts.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>JHtml::_()</tt> approach has changed in Joomla 4. Rather than Joomla having to look for a helper file when it encounters something it doesn't recognise, it's expected that you should register such classes beforehand, and you do this by obtaining an instance of the Joomla\CMS\HTML\Registry class (it's a singleton class) and then calling <tt>register</tt> on it, passing
* the key you want to use
* an instance of your class
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Joomla pattern is to put the code in a file admin/src/Service/HTML/AdministratorService.php, and we have to ensure that our key won't be used elsewhere within Joomla, so in the tutorial we've used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Robbie\Component\Helloworld\Administrator\Service\HTML\AdministratorService;
...
register('helloworldadministrator', new AdministratorService)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when we call:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo HTMLHelper::_('helloworldadministrator.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will result in Joomla calling the <tt>association</tt> method in our class, passing the <tt>$row->id</tt> parameter.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We should get the Joomla\CMS\HTML\Registry class from the Dependency Injection container. Joomla components generally do this via their services/provider.php file, and then call <tt>register</tt> within the extension's <tt>boot</tt> function, described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Step_5_Call_boot.28.29_on_our_Component|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The extension uses HTMLRegistryAwareTrait which contains <tt>setRegistry</tt> and <tt>getRegistry methods</tt>. In services/provider.php there is:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\HTML\Registry;
...
$component->setRegistry($container->get(Registry::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets 'Joomla\CMS\HTML\Registry' out of the DI container and stores it within the
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
private $registry;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
variable of the HTMLRegistryAwareTrait included in the extension.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the <tt>boot</tt> function it calls
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getRegistry()->register('helloworldadministrator', new AdministratorService);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets the registry and calls <tt>register</tt> as required.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that <tt>boot</tt> is called whenever Joomla dispatches <tt>com_helloworld</tt>, both for the site and administrator, so it would make sense to check the Application <tt>isClient</tt> before deciding whether to register the HTML Helper service or not. This hasn't been included in the tutorial code though.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==User Interface Changes==
Joomla 4 introduced new templates, atum on administrator and cassiopeia on site, and in particular the administrator is built upon some UI rearrangements which affect the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Sidebar===
In Joomla 3 each component incorporated a sidebar which we coded in the <tt>addSubmenu</tt> function in admin/helpers/helloworld.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the administrator menu is in a vertical panel on the left hand side, and the Hello World submenu is built from entries in the helloworld.xml manifest file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<administration>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<submenu>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<menu link="option=com_categories&extension=com_helloworld">COM_HELLOWORLD_CATEGORIES</menu>
<menu link="option=com_fields&view=fields&context=com_helloworld.helloworld">MOD_MENU_FIELDS</menu>
<menu link="option=com_fields&view=groups&context=com_helloworld.helloworld">MOD_MENU_FIELDS_GROUP</menu>
</submenu>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===CSS Classes===
In several places the CSS classes defined in the html elements have been changed in Joomla 4. For example, for general layout the classes now align with the [https://getbootstrap.com/docs/3.4/css/ Bootstrap CSS Classes], and classes such as <tt>row-fluid</tt> and <tt>span3</tt> which were prominent in Joomla 3 have disappeared. If you're upgrading a Joomla 3 component then it's probably best (on the back-end at least) to find a similar Joomla component and use the overall html structure and css classes within its tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the tutorial code those classes which are specifically used by Bootstrap have been changed from eg 'data-target' to 'data-bs-target', and it has been necessary to change these to enable the functionality to work.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, not all of CSS class changes affecting solely the presentation have been reflected in the updated tutorial code. For example, in the <tt>helloworlds</tt> view, showing the list of helloworld messages, the display of the associations is different from that of other Joomla components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Fonts===
In Joomla 3 [[J3.x:Joomla_Standard_Icomoon_Fonts|Icomoon Fonts]] were used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 Font Awesome's free icons are used, and you can see what is available on their [https://fontawesome.com/v5/cheatsheet cheatsheet]. The icons are implemented using CSS pseudo-elements, as described [https://fontawesome.com/v5/docs/web/advanced/css-pseudo-elements here]. Basically they convert a CSS class into html content, namely a unicode value in the private use range. A couple of these have been implemented in the frontend form, in the Save and Cancel buttons, for example:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>span class="icon-cancel">/span <?php echo Text::_('JCANCEL') ?></tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(with angle brackets removed from the <tt>span</tt> tags to stop the icon just being displayed by the browser).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This class is defined in media/system/css/joomla-fontawesome.css (where you can find the list of icon classes supported):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
.icon-cancel:before {
content: "\f00d";
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so this includes in front of the text the unicode character <tt>f00d</tt>, which you can see on the cheatsheet as "times", and displayed as <span class="icon-cancel"></span>. You can also use <tt>fa-</tt> plus the icon name on the font awesome cheatsheet page. If you use Icomoon icon names in your code which you run under Joomla 4, then the icon displayed will be a Font Awesome icon (if there's one with the same name) or it will use a mapping which the Joomla team have defined to display a Font Awesome icon which resembles the Icomoon one.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Buttons and Links===
An accessibility principle is that <tt><a></tt> html elements should be used for links to other web pages, and <tt><button></tt> elements should be used for actions, eg on a form. To align with this, the <tt><a></tt> elements in the helloworld modal field (defined in admin/src/Field/Modal/Helloworld.php) have been changed to <tt><button></tt> elements. These are the Select and Clear buttons displayed when choosing a Helloworld record for a menuitem pointing to a Helloworld message. (The buttons also include fontawesome icons, by the way).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This change was actually made in Joomla in one of the Joomla 3 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Categories View===
In the Categories view of standard Joomla components there now appears columns which show for each category the number of items, split by published status. This is populated by <tt>com_categories</tt> calling each extension's <tt>countItems</tt> function, as described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_categories|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Miscellaneous Changes==
===Version History===
In Joomla 3 the tutorial code used the <tt>JTableObserver</tt> functionality to copy relevant changes from the Helloworld and Categories tables into the UCM tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it uses a plugin mechanism to subscribe to Table events 'onTableAfterStore' and 'onTableBeforeDelete'. The plugin can be found in plugins/behaviour/versionable, and it is activated by Joomla as part of its application initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The copying of fields from the table works roughly the same way as before, except that the name of the table where the versions are stored is now <tt>#__history</tt>, so the entries which have to be inserted into the <tt>#__content_types</tt> table are fairly similar. Because the folders in which forms are stored has changed in Joomla 4, the 'formFile' parameter is different (remember that this is where Joomla gets the field labels in order to display the Preview within the Versions modal window, otherwise just the names of the database columns will be output).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here's a summary of what needs to be done to enable versioning under Joomla 4. The Versioning Traits and Interface definitions are found in libraries/src/Versioning:
* Enter data into content_types database table
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Storing the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The Table class must implement VersionableTableInterface and provide <tt>getTypeAlias()</tt>, which returns 'com_helloworld.helloworld'. This type alias + the helloworld record id is used as the key to identify versions in the <tt>#__history</tt> table.
* Define <tt>save_history</tt> and <tt>history_limit</tt> options in config.php, and ensure these are both set.
* Add a <tt>version_note</tt> field into the output of the edit view's tmpl file (admin/tmpl/helloworld/edit.php).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Viewing and Restoring the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit Controller (admin/src/Controller/HelloworldController.php) should <tt>use VersionableControllerTrait</tt>.
* The edit Model (admin/src/Model/HelloworldModel.php) should <tt>use VersionableModelTrait</tt> and include a variable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public $typeAlias = 'com_helloworld.helloworld';
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit View (admin/src/View/Helloworld/HtmlView.php) – should display the Versions toolbar button if global config has <tt>save_history</tt> on.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Joomla 4 allows us to have different history version limits for helloworld items and categories, and this has been used in the configuration definition in admin/config.xml.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Setting Configuration Parameters in Install Script===
As you may remember, global configuration parameters relating to the Hello World component are defined in admin/config.xml and stored in the <tt>#__extensions</tt> table, in a JSON string in the params field of the record relating to <tt>com_helloworld</tt>. This means that when the component is first installed the params are not set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So, for example, even if the <tt>save_history</tt> is defined in config.xml to default to true, the versions won't be saved until an administrator actively saves the configuration parameters, because the Joomla versioning code assumes <tt>save_history</tt> to be false if it's not explicitly set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For this reason it makes sense to set any default configuration parameters in the install script.php, in the <tt>postflight</tt> method, and that has been done in this step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Tags===
Like version history, tags functionality has been changed to use a plugin – in plugins/behaviour/taggable – rather than the <tt>JTableObserver</tt> approach.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To enable tags the component table must implement TaggableTableInterface (in libraries/src/Tag), and provide the <tt>getTypeAlias()</tt> which is common to the Versioning functionality.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Whenever <tt>com_tags</tt> outputs helloworld messages or categories relating to a tag it displays them as links, and looks in the site/helpers/route.php file to find the route functions (as described above in [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_tags|com_tags]]). The class and method in this file must match the 'router' field within the data entered into the <tt>#__content_types</tt> table.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===media files===
Under Joomla 4 all of the media files are stored in the /media folder; these include javascript and css files (scss files too), as well as images such as the little flag symbols shown in the language switcher. Extensions being developed should store all of the js and css files in their /media folder, and then when the extension is installed these files are put under the extension's folder under the /media folder of the Joomla instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Patches==
Some bugs in Joomla were discovered during the course of updating the tutorial code to work under Joomla 4. If you find something doesn't work then make sure you're on at least Joomla 4.2.6 and check if you need one of the following patches:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
CategoryAssociationHelper.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39358/files
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
MediaField.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/issues/39203
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Category restore
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39474
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Contributors ==
*[[User:Robbiej|Robbie Jackson]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Prev: Adding Custom Fields|class=expand success}}</div>
</div>
</div>

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/25/it

2023-05-27T12:46:33Z

Se utilizzi definizioni di campi o regole personalizzate nei tuoi file xml del modulo, devi indicare a PHP quale prefisso dello spazio dei nomi utilizzare per cercarli, ad esempio in <tt>site/forms/add-form.xml</tt>:

J3.x:Developing an MVC Component/Upgrading to Joomla4/it

2023-05-27T12:46:14Z

Ing Pulizzi: Created page with "Inoltre, se usi una delle classi predefinite di PHP (ad es. <tt>Exception</tt>) nel tuo codice, aggiungi una barra rovesciata prima di essa (ad es. <tt>\Exception</tt>), altri..."

<noinclude><languages /></noinclude>

{{:J3.1:Developing an MVC Component/it}}
Questo passaggio copre ciò che è coinvolto nell'aggiornamento del codice del tutorial per allinearlo con la versione 4 di Joomla.

== Introduzione ==
Questa pagina descrive i principali aspetti relativi allo sviluppo dei componenti che sono stati introdotti in Joomla 4 e descrive in dettaglio cosa è stato modificato nel codice del tutorial per allinearsi con v4.

Non è pratico dettagliare tutte le modifiche al codice sulla pagina Web come è stato fatto per i passaggi precedenti dell'esercitazione. Invece puoi trovare il codice come repository github su [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial Joomla 4 Tutorial code], e puoi confrontarlo con il codice del passaggio precedente del tutorial (Adding Custom Fields) su [https://github.com/robbiejackson/Joomla-3-MVC-Tutorial Joomla 3 MVC code]. Il codice di Joomla 4 replica tutte le funzionalità del codice di Joomla 3, con l'eccezione dell'implementazione dell'icona del piccolo pinguino introdotta in [[S:MyLanguage/J3.2:Developing an MVC Component/Adding decorations to the backend|Aggiunta di decorazioni al backend]] (che non è così rilevante data la modifica dell'interfaccia utente in Joomla 4 Administrator) e l'uso di un plug-in CAPTCHA ([[J3.x:Developing an MVC Component/Adding a frontend form|Adding a frontend form]] ). Probabilmente troverai utile avere a portata di mano questo codice Joomla 4 a cui fare riferimento mentre leggi questa pagina.

Il codice per questo passaggio è stato sviluppato seguendo ciascuno dei precedenti passaggi del tutorial e cercando di far funzionare ogni passaggio con Joomla 4.2.5. Poiché Joomla 4 si sta ancora evolvendo abbastanza velocemente, è possibile che alcuni aspetti qui citati vengano modificati durante la vita di Joomla 4. Sentiti libero di correggere gli aspetti in questa pagina e creare richieste pull su [https://github.com/robbiejackson /Joomla-4-MVC-Tutorial Joomla 4 github repository].

Se stai installando il codice del tutorial di Joomla 4 su una nuova istanza di Joomla, dovrai configurare la tua istanza per renderla multilingue e aggiungere le voci di menu nascoste di Ajax come descritto nel passaggio [[J3.x:Developing an MVC Component/ Utilizzo del filtro della lingua |Utilizzo del filtro della lingua]]. Assicurati inoltre che ogni record helloworld abbia una categoria valida.

=== Ulteriori letture ===
Puoi trovare [https://blog.astrid-guenther.de/en/der-weg-zu-joomla4-erweiterungen/ qui] un tutorial per lo sviluppo dei componenti di Joomla 4, simile a questo Joomla 3, e alcuni eccellenti Joomla 4 è disponibile anche la documentazione [https://www.dionysopoulos.me/book.html qui]. Entrambi questi riferimenti includono descrizioni degli impatti di Joomla 4 sullo sviluppo di altri tipi di estensioni Joomla (plugin, moduli e modelli), che non sono trattati qui.

Questo passaggio non copre tutto ciò che è necessario per aggiornare un componente da Joomla 3 a Joomla 4, solo gli aspetti coperti dal codice del tutorial. Se stai aggiornando il tuo componente Joomla 3, potresti trovare utile esaminare [[Potenziali problemi di compatibilità con le versioni precedenti in Joomla 4]].

== NameSpace ==
===NameSpace dei nomi dei componenti===
I NameSpace delle classi che utilizza la [https://www.php-fig.org/psr/psr-4/ PSR-4 recommendation] è stato gradualmente introdotto durante le versioni di Joomla 3 e con Joomla 4 è praticamente tutto con NameSpace

Ora è previsto che anche le estensioni di Joomla utilizzino i NameSpace di base per l'estensione definito nel suo file XML manifest. I componenti di Joomla usano uno NameSpace della forma <tt>Joomla\Component\<Nome componente></tt> es. <tt>Joomla\Component\Content</tt>, quindi seguendo questo schema ho dato una base al codice del tutorial spazio dei nomi di <tt>Robbie\Component\Helloworld</tt>. Ecco la riga nel file manifest helloworld.xml:

<namespace path="src">Robbie\Component\Helloworld</namespace>

(L'attributo <tt>path="src"</tt> indica che si aspetterà che le classi si trovino nella sottocartella <tt>src</tt>.)

Questo in realtà crea 2 prefissi dello spazio dei nomi, che puntano a cartelle specifiche nella nostra struttura di sviluppo helloworld e nella nostra istanza joomla live:

<tt>Robbie\Component\Helloworld\Administrator</tt> – punterà ad administrator/components/com_helloworld/src sull'istanza live ed è associato ad admin/src nella nostra area di sviluppo.

<tt>Robbie\Component\Helloworld\Site</tt> – punterà a components/com_helloworld/src sull'istanza live ed è associato a site/src nella nostra area di sviluppo.

Quindi Joomla ora si aspetta che tutti i nomi delle classi vengano trovati in quelle directory di base, con il nome del file che corrisponde al nome della classe e il nome della classe completo che corrisponde al percorso, ad esempio

<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> si troverà in
administrator/components/com_helloworld/src/Controller/DisplayController.php

<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> si troverà in
components/com_helloworld/src/Model/CategoryModel.php

'''Nota che le lettere maiuscole sono importanti nei namespace, nei nomi delle classi e nei nomi dei percorsi!'''

Quando Joomla 3 ha voluto chiamare le funzioni nel tuo componente, ha cercato determinati nomi di file in cartelle particolari e ha verificato che il nome della classe in quel file corrispondesse a quello previsto.

In Joomla 4 genera il nome completo della classe che vuole trovare, quindi cerca di trovarlo nella posizione in cui la raccomandazione PSR-4 lo aspetterebbe.

Quindi il namespace che specifichi nei tuoi file di classe deve essere allineato con il percorso del tuo file PHP, sotto la cartella di base <tt>src</tt> nel prefisso del tuo namespace.

Si noti in particolare come sono ora organizzati i file della classe <tt>View</tt>.

Inoltre, se usi una delle classi predefinite di PHP (ad es. <tt>Exception</tt>) nel tuo codice, aggiungi una barra rovesciata prima di essa (ad es. <tt>\Exception</tt>), altrimenti PHP cercherà di trovare nel tuo spazio dei nomi.

<div lang="en" dir="ltr" class="mw-content-ltr">
If you use custom Field or Rule definitions in your form xml files then you have to indicate to PHP which namespace prefix to use to look for them, eg in <tt>site/forms/add-form.xml</tt>:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
addruleprefix="Robbie\Component\Helloworld\Administrator\Rule"
addfieldprefix="Robbie\Component\Helloworld\Administrator\Field"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and also in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> where the associations are added into the form dynamically to form the custom <tt>modal_helloworld</tt> type field:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Class Autoloading===
Joomla uses the PHP mechanism for [https://www.php.net/manual/en/language.oop5.autoload.php Autoloading Classes] and on startup registers a number of autoloaders – functions which get called when PHP can't find a given class. In particular the Joomla PSR-4 autoloader function (in <tt>libraries/loader.php</tt>) is responsible for finding classes of Joomla extensions whose code is in source files which are organised according to the PSR-4 recommendation. (Joomla library classes are autoloaded using a different autoloader – see <tt>libraries/vendor/composer/autoload_static.php</tt>).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can see the namespace prefixes of extensions on the Joomla instance by looking at <tt>administrator/cache/autoload_psr4.php</tt>. (These namespace strings have double backslashes, but in PHP they're the [https://stackoverflow.com/questions/25459197/single-or-double-slash-when-using-php-namespace same strings as those with single backslashes]). This is generated by Joomla looking through the component, module and plugin directories to find each extension's manifest file, and then processing these xml files to extract the <tt><namespace></tt> element – quite a lot of work, which is why it's cached I guess!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider what happens when Joomla wants our admin HelloworldController class. It might have something like
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$classname = 'Robbie\Component\Helloworld\Administrator\Controller\HelloworldController'
if (!class_exists($classname)) { …
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Assuming PHP doesn't already know about this class, the <tt>class_exists</tt> function will result in the classname being passed to the registered autoload function(s). The PSR-4 autoloader will then:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# go through its array of namespaces to try and match <tt>$classname</tt> from the start of the string.
# find 'Robbie\Component\Helloworld\Administrator' as a match
# see that this maps to "administrator/components/com_helloworld/src"
# extract the remainder of the classname: 'Controller\HelloworldController'
# treat this as the path down to the class file
# and so look for "administrator/components/com_helloworld/src/Controller/HelloworldController.php"
# check that in this file there's actually a class with that namespace + class name.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So in this way Joomla can go from a fully qualified class name to find the source code for that class. This makes it easier for us too when the core Joomla code is looking for one of our classes. We still need to know what class it's looking for, but once we know that, we know what we should call our class and where we should save the source code for it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Joomla Library classes===
Originally Joomla's core classes (beginning with a capital J) were global classes. Over the Joomla 3 versions and into Joomla 4 these migrated to their namespaced equivalents, but the original global classnames were still available as Joomla registered them as aliases (in the <tt>libraries/classmap.php</tt> file).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In a Joomla 4 extension you can still use these global classnames, except that in a namespaced file you'd have to prefix the name with a backslash to indicate a global class rather than one in your namespace (eg <tt>\JFactory</tt> instead of <tt>JFactory</tt>).
However it's pretty definite that the aliases will disappear at some stage, so the upgrade to Joomla 4 seems an appropriate opportunity to replace all your component's calls to the global JSomething classes to the namespaced equivalents. This involves adding the appropriate <tt>use</tt> statements, and all this has been done in the tutorial code. A useful mapping between the two can be found [https://github.com/nikosdion/joomlatypehints/blob/main/JoomlaObsoleteClasses.md here], where the new qualified classname can be copied and pasted into a <tt>use</tt> statement in your PHP file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
With reference to the [https://api.joomla.org/ Joomla API Documentation] there are 2 Joomla library namespaces:
* Joomla CMS classes – have namespaces <tt>Joomla\CMS\Something</tt> – are found under <tt>libraries/src/Something</tt>
* Joomla Framework classes – have namespaces <tt>Joomla\Something</tt> – are found under <tt>libraries/vendor/joomla/something/src</tt>
So a big advantage of namespacing is that you can immediately determine from the fully qualified class name in a PHP <tt>use</tt> statement where the source for that class exists in the <tt>libraries</tt> directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
On the other hand class names which aren't fully qualified don't have to be unique, eg <tt>MVCFactory</tt>
* occurs as <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in <tt>libraries/src/Extension/Service/Provider/MVCFactory.php</tt>
* occurs as <tt>Joomla\CMS\MVC\Factory\MVCFactory</tt> in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>
so sometimes you have to be careful to examine the <tt>use</tt> statement to identify the right class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly our FormModel class in <tt>site/src/Model/FormModel.php</tt> can have the same FormModel classname as the Joomla FormModel in <tt>libraries/src/MVC/Model/FormModel.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The API documentation gives the methods available in each of the [https://api.joomla.org/cms-4/namespaces/joomla.html Joomla CMS] and [https://api.joomla.org/framework-2/namespaces/joomla.html Framework] classes, but just be aware that a Joomla CMS class may extend a Framework class, and in this case some methods may not be visible under the Joomla CMS documentation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For example, <tt>$app->setHeader()</tt> which is used to set the HTTP response code is not listed under the [https://api.joomla.org/cms-4/classes/Joomla-CMS-Application-CMSApplication.html CMS Application class API], but is available as a method because it inherits from the Framework class [https://api.joomla.org/framework-2/classes/Joomla-Application-AbstractWebApplication.html AbstractWebApplication].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Vendor Namespaces===
These are also in <tt>libraries/vendor</tt>, eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Psr\Container\ContainerInterface;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
refers to <tt>libraries/vendor/psr/Container/src/ContainerInterface.php</tt>. However there are few of these in the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other File Rearrangements===
With all of the namespaced classes moving under the src directories, the <tt>tmpl</tt> layout files and <tt>form</tt> xml files have been moved out into their own directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Extension and Dispatcher classes ==
===Extension===
In Joomla 3 the point where the Joomla core handed over to your component code was when it ran your <tt>helloworld.php</tt> code; if it was the frontend it ran your site <tt>helloworld.php</tt> code, or if was the backend it ran your admin <tt>helloworld.php</tt> code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the entry point into your component code is your Extension class, both for site and admin, found in <tt>admin/src/Extension/HelloworldComponent.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When the Joomla core application wants to start executing the component code it creates an instance of <tt>HelloworldComponent</tt>, just to get a handle on the component code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly (as described below) other Joomla classes such as Router or Categories need to call certain Helloworld methods (eg custom router functions). In Joomla 3 these methods were written in certain Helper files etc. In Joomla 4 the principle is that the component creates an instance of the <tt>HelloworldComponent</tt> Extension class, and calls the required methods on that instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This Extension class isn't anything like a big container class for the component, it's more like a glue class, providing a way in to the Helloworld component, enabling the Joomla core and other components call the methods which they want to call.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla core wants to execute the component code, the key method it is looking for in your <tt>Extension</tt> instance is <tt>getDispatcher</tt>, and it expects to get back a <tt>Dispatcher</tt> instance. The <tt>HelloworldComponent</tt> extends <tt>MVCComponent</tt>, which in turn extends <tt>Component</tt>, and it is this class which defines <tt>getDispatcher</tt> for us.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Dispatcher===
When Joomla wants to run the Hello World component, it gets the <tt>Dispatcher</tt> instance as described above and then calls the <tt>dispatch</tt> method on it. It is this <tt>dispatch</tt> function which replaces the functionality in the admin and site <tt>helloworld.php</tt> files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's look at the main lines of code in our Joomla 3 admin <tt>helloworld.php</tt> file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="site/views/form/view.html.php">
<syntaxhighlight lang="php">
if (!JFactory::getUser()->authorise('core.manage', 'com_helloworld'))
{
throw new Exception(JText::_('JERROR_ALERTNOAUTHOR'));
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Get an instance of the controller
$controller = JControllerLegacy::getInstance('HelloWorld');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Execute the Request task method
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Redirect if set by the controller
$controller->redirect();
</syntaxhighlight>
</span>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code
* performs some permissions checks
* instantiates the appropriate Helloworld controller
* executes the appropriate method in that controller
* implements any redirect set by the controller
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Model-View-Controller]] for further details of how this works in Joomla 3. The second and third steps used the <tt>task</tt> parameter within the URL query to determine the correct controller class to instantiate and method to call. If no <tt>task</tt> parameter was present then it instantiated the controller in <tt>controller.php</tt> and called the <tt>display</tt> method. Otherwise it instantiated one of the controllers in the <tt>controllers</tt> subfolder (eg <tt>controllers/helloworld.php</tt>) and called the appropriate method on it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>ComponentDispatcher::dispatch</tt> method (in <tt>libraries/src/Dispatcher/ComponentDispatcher.php</tt>) now provides this functionality, but in a nicer way. After checking the permissions it uses the <tt>task</tt> by considering its parts as <tt><controller type>.<method></tt> (taking 'display' as default if either part is missing). It will then pass control to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* an instance of the class <Controller type>Controller
* calling the function <method>
* using the admin or site controller, as appropriate
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In this way the naming of the controllers is consistent - we have DisplayController, HelloworldController and HelloworldsController, all in the same folder.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Dispatcher class can thus be considered as providing some 'routing - execution' functionality, enabling us to find the right controller and function within that controller, and it is cleaner to have this in a separate class rather than in the <tt>JControllerLegacy</tt> class as it was in Joomla 3.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Since the Hello World tutorial uses the standard Joomla pattern for selecting the class and method based on the <tt>task</tt> and has the same permissions checks, we can use the <tt>dispatch</tt> code as it stands in <tt>ComponentDispatcher</tt>, and don't need to define a special class of our own.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Factory classes ==
In Joomla 3 many classes had static <tt>getInstance</tt> methods which returned an instance of that class, configured with the parameters passed to <tt>getInstance</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the <tt>getInstance</tt> methods have been deprecated in favour of using Factory classes. The preferred mechanism is now to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* get an instance of the appropriate Factory class (how we do that is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below)
* call the <tt>createSomething()</tt> method of the Factory class with relevant parameter values to generate an instance of the Something class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===MVC Factory===
In this section the <tt>MVCFactory</tt> class refers to the one in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory class will instantiate Controller, View, Model and Table instances on our behalf, and it does this by generating the classname of the class and then calling <tt>new</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The way it works is as follows:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Each component gets an individual MVCFactory instance which is constructed passing the component's namespace as a parameter (so in our case 'Robbie\Component\Helloworld'). (How this MVCFactory instance is created is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below).
# The MVCFactory createController / createView / createModel / createTable function is then called, passing the name of the Controller / Model / View / Table and the prefix (which specifies whether the administrator or site class is required).
# The create function forms the classname from this data and calls <tt>new</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory create functions just form the classname from the parameters they're passed. The intelligence for working out what name and prefix should be used to form the appropriate classes for an incoming HTTP request is
* in the dispatcher code for defining the controller to use
* in the controller for the view and model
* in the model for the table
and, for example, the names of the classes created for a request with URL query <tt>?option=com_helloworld&view=viewname</tt> and no <tt>task</tt> parameter will be
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<namespace>\Controller\DisplayController
<namespace>\View\Viewname\HtmlView
<namespace>\Model\ViewnameModel
<namespace>\Table\ViewnameTable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you need an alternative name then you can override the appropriate getView, getModel or getTable function – as for example was done in the [[J3.x:Developing an MVC Component/Adding Custom Fields#Front-end_Form|Adding Custom Fields step, frontend Form section]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So from the outside this is pretty much the same as in Joomla 3. However, note that the <tt>$prefix</tt> parameter in calls to <tt>getModel</tt> etc is subtly different
* in Joomla 3 this referred to a prefix to be applied to the classname – in the tutorial code we used 'HelloWorldTable' as the prefix part of the 'HelloWorldTableHelloWorld' classname.
* in Joomla 4 this refers to a prefix higher up the classname path, and should be set to either 'Site' or 'Administrator' (the capital letter at the start is optional), depending on whether you want the class under 'Robbie\Component\Helloworld\Site' or 'Robbie\Component\Helloworld\Administrator'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVC Factory class is now the Joomla recommended way to create the controller, view, model and table classes, by using the eg <tt>getModel()</tt> method, and the use of <tt>getInstance()</tt> for these classes is now deprecated. However, the use of these functions is restricted:
* in the controller class you can call <tt>$this->getView($viewname, $viewtype, $prefix, $config)</tt> to create a view and <tt>$this->getModel($modelname, $prefix, $config)</tt> to create a model.
* in the view class you can call <tt>$this->getModel($modelname)</tt>, but only for models which the controller has previously defined using <tt>$view->setModel($modelname, $default)</tt>. It doesn't create a new model instance.
* in the model class you can call <tt>$this->getTable($tableclass, $prefix, $options)</tt> to create a table instance. Controllers and views can access the table classes in this way, by going via a model.
These restrictions do have an impact on moving away from using <tt>getInstance()</tt>, and indeed in Joomla 4.2.6 you will still find several <tt>getInstance()</tt> calls within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Factory Classes===
Several other Factory classes have been introduced in Joomla 4, enabling you to get instances of core classes such as Form, User, CacheController, etc, usually by calling a createSomething function on the Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Associated with the Factory class is a FactoryInterface, a PHP Interface which specifies the key functions which the Factory class must implement. For example, with <tt>libraries/src/Categories</tt> we have:
* CategoryFactoryInterface – which specifies the <tt>createCategory</tt> function
* CategoryFactory implements CategoryFactoryInterface – which provides the <tt>createCategory</tt> function.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Dependency Injection ==
===Overview===
The DI container is one of the significant new additions to Joomla 4. It's basically a repository of key-value pairs where:
* the key is a string which is the name of a class or interface
* the value is an instance of the relevant class, or a function that returns an instance of that class.
You put things into the container using <tt>set()</tt> passing:
* the class name or interface name
* a function which returns an instance of the class (or an instance of the class)
* a boolean defining whether the class instance may be shared or not
* a boolean defining whether this entry into the DI container is protected or not (an error will be raised if you try to overwrite a protected entry by calling <tt>set()</tt> again using the same key).
The function <tt>share()</tt> is basically the same as <tt>set()</tt> with the <tt>shared</tt> boolean set to true.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You get things out of the container by calling <tt>get()</tt> passing the key of the resource you want. The container will
* find the key in the container
* if the value isn't already a class instance, then it will run the associated function to generate an instance of the class
* if the resource is shared, it will store the class instance, so that on subsequent invocations of <tt>get()</tt> it can just return the instance
* return the class instance to you
You can also define aliases for each key in the container, which means that you call <tt>get()</tt> passing either the key or an alias of the key.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The DI container is initialised in <tt>library/src/Factory.php createContainer()</tt> which results in the <tt>register()</tt> function being called in each of the class files in <tt>libraries/src/Service/Provider</tt>. By looking through those files you can see what gets put into the DI container upon initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===JConfig Example===
Let's consider the example of JConfig which holds the system global configuration. If you look inside <tt>libraries/src/Service/Provider/Config.php</tt> then you'll see the <tt>register()</tt> function and that it stores in the DI container a resource with:
* key = 'JConfig'
* value = an anonymous function - which loads what's in <tt>configuration.php</tt> into a <tt>Registry</tt> object, and returns it
* shared flag = true (because the <tt>share()</tt> function is used)
* protected flag = true
Then when you do
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$config = $container->get('JConfig');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will run the anonymous function and return the Registry object to you. As the 'shared' boolean is set it will also store a copy of the class instance locally in the container to be returned on subsequent calls of <tt>get('JConfig')</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Justification===
What's the point of all this?
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The advantage of dependency injection is that it allows classes to be easily mocked for testing. The file <tt>libraries/src/Service/Provider/Config.php</tt> can be replaced to return to a DI container <tt>get()</tt> call a mock class instead of the usual <tt>JConfig</tt>. This is in comparison to Joomla 3 where <tt>Factory::getConfig()</tt> code directly reads the <tt>configuration.php</tt> into a Registry structure and returns it – which makes it harder to mock.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The [https://api.joomla.org/cms-4/classes/Joomla-CMS-Factory.html Factory API] has several functions which are marked as deprecated with advice to get the object from the DI container instead.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Several of the other Factory classes (eg Form, Language, Menu, User) are in the DI container – so that we can get an instance of them via eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Factory::getContainer()->get('Joomla\CMS\Toolbar\ToolbarFactoryInterface')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to get a Toolbar instance. However, this only works for singleton classes which aren't specific to the needs of a particular extension. We'll see shortly how to make it work for class instances which need to be specific to a component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As indicated above, Joomla is moving away from using the class static <tt>getInstance()</tt> functions. We can see now that this is not only because it's more pure from an object oriented perspective. But also creating class instances from the DI container, or from Factory objects which are obtained from the DI container, builds in the dependency injection which allows classes to be more easily mocked, and hence more easily tested.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==services/provider.php==
We're now finally in a good position to understand what's happening in our services/provider.php file, and we'll explore this by walking through what happens whenever this line in libraries/src/Component/ComponentHelper.php <tt>renderComponent</tt> is run:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is run whenever Joomla has worked out which component is to be run on the requested web page, and it wants to run that component to capture its output.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 1 Create Child DI Container===
Joomla first creates another DI container (initially empty) just for this component, and links it to the main DI container via a parent field in the child DI container structure.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Now whenever <tt>set()</tt> is called on this DI container the key-value pair is inserted into the child container. Whenever <tt>get()</tt> is called on it, the resource is obtained from the child container, but if it's not found there then the parent container is searched also.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 2 Run register() in provider.php===
Next we encounter these lines (in <tt>libraries/src/Extension/ExtensionManagerTrait.php</tt>), where <tt>$path</tt> contains the path of our helloworld admin/services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$provider = require_once $path;
// Check if the extension supports the service provider interface
if ($provider instanceof ServiceProviderInterface) {
$provider->register($container);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here we see 3 things:
# our provider.php should return some object (so that <tt>$provider</tt> gets set to something)
# what is returned should implement ServiceProviderInterface (you can see in <tt>libraries/vendor/joomla/di/src/ServiceProviderInterface.php</tt> what is expected)
# the code then runs the <tt>register</tt> function on that object, passing as a parameter the child DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider a minimal version of our provider.php file. This would actually support steps in the Joomla 3 tutorial up to and including the [[J3.x:Developing an MVC Component/Adding AJAX|Adding Ajax step]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {

public function register(Container $container): void
{
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
}
};
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As you can see from the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
this file does indeed return something – it returns an instance of an anonymous class, one that implements <tt>ServiceProviderInterface</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it's not sufficient to just provide the <tt>register</tt> function in the class, we also need to explicity state that the class implements <tt>ServiceProviderInterface</tt>. This now happens in several places in Joomla, so if you're debugging your component and wondering why a function you expect to be called isn't being called, then check to make sure that you don't have to explicitly add the appropriate <tt>implements <Interface></tt> clause to your class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Next we look at the 3 lines in the <tt>register</tt> function
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3a Registering our MVC Factory===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here our <tt>MVCFactory</tt> refers to <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in libraries/src/Extension/Service/Provider/MVCFactory.php, and you should have a look at this file. This is a file similar to our provider.php file, but it's a named class, and it doesn't return anything. When we do:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
new MVCFactory('\\Robbie\\Component\\Helloworld')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it creates an instance of this class, and in the constructor it stores locally in <tt>$this->namespace</tt> our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>registerServiceProvider</tt> function then calls the <tt>register</tt> function of this instance, which runs (in its minimalist form):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
MVCFactoryInterface::class,
function (Container $container) {
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
return $factory;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So what gets entered into our child DI container is a key-value pair with:
* key = MVCFactoryInterface::class (this is just a shorthand form to obtain a string of the fully qualified name – ie 'Joomla\CMS\MVC\Factory\MVCFactoryInterface')
* value = a function which returns an instance of <tt>\Joomla\CMS\MVC\Factory\MVCFactory</tt>.
This is our MVCFactory class which generates our Controllers, Views, Models and Tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Notice that we're passing our namespace as a parameter <tt>$this->namespace</tt>. Because this function is a closure, this variable will still be available when we run this function later, and when the MVCFactory class is instantiated the namespace will be passed into the constructor, stored locally, and then subsequently used to form the fully qualified names of our Controllers, View, etc. So this is how we get instantiated the MVCFactory class which is specific to our component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3b Registering the Dispatcher Factory===
Careful: ComponentDispatcherFactory refers to two different classes here!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This ComponentDispatcherFactory is Joomla\CMS\Extension\Service\Provider\ComponentDispatcherFactory in libraries/src/Extension/Service/Provider/ComponentDispatcherFactory.php. Similar to the above, the ComponentDispatcherFactory service provider class stores locally our namespace, and then when <tt>register</tt> is called it executes:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentDispatcherFactoryInterface::class,
function (Container $container) {
return new \Joomla\CMS\Dispatcher\ComponentDispatcherFactory($this->namespace,$container->get(MVCFactoryInterface::class));
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so a second entry is added to the child DI container with:
* key = ComponentDispatcherFactoryInterface::class
* value = a function which returns an instance of the ComponentDispatcherFactory (the other ComponentDispatcherFactory class!), where the class constructor will be passed the namespace ('\\Robbie\\Component\\Helloworld') and an MVCFactory instance, retrieved from the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that the code
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->get(MVCFactoryInterface::class)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
will get from the container an entry with key = 'Joomla\CMS\MVC\Factory\MVCFactoryInterface' – which is what we entered into the container in step 3a – and will run the function associated with this key, and then return the object which this function returns. This returned object will be an instance of '\Joomla\CMS\MVC\Factory\MVCFactory', constructed using our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3c Including the Extension===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will put into the child DI container a key-value pair with
* key = ComponentInterface::class
* value = the function which will create an instance of our <tt>HelloworldComponent</tt> (ie our Extension class), and pass into the constructor an instance of the ComponentDispatcherFactory class, retrieving what was entered into the child DI container in Step 3b.
It will call <tt>$container->get(MVCFactoryInterface::class)</tt>, getting an MVC Factory instance from what was entered into the DI container in Step 3a.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It will then associate our component with this MVC Factory instance via the <tt>setMVCFactory</tt> call. Significantly this will then allow our component to access this instance later, via a call to <tt>getMVCFactory</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3 Summary===
We have now got 3 entries in our child DI container, keyed by
* key = MVCFactoryInterface::class, value is a function returning an MVCFactory instance
* key = ComponentDispatcherFactoryInterface::class, value is a function returning a ComponentDispatcherFactory instance
* key = ComponentInterface::class, value is a function returning our HelloworldComponent, an instance of our Extension class.
The important aspect is that these entries are all aware of our namespace '\Robbie\Component\Helloworld' and will return instances of these classes which are specific to our Helloworld component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 4 Retrieving from the DI Container===
Joomla will then execute the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $container->get($type);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
where <tt>$type</tt> contains 'Joomla\CMS\Extension\ComponentInterface'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This starts the process of retrieving from the DI container the 3 entries which we put in, and will run our code in services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We end up with a HelloworldComponent instance, which has:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. a ComponentDispatcherFactory instance passed into the constructor, and which is saved locally by the constructor code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function __construct(ComponentDispatcherFactoryInterface $dispatcherFactory)
{
$this->dispatcherFactory = $dispatcherFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This code is in libraries/src/Extension/Component.php, in the class which our HelloworldComponent extends, via the class MVCComponent).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. an MVC Factory instance, stored by the HelloworldComponent <tt>setMVCFactory</tt> call
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 5 Call boot() on our Component===
Joomla calls:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
if ($extension instanceof BootableExtensionInterface) {
$extension->boot($container);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will call <tt>boot</tt> within our HelloworldComponent, and allows us to perform some initialisation within our component. We'll return to this later, in the section on [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#HTML_Snippets|HTML snippets]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note again that Joomla checks that our HelloworldComponent class implements BootableExtensionInterface before calling <tt>boot</tt>. It's not sufficient to just provide the <tt>boot</tt> function, we have to explicitly declare that our HelloworldComponent implements the interface.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 6 Get the Dispatcher===
Returning to our key line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
we have now accomplished the first part <tt>bootComponent($option)</tt>, and this has returned our HelloworldComponent instance. Now we call <tt>getDispatcher($app)</tt> on this instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This code is also in libraries/src/Extension/Component.php, in the Component class which our HelloworldComponent extends:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function getDispatcher(CMSApplicationInterface $application): DispatcherInterface
{
return $this->dispatcherFactory->createDispatcher($application);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We call <tt>createDispatcher</tt> on our ComponentDispatcherFactory class instance which we saved in Step 4. This code is in libraries/src/Dispatcher/ComponentDispatcherFactory.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createDispatcher(CMSApplicationInterface $application, Input $input = null): DispatcherInterface
{
$name = ucfirst($application->getName());

$className = '\\' . trim($this->namespace, '\\') . '\\' . $name . '\\Dispatcher\\Dispatcher';

if (!class_exists($className)) {
if ($application->isClient('api')) {
$className = ApiDispatcher::class;
} else {
$className = ComponentDispatcher::class;
}
}

return new $className($application, $input ?: $application->input, $this->mvcFactory);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code checks if we have our own Dispatcher class (our Helloworld tutorial doesn't, but <tt>com_users</tt> for example has its own). So it creates a <tt>ComponentDispatcher</tt> instance, and passes into its constructor the MVC Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that this ComponentDispatcherFactory instance is what was instantiated when it was retrieved from our child DI Container (from being inserted in step 3b), and hence it already knows about our namespace, and has a pointer to our MVCFactory class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 7 call dispatch()===
This is the final aspect to our line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We're now back to what was described in the Dispatcher section above, except that now we can see that this Dispatcher instance has a pointer to our MVC Factory instance (which knows about our namespace prefix), so when the Dispatcher code wants to create a Controller it can use that MVC Factory instance to instantiate it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's been a long and tortuous journey to get here, but the significant thing is that all of our key class instances have been obtained via the DI Container. If we want to mock out any of those classes for testing then all we need to do is replace the relevant services/provider file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Javascript and the Web Asset Manager ==
The web asset manager has been introduced in Joomla 4 and is well documented [[J4.x:Web_Assets|here]]. It provides a much-improved means of managing JS and CSS resources, and a framework for handling their dependencies.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Component Javascript and CSS files should now be stored in the <tt>media</tt> folder, and the Web Asset Manager used to register them and output them on specific web pages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following assets have been registered in the tutorial <tt>joomla.asset.json</tt>, and you should have a look at that file now.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.validate-greeting===
This is the code for client validation of the helloworld greeting field using a regex, and it is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it is dependent upon jQuery and the Joomla <tt>form.validator</tt> script, so those both get included as dependencies.
If we didn't have specific validation on our form then we would need to include explicitly the <tt>form.validator</tt> script in order for the basic Joomla field validation to be included, eg in the tmpl file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->document->getWebAssetManager()->useScript('form.validate');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that this requires us to have a <tt>class="form-validate"</tt> on the </tt><form></tt> html element.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.fix-permissions-ajax-call===
This is the code which copies the value from the greeting field into the title field, so that the Ajax calls setting the permissions work correctly. The js code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.enable-tooltips===
This is the code which enables bootstrap tooltips to operate, including allowing them to include html code. It's used to display the image as a tooltip within the admin <tt>helloworlds</tt> view.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.openstreetmap===
This is defined as a preset, comprising the helloworld js and css code for the map display, as well as the dependency named 'com_helloworld.openlayers' relating to the openlayers CSS and js code. The code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.admin-helloworlds-modal===
This is the js code for selecting an individual helloworld record within a modal, and passing its details to the form in the main window. Its code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===submitbutton.js===
In the Joomla 3 code we introduced in [[Special:MyLanguage/J3.2:Developing_an_MVC_Component/Adding_verifications|Adding Verifications]] a js file which controlled when the form was submitted. It differentiated between buttons such as <tt>Save</tt> (which submitted the form) and <tt>Cancel</tt> (which didn't).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 there is a more sophisticated version of <tt>Joomla.submitbutton</tt> (found in media/system/js/core.js) which uses the CSS classes which the Toolbar functionality sets on the buttons to determine whether the form should be submitted or not. And you can override whether the validation is performed by adding a third parameter to the <tt>submitbutton</tt> js call. For example, to avoid validation being performed when a button is clicked you can set on the button element:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
onclick="Joomla.submitbutton('controller.method', '', false)"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As this is sufficient for what we need in the tutorial, the custom <tt>submitbutton.js</tt> has been removed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Interaction with other components ==
The way that Joomla interacts with components has changed in Joomla 4. In general the Joomla functionality will boot the component using something like:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $app->bootComponent($option);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and in our case this will return an instance of the <tt>HelloworldComponent</tt> class. It will then try to call certain methods on our extension object, as described below.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_categories===
In the backend the helloworld functionality can display to the administrator
* the view of the helloworld messages
* the view of the helloworld categories
The categories view is generated by <tt>com_categories</tt>, and in Joomla 4 these component categories views display the number of component records there are for each of the possible published status values. To do this the categories component executes the following code (in administrator/components/com_categories/src/Model/CategoriesModel.php):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof CategoryServiceInterface) {
$component->countItems($items, $section);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So our HelloworldComponent must:
* declare that it implements <tt>CategoryServiceInterface</tt>
* provide an implementation of <tt>countItems</tt>
We provide <tt>countItems</tt> by using a trait in libraries/src/Categories/CategoryServiceTrait.php, which (with the assistance of a helper function) does the query on our behalf. We just need to tell it:
* the name of our table – in the callback <tt>getTableNameForSection</tt>
* the database field in which we hold the published status – in <tt>getStateColumnForSection</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_associations===
Remember that <tt>com_associations</tt> is the component which is run whenever you click on Multilingual Associations in the admin backend.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Under Joomla 3 we provided an associations helper file as described in [[J3.x:Multilingual Associations/Developers|Multilingual Associations/Developers]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the helper file remains basically the same, but <tt>com_associations</tt> primarily tries to find the helper file via the extension class; here's the code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($extensionName);
if ($component instanceof AssociationServiceInterface) {
return $component->getAssociationsExtension();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's expecting that:
* the extension (HelloworldComponent in our case) implements <tt>AssociationServiceInterface</tt>
* its <tt>getAssociationsExtension</tt> method returns the helper class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The easiest thing would be just to code <tt>getAssociationsMethod</tt> and get it to return <tt>new AssociationsHelper</tt>. However, we follow the Joomla 4 principle of putting key classes into the Dependency Injection container, and retrieving them later, by having the following code in our services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(AssociationExtensionInterface::class, new AssociationsHelper());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The above line puts a key-value pair into our child DI container
* key = 'Joomla\CMS\Association\AssociationExtensionInterface'
* value is an instance of our <tt>AssociationsHelper</tt> class.
We then retrieve it later and use the setter:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setAssociationExtension($container->get(AssociationExtensionInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so that whenever
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getAssociationExtension()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
is called it returns the <tt>AssociationsHelper</tt> class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_fields===
<tt>com_fields</tt> is the component which is run when an administrator clicks on the Fields or Field Groups menuitem within the backend, and this functionality was included in the [[J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Adding Custom Fields]] tutorial step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>com_fields</tt> component stores the custom fields and field groups for all components in the database tables <tt>#__fields</tt> and <tt>#__fields_groups</tt>, and these tables are partitioned into "sections", one section per component. For our helloworld component the section is named "helloworld".
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within the section we have 2 "contexts" – one for the helloworld messages (called "com_helloworld.helloworld") and one for the helloworld categories (called "com_helloworld.categories"). This enables us to define custom fields for both our helloworld records and helloworld category records.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When <tt>com_fields</tt> runs it checks both the section and contexts at various times. For example, when an admin selects Helloworld / Fields on the backend then <tt>com_fields</tt> checks the section which was defined in the menuitem in the manifest file (see [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Sidebar|below]]). Here's the code in administrator/components/com_fields/src/Helpers/FieldsHelper <tt>extract</tt> function:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
$newSection = $component->validateSection($parts[1], $item);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And when <tt>com_fields</tt> wants to display the little dropdown menu of contexts (to allow the administrator to set custom fields on either helloworld items or categories) it calls (in administrator/components/com_fields/src/Fields/FieldcontextsField.php <tt>getOptions()</tt>):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
return $component->getContexts();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So it's clear that our component extension class must :
* implement <tt>FieldsServiceInterface</tt>
* provide the <tt>validateSection</tt> and <tt>getContexts</tt> methods
So in upgrading to Joomla 4 we've just moved those two methods from the helper file to the extension class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Router===
The Joomla router will access our custom router code:
* whenever it wants to parse an SEF route which it has identified as belonging to <tt>com_helloworld</tt>
* whenever it wants to build an SEF route from a call to <tt>Route::_()</tt> where the option = "com_helloworld".
To find our custom router it will:
* boot the <tt>com_helloworld</tt> extension
* check that the extension implements <tt>RouterServiceInterface</tt>
* call <tt>createRouter</tt> on our extension instance
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In our services/provider.php file we have (careful again - 2 different RouterFactory classes!):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new RouterFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which from libraries/src/Extension/Service/Provider/RouterFactory.php puts into our child DI container an entry with:
* key = "Joomla\CMS\Component\Router\RouterFactoryInterface"
* value is a <tt>\Joomla\CMS\Component\Router\RouterFactory</tt> instance, constructed with our namespace
We then retrieve this in the line in our services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setRouterFactory($container->get(RouterFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And then within our extension class we have
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use RouterServiceTrait;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which includes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function setRouterFactory(RouterFactoryInterface $routerFactory)
{
$this->routerFactory = $routerFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which stores the <tt>routerFactory</tt> locally and
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return $this->routerFactory->createRouter($application, $menu);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which provides our extension's <tt>createRouter</tt> call that the Joomla Router expects.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>routerFactory::createRouter</tt> method is in libraries/src/Component/Router/RouterFactory.php. It looks for a class in our site namespace </tt>Robbie\Component\Helloworld\Site\Service\Router</tt> which is in our site/src/Service/Router.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
At this stage we have a choice, we can either:
* provide a traditional custom router, with the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions, or
* use the more modern <tt>RouterView</tt> mechanism.
By default in the upgraded tutorial code the Router View option has been coded in the Router.php file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====RouterView====
In the <tt>RouterView</tt> case the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions are in the <tt>RouterView</tt> class which we extend, and we provide
* a constructor with router view configuration
* methods <tt>getHelloworldId</tt> and <tt>getCategoryId</tt> which are used to obtain from the SEF segment the <tt>id=</tt> and <tt>catid=</tt> parts of the internal URL
* methods <tt>getHelloworldSegment</tt> and <tt>getCategorySegment</tt> which are used to generate segments for the SEF URLs based on the <tt>id=</tt> and <tt>catid=</tt> parts within the <tt>Route::_()</tt> parameter.
Unfortunately there doesn't seem to be a good guide to configuring the RouterView class. There is some documentation available [https://www.dionysopoulos.me/book/com-router-routerview.html here].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the helloworld tutorial we have 3 views
* a view which displays a single helloworld record
* a view which displays a single helloworld category, and the helloworld records associated with it
* a view which displays the frontend form
So we need 3 Router Views associated with these.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'form' view doesn't have an associated id or catid so it's just a fixed URL, and the router just has to convert between the alias of the form menuitem and the Itemid / view parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'category' view has an associated id (of the category record), and an SEF URL will use the category path down the Categories Nested Set table structure, hence <tt>setNestable()</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'helloworld' view has an associated id (of the helloworld record), and in an SEF URL in the category view the helloworld record alias is added to the category path (hence <tt>setParent()</tt>). But although the helloworld records use a Nested Table structure in the database, the URLs just include the alias of the single record, and so <tt>setNestable()</tt> is not used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There doesn't seem to be a way to configure an additional SEF URL scheme which just displays a helloworld segment, without a category segment.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====Traditional Router====
To use the traditional router in the tutorial code you should uncomment the function in the extension class:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return new TraditionalRouter($application, $menu, $this->categoryFactory, $this->getDatabase());
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will cause the code in site/src/Service/TraditionalRouter.php to be used. However, changes in the Joomla 4 router mean that the interaction between it and the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> methods have changed. This requires significant changes to the <tt>preprocess</tt> and <tt>build</tt> methods, but only a minor change to <tt>parse</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. Previously Joomla injected into the <tt>$query</tt> parameters the <tt>Itemid</tt> of the active menuitem (ie the id of the menuitem the user is currently on). This meant that we had to change the <tt>Itemid</tt> for links generated by the Language Switcher module (which generates the flags for switching between languages), and these links being associated with a different language would obviously use a different <tt>Itemid</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 you get an <tt>Itemid</tt> in the <tt>$query</tt> parameters only if you specified an <tt>Itemid</tt> in the <tt>Route::_()</tt> call. For others you have to work out which menuitem to use yourself, by using the Joomla menu/menuitems API to find details of the configured menuitems, and work out which to use based on the other <tt>$query</tt> parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You do this in the <tt>preprocess</tt> method, and then the <tt>Itemid</tt> you set will be passed in the <tt>$query</tt> parameters to the <tt>build</tt> method.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. In some instances the <tt>Route::_()</tt> URL you're generating matches exactly one of the configured menuitems on the site. In this case the <tt>$query</tt> parameters will match those in the menuitem <tt>"query"</tt> array, and you have to remove explicitly remove the 'view', 'id' and 'catid' parameters so that they don't appear as URL query parameters after the normal SEF URL of the menuitem.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
3. The custom router will be used to build the URLs for the helloworld menuitems shown in menus on the page. For these the <tt>$query</tt> parameters will have the view / id / catid associated with those menuitems. Note that even if you remove these in your <tt>preprocess</tt> method, Joomla will inject them again into the <tt>$query</tt> array when it's passed to your <tt>build</tt> method, so you'll have to remove them again there!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
4. In the <tt>parse</tt> method you now have to unset the <tt>$segments</tt>, or else Joomla will return an HTTP 404 (page not found). Otherwise <tt>parse</tt> works as before.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
5. I've implemented <tt>build</tt> only for when Multilanguage is enabled on the site. If it's not enabled an empty <tt>$segments</tt> array is just returned, without doing unset on any of the <tt>$query</tt> parameters, so these will appear as URL parameters after the SEF URL. Also it's not coded properly to deal with items which have language set to <tt>*</tt>. These include helloworld records, categories or menuitems (eg the helloworld form).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that the <tt>categoryFactory</tt> is also now passed to the router. This is so that it can be used instead of <tt>Categories::getInstance()</tt> to get access to the Categories API calls.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_tags===
Whenever we setup a Tags Menu Item Type which displays items having a given tag or tags, then <tt>com_tags</tt> displays those items as links, and uses route helper functions to generate the URL parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The route helpers <tt>com_tags</tt> expects to find loaded into the data of the <tt>#__content_types</tt> table, in the router field, and these have been set to:
* For links to helloworld items: 'HelloworldHelperRoute::getHelloworldRoute'
* For links to helloworld categories: 'HelloworldHelperRoute::getCategoryRoute'
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, <tt>com_tags</tt> doesn't boot the helloworld extension to get access to these, but rather seeks to find them in site/helpers/route.php, so that's where they continue to be.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(We also had a <tt>getCategoryRoute</tt> which was used by <tt>com_categories</tt> in administrator/components/com_categories/src/Helper/CategoryAssociationHelper. When a category was displayed on the frontend then the Language Switcher module (now Language Filter) used this function to generate the links to the Associated Categories. Our <tt>getCategoryRoute</tt> previously was necessary to insert the <tt>lang=<language tag></tt> parameter into the link URL, but since [https://github.com/joomla/joomla-cms/pull/39358 this change] the calling function inserts the <tt>lang</tt> parameter itself, so our <tt>getCategoryRoute</tt> function for this purposes is superfluous.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Deprecated APIs ==
With Joomla 4 there are a number of methods which are deprecated, with a view to removing them in Joomla 5.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Factory Methods===
Many of the <tt>Factory</tt> methods for getting singleton classes have been deprecated in favour of getting these classes via the DI container, and it appears that only class instances which should be obtained via Factory methods are:
* the Application – <tt>Factory::getApplication()</tt>
* the DI container – <tt>Factory::getContainer()</tt>
Here is a list of what has been changed in the tutorial code. Note that with some calls there are variants available, through the aliases defined in the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDbo'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\Database\DatabaseInterface;
...
$db = Factory::getContainer()->get(DatabaseInterface::class);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, in many classes the database instance is more easily (and efficiently) returned via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$db = $this->getDatabase();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is available in Model classes, custom field definitions, etc.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getUser();'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get the current user use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = Factory::getApplication()->getIdentity()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get a different user (whose id you know):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\User\UserFactoryInterface;
...
$user = Factory::getContainer()->get(UserFactoryInterface::class)->loadUserById($userid);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within models which extend Joomla\CMS\MVC\Model\BaseDatabaseModel and views which extend Joomla\CMS\MVC\View\HtmlView you can also use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = $this->getCurrentUser()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDocument()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication()->getDocument()</tt>, or within a View you can use <tt>$this->document</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getConfig()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Two options have been used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->getConfig()</tt> – returns a Registry object containing all the configuration values
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->get('access')</tt> – returns the value of the 'access' configuration parameter
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getLanguage()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication->getLanguage()</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JFactory::getCache('com_example', <type>)'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Cache\CacheControllerFactoryInterface;
...
Factory::getContainer()->get(CacheControllerFactoryInterface::class)->createCacheController(<type>)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated getInstance Methods===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general <tt>getInstance()</tt> calls have been deprecated in favour of obtaining the instance, either via a factory class or via the DI container. For example, within a controller you can use <tt>getModel()</tt> repeatedly to get different models (passing the relevant model names), which results in the MVCFactory class creating the Model classes.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there are currently some problems with replacing some getInstance calls. I expect that the Joomla team will resolve these issues over the course of the Joomla 4 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Categories::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is deprecated with a notice: "Use the ComponentInterface to get the categories". This means that we should get the category factory instance via the DI container. This is done in our services/provider.php by the lines:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Extension\Service\Provider\CategoryFactory;
...
$container->registerServiceProvider(new CategoryFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to put into our child DI container the closure which will create a Joomla\CMS\Categories\CategoryFactory instance, constructed with our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when our HelloworldComponent (Extension) instance is created:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We can then use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getCategoryFactory()->createCategory();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to create our Categories object, and in this way get access to the Categories APIs.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This createCategory method creates the instance by looking for the \\Site\\Service\\Category class within our namespace. The constructor in our class sets our extension ('com_helloworld') and table ('#__helloworld') and calls the parent Categories constructor with these options).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this means that the section of our code where we want to use the Categories APIs must have a pointer to a CategoryFactory instance. In the tutorial code for Joomla 3 there are 2 places where <tt>Categories::getInstance</tt> is used:
* in the custom router code, to handle building and parsing of the category parts of the SEF URL
* in the site category model, where the Categories APIs are used to obtain details of categories to display on the page.
For the custom router code, the CategoryFactory instance is passed as a parameter to the TraditionalRouter constructor so that it can be used there.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, the site category model is instantiated by the MVCFactory instance, and it doesn't make available a CategoryFactory instance. So in this category model the calls to <tt>Categories::getInstance()</tt> have been left, and you can still find a number of calls to <tt>Categories::getInstance</tt> within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Categories::getInstance()</tt> itself solves the problem of access to a CategoryFactory instance by rebooting our component again to get a pointer to our Extension instance, and thus to the category factory instance. However, this involves a lot of work, so <tt>getInstance</tt> caches locally the Categories instances and just returns one of them if it can.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Pushing the CategoryFactory to the model'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there is a way to get access to the CategoryFactory instance, by defining your own MVCFactory class, and pushing the instance down through it to the model. Here's how you can go about it:
* Define your own SuperMVCFactory class, which extends the Joomla Joomla\CMS\MVC\Factory\MVCFactory class, but which has a means of storing a CategoryFactory instance. Use the CategoryServiceTrait in libraries/src/Categories/CategoryServiceTrait.php
* Create your own version of the file libraries/src/Extension/Service/Provider/MVCFactory.php, which is the 'provider.php' like file for MVCFactory, but change it so that:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
becomes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new <namespace>\SuperMVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and include
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla creates a model such as CategoryModel it passes in its constructor the MVCFactory instance (so that the model can call createTable on it), so you can access it via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will return your SuperMVCFactory instance. So in this way within the model you can access the CategoryFactory, and use it to create the Categories instance via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()->getCategory() (from the CategoryServiceTrait)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you can get this working you can congratulate yourself on a good understanding of Joomla namespacing and dependency injection! A similar approach to address a similar problem is described [https://www.dionysopoulos.me/book/com-router-push-dependencies.html here]. If you get stuck you can always view the solution by viewing the github tutorial code selecting the branch [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial/tree/push-category-factory-to-mvc push-category-factory-to-mvc].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Table::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There are a couple of calls to <tt>Table::getInstance()</tt> within admin/src/Helper/AssociationsHelper.php in <tt>getItem()</tt>:
* <tt>Table::getInstance('Helloworld', 'Robbie\\Component\\Helloworld\\Administrator\\Table\\')</tt> to get an instance of our HelloworldTable class.
* <tt>Table::getInstance('Category')</tt> to get an instance of the Category table in libraries/src/Table/Category.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We could actually arrange for the AssociationsHelper class to get injected with the MVCFactory instance, so that the HelloworldTable class could be instantiated by it. However, we couldn't use the helloworld MVCFactory instance to create the Category table instance, as it's not in the helloworld namespace, and our MVCFactory instance creates table instances within our namespace only.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Toolbar::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The tutorial code uses <tt>Toolbar::getInstance()</tt> to get a Toolbar instance onto which it can attach the batch button in the helloworlds form. The Toolbar API documentation seems to suggest that we should replace
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Toolbar::getInstance('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
with
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this currently won't work. The problem is that all the other Joomla code uses <tt>getInstance('toolbar')</tt> to access the Toolbar class, including the code in administrator/modules/mod_toolbar/mod_toolbar.php which renders the toolbar. The <tt>getInstance</tt> method keeps track of the Toolbar instances in a local static variable <tt>$instances</tt>, and returns the same Toolbar instance on repeated invocations.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you use the second approach above you will get a Toolbar instance, but it won't be the same Toolbar instance as is stored in the <tt>$instances</tt> variable. It won't then be picked up by the Toolbar module, and so won't be rendered on the form.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Error Handling===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead of
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
JError::raiseError(500, implode('<br />', $errors));
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
you should throw an exception, using or extending one of the standard [https://www.php.net/manual/en/spl.exceptions.php PHP exceptions], eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
throw new \Exception(implode("\n", $errors), 500);
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===jimport===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
jimport is no longer necessary in order to get access to Path or File classes. All of the Joomla classes are found by the autoloader.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Methods related to Javascript===
'''JHtml::_('behavior.framework');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general, the use of JHtml::_('behavior.xxx') is now obsolete, and calls using this have been removed in the tutorial code. The 'behavior.framework' call referred to including jQuery. Where jQuery is necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.formvalidator');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by the <tt>form.validate</tt> javascript asset, and where necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It can also be included directly using the web asset manager:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$wa->useScript('form.validate')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.tooltip')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This no longer exists, and tooltips don't seem to be enabled by default in Joomla 4. This is replaced by the code in media/js/enable-tooltips.js.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('formbehavior.chosen')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The chosen js library seems to be no longer used, and using it will cause formatting issues if you include it in your tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''sortable'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The sortable js library provided the ability in the helloworlds view to drag rows up and down to change the ordering of the records. This has been replaced in Joomla 4 by the draggable library. To enable it you have to set:
* <tt>HTMLHelper::_('draggablelist.draggable');</tt>
* on your <tt><tbody></tt> element define the table in which dragging occurs and the URL of the Ajax call to set the ordering:
<source lang="php">
<tbody<?php if ($saveOrder) : ?> class="js-draggable" data-url="<?php echo $saveOrderingUrl; ?>" data-direction="<?php echo strtolower($listDirn); ?>" data-nested="true"
<?php endif; ?>>
</source>
* on your <tt>tr</tt> element within your <tt><tbody></tt> define the group of records in which dragging occurs (by category below):
<source lang="php">
<tr class="row<?php echo $i % 2; ?>" data-draggable-group="<?php echo $row->catid; ?>">
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==HTML Snippets==
There are two places in the tutorial where reusable snippets of HTML have beeen defined:
* For displaying the item associations in the helloworlds view:
* For displaying the position latitude and longitude fields within the batch options in the helloworlds view
These used different approaches:
* the item associations display was coded in an html helper file in admin/helpers/html/helloworlds.php and accessed via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JHtml::_('helloworlds.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
in the helloworlds tmpl file. (Although it did use a common joomla layout file underneath).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* the position field was coded as a layout in layouts/position.php, and rendered using
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JLayoutHelper::render('position', array());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When should you use one approach rather than the other? A significant difference is that layouts are designed so that an administrator can override them, via the Templates / Details and File functionality. So, for example, an administrator could change the position to show the longitude before the latitude. So it's more appropriate for layouts to focus on the html elements rather than functional logic, and particularly if you would want to allow an administrator to override the layout.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The layouts functionality in Joomla 4 hasn't changed significantly. One correction which has been made in the updated tutorial code has been to include the position.php file in a subfolder of layouts, ie in admin/layouts/helloworld/position.php rather than admin/layouts/position.php. It appears that in the Templates / Details and Files / Create Overrides tab the <tt>com_helloworld</tt> layout appears only if it's in a subfolder of /layouts.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>JHtml::_()</tt> approach has changed in Joomla 4. Rather than Joomla having to look for a helper file when it encounters something it doesn't recognise, it's expected that you should register such classes beforehand, and you do this by obtaining an instance of the Joomla\CMS\HTML\Registry class (it's a singleton class) and then calling <tt>register</tt> on it, passing
* the key you want to use
* an instance of your class
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Joomla pattern is to put the code in a file admin/src/Service/HTML/AdministratorService.php, and we have to ensure that our key won't be used elsewhere within Joomla, so in the tutorial we've used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Robbie\Component\Helloworld\Administrator\Service\HTML\AdministratorService;
...
register('helloworldadministrator', new AdministratorService)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when we call:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo HTMLHelper::_('helloworldadministrator.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will result in Joomla calling the <tt>association</tt> method in our class, passing the <tt>$row->id</tt> parameter.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We should get the Joomla\CMS\HTML\Registry class from the Dependency Injection container. Joomla components generally do this via their services/provider.php file, and then call <tt>register</tt> within the extension's <tt>boot</tt> function, described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Step_5_Call_boot.28.29_on_our_Component|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The extension uses HTMLRegistryAwareTrait which contains <tt>setRegistry</tt> and <tt>getRegistry methods</tt>. In services/provider.php there is:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\HTML\Registry;
...
$component->setRegistry($container->get(Registry::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets 'Joomla\CMS\HTML\Registry' out of the DI container and stores it within the
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
private $registry;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
variable of the HTMLRegistryAwareTrait included in the extension.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the <tt>boot</tt> function it calls
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getRegistry()->register('helloworldadministrator', new AdministratorService);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets the registry and calls <tt>register</tt> as required.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that <tt>boot</tt> is called whenever Joomla dispatches <tt>com_helloworld</tt>, both for the site and administrator, so it would make sense to check the Application <tt>isClient</tt> before deciding whether to register the HTML Helper service or not. This hasn't been included in the tutorial code though.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==User Interface Changes==
Joomla 4 introduced new templates, atum on administrator and cassiopeia on site, and in particular the administrator is built upon some UI rearrangements which affect the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Sidebar===
In Joomla 3 each component incorporated a sidebar which we coded in the <tt>addSubmenu</tt> function in admin/helpers/helloworld.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the administrator menu is in a vertical panel on the left hand side, and the Hello World submenu is built from entries in the helloworld.xml manifest file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<administration>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<submenu>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<menu link="option=com_categories&extension=com_helloworld">COM_HELLOWORLD_CATEGORIES</menu>
<menu link="option=com_fields&view=fields&context=com_helloworld.helloworld">MOD_MENU_FIELDS</menu>
<menu link="option=com_fields&view=groups&context=com_helloworld.helloworld">MOD_MENU_FIELDS_GROUP</menu>
</submenu>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===CSS Classes===
In several places the CSS classes defined in the html elements have been changed in Joomla 4. For example, for general layout the classes now align with the [https://getbootstrap.com/docs/3.4/css/ Bootstrap CSS Classes], and classes such as <tt>row-fluid</tt> and <tt>span3</tt> which were prominent in Joomla 3 have disappeared. If you're upgrading a Joomla 3 component then it's probably best (on the back-end at least) to find a similar Joomla component and use the overall html structure and css classes within its tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the tutorial code those classes which are specifically used by Bootstrap have been changed from eg 'data-target' to 'data-bs-target', and it has been necessary to change these to enable the functionality to work.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, not all of CSS class changes affecting solely the presentation have been reflected in the updated tutorial code. For example, in the <tt>helloworlds</tt> view, showing the list of helloworld messages, the display of the associations is different from that of other Joomla components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Fonts===
In Joomla 3 [[J3.x:Joomla_Standard_Icomoon_Fonts|Icomoon Fonts]] were used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 Font Awesome's free icons are used, and you can see what is available on their [https://fontawesome.com/v5/cheatsheet cheatsheet]. The icons are implemented using CSS pseudo-elements, as described [https://fontawesome.com/v5/docs/web/advanced/css-pseudo-elements here]. Basically they convert a CSS class into html content, namely a unicode value in the private use range. A couple of these have been implemented in the frontend form, in the Save and Cancel buttons, for example:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>span class="icon-cancel">/span <?php echo Text::_('JCANCEL') ?></tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(with angle brackets removed from the <tt>span</tt> tags to stop the icon just being displayed by the browser).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This class is defined in media/system/css/joomla-fontawesome.css (where you can find the list of icon classes supported):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
.icon-cancel:before {
content: "\f00d";
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so this includes in front of the text the unicode character <tt>f00d</tt>, which you can see on the cheatsheet as "times", and displayed as <span class="icon-cancel"></span>. You can also use <tt>fa-</tt> plus the icon name on the font awesome cheatsheet page. If you use Icomoon icon names in your code which you run under Joomla 4, then the icon displayed will be a Font Awesome icon (if there's one with the same name) or it will use a mapping which the Joomla team have defined to display a Font Awesome icon which resembles the Icomoon one.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Buttons and Links===
An accessibility principle is that <tt><a></tt> html elements should be used for links to other web pages, and <tt><button></tt> elements should be used for actions, eg on a form. To align with this, the <tt><a></tt> elements in the helloworld modal field (defined in admin/src/Field/Modal/Helloworld.php) have been changed to <tt><button></tt> elements. These are the Select and Clear buttons displayed when choosing a Helloworld record for a menuitem pointing to a Helloworld message. (The buttons also include fontawesome icons, by the way).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This change was actually made in Joomla in one of the Joomla 3 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Categories View===
In the Categories view of standard Joomla components there now appears columns which show for each category the number of items, split by published status. This is populated by <tt>com_categories</tt> calling each extension's <tt>countItems</tt> function, as described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_categories|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Miscellaneous Changes==
===Version History===
In Joomla 3 the tutorial code used the <tt>JTableObserver</tt> functionality to copy relevant changes from the Helloworld and Categories tables into the UCM tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it uses a plugin mechanism to subscribe to Table events 'onTableAfterStore' and 'onTableBeforeDelete'. The plugin can be found in plugins/behaviour/versionable, and it is activated by Joomla as part of its application initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The copying of fields from the table works roughly the same way as before, except that the name of the table where the versions are stored is now <tt>#__history</tt>, so the entries which have to be inserted into the <tt>#__content_types</tt> table are fairly similar. Because the folders in which forms are stored has changed in Joomla 4, the 'formFile' parameter is different (remember that this is where Joomla gets the field labels in order to display the Preview within the Versions modal window, otherwise just the names of the database columns will be output).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here's a summary of what needs to be done to enable versioning under Joomla 4. The Versioning Traits and Interface definitions are found in libraries/src/Versioning:
* Enter data into content_types database table
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Storing the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The Table class must implement VersionableTableInterface and provide <tt>getTypeAlias()</tt>, which returns 'com_helloworld.helloworld'. This type alias + the helloworld record id is used as the key to identify versions in the <tt>#__history</tt> table.
* Define <tt>save_history</tt> and <tt>history_limit</tt> options in config.php, and ensure these are both set.
* Add a <tt>version_note</tt> field into the output of the edit view's tmpl file (admin/tmpl/helloworld/edit.php).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Viewing and Restoring the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit Controller (admin/src/Controller/HelloworldController.php) should <tt>use VersionableControllerTrait</tt>.
* The edit Model (admin/src/Model/HelloworldModel.php) should <tt>use VersionableModelTrait</tt> and include a variable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public $typeAlias = 'com_helloworld.helloworld';
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit View (admin/src/View/Helloworld/HtmlView.php) – should display the Versions toolbar button if global config has <tt>save_history</tt> on.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Joomla 4 allows us to have different history version limits for helloworld items and categories, and this has been used in the configuration definition in admin/config.xml.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Setting Configuration Parameters in Install Script===
As you may remember, global configuration parameters relating to the Hello World component are defined in admin/config.xml and stored in the <tt>#__extensions</tt> table, in a JSON string in the params field of the record relating to <tt>com_helloworld</tt>. This means that when the component is first installed the params are not set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So, for example, even if the <tt>save_history</tt> is defined in config.xml to default to true, the versions won't be saved until an administrator actively saves the configuration parameters, because the Joomla versioning code assumes <tt>save_history</tt> to be false if it's not explicitly set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For this reason it makes sense to set any default configuration parameters in the install script.php, in the <tt>postflight</tt> method, and that has been done in this step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Tags===
Like version history, tags functionality has been changed to use a plugin – in plugins/behaviour/taggable – rather than the <tt>JTableObserver</tt> approach.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To enable tags the component table must implement TaggableTableInterface (in libraries/src/Tag), and provide the <tt>getTypeAlias()</tt> which is common to the Versioning functionality.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Whenever <tt>com_tags</tt> outputs helloworld messages or categories relating to a tag it displays them as links, and looks in the site/helpers/route.php file to find the route functions (as described above in [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_tags|com_tags]]). The class and method in this file must match the 'router' field within the data entered into the <tt>#__content_types</tt> table.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===media files===
Under Joomla 4 all of the media files are stored in the /media folder; these include javascript and css files (scss files too), as well as images such as the little flag symbols shown in the language switcher. Extensions being developed should store all of the js and css files in their /media folder, and then when the extension is installed these files are put under the extension's folder under the /media folder of the Joomla instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Patches==
Some bugs in Joomla were discovered during the course of updating the tutorial code to work under Joomla 4. If you find something doesn't work then make sure you're on at least Joomla 4.2.6 and check if you need one of the following patches:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
CategoryAssociationHelper.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39358/files
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
MediaField.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/issues/39203
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Category restore
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39474
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Contributors ==
*[[User:Robbiej|Robbie Jackson]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Prev: Adding Custom Fields|class=expand success}}</div>
</div>
</div>

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/24/it

2023-05-27T12:46:09Z

Inoltre, se usi una delle classi predefinite di PHP (ad es. <tt>Exception</tt>) nel tuo codice, aggiungi una barra rovesciata prima di essa (ad es. <tt>\Exception</tt>), altrimenti PHP cercherà di trovare nel tuo spazio dei nomi.

J3.x:Developing an MVC Component/Upgrading to Joomla4/it

2023-05-27T12:45:44Z

Ing Pulizzi: Created page with "Quindi il namespace che specifichi nei tuoi file di classe deve essere allineato con il percorso del tuo file PHP, sotto la cartella di base <tt>src</tt> nel prefisso del tuo..."

<noinclude><languages /></noinclude>

{{:J3.1:Developing an MVC Component/it}}
Questo passaggio copre ciò che è coinvolto nell'aggiornamento del codice del tutorial per allinearlo con la versione 4 di Joomla.

== Introduzione ==
Questa pagina descrive i principali aspetti relativi allo sviluppo dei componenti che sono stati introdotti in Joomla 4 e descrive in dettaglio cosa è stato modificato nel codice del tutorial per allinearsi con v4.

Non è pratico dettagliare tutte le modifiche al codice sulla pagina Web come è stato fatto per i passaggi precedenti dell'esercitazione. Invece puoi trovare il codice come repository github su [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial Joomla 4 Tutorial code], e puoi confrontarlo con il codice del passaggio precedente del tutorial (Adding Custom Fields) su [https://github.com/robbiejackson/Joomla-3-MVC-Tutorial Joomla 3 MVC code]. Il codice di Joomla 4 replica tutte le funzionalità del codice di Joomla 3, con l'eccezione dell'implementazione dell'icona del piccolo pinguino introdotta in [[S:MyLanguage/J3.2:Developing an MVC Component/Adding decorations to the backend|Aggiunta di decorazioni al backend]] (che non è così rilevante data la modifica dell'interfaccia utente in Joomla 4 Administrator) e l'uso di un plug-in CAPTCHA ([[J3.x:Developing an MVC Component/Adding a frontend form|Adding a frontend form]] ). Probabilmente troverai utile avere a portata di mano questo codice Joomla 4 a cui fare riferimento mentre leggi questa pagina.

Il codice per questo passaggio è stato sviluppato seguendo ciascuno dei precedenti passaggi del tutorial e cercando di far funzionare ogni passaggio con Joomla 4.2.5. Poiché Joomla 4 si sta ancora evolvendo abbastanza velocemente, è possibile che alcuni aspetti qui citati vengano modificati durante la vita di Joomla 4. Sentiti libero di correggere gli aspetti in questa pagina e creare richieste pull su [https://github.com/robbiejackson /Joomla-4-MVC-Tutorial Joomla 4 github repository].

Se stai installando il codice del tutorial di Joomla 4 su una nuova istanza di Joomla, dovrai configurare la tua istanza per renderla multilingue e aggiungere le voci di menu nascoste di Ajax come descritto nel passaggio [[J3.x:Developing an MVC Component/ Utilizzo del filtro della lingua |Utilizzo del filtro della lingua]]. Assicurati inoltre che ogni record helloworld abbia una categoria valida.

=== Ulteriori letture ===
Puoi trovare [https://blog.astrid-guenther.de/en/der-weg-zu-joomla4-erweiterungen/ qui] un tutorial per lo sviluppo dei componenti di Joomla 4, simile a questo Joomla 3, e alcuni eccellenti Joomla 4 è disponibile anche la documentazione [https://www.dionysopoulos.me/book.html qui]. Entrambi questi riferimenti includono descrizioni degli impatti di Joomla 4 sullo sviluppo di altri tipi di estensioni Joomla (plugin, moduli e modelli), che non sono trattati qui.

Questo passaggio non copre tutto ciò che è necessario per aggiornare un componente da Joomla 3 a Joomla 4, solo gli aspetti coperti dal codice del tutorial. Se stai aggiornando il tuo componente Joomla 3, potresti trovare utile esaminare [[Potenziali problemi di compatibilità con le versioni precedenti in Joomla 4]].

== NameSpace ==
===NameSpace dei nomi dei componenti===
I NameSpace delle classi che utilizza la [https://www.php-fig.org/psr/psr-4/ PSR-4 recommendation] è stato gradualmente introdotto durante le versioni di Joomla 3 e con Joomla 4 è praticamente tutto con NameSpace

Ora è previsto che anche le estensioni di Joomla utilizzino i NameSpace di base per l'estensione definito nel suo file XML manifest. I componenti di Joomla usano uno NameSpace della forma <tt>Joomla\Component\<Nome componente></tt> es. <tt>Joomla\Component\Content</tt>, quindi seguendo questo schema ho dato una base al codice del tutorial spazio dei nomi di <tt>Robbie\Component\Helloworld</tt>. Ecco la riga nel file manifest helloworld.xml:

<namespace path="src">Robbie\Component\Helloworld</namespace>

(L'attributo <tt>path="src"</tt> indica che si aspetterà che le classi si trovino nella sottocartella <tt>src</tt>.)

Questo in realtà crea 2 prefissi dello spazio dei nomi, che puntano a cartelle specifiche nella nostra struttura di sviluppo helloworld e nella nostra istanza joomla live:

<tt>Robbie\Component\Helloworld\Administrator</tt> – punterà ad administrator/components/com_helloworld/src sull'istanza live ed è associato ad admin/src nella nostra area di sviluppo.

<tt>Robbie\Component\Helloworld\Site</tt> – punterà a components/com_helloworld/src sull'istanza live ed è associato a site/src nella nostra area di sviluppo.

Quindi Joomla ora si aspetta che tutti i nomi delle classi vengano trovati in quelle directory di base, con il nome del file che corrisponde al nome della classe e il nome della classe completo che corrisponde al percorso, ad esempio

<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> si troverà in
administrator/components/com_helloworld/src/Controller/DisplayController.php

<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> si troverà in
components/com_helloworld/src/Model/CategoryModel.php

'''Nota che le lettere maiuscole sono importanti nei namespace, nei nomi delle classi e nei nomi dei percorsi!'''

Quando Joomla 3 ha voluto chiamare le funzioni nel tuo componente, ha cercato determinati nomi di file in cartelle particolari e ha verificato che il nome della classe in quel file corrispondesse a quello previsto.

In Joomla 4 genera il nome completo della classe che vuole trovare, quindi cerca di trovarlo nella posizione in cui la raccomandazione PSR-4 lo aspetterebbe.

Quindi il namespace che specifichi nei tuoi file di classe deve essere allineato con il percorso del tuo file PHP, sotto la cartella di base <tt>src</tt> nel prefisso del tuo namespace.

Si noti in particolare come sono ora organizzati i file della classe <tt>View</tt>.

<div lang="en" dir="ltr" class="mw-content-ltr">
Also if you use one of the PHP predefined classes (eg <tt>Exception</tt>) in your code, then add a backslash before it (eg <tt>\Exception</tt>), otherwise PHP will try and find it in your namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you use custom Field or Rule definitions in your form xml files then you have to indicate to PHP which namespace prefix to use to look for them, eg in <tt>site/forms/add-form.xml</tt>:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
addruleprefix="Robbie\Component\Helloworld\Administrator\Rule"
addfieldprefix="Robbie\Component\Helloworld\Administrator\Field"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and also in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> where the associations are added into the form dynamically to form the custom <tt>modal_helloworld</tt> type field:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Class Autoloading===
Joomla uses the PHP mechanism for [https://www.php.net/manual/en/language.oop5.autoload.php Autoloading Classes] and on startup registers a number of autoloaders – functions which get called when PHP can't find a given class. In particular the Joomla PSR-4 autoloader function (in <tt>libraries/loader.php</tt>) is responsible for finding classes of Joomla extensions whose code is in source files which are organised according to the PSR-4 recommendation. (Joomla library classes are autoloaded using a different autoloader – see <tt>libraries/vendor/composer/autoload_static.php</tt>).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can see the namespace prefixes of extensions on the Joomla instance by looking at <tt>administrator/cache/autoload_psr4.php</tt>. (These namespace strings have double backslashes, but in PHP they're the [https://stackoverflow.com/questions/25459197/single-or-double-slash-when-using-php-namespace same strings as those with single backslashes]). This is generated by Joomla looking through the component, module and plugin directories to find each extension's manifest file, and then processing these xml files to extract the <tt><namespace></tt> element – quite a lot of work, which is why it's cached I guess!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider what happens when Joomla wants our admin HelloworldController class. It might have something like
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$classname = 'Robbie\Component\Helloworld\Administrator\Controller\HelloworldController'
if (!class_exists($classname)) { …
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Assuming PHP doesn't already know about this class, the <tt>class_exists</tt> function will result in the classname being passed to the registered autoload function(s). The PSR-4 autoloader will then:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# go through its array of namespaces to try and match <tt>$classname</tt> from the start of the string.
# find 'Robbie\Component\Helloworld\Administrator' as a match
# see that this maps to "administrator/components/com_helloworld/src"
# extract the remainder of the classname: 'Controller\HelloworldController'
# treat this as the path down to the class file
# and so look for "administrator/components/com_helloworld/src/Controller/HelloworldController.php"
# check that in this file there's actually a class with that namespace + class name.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So in this way Joomla can go from a fully qualified class name to find the source code for that class. This makes it easier for us too when the core Joomla code is looking for one of our classes. We still need to know what class it's looking for, but once we know that, we know what we should call our class and where we should save the source code for it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Joomla Library classes===
Originally Joomla's core classes (beginning with a capital J) were global classes. Over the Joomla 3 versions and into Joomla 4 these migrated to their namespaced equivalents, but the original global classnames were still available as Joomla registered them as aliases (in the <tt>libraries/classmap.php</tt> file).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In a Joomla 4 extension you can still use these global classnames, except that in a namespaced file you'd have to prefix the name with a backslash to indicate a global class rather than one in your namespace (eg <tt>\JFactory</tt> instead of <tt>JFactory</tt>).
However it's pretty definite that the aliases will disappear at some stage, so the upgrade to Joomla 4 seems an appropriate opportunity to replace all your component's calls to the global JSomething classes to the namespaced equivalents. This involves adding the appropriate <tt>use</tt> statements, and all this has been done in the tutorial code. A useful mapping between the two can be found [https://github.com/nikosdion/joomlatypehints/blob/main/JoomlaObsoleteClasses.md here], where the new qualified classname can be copied and pasted into a <tt>use</tt> statement in your PHP file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
With reference to the [https://api.joomla.org/ Joomla API Documentation] there are 2 Joomla library namespaces:
* Joomla CMS classes – have namespaces <tt>Joomla\CMS\Something</tt> – are found under <tt>libraries/src/Something</tt>
* Joomla Framework classes – have namespaces <tt>Joomla\Something</tt> – are found under <tt>libraries/vendor/joomla/something/src</tt>
So a big advantage of namespacing is that you can immediately determine from the fully qualified class name in a PHP <tt>use</tt> statement where the source for that class exists in the <tt>libraries</tt> directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
On the other hand class names which aren't fully qualified don't have to be unique, eg <tt>MVCFactory</tt>
* occurs as <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in <tt>libraries/src/Extension/Service/Provider/MVCFactory.php</tt>
* occurs as <tt>Joomla\CMS\MVC\Factory\MVCFactory</tt> in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>
so sometimes you have to be careful to examine the <tt>use</tt> statement to identify the right class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly our FormModel class in <tt>site/src/Model/FormModel.php</tt> can have the same FormModel classname as the Joomla FormModel in <tt>libraries/src/MVC/Model/FormModel.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The API documentation gives the methods available in each of the [https://api.joomla.org/cms-4/namespaces/joomla.html Joomla CMS] and [https://api.joomla.org/framework-2/namespaces/joomla.html Framework] classes, but just be aware that a Joomla CMS class may extend a Framework class, and in this case some methods may not be visible under the Joomla CMS documentation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For example, <tt>$app->setHeader()</tt> which is used to set the HTTP response code is not listed under the [https://api.joomla.org/cms-4/classes/Joomla-CMS-Application-CMSApplication.html CMS Application class API], but is available as a method because it inherits from the Framework class [https://api.joomla.org/framework-2/classes/Joomla-Application-AbstractWebApplication.html AbstractWebApplication].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Vendor Namespaces===
These are also in <tt>libraries/vendor</tt>, eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Psr\Container\ContainerInterface;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
refers to <tt>libraries/vendor/psr/Container/src/ContainerInterface.php</tt>. However there are few of these in the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other File Rearrangements===
With all of the namespaced classes moving under the src directories, the <tt>tmpl</tt> layout files and <tt>form</tt> xml files have been moved out into their own directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Extension and Dispatcher classes ==
===Extension===
In Joomla 3 the point where the Joomla core handed over to your component code was when it ran your <tt>helloworld.php</tt> code; if it was the frontend it ran your site <tt>helloworld.php</tt> code, or if was the backend it ran your admin <tt>helloworld.php</tt> code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the entry point into your component code is your Extension class, both for site and admin, found in <tt>admin/src/Extension/HelloworldComponent.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When the Joomla core application wants to start executing the component code it creates an instance of <tt>HelloworldComponent</tt>, just to get a handle on the component code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly (as described below) other Joomla classes such as Router or Categories need to call certain Helloworld methods (eg custom router functions). In Joomla 3 these methods were written in certain Helper files etc. In Joomla 4 the principle is that the component creates an instance of the <tt>HelloworldComponent</tt> Extension class, and calls the required methods on that instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This Extension class isn't anything like a big container class for the component, it's more like a glue class, providing a way in to the Helloworld component, enabling the Joomla core and other components call the methods which they want to call.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla core wants to execute the component code, the key method it is looking for in your <tt>Extension</tt> instance is <tt>getDispatcher</tt>, and it expects to get back a <tt>Dispatcher</tt> instance. The <tt>HelloworldComponent</tt> extends <tt>MVCComponent</tt>, which in turn extends <tt>Component</tt>, and it is this class which defines <tt>getDispatcher</tt> for us.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Dispatcher===
When Joomla wants to run the Hello World component, it gets the <tt>Dispatcher</tt> instance as described above and then calls the <tt>dispatch</tt> method on it. It is this <tt>dispatch</tt> function which replaces the functionality in the admin and site <tt>helloworld.php</tt> files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's look at the main lines of code in our Joomla 3 admin <tt>helloworld.php</tt> file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="site/views/form/view.html.php">
<syntaxhighlight lang="php">
if (!JFactory::getUser()->authorise('core.manage', 'com_helloworld'))
{
throw new Exception(JText::_('JERROR_ALERTNOAUTHOR'));
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Get an instance of the controller
$controller = JControllerLegacy::getInstance('HelloWorld');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Execute the Request task method
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Redirect if set by the controller
$controller->redirect();
</syntaxhighlight>
</span>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code
* performs some permissions checks
* instantiates the appropriate Helloworld controller
* executes the appropriate method in that controller
* implements any redirect set by the controller
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Model-View-Controller]] for further details of how this works in Joomla 3. The second and third steps used the <tt>task</tt> parameter within the URL query to determine the correct controller class to instantiate and method to call. If no <tt>task</tt> parameter was present then it instantiated the controller in <tt>controller.php</tt> and called the <tt>display</tt> method. Otherwise it instantiated one of the controllers in the <tt>controllers</tt> subfolder (eg <tt>controllers/helloworld.php</tt>) and called the appropriate method on it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>ComponentDispatcher::dispatch</tt> method (in <tt>libraries/src/Dispatcher/ComponentDispatcher.php</tt>) now provides this functionality, but in a nicer way. After checking the permissions it uses the <tt>task</tt> by considering its parts as <tt><controller type>.<method></tt> (taking 'display' as default if either part is missing). It will then pass control to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* an instance of the class <Controller type>Controller
* calling the function <method>
* using the admin or site controller, as appropriate
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In this way the naming of the controllers is consistent - we have DisplayController, HelloworldController and HelloworldsController, all in the same folder.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Dispatcher class can thus be considered as providing some 'routing - execution' functionality, enabling us to find the right controller and function within that controller, and it is cleaner to have this in a separate class rather than in the <tt>JControllerLegacy</tt> class as it was in Joomla 3.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Since the Hello World tutorial uses the standard Joomla pattern for selecting the class and method based on the <tt>task</tt> and has the same permissions checks, we can use the <tt>dispatch</tt> code as it stands in <tt>ComponentDispatcher</tt>, and don't need to define a special class of our own.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Factory classes ==
In Joomla 3 many classes had static <tt>getInstance</tt> methods which returned an instance of that class, configured with the parameters passed to <tt>getInstance</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the <tt>getInstance</tt> methods have been deprecated in favour of using Factory classes. The preferred mechanism is now to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* get an instance of the appropriate Factory class (how we do that is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below)
* call the <tt>createSomething()</tt> method of the Factory class with relevant parameter values to generate an instance of the Something class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===MVC Factory===
In this section the <tt>MVCFactory</tt> class refers to the one in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory class will instantiate Controller, View, Model and Table instances on our behalf, and it does this by generating the classname of the class and then calling <tt>new</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The way it works is as follows:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Each component gets an individual MVCFactory instance which is constructed passing the component's namespace as a parameter (so in our case 'Robbie\Component\Helloworld'). (How this MVCFactory instance is created is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below).
# The MVCFactory createController / createView / createModel / createTable function is then called, passing the name of the Controller / Model / View / Table and the prefix (which specifies whether the administrator or site class is required).
# The create function forms the classname from this data and calls <tt>new</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory create functions just form the classname from the parameters they're passed. The intelligence for working out what name and prefix should be used to form the appropriate classes for an incoming HTTP request is
* in the dispatcher code for defining the controller to use
* in the controller for the view and model
* in the model for the table
and, for example, the names of the classes created for a request with URL query <tt>?option=com_helloworld&view=viewname</tt> and no <tt>task</tt> parameter will be
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<namespace>\Controller\DisplayController
<namespace>\View\Viewname\HtmlView
<namespace>\Model\ViewnameModel
<namespace>\Table\ViewnameTable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you need an alternative name then you can override the appropriate getView, getModel or getTable function – as for example was done in the [[J3.x:Developing an MVC Component/Adding Custom Fields#Front-end_Form|Adding Custom Fields step, frontend Form section]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So from the outside this is pretty much the same as in Joomla 3. However, note that the <tt>$prefix</tt> parameter in calls to <tt>getModel</tt> etc is subtly different
* in Joomla 3 this referred to a prefix to be applied to the classname – in the tutorial code we used 'HelloWorldTable' as the prefix part of the 'HelloWorldTableHelloWorld' classname.
* in Joomla 4 this refers to a prefix higher up the classname path, and should be set to either 'Site' or 'Administrator' (the capital letter at the start is optional), depending on whether you want the class under 'Robbie\Component\Helloworld\Site' or 'Robbie\Component\Helloworld\Administrator'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVC Factory class is now the Joomla recommended way to create the controller, view, model and table classes, by using the eg <tt>getModel()</tt> method, and the use of <tt>getInstance()</tt> for these classes is now deprecated. However, the use of these functions is restricted:
* in the controller class you can call <tt>$this->getView($viewname, $viewtype, $prefix, $config)</tt> to create a view and <tt>$this->getModel($modelname, $prefix, $config)</tt> to create a model.
* in the view class you can call <tt>$this->getModel($modelname)</tt>, but only for models which the controller has previously defined using <tt>$view->setModel($modelname, $default)</tt>. It doesn't create a new model instance.
* in the model class you can call <tt>$this->getTable($tableclass, $prefix, $options)</tt> to create a table instance. Controllers and views can access the table classes in this way, by going via a model.
These restrictions do have an impact on moving away from using <tt>getInstance()</tt>, and indeed in Joomla 4.2.6 you will still find several <tt>getInstance()</tt> calls within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Factory Classes===
Several other Factory classes have been introduced in Joomla 4, enabling you to get instances of core classes such as Form, User, CacheController, etc, usually by calling a createSomething function on the Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Associated with the Factory class is a FactoryInterface, a PHP Interface which specifies the key functions which the Factory class must implement. For example, with <tt>libraries/src/Categories</tt> we have:
* CategoryFactoryInterface – which specifies the <tt>createCategory</tt> function
* CategoryFactory implements CategoryFactoryInterface – which provides the <tt>createCategory</tt> function.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Dependency Injection ==
===Overview===
The DI container is one of the significant new additions to Joomla 4. It's basically a repository of key-value pairs where:
* the key is a string which is the name of a class or interface
* the value is an instance of the relevant class, or a function that returns an instance of that class.
You put things into the container using <tt>set()</tt> passing:
* the class name or interface name
* a function which returns an instance of the class (or an instance of the class)
* a boolean defining whether the class instance may be shared or not
* a boolean defining whether this entry into the DI container is protected or not (an error will be raised if you try to overwrite a protected entry by calling <tt>set()</tt> again using the same key).
The function <tt>share()</tt> is basically the same as <tt>set()</tt> with the <tt>shared</tt> boolean set to true.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You get things out of the container by calling <tt>get()</tt> passing the key of the resource you want. The container will
* find the key in the container
* if the value isn't already a class instance, then it will run the associated function to generate an instance of the class
* if the resource is shared, it will store the class instance, so that on subsequent invocations of <tt>get()</tt> it can just return the instance
* return the class instance to you
You can also define aliases for each key in the container, which means that you call <tt>get()</tt> passing either the key or an alias of the key.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The DI container is initialised in <tt>library/src/Factory.php createContainer()</tt> which results in the <tt>register()</tt> function being called in each of the class files in <tt>libraries/src/Service/Provider</tt>. By looking through those files you can see what gets put into the DI container upon initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===JConfig Example===
Let's consider the example of JConfig which holds the system global configuration. If you look inside <tt>libraries/src/Service/Provider/Config.php</tt> then you'll see the <tt>register()</tt> function and that it stores in the DI container a resource with:
* key = 'JConfig'
* value = an anonymous function - which loads what's in <tt>configuration.php</tt> into a <tt>Registry</tt> object, and returns it
* shared flag = true (because the <tt>share()</tt> function is used)
* protected flag = true
Then when you do
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$config = $container->get('JConfig');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will run the anonymous function and return the Registry object to you. As the 'shared' boolean is set it will also store a copy of the class instance locally in the container to be returned on subsequent calls of <tt>get('JConfig')</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Justification===
What's the point of all this?
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The advantage of dependency injection is that it allows classes to be easily mocked for testing. The file <tt>libraries/src/Service/Provider/Config.php</tt> can be replaced to return to a DI container <tt>get()</tt> call a mock class instead of the usual <tt>JConfig</tt>. This is in comparison to Joomla 3 where <tt>Factory::getConfig()</tt> code directly reads the <tt>configuration.php</tt> into a Registry structure and returns it – which makes it harder to mock.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The [https://api.joomla.org/cms-4/classes/Joomla-CMS-Factory.html Factory API] has several functions which are marked as deprecated with advice to get the object from the DI container instead.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Several of the other Factory classes (eg Form, Language, Menu, User) are in the DI container – so that we can get an instance of them via eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Factory::getContainer()->get('Joomla\CMS\Toolbar\ToolbarFactoryInterface')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to get a Toolbar instance. However, this only works for singleton classes which aren't specific to the needs of a particular extension. We'll see shortly how to make it work for class instances which need to be specific to a component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As indicated above, Joomla is moving away from using the class static <tt>getInstance()</tt> functions. We can see now that this is not only because it's more pure from an object oriented perspective. But also creating class instances from the DI container, or from Factory objects which are obtained from the DI container, builds in the dependency injection which allows classes to be more easily mocked, and hence more easily tested.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==services/provider.php==
We're now finally in a good position to understand what's happening in our services/provider.php file, and we'll explore this by walking through what happens whenever this line in libraries/src/Component/ComponentHelper.php <tt>renderComponent</tt> is run:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is run whenever Joomla has worked out which component is to be run on the requested web page, and it wants to run that component to capture its output.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 1 Create Child DI Container===
Joomla first creates another DI container (initially empty) just for this component, and links it to the main DI container via a parent field in the child DI container structure.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Now whenever <tt>set()</tt> is called on this DI container the key-value pair is inserted into the child container. Whenever <tt>get()</tt> is called on it, the resource is obtained from the child container, but if it's not found there then the parent container is searched also.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 2 Run register() in provider.php===
Next we encounter these lines (in <tt>libraries/src/Extension/ExtensionManagerTrait.php</tt>), where <tt>$path</tt> contains the path of our helloworld admin/services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$provider = require_once $path;
// Check if the extension supports the service provider interface
if ($provider instanceof ServiceProviderInterface) {
$provider->register($container);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here we see 3 things:
# our provider.php should return some object (so that <tt>$provider</tt> gets set to something)
# what is returned should implement ServiceProviderInterface (you can see in <tt>libraries/vendor/joomla/di/src/ServiceProviderInterface.php</tt> what is expected)
# the code then runs the <tt>register</tt> function on that object, passing as a parameter the child DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider a minimal version of our provider.php file. This would actually support steps in the Joomla 3 tutorial up to and including the [[J3.x:Developing an MVC Component/Adding AJAX|Adding Ajax step]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {

public function register(Container $container): void
{
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
}
};
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As you can see from the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
this file does indeed return something – it returns an instance of an anonymous class, one that implements <tt>ServiceProviderInterface</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it's not sufficient to just provide the <tt>register</tt> function in the class, we also need to explicity state that the class implements <tt>ServiceProviderInterface</tt>. This now happens in several places in Joomla, so if you're debugging your component and wondering why a function you expect to be called isn't being called, then check to make sure that you don't have to explicitly add the appropriate <tt>implements <Interface></tt> clause to your class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Next we look at the 3 lines in the <tt>register</tt> function
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3a Registering our MVC Factory===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here our <tt>MVCFactory</tt> refers to <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in libraries/src/Extension/Service/Provider/MVCFactory.php, and you should have a look at this file. This is a file similar to our provider.php file, but it's a named class, and it doesn't return anything. When we do:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
new MVCFactory('\\Robbie\\Component\\Helloworld')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it creates an instance of this class, and in the constructor it stores locally in <tt>$this->namespace</tt> our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>registerServiceProvider</tt> function then calls the <tt>register</tt> function of this instance, which runs (in its minimalist form):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
MVCFactoryInterface::class,
function (Container $container) {
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
return $factory;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So what gets entered into our child DI container is a key-value pair with:
* key = MVCFactoryInterface::class (this is just a shorthand form to obtain a string of the fully qualified name – ie 'Joomla\CMS\MVC\Factory\MVCFactoryInterface')
* value = a function which returns an instance of <tt>\Joomla\CMS\MVC\Factory\MVCFactory</tt>.
This is our MVCFactory class which generates our Controllers, Views, Models and Tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Notice that we're passing our namespace as a parameter <tt>$this->namespace</tt>. Because this function is a closure, this variable will still be available when we run this function later, and when the MVCFactory class is instantiated the namespace will be passed into the constructor, stored locally, and then subsequently used to form the fully qualified names of our Controllers, View, etc. So this is how we get instantiated the MVCFactory class which is specific to our component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3b Registering the Dispatcher Factory===
Careful: ComponentDispatcherFactory refers to two different classes here!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This ComponentDispatcherFactory is Joomla\CMS\Extension\Service\Provider\ComponentDispatcherFactory in libraries/src/Extension/Service/Provider/ComponentDispatcherFactory.php. Similar to the above, the ComponentDispatcherFactory service provider class stores locally our namespace, and then when <tt>register</tt> is called it executes:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentDispatcherFactoryInterface::class,
function (Container $container) {
return new \Joomla\CMS\Dispatcher\ComponentDispatcherFactory($this->namespace,$container->get(MVCFactoryInterface::class));
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so a second entry is added to the child DI container with:
* key = ComponentDispatcherFactoryInterface::class
* value = a function which returns an instance of the ComponentDispatcherFactory (the other ComponentDispatcherFactory class!), where the class constructor will be passed the namespace ('\\Robbie\\Component\\Helloworld') and an MVCFactory instance, retrieved from the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that the code
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->get(MVCFactoryInterface::class)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
will get from the container an entry with key = 'Joomla\CMS\MVC\Factory\MVCFactoryInterface' – which is what we entered into the container in step 3a – and will run the function associated with this key, and then return the object which this function returns. This returned object will be an instance of '\Joomla\CMS\MVC\Factory\MVCFactory', constructed using our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3c Including the Extension===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will put into the child DI container a key-value pair with
* key = ComponentInterface::class
* value = the function which will create an instance of our <tt>HelloworldComponent</tt> (ie our Extension class), and pass into the constructor an instance of the ComponentDispatcherFactory class, retrieving what was entered into the child DI container in Step 3b.
It will call <tt>$container->get(MVCFactoryInterface::class)</tt>, getting an MVC Factory instance from what was entered into the DI container in Step 3a.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It will then associate our component with this MVC Factory instance via the <tt>setMVCFactory</tt> call. Significantly this will then allow our component to access this instance later, via a call to <tt>getMVCFactory</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3 Summary===
We have now got 3 entries in our child DI container, keyed by
* key = MVCFactoryInterface::class, value is a function returning an MVCFactory instance
* key = ComponentDispatcherFactoryInterface::class, value is a function returning a ComponentDispatcherFactory instance
* key = ComponentInterface::class, value is a function returning our HelloworldComponent, an instance of our Extension class.
The important aspect is that these entries are all aware of our namespace '\Robbie\Component\Helloworld' and will return instances of these classes which are specific to our Helloworld component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 4 Retrieving from the DI Container===
Joomla will then execute the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $container->get($type);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
where <tt>$type</tt> contains 'Joomla\CMS\Extension\ComponentInterface'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This starts the process of retrieving from the DI container the 3 entries which we put in, and will run our code in services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We end up with a HelloworldComponent instance, which has:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. a ComponentDispatcherFactory instance passed into the constructor, and which is saved locally by the constructor code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function __construct(ComponentDispatcherFactoryInterface $dispatcherFactory)
{
$this->dispatcherFactory = $dispatcherFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This code is in libraries/src/Extension/Component.php, in the class which our HelloworldComponent extends, via the class MVCComponent).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. an MVC Factory instance, stored by the HelloworldComponent <tt>setMVCFactory</tt> call
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 5 Call boot() on our Component===
Joomla calls:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
if ($extension instanceof BootableExtensionInterface) {
$extension->boot($container);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will call <tt>boot</tt> within our HelloworldComponent, and allows us to perform some initialisation within our component. We'll return to this later, in the section on [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#HTML_Snippets|HTML snippets]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note again that Joomla checks that our HelloworldComponent class implements BootableExtensionInterface before calling <tt>boot</tt>. It's not sufficient to just provide the <tt>boot</tt> function, we have to explicitly declare that our HelloworldComponent implements the interface.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 6 Get the Dispatcher===
Returning to our key line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
we have now accomplished the first part <tt>bootComponent($option)</tt>, and this has returned our HelloworldComponent instance. Now we call <tt>getDispatcher($app)</tt> on this instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This code is also in libraries/src/Extension/Component.php, in the Component class which our HelloworldComponent extends:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function getDispatcher(CMSApplicationInterface $application): DispatcherInterface
{
return $this->dispatcherFactory->createDispatcher($application);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We call <tt>createDispatcher</tt> on our ComponentDispatcherFactory class instance which we saved in Step 4. This code is in libraries/src/Dispatcher/ComponentDispatcherFactory.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createDispatcher(CMSApplicationInterface $application, Input $input = null): DispatcherInterface
{
$name = ucfirst($application->getName());

$className = '\\' . trim($this->namespace, '\\') . '\\' . $name . '\\Dispatcher\\Dispatcher';

if (!class_exists($className)) {
if ($application->isClient('api')) {
$className = ApiDispatcher::class;
} else {
$className = ComponentDispatcher::class;
}
}

return new $className($application, $input ?: $application->input, $this->mvcFactory);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code checks if we have our own Dispatcher class (our Helloworld tutorial doesn't, but <tt>com_users</tt> for example has its own). So it creates a <tt>ComponentDispatcher</tt> instance, and passes into its constructor the MVC Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that this ComponentDispatcherFactory instance is what was instantiated when it was retrieved from our child DI Container (from being inserted in step 3b), and hence it already knows about our namespace, and has a pointer to our MVCFactory class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 7 call dispatch()===
This is the final aspect to our line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We're now back to what was described in the Dispatcher section above, except that now we can see that this Dispatcher instance has a pointer to our MVC Factory instance (which knows about our namespace prefix), so when the Dispatcher code wants to create a Controller it can use that MVC Factory instance to instantiate it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's been a long and tortuous journey to get here, but the significant thing is that all of our key class instances have been obtained via the DI Container. If we want to mock out any of those classes for testing then all we need to do is replace the relevant services/provider file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Javascript and the Web Asset Manager ==
The web asset manager has been introduced in Joomla 4 and is well documented [[J4.x:Web_Assets|here]]. It provides a much-improved means of managing JS and CSS resources, and a framework for handling their dependencies.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Component Javascript and CSS files should now be stored in the <tt>media</tt> folder, and the Web Asset Manager used to register them and output them on specific web pages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following assets have been registered in the tutorial <tt>joomla.asset.json</tt>, and you should have a look at that file now.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.validate-greeting===
This is the code for client validation of the helloworld greeting field using a regex, and it is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it is dependent upon jQuery and the Joomla <tt>form.validator</tt> script, so those both get included as dependencies.
If we didn't have specific validation on our form then we would need to include explicitly the <tt>form.validator</tt> script in order for the basic Joomla field validation to be included, eg in the tmpl file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->document->getWebAssetManager()->useScript('form.validate');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that this requires us to have a <tt>class="form-validate"</tt> on the </tt><form></tt> html element.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.fix-permissions-ajax-call===
This is the code which copies the value from the greeting field into the title field, so that the Ajax calls setting the permissions work correctly. The js code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.enable-tooltips===
This is the code which enables bootstrap tooltips to operate, including allowing them to include html code. It's used to display the image as a tooltip within the admin <tt>helloworlds</tt> view.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.openstreetmap===
This is defined as a preset, comprising the helloworld js and css code for the map display, as well as the dependency named 'com_helloworld.openlayers' relating to the openlayers CSS and js code. The code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.admin-helloworlds-modal===
This is the js code for selecting an individual helloworld record within a modal, and passing its details to the form in the main window. Its code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===submitbutton.js===
In the Joomla 3 code we introduced in [[Special:MyLanguage/J3.2:Developing_an_MVC_Component/Adding_verifications|Adding Verifications]] a js file which controlled when the form was submitted. It differentiated between buttons such as <tt>Save</tt> (which submitted the form) and <tt>Cancel</tt> (which didn't).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 there is a more sophisticated version of <tt>Joomla.submitbutton</tt> (found in media/system/js/core.js) which uses the CSS classes which the Toolbar functionality sets on the buttons to determine whether the form should be submitted or not. And you can override whether the validation is performed by adding a third parameter to the <tt>submitbutton</tt> js call. For example, to avoid validation being performed when a button is clicked you can set on the button element:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
onclick="Joomla.submitbutton('controller.method', '', false)"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As this is sufficient for what we need in the tutorial, the custom <tt>submitbutton.js</tt> has been removed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Interaction with other components ==
The way that Joomla interacts with components has changed in Joomla 4. In general the Joomla functionality will boot the component using something like:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $app->bootComponent($option);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and in our case this will return an instance of the <tt>HelloworldComponent</tt> class. It will then try to call certain methods on our extension object, as described below.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_categories===
In the backend the helloworld functionality can display to the administrator
* the view of the helloworld messages
* the view of the helloworld categories
The categories view is generated by <tt>com_categories</tt>, and in Joomla 4 these component categories views display the number of component records there are for each of the possible published status values. To do this the categories component executes the following code (in administrator/components/com_categories/src/Model/CategoriesModel.php):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof CategoryServiceInterface) {
$component->countItems($items, $section);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So our HelloworldComponent must:
* declare that it implements <tt>CategoryServiceInterface</tt>
* provide an implementation of <tt>countItems</tt>
We provide <tt>countItems</tt> by using a trait in libraries/src/Categories/CategoryServiceTrait.php, which (with the assistance of a helper function) does the query on our behalf. We just need to tell it:
* the name of our table – in the callback <tt>getTableNameForSection</tt>
* the database field in which we hold the published status – in <tt>getStateColumnForSection</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_associations===
Remember that <tt>com_associations</tt> is the component which is run whenever you click on Multilingual Associations in the admin backend.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Under Joomla 3 we provided an associations helper file as described in [[J3.x:Multilingual Associations/Developers|Multilingual Associations/Developers]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the helper file remains basically the same, but <tt>com_associations</tt> primarily tries to find the helper file via the extension class; here's the code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($extensionName);
if ($component instanceof AssociationServiceInterface) {
return $component->getAssociationsExtension();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's expecting that:
* the extension (HelloworldComponent in our case) implements <tt>AssociationServiceInterface</tt>
* its <tt>getAssociationsExtension</tt> method returns the helper class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The easiest thing would be just to code <tt>getAssociationsMethod</tt> and get it to return <tt>new AssociationsHelper</tt>. However, we follow the Joomla 4 principle of putting key classes into the Dependency Injection container, and retrieving them later, by having the following code in our services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(AssociationExtensionInterface::class, new AssociationsHelper());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The above line puts a key-value pair into our child DI container
* key = 'Joomla\CMS\Association\AssociationExtensionInterface'
* value is an instance of our <tt>AssociationsHelper</tt> class.
We then retrieve it later and use the setter:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setAssociationExtension($container->get(AssociationExtensionInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so that whenever
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getAssociationExtension()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
is called it returns the <tt>AssociationsHelper</tt> class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_fields===
<tt>com_fields</tt> is the component which is run when an administrator clicks on the Fields or Field Groups menuitem within the backend, and this functionality was included in the [[J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Adding Custom Fields]] tutorial step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>com_fields</tt> component stores the custom fields and field groups for all components in the database tables <tt>#__fields</tt> and <tt>#__fields_groups</tt>, and these tables are partitioned into "sections", one section per component. For our helloworld component the section is named "helloworld".
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within the section we have 2 "contexts" – one for the helloworld messages (called "com_helloworld.helloworld") and one for the helloworld categories (called "com_helloworld.categories"). This enables us to define custom fields for both our helloworld records and helloworld category records.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When <tt>com_fields</tt> runs it checks both the section and contexts at various times. For example, when an admin selects Helloworld / Fields on the backend then <tt>com_fields</tt> checks the section which was defined in the menuitem in the manifest file (see [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Sidebar|below]]). Here's the code in administrator/components/com_fields/src/Helpers/FieldsHelper <tt>extract</tt> function:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
$newSection = $component->validateSection($parts[1], $item);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And when <tt>com_fields</tt> wants to display the little dropdown menu of contexts (to allow the administrator to set custom fields on either helloworld items or categories) it calls (in administrator/components/com_fields/src/Fields/FieldcontextsField.php <tt>getOptions()</tt>):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
return $component->getContexts();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So it's clear that our component extension class must :
* implement <tt>FieldsServiceInterface</tt>
* provide the <tt>validateSection</tt> and <tt>getContexts</tt> methods
So in upgrading to Joomla 4 we've just moved those two methods from the helper file to the extension class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Router===
The Joomla router will access our custom router code:
* whenever it wants to parse an SEF route which it has identified as belonging to <tt>com_helloworld</tt>
* whenever it wants to build an SEF route from a call to <tt>Route::_()</tt> where the option = "com_helloworld".
To find our custom router it will:
* boot the <tt>com_helloworld</tt> extension
* check that the extension implements <tt>RouterServiceInterface</tt>
* call <tt>createRouter</tt> on our extension instance
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In our services/provider.php file we have (careful again - 2 different RouterFactory classes!):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new RouterFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which from libraries/src/Extension/Service/Provider/RouterFactory.php puts into our child DI container an entry with:
* key = "Joomla\CMS\Component\Router\RouterFactoryInterface"
* value is a <tt>\Joomla\CMS\Component\Router\RouterFactory</tt> instance, constructed with our namespace
We then retrieve this in the line in our services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setRouterFactory($container->get(RouterFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And then within our extension class we have
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use RouterServiceTrait;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which includes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function setRouterFactory(RouterFactoryInterface $routerFactory)
{
$this->routerFactory = $routerFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which stores the <tt>routerFactory</tt> locally and
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return $this->routerFactory->createRouter($application, $menu);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which provides our extension's <tt>createRouter</tt> call that the Joomla Router expects.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>routerFactory::createRouter</tt> method is in libraries/src/Component/Router/RouterFactory.php. It looks for a class in our site namespace </tt>Robbie\Component\Helloworld\Site\Service\Router</tt> which is in our site/src/Service/Router.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
At this stage we have a choice, we can either:
* provide a traditional custom router, with the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions, or
* use the more modern <tt>RouterView</tt> mechanism.
By default in the upgraded tutorial code the Router View option has been coded in the Router.php file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====RouterView====
In the <tt>RouterView</tt> case the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions are in the <tt>RouterView</tt> class which we extend, and we provide
* a constructor with router view configuration
* methods <tt>getHelloworldId</tt> and <tt>getCategoryId</tt> which are used to obtain from the SEF segment the <tt>id=</tt> and <tt>catid=</tt> parts of the internal URL
* methods <tt>getHelloworldSegment</tt> and <tt>getCategorySegment</tt> which are used to generate segments for the SEF URLs based on the <tt>id=</tt> and <tt>catid=</tt> parts within the <tt>Route::_()</tt> parameter.
Unfortunately there doesn't seem to be a good guide to configuring the RouterView class. There is some documentation available [https://www.dionysopoulos.me/book/com-router-routerview.html here].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the helloworld tutorial we have 3 views
* a view which displays a single helloworld record
* a view which displays a single helloworld category, and the helloworld records associated with it
* a view which displays the frontend form
So we need 3 Router Views associated with these.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'form' view doesn't have an associated id or catid so it's just a fixed URL, and the router just has to convert between the alias of the form menuitem and the Itemid / view parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'category' view has an associated id (of the category record), and an SEF URL will use the category path down the Categories Nested Set table structure, hence <tt>setNestable()</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'helloworld' view has an associated id (of the helloworld record), and in an SEF URL in the category view the helloworld record alias is added to the category path (hence <tt>setParent()</tt>). But although the helloworld records use a Nested Table structure in the database, the URLs just include the alias of the single record, and so <tt>setNestable()</tt> is not used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There doesn't seem to be a way to configure an additional SEF URL scheme which just displays a helloworld segment, without a category segment.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====Traditional Router====
To use the traditional router in the tutorial code you should uncomment the function in the extension class:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return new TraditionalRouter($application, $menu, $this->categoryFactory, $this->getDatabase());
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will cause the code in site/src/Service/TraditionalRouter.php to be used. However, changes in the Joomla 4 router mean that the interaction between it and the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> methods have changed. This requires significant changes to the <tt>preprocess</tt> and <tt>build</tt> methods, but only a minor change to <tt>parse</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. Previously Joomla injected into the <tt>$query</tt> parameters the <tt>Itemid</tt> of the active menuitem (ie the id of the menuitem the user is currently on). This meant that we had to change the <tt>Itemid</tt> for links generated by the Language Switcher module (which generates the flags for switching between languages), and these links being associated with a different language would obviously use a different <tt>Itemid</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 you get an <tt>Itemid</tt> in the <tt>$query</tt> parameters only if you specified an <tt>Itemid</tt> in the <tt>Route::_()</tt> call. For others you have to work out which menuitem to use yourself, by using the Joomla menu/menuitems API to find details of the configured menuitems, and work out which to use based on the other <tt>$query</tt> parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You do this in the <tt>preprocess</tt> method, and then the <tt>Itemid</tt> you set will be passed in the <tt>$query</tt> parameters to the <tt>build</tt> method.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. In some instances the <tt>Route::_()</tt> URL you're generating matches exactly one of the configured menuitems on the site. In this case the <tt>$query</tt> parameters will match those in the menuitem <tt>"query"</tt> array, and you have to remove explicitly remove the 'view', 'id' and 'catid' parameters so that they don't appear as URL query parameters after the normal SEF URL of the menuitem.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
3. The custom router will be used to build the URLs for the helloworld menuitems shown in menus on the page. For these the <tt>$query</tt> parameters will have the view / id / catid associated with those menuitems. Note that even if you remove these in your <tt>preprocess</tt> method, Joomla will inject them again into the <tt>$query</tt> array when it's passed to your <tt>build</tt> method, so you'll have to remove them again there!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
4. In the <tt>parse</tt> method you now have to unset the <tt>$segments</tt>, or else Joomla will return an HTTP 404 (page not found). Otherwise <tt>parse</tt> works as before.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
5. I've implemented <tt>build</tt> only for when Multilanguage is enabled on the site. If it's not enabled an empty <tt>$segments</tt> array is just returned, without doing unset on any of the <tt>$query</tt> parameters, so these will appear as URL parameters after the SEF URL. Also it's not coded properly to deal with items which have language set to <tt>*</tt>. These include helloworld records, categories or menuitems (eg the helloworld form).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that the <tt>categoryFactory</tt> is also now passed to the router. This is so that it can be used instead of <tt>Categories::getInstance()</tt> to get access to the Categories API calls.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_tags===
Whenever we setup a Tags Menu Item Type which displays items having a given tag or tags, then <tt>com_tags</tt> displays those items as links, and uses route helper functions to generate the URL parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The route helpers <tt>com_tags</tt> expects to find loaded into the data of the <tt>#__content_types</tt> table, in the router field, and these have been set to:
* For links to helloworld items: 'HelloworldHelperRoute::getHelloworldRoute'
* For links to helloworld categories: 'HelloworldHelperRoute::getCategoryRoute'
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, <tt>com_tags</tt> doesn't boot the helloworld extension to get access to these, but rather seeks to find them in site/helpers/route.php, so that's where they continue to be.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(We also had a <tt>getCategoryRoute</tt> which was used by <tt>com_categories</tt> in administrator/components/com_categories/src/Helper/CategoryAssociationHelper. When a category was displayed on the frontend then the Language Switcher module (now Language Filter) used this function to generate the links to the Associated Categories. Our <tt>getCategoryRoute</tt> previously was necessary to insert the <tt>lang=<language tag></tt> parameter into the link URL, but since [https://github.com/joomla/joomla-cms/pull/39358 this change] the calling function inserts the <tt>lang</tt> parameter itself, so our <tt>getCategoryRoute</tt> function for this purposes is superfluous.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Deprecated APIs ==
With Joomla 4 there are a number of methods which are deprecated, with a view to removing them in Joomla 5.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Factory Methods===
Many of the <tt>Factory</tt> methods for getting singleton classes have been deprecated in favour of getting these classes via the DI container, and it appears that only class instances which should be obtained via Factory methods are:
* the Application – <tt>Factory::getApplication()</tt>
* the DI container – <tt>Factory::getContainer()</tt>
Here is a list of what has been changed in the tutorial code. Note that with some calls there are variants available, through the aliases defined in the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDbo'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\Database\DatabaseInterface;
...
$db = Factory::getContainer()->get(DatabaseInterface::class);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, in many classes the database instance is more easily (and efficiently) returned via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$db = $this->getDatabase();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is available in Model classes, custom field definitions, etc.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getUser();'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get the current user use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = Factory::getApplication()->getIdentity()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get a different user (whose id you know):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\User\UserFactoryInterface;
...
$user = Factory::getContainer()->get(UserFactoryInterface::class)->loadUserById($userid);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within models which extend Joomla\CMS\MVC\Model\BaseDatabaseModel and views which extend Joomla\CMS\MVC\View\HtmlView you can also use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = $this->getCurrentUser()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDocument()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication()->getDocument()</tt>, or within a View you can use <tt>$this->document</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getConfig()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Two options have been used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->getConfig()</tt> – returns a Registry object containing all the configuration values
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->get('access')</tt> – returns the value of the 'access' configuration parameter
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getLanguage()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication->getLanguage()</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JFactory::getCache('com_example', <type>)'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Cache\CacheControllerFactoryInterface;
...
Factory::getContainer()->get(CacheControllerFactoryInterface::class)->createCacheController(<type>)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated getInstance Methods===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general <tt>getInstance()</tt> calls have been deprecated in favour of obtaining the instance, either via a factory class or via the DI container. For example, within a controller you can use <tt>getModel()</tt> repeatedly to get different models (passing the relevant model names), which results in the MVCFactory class creating the Model classes.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there are currently some problems with replacing some getInstance calls. I expect that the Joomla team will resolve these issues over the course of the Joomla 4 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Categories::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is deprecated with a notice: "Use the ComponentInterface to get the categories". This means that we should get the category factory instance via the DI container. This is done in our services/provider.php by the lines:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Extension\Service\Provider\CategoryFactory;
...
$container->registerServiceProvider(new CategoryFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to put into our child DI container the closure which will create a Joomla\CMS\Categories\CategoryFactory instance, constructed with our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when our HelloworldComponent (Extension) instance is created:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We can then use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getCategoryFactory()->createCategory();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to create our Categories object, and in this way get access to the Categories APIs.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This createCategory method creates the instance by looking for the \\Site\\Service\\Category class within our namespace. The constructor in our class sets our extension ('com_helloworld') and table ('#__helloworld') and calls the parent Categories constructor with these options).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this means that the section of our code where we want to use the Categories APIs must have a pointer to a CategoryFactory instance. In the tutorial code for Joomla 3 there are 2 places where <tt>Categories::getInstance</tt> is used:
* in the custom router code, to handle building and parsing of the category parts of the SEF URL
* in the site category model, where the Categories APIs are used to obtain details of categories to display on the page.
For the custom router code, the CategoryFactory instance is passed as a parameter to the TraditionalRouter constructor so that it can be used there.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, the site category model is instantiated by the MVCFactory instance, and it doesn't make available a CategoryFactory instance. So in this category model the calls to <tt>Categories::getInstance()</tt> have been left, and you can still find a number of calls to <tt>Categories::getInstance</tt> within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Categories::getInstance()</tt> itself solves the problem of access to a CategoryFactory instance by rebooting our component again to get a pointer to our Extension instance, and thus to the category factory instance. However, this involves a lot of work, so <tt>getInstance</tt> caches locally the Categories instances and just returns one of them if it can.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Pushing the CategoryFactory to the model'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there is a way to get access to the CategoryFactory instance, by defining your own MVCFactory class, and pushing the instance down through it to the model. Here's how you can go about it:
* Define your own SuperMVCFactory class, which extends the Joomla Joomla\CMS\MVC\Factory\MVCFactory class, but which has a means of storing a CategoryFactory instance. Use the CategoryServiceTrait in libraries/src/Categories/CategoryServiceTrait.php
* Create your own version of the file libraries/src/Extension/Service/Provider/MVCFactory.php, which is the 'provider.php' like file for MVCFactory, but change it so that:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
becomes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new <namespace>\SuperMVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and include
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla creates a model such as CategoryModel it passes in its constructor the MVCFactory instance (so that the model can call createTable on it), so you can access it via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will return your SuperMVCFactory instance. So in this way within the model you can access the CategoryFactory, and use it to create the Categories instance via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()->getCategory() (from the CategoryServiceTrait)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you can get this working you can congratulate yourself on a good understanding of Joomla namespacing and dependency injection! A similar approach to address a similar problem is described [https://www.dionysopoulos.me/book/com-router-push-dependencies.html here]. If you get stuck you can always view the solution by viewing the github tutorial code selecting the branch [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial/tree/push-category-factory-to-mvc push-category-factory-to-mvc].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Table::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There are a couple of calls to <tt>Table::getInstance()</tt> within admin/src/Helper/AssociationsHelper.php in <tt>getItem()</tt>:
* <tt>Table::getInstance('Helloworld', 'Robbie\\Component\\Helloworld\\Administrator\\Table\\')</tt> to get an instance of our HelloworldTable class.
* <tt>Table::getInstance('Category')</tt> to get an instance of the Category table in libraries/src/Table/Category.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We could actually arrange for the AssociationsHelper class to get injected with the MVCFactory instance, so that the HelloworldTable class could be instantiated by it. However, we couldn't use the helloworld MVCFactory instance to create the Category table instance, as it's not in the helloworld namespace, and our MVCFactory instance creates table instances within our namespace only.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Toolbar::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The tutorial code uses <tt>Toolbar::getInstance()</tt> to get a Toolbar instance onto which it can attach the batch button in the helloworlds form. The Toolbar API documentation seems to suggest that we should replace
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Toolbar::getInstance('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
with
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this currently won't work. The problem is that all the other Joomla code uses <tt>getInstance('toolbar')</tt> to access the Toolbar class, including the code in administrator/modules/mod_toolbar/mod_toolbar.php which renders the toolbar. The <tt>getInstance</tt> method keeps track of the Toolbar instances in a local static variable <tt>$instances</tt>, and returns the same Toolbar instance on repeated invocations.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you use the second approach above you will get a Toolbar instance, but it won't be the same Toolbar instance as is stored in the <tt>$instances</tt> variable. It won't then be picked up by the Toolbar module, and so won't be rendered on the form.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Error Handling===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead of
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
JError::raiseError(500, implode('<br />', $errors));
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
you should throw an exception, using or extending one of the standard [https://www.php.net/manual/en/spl.exceptions.php PHP exceptions], eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
throw new \Exception(implode("\n", $errors), 500);
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===jimport===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
jimport is no longer necessary in order to get access to Path or File classes. All of the Joomla classes are found by the autoloader.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Methods related to Javascript===
'''JHtml::_('behavior.framework');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general, the use of JHtml::_('behavior.xxx') is now obsolete, and calls using this have been removed in the tutorial code. The 'behavior.framework' call referred to including jQuery. Where jQuery is necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.formvalidator');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by the <tt>form.validate</tt> javascript asset, and where necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It can also be included directly using the web asset manager:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$wa->useScript('form.validate')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.tooltip')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This no longer exists, and tooltips don't seem to be enabled by default in Joomla 4. This is replaced by the code in media/js/enable-tooltips.js.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('formbehavior.chosen')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The chosen js library seems to be no longer used, and using it will cause formatting issues if you include it in your tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''sortable'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The sortable js library provided the ability in the helloworlds view to drag rows up and down to change the ordering of the records. This has been replaced in Joomla 4 by the draggable library. To enable it you have to set:
* <tt>HTMLHelper::_('draggablelist.draggable');</tt>
* on your <tt><tbody></tt> element define the table in which dragging occurs and the URL of the Ajax call to set the ordering:
<source lang="php">
<tbody<?php if ($saveOrder) : ?> class="js-draggable" data-url="<?php echo $saveOrderingUrl; ?>" data-direction="<?php echo strtolower($listDirn); ?>" data-nested="true"
<?php endif; ?>>
</source>
* on your <tt>tr</tt> element within your <tt><tbody></tt> define the group of records in which dragging occurs (by category below):
<source lang="php">
<tr class="row<?php echo $i % 2; ?>" data-draggable-group="<?php echo $row->catid; ?>">
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==HTML Snippets==
There are two places in the tutorial where reusable snippets of HTML have beeen defined:
* For displaying the item associations in the helloworlds view:
* For displaying the position latitude and longitude fields within the batch options in the helloworlds view
These used different approaches:
* the item associations display was coded in an html helper file in admin/helpers/html/helloworlds.php and accessed via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JHtml::_('helloworlds.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
in the helloworlds tmpl file. (Although it did use a common joomla layout file underneath).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* the position field was coded as a layout in layouts/position.php, and rendered using
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JLayoutHelper::render('position', array());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When should you use one approach rather than the other? A significant difference is that layouts are designed so that an administrator can override them, via the Templates / Details and File functionality. So, for example, an administrator could change the position to show the longitude before the latitude. So it's more appropriate for layouts to focus on the html elements rather than functional logic, and particularly if you would want to allow an administrator to override the layout.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The layouts functionality in Joomla 4 hasn't changed significantly. One correction which has been made in the updated tutorial code has been to include the position.php file in a subfolder of layouts, ie in admin/layouts/helloworld/position.php rather than admin/layouts/position.php. It appears that in the Templates / Details and Files / Create Overrides tab the <tt>com_helloworld</tt> layout appears only if it's in a subfolder of /layouts.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>JHtml::_()</tt> approach has changed in Joomla 4. Rather than Joomla having to look for a helper file when it encounters something it doesn't recognise, it's expected that you should register such classes beforehand, and you do this by obtaining an instance of the Joomla\CMS\HTML\Registry class (it's a singleton class) and then calling <tt>register</tt> on it, passing
* the key you want to use
* an instance of your class
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Joomla pattern is to put the code in a file admin/src/Service/HTML/AdministratorService.php, and we have to ensure that our key won't be used elsewhere within Joomla, so in the tutorial we've used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Robbie\Component\Helloworld\Administrator\Service\HTML\AdministratorService;
...
register('helloworldadministrator', new AdministratorService)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when we call:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo HTMLHelper::_('helloworldadministrator.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will result in Joomla calling the <tt>association</tt> method in our class, passing the <tt>$row->id</tt> parameter.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We should get the Joomla\CMS\HTML\Registry class from the Dependency Injection container. Joomla components generally do this via their services/provider.php file, and then call <tt>register</tt> within the extension's <tt>boot</tt> function, described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Step_5_Call_boot.28.29_on_our_Component|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The extension uses HTMLRegistryAwareTrait which contains <tt>setRegistry</tt> and <tt>getRegistry methods</tt>. In services/provider.php there is:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\HTML\Registry;
...
$component->setRegistry($container->get(Registry::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets 'Joomla\CMS\HTML\Registry' out of the DI container and stores it within the
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
private $registry;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
variable of the HTMLRegistryAwareTrait included in the extension.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the <tt>boot</tt> function it calls
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getRegistry()->register('helloworldadministrator', new AdministratorService);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets the registry and calls <tt>register</tt> as required.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that <tt>boot</tt> is called whenever Joomla dispatches <tt>com_helloworld</tt>, both for the site and administrator, so it would make sense to check the Application <tt>isClient</tt> before deciding whether to register the HTML Helper service or not. This hasn't been included in the tutorial code though.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==User Interface Changes==
Joomla 4 introduced new templates, atum on administrator and cassiopeia on site, and in particular the administrator is built upon some UI rearrangements which affect the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Sidebar===
In Joomla 3 each component incorporated a sidebar which we coded in the <tt>addSubmenu</tt> function in admin/helpers/helloworld.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the administrator menu is in a vertical panel on the left hand side, and the Hello World submenu is built from entries in the helloworld.xml manifest file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<administration>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<submenu>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<menu link="option=com_categories&extension=com_helloworld">COM_HELLOWORLD_CATEGORIES</menu>
<menu link="option=com_fields&view=fields&context=com_helloworld.helloworld">MOD_MENU_FIELDS</menu>
<menu link="option=com_fields&view=groups&context=com_helloworld.helloworld">MOD_MENU_FIELDS_GROUP</menu>
</submenu>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===CSS Classes===
In several places the CSS classes defined in the html elements have been changed in Joomla 4. For example, for general layout the classes now align with the [https://getbootstrap.com/docs/3.4/css/ Bootstrap CSS Classes], and classes such as <tt>row-fluid</tt> and <tt>span3</tt> which were prominent in Joomla 3 have disappeared. If you're upgrading a Joomla 3 component then it's probably best (on the back-end at least) to find a similar Joomla component and use the overall html structure and css classes within its tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the tutorial code those classes which are specifically used by Bootstrap have been changed from eg 'data-target' to 'data-bs-target', and it has been necessary to change these to enable the functionality to work.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, not all of CSS class changes affecting solely the presentation have been reflected in the updated tutorial code. For example, in the <tt>helloworlds</tt> view, showing the list of helloworld messages, the display of the associations is different from that of other Joomla components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Fonts===
In Joomla 3 [[J3.x:Joomla_Standard_Icomoon_Fonts|Icomoon Fonts]] were used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 Font Awesome's free icons are used, and you can see what is available on their [https://fontawesome.com/v5/cheatsheet cheatsheet]. The icons are implemented using CSS pseudo-elements, as described [https://fontawesome.com/v5/docs/web/advanced/css-pseudo-elements here]. Basically they convert a CSS class into html content, namely a unicode value in the private use range. A couple of these have been implemented in the frontend form, in the Save and Cancel buttons, for example:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>span class="icon-cancel">/span <?php echo Text::_('JCANCEL') ?></tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(with angle brackets removed from the <tt>span</tt> tags to stop the icon just being displayed by the browser).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This class is defined in media/system/css/joomla-fontawesome.css (where you can find the list of icon classes supported):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
.icon-cancel:before {
content: "\f00d";
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so this includes in front of the text the unicode character <tt>f00d</tt>, which you can see on the cheatsheet as "times", and displayed as <span class="icon-cancel"></span>. You can also use <tt>fa-</tt> plus the icon name on the font awesome cheatsheet page. If you use Icomoon icon names in your code which you run under Joomla 4, then the icon displayed will be a Font Awesome icon (if there's one with the same name) or it will use a mapping which the Joomla team have defined to display a Font Awesome icon which resembles the Icomoon one.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Buttons and Links===
An accessibility principle is that <tt><a></tt> html elements should be used for links to other web pages, and <tt><button></tt> elements should be used for actions, eg on a form. To align with this, the <tt><a></tt> elements in the helloworld modal field (defined in admin/src/Field/Modal/Helloworld.php) have been changed to <tt><button></tt> elements. These are the Select and Clear buttons displayed when choosing a Helloworld record for a menuitem pointing to a Helloworld message. (The buttons also include fontawesome icons, by the way).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This change was actually made in Joomla in one of the Joomla 3 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Categories View===
In the Categories view of standard Joomla components there now appears columns which show for each category the number of items, split by published status. This is populated by <tt>com_categories</tt> calling each extension's <tt>countItems</tt> function, as described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_categories|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Miscellaneous Changes==
===Version History===
In Joomla 3 the tutorial code used the <tt>JTableObserver</tt> functionality to copy relevant changes from the Helloworld and Categories tables into the UCM tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it uses a plugin mechanism to subscribe to Table events 'onTableAfterStore' and 'onTableBeforeDelete'. The plugin can be found in plugins/behaviour/versionable, and it is activated by Joomla as part of its application initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The copying of fields from the table works roughly the same way as before, except that the name of the table where the versions are stored is now <tt>#__history</tt>, so the entries which have to be inserted into the <tt>#__content_types</tt> table are fairly similar. Because the folders in which forms are stored has changed in Joomla 4, the 'formFile' parameter is different (remember that this is where Joomla gets the field labels in order to display the Preview within the Versions modal window, otherwise just the names of the database columns will be output).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here's a summary of what needs to be done to enable versioning under Joomla 4. The Versioning Traits and Interface definitions are found in libraries/src/Versioning:
* Enter data into content_types database table
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Storing the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The Table class must implement VersionableTableInterface and provide <tt>getTypeAlias()</tt>, which returns 'com_helloworld.helloworld'. This type alias + the helloworld record id is used as the key to identify versions in the <tt>#__history</tt> table.
* Define <tt>save_history</tt> and <tt>history_limit</tt> options in config.php, and ensure these are both set.
* Add a <tt>version_note</tt> field into the output of the edit view's tmpl file (admin/tmpl/helloworld/edit.php).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Viewing and Restoring the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit Controller (admin/src/Controller/HelloworldController.php) should <tt>use VersionableControllerTrait</tt>.
* The edit Model (admin/src/Model/HelloworldModel.php) should <tt>use VersionableModelTrait</tt> and include a variable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public $typeAlias = 'com_helloworld.helloworld';
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit View (admin/src/View/Helloworld/HtmlView.php) – should display the Versions toolbar button if global config has <tt>save_history</tt> on.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Joomla 4 allows us to have different history version limits for helloworld items and categories, and this has been used in the configuration definition in admin/config.xml.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Setting Configuration Parameters in Install Script===
As you may remember, global configuration parameters relating to the Hello World component are defined in admin/config.xml and stored in the <tt>#__extensions</tt> table, in a JSON string in the params field of the record relating to <tt>com_helloworld</tt>. This means that when the component is first installed the params are not set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So, for example, even if the <tt>save_history</tt> is defined in config.xml to default to true, the versions won't be saved until an administrator actively saves the configuration parameters, because the Joomla versioning code assumes <tt>save_history</tt> to be false if it's not explicitly set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For this reason it makes sense to set any default configuration parameters in the install script.php, in the <tt>postflight</tt> method, and that has been done in this step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Tags===
Like version history, tags functionality has been changed to use a plugin – in plugins/behaviour/taggable – rather than the <tt>JTableObserver</tt> approach.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To enable tags the component table must implement TaggableTableInterface (in libraries/src/Tag), and provide the <tt>getTypeAlias()</tt> which is common to the Versioning functionality.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Whenever <tt>com_tags</tt> outputs helloworld messages or categories relating to a tag it displays them as links, and looks in the site/helpers/route.php file to find the route functions (as described above in [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_tags|com_tags]]). The class and method in this file must match the 'router' field within the data entered into the <tt>#__content_types</tt> table.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===media files===
Under Joomla 4 all of the media files are stored in the /media folder; these include javascript and css files (scss files too), as well as images such as the little flag symbols shown in the language switcher. Extensions being developed should store all of the js and css files in their /media folder, and then when the extension is installed these files are put under the extension's folder under the /media folder of the Joomla instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Patches==
Some bugs in Joomla were discovered during the course of updating the tutorial code to work under Joomla 4. If you find something doesn't work then make sure you're on at least Joomla 4.2.6 and check if you need one of the following patches:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
CategoryAssociationHelper.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39358/files
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
MediaField.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/issues/39203
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Category restore
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39474
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Contributors ==
*[[User:Robbiej|Robbie Jackson]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Prev: Adding Custom Fields|class=expand success}}</div>
</div>
</div>

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/23/it

2023-05-27T12:45:40Z

Ing Pulizzi: Created page with "Si noti in particolare come sono ora organizzati i file della classe <tt>View</tt>."

Si noti in particolare come sono ora organizzati i file della classe <tt>View</tt>.

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/22/it

2023-05-27T12:45:32Z

Quindi il namespace che specifichi nei tuoi file di classe deve essere allineato con il percorso del tuo file PHP, sotto la cartella di base <tt>src</tt> nel prefisso del tuo namespace.

J3.x:Developing an MVC Component/Upgrading to Joomla4/it

2023-05-27T12:44:41Z

Ing Pulizzi: Created page with "In Joomla 4 genera il nome completo della classe che vuole trovare, quindi cerca di trovarlo nella posizione in cui la raccomandazione PSR-4 lo aspetterebbe."

<noinclude><languages /></noinclude>

{{:J3.1:Developing an MVC Component/it}}
Questo passaggio copre ciò che è coinvolto nell'aggiornamento del codice del tutorial per allinearlo con la versione 4 di Joomla.

== Introduzione ==
Questa pagina descrive i principali aspetti relativi allo sviluppo dei componenti che sono stati introdotti in Joomla 4 e descrive in dettaglio cosa è stato modificato nel codice del tutorial per allinearsi con v4.

Non è pratico dettagliare tutte le modifiche al codice sulla pagina Web come è stato fatto per i passaggi precedenti dell'esercitazione. Invece puoi trovare il codice come repository github su [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial Joomla 4 Tutorial code], e puoi confrontarlo con il codice del passaggio precedente del tutorial (Adding Custom Fields) su [https://github.com/robbiejackson/Joomla-3-MVC-Tutorial Joomla 3 MVC code]. Il codice di Joomla 4 replica tutte le funzionalità del codice di Joomla 3, con l'eccezione dell'implementazione dell'icona del piccolo pinguino introdotta in [[S:MyLanguage/J3.2:Developing an MVC Component/Adding decorations to the backend|Aggiunta di decorazioni al backend]] (che non è così rilevante data la modifica dell'interfaccia utente in Joomla 4 Administrator) e l'uso di un plug-in CAPTCHA ([[J3.x:Developing an MVC Component/Adding a frontend form|Adding a frontend form]] ). Probabilmente troverai utile avere a portata di mano questo codice Joomla 4 a cui fare riferimento mentre leggi questa pagina.

Il codice per questo passaggio è stato sviluppato seguendo ciascuno dei precedenti passaggi del tutorial e cercando di far funzionare ogni passaggio con Joomla 4.2.5. Poiché Joomla 4 si sta ancora evolvendo abbastanza velocemente, è possibile che alcuni aspetti qui citati vengano modificati durante la vita di Joomla 4. Sentiti libero di correggere gli aspetti in questa pagina e creare richieste pull su [https://github.com/robbiejackson /Joomla-4-MVC-Tutorial Joomla 4 github repository].

Se stai installando il codice del tutorial di Joomla 4 su una nuova istanza di Joomla, dovrai configurare la tua istanza per renderla multilingue e aggiungere le voci di menu nascoste di Ajax come descritto nel passaggio [[J3.x:Developing an MVC Component/ Utilizzo del filtro della lingua |Utilizzo del filtro della lingua]]. Assicurati inoltre che ogni record helloworld abbia una categoria valida.

=== Ulteriori letture ===
Puoi trovare [https://blog.astrid-guenther.de/en/der-weg-zu-joomla4-erweiterungen/ qui] un tutorial per lo sviluppo dei componenti di Joomla 4, simile a questo Joomla 3, e alcuni eccellenti Joomla 4 è disponibile anche la documentazione [https://www.dionysopoulos.me/book.html qui]. Entrambi questi riferimenti includono descrizioni degli impatti di Joomla 4 sullo sviluppo di altri tipi di estensioni Joomla (plugin, moduli e modelli), che non sono trattati qui.

Questo passaggio non copre tutto ciò che è necessario per aggiornare un componente da Joomla 3 a Joomla 4, solo gli aspetti coperti dal codice del tutorial. Se stai aggiornando il tuo componente Joomla 3, potresti trovare utile esaminare [[Potenziali problemi di compatibilità con le versioni precedenti in Joomla 4]].

== NameSpace ==
===NameSpace dei nomi dei componenti===
I NameSpace delle classi che utilizza la [https://www.php-fig.org/psr/psr-4/ PSR-4 recommendation] è stato gradualmente introdotto durante le versioni di Joomla 3 e con Joomla 4 è praticamente tutto con NameSpace

Ora è previsto che anche le estensioni di Joomla utilizzino i NameSpace di base per l'estensione definito nel suo file XML manifest. I componenti di Joomla usano uno NameSpace della forma <tt>Joomla\Component\<Nome componente></tt> es. <tt>Joomla\Component\Content</tt>, quindi seguendo questo schema ho dato una base al codice del tutorial spazio dei nomi di <tt>Robbie\Component\Helloworld</tt>. Ecco la riga nel file manifest helloworld.xml:

<namespace path="src">Robbie\Component\Helloworld</namespace>

(L'attributo <tt>path="src"</tt> indica che si aspetterà che le classi si trovino nella sottocartella <tt>src</tt>.)

Questo in realtà crea 2 prefissi dello spazio dei nomi, che puntano a cartelle specifiche nella nostra struttura di sviluppo helloworld e nella nostra istanza joomla live:

<tt>Robbie\Component\Helloworld\Administrator</tt> – punterà ad administrator/components/com_helloworld/src sull'istanza live ed è associato ad admin/src nella nostra area di sviluppo.

<tt>Robbie\Component\Helloworld\Site</tt> – punterà a components/com_helloworld/src sull'istanza live ed è associato a site/src nella nostra area di sviluppo.

Quindi Joomla ora si aspetta che tutti i nomi delle classi vengano trovati in quelle directory di base, con il nome del file che corrisponde al nome della classe e il nome della classe completo che corrisponde al percorso, ad esempio

<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> si troverà in
administrator/components/com_helloworld/src/Controller/DisplayController.php

<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> si troverà in
components/com_helloworld/src/Model/CategoryModel.php

'''Nota che le lettere maiuscole sono importanti nei namespace, nei nomi delle classi e nei nomi dei percorsi!'''

Quando Joomla 3 ha voluto chiamare le funzioni nel tuo componente, ha cercato determinati nomi di file in cartelle particolari e ha verificato che il nome della classe in quel file corrispondesse a quello previsto.

In Joomla 4 genera il nome completo della classe che vuole trovare, quindi cerca di trovarlo nella posizione in cui la raccomandazione PSR-4 lo aspetterebbe.

<div lang="en" dir="ltr" class="mw-content-ltr">
Hence the namespace you specify in your class files must align with the file path to your PHP file, below the base <tt>src</tt> folder at your namespace prefix.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note in particular how the <tt>View</tt> class files are now organised.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Also if you use one of the PHP predefined classes (eg <tt>Exception</tt>) in your code, then add a backslash before it (eg <tt>\Exception</tt>), otherwise PHP will try and find it in your namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you use custom Field or Rule definitions in your form xml files then you have to indicate to PHP which namespace prefix to use to look for them, eg in <tt>site/forms/add-form.xml</tt>:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
addruleprefix="Robbie\Component\Helloworld\Administrator\Rule"
addfieldprefix="Robbie\Component\Helloworld\Administrator\Field"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and also in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> where the associations are added into the form dynamically to form the custom <tt>modal_helloworld</tt> type field:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Class Autoloading===
Joomla uses the PHP mechanism for [https://www.php.net/manual/en/language.oop5.autoload.php Autoloading Classes] and on startup registers a number of autoloaders – functions which get called when PHP can't find a given class. In particular the Joomla PSR-4 autoloader function (in <tt>libraries/loader.php</tt>) is responsible for finding classes of Joomla extensions whose code is in source files which are organised according to the PSR-4 recommendation. (Joomla library classes are autoloaded using a different autoloader – see <tt>libraries/vendor/composer/autoload_static.php</tt>).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can see the namespace prefixes of extensions on the Joomla instance by looking at <tt>administrator/cache/autoload_psr4.php</tt>. (These namespace strings have double backslashes, but in PHP they're the [https://stackoverflow.com/questions/25459197/single-or-double-slash-when-using-php-namespace same strings as those with single backslashes]). This is generated by Joomla looking through the component, module and plugin directories to find each extension's manifest file, and then processing these xml files to extract the <tt><namespace></tt> element – quite a lot of work, which is why it's cached I guess!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider what happens when Joomla wants our admin HelloworldController class. It might have something like
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$classname = 'Robbie\Component\Helloworld\Administrator\Controller\HelloworldController'
if (!class_exists($classname)) { …
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Assuming PHP doesn't already know about this class, the <tt>class_exists</tt> function will result in the classname being passed to the registered autoload function(s). The PSR-4 autoloader will then:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# go through its array of namespaces to try and match <tt>$classname</tt> from the start of the string.
# find 'Robbie\Component\Helloworld\Administrator' as a match
# see that this maps to "administrator/components/com_helloworld/src"
# extract the remainder of the classname: 'Controller\HelloworldController'
# treat this as the path down to the class file
# and so look for "administrator/components/com_helloworld/src/Controller/HelloworldController.php"
# check that in this file there's actually a class with that namespace + class name.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So in this way Joomla can go from a fully qualified class name to find the source code for that class. This makes it easier for us too when the core Joomla code is looking for one of our classes. We still need to know what class it's looking for, but once we know that, we know what we should call our class and where we should save the source code for it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Joomla Library classes===
Originally Joomla's core classes (beginning with a capital J) were global classes. Over the Joomla 3 versions and into Joomla 4 these migrated to their namespaced equivalents, but the original global classnames were still available as Joomla registered them as aliases (in the <tt>libraries/classmap.php</tt> file).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In a Joomla 4 extension you can still use these global classnames, except that in a namespaced file you'd have to prefix the name with a backslash to indicate a global class rather than one in your namespace (eg <tt>\JFactory</tt> instead of <tt>JFactory</tt>).
However it's pretty definite that the aliases will disappear at some stage, so the upgrade to Joomla 4 seems an appropriate opportunity to replace all your component's calls to the global JSomething classes to the namespaced equivalents. This involves adding the appropriate <tt>use</tt> statements, and all this has been done in the tutorial code. A useful mapping between the two can be found [https://github.com/nikosdion/joomlatypehints/blob/main/JoomlaObsoleteClasses.md here], where the new qualified classname can be copied and pasted into a <tt>use</tt> statement in your PHP file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
With reference to the [https://api.joomla.org/ Joomla API Documentation] there are 2 Joomla library namespaces:
* Joomla CMS classes – have namespaces <tt>Joomla\CMS\Something</tt> – are found under <tt>libraries/src/Something</tt>
* Joomla Framework classes – have namespaces <tt>Joomla\Something</tt> – are found under <tt>libraries/vendor/joomla/something/src</tt>
So a big advantage of namespacing is that you can immediately determine from the fully qualified class name in a PHP <tt>use</tt> statement where the source for that class exists in the <tt>libraries</tt> directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
On the other hand class names which aren't fully qualified don't have to be unique, eg <tt>MVCFactory</tt>
* occurs as <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in <tt>libraries/src/Extension/Service/Provider/MVCFactory.php</tt>
* occurs as <tt>Joomla\CMS\MVC\Factory\MVCFactory</tt> in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>
so sometimes you have to be careful to examine the <tt>use</tt> statement to identify the right class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly our FormModel class in <tt>site/src/Model/FormModel.php</tt> can have the same FormModel classname as the Joomla FormModel in <tt>libraries/src/MVC/Model/FormModel.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The API documentation gives the methods available in each of the [https://api.joomla.org/cms-4/namespaces/joomla.html Joomla CMS] and [https://api.joomla.org/framework-2/namespaces/joomla.html Framework] classes, but just be aware that a Joomla CMS class may extend a Framework class, and in this case some methods may not be visible under the Joomla CMS documentation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For example, <tt>$app->setHeader()</tt> which is used to set the HTTP response code is not listed under the [https://api.joomla.org/cms-4/classes/Joomla-CMS-Application-CMSApplication.html CMS Application class API], but is available as a method because it inherits from the Framework class [https://api.joomla.org/framework-2/classes/Joomla-Application-AbstractWebApplication.html AbstractWebApplication].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Vendor Namespaces===
These are also in <tt>libraries/vendor</tt>, eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Psr\Container\ContainerInterface;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
refers to <tt>libraries/vendor/psr/Container/src/ContainerInterface.php</tt>. However there are few of these in the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other File Rearrangements===
With all of the namespaced classes moving under the src directories, the <tt>tmpl</tt> layout files and <tt>form</tt> xml files have been moved out into their own directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Extension and Dispatcher classes ==
===Extension===
In Joomla 3 the point where the Joomla core handed over to your component code was when it ran your <tt>helloworld.php</tt> code; if it was the frontend it ran your site <tt>helloworld.php</tt> code, or if was the backend it ran your admin <tt>helloworld.php</tt> code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the entry point into your component code is your Extension class, both for site and admin, found in <tt>admin/src/Extension/HelloworldComponent.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When the Joomla core application wants to start executing the component code it creates an instance of <tt>HelloworldComponent</tt>, just to get a handle on the component code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly (as described below) other Joomla classes such as Router or Categories need to call certain Helloworld methods (eg custom router functions). In Joomla 3 these methods were written in certain Helper files etc. In Joomla 4 the principle is that the component creates an instance of the <tt>HelloworldComponent</tt> Extension class, and calls the required methods on that instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This Extension class isn't anything like a big container class for the component, it's more like a glue class, providing a way in to the Helloworld component, enabling the Joomla core and other components call the methods which they want to call.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla core wants to execute the component code, the key method it is looking for in your <tt>Extension</tt> instance is <tt>getDispatcher</tt>, and it expects to get back a <tt>Dispatcher</tt> instance. The <tt>HelloworldComponent</tt> extends <tt>MVCComponent</tt>, which in turn extends <tt>Component</tt>, and it is this class which defines <tt>getDispatcher</tt> for us.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Dispatcher===
When Joomla wants to run the Hello World component, it gets the <tt>Dispatcher</tt> instance as described above and then calls the <tt>dispatch</tt> method on it. It is this <tt>dispatch</tt> function which replaces the functionality in the admin and site <tt>helloworld.php</tt> files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's look at the main lines of code in our Joomla 3 admin <tt>helloworld.php</tt> file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="site/views/form/view.html.php">
<syntaxhighlight lang="php">
if (!JFactory::getUser()->authorise('core.manage', 'com_helloworld'))
{
throw new Exception(JText::_('JERROR_ALERTNOAUTHOR'));
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Get an instance of the controller
$controller = JControllerLegacy::getInstance('HelloWorld');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Execute the Request task method
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Redirect if set by the controller
$controller->redirect();
</syntaxhighlight>
</span>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code
* performs some permissions checks
* instantiates the appropriate Helloworld controller
* executes the appropriate method in that controller
* implements any redirect set by the controller
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Model-View-Controller]] for further details of how this works in Joomla 3. The second and third steps used the <tt>task</tt> parameter within the URL query to determine the correct controller class to instantiate and method to call. If no <tt>task</tt> parameter was present then it instantiated the controller in <tt>controller.php</tt> and called the <tt>display</tt> method. Otherwise it instantiated one of the controllers in the <tt>controllers</tt> subfolder (eg <tt>controllers/helloworld.php</tt>) and called the appropriate method on it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>ComponentDispatcher::dispatch</tt> method (in <tt>libraries/src/Dispatcher/ComponentDispatcher.php</tt>) now provides this functionality, but in a nicer way. After checking the permissions it uses the <tt>task</tt> by considering its parts as <tt><controller type>.<method></tt> (taking 'display' as default if either part is missing). It will then pass control to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* an instance of the class <Controller type>Controller
* calling the function <method>
* using the admin or site controller, as appropriate
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In this way the naming of the controllers is consistent - we have DisplayController, HelloworldController and HelloworldsController, all in the same folder.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Dispatcher class can thus be considered as providing some 'routing - execution' functionality, enabling us to find the right controller and function within that controller, and it is cleaner to have this in a separate class rather than in the <tt>JControllerLegacy</tt> class as it was in Joomla 3.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Since the Hello World tutorial uses the standard Joomla pattern for selecting the class and method based on the <tt>task</tt> and has the same permissions checks, we can use the <tt>dispatch</tt> code as it stands in <tt>ComponentDispatcher</tt>, and don't need to define a special class of our own.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Factory classes ==
In Joomla 3 many classes had static <tt>getInstance</tt> methods which returned an instance of that class, configured with the parameters passed to <tt>getInstance</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the <tt>getInstance</tt> methods have been deprecated in favour of using Factory classes. The preferred mechanism is now to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* get an instance of the appropriate Factory class (how we do that is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below)
* call the <tt>createSomething()</tt> method of the Factory class with relevant parameter values to generate an instance of the Something class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===MVC Factory===
In this section the <tt>MVCFactory</tt> class refers to the one in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory class will instantiate Controller, View, Model and Table instances on our behalf, and it does this by generating the classname of the class and then calling <tt>new</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The way it works is as follows:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Each component gets an individual MVCFactory instance which is constructed passing the component's namespace as a parameter (so in our case 'Robbie\Component\Helloworld'). (How this MVCFactory instance is created is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below).
# The MVCFactory createController / createView / createModel / createTable function is then called, passing the name of the Controller / Model / View / Table and the prefix (which specifies whether the administrator or site class is required).
# The create function forms the classname from this data and calls <tt>new</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory create functions just form the classname from the parameters they're passed. The intelligence for working out what name and prefix should be used to form the appropriate classes for an incoming HTTP request is
* in the dispatcher code for defining the controller to use
* in the controller for the view and model
* in the model for the table
and, for example, the names of the classes created for a request with URL query <tt>?option=com_helloworld&view=viewname</tt> and no <tt>task</tt> parameter will be
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<namespace>\Controller\DisplayController
<namespace>\View\Viewname\HtmlView
<namespace>\Model\ViewnameModel
<namespace>\Table\ViewnameTable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you need an alternative name then you can override the appropriate getView, getModel or getTable function – as for example was done in the [[J3.x:Developing an MVC Component/Adding Custom Fields#Front-end_Form|Adding Custom Fields step, frontend Form section]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So from the outside this is pretty much the same as in Joomla 3. However, note that the <tt>$prefix</tt> parameter in calls to <tt>getModel</tt> etc is subtly different
* in Joomla 3 this referred to a prefix to be applied to the classname – in the tutorial code we used 'HelloWorldTable' as the prefix part of the 'HelloWorldTableHelloWorld' classname.
* in Joomla 4 this refers to a prefix higher up the classname path, and should be set to either 'Site' or 'Administrator' (the capital letter at the start is optional), depending on whether you want the class under 'Robbie\Component\Helloworld\Site' or 'Robbie\Component\Helloworld\Administrator'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVC Factory class is now the Joomla recommended way to create the controller, view, model and table classes, by using the eg <tt>getModel()</tt> method, and the use of <tt>getInstance()</tt> for these classes is now deprecated. However, the use of these functions is restricted:
* in the controller class you can call <tt>$this->getView($viewname, $viewtype, $prefix, $config)</tt> to create a view and <tt>$this->getModel($modelname, $prefix, $config)</tt> to create a model.
* in the view class you can call <tt>$this->getModel($modelname)</tt>, but only for models which the controller has previously defined using <tt>$view->setModel($modelname, $default)</tt>. It doesn't create a new model instance.
* in the model class you can call <tt>$this->getTable($tableclass, $prefix, $options)</tt> to create a table instance. Controllers and views can access the table classes in this way, by going via a model.
These restrictions do have an impact on moving away from using <tt>getInstance()</tt>, and indeed in Joomla 4.2.6 you will still find several <tt>getInstance()</tt> calls within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Factory Classes===
Several other Factory classes have been introduced in Joomla 4, enabling you to get instances of core classes such as Form, User, CacheController, etc, usually by calling a createSomething function on the Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Associated with the Factory class is a FactoryInterface, a PHP Interface which specifies the key functions which the Factory class must implement. For example, with <tt>libraries/src/Categories</tt> we have:
* CategoryFactoryInterface – which specifies the <tt>createCategory</tt> function
* CategoryFactory implements CategoryFactoryInterface – which provides the <tt>createCategory</tt> function.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Dependency Injection ==
===Overview===
The DI container is one of the significant new additions to Joomla 4. It's basically a repository of key-value pairs where:
* the key is a string which is the name of a class or interface
* the value is an instance of the relevant class, or a function that returns an instance of that class.
You put things into the container using <tt>set()</tt> passing:
* the class name or interface name
* a function which returns an instance of the class (or an instance of the class)
* a boolean defining whether the class instance may be shared or not
* a boolean defining whether this entry into the DI container is protected or not (an error will be raised if you try to overwrite a protected entry by calling <tt>set()</tt> again using the same key).
The function <tt>share()</tt> is basically the same as <tt>set()</tt> with the <tt>shared</tt> boolean set to true.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You get things out of the container by calling <tt>get()</tt> passing the key of the resource you want. The container will
* find the key in the container
* if the value isn't already a class instance, then it will run the associated function to generate an instance of the class
* if the resource is shared, it will store the class instance, so that on subsequent invocations of <tt>get()</tt> it can just return the instance
* return the class instance to you
You can also define aliases for each key in the container, which means that you call <tt>get()</tt> passing either the key or an alias of the key.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The DI container is initialised in <tt>library/src/Factory.php createContainer()</tt> which results in the <tt>register()</tt> function being called in each of the class files in <tt>libraries/src/Service/Provider</tt>. By looking through those files you can see what gets put into the DI container upon initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===JConfig Example===
Let's consider the example of JConfig which holds the system global configuration. If you look inside <tt>libraries/src/Service/Provider/Config.php</tt> then you'll see the <tt>register()</tt> function and that it stores in the DI container a resource with:
* key = 'JConfig'
* value = an anonymous function - which loads what's in <tt>configuration.php</tt> into a <tt>Registry</tt> object, and returns it
* shared flag = true (because the <tt>share()</tt> function is used)
* protected flag = true
Then when you do
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$config = $container->get('JConfig');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will run the anonymous function and return the Registry object to you. As the 'shared' boolean is set it will also store a copy of the class instance locally in the container to be returned on subsequent calls of <tt>get('JConfig')</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Justification===
What's the point of all this?
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The advantage of dependency injection is that it allows classes to be easily mocked for testing. The file <tt>libraries/src/Service/Provider/Config.php</tt> can be replaced to return to a DI container <tt>get()</tt> call a mock class instead of the usual <tt>JConfig</tt>. This is in comparison to Joomla 3 where <tt>Factory::getConfig()</tt> code directly reads the <tt>configuration.php</tt> into a Registry structure and returns it – which makes it harder to mock.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The [https://api.joomla.org/cms-4/classes/Joomla-CMS-Factory.html Factory API] has several functions which are marked as deprecated with advice to get the object from the DI container instead.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Several of the other Factory classes (eg Form, Language, Menu, User) are in the DI container – so that we can get an instance of them via eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Factory::getContainer()->get('Joomla\CMS\Toolbar\ToolbarFactoryInterface')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to get a Toolbar instance. However, this only works for singleton classes which aren't specific to the needs of a particular extension. We'll see shortly how to make it work for class instances which need to be specific to a component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As indicated above, Joomla is moving away from using the class static <tt>getInstance()</tt> functions. We can see now that this is not only because it's more pure from an object oriented perspective. But also creating class instances from the DI container, or from Factory objects which are obtained from the DI container, builds in the dependency injection which allows classes to be more easily mocked, and hence more easily tested.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==services/provider.php==
We're now finally in a good position to understand what's happening in our services/provider.php file, and we'll explore this by walking through what happens whenever this line in libraries/src/Component/ComponentHelper.php <tt>renderComponent</tt> is run:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is run whenever Joomla has worked out which component is to be run on the requested web page, and it wants to run that component to capture its output.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 1 Create Child DI Container===
Joomla first creates another DI container (initially empty) just for this component, and links it to the main DI container via a parent field in the child DI container structure.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Now whenever <tt>set()</tt> is called on this DI container the key-value pair is inserted into the child container. Whenever <tt>get()</tt> is called on it, the resource is obtained from the child container, but if it's not found there then the parent container is searched also.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 2 Run register() in provider.php===
Next we encounter these lines (in <tt>libraries/src/Extension/ExtensionManagerTrait.php</tt>), where <tt>$path</tt> contains the path of our helloworld admin/services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$provider = require_once $path;
// Check if the extension supports the service provider interface
if ($provider instanceof ServiceProviderInterface) {
$provider->register($container);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here we see 3 things:
# our provider.php should return some object (so that <tt>$provider</tt> gets set to something)
# what is returned should implement ServiceProviderInterface (you can see in <tt>libraries/vendor/joomla/di/src/ServiceProviderInterface.php</tt> what is expected)
# the code then runs the <tt>register</tt> function on that object, passing as a parameter the child DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider a minimal version of our provider.php file. This would actually support steps in the Joomla 3 tutorial up to and including the [[J3.x:Developing an MVC Component/Adding AJAX|Adding Ajax step]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {

public function register(Container $container): void
{
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
}
};
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As you can see from the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
this file does indeed return something – it returns an instance of an anonymous class, one that implements <tt>ServiceProviderInterface</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it's not sufficient to just provide the <tt>register</tt> function in the class, we also need to explicity state that the class implements <tt>ServiceProviderInterface</tt>. This now happens in several places in Joomla, so if you're debugging your component and wondering why a function you expect to be called isn't being called, then check to make sure that you don't have to explicitly add the appropriate <tt>implements <Interface></tt> clause to your class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Next we look at the 3 lines in the <tt>register</tt> function
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3a Registering our MVC Factory===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here our <tt>MVCFactory</tt> refers to <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in libraries/src/Extension/Service/Provider/MVCFactory.php, and you should have a look at this file. This is a file similar to our provider.php file, but it's a named class, and it doesn't return anything. When we do:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
new MVCFactory('\\Robbie\\Component\\Helloworld')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it creates an instance of this class, and in the constructor it stores locally in <tt>$this->namespace</tt> our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>registerServiceProvider</tt> function then calls the <tt>register</tt> function of this instance, which runs (in its minimalist form):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
MVCFactoryInterface::class,
function (Container $container) {
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
return $factory;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So what gets entered into our child DI container is a key-value pair with:
* key = MVCFactoryInterface::class (this is just a shorthand form to obtain a string of the fully qualified name – ie 'Joomla\CMS\MVC\Factory\MVCFactoryInterface')
* value = a function which returns an instance of <tt>\Joomla\CMS\MVC\Factory\MVCFactory</tt>.
This is our MVCFactory class which generates our Controllers, Views, Models and Tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Notice that we're passing our namespace as a parameter <tt>$this->namespace</tt>. Because this function is a closure, this variable will still be available when we run this function later, and when the MVCFactory class is instantiated the namespace will be passed into the constructor, stored locally, and then subsequently used to form the fully qualified names of our Controllers, View, etc. So this is how we get instantiated the MVCFactory class which is specific to our component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3b Registering the Dispatcher Factory===
Careful: ComponentDispatcherFactory refers to two different classes here!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This ComponentDispatcherFactory is Joomla\CMS\Extension\Service\Provider\ComponentDispatcherFactory in libraries/src/Extension/Service/Provider/ComponentDispatcherFactory.php. Similar to the above, the ComponentDispatcherFactory service provider class stores locally our namespace, and then when <tt>register</tt> is called it executes:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentDispatcherFactoryInterface::class,
function (Container $container) {
return new \Joomla\CMS\Dispatcher\ComponentDispatcherFactory($this->namespace,$container->get(MVCFactoryInterface::class));
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so a second entry is added to the child DI container with:
* key = ComponentDispatcherFactoryInterface::class
* value = a function which returns an instance of the ComponentDispatcherFactory (the other ComponentDispatcherFactory class!), where the class constructor will be passed the namespace ('\\Robbie\\Component\\Helloworld') and an MVCFactory instance, retrieved from the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that the code
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->get(MVCFactoryInterface::class)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
will get from the container an entry with key = 'Joomla\CMS\MVC\Factory\MVCFactoryInterface' – which is what we entered into the container in step 3a – and will run the function associated with this key, and then return the object which this function returns. This returned object will be an instance of '\Joomla\CMS\MVC\Factory\MVCFactory', constructed using our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3c Including the Extension===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will put into the child DI container a key-value pair with
* key = ComponentInterface::class
* value = the function which will create an instance of our <tt>HelloworldComponent</tt> (ie our Extension class), and pass into the constructor an instance of the ComponentDispatcherFactory class, retrieving what was entered into the child DI container in Step 3b.
It will call <tt>$container->get(MVCFactoryInterface::class)</tt>, getting an MVC Factory instance from what was entered into the DI container in Step 3a.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It will then associate our component with this MVC Factory instance via the <tt>setMVCFactory</tt> call. Significantly this will then allow our component to access this instance later, via a call to <tt>getMVCFactory</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3 Summary===
We have now got 3 entries in our child DI container, keyed by
* key = MVCFactoryInterface::class, value is a function returning an MVCFactory instance
* key = ComponentDispatcherFactoryInterface::class, value is a function returning a ComponentDispatcherFactory instance
* key = ComponentInterface::class, value is a function returning our HelloworldComponent, an instance of our Extension class.
The important aspect is that these entries are all aware of our namespace '\Robbie\Component\Helloworld' and will return instances of these classes which are specific to our Helloworld component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 4 Retrieving from the DI Container===
Joomla will then execute the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $container->get($type);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
where <tt>$type</tt> contains 'Joomla\CMS\Extension\ComponentInterface'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This starts the process of retrieving from the DI container the 3 entries which we put in, and will run our code in services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We end up with a HelloworldComponent instance, which has:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. a ComponentDispatcherFactory instance passed into the constructor, and which is saved locally by the constructor code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function __construct(ComponentDispatcherFactoryInterface $dispatcherFactory)
{
$this->dispatcherFactory = $dispatcherFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This code is in libraries/src/Extension/Component.php, in the class which our HelloworldComponent extends, via the class MVCComponent).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. an MVC Factory instance, stored by the HelloworldComponent <tt>setMVCFactory</tt> call
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 5 Call boot() on our Component===
Joomla calls:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
if ($extension instanceof BootableExtensionInterface) {
$extension->boot($container);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will call <tt>boot</tt> within our HelloworldComponent, and allows us to perform some initialisation within our component. We'll return to this later, in the section on [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#HTML_Snippets|HTML snippets]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note again that Joomla checks that our HelloworldComponent class implements BootableExtensionInterface before calling <tt>boot</tt>. It's not sufficient to just provide the <tt>boot</tt> function, we have to explicitly declare that our HelloworldComponent implements the interface.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 6 Get the Dispatcher===
Returning to our key line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
we have now accomplished the first part <tt>bootComponent($option)</tt>, and this has returned our HelloworldComponent instance. Now we call <tt>getDispatcher($app)</tt> on this instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This code is also in libraries/src/Extension/Component.php, in the Component class which our HelloworldComponent extends:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function getDispatcher(CMSApplicationInterface $application): DispatcherInterface
{
return $this->dispatcherFactory->createDispatcher($application);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We call <tt>createDispatcher</tt> on our ComponentDispatcherFactory class instance which we saved in Step 4. This code is in libraries/src/Dispatcher/ComponentDispatcherFactory.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createDispatcher(CMSApplicationInterface $application, Input $input = null): DispatcherInterface
{
$name = ucfirst($application->getName());

$className = '\\' . trim($this->namespace, '\\') . '\\' . $name . '\\Dispatcher\\Dispatcher';

if (!class_exists($className)) {
if ($application->isClient('api')) {
$className = ApiDispatcher::class;
} else {
$className = ComponentDispatcher::class;
}
}

return new $className($application, $input ?: $application->input, $this->mvcFactory);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code checks if we have our own Dispatcher class (our Helloworld tutorial doesn't, but <tt>com_users</tt> for example has its own). So it creates a <tt>ComponentDispatcher</tt> instance, and passes into its constructor the MVC Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that this ComponentDispatcherFactory instance is what was instantiated when it was retrieved from our child DI Container (from being inserted in step 3b), and hence it already knows about our namespace, and has a pointer to our MVCFactory class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 7 call dispatch()===
This is the final aspect to our line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We're now back to what was described in the Dispatcher section above, except that now we can see that this Dispatcher instance has a pointer to our MVC Factory instance (which knows about our namespace prefix), so when the Dispatcher code wants to create a Controller it can use that MVC Factory instance to instantiate it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's been a long and tortuous journey to get here, but the significant thing is that all of our key class instances have been obtained via the DI Container. If we want to mock out any of those classes for testing then all we need to do is replace the relevant services/provider file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Javascript and the Web Asset Manager ==
The web asset manager has been introduced in Joomla 4 and is well documented [[J4.x:Web_Assets|here]]. It provides a much-improved means of managing JS and CSS resources, and a framework for handling their dependencies.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Component Javascript and CSS files should now be stored in the <tt>media</tt> folder, and the Web Asset Manager used to register them and output them on specific web pages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following assets have been registered in the tutorial <tt>joomla.asset.json</tt>, and you should have a look at that file now.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.validate-greeting===
This is the code for client validation of the helloworld greeting field using a regex, and it is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it is dependent upon jQuery and the Joomla <tt>form.validator</tt> script, so those both get included as dependencies.
If we didn't have specific validation on our form then we would need to include explicitly the <tt>form.validator</tt> script in order for the basic Joomla field validation to be included, eg in the tmpl file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->document->getWebAssetManager()->useScript('form.validate');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that this requires us to have a <tt>class="form-validate"</tt> on the </tt><form></tt> html element.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.fix-permissions-ajax-call===
This is the code which copies the value from the greeting field into the title field, so that the Ajax calls setting the permissions work correctly. The js code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.enable-tooltips===
This is the code which enables bootstrap tooltips to operate, including allowing them to include html code. It's used to display the image as a tooltip within the admin <tt>helloworlds</tt> view.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.openstreetmap===
This is defined as a preset, comprising the helloworld js and css code for the map display, as well as the dependency named 'com_helloworld.openlayers' relating to the openlayers CSS and js code. The code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.admin-helloworlds-modal===
This is the js code for selecting an individual helloworld record within a modal, and passing its details to the form in the main window. Its code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===submitbutton.js===
In the Joomla 3 code we introduced in [[Special:MyLanguage/J3.2:Developing_an_MVC_Component/Adding_verifications|Adding Verifications]] a js file which controlled when the form was submitted. It differentiated between buttons such as <tt>Save</tt> (which submitted the form) and <tt>Cancel</tt> (which didn't).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 there is a more sophisticated version of <tt>Joomla.submitbutton</tt> (found in media/system/js/core.js) which uses the CSS classes which the Toolbar functionality sets on the buttons to determine whether the form should be submitted or not. And you can override whether the validation is performed by adding a third parameter to the <tt>submitbutton</tt> js call. For example, to avoid validation being performed when a button is clicked you can set on the button element:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
onclick="Joomla.submitbutton('controller.method', '', false)"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As this is sufficient for what we need in the tutorial, the custom <tt>submitbutton.js</tt> has been removed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Interaction with other components ==
The way that Joomla interacts with components has changed in Joomla 4. In general the Joomla functionality will boot the component using something like:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $app->bootComponent($option);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and in our case this will return an instance of the <tt>HelloworldComponent</tt> class. It will then try to call certain methods on our extension object, as described below.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_categories===
In the backend the helloworld functionality can display to the administrator
* the view of the helloworld messages
* the view of the helloworld categories
The categories view is generated by <tt>com_categories</tt>, and in Joomla 4 these component categories views display the number of component records there are for each of the possible published status values. To do this the categories component executes the following code (in administrator/components/com_categories/src/Model/CategoriesModel.php):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof CategoryServiceInterface) {
$component->countItems($items, $section);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So our HelloworldComponent must:
* declare that it implements <tt>CategoryServiceInterface</tt>
* provide an implementation of <tt>countItems</tt>
We provide <tt>countItems</tt> by using a trait in libraries/src/Categories/CategoryServiceTrait.php, which (with the assistance of a helper function) does the query on our behalf. We just need to tell it:
* the name of our table – in the callback <tt>getTableNameForSection</tt>
* the database field in which we hold the published status – in <tt>getStateColumnForSection</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_associations===
Remember that <tt>com_associations</tt> is the component which is run whenever you click on Multilingual Associations in the admin backend.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Under Joomla 3 we provided an associations helper file as described in [[J3.x:Multilingual Associations/Developers|Multilingual Associations/Developers]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the helper file remains basically the same, but <tt>com_associations</tt> primarily tries to find the helper file via the extension class; here's the code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($extensionName);
if ($component instanceof AssociationServiceInterface) {
return $component->getAssociationsExtension();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's expecting that:
* the extension (HelloworldComponent in our case) implements <tt>AssociationServiceInterface</tt>
* its <tt>getAssociationsExtension</tt> method returns the helper class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The easiest thing would be just to code <tt>getAssociationsMethod</tt> and get it to return <tt>new AssociationsHelper</tt>. However, we follow the Joomla 4 principle of putting key classes into the Dependency Injection container, and retrieving them later, by having the following code in our services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(AssociationExtensionInterface::class, new AssociationsHelper());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The above line puts a key-value pair into our child DI container
* key = 'Joomla\CMS\Association\AssociationExtensionInterface'
* value is an instance of our <tt>AssociationsHelper</tt> class.
We then retrieve it later and use the setter:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setAssociationExtension($container->get(AssociationExtensionInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so that whenever
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getAssociationExtension()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
is called it returns the <tt>AssociationsHelper</tt> class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_fields===
<tt>com_fields</tt> is the component which is run when an administrator clicks on the Fields or Field Groups menuitem within the backend, and this functionality was included in the [[J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Adding Custom Fields]] tutorial step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>com_fields</tt> component stores the custom fields and field groups for all components in the database tables <tt>#__fields</tt> and <tt>#__fields_groups</tt>, and these tables are partitioned into "sections", one section per component. For our helloworld component the section is named "helloworld".
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within the section we have 2 "contexts" – one for the helloworld messages (called "com_helloworld.helloworld") and one for the helloworld categories (called "com_helloworld.categories"). This enables us to define custom fields for both our helloworld records and helloworld category records.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When <tt>com_fields</tt> runs it checks both the section and contexts at various times. For example, when an admin selects Helloworld / Fields on the backend then <tt>com_fields</tt> checks the section which was defined in the menuitem in the manifest file (see [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Sidebar|below]]). Here's the code in administrator/components/com_fields/src/Helpers/FieldsHelper <tt>extract</tt> function:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
$newSection = $component->validateSection($parts[1], $item);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And when <tt>com_fields</tt> wants to display the little dropdown menu of contexts (to allow the administrator to set custom fields on either helloworld items or categories) it calls (in administrator/components/com_fields/src/Fields/FieldcontextsField.php <tt>getOptions()</tt>):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
return $component->getContexts();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So it's clear that our component extension class must :
* implement <tt>FieldsServiceInterface</tt>
* provide the <tt>validateSection</tt> and <tt>getContexts</tt> methods
So in upgrading to Joomla 4 we've just moved those two methods from the helper file to the extension class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Router===
The Joomla router will access our custom router code:
* whenever it wants to parse an SEF route which it has identified as belonging to <tt>com_helloworld</tt>
* whenever it wants to build an SEF route from a call to <tt>Route::_()</tt> where the option = "com_helloworld".
To find our custom router it will:
* boot the <tt>com_helloworld</tt> extension
* check that the extension implements <tt>RouterServiceInterface</tt>
* call <tt>createRouter</tt> on our extension instance
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In our services/provider.php file we have (careful again - 2 different RouterFactory classes!):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new RouterFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which from libraries/src/Extension/Service/Provider/RouterFactory.php puts into our child DI container an entry with:
* key = "Joomla\CMS\Component\Router\RouterFactoryInterface"
* value is a <tt>\Joomla\CMS\Component\Router\RouterFactory</tt> instance, constructed with our namespace
We then retrieve this in the line in our services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setRouterFactory($container->get(RouterFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And then within our extension class we have
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use RouterServiceTrait;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which includes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function setRouterFactory(RouterFactoryInterface $routerFactory)
{
$this->routerFactory = $routerFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which stores the <tt>routerFactory</tt> locally and
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return $this->routerFactory->createRouter($application, $menu);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which provides our extension's <tt>createRouter</tt> call that the Joomla Router expects.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>routerFactory::createRouter</tt> method is in libraries/src/Component/Router/RouterFactory.php. It looks for a class in our site namespace </tt>Robbie\Component\Helloworld\Site\Service\Router</tt> which is in our site/src/Service/Router.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
At this stage we have a choice, we can either:
* provide a traditional custom router, with the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions, or
* use the more modern <tt>RouterView</tt> mechanism.
By default in the upgraded tutorial code the Router View option has been coded in the Router.php file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====RouterView====
In the <tt>RouterView</tt> case the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions are in the <tt>RouterView</tt> class which we extend, and we provide
* a constructor with router view configuration
* methods <tt>getHelloworldId</tt> and <tt>getCategoryId</tt> which are used to obtain from the SEF segment the <tt>id=</tt> and <tt>catid=</tt> parts of the internal URL
* methods <tt>getHelloworldSegment</tt> and <tt>getCategorySegment</tt> which are used to generate segments for the SEF URLs based on the <tt>id=</tt> and <tt>catid=</tt> parts within the <tt>Route::_()</tt> parameter.
Unfortunately there doesn't seem to be a good guide to configuring the RouterView class. There is some documentation available [https://www.dionysopoulos.me/book/com-router-routerview.html here].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the helloworld tutorial we have 3 views
* a view which displays a single helloworld record
* a view which displays a single helloworld category, and the helloworld records associated with it
* a view which displays the frontend form
So we need 3 Router Views associated with these.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'form' view doesn't have an associated id or catid so it's just a fixed URL, and the router just has to convert between the alias of the form menuitem and the Itemid / view parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'category' view has an associated id (of the category record), and an SEF URL will use the category path down the Categories Nested Set table structure, hence <tt>setNestable()</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'helloworld' view has an associated id (of the helloworld record), and in an SEF URL in the category view the helloworld record alias is added to the category path (hence <tt>setParent()</tt>). But although the helloworld records use a Nested Table structure in the database, the URLs just include the alias of the single record, and so <tt>setNestable()</tt> is not used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There doesn't seem to be a way to configure an additional SEF URL scheme which just displays a helloworld segment, without a category segment.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====Traditional Router====
To use the traditional router in the tutorial code you should uncomment the function in the extension class:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return new TraditionalRouter($application, $menu, $this->categoryFactory, $this->getDatabase());
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will cause the code in site/src/Service/TraditionalRouter.php to be used. However, changes in the Joomla 4 router mean that the interaction between it and the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> methods have changed. This requires significant changes to the <tt>preprocess</tt> and <tt>build</tt> methods, but only a minor change to <tt>parse</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. Previously Joomla injected into the <tt>$query</tt> parameters the <tt>Itemid</tt> of the active menuitem (ie the id of the menuitem the user is currently on). This meant that we had to change the <tt>Itemid</tt> for links generated by the Language Switcher module (which generates the flags for switching between languages), and these links being associated with a different language would obviously use a different <tt>Itemid</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 you get an <tt>Itemid</tt> in the <tt>$query</tt> parameters only if you specified an <tt>Itemid</tt> in the <tt>Route::_()</tt> call. For others you have to work out which menuitem to use yourself, by using the Joomla menu/menuitems API to find details of the configured menuitems, and work out which to use based on the other <tt>$query</tt> parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You do this in the <tt>preprocess</tt> method, and then the <tt>Itemid</tt> you set will be passed in the <tt>$query</tt> parameters to the <tt>build</tt> method.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. In some instances the <tt>Route::_()</tt> URL you're generating matches exactly one of the configured menuitems on the site. In this case the <tt>$query</tt> parameters will match those in the menuitem <tt>"query"</tt> array, and you have to remove explicitly remove the 'view', 'id' and 'catid' parameters so that they don't appear as URL query parameters after the normal SEF URL of the menuitem.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
3. The custom router will be used to build the URLs for the helloworld menuitems shown in menus on the page. For these the <tt>$query</tt> parameters will have the view / id / catid associated with those menuitems. Note that even if you remove these in your <tt>preprocess</tt> method, Joomla will inject them again into the <tt>$query</tt> array when it's passed to your <tt>build</tt> method, so you'll have to remove them again there!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
4. In the <tt>parse</tt> method you now have to unset the <tt>$segments</tt>, or else Joomla will return an HTTP 404 (page not found). Otherwise <tt>parse</tt> works as before.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
5. I've implemented <tt>build</tt> only for when Multilanguage is enabled on the site. If it's not enabled an empty <tt>$segments</tt> array is just returned, without doing unset on any of the <tt>$query</tt> parameters, so these will appear as URL parameters after the SEF URL. Also it's not coded properly to deal with items which have language set to <tt>*</tt>. These include helloworld records, categories or menuitems (eg the helloworld form).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that the <tt>categoryFactory</tt> is also now passed to the router. This is so that it can be used instead of <tt>Categories::getInstance()</tt> to get access to the Categories API calls.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_tags===
Whenever we setup a Tags Menu Item Type which displays items having a given tag or tags, then <tt>com_tags</tt> displays those items as links, and uses route helper functions to generate the URL parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The route helpers <tt>com_tags</tt> expects to find loaded into the data of the <tt>#__content_types</tt> table, in the router field, and these have been set to:
* For links to helloworld items: 'HelloworldHelperRoute::getHelloworldRoute'
* For links to helloworld categories: 'HelloworldHelperRoute::getCategoryRoute'
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, <tt>com_tags</tt> doesn't boot the helloworld extension to get access to these, but rather seeks to find them in site/helpers/route.php, so that's where they continue to be.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(We also had a <tt>getCategoryRoute</tt> which was used by <tt>com_categories</tt> in administrator/components/com_categories/src/Helper/CategoryAssociationHelper. When a category was displayed on the frontend then the Language Switcher module (now Language Filter) used this function to generate the links to the Associated Categories. Our <tt>getCategoryRoute</tt> previously was necessary to insert the <tt>lang=<language tag></tt> parameter into the link URL, but since [https://github.com/joomla/joomla-cms/pull/39358 this change] the calling function inserts the <tt>lang</tt> parameter itself, so our <tt>getCategoryRoute</tt> function for this purposes is superfluous.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Deprecated APIs ==
With Joomla 4 there are a number of methods which are deprecated, with a view to removing them in Joomla 5.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Factory Methods===
Many of the <tt>Factory</tt> methods for getting singleton classes have been deprecated in favour of getting these classes via the DI container, and it appears that only class instances which should be obtained via Factory methods are:
* the Application – <tt>Factory::getApplication()</tt>
* the DI container – <tt>Factory::getContainer()</tt>
Here is a list of what has been changed in the tutorial code. Note that with some calls there are variants available, through the aliases defined in the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDbo'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\Database\DatabaseInterface;
...
$db = Factory::getContainer()->get(DatabaseInterface::class);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, in many classes the database instance is more easily (and efficiently) returned via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$db = $this->getDatabase();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is available in Model classes, custom field definitions, etc.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getUser();'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get the current user use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = Factory::getApplication()->getIdentity()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get a different user (whose id you know):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\User\UserFactoryInterface;
...
$user = Factory::getContainer()->get(UserFactoryInterface::class)->loadUserById($userid);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within models which extend Joomla\CMS\MVC\Model\BaseDatabaseModel and views which extend Joomla\CMS\MVC\View\HtmlView you can also use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = $this->getCurrentUser()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDocument()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication()->getDocument()</tt>, or within a View you can use <tt>$this->document</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getConfig()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Two options have been used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->getConfig()</tt> – returns a Registry object containing all the configuration values
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->get('access')</tt> – returns the value of the 'access' configuration parameter
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getLanguage()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication->getLanguage()</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JFactory::getCache('com_example', <type>)'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Cache\CacheControllerFactoryInterface;
...
Factory::getContainer()->get(CacheControllerFactoryInterface::class)->createCacheController(<type>)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated getInstance Methods===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general <tt>getInstance()</tt> calls have been deprecated in favour of obtaining the instance, either via a factory class or via the DI container. For example, within a controller you can use <tt>getModel()</tt> repeatedly to get different models (passing the relevant model names), which results in the MVCFactory class creating the Model classes.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there are currently some problems with replacing some getInstance calls. I expect that the Joomla team will resolve these issues over the course of the Joomla 4 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Categories::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is deprecated with a notice: "Use the ComponentInterface to get the categories". This means that we should get the category factory instance via the DI container. This is done in our services/provider.php by the lines:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Extension\Service\Provider\CategoryFactory;
...
$container->registerServiceProvider(new CategoryFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to put into our child DI container the closure which will create a Joomla\CMS\Categories\CategoryFactory instance, constructed with our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when our HelloworldComponent (Extension) instance is created:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We can then use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getCategoryFactory()->createCategory();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to create our Categories object, and in this way get access to the Categories APIs.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This createCategory method creates the instance by looking for the \\Site\\Service\\Category class within our namespace. The constructor in our class sets our extension ('com_helloworld') and table ('#__helloworld') and calls the parent Categories constructor with these options).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this means that the section of our code where we want to use the Categories APIs must have a pointer to a CategoryFactory instance. In the tutorial code for Joomla 3 there are 2 places where <tt>Categories::getInstance</tt> is used:
* in the custom router code, to handle building and parsing of the category parts of the SEF URL
* in the site category model, where the Categories APIs are used to obtain details of categories to display on the page.
For the custom router code, the CategoryFactory instance is passed as a parameter to the TraditionalRouter constructor so that it can be used there.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, the site category model is instantiated by the MVCFactory instance, and it doesn't make available a CategoryFactory instance. So in this category model the calls to <tt>Categories::getInstance()</tt> have been left, and you can still find a number of calls to <tt>Categories::getInstance</tt> within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Categories::getInstance()</tt> itself solves the problem of access to a CategoryFactory instance by rebooting our component again to get a pointer to our Extension instance, and thus to the category factory instance. However, this involves a lot of work, so <tt>getInstance</tt> caches locally the Categories instances and just returns one of them if it can.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Pushing the CategoryFactory to the model'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there is a way to get access to the CategoryFactory instance, by defining your own MVCFactory class, and pushing the instance down through it to the model. Here's how you can go about it:
* Define your own SuperMVCFactory class, which extends the Joomla Joomla\CMS\MVC\Factory\MVCFactory class, but which has a means of storing a CategoryFactory instance. Use the CategoryServiceTrait in libraries/src/Categories/CategoryServiceTrait.php
* Create your own version of the file libraries/src/Extension/Service/Provider/MVCFactory.php, which is the 'provider.php' like file for MVCFactory, but change it so that:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
becomes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new <namespace>\SuperMVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and include
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla creates a model such as CategoryModel it passes in its constructor the MVCFactory instance (so that the model can call createTable on it), so you can access it via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will return your SuperMVCFactory instance. So in this way within the model you can access the CategoryFactory, and use it to create the Categories instance via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()->getCategory() (from the CategoryServiceTrait)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you can get this working you can congratulate yourself on a good understanding of Joomla namespacing and dependency injection! A similar approach to address a similar problem is described [https://www.dionysopoulos.me/book/com-router-push-dependencies.html here]. If you get stuck you can always view the solution by viewing the github tutorial code selecting the branch [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial/tree/push-category-factory-to-mvc push-category-factory-to-mvc].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Table::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There are a couple of calls to <tt>Table::getInstance()</tt> within admin/src/Helper/AssociationsHelper.php in <tt>getItem()</tt>:
* <tt>Table::getInstance('Helloworld', 'Robbie\\Component\\Helloworld\\Administrator\\Table\\')</tt> to get an instance of our HelloworldTable class.
* <tt>Table::getInstance('Category')</tt> to get an instance of the Category table in libraries/src/Table/Category.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We could actually arrange for the AssociationsHelper class to get injected with the MVCFactory instance, so that the HelloworldTable class could be instantiated by it. However, we couldn't use the helloworld MVCFactory instance to create the Category table instance, as it's not in the helloworld namespace, and our MVCFactory instance creates table instances within our namespace only.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Toolbar::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The tutorial code uses <tt>Toolbar::getInstance()</tt> to get a Toolbar instance onto which it can attach the batch button in the helloworlds form. The Toolbar API documentation seems to suggest that we should replace
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Toolbar::getInstance('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
with
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this currently won't work. The problem is that all the other Joomla code uses <tt>getInstance('toolbar')</tt> to access the Toolbar class, including the code in administrator/modules/mod_toolbar/mod_toolbar.php which renders the toolbar. The <tt>getInstance</tt> method keeps track of the Toolbar instances in a local static variable <tt>$instances</tt>, and returns the same Toolbar instance on repeated invocations.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you use the second approach above you will get a Toolbar instance, but it won't be the same Toolbar instance as is stored in the <tt>$instances</tt> variable. It won't then be picked up by the Toolbar module, and so won't be rendered on the form.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Error Handling===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead of
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
JError::raiseError(500, implode('<br />', $errors));
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
you should throw an exception, using or extending one of the standard [https://www.php.net/manual/en/spl.exceptions.php PHP exceptions], eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
throw new \Exception(implode("\n", $errors), 500);
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===jimport===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
jimport is no longer necessary in order to get access to Path or File classes. All of the Joomla classes are found by the autoloader.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Methods related to Javascript===
'''JHtml::_('behavior.framework');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general, the use of JHtml::_('behavior.xxx') is now obsolete, and calls using this have been removed in the tutorial code. The 'behavior.framework' call referred to including jQuery. Where jQuery is necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.formvalidator');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by the <tt>form.validate</tt> javascript asset, and where necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It can also be included directly using the web asset manager:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$wa->useScript('form.validate')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.tooltip')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This no longer exists, and tooltips don't seem to be enabled by default in Joomla 4. This is replaced by the code in media/js/enable-tooltips.js.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('formbehavior.chosen')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The chosen js library seems to be no longer used, and using it will cause formatting issues if you include it in your tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''sortable'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The sortable js library provided the ability in the helloworlds view to drag rows up and down to change the ordering of the records. This has been replaced in Joomla 4 by the draggable library. To enable it you have to set:
* <tt>HTMLHelper::_('draggablelist.draggable');</tt>
* on your <tt><tbody></tt> element define the table in which dragging occurs and the URL of the Ajax call to set the ordering:
<source lang="php">
<tbody<?php if ($saveOrder) : ?> class="js-draggable" data-url="<?php echo $saveOrderingUrl; ?>" data-direction="<?php echo strtolower($listDirn); ?>" data-nested="true"
<?php endif; ?>>
</source>
* on your <tt>tr</tt> element within your <tt><tbody></tt> define the group of records in which dragging occurs (by category below):
<source lang="php">
<tr class="row<?php echo $i % 2; ?>" data-draggable-group="<?php echo $row->catid; ?>">
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==HTML Snippets==
There are two places in the tutorial where reusable snippets of HTML have beeen defined:
* For displaying the item associations in the helloworlds view:
* For displaying the position latitude and longitude fields within the batch options in the helloworlds view
These used different approaches:
* the item associations display was coded in an html helper file in admin/helpers/html/helloworlds.php and accessed via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JHtml::_('helloworlds.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
in the helloworlds tmpl file. (Although it did use a common joomla layout file underneath).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* the position field was coded as a layout in layouts/position.php, and rendered using
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JLayoutHelper::render('position', array());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When should you use one approach rather than the other? A significant difference is that layouts are designed so that an administrator can override them, via the Templates / Details and File functionality. So, for example, an administrator could change the position to show the longitude before the latitude. So it's more appropriate for layouts to focus on the html elements rather than functional logic, and particularly if you would want to allow an administrator to override the layout.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The layouts functionality in Joomla 4 hasn't changed significantly. One correction which has been made in the updated tutorial code has been to include the position.php file in a subfolder of layouts, ie in admin/layouts/helloworld/position.php rather than admin/layouts/position.php. It appears that in the Templates / Details and Files / Create Overrides tab the <tt>com_helloworld</tt> layout appears only if it's in a subfolder of /layouts.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>JHtml::_()</tt> approach has changed in Joomla 4. Rather than Joomla having to look for a helper file when it encounters something it doesn't recognise, it's expected that you should register such classes beforehand, and you do this by obtaining an instance of the Joomla\CMS\HTML\Registry class (it's a singleton class) and then calling <tt>register</tt> on it, passing
* the key you want to use
* an instance of your class
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Joomla pattern is to put the code in a file admin/src/Service/HTML/AdministratorService.php, and we have to ensure that our key won't be used elsewhere within Joomla, so in the tutorial we've used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Robbie\Component\Helloworld\Administrator\Service\HTML\AdministratorService;
...
register('helloworldadministrator', new AdministratorService)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when we call:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo HTMLHelper::_('helloworldadministrator.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will result in Joomla calling the <tt>association</tt> method in our class, passing the <tt>$row->id</tt> parameter.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We should get the Joomla\CMS\HTML\Registry class from the Dependency Injection container. Joomla components generally do this via their services/provider.php file, and then call <tt>register</tt> within the extension's <tt>boot</tt> function, described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Step_5_Call_boot.28.29_on_our_Component|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The extension uses HTMLRegistryAwareTrait which contains <tt>setRegistry</tt> and <tt>getRegistry methods</tt>. In services/provider.php there is:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\HTML\Registry;
...
$component->setRegistry($container->get(Registry::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets 'Joomla\CMS\HTML\Registry' out of the DI container and stores it within the
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
private $registry;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
variable of the HTMLRegistryAwareTrait included in the extension.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the <tt>boot</tt> function it calls
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getRegistry()->register('helloworldadministrator', new AdministratorService);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets the registry and calls <tt>register</tt> as required.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that <tt>boot</tt> is called whenever Joomla dispatches <tt>com_helloworld</tt>, both for the site and administrator, so it would make sense to check the Application <tt>isClient</tt> before deciding whether to register the HTML Helper service or not. This hasn't been included in the tutorial code though.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==User Interface Changes==
Joomla 4 introduced new templates, atum on administrator and cassiopeia on site, and in particular the administrator is built upon some UI rearrangements which affect the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Sidebar===
In Joomla 3 each component incorporated a sidebar which we coded in the <tt>addSubmenu</tt> function in admin/helpers/helloworld.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the administrator menu is in a vertical panel on the left hand side, and the Hello World submenu is built from entries in the helloworld.xml manifest file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<administration>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<submenu>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<menu link="option=com_categories&extension=com_helloworld">COM_HELLOWORLD_CATEGORIES</menu>
<menu link="option=com_fields&view=fields&context=com_helloworld.helloworld">MOD_MENU_FIELDS</menu>
<menu link="option=com_fields&view=groups&context=com_helloworld.helloworld">MOD_MENU_FIELDS_GROUP</menu>
</submenu>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===CSS Classes===
In several places the CSS classes defined in the html elements have been changed in Joomla 4. For example, for general layout the classes now align with the [https://getbootstrap.com/docs/3.4/css/ Bootstrap CSS Classes], and classes such as <tt>row-fluid</tt> and <tt>span3</tt> which were prominent in Joomla 3 have disappeared. If you're upgrading a Joomla 3 component then it's probably best (on the back-end at least) to find a similar Joomla component and use the overall html structure and css classes within its tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the tutorial code those classes which are specifically used by Bootstrap have been changed from eg 'data-target' to 'data-bs-target', and it has been necessary to change these to enable the functionality to work.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, not all of CSS class changes affecting solely the presentation have been reflected in the updated tutorial code. For example, in the <tt>helloworlds</tt> view, showing the list of helloworld messages, the display of the associations is different from that of other Joomla components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Fonts===
In Joomla 3 [[J3.x:Joomla_Standard_Icomoon_Fonts|Icomoon Fonts]] were used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 Font Awesome's free icons are used, and you can see what is available on their [https://fontawesome.com/v5/cheatsheet cheatsheet]. The icons are implemented using CSS pseudo-elements, as described [https://fontawesome.com/v5/docs/web/advanced/css-pseudo-elements here]. Basically they convert a CSS class into html content, namely a unicode value in the private use range. A couple of these have been implemented in the frontend form, in the Save and Cancel buttons, for example:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>span class="icon-cancel">/span <?php echo Text::_('JCANCEL') ?></tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(with angle brackets removed from the <tt>span</tt> tags to stop the icon just being displayed by the browser).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This class is defined in media/system/css/joomla-fontawesome.css (where you can find the list of icon classes supported):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
.icon-cancel:before {
content: "\f00d";
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so this includes in front of the text the unicode character <tt>f00d</tt>, which you can see on the cheatsheet as "times", and displayed as <span class="icon-cancel"></span>. You can also use <tt>fa-</tt> plus the icon name on the font awesome cheatsheet page. If you use Icomoon icon names in your code which you run under Joomla 4, then the icon displayed will be a Font Awesome icon (if there's one with the same name) or it will use a mapping which the Joomla team have defined to display a Font Awesome icon which resembles the Icomoon one.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Buttons and Links===
An accessibility principle is that <tt><a></tt> html elements should be used for links to other web pages, and <tt><button></tt> elements should be used for actions, eg on a form. To align with this, the <tt><a></tt> elements in the helloworld modal field (defined in admin/src/Field/Modal/Helloworld.php) have been changed to <tt><button></tt> elements. These are the Select and Clear buttons displayed when choosing a Helloworld record for a menuitem pointing to a Helloworld message. (The buttons also include fontawesome icons, by the way).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This change was actually made in Joomla in one of the Joomla 3 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Categories View===
In the Categories view of standard Joomla components there now appears columns which show for each category the number of items, split by published status. This is populated by <tt>com_categories</tt> calling each extension's <tt>countItems</tt> function, as described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_categories|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Miscellaneous Changes==
===Version History===
In Joomla 3 the tutorial code used the <tt>JTableObserver</tt> functionality to copy relevant changes from the Helloworld and Categories tables into the UCM tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it uses a plugin mechanism to subscribe to Table events 'onTableAfterStore' and 'onTableBeforeDelete'. The plugin can be found in plugins/behaviour/versionable, and it is activated by Joomla as part of its application initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The copying of fields from the table works roughly the same way as before, except that the name of the table where the versions are stored is now <tt>#__history</tt>, so the entries which have to be inserted into the <tt>#__content_types</tt> table are fairly similar. Because the folders in which forms are stored has changed in Joomla 4, the 'formFile' parameter is different (remember that this is where Joomla gets the field labels in order to display the Preview within the Versions modal window, otherwise just the names of the database columns will be output).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here's a summary of what needs to be done to enable versioning under Joomla 4. The Versioning Traits and Interface definitions are found in libraries/src/Versioning:
* Enter data into content_types database table
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Storing the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The Table class must implement VersionableTableInterface and provide <tt>getTypeAlias()</tt>, which returns 'com_helloworld.helloworld'. This type alias + the helloworld record id is used as the key to identify versions in the <tt>#__history</tt> table.
* Define <tt>save_history</tt> and <tt>history_limit</tt> options in config.php, and ensure these are both set.
* Add a <tt>version_note</tt> field into the output of the edit view's tmpl file (admin/tmpl/helloworld/edit.php).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Viewing and Restoring the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit Controller (admin/src/Controller/HelloworldController.php) should <tt>use VersionableControllerTrait</tt>.
* The edit Model (admin/src/Model/HelloworldModel.php) should <tt>use VersionableModelTrait</tt> and include a variable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public $typeAlias = 'com_helloworld.helloworld';
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit View (admin/src/View/Helloworld/HtmlView.php) – should display the Versions toolbar button if global config has <tt>save_history</tt> on.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Joomla 4 allows us to have different history version limits for helloworld items and categories, and this has been used in the configuration definition in admin/config.xml.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Setting Configuration Parameters in Install Script===
As you may remember, global configuration parameters relating to the Hello World component are defined in admin/config.xml and stored in the <tt>#__extensions</tt> table, in a JSON string in the params field of the record relating to <tt>com_helloworld</tt>. This means that when the component is first installed the params are not set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So, for example, even if the <tt>save_history</tt> is defined in config.xml to default to true, the versions won't be saved until an administrator actively saves the configuration parameters, because the Joomla versioning code assumes <tt>save_history</tt> to be false if it's not explicitly set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For this reason it makes sense to set any default configuration parameters in the install script.php, in the <tt>postflight</tt> method, and that has been done in this step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Tags===
Like version history, tags functionality has been changed to use a plugin – in plugins/behaviour/taggable – rather than the <tt>JTableObserver</tt> approach.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To enable tags the component table must implement TaggableTableInterface (in libraries/src/Tag), and provide the <tt>getTypeAlias()</tt> which is common to the Versioning functionality.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Whenever <tt>com_tags</tt> outputs helloworld messages or categories relating to a tag it displays them as links, and looks in the site/helpers/route.php file to find the route functions (as described above in [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_tags|com_tags]]). The class and method in this file must match the 'router' field within the data entered into the <tt>#__content_types</tt> table.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===media files===
Under Joomla 4 all of the media files are stored in the /media folder; these include javascript and css files (scss files too), as well as images such as the little flag symbols shown in the language switcher. Extensions being developed should store all of the js and css files in their /media folder, and then when the extension is installed these files are put under the extension's folder under the /media folder of the Joomla instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Patches==
Some bugs in Joomla were discovered during the course of updating the tutorial code to work under Joomla 4. If you find something doesn't work then make sure you're on at least Joomla 4.2.6 and check if you need one of the following patches:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
CategoryAssociationHelper.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39358/files
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
MediaField.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/issues/39203
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Category restore
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39474
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Contributors ==
*[[User:Robbiej|Robbie Jackson]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Prev: Adding Custom Fields|class=expand success}}</div>
</div>
</div>

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/21/it

2023-05-27T12:44:37Z

Ing Pulizzi: Created page with "In Joomla 4 genera il nome completo della classe che vuole trovare, quindi cerca di trovarlo nella posizione in cui la raccomandazione PSR-4 lo aspetterebbe."

In Joomla 4 genera il nome completo della classe che vuole trovare, quindi cerca di trovarlo nella posizione in cui la raccomandazione PSR-4 lo aspetterebbe.

J3.x:Developing an MVC Component/Upgrading to Joomla4/it

2023-05-27T12:44:25Z

Ing Pulizzi: Created page with "Quando Joomla 3 ha voluto chiamare le funzioni nel tuo componente, ha cercato determinati nomi di file in cartelle particolari e ha verificato che il nome della classe in quel..."

<noinclude><languages /></noinclude>

{{:J3.1:Developing an MVC Component/it}}
Questo passaggio copre ciò che è coinvolto nell'aggiornamento del codice del tutorial per allinearlo con la versione 4 di Joomla.

== Introduzione ==
Questa pagina descrive i principali aspetti relativi allo sviluppo dei componenti che sono stati introdotti in Joomla 4 e descrive in dettaglio cosa è stato modificato nel codice del tutorial per allinearsi con v4.

Non è pratico dettagliare tutte le modifiche al codice sulla pagina Web come è stato fatto per i passaggi precedenti dell'esercitazione. Invece puoi trovare il codice come repository github su [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial Joomla 4 Tutorial code], e puoi confrontarlo con il codice del passaggio precedente del tutorial (Adding Custom Fields) su [https://github.com/robbiejackson/Joomla-3-MVC-Tutorial Joomla 3 MVC code]. Il codice di Joomla 4 replica tutte le funzionalità del codice di Joomla 3, con l'eccezione dell'implementazione dell'icona del piccolo pinguino introdotta in [[S:MyLanguage/J3.2:Developing an MVC Component/Adding decorations to the backend|Aggiunta di decorazioni al backend]] (che non è così rilevante data la modifica dell'interfaccia utente in Joomla 4 Administrator) e l'uso di un plug-in CAPTCHA ([[J3.x:Developing an MVC Component/Adding a frontend form|Adding a frontend form]] ). Probabilmente troverai utile avere a portata di mano questo codice Joomla 4 a cui fare riferimento mentre leggi questa pagina.

Il codice per questo passaggio è stato sviluppato seguendo ciascuno dei precedenti passaggi del tutorial e cercando di far funzionare ogni passaggio con Joomla 4.2.5. Poiché Joomla 4 si sta ancora evolvendo abbastanza velocemente, è possibile che alcuni aspetti qui citati vengano modificati durante la vita di Joomla 4. Sentiti libero di correggere gli aspetti in questa pagina e creare richieste pull su [https://github.com/robbiejackson /Joomla-4-MVC-Tutorial Joomla 4 github repository].

Se stai installando il codice del tutorial di Joomla 4 su una nuova istanza di Joomla, dovrai configurare la tua istanza per renderla multilingue e aggiungere le voci di menu nascoste di Ajax come descritto nel passaggio [[J3.x:Developing an MVC Component/ Utilizzo del filtro della lingua |Utilizzo del filtro della lingua]]. Assicurati inoltre che ogni record helloworld abbia una categoria valida.

=== Ulteriori letture ===
Puoi trovare [https://blog.astrid-guenther.de/en/der-weg-zu-joomla4-erweiterungen/ qui] un tutorial per lo sviluppo dei componenti di Joomla 4, simile a questo Joomla 3, e alcuni eccellenti Joomla 4 è disponibile anche la documentazione [https://www.dionysopoulos.me/book.html qui]. Entrambi questi riferimenti includono descrizioni degli impatti di Joomla 4 sullo sviluppo di altri tipi di estensioni Joomla (plugin, moduli e modelli), che non sono trattati qui.

Questo passaggio non copre tutto ciò che è necessario per aggiornare un componente da Joomla 3 a Joomla 4, solo gli aspetti coperti dal codice del tutorial. Se stai aggiornando il tuo componente Joomla 3, potresti trovare utile esaminare [[Potenziali problemi di compatibilità con le versioni precedenti in Joomla 4]].

== NameSpace ==
===NameSpace dei nomi dei componenti===
I NameSpace delle classi che utilizza la [https://www.php-fig.org/psr/psr-4/ PSR-4 recommendation] è stato gradualmente introdotto durante le versioni di Joomla 3 e con Joomla 4 è praticamente tutto con NameSpace

Ora è previsto che anche le estensioni di Joomla utilizzino i NameSpace di base per l'estensione definito nel suo file XML manifest. I componenti di Joomla usano uno NameSpace della forma <tt>Joomla\Component\<Nome componente></tt> es. <tt>Joomla\Component\Content</tt>, quindi seguendo questo schema ho dato una base al codice del tutorial spazio dei nomi di <tt>Robbie\Component\Helloworld</tt>. Ecco la riga nel file manifest helloworld.xml:

<namespace path="src">Robbie\Component\Helloworld</namespace>

(L'attributo <tt>path="src"</tt> indica che si aspetterà che le classi si trovino nella sottocartella <tt>src</tt>.)

Questo in realtà crea 2 prefissi dello spazio dei nomi, che puntano a cartelle specifiche nella nostra struttura di sviluppo helloworld e nella nostra istanza joomla live:

<tt>Robbie\Component\Helloworld\Administrator</tt> – punterà ad administrator/components/com_helloworld/src sull'istanza live ed è associato ad admin/src nella nostra area di sviluppo.

<tt>Robbie\Component\Helloworld\Site</tt> – punterà a components/com_helloworld/src sull'istanza live ed è associato a site/src nella nostra area di sviluppo.

Quindi Joomla ora si aspetta che tutti i nomi delle classi vengano trovati in quelle directory di base, con il nome del file che corrisponde al nome della classe e il nome della classe completo che corrisponde al percorso, ad esempio

<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> si troverà in
administrator/components/com_helloworld/src/Controller/DisplayController.php

<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> si troverà in
components/com_helloworld/src/Model/CategoryModel.php

'''Nota che le lettere maiuscole sono importanti nei namespace, nei nomi delle classi e nei nomi dei percorsi!'''

Quando Joomla 3 ha voluto chiamare le funzioni nel tuo componente, ha cercato determinati nomi di file in cartelle particolari e ha verificato che il nome della classe in quel file corrispondesse a quello previsto.

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it generates the fully qualified name of the class it wants to find, and then looks to find it in the location where the PSR-4 recommendation would expect it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Hence the namespace you specify in your class files must align with the file path to your PHP file, below the base <tt>src</tt> folder at your namespace prefix.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note in particular how the <tt>View</tt> class files are now organised.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Also if you use one of the PHP predefined classes (eg <tt>Exception</tt>) in your code, then add a backslash before it (eg <tt>\Exception</tt>), otherwise PHP will try and find it in your namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you use custom Field or Rule definitions in your form xml files then you have to indicate to PHP which namespace prefix to use to look for them, eg in <tt>site/forms/add-form.xml</tt>:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
addruleprefix="Robbie\Component\Helloworld\Administrator\Rule"
addfieldprefix="Robbie\Component\Helloworld\Administrator\Field"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and also in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> where the associations are added into the form dynamically to form the custom <tt>modal_helloworld</tt> type field:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Class Autoloading===
Joomla uses the PHP mechanism for [https://www.php.net/manual/en/language.oop5.autoload.php Autoloading Classes] and on startup registers a number of autoloaders – functions which get called when PHP can't find a given class. In particular the Joomla PSR-4 autoloader function (in <tt>libraries/loader.php</tt>) is responsible for finding classes of Joomla extensions whose code is in source files which are organised according to the PSR-4 recommendation. (Joomla library classes are autoloaded using a different autoloader – see <tt>libraries/vendor/composer/autoload_static.php</tt>).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can see the namespace prefixes of extensions on the Joomla instance by looking at <tt>administrator/cache/autoload_psr4.php</tt>. (These namespace strings have double backslashes, but in PHP they're the [https://stackoverflow.com/questions/25459197/single-or-double-slash-when-using-php-namespace same strings as those with single backslashes]). This is generated by Joomla looking through the component, module and plugin directories to find each extension's manifest file, and then processing these xml files to extract the <tt><namespace></tt> element – quite a lot of work, which is why it's cached I guess!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider what happens when Joomla wants our admin HelloworldController class. It might have something like
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$classname = 'Robbie\Component\Helloworld\Administrator\Controller\HelloworldController'
if (!class_exists($classname)) { …
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Assuming PHP doesn't already know about this class, the <tt>class_exists</tt> function will result in the classname being passed to the registered autoload function(s). The PSR-4 autoloader will then:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# go through its array of namespaces to try and match <tt>$classname</tt> from the start of the string.
# find 'Robbie\Component\Helloworld\Administrator' as a match
# see that this maps to "administrator/components/com_helloworld/src"
# extract the remainder of the classname: 'Controller\HelloworldController'
# treat this as the path down to the class file
# and so look for "administrator/components/com_helloworld/src/Controller/HelloworldController.php"
# check that in this file there's actually a class with that namespace + class name.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So in this way Joomla can go from a fully qualified class name to find the source code for that class. This makes it easier for us too when the core Joomla code is looking for one of our classes. We still need to know what class it's looking for, but once we know that, we know what we should call our class and where we should save the source code for it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Joomla Library classes===
Originally Joomla's core classes (beginning with a capital J) were global classes. Over the Joomla 3 versions and into Joomla 4 these migrated to their namespaced equivalents, but the original global classnames were still available as Joomla registered them as aliases (in the <tt>libraries/classmap.php</tt> file).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In a Joomla 4 extension you can still use these global classnames, except that in a namespaced file you'd have to prefix the name with a backslash to indicate a global class rather than one in your namespace (eg <tt>\JFactory</tt> instead of <tt>JFactory</tt>).
However it's pretty definite that the aliases will disappear at some stage, so the upgrade to Joomla 4 seems an appropriate opportunity to replace all your component's calls to the global JSomething classes to the namespaced equivalents. This involves adding the appropriate <tt>use</tt> statements, and all this has been done in the tutorial code. A useful mapping between the two can be found [https://github.com/nikosdion/joomlatypehints/blob/main/JoomlaObsoleteClasses.md here], where the new qualified classname can be copied and pasted into a <tt>use</tt> statement in your PHP file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
With reference to the [https://api.joomla.org/ Joomla API Documentation] there are 2 Joomla library namespaces:
* Joomla CMS classes – have namespaces <tt>Joomla\CMS\Something</tt> – are found under <tt>libraries/src/Something</tt>
* Joomla Framework classes – have namespaces <tt>Joomla\Something</tt> – are found under <tt>libraries/vendor/joomla/something/src</tt>
So a big advantage of namespacing is that you can immediately determine from the fully qualified class name in a PHP <tt>use</tt> statement where the source for that class exists in the <tt>libraries</tt> directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
On the other hand class names which aren't fully qualified don't have to be unique, eg <tt>MVCFactory</tt>
* occurs as <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in <tt>libraries/src/Extension/Service/Provider/MVCFactory.php</tt>
* occurs as <tt>Joomla\CMS\MVC\Factory\MVCFactory</tt> in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>
so sometimes you have to be careful to examine the <tt>use</tt> statement to identify the right class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly our FormModel class in <tt>site/src/Model/FormModel.php</tt> can have the same FormModel classname as the Joomla FormModel in <tt>libraries/src/MVC/Model/FormModel.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The API documentation gives the methods available in each of the [https://api.joomla.org/cms-4/namespaces/joomla.html Joomla CMS] and [https://api.joomla.org/framework-2/namespaces/joomla.html Framework] classes, but just be aware that a Joomla CMS class may extend a Framework class, and in this case some methods may not be visible under the Joomla CMS documentation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For example, <tt>$app->setHeader()</tt> which is used to set the HTTP response code is not listed under the [https://api.joomla.org/cms-4/classes/Joomla-CMS-Application-CMSApplication.html CMS Application class API], but is available as a method because it inherits from the Framework class [https://api.joomla.org/framework-2/classes/Joomla-Application-AbstractWebApplication.html AbstractWebApplication].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Vendor Namespaces===
These are also in <tt>libraries/vendor</tt>, eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Psr\Container\ContainerInterface;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
refers to <tt>libraries/vendor/psr/Container/src/ContainerInterface.php</tt>. However there are few of these in the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other File Rearrangements===
With all of the namespaced classes moving under the src directories, the <tt>tmpl</tt> layout files and <tt>form</tt> xml files have been moved out into their own directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Extension and Dispatcher classes ==
===Extension===
In Joomla 3 the point where the Joomla core handed over to your component code was when it ran your <tt>helloworld.php</tt> code; if it was the frontend it ran your site <tt>helloworld.php</tt> code, or if was the backend it ran your admin <tt>helloworld.php</tt> code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the entry point into your component code is your Extension class, both for site and admin, found in <tt>admin/src/Extension/HelloworldComponent.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When the Joomla core application wants to start executing the component code it creates an instance of <tt>HelloworldComponent</tt>, just to get a handle on the component code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly (as described below) other Joomla classes such as Router or Categories need to call certain Helloworld methods (eg custom router functions). In Joomla 3 these methods were written in certain Helper files etc. In Joomla 4 the principle is that the component creates an instance of the <tt>HelloworldComponent</tt> Extension class, and calls the required methods on that instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This Extension class isn't anything like a big container class for the component, it's more like a glue class, providing a way in to the Helloworld component, enabling the Joomla core and other components call the methods which they want to call.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla core wants to execute the component code, the key method it is looking for in your <tt>Extension</tt> instance is <tt>getDispatcher</tt>, and it expects to get back a <tt>Dispatcher</tt> instance. The <tt>HelloworldComponent</tt> extends <tt>MVCComponent</tt>, which in turn extends <tt>Component</tt>, and it is this class which defines <tt>getDispatcher</tt> for us.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Dispatcher===
When Joomla wants to run the Hello World component, it gets the <tt>Dispatcher</tt> instance as described above and then calls the <tt>dispatch</tt> method on it. It is this <tt>dispatch</tt> function which replaces the functionality in the admin and site <tt>helloworld.php</tt> files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's look at the main lines of code in our Joomla 3 admin <tt>helloworld.php</tt> file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="site/views/form/view.html.php">
<syntaxhighlight lang="php">
if (!JFactory::getUser()->authorise('core.manage', 'com_helloworld'))
{
throw new Exception(JText::_('JERROR_ALERTNOAUTHOR'));
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Get an instance of the controller
$controller = JControllerLegacy::getInstance('HelloWorld');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Execute the Request task method
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Redirect if set by the controller
$controller->redirect();
</syntaxhighlight>
</span>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code
* performs some permissions checks
* instantiates the appropriate Helloworld controller
* executes the appropriate method in that controller
* implements any redirect set by the controller
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Model-View-Controller]] for further details of how this works in Joomla 3. The second and third steps used the <tt>task</tt> parameter within the URL query to determine the correct controller class to instantiate and method to call. If no <tt>task</tt> parameter was present then it instantiated the controller in <tt>controller.php</tt> and called the <tt>display</tt> method. Otherwise it instantiated one of the controllers in the <tt>controllers</tt> subfolder (eg <tt>controllers/helloworld.php</tt>) and called the appropriate method on it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>ComponentDispatcher::dispatch</tt> method (in <tt>libraries/src/Dispatcher/ComponentDispatcher.php</tt>) now provides this functionality, but in a nicer way. After checking the permissions it uses the <tt>task</tt> by considering its parts as <tt><controller type>.<method></tt> (taking 'display' as default if either part is missing). It will then pass control to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* an instance of the class <Controller type>Controller
* calling the function <method>
* using the admin or site controller, as appropriate
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In this way the naming of the controllers is consistent - we have DisplayController, HelloworldController and HelloworldsController, all in the same folder.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Dispatcher class can thus be considered as providing some 'routing - execution' functionality, enabling us to find the right controller and function within that controller, and it is cleaner to have this in a separate class rather than in the <tt>JControllerLegacy</tt> class as it was in Joomla 3.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Since the Hello World tutorial uses the standard Joomla pattern for selecting the class and method based on the <tt>task</tt> and has the same permissions checks, we can use the <tt>dispatch</tt> code as it stands in <tt>ComponentDispatcher</tt>, and don't need to define a special class of our own.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Factory classes ==
In Joomla 3 many classes had static <tt>getInstance</tt> methods which returned an instance of that class, configured with the parameters passed to <tt>getInstance</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the <tt>getInstance</tt> methods have been deprecated in favour of using Factory classes. The preferred mechanism is now to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* get an instance of the appropriate Factory class (how we do that is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below)
* call the <tt>createSomething()</tt> method of the Factory class with relevant parameter values to generate an instance of the Something class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===MVC Factory===
In this section the <tt>MVCFactory</tt> class refers to the one in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory class will instantiate Controller, View, Model and Table instances on our behalf, and it does this by generating the classname of the class and then calling <tt>new</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The way it works is as follows:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Each component gets an individual MVCFactory instance which is constructed passing the component's namespace as a parameter (so in our case 'Robbie\Component\Helloworld'). (How this MVCFactory instance is created is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below).
# The MVCFactory createController / createView / createModel / createTable function is then called, passing the name of the Controller / Model / View / Table and the prefix (which specifies whether the administrator or site class is required).
# The create function forms the classname from this data and calls <tt>new</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory create functions just form the classname from the parameters they're passed. The intelligence for working out what name and prefix should be used to form the appropriate classes for an incoming HTTP request is
* in the dispatcher code for defining the controller to use
* in the controller for the view and model
* in the model for the table
and, for example, the names of the classes created for a request with URL query <tt>?option=com_helloworld&view=viewname</tt> and no <tt>task</tt> parameter will be
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<namespace>\Controller\DisplayController
<namespace>\View\Viewname\HtmlView
<namespace>\Model\ViewnameModel
<namespace>\Table\ViewnameTable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you need an alternative name then you can override the appropriate getView, getModel or getTable function – as for example was done in the [[J3.x:Developing an MVC Component/Adding Custom Fields#Front-end_Form|Adding Custom Fields step, frontend Form section]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So from the outside this is pretty much the same as in Joomla 3. However, note that the <tt>$prefix</tt> parameter in calls to <tt>getModel</tt> etc is subtly different
* in Joomla 3 this referred to a prefix to be applied to the classname – in the tutorial code we used 'HelloWorldTable' as the prefix part of the 'HelloWorldTableHelloWorld' classname.
* in Joomla 4 this refers to a prefix higher up the classname path, and should be set to either 'Site' or 'Administrator' (the capital letter at the start is optional), depending on whether you want the class under 'Robbie\Component\Helloworld\Site' or 'Robbie\Component\Helloworld\Administrator'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVC Factory class is now the Joomla recommended way to create the controller, view, model and table classes, by using the eg <tt>getModel()</tt> method, and the use of <tt>getInstance()</tt> for these classes is now deprecated. However, the use of these functions is restricted:
* in the controller class you can call <tt>$this->getView($viewname, $viewtype, $prefix, $config)</tt> to create a view and <tt>$this->getModel($modelname, $prefix, $config)</tt> to create a model.
* in the view class you can call <tt>$this->getModel($modelname)</tt>, but only for models which the controller has previously defined using <tt>$view->setModel($modelname, $default)</tt>. It doesn't create a new model instance.
* in the model class you can call <tt>$this->getTable($tableclass, $prefix, $options)</tt> to create a table instance. Controllers and views can access the table classes in this way, by going via a model.
These restrictions do have an impact on moving away from using <tt>getInstance()</tt>, and indeed in Joomla 4.2.6 you will still find several <tt>getInstance()</tt> calls within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Factory Classes===
Several other Factory classes have been introduced in Joomla 4, enabling you to get instances of core classes such as Form, User, CacheController, etc, usually by calling a createSomething function on the Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Associated with the Factory class is a FactoryInterface, a PHP Interface which specifies the key functions which the Factory class must implement. For example, with <tt>libraries/src/Categories</tt> we have:
* CategoryFactoryInterface – which specifies the <tt>createCategory</tt> function
* CategoryFactory implements CategoryFactoryInterface – which provides the <tt>createCategory</tt> function.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Dependency Injection ==
===Overview===
The DI container is one of the significant new additions to Joomla 4. It's basically a repository of key-value pairs where:
* the key is a string which is the name of a class or interface
* the value is an instance of the relevant class, or a function that returns an instance of that class.
You put things into the container using <tt>set()</tt> passing:
* the class name or interface name
* a function which returns an instance of the class (or an instance of the class)
* a boolean defining whether the class instance may be shared or not
* a boolean defining whether this entry into the DI container is protected or not (an error will be raised if you try to overwrite a protected entry by calling <tt>set()</tt> again using the same key).
The function <tt>share()</tt> is basically the same as <tt>set()</tt> with the <tt>shared</tt> boolean set to true.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You get things out of the container by calling <tt>get()</tt> passing the key of the resource you want. The container will
* find the key in the container
* if the value isn't already a class instance, then it will run the associated function to generate an instance of the class
* if the resource is shared, it will store the class instance, so that on subsequent invocations of <tt>get()</tt> it can just return the instance
* return the class instance to you
You can also define aliases for each key in the container, which means that you call <tt>get()</tt> passing either the key or an alias of the key.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The DI container is initialised in <tt>library/src/Factory.php createContainer()</tt> which results in the <tt>register()</tt> function being called in each of the class files in <tt>libraries/src/Service/Provider</tt>. By looking through those files you can see what gets put into the DI container upon initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===JConfig Example===
Let's consider the example of JConfig which holds the system global configuration. If you look inside <tt>libraries/src/Service/Provider/Config.php</tt> then you'll see the <tt>register()</tt> function and that it stores in the DI container a resource with:
* key = 'JConfig'
* value = an anonymous function - which loads what's in <tt>configuration.php</tt> into a <tt>Registry</tt> object, and returns it
* shared flag = true (because the <tt>share()</tt> function is used)
* protected flag = true
Then when you do
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$config = $container->get('JConfig');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will run the anonymous function and return the Registry object to you. As the 'shared' boolean is set it will also store a copy of the class instance locally in the container to be returned on subsequent calls of <tt>get('JConfig')</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Justification===
What's the point of all this?
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The advantage of dependency injection is that it allows classes to be easily mocked for testing. The file <tt>libraries/src/Service/Provider/Config.php</tt> can be replaced to return to a DI container <tt>get()</tt> call a mock class instead of the usual <tt>JConfig</tt>. This is in comparison to Joomla 3 where <tt>Factory::getConfig()</tt> code directly reads the <tt>configuration.php</tt> into a Registry structure and returns it – which makes it harder to mock.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The [https://api.joomla.org/cms-4/classes/Joomla-CMS-Factory.html Factory API] has several functions which are marked as deprecated with advice to get the object from the DI container instead.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Several of the other Factory classes (eg Form, Language, Menu, User) are in the DI container – so that we can get an instance of them via eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Factory::getContainer()->get('Joomla\CMS\Toolbar\ToolbarFactoryInterface')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to get a Toolbar instance. However, this only works for singleton classes which aren't specific to the needs of a particular extension. We'll see shortly how to make it work for class instances which need to be specific to a component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As indicated above, Joomla is moving away from using the class static <tt>getInstance()</tt> functions. We can see now that this is not only because it's more pure from an object oriented perspective. But also creating class instances from the DI container, or from Factory objects which are obtained from the DI container, builds in the dependency injection which allows classes to be more easily mocked, and hence more easily tested.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==services/provider.php==
We're now finally in a good position to understand what's happening in our services/provider.php file, and we'll explore this by walking through what happens whenever this line in libraries/src/Component/ComponentHelper.php <tt>renderComponent</tt> is run:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is run whenever Joomla has worked out which component is to be run on the requested web page, and it wants to run that component to capture its output.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 1 Create Child DI Container===
Joomla first creates another DI container (initially empty) just for this component, and links it to the main DI container via a parent field in the child DI container structure.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Now whenever <tt>set()</tt> is called on this DI container the key-value pair is inserted into the child container. Whenever <tt>get()</tt> is called on it, the resource is obtained from the child container, but if it's not found there then the parent container is searched also.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 2 Run register() in provider.php===
Next we encounter these lines (in <tt>libraries/src/Extension/ExtensionManagerTrait.php</tt>), where <tt>$path</tt> contains the path of our helloworld admin/services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$provider = require_once $path;
// Check if the extension supports the service provider interface
if ($provider instanceof ServiceProviderInterface) {
$provider->register($container);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here we see 3 things:
# our provider.php should return some object (so that <tt>$provider</tt> gets set to something)
# what is returned should implement ServiceProviderInterface (you can see in <tt>libraries/vendor/joomla/di/src/ServiceProviderInterface.php</tt> what is expected)
# the code then runs the <tt>register</tt> function on that object, passing as a parameter the child DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider a minimal version of our provider.php file. This would actually support steps in the Joomla 3 tutorial up to and including the [[J3.x:Developing an MVC Component/Adding AJAX|Adding Ajax step]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {

public function register(Container $container): void
{
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
}
};
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As you can see from the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
this file does indeed return something – it returns an instance of an anonymous class, one that implements <tt>ServiceProviderInterface</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it's not sufficient to just provide the <tt>register</tt> function in the class, we also need to explicity state that the class implements <tt>ServiceProviderInterface</tt>. This now happens in several places in Joomla, so if you're debugging your component and wondering why a function you expect to be called isn't being called, then check to make sure that you don't have to explicitly add the appropriate <tt>implements <Interface></tt> clause to your class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Next we look at the 3 lines in the <tt>register</tt> function
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3a Registering our MVC Factory===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here our <tt>MVCFactory</tt> refers to <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in libraries/src/Extension/Service/Provider/MVCFactory.php, and you should have a look at this file. This is a file similar to our provider.php file, but it's a named class, and it doesn't return anything. When we do:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
new MVCFactory('\\Robbie\\Component\\Helloworld')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it creates an instance of this class, and in the constructor it stores locally in <tt>$this->namespace</tt> our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>registerServiceProvider</tt> function then calls the <tt>register</tt> function of this instance, which runs (in its minimalist form):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
MVCFactoryInterface::class,
function (Container $container) {
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
return $factory;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So what gets entered into our child DI container is a key-value pair with:
* key = MVCFactoryInterface::class (this is just a shorthand form to obtain a string of the fully qualified name – ie 'Joomla\CMS\MVC\Factory\MVCFactoryInterface')
* value = a function which returns an instance of <tt>\Joomla\CMS\MVC\Factory\MVCFactory</tt>.
This is our MVCFactory class which generates our Controllers, Views, Models and Tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Notice that we're passing our namespace as a parameter <tt>$this->namespace</tt>. Because this function is a closure, this variable will still be available when we run this function later, and when the MVCFactory class is instantiated the namespace will be passed into the constructor, stored locally, and then subsequently used to form the fully qualified names of our Controllers, View, etc. So this is how we get instantiated the MVCFactory class which is specific to our component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3b Registering the Dispatcher Factory===
Careful: ComponentDispatcherFactory refers to two different classes here!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This ComponentDispatcherFactory is Joomla\CMS\Extension\Service\Provider\ComponentDispatcherFactory in libraries/src/Extension/Service/Provider/ComponentDispatcherFactory.php. Similar to the above, the ComponentDispatcherFactory service provider class stores locally our namespace, and then when <tt>register</tt> is called it executes:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentDispatcherFactoryInterface::class,
function (Container $container) {
return new \Joomla\CMS\Dispatcher\ComponentDispatcherFactory($this->namespace,$container->get(MVCFactoryInterface::class));
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so a second entry is added to the child DI container with:
* key = ComponentDispatcherFactoryInterface::class
* value = a function which returns an instance of the ComponentDispatcherFactory (the other ComponentDispatcherFactory class!), where the class constructor will be passed the namespace ('\\Robbie\\Component\\Helloworld') and an MVCFactory instance, retrieved from the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that the code
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->get(MVCFactoryInterface::class)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
will get from the container an entry with key = 'Joomla\CMS\MVC\Factory\MVCFactoryInterface' – which is what we entered into the container in step 3a – and will run the function associated with this key, and then return the object which this function returns. This returned object will be an instance of '\Joomla\CMS\MVC\Factory\MVCFactory', constructed using our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3c Including the Extension===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will put into the child DI container a key-value pair with
* key = ComponentInterface::class
* value = the function which will create an instance of our <tt>HelloworldComponent</tt> (ie our Extension class), and pass into the constructor an instance of the ComponentDispatcherFactory class, retrieving what was entered into the child DI container in Step 3b.
It will call <tt>$container->get(MVCFactoryInterface::class)</tt>, getting an MVC Factory instance from what was entered into the DI container in Step 3a.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It will then associate our component with this MVC Factory instance via the <tt>setMVCFactory</tt> call. Significantly this will then allow our component to access this instance later, via a call to <tt>getMVCFactory</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3 Summary===
We have now got 3 entries in our child DI container, keyed by
* key = MVCFactoryInterface::class, value is a function returning an MVCFactory instance
* key = ComponentDispatcherFactoryInterface::class, value is a function returning a ComponentDispatcherFactory instance
* key = ComponentInterface::class, value is a function returning our HelloworldComponent, an instance of our Extension class.
The important aspect is that these entries are all aware of our namespace '\Robbie\Component\Helloworld' and will return instances of these classes which are specific to our Helloworld component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 4 Retrieving from the DI Container===
Joomla will then execute the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $container->get($type);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
where <tt>$type</tt> contains 'Joomla\CMS\Extension\ComponentInterface'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This starts the process of retrieving from the DI container the 3 entries which we put in, and will run our code in services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We end up with a HelloworldComponent instance, which has:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. a ComponentDispatcherFactory instance passed into the constructor, and which is saved locally by the constructor code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function __construct(ComponentDispatcherFactoryInterface $dispatcherFactory)
{
$this->dispatcherFactory = $dispatcherFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This code is in libraries/src/Extension/Component.php, in the class which our HelloworldComponent extends, via the class MVCComponent).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. an MVC Factory instance, stored by the HelloworldComponent <tt>setMVCFactory</tt> call
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 5 Call boot() on our Component===
Joomla calls:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
if ($extension instanceof BootableExtensionInterface) {
$extension->boot($container);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will call <tt>boot</tt> within our HelloworldComponent, and allows us to perform some initialisation within our component. We'll return to this later, in the section on [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#HTML_Snippets|HTML snippets]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note again that Joomla checks that our HelloworldComponent class implements BootableExtensionInterface before calling <tt>boot</tt>. It's not sufficient to just provide the <tt>boot</tt> function, we have to explicitly declare that our HelloworldComponent implements the interface.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 6 Get the Dispatcher===
Returning to our key line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
we have now accomplished the first part <tt>bootComponent($option)</tt>, and this has returned our HelloworldComponent instance. Now we call <tt>getDispatcher($app)</tt> on this instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This code is also in libraries/src/Extension/Component.php, in the Component class which our HelloworldComponent extends:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function getDispatcher(CMSApplicationInterface $application): DispatcherInterface
{
return $this->dispatcherFactory->createDispatcher($application);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We call <tt>createDispatcher</tt> on our ComponentDispatcherFactory class instance which we saved in Step 4. This code is in libraries/src/Dispatcher/ComponentDispatcherFactory.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createDispatcher(CMSApplicationInterface $application, Input $input = null): DispatcherInterface
{
$name = ucfirst($application->getName());

$className = '\\' . trim($this->namespace, '\\') . '\\' . $name . '\\Dispatcher\\Dispatcher';

if (!class_exists($className)) {
if ($application->isClient('api')) {
$className = ApiDispatcher::class;
} else {
$className = ComponentDispatcher::class;
}
}

return new $className($application, $input ?: $application->input, $this->mvcFactory);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code checks if we have our own Dispatcher class (our Helloworld tutorial doesn't, but <tt>com_users</tt> for example has its own). So it creates a <tt>ComponentDispatcher</tt> instance, and passes into its constructor the MVC Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that this ComponentDispatcherFactory instance is what was instantiated when it was retrieved from our child DI Container (from being inserted in step 3b), and hence it already knows about our namespace, and has a pointer to our MVCFactory class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 7 call dispatch()===
This is the final aspect to our line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We're now back to what was described in the Dispatcher section above, except that now we can see that this Dispatcher instance has a pointer to our MVC Factory instance (which knows about our namespace prefix), so when the Dispatcher code wants to create a Controller it can use that MVC Factory instance to instantiate it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's been a long and tortuous journey to get here, but the significant thing is that all of our key class instances have been obtained via the DI Container. If we want to mock out any of those classes for testing then all we need to do is replace the relevant services/provider file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Javascript and the Web Asset Manager ==
The web asset manager has been introduced in Joomla 4 and is well documented [[J4.x:Web_Assets|here]]. It provides a much-improved means of managing JS and CSS resources, and a framework for handling their dependencies.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Component Javascript and CSS files should now be stored in the <tt>media</tt> folder, and the Web Asset Manager used to register them and output them on specific web pages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following assets have been registered in the tutorial <tt>joomla.asset.json</tt>, and you should have a look at that file now.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.validate-greeting===
This is the code for client validation of the helloworld greeting field using a regex, and it is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it is dependent upon jQuery and the Joomla <tt>form.validator</tt> script, so those both get included as dependencies.
If we didn't have specific validation on our form then we would need to include explicitly the <tt>form.validator</tt> script in order for the basic Joomla field validation to be included, eg in the tmpl file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->document->getWebAssetManager()->useScript('form.validate');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that this requires us to have a <tt>class="form-validate"</tt> on the </tt><form></tt> html element.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.fix-permissions-ajax-call===
This is the code which copies the value from the greeting field into the title field, so that the Ajax calls setting the permissions work correctly. The js code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.enable-tooltips===
This is the code which enables bootstrap tooltips to operate, including allowing them to include html code. It's used to display the image as a tooltip within the admin <tt>helloworlds</tt> view.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.openstreetmap===
This is defined as a preset, comprising the helloworld js and css code for the map display, as well as the dependency named 'com_helloworld.openlayers' relating to the openlayers CSS and js code. The code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.admin-helloworlds-modal===
This is the js code for selecting an individual helloworld record within a modal, and passing its details to the form in the main window. Its code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===submitbutton.js===
In the Joomla 3 code we introduced in [[Special:MyLanguage/J3.2:Developing_an_MVC_Component/Adding_verifications|Adding Verifications]] a js file which controlled when the form was submitted. It differentiated between buttons such as <tt>Save</tt> (which submitted the form) and <tt>Cancel</tt> (which didn't).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 there is a more sophisticated version of <tt>Joomla.submitbutton</tt> (found in media/system/js/core.js) which uses the CSS classes which the Toolbar functionality sets on the buttons to determine whether the form should be submitted or not. And you can override whether the validation is performed by adding a third parameter to the <tt>submitbutton</tt> js call. For example, to avoid validation being performed when a button is clicked you can set on the button element:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
onclick="Joomla.submitbutton('controller.method', '', false)"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As this is sufficient for what we need in the tutorial, the custom <tt>submitbutton.js</tt> has been removed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Interaction with other components ==
The way that Joomla interacts with components has changed in Joomla 4. In general the Joomla functionality will boot the component using something like:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $app->bootComponent($option);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and in our case this will return an instance of the <tt>HelloworldComponent</tt> class. It will then try to call certain methods on our extension object, as described below.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_categories===
In the backend the helloworld functionality can display to the administrator
* the view of the helloworld messages
* the view of the helloworld categories
The categories view is generated by <tt>com_categories</tt>, and in Joomla 4 these component categories views display the number of component records there are for each of the possible published status values. To do this the categories component executes the following code (in administrator/components/com_categories/src/Model/CategoriesModel.php):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof CategoryServiceInterface) {
$component->countItems($items, $section);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So our HelloworldComponent must:
* declare that it implements <tt>CategoryServiceInterface</tt>
* provide an implementation of <tt>countItems</tt>
We provide <tt>countItems</tt> by using a trait in libraries/src/Categories/CategoryServiceTrait.php, which (with the assistance of a helper function) does the query on our behalf. We just need to tell it:
* the name of our table – in the callback <tt>getTableNameForSection</tt>
* the database field in which we hold the published status – in <tt>getStateColumnForSection</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_associations===
Remember that <tt>com_associations</tt> is the component which is run whenever you click on Multilingual Associations in the admin backend.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Under Joomla 3 we provided an associations helper file as described in [[J3.x:Multilingual Associations/Developers|Multilingual Associations/Developers]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the helper file remains basically the same, but <tt>com_associations</tt> primarily tries to find the helper file via the extension class; here's the code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($extensionName);
if ($component instanceof AssociationServiceInterface) {
return $component->getAssociationsExtension();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's expecting that:
* the extension (HelloworldComponent in our case) implements <tt>AssociationServiceInterface</tt>
* its <tt>getAssociationsExtension</tt> method returns the helper class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The easiest thing would be just to code <tt>getAssociationsMethod</tt> and get it to return <tt>new AssociationsHelper</tt>. However, we follow the Joomla 4 principle of putting key classes into the Dependency Injection container, and retrieving them later, by having the following code in our services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(AssociationExtensionInterface::class, new AssociationsHelper());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The above line puts a key-value pair into our child DI container
* key = 'Joomla\CMS\Association\AssociationExtensionInterface'
* value is an instance of our <tt>AssociationsHelper</tt> class.
We then retrieve it later and use the setter:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setAssociationExtension($container->get(AssociationExtensionInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so that whenever
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getAssociationExtension()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
is called it returns the <tt>AssociationsHelper</tt> class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_fields===
<tt>com_fields</tt> is the component which is run when an administrator clicks on the Fields or Field Groups menuitem within the backend, and this functionality was included in the [[J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Adding Custom Fields]] tutorial step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>com_fields</tt> component stores the custom fields and field groups for all components in the database tables <tt>#__fields</tt> and <tt>#__fields_groups</tt>, and these tables are partitioned into "sections", one section per component. For our helloworld component the section is named "helloworld".
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within the section we have 2 "contexts" – one for the helloworld messages (called "com_helloworld.helloworld") and one for the helloworld categories (called "com_helloworld.categories"). This enables us to define custom fields for both our helloworld records and helloworld category records.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When <tt>com_fields</tt> runs it checks both the section and contexts at various times. For example, when an admin selects Helloworld / Fields on the backend then <tt>com_fields</tt> checks the section which was defined in the menuitem in the manifest file (see [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Sidebar|below]]). Here's the code in administrator/components/com_fields/src/Helpers/FieldsHelper <tt>extract</tt> function:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
$newSection = $component->validateSection($parts[1], $item);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And when <tt>com_fields</tt> wants to display the little dropdown menu of contexts (to allow the administrator to set custom fields on either helloworld items or categories) it calls (in administrator/components/com_fields/src/Fields/FieldcontextsField.php <tt>getOptions()</tt>):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
return $component->getContexts();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So it's clear that our component extension class must :
* implement <tt>FieldsServiceInterface</tt>
* provide the <tt>validateSection</tt> and <tt>getContexts</tt> methods
So in upgrading to Joomla 4 we've just moved those two methods from the helper file to the extension class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Router===
The Joomla router will access our custom router code:
* whenever it wants to parse an SEF route which it has identified as belonging to <tt>com_helloworld</tt>
* whenever it wants to build an SEF route from a call to <tt>Route::_()</tt> where the option = "com_helloworld".
To find our custom router it will:
* boot the <tt>com_helloworld</tt> extension
* check that the extension implements <tt>RouterServiceInterface</tt>
* call <tt>createRouter</tt> on our extension instance
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In our services/provider.php file we have (careful again - 2 different RouterFactory classes!):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new RouterFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which from libraries/src/Extension/Service/Provider/RouterFactory.php puts into our child DI container an entry with:
* key = "Joomla\CMS\Component\Router\RouterFactoryInterface"
* value is a <tt>\Joomla\CMS\Component\Router\RouterFactory</tt> instance, constructed with our namespace
We then retrieve this in the line in our services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setRouterFactory($container->get(RouterFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And then within our extension class we have
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use RouterServiceTrait;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which includes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function setRouterFactory(RouterFactoryInterface $routerFactory)
{
$this->routerFactory = $routerFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which stores the <tt>routerFactory</tt> locally and
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return $this->routerFactory->createRouter($application, $menu);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which provides our extension's <tt>createRouter</tt> call that the Joomla Router expects.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>routerFactory::createRouter</tt> method is in libraries/src/Component/Router/RouterFactory.php. It looks for a class in our site namespace </tt>Robbie\Component\Helloworld\Site\Service\Router</tt> which is in our site/src/Service/Router.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
At this stage we have a choice, we can either:
* provide a traditional custom router, with the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions, or
* use the more modern <tt>RouterView</tt> mechanism.
By default in the upgraded tutorial code the Router View option has been coded in the Router.php file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====RouterView====
In the <tt>RouterView</tt> case the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions are in the <tt>RouterView</tt> class which we extend, and we provide
* a constructor with router view configuration
* methods <tt>getHelloworldId</tt> and <tt>getCategoryId</tt> which are used to obtain from the SEF segment the <tt>id=</tt> and <tt>catid=</tt> parts of the internal URL
* methods <tt>getHelloworldSegment</tt> and <tt>getCategorySegment</tt> which are used to generate segments for the SEF URLs based on the <tt>id=</tt> and <tt>catid=</tt> parts within the <tt>Route::_()</tt> parameter.
Unfortunately there doesn't seem to be a good guide to configuring the RouterView class. There is some documentation available [https://www.dionysopoulos.me/book/com-router-routerview.html here].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the helloworld tutorial we have 3 views
* a view which displays a single helloworld record
* a view which displays a single helloworld category, and the helloworld records associated with it
* a view which displays the frontend form
So we need 3 Router Views associated with these.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'form' view doesn't have an associated id or catid so it's just a fixed URL, and the router just has to convert between the alias of the form menuitem and the Itemid / view parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'category' view has an associated id (of the category record), and an SEF URL will use the category path down the Categories Nested Set table structure, hence <tt>setNestable()</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'helloworld' view has an associated id (of the helloworld record), and in an SEF URL in the category view the helloworld record alias is added to the category path (hence <tt>setParent()</tt>). But although the helloworld records use a Nested Table structure in the database, the URLs just include the alias of the single record, and so <tt>setNestable()</tt> is not used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There doesn't seem to be a way to configure an additional SEF URL scheme which just displays a helloworld segment, without a category segment.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====Traditional Router====
To use the traditional router in the tutorial code you should uncomment the function in the extension class:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return new TraditionalRouter($application, $menu, $this->categoryFactory, $this->getDatabase());
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will cause the code in site/src/Service/TraditionalRouter.php to be used. However, changes in the Joomla 4 router mean that the interaction between it and the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> methods have changed. This requires significant changes to the <tt>preprocess</tt> and <tt>build</tt> methods, but only a minor change to <tt>parse</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. Previously Joomla injected into the <tt>$query</tt> parameters the <tt>Itemid</tt> of the active menuitem (ie the id of the menuitem the user is currently on). This meant that we had to change the <tt>Itemid</tt> for links generated by the Language Switcher module (which generates the flags for switching between languages), and these links being associated with a different language would obviously use a different <tt>Itemid</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 you get an <tt>Itemid</tt> in the <tt>$query</tt> parameters only if you specified an <tt>Itemid</tt> in the <tt>Route::_()</tt> call. For others you have to work out which menuitem to use yourself, by using the Joomla menu/menuitems API to find details of the configured menuitems, and work out which to use based on the other <tt>$query</tt> parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You do this in the <tt>preprocess</tt> method, and then the <tt>Itemid</tt> you set will be passed in the <tt>$query</tt> parameters to the <tt>build</tt> method.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. In some instances the <tt>Route::_()</tt> URL you're generating matches exactly one of the configured menuitems on the site. In this case the <tt>$query</tt> parameters will match those in the menuitem <tt>"query"</tt> array, and you have to remove explicitly remove the 'view', 'id' and 'catid' parameters so that they don't appear as URL query parameters after the normal SEF URL of the menuitem.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
3. The custom router will be used to build the URLs for the helloworld menuitems shown in menus on the page. For these the <tt>$query</tt> parameters will have the view / id / catid associated with those menuitems. Note that even if you remove these in your <tt>preprocess</tt> method, Joomla will inject them again into the <tt>$query</tt> array when it's passed to your <tt>build</tt> method, so you'll have to remove them again there!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
4. In the <tt>parse</tt> method you now have to unset the <tt>$segments</tt>, or else Joomla will return an HTTP 404 (page not found). Otherwise <tt>parse</tt> works as before.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
5. I've implemented <tt>build</tt> only for when Multilanguage is enabled on the site. If it's not enabled an empty <tt>$segments</tt> array is just returned, without doing unset on any of the <tt>$query</tt> parameters, so these will appear as URL parameters after the SEF URL. Also it's not coded properly to deal with items which have language set to <tt>*</tt>. These include helloworld records, categories or menuitems (eg the helloworld form).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that the <tt>categoryFactory</tt> is also now passed to the router. This is so that it can be used instead of <tt>Categories::getInstance()</tt> to get access to the Categories API calls.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_tags===
Whenever we setup a Tags Menu Item Type which displays items having a given tag or tags, then <tt>com_tags</tt> displays those items as links, and uses route helper functions to generate the URL parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The route helpers <tt>com_tags</tt> expects to find loaded into the data of the <tt>#__content_types</tt> table, in the router field, and these have been set to:
* For links to helloworld items: 'HelloworldHelperRoute::getHelloworldRoute'
* For links to helloworld categories: 'HelloworldHelperRoute::getCategoryRoute'
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, <tt>com_tags</tt> doesn't boot the helloworld extension to get access to these, but rather seeks to find them in site/helpers/route.php, so that's where they continue to be.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(We also had a <tt>getCategoryRoute</tt> which was used by <tt>com_categories</tt> in administrator/components/com_categories/src/Helper/CategoryAssociationHelper. When a category was displayed on the frontend then the Language Switcher module (now Language Filter) used this function to generate the links to the Associated Categories. Our <tt>getCategoryRoute</tt> previously was necessary to insert the <tt>lang=<language tag></tt> parameter into the link URL, but since [https://github.com/joomla/joomla-cms/pull/39358 this change] the calling function inserts the <tt>lang</tt> parameter itself, so our <tt>getCategoryRoute</tt> function for this purposes is superfluous.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Deprecated APIs ==
With Joomla 4 there are a number of methods which are deprecated, with a view to removing them in Joomla 5.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Factory Methods===
Many of the <tt>Factory</tt> methods for getting singleton classes have been deprecated in favour of getting these classes via the DI container, and it appears that only class instances which should be obtained via Factory methods are:
* the Application – <tt>Factory::getApplication()</tt>
* the DI container – <tt>Factory::getContainer()</tt>
Here is a list of what has been changed in the tutorial code. Note that with some calls there are variants available, through the aliases defined in the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDbo'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\Database\DatabaseInterface;
...
$db = Factory::getContainer()->get(DatabaseInterface::class);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, in many classes the database instance is more easily (and efficiently) returned via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$db = $this->getDatabase();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is available in Model classes, custom field definitions, etc.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getUser();'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get the current user use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = Factory::getApplication()->getIdentity()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get a different user (whose id you know):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\User\UserFactoryInterface;
...
$user = Factory::getContainer()->get(UserFactoryInterface::class)->loadUserById($userid);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within models which extend Joomla\CMS\MVC\Model\BaseDatabaseModel and views which extend Joomla\CMS\MVC\View\HtmlView you can also use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = $this->getCurrentUser()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDocument()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication()->getDocument()</tt>, or within a View you can use <tt>$this->document</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getConfig()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Two options have been used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->getConfig()</tt> – returns a Registry object containing all the configuration values
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->get('access')</tt> – returns the value of the 'access' configuration parameter
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getLanguage()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication->getLanguage()</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JFactory::getCache('com_example', <type>)'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Cache\CacheControllerFactoryInterface;
...
Factory::getContainer()->get(CacheControllerFactoryInterface::class)->createCacheController(<type>)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated getInstance Methods===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general <tt>getInstance()</tt> calls have been deprecated in favour of obtaining the instance, either via a factory class or via the DI container. For example, within a controller you can use <tt>getModel()</tt> repeatedly to get different models (passing the relevant model names), which results in the MVCFactory class creating the Model classes.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there are currently some problems with replacing some getInstance calls. I expect that the Joomla team will resolve these issues over the course of the Joomla 4 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Categories::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is deprecated with a notice: "Use the ComponentInterface to get the categories". This means that we should get the category factory instance via the DI container. This is done in our services/provider.php by the lines:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Extension\Service\Provider\CategoryFactory;
...
$container->registerServiceProvider(new CategoryFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to put into our child DI container the closure which will create a Joomla\CMS\Categories\CategoryFactory instance, constructed with our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when our HelloworldComponent (Extension) instance is created:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We can then use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getCategoryFactory()->createCategory();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to create our Categories object, and in this way get access to the Categories APIs.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This createCategory method creates the instance by looking for the \\Site\\Service\\Category class within our namespace. The constructor in our class sets our extension ('com_helloworld') and table ('#__helloworld') and calls the parent Categories constructor with these options).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this means that the section of our code where we want to use the Categories APIs must have a pointer to a CategoryFactory instance. In the tutorial code for Joomla 3 there are 2 places where <tt>Categories::getInstance</tt> is used:
* in the custom router code, to handle building and parsing of the category parts of the SEF URL
* in the site category model, where the Categories APIs are used to obtain details of categories to display on the page.
For the custom router code, the CategoryFactory instance is passed as a parameter to the TraditionalRouter constructor so that it can be used there.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, the site category model is instantiated by the MVCFactory instance, and it doesn't make available a CategoryFactory instance. So in this category model the calls to <tt>Categories::getInstance()</tt> have been left, and you can still find a number of calls to <tt>Categories::getInstance</tt> within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Categories::getInstance()</tt> itself solves the problem of access to a CategoryFactory instance by rebooting our component again to get a pointer to our Extension instance, and thus to the category factory instance. However, this involves a lot of work, so <tt>getInstance</tt> caches locally the Categories instances and just returns one of them if it can.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Pushing the CategoryFactory to the model'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there is a way to get access to the CategoryFactory instance, by defining your own MVCFactory class, and pushing the instance down through it to the model. Here's how you can go about it:
* Define your own SuperMVCFactory class, which extends the Joomla Joomla\CMS\MVC\Factory\MVCFactory class, but which has a means of storing a CategoryFactory instance. Use the CategoryServiceTrait in libraries/src/Categories/CategoryServiceTrait.php
* Create your own version of the file libraries/src/Extension/Service/Provider/MVCFactory.php, which is the 'provider.php' like file for MVCFactory, but change it so that:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
becomes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new <namespace>\SuperMVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and include
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla creates a model such as CategoryModel it passes in its constructor the MVCFactory instance (so that the model can call createTable on it), so you can access it via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will return your SuperMVCFactory instance. So in this way within the model you can access the CategoryFactory, and use it to create the Categories instance via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()->getCategory() (from the CategoryServiceTrait)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you can get this working you can congratulate yourself on a good understanding of Joomla namespacing and dependency injection! A similar approach to address a similar problem is described [https://www.dionysopoulos.me/book/com-router-push-dependencies.html here]. If you get stuck you can always view the solution by viewing the github tutorial code selecting the branch [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial/tree/push-category-factory-to-mvc push-category-factory-to-mvc].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Table::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There are a couple of calls to <tt>Table::getInstance()</tt> within admin/src/Helper/AssociationsHelper.php in <tt>getItem()</tt>:
* <tt>Table::getInstance('Helloworld', 'Robbie\\Component\\Helloworld\\Administrator\\Table\\')</tt> to get an instance of our HelloworldTable class.
* <tt>Table::getInstance('Category')</tt> to get an instance of the Category table in libraries/src/Table/Category.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We could actually arrange for the AssociationsHelper class to get injected with the MVCFactory instance, so that the HelloworldTable class could be instantiated by it. However, we couldn't use the helloworld MVCFactory instance to create the Category table instance, as it's not in the helloworld namespace, and our MVCFactory instance creates table instances within our namespace only.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Toolbar::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The tutorial code uses <tt>Toolbar::getInstance()</tt> to get a Toolbar instance onto which it can attach the batch button in the helloworlds form. The Toolbar API documentation seems to suggest that we should replace
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Toolbar::getInstance('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
with
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this currently won't work. The problem is that all the other Joomla code uses <tt>getInstance('toolbar')</tt> to access the Toolbar class, including the code in administrator/modules/mod_toolbar/mod_toolbar.php which renders the toolbar. The <tt>getInstance</tt> method keeps track of the Toolbar instances in a local static variable <tt>$instances</tt>, and returns the same Toolbar instance on repeated invocations.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you use the second approach above you will get a Toolbar instance, but it won't be the same Toolbar instance as is stored in the <tt>$instances</tt> variable. It won't then be picked up by the Toolbar module, and so won't be rendered on the form.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Error Handling===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead of
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
JError::raiseError(500, implode('<br />', $errors));
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
you should throw an exception, using or extending one of the standard [https://www.php.net/manual/en/spl.exceptions.php PHP exceptions], eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
throw new \Exception(implode("\n", $errors), 500);
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===jimport===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
jimport is no longer necessary in order to get access to Path or File classes. All of the Joomla classes are found by the autoloader.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Methods related to Javascript===
'''JHtml::_('behavior.framework');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general, the use of JHtml::_('behavior.xxx') is now obsolete, and calls using this have been removed in the tutorial code. The 'behavior.framework' call referred to including jQuery. Where jQuery is necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.formvalidator');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by the <tt>form.validate</tt> javascript asset, and where necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It can also be included directly using the web asset manager:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$wa->useScript('form.validate')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.tooltip')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This no longer exists, and tooltips don't seem to be enabled by default in Joomla 4. This is replaced by the code in media/js/enable-tooltips.js.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('formbehavior.chosen')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The chosen js library seems to be no longer used, and using it will cause formatting issues if you include it in your tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''sortable'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The sortable js library provided the ability in the helloworlds view to drag rows up and down to change the ordering of the records. This has been replaced in Joomla 4 by the draggable library. To enable it you have to set:
* <tt>HTMLHelper::_('draggablelist.draggable');</tt>
* on your <tt><tbody></tt> element define the table in which dragging occurs and the URL of the Ajax call to set the ordering:
<source lang="php">
<tbody<?php if ($saveOrder) : ?> class="js-draggable" data-url="<?php echo $saveOrderingUrl; ?>" data-direction="<?php echo strtolower($listDirn); ?>" data-nested="true"
<?php endif; ?>>
</source>
* on your <tt>tr</tt> element within your <tt><tbody></tt> define the group of records in which dragging occurs (by category below):
<source lang="php">
<tr class="row<?php echo $i % 2; ?>" data-draggable-group="<?php echo $row->catid; ?>">
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==HTML Snippets==
There are two places in the tutorial where reusable snippets of HTML have beeen defined:
* For displaying the item associations in the helloworlds view:
* For displaying the position latitude and longitude fields within the batch options in the helloworlds view
These used different approaches:
* the item associations display was coded in an html helper file in admin/helpers/html/helloworlds.php and accessed via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JHtml::_('helloworlds.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
in the helloworlds tmpl file. (Although it did use a common joomla layout file underneath).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* the position field was coded as a layout in layouts/position.php, and rendered using
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JLayoutHelper::render('position', array());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When should you use one approach rather than the other? A significant difference is that layouts are designed so that an administrator can override them, via the Templates / Details and File functionality. So, for example, an administrator could change the position to show the longitude before the latitude. So it's more appropriate for layouts to focus on the html elements rather than functional logic, and particularly if you would want to allow an administrator to override the layout.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The layouts functionality in Joomla 4 hasn't changed significantly. One correction which has been made in the updated tutorial code has been to include the position.php file in a subfolder of layouts, ie in admin/layouts/helloworld/position.php rather than admin/layouts/position.php. It appears that in the Templates / Details and Files / Create Overrides tab the <tt>com_helloworld</tt> layout appears only if it's in a subfolder of /layouts.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>JHtml::_()</tt> approach has changed in Joomla 4. Rather than Joomla having to look for a helper file when it encounters something it doesn't recognise, it's expected that you should register such classes beforehand, and you do this by obtaining an instance of the Joomla\CMS\HTML\Registry class (it's a singleton class) and then calling <tt>register</tt> on it, passing
* the key you want to use
* an instance of your class
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Joomla pattern is to put the code in a file admin/src/Service/HTML/AdministratorService.php, and we have to ensure that our key won't be used elsewhere within Joomla, so in the tutorial we've used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Robbie\Component\Helloworld\Administrator\Service\HTML\AdministratorService;
...
register('helloworldadministrator', new AdministratorService)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when we call:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo HTMLHelper::_('helloworldadministrator.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will result in Joomla calling the <tt>association</tt> method in our class, passing the <tt>$row->id</tt> parameter.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We should get the Joomla\CMS\HTML\Registry class from the Dependency Injection container. Joomla components generally do this via their services/provider.php file, and then call <tt>register</tt> within the extension's <tt>boot</tt> function, described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Step_5_Call_boot.28.29_on_our_Component|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The extension uses HTMLRegistryAwareTrait which contains <tt>setRegistry</tt> and <tt>getRegistry methods</tt>. In services/provider.php there is:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\HTML\Registry;
...
$component->setRegistry($container->get(Registry::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets 'Joomla\CMS\HTML\Registry' out of the DI container and stores it within the
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
private $registry;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
variable of the HTMLRegistryAwareTrait included in the extension.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the <tt>boot</tt> function it calls
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getRegistry()->register('helloworldadministrator', new AdministratorService);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets the registry and calls <tt>register</tt> as required.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that <tt>boot</tt> is called whenever Joomla dispatches <tt>com_helloworld</tt>, both for the site and administrator, so it would make sense to check the Application <tt>isClient</tt> before deciding whether to register the HTML Helper service or not. This hasn't been included in the tutorial code though.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==User Interface Changes==
Joomla 4 introduced new templates, atum on administrator and cassiopeia on site, and in particular the administrator is built upon some UI rearrangements which affect the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Sidebar===
In Joomla 3 each component incorporated a sidebar which we coded in the <tt>addSubmenu</tt> function in admin/helpers/helloworld.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the administrator menu is in a vertical panel on the left hand side, and the Hello World submenu is built from entries in the helloworld.xml manifest file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<administration>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<submenu>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<menu link="option=com_categories&extension=com_helloworld">COM_HELLOWORLD_CATEGORIES</menu>
<menu link="option=com_fields&view=fields&context=com_helloworld.helloworld">MOD_MENU_FIELDS</menu>
<menu link="option=com_fields&view=groups&context=com_helloworld.helloworld">MOD_MENU_FIELDS_GROUP</menu>
</submenu>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===CSS Classes===
In several places the CSS classes defined in the html elements have been changed in Joomla 4. For example, for general layout the classes now align with the [https://getbootstrap.com/docs/3.4/css/ Bootstrap CSS Classes], and classes such as <tt>row-fluid</tt> and <tt>span3</tt> which were prominent in Joomla 3 have disappeared. If you're upgrading a Joomla 3 component then it's probably best (on the back-end at least) to find a similar Joomla component and use the overall html structure and css classes within its tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the tutorial code those classes which are specifically used by Bootstrap have been changed from eg 'data-target' to 'data-bs-target', and it has been necessary to change these to enable the functionality to work.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, not all of CSS class changes affecting solely the presentation have been reflected in the updated tutorial code. For example, in the <tt>helloworlds</tt> view, showing the list of helloworld messages, the display of the associations is different from that of other Joomla components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Fonts===
In Joomla 3 [[J3.x:Joomla_Standard_Icomoon_Fonts|Icomoon Fonts]] were used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 Font Awesome's free icons are used, and you can see what is available on their [https://fontawesome.com/v5/cheatsheet cheatsheet]. The icons are implemented using CSS pseudo-elements, as described [https://fontawesome.com/v5/docs/web/advanced/css-pseudo-elements here]. Basically they convert a CSS class into html content, namely a unicode value in the private use range. A couple of these have been implemented in the frontend form, in the Save and Cancel buttons, for example:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>span class="icon-cancel">/span <?php echo Text::_('JCANCEL') ?></tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(with angle brackets removed from the <tt>span</tt> tags to stop the icon just being displayed by the browser).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This class is defined in media/system/css/joomla-fontawesome.css (where you can find the list of icon classes supported):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
.icon-cancel:before {
content: "\f00d";
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so this includes in front of the text the unicode character <tt>f00d</tt>, which you can see on the cheatsheet as "times", and displayed as <span class="icon-cancel"></span>. You can also use <tt>fa-</tt> plus the icon name on the font awesome cheatsheet page. If you use Icomoon icon names in your code which you run under Joomla 4, then the icon displayed will be a Font Awesome icon (if there's one with the same name) or it will use a mapping which the Joomla team have defined to display a Font Awesome icon which resembles the Icomoon one.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Buttons and Links===
An accessibility principle is that <tt><a></tt> html elements should be used for links to other web pages, and <tt><button></tt> elements should be used for actions, eg on a form. To align with this, the <tt><a></tt> elements in the helloworld modal field (defined in admin/src/Field/Modal/Helloworld.php) have been changed to <tt><button></tt> elements. These are the Select and Clear buttons displayed when choosing a Helloworld record for a menuitem pointing to a Helloworld message. (The buttons also include fontawesome icons, by the way).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This change was actually made in Joomla in one of the Joomla 3 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Categories View===
In the Categories view of standard Joomla components there now appears columns which show for each category the number of items, split by published status. This is populated by <tt>com_categories</tt> calling each extension's <tt>countItems</tt> function, as described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_categories|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Miscellaneous Changes==
===Version History===
In Joomla 3 the tutorial code used the <tt>JTableObserver</tt> functionality to copy relevant changes from the Helloworld and Categories tables into the UCM tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it uses a plugin mechanism to subscribe to Table events 'onTableAfterStore' and 'onTableBeforeDelete'. The plugin can be found in plugins/behaviour/versionable, and it is activated by Joomla as part of its application initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The copying of fields from the table works roughly the same way as before, except that the name of the table where the versions are stored is now <tt>#__history</tt>, so the entries which have to be inserted into the <tt>#__content_types</tt> table are fairly similar. Because the folders in which forms are stored has changed in Joomla 4, the 'formFile' parameter is different (remember that this is where Joomla gets the field labels in order to display the Preview within the Versions modal window, otherwise just the names of the database columns will be output).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here's a summary of what needs to be done to enable versioning under Joomla 4. The Versioning Traits and Interface definitions are found in libraries/src/Versioning:
* Enter data into content_types database table
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Storing the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The Table class must implement VersionableTableInterface and provide <tt>getTypeAlias()</tt>, which returns 'com_helloworld.helloworld'. This type alias + the helloworld record id is used as the key to identify versions in the <tt>#__history</tt> table.
* Define <tt>save_history</tt> and <tt>history_limit</tt> options in config.php, and ensure these are both set.
* Add a <tt>version_note</tt> field into the output of the edit view's tmpl file (admin/tmpl/helloworld/edit.php).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Viewing and Restoring the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit Controller (admin/src/Controller/HelloworldController.php) should <tt>use VersionableControllerTrait</tt>.
* The edit Model (admin/src/Model/HelloworldModel.php) should <tt>use VersionableModelTrait</tt> and include a variable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public $typeAlias = 'com_helloworld.helloworld';
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit View (admin/src/View/Helloworld/HtmlView.php) – should display the Versions toolbar button if global config has <tt>save_history</tt> on.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Joomla 4 allows us to have different history version limits for helloworld items and categories, and this has been used in the configuration definition in admin/config.xml.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Setting Configuration Parameters in Install Script===
As you may remember, global configuration parameters relating to the Hello World component are defined in admin/config.xml and stored in the <tt>#__extensions</tt> table, in a JSON string in the params field of the record relating to <tt>com_helloworld</tt>. This means that when the component is first installed the params are not set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So, for example, even if the <tt>save_history</tt> is defined in config.xml to default to true, the versions won't be saved until an administrator actively saves the configuration parameters, because the Joomla versioning code assumes <tt>save_history</tt> to be false if it's not explicitly set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For this reason it makes sense to set any default configuration parameters in the install script.php, in the <tt>postflight</tt> method, and that has been done in this step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Tags===
Like version history, tags functionality has been changed to use a plugin – in plugins/behaviour/taggable – rather than the <tt>JTableObserver</tt> approach.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To enable tags the component table must implement TaggableTableInterface (in libraries/src/Tag), and provide the <tt>getTypeAlias()</tt> which is common to the Versioning functionality.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Whenever <tt>com_tags</tt> outputs helloworld messages or categories relating to a tag it displays them as links, and looks in the site/helpers/route.php file to find the route functions (as described above in [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_tags|com_tags]]). The class and method in this file must match the 'router' field within the data entered into the <tt>#__content_types</tt> table.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===media files===
Under Joomla 4 all of the media files are stored in the /media folder; these include javascript and css files (scss files too), as well as images such as the little flag symbols shown in the language switcher. Extensions being developed should store all of the js and css files in their /media folder, and then when the extension is installed these files are put under the extension's folder under the /media folder of the Joomla instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Patches==
Some bugs in Joomla were discovered during the course of updating the tutorial code to work under Joomla 4. If you find something doesn't work then make sure you're on at least Joomla 4.2.6 and check if you need one of the following patches:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
CategoryAssociationHelper.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39358/files
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
MediaField.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/issues/39203
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Category restore
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39474
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Contributors ==
*[[User:Robbiej|Robbie Jackson]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Prev: Adding Custom Fields|class=expand success}}</div>
</div>
</div>

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/20/it

2023-05-27T12:44:22Z

Quando Joomla 3 ha voluto chiamare le funzioni nel tuo componente, ha cercato determinati nomi di file in cartelle particolari e ha verificato che il nome della classe in quel file corrispondesse a quello previsto.

J3.x:Developing an MVC Component/Upgrading to Joomla4/it

2023-05-27T12:44:12Z

Ing Pulizzi: Created page with "'''Nota che le lettere maiuscole sono importanti nei namespace, nei nomi delle classi e nei nomi dei percorsi!'''"

<noinclude><languages /></noinclude>

{{:J3.1:Developing an MVC Component/it}}
Questo passaggio copre ciò che è coinvolto nell'aggiornamento del codice del tutorial per allinearlo con la versione 4 di Joomla.

== Introduzione ==
Questa pagina descrive i principali aspetti relativi allo sviluppo dei componenti che sono stati introdotti in Joomla 4 e descrive in dettaglio cosa è stato modificato nel codice del tutorial per allinearsi con v4.

Non è pratico dettagliare tutte le modifiche al codice sulla pagina Web come è stato fatto per i passaggi precedenti dell'esercitazione. Invece puoi trovare il codice come repository github su [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial Joomla 4 Tutorial code], e puoi confrontarlo con il codice del passaggio precedente del tutorial (Adding Custom Fields) su [https://github.com/robbiejackson/Joomla-3-MVC-Tutorial Joomla 3 MVC code]. Il codice di Joomla 4 replica tutte le funzionalità del codice di Joomla 3, con l'eccezione dell'implementazione dell'icona del piccolo pinguino introdotta in [[S:MyLanguage/J3.2:Developing an MVC Component/Adding decorations to the backend|Aggiunta di decorazioni al backend]] (che non è così rilevante data la modifica dell'interfaccia utente in Joomla 4 Administrator) e l'uso di un plug-in CAPTCHA ([[J3.x:Developing an MVC Component/Adding a frontend form|Adding a frontend form]] ). Probabilmente troverai utile avere a portata di mano questo codice Joomla 4 a cui fare riferimento mentre leggi questa pagina.

Il codice per questo passaggio è stato sviluppato seguendo ciascuno dei precedenti passaggi del tutorial e cercando di far funzionare ogni passaggio con Joomla 4.2.5. Poiché Joomla 4 si sta ancora evolvendo abbastanza velocemente, è possibile che alcuni aspetti qui citati vengano modificati durante la vita di Joomla 4. Sentiti libero di correggere gli aspetti in questa pagina e creare richieste pull su [https://github.com/robbiejackson /Joomla-4-MVC-Tutorial Joomla 4 github repository].

Se stai installando il codice del tutorial di Joomla 4 su una nuova istanza di Joomla, dovrai configurare la tua istanza per renderla multilingue e aggiungere le voci di menu nascoste di Ajax come descritto nel passaggio [[J3.x:Developing an MVC Component/ Utilizzo del filtro della lingua |Utilizzo del filtro della lingua]]. Assicurati inoltre che ogni record helloworld abbia una categoria valida.

=== Ulteriori letture ===
Puoi trovare [https://blog.astrid-guenther.de/en/der-weg-zu-joomla4-erweiterungen/ qui] un tutorial per lo sviluppo dei componenti di Joomla 4, simile a questo Joomla 3, e alcuni eccellenti Joomla 4 è disponibile anche la documentazione [https://www.dionysopoulos.me/book.html qui]. Entrambi questi riferimenti includono descrizioni degli impatti di Joomla 4 sullo sviluppo di altri tipi di estensioni Joomla (plugin, moduli e modelli), che non sono trattati qui.

Questo passaggio non copre tutto ciò che è necessario per aggiornare un componente da Joomla 3 a Joomla 4, solo gli aspetti coperti dal codice del tutorial. Se stai aggiornando il tuo componente Joomla 3, potresti trovare utile esaminare [[Potenziali problemi di compatibilità con le versioni precedenti in Joomla 4]].

== NameSpace ==
===NameSpace dei nomi dei componenti===
I NameSpace delle classi che utilizza la [https://www.php-fig.org/psr/psr-4/ PSR-4 recommendation] è stato gradualmente introdotto durante le versioni di Joomla 3 e con Joomla 4 è praticamente tutto con NameSpace

Ora è previsto che anche le estensioni di Joomla utilizzino i NameSpace di base per l'estensione definito nel suo file XML manifest. I componenti di Joomla usano uno NameSpace della forma <tt>Joomla\Component\<Nome componente></tt> es. <tt>Joomla\Component\Content</tt>, quindi seguendo questo schema ho dato una base al codice del tutorial spazio dei nomi di <tt>Robbie\Component\Helloworld</tt>. Ecco la riga nel file manifest helloworld.xml:

<namespace path="src">Robbie\Component\Helloworld</namespace>

(L'attributo <tt>path="src"</tt> indica che si aspetterà che le classi si trovino nella sottocartella <tt>src</tt>.)

Questo in realtà crea 2 prefissi dello spazio dei nomi, che puntano a cartelle specifiche nella nostra struttura di sviluppo helloworld e nella nostra istanza joomla live:

<tt>Robbie\Component\Helloworld\Administrator</tt> – punterà ad administrator/components/com_helloworld/src sull'istanza live ed è associato ad admin/src nella nostra area di sviluppo.

<tt>Robbie\Component\Helloworld\Site</tt> – punterà a components/com_helloworld/src sull'istanza live ed è associato a site/src nella nostra area di sviluppo.

Quindi Joomla ora si aspetta che tutti i nomi delle classi vengano trovati in quelle directory di base, con il nome del file che corrisponde al nome della classe e il nome della classe completo che corrisponde al percorso, ad esempio

<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> si troverà in
administrator/components/com_helloworld/src/Controller/DisplayController.php

<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> si troverà in
components/com_helloworld/src/Model/CategoryModel.php

'''Nota che le lettere maiuscole sono importanti nei namespace, nei nomi delle classi e nei nomi dei percorsi!'''

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla 3 wanted to call functions in your component it looked for certain file names in particular folders, and checked that the name of the class in that file matched what it expected.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it generates the fully qualified name of the class it wants to find, and then looks to find it in the location where the PSR-4 recommendation would expect it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Hence the namespace you specify in your class files must align with the file path to your PHP file, below the base <tt>src</tt> folder at your namespace prefix.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note in particular how the <tt>View</tt> class files are now organised.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Also if you use one of the PHP predefined classes (eg <tt>Exception</tt>) in your code, then add a backslash before it (eg <tt>\Exception</tt>), otherwise PHP will try and find it in your namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you use custom Field or Rule definitions in your form xml files then you have to indicate to PHP which namespace prefix to use to look for them, eg in <tt>site/forms/add-form.xml</tt>:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
addruleprefix="Robbie\Component\Helloworld\Administrator\Rule"
addfieldprefix="Robbie\Component\Helloworld\Administrator\Field"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and also in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> where the associations are added into the form dynamically to form the custom <tt>modal_helloworld</tt> type field:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Class Autoloading===
Joomla uses the PHP mechanism for [https://www.php.net/manual/en/language.oop5.autoload.php Autoloading Classes] and on startup registers a number of autoloaders – functions which get called when PHP can't find a given class. In particular the Joomla PSR-4 autoloader function (in <tt>libraries/loader.php</tt>) is responsible for finding classes of Joomla extensions whose code is in source files which are organised according to the PSR-4 recommendation. (Joomla library classes are autoloaded using a different autoloader – see <tt>libraries/vendor/composer/autoload_static.php</tt>).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can see the namespace prefixes of extensions on the Joomla instance by looking at <tt>administrator/cache/autoload_psr4.php</tt>. (These namespace strings have double backslashes, but in PHP they're the [https://stackoverflow.com/questions/25459197/single-or-double-slash-when-using-php-namespace same strings as those with single backslashes]). This is generated by Joomla looking through the component, module and plugin directories to find each extension's manifest file, and then processing these xml files to extract the <tt><namespace></tt> element – quite a lot of work, which is why it's cached I guess!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider what happens when Joomla wants our admin HelloworldController class. It might have something like
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$classname = 'Robbie\Component\Helloworld\Administrator\Controller\HelloworldController'
if (!class_exists($classname)) { …
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Assuming PHP doesn't already know about this class, the <tt>class_exists</tt> function will result in the classname being passed to the registered autoload function(s). The PSR-4 autoloader will then:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# go through its array of namespaces to try and match <tt>$classname</tt> from the start of the string.
# find 'Robbie\Component\Helloworld\Administrator' as a match
# see that this maps to "administrator/components/com_helloworld/src"
# extract the remainder of the classname: 'Controller\HelloworldController'
# treat this as the path down to the class file
# and so look for "administrator/components/com_helloworld/src/Controller/HelloworldController.php"
# check that in this file there's actually a class with that namespace + class name.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So in this way Joomla can go from a fully qualified class name to find the source code for that class. This makes it easier for us too when the core Joomla code is looking for one of our classes. We still need to know what class it's looking for, but once we know that, we know what we should call our class and where we should save the source code for it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Joomla Library classes===
Originally Joomla's core classes (beginning with a capital J) were global classes. Over the Joomla 3 versions and into Joomla 4 these migrated to their namespaced equivalents, but the original global classnames were still available as Joomla registered them as aliases (in the <tt>libraries/classmap.php</tt> file).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In a Joomla 4 extension you can still use these global classnames, except that in a namespaced file you'd have to prefix the name with a backslash to indicate a global class rather than one in your namespace (eg <tt>\JFactory</tt> instead of <tt>JFactory</tt>).
However it's pretty definite that the aliases will disappear at some stage, so the upgrade to Joomla 4 seems an appropriate opportunity to replace all your component's calls to the global JSomething classes to the namespaced equivalents. This involves adding the appropriate <tt>use</tt> statements, and all this has been done in the tutorial code. A useful mapping between the two can be found [https://github.com/nikosdion/joomlatypehints/blob/main/JoomlaObsoleteClasses.md here], where the new qualified classname can be copied and pasted into a <tt>use</tt> statement in your PHP file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
With reference to the [https://api.joomla.org/ Joomla API Documentation] there are 2 Joomla library namespaces:
* Joomla CMS classes – have namespaces <tt>Joomla\CMS\Something</tt> – are found under <tt>libraries/src/Something</tt>
* Joomla Framework classes – have namespaces <tt>Joomla\Something</tt> – are found under <tt>libraries/vendor/joomla/something/src</tt>
So a big advantage of namespacing is that you can immediately determine from the fully qualified class name in a PHP <tt>use</tt> statement where the source for that class exists in the <tt>libraries</tt> directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
On the other hand class names which aren't fully qualified don't have to be unique, eg <tt>MVCFactory</tt>
* occurs as <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in <tt>libraries/src/Extension/Service/Provider/MVCFactory.php</tt>
* occurs as <tt>Joomla\CMS\MVC\Factory\MVCFactory</tt> in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>
so sometimes you have to be careful to examine the <tt>use</tt> statement to identify the right class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly our FormModel class in <tt>site/src/Model/FormModel.php</tt> can have the same FormModel classname as the Joomla FormModel in <tt>libraries/src/MVC/Model/FormModel.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The API documentation gives the methods available in each of the [https://api.joomla.org/cms-4/namespaces/joomla.html Joomla CMS] and [https://api.joomla.org/framework-2/namespaces/joomla.html Framework] classes, but just be aware that a Joomla CMS class may extend a Framework class, and in this case some methods may not be visible under the Joomla CMS documentation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For example, <tt>$app->setHeader()</tt> which is used to set the HTTP response code is not listed under the [https://api.joomla.org/cms-4/classes/Joomla-CMS-Application-CMSApplication.html CMS Application class API], but is available as a method because it inherits from the Framework class [https://api.joomla.org/framework-2/classes/Joomla-Application-AbstractWebApplication.html AbstractWebApplication].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Vendor Namespaces===
These are also in <tt>libraries/vendor</tt>, eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Psr\Container\ContainerInterface;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
refers to <tt>libraries/vendor/psr/Container/src/ContainerInterface.php</tt>. However there are few of these in the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other File Rearrangements===
With all of the namespaced classes moving under the src directories, the <tt>tmpl</tt> layout files and <tt>form</tt> xml files have been moved out into their own directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Extension and Dispatcher classes ==
===Extension===
In Joomla 3 the point where the Joomla core handed over to your component code was when it ran your <tt>helloworld.php</tt> code; if it was the frontend it ran your site <tt>helloworld.php</tt> code, or if was the backend it ran your admin <tt>helloworld.php</tt> code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the entry point into your component code is your Extension class, both for site and admin, found in <tt>admin/src/Extension/HelloworldComponent.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When the Joomla core application wants to start executing the component code it creates an instance of <tt>HelloworldComponent</tt>, just to get a handle on the component code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly (as described below) other Joomla classes such as Router or Categories need to call certain Helloworld methods (eg custom router functions). In Joomla 3 these methods were written in certain Helper files etc. In Joomla 4 the principle is that the component creates an instance of the <tt>HelloworldComponent</tt> Extension class, and calls the required methods on that instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This Extension class isn't anything like a big container class for the component, it's more like a glue class, providing a way in to the Helloworld component, enabling the Joomla core and other components call the methods which they want to call.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla core wants to execute the component code, the key method it is looking for in your <tt>Extension</tt> instance is <tt>getDispatcher</tt>, and it expects to get back a <tt>Dispatcher</tt> instance. The <tt>HelloworldComponent</tt> extends <tt>MVCComponent</tt>, which in turn extends <tt>Component</tt>, and it is this class which defines <tt>getDispatcher</tt> for us.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Dispatcher===
When Joomla wants to run the Hello World component, it gets the <tt>Dispatcher</tt> instance as described above and then calls the <tt>dispatch</tt> method on it. It is this <tt>dispatch</tt> function which replaces the functionality in the admin and site <tt>helloworld.php</tt> files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's look at the main lines of code in our Joomla 3 admin <tt>helloworld.php</tt> file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="site/views/form/view.html.php">
<syntaxhighlight lang="php">
if (!JFactory::getUser()->authorise('core.manage', 'com_helloworld'))
{
throw new Exception(JText::_('JERROR_ALERTNOAUTHOR'));
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Get an instance of the controller
$controller = JControllerLegacy::getInstance('HelloWorld');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Execute the Request task method
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Redirect if set by the controller
$controller->redirect();
</syntaxhighlight>
</span>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code
* performs some permissions checks
* instantiates the appropriate Helloworld controller
* executes the appropriate method in that controller
* implements any redirect set by the controller
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Model-View-Controller]] for further details of how this works in Joomla 3. The second and third steps used the <tt>task</tt> parameter within the URL query to determine the correct controller class to instantiate and method to call. If no <tt>task</tt> parameter was present then it instantiated the controller in <tt>controller.php</tt> and called the <tt>display</tt> method. Otherwise it instantiated one of the controllers in the <tt>controllers</tt> subfolder (eg <tt>controllers/helloworld.php</tt>) and called the appropriate method on it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>ComponentDispatcher::dispatch</tt> method (in <tt>libraries/src/Dispatcher/ComponentDispatcher.php</tt>) now provides this functionality, but in a nicer way. After checking the permissions it uses the <tt>task</tt> by considering its parts as <tt><controller type>.<method></tt> (taking 'display' as default if either part is missing). It will then pass control to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* an instance of the class <Controller type>Controller
* calling the function <method>
* using the admin or site controller, as appropriate
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In this way the naming of the controllers is consistent - we have DisplayController, HelloworldController and HelloworldsController, all in the same folder.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Dispatcher class can thus be considered as providing some 'routing - execution' functionality, enabling us to find the right controller and function within that controller, and it is cleaner to have this in a separate class rather than in the <tt>JControllerLegacy</tt> class as it was in Joomla 3.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Since the Hello World tutorial uses the standard Joomla pattern for selecting the class and method based on the <tt>task</tt> and has the same permissions checks, we can use the <tt>dispatch</tt> code as it stands in <tt>ComponentDispatcher</tt>, and don't need to define a special class of our own.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Factory classes ==
In Joomla 3 many classes had static <tt>getInstance</tt> methods which returned an instance of that class, configured with the parameters passed to <tt>getInstance</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the <tt>getInstance</tt> methods have been deprecated in favour of using Factory classes. The preferred mechanism is now to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* get an instance of the appropriate Factory class (how we do that is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below)
* call the <tt>createSomething()</tt> method of the Factory class with relevant parameter values to generate an instance of the Something class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===MVC Factory===
In this section the <tt>MVCFactory</tt> class refers to the one in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory class will instantiate Controller, View, Model and Table instances on our behalf, and it does this by generating the classname of the class and then calling <tt>new</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The way it works is as follows:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Each component gets an individual MVCFactory instance which is constructed passing the component's namespace as a parameter (so in our case 'Robbie\Component\Helloworld'). (How this MVCFactory instance is created is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below).
# The MVCFactory createController / createView / createModel / createTable function is then called, passing the name of the Controller / Model / View / Table and the prefix (which specifies whether the administrator or site class is required).
# The create function forms the classname from this data and calls <tt>new</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory create functions just form the classname from the parameters they're passed. The intelligence for working out what name and prefix should be used to form the appropriate classes for an incoming HTTP request is
* in the dispatcher code for defining the controller to use
* in the controller for the view and model
* in the model for the table
and, for example, the names of the classes created for a request with URL query <tt>?option=com_helloworld&view=viewname</tt> and no <tt>task</tt> parameter will be
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<namespace>\Controller\DisplayController
<namespace>\View\Viewname\HtmlView
<namespace>\Model\ViewnameModel
<namespace>\Table\ViewnameTable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you need an alternative name then you can override the appropriate getView, getModel or getTable function – as for example was done in the [[J3.x:Developing an MVC Component/Adding Custom Fields#Front-end_Form|Adding Custom Fields step, frontend Form section]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So from the outside this is pretty much the same as in Joomla 3. However, note that the <tt>$prefix</tt> parameter in calls to <tt>getModel</tt> etc is subtly different
* in Joomla 3 this referred to a prefix to be applied to the classname – in the tutorial code we used 'HelloWorldTable' as the prefix part of the 'HelloWorldTableHelloWorld' classname.
* in Joomla 4 this refers to a prefix higher up the classname path, and should be set to either 'Site' or 'Administrator' (the capital letter at the start is optional), depending on whether you want the class under 'Robbie\Component\Helloworld\Site' or 'Robbie\Component\Helloworld\Administrator'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVC Factory class is now the Joomla recommended way to create the controller, view, model and table classes, by using the eg <tt>getModel()</tt> method, and the use of <tt>getInstance()</tt> for these classes is now deprecated. However, the use of these functions is restricted:
* in the controller class you can call <tt>$this->getView($viewname, $viewtype, $prefix, $config)</tt> to create a view and <tt>$this->getModel($modelname, $prefix, $config)</tt> to create a model.
* in the view class you can call <tt>$this->getModel($modelname)</tt>, but only for models which the controller has previously defined using <tt>$view->setModel($modelname, $default)</tt>. It doesn't create a new model instance.
* in the model class you can call <tt>$this->getTable($tableclass, $prefix, $options)</tt> to create a table instance. Controllers and views can access the table classes in this way, by going via a model.
These restrictions do have an impact on moving away from using <tt>getInstance()</tt>, and indeed in Joomla 4.2.6 you will still find several <tt>getInstance()</tt> calls within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Factory Classes===
Several other Factory classes have been introduced in Joomla 4, enabling you to get instances of core classes such as Form, User, CacheController, etc, usually by calling a createSomething function on the Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Associated with the Factory class is a FactoryInterface, a PHP Interface which specifies the key functions which the Factory class must implement. For example, with <tt>libraries/src/Categories</tt> we have:
* CategoryFactoryInterface – which specifies the <tt>createCategory</tt> function
* CategoryFactory implements CategoryFactoryInterface – which provides the <tt>createCategory</tt> function.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Dependency Injection ==
===Overview===
The DI container is one of the significant new additions to Joomla 4. It's basically a repository of key-value pairs where:
* the key is a string which is the name of a class or interface
* the value is an instance of the relevant class, or a function that returns an instance of that class.
You put things into the container using <tt>set()</tt> passing:
* the class name or interface name
* a function which returns an instance of the class (or an instance of the class)
* a boolean defining whether the class instance may be shared or not
* a boolean defining whether this entry into the DI container is protected or not (an error will be raised if you try to overwrite a protected entry by calling <tt>set()</tt> again using the same key).
The function <tt>share()</tt> is basically the same as <tt>set()</tt> with the <tt>shared</tt> boolean set to true.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You get things out of the container by calling <tt>get()</tt> passing the key of the resource you want. The container will
* find the key in the container
* if the value isn't already a class instance, then it will run the associated function to generate an instance of the class
* if the resource is shared, it will store the class instance, so that on subsequent invocations of <tt>get()</tt> it can just return the instance
* return the class instance to you
You can also define aliases for each key in the container, which means that you call <tt>get()</tt> passing either the key or an alias of the key.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The DI container is initialised in <tt>library/src/Factory.php createContainer()</tt> which results in the <tt>register()</tt> function being called in each of the class files in <tt>libraries/src/Service/Provider</tt>. By looking through those files you can see what gets put into the DI container upon initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===JConfig Example===
Let's consider the example of JConfig which holds the system global configuration. If you look inside <tt>libraries/src/Service/Provider/Config.php</tt> then you'll see the <tt>register()</tt> function and that it stores in the DI container a resource with:
* key = 'JConfig'
* value = an anonymous function - which loads what's in <tt>configuration.php</tt> into a <tt>Registry</tt> object, and returns it
* shared flag = true (because the <tt>share()</tt> function is used)
* protected flag = true
Then when you do
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$config = $container->get('JConfig');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will run the anonymous function and return the Registry object to you. As the 'shared' boolean is set it will also store a copy of the class instance locally in the container to be returned on subsequent calls of <tt>get('JConfig')</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Justification===
What's the point of all this?
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The advantage of dependency injection is that it allows classes to be easily mocked for testing. The file <tt>libraries/src/Service/Provider/Config.php</tt> can be replaced to return to a DI container <tt>get()</tt> call a mock class instead of the usual <tt>JConfig</tt>. This is in comparison to Joomla 3 where <tt>Factory::getConfig()</tt> code directly reads the <tt>configuration.php</tt> into a Registry structure and returns it – which makes it harder to mock.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The [https://api.joomla.org/cms-4/classes/Joomla-CMS-Factory.html Factory API] has several functions which are marked as deprecated with advice to get the object from the DI container instead.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Several of the other Factory classes (eg Form, Language, Menu, User) are in the DI container – so that we can get an instance of them via eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Factory::getContainer()->get('Joomla\CMS\Toolbar\ToolbarFactoryInterface')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to get a Toolbar instance. However, this only works for singleton classes which aren't specific to the needs of a particular extension. We'll see shortly how to make it work for class instances which need to be specific to a component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As indicated above, Joomla is moving away from using the class static <tt>getInstance()</tt> functions. We can see now that this is not only because it's more pure from an object oriented perspective. But also creating class instances from the DI container, or from Factory objects which are obtained from the DI container, builds in the dependency injection which allows classes to be more easily mocked, and hence more easily tested.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==services/provider.php==
We're now finally in a good position to understand what's happening in our services/provider.php file, and we'll explore this by walking through what happens whenever this line in libraries/src/Component/ComponentHelper.php <tt>renderComponent</tt> is run:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is run whenever Joomla has worked out which component is to be run on the requested web page, and it wants to run that component to capture its output.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 1 Create Child DI Container===
Joomla first creates another DI container (initially empty) just for this component, and links it to the main DI container via a parent field in the child DI container structure.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Now whenever <tt>set()</tt> is called on this DI container the key-value pair is inserted into the child container. Whenever <tt>get()</tt> is called on it, the resource is obtained from the child container, but if it's not found there then the parent container is searched also.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 2 Run register() in provider.php===
Next we encounter these lines (in <tt>libraries/src/Extension/ExtensionManagerTrait.php</tt>), where <tt>$path</tt> contains the path of our helloworld admin/services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$provider = require_once $path;
// Check if the extension supports the service provider interface
if ($provider instanceof ServiceProviderInterface) {
$provider->register($container);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here we see 3 things:
# our provider.php should return some object (so that <tt>$provider</tt> gets set to something)
# what is returned should implement ServiceProviderInterface (you can see in <tt>libraries/vendor/joomla/di/src/ServiceProviderInterface.php</tt> what is expected)
# the code then runs the <tt>register</tt> function on that object, passing as a parameter the child DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider a minimal version of our provider.php file. This would actually support steps in the Joomla 3 tutorial up to and including the [[J3.x:Developing an MVC Component/Adding AJAX|Adding Ajax step]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {

public function register(Container $container): void
{
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
}
};
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As you can see from the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
this file does indeed return something – it returns an instance of an anonymous class, one that implements <tt>ServiceProviderInterface</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it's not sufficient to just provide the <tt>register</tt> function in the class, we also need to explicity state that the class implements <tt>ServiceProviderInterface</tt>. This now happens in several places in Joomla, so if you're debugging your component and wondering why a function you expect to be called isn't being called, then check to make sure that you don't have to explicitly add the appropriate <tt>implements <Interface></tt> clause to your class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Next we look at the 3 lines in the <tt>register</tt> function
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3a Registering our MVC Factory===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here our <tt>MVCFactory</tt> refers to <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in libraries/src/Extension/Service/Provider/MVCFactory.php, and you should have a look at this file. This is a file similar to our provider.php file, but it's a named class, and it doesn't return anything. When we do:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
new MVCFactory('\\Robbie\\Component\\Helloworld')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it creates an instance of this class, and in the constructor it stores locally in <tt>$this->namespace</tt> our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>registerServiceProvider</tt> function then calls the <tt>register</tt> function of this instance, which runs (in its minimalist form):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
MVCFactoryInterface::class,
function (Container $container) {
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
return $factory;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So what gets entered into our child DI container is a key-value pair with:
* key = MVCFactoryInterface::class (this is just a shorthand form to obtain a string of the fully qualified name – ie 'Joomla\CMS\MVC\Factory\MVCFactoryInterface')
* value = a function which returns an instance of <tt>\Joomla\CMS\MVC\Factory\MVCFactory</tt>.
This is our MVCFactory class which generates our Controllers, Views, Models and Tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Notice that we're passing our namespace as a parameter <tt>$this->namespace</tt>. Because this function is a closure, this variable will still be available when we run this function later, and when the MVCFactory class is instantiated the namespace will be passed into the constructor, stored locally, and then subsequently used to form the fully qualified names of our Controllers, View, etc. So this is how we get instantiated the MVCFactory class which is specific to our component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3b Registering the Dispatcher Factory===
Careful: ComponentDispatcherFactory refers to two different classes here!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This ComponentDispatcherFactory is Joomla\CMS\Extension\Service\Provider\ComponentDispatcherFactory in libraries/src/Extension/Service/Provider/ComponentDispatcherFactory.php. Similar to the above, the ComponentDispatcherFactory service provider class stores locally our namespace, and then when <tt>register</tt> is called it executes:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentDispatcherFactoryInterface::class,
function (Container $container) {
return new \Joomla\CMS\Dispatcher\ComponentDispatcherFactory($this->namespace,$container->get(MVCFactoryInterface::class));
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so a second entry is added to the child DI container with:
* key = ComponentDispatcherFactoryInterface::class
* value = a function which returns an instance of the ComponentDispatcherFactory (the other ComponentDispatcherFactory class!), where the class constructor will be passed the namespace ('\\Robbie\\Component\\Helloworld') and an MVCFactory instance, retrieved from the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that the code
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->get(MVCFactoryInterface::class)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
will get from the container an entry with key = 'Joomla\CMS\MVC\Factory\MVCFactoryInterface' – which is what we entered into the container in step 3a – and will run the function associated with this key, and then return the object which this function returns. This returned object will be an instance of '\Joomla\CMS\MVC\Factory\MVCFactory', constructed using our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3c Including the Extension===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will put into the child DI container a key-value pair with
* key = ComponentInterface::class
* value = the function which will create an instance of our <tt>HelloworldComponent</tt> (ie our Extension class), and pass into the constructor an instance of the ComponentDispatcherFactory class, retrieving what was entered into the child DI container in Step 3b.
It will call <tt>$container->get(MVCFactoryInterface::class)</tt>, getting an MVC Factory instance from what was entered into the DI container in Step 3a.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It will then associate our component with this MVC Factory instance via the <tt>setMVCFactory</tt> call. Significantly this will then allow our component to access this instance later, via a call to <tt>getMVCFactory</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3 Summary===
We have now got 3 entries in our child DI container, keyed by
* key = MVCFactoryInterface::class, value is a function returning an MVCFactory instance
* key = ComponentDispatcherFactoryInterface::class, value is a function returning a ComponentDispatcherFactory instance
* key = ComponentInterface::class, value is a function returning our HelloworldComponent, an instance of our Extension class.
The important aspect is that these entries are all aware of our namespace '\Robbie\Component\Helloworld' and will return instances of these classes which are specific to our Helloworld component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 4 Retrieving from the DI Container===
Joomla will then execute the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $container->get($type);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
where <tt>$type</tt> contains 'Joomla\CMS\Extension\ComponentInterface'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This starts the process of retrieving from the DI container the 3 entries which we put in, and will run our code in services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We end up with a HelloworldComponent instance, which has:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. a ComponentDispatcherFactory instance passed into the constructor, and which is saved locally by the constructor code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function __construct(ComponentDispatcherFactoryInterface $dispatcherFactory)
{
$this->dispatcherFactory = $dispatcherFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This code is in libraries/src/Extension/Component.php, in the class which our HelloworldComponent extends, via the class MVCComponent).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. an MVC Factory instance, stored by the HelloworldComponent <tt>setMVCFactory</tt> call
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 5 Call boot() on our Component===
Joomla calls:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
if ($extension instanceof BootableExtensionInterface) {
$extension->boot($container);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will call <tt>boot</tt> within our HelloworldComponent, and allows us to perform some initialisation within our component. We'll return to this later, in the section on [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#HTML_Snippets|HTML snippets]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note again that Joomla checks that our HelloworldComponent class implements BootableExtensionInterface before calling <tt>boot</tt>. It's not sufficient to just provide the <tt>boot</tt> function, we have to explicitly declare that our HelloworldComponent implements the interface.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 6 Get the Dispatcher===
Returning to our key line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
we have now accomplished the first part <tt>bootComponent($option)</tt>, and this has returned our HelloworldComponent instance. Now we call <tt>getDispatcher($app)</tt> on this instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This code is also in libraries/src/Extension/Component.php, in the Component class which our HelloworldComponent extends:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function getDispatcher(CMSApplicationInterface $application): DispatcherInterface
{
return $this->dispatcherFactory->createDispatcher($application);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We call <tt>createDispatcher</tt> on our ComponentDispatcherFactory class instance which we saved in Step 4. This code is in libraries/src/Dispatcher/ComponentDispatcherFactory.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createDispatcher(CMSApplicationInterface $application, Input $input = null): DispatcherInterface
{
$name = ucfirst($application->getName());

$className = '\\' . trim($this->namespace, '\\') . '\\' . $name . '\\Dispatcher\\Dispatcher';

if (!class_exists($className)) {
if ($application->isClient('api')) {
$className = ApiDispatcher::class;
} else {
$className = ComponentDispatcher::class;
}
}

return new $className($application, $input ?: $application->input, $this->mvcFactory);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code checks if we have our own Dispatcher class (our Helloworld tutorial doesn't, but <tt>com_users</tt> for example has its own). So it creates a <tt>ComponentDispatcher</tt> instance, and passes into its constructor the MVC Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that this ComponentDispatcherFactory instance is what was instantiated when it was retrieved from our child DI Container (from being inserted in step 3b), and hence it already knows about our namespace, and has a pointer to our MVCFactory class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 7 call dispatch()===
This is the final aspect to our line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We're now back to what was described in the Dispatcher section above, except that now we can see that this Dispatcher instance has a pointer to our MVC Factory instance (which knows about our namespace prefix), so when the Dispatcher code wants to create a Controller it can use that MVC Factory instance to instantiate it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's been a long and tortuous journey to get here, but the significant thing is that all of our key class instances have been obtained via the DI Container. If we want to mock out any of those classes for testing then all we need to do is replace the relevant services/provider file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Javascript and the Web Asset Manager ==
The web asset manager has been introduced in Joomla 4 and is well documented [[J4.x:Web_Assets|here]]. It provides a much-improved means of managing JS and CSS resources, and a framework for handling their dependencies.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Component Javascript and CSS files should now be stored in the <tt>media</tt> folder, and the Web Asset Manager used to register them and output them on specific web pages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following assets have been registered in the tutorial <tt>joomla.asset.json</tt>, and you should have a look at that file now.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.validate-greeting===
This is the code for client validation of the helloworld greeting field using a regex, and it is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it is dependent upon jQuery and the Joomla <tt>form.validator</tt> script, so those both get included as dependencies.
If we didn't have specific validation on our form then we would need to include explicitly the <tt>form.validator</tt> script in order for the basic Joomla field validation to be included, eg in the tmpl file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->document->getWebAssetManager()->useScript('form.validate');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that this requires us to have a <tt>class="form-validate"</tt> on the </tt><form></tt> html element.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.fix-permissions-ajax-call===
This is the code which copies the value from the greeting field into the title field, so that the Ajax calls setting the permissions work correctly. The js code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.enable-tooltips===
This is the code which enables bootstrap tooltips to operate, including allowing them to include html code. It's used to display the image as a tooltip within the admin <tt>helloworlds</tt> view.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.openstreetmap===
This is defined as a preset, comprising the helloworld js and css code for the map display, as well as the dependency named 'com_helloworld.openlayers' relating to the openlayers CSS and js code. The code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.admin-helloworlds-modal===
This is the js code for selecting an individual helloworld record within a modal, and passing its details to the form in the main window. Its code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===submitbutton.js===
In the Joomla 3 code we introduced in [[Special:MyLanguage/J3.2:Developing_an_MVC_Component/Adding_verifications|Adding Verifications]] a js file which controlled when the form was submitted. It differentiated between buttons such as <tt>Save</tt> (which submitted the form) and <tt>Cancel</tt> (which didn't).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 there is a more sophisticated version of <tt>Joomla.submitbutton</tt> (found in media/system/js/core.js) which uses the CSS classes which the Toolbar functionality sets on the buttons to determine whether the form should be submitted or not. And you can override whether the validation is performed by adding a third parameter to the <tt>submitbutton</tt> js call. For example, to avoid validation being performed when a button is clicked you can set on the button element:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
onclick="Joomla.submitbutton('controller.method', '', false)"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As this is sufficient for what we need in the tutorial, the custom <tt>submitbutton.js</tt> has been removed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Interaction with other components ==
The way that Joomla interacts with components has changed in Joomla 4. In general the Joomla functionality will boot the component using something like:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $app->bootComponent($option);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and in our case this will return an instance of the <tt>HelloworldComponent</tt> class. It will then try to call certain methods on our extension object, as described below.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_categories===
In the backend the helloworld functionality can display to the administrator
* the view of the helloworld messages
* the view of the helloworld categories
The categories view is generated by <tt>com_categories</tt>, and in Joomla 4 these component categories views display the number of component records there are for each of the possible published status values. To do this the categories component executes the following code (in administrator/components/com_categories/src/Model/CategoriesModel.php):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof CategoryServiceInterface) {
$component->countItems($items, $section);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So our HelloworldComponent must:
* declare that it implements <tt>CategoryServiceInterface</tt>
* provide an implementation of <tt>countItems</tt>
We provide <tt>countItems</tt> by using a trait in libraries/src/Categories/CategoryServiceTrait.php, which (with the assistance of a helper function) does the query on our behalf. We just need to tell it:
* the name of our table – in the callback <tt>getTableNameForSection</tt>
* the database field in which we hold the published status – in <tt>getStateColumnForSection</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_associations===
Remember that <tt>com_associations</tt> is the component which is run whenever you click on Multilingual Associations in the admin backend.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Under Joomla 3 we provided an associations helper file as described in [[J3.x:Multilingual Associations/Developers|Multilingual Associations/Developers]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the helper file remains basically the same, but <tt>com_associations</tt> primarily tries to find the helper file via the extension class; here's the code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($extensionName);
if ($component instanceof AssociationServiceInterface) {
return $component->getAssociationsExtension();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's expecting that:
* the extension (HelloworldComponent in our case) implements <tt>AssociationServiceInterface</tt>
* its <tt>getAssociationsExtension</tt> method returns the helper class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The easiest thing would be just to code <tt>getAssociationsMethod</tt> and get it to return <tt>new AssociationsHelper</tt>. However, we follow the Joomla 4 principle of putting key classes into the Dependency Injection container, and retrieving them later, by having the following code in our services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(AssociationExtensionInterface::class, new AssociationsHelper());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The above line puts a key-value pair into our child DI container
* key = 'Joomla\CMS\Association\AssociationExtensionInterface'
* value is an instance of our <tt>AssociationsHelper</tt> class.
We then retrieve it later and use the setter:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setAssociationExtension($container->get(AssociationExtensionInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so that whenever
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getAssociationExtension()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
is called it returns the <tt>AssociationsHelper</tt> class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_fields===
<tt>com_fields</tt> is the component which is run when an administrator clicks on the Fields or Field Groups menuitem within the backend, and this functionality was included in the [[J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Adding Custom Fields]] tutorial step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>com_fields</tt> component stores the custom fields and field groups for all components in the database tables <tt>#__fields</tt> and <tt>#__fields_groups</tt>, and these tables are partitioned into "sections", one section per component. For our helloworld component the section is named "helloworld".
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within the section we have 2 "contexts" – one for the helloworld messages (called "com_helloworld.helloworld") and one for the helloworld categories (called "com_helloworld.categories"). This enables us to define custom fields for both our helloworld records and helloworld category records.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When <tt>com_fields</tt> runs it checks both the section and contexts at various times. For example, when an admin selects Helloworld / Fields on the backend then <tt>com_fields</tt> checks the section which was defined in the menuitem in the manifest file (see [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Sidebar|below]]). Here's the code in administrator/components/com_fields/src/Helpers/FieldsHelper <tt>extract</tt> function:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
$newSection = $component->validateSection($parts[1], $item);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And when <tt>com_fields</tt> wants to display the little dropdown menu of contexts (to allow the administrator to set custom fields on either helloworld items or categories) it calls (in administrator/components/com_fields/src/Fields/FieldcontextsField.php <tt>getOptions()</tt>):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
return $component->getContexts();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So it's clear that our component extension class must :
* implement <tt>FieldsServiceInterface</tt>
* provide the <tt>validateSection</tt> and <tt>getContexts</tt> methods
So in upgrading to Joomla 4 we've just moved those two methods from the helper file to the extension class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Router===
The Joomla router will access our custom router code:
* whenever it wants to parse an SEF route which it has identified as belonging to <tt>com_helloworld</tt>
* whenever it wants to build an SEF route from a call to <tt>Route::_()</tt> where the option = "com_helloworld".
To find our custom router it will:
* boot the <tt>com_helloworld</tt> extension
* check that the extension implements <tt>RouterServiceInterface</tt>
* call <tt>createRouter</tt> on our extension instance
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In our services/provider.php file we have (careful again - 2 different RouterFactory classes!):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new RouterFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which from libraries/src/Extension/Service/Provider/RouterFactory.php puts into our child DI container an entry with:
* key = "Joomla\CMS\Component\Router\RouterFactoryInterface"
* value is a <tt>\Joomla\CMS\Component\Router\RouterFactory</tt> instance, constructed with our namespace
We then retrieve this in the line in our services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setRouterFactory($container->get(RouterFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And then within our extension class we have
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use RouterServiceTrait;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which includes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function setRouterFactory(RouterFactoryInterface $routerFactory)
{
$this->routerFactory = $routerFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which stores the <tt>routerFactory</tt> locally and
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return $this->routerFactory->createRouter($application, $menu);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which provides our extension's <tt>createRouter</tt> call that the Joomla Router expects.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>routerFactory::createRouter</tt> method is in libraries/src/Component/Router/RouterFactory.php. It looks for a class in our site namespace </tt>Robbie\Component\Helloworld\Site\Service\Router</tt> which is in our site/src/Service/Router.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
At this stage we have a choice, we can either:
* provide a traditional custom router, with the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions, or
* use the more modern <tt>RouterView</tt> mechanism.
By default in the upgraded tutorial code the Router View option has been coded in the Router.php file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====RouterView====
In the <tt>RouterView</tt> case the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions are in the <tt>RouterView</tt> class which we extend, and we provide
* a constructor with router view configuration
* methods <tt>getHelloworldId</tt> and <tt>getCategoryId</tt> which are used to obtain from the SEF segment the <tt>id=</tt> and <tt>catid=</tt> parts of the internal URL
* methods <tt>getHelloworldSegment</tt> and <tt>getCategorySegment</tt> which are used to generate segments for the SEF URLs based on the <tt>id=</tt> and <tt>catid=</tt> parts within the <tt>Route::_()</tt> parameter.
Unfortunately there doesn't seem to be a good guide to configuring the RouterView class. There is some documentation available [https://www.dionysopoulos.me/book/com-router-routerview.html here].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the helloworld tutorial we have 3 views
* a view which displays a single helloworld record
* a view which displays a single helloworld category, and the helloworld records associated with it
* a view which displays the frontend form
So we need 3 Router Views associated with these.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'form' view doesn't have an associated id or catid so it's just a fixed URL, and the router just has to convert between the alias of the form menuitem and the Itemid / view parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'category' view has an associated id (of the category record), and an SEF URL will use the category path down the Categories Nested Set table structure, hence <tt>setNestable()</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'helloworld' view has an associated id (of the helloworld record), and in an SEF URL in the category view the helloworld record alias is added to the category path (hence <tt>setParent()</tt>). But although the helloworld records use a Nested Table structure in the database, the URLs just include the alias of the single record, and so <tt>setNestable()</tt> is not used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There doesn't seem to be a way to configure an additional SEF URL scheme which just displays a helloworld segment, without a category segment.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====Traditional Router====
To use the traditional router in the tutorial code you should uncomment the function in the extension class:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return new TraditionalRouter($application, $menu, $this->categoryFactory, $this->getDatabase());
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will cause the code in site/src/Service/TraditionalRouter.php to be used. However, changes in the Joomla 4 router mean that the interaction between it and the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> methods have changed. This requires significant changes to the <tt>preprocess</tt> and <tt>build</tt> methods, but only a minor change to <tt>parse</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. Previously Joomla injected into the <tt>$query</tt> parameters the <tt>Itemid</tt> of the active menuitem (ie the id of the menuitem the user is currently on). This meant that we had to change the <tt>Itemid</tt> for links generated by the Language Switcher module (which generates the flags for switching between languages), and these links being associated with a different language would obviously use a different <tt>Itemid</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 you get an <tt>Itemid</tt> in the <tt>$query</tt> parameters only if you specified an <tt>Itemid</tt> in the <tt>Route::_()</tt> call. For others you have to work out which menuitem to use yourself, by using the Joomla menu/menuitems API to find details of the configured menuitems, and work out which to use based on the other <tt>$query</tt> parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You do this in the <tt>preprocess</tt> method, and then the <tt>Itemid</tt> you set will be passed in the <tt>$query</tt> parameters to the <tt>build</tt> method.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. In some instances the <tt>Route::_()</tt> URL you're generating matches exactly one of the configured menuitems on the site. In this case the <tt>$query</tt> parameters will match those in the menuitem <tt>"query"</tt> array, and you have to remove explicitly remove the 'view', 'id' and 'catid' parameters so that they don't appear as URL query parameters after the normal SEF URL of the menuitem.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
3. The custom router will be used to build the URLs for the helloworld menuitems shown in menus on the page. For these the <tt>$query</tt> parameters will have the view / id / catid associated with those menuitems. Note that even if you remove these in your <tt>preprocess</tt> method, Joomla will inject them again into the <tt>$query</tt> array when it's passed to your <tt>build</tt> method, so you'll have to remove them again there!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
4. In the <tt>parse</tt> method you now have to unset the <tt>$segments</tt>, or else Joomla will return an HTTP 404 (page not found). Otherwise <tt>parse</tt> works as before.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
5. I've implemented <tt>build</tt> only for when Multilanguage is enabled on the site. If it's not enabled an empty <tt>$segments</tt> array is just returned, without doing unset on any of the <tt>$query</tt> parameters, so these will appear as URL parameters after the SEF URL. Also it's not coded properly to deal with items which have language set to <tt>*</tt>. These include helloworld records, categories or menuitems (eg the helloworld form).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that the <tt>categoryFactory</tt> is also now passed to the router. This is so that it can be used instead of <tt>Categories::getInstance()</tt> to get access to the Categories API calls.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_tags===
Whenever we setup a Tags Menu Item Type which displays items having a given tag or tags, then <tt>com_tags</tt> displays those items as links, and uses route helper functions to generate the URL parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The route helpers <tt>com_tags</tt> expects to find loaded into the data of the <tt>#__content_types</tt> table, in the router field, and these have been set to:
* For links to helloworld items: 'HelloworldHelperRoute::getHelloworldRoute'
* For links to helloworld categories: 'HelloworldHelperRoute::getCategoryRoute'
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, <tt>com_tags</tt> doesn't boot the helloworld extension to get access to these, but rather seeks to find them in site/helpers/route.php, so that's where they continue to be.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(We also had a <tt>getCategoryRoute</tt> which was used by <tt>com_categories</tt> in administrator/components/com_categories/src/Helper/CategoryAssociationHelper. When a category was displayed on the frontend then the Language Switcher module (now Language Filter) used this function to generate the links to the Associated Categories. Our <tt>getCategoryRoute</tt> previously was necessary to insert the <tt>lang=<language tag></tt> parameter into the link URL, but since [https://github.com/joomla/joomla-cms/pull/39358 this change] the calling function inserts the <tt>lang</tt> parameter itself, so our <tt>getCategoryRoute</tt> function for this purposes is superfluous.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Deprecated APIs ==
With Joomla 4 there are a number of methods which are deprecated, with a view to removing them in Joomla 5.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Factory Methods===
Many of the <tt>Factory</tt> methods for getting singleton classes have been deprecated in favour of getting these classes via the DI container, and it appears that only class instances which should be obtained via Factory methods are:
* the Application – <tt>Factory::getApplication()</tt>
* the DI container – <tt>Factory::getContainer()</tt>
Here is a list of what has been changed in the tutorial code. Note that with some calls there are variants available, through the aliases defined in the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDbo'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\Database\DatabaseInterface;
...
$db = Factory::getContainer()->get(DatabaseInterface::class);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, in many classes the database instance is more easily (and efficiently) returned via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$db = $this->getDatabase();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is available in Model classes, custom field definitions, etc.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getUser();'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get the current user use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = Factory::getApplication()->getIdentity()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get a different user (whose id you know):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\User\UserFactoryInterface;
...
$user = Factory::getContainer()->get(UserFactoryInterface::class)->loadUserById($userid);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within models which extend Joomla\CMS\MVC\Model\BaseDatabaseModel and views which extend Joomla\CMS\MVC\View\HtmlView you can also use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = $this->getCurrentUser()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDocument()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication()->getDocument()</tt>, or within a View you can use <tt>$this->document</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getConfig()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Two options have been used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->getConfig()</tt> – returns a Registry object containing all the configuration values
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->get('access')</tt> – returns the value of the 'access' configuration parameter
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getLanguage()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication->getLanguage()</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JFactory::getCache('com_example', <type>)'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Cache\CacheControllerFactoryInterface;
...
Factory::getContainer()->get(CacheControllerFactoryInterface::class)->createCacheController(<type>)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated getInstance Methods===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general <tt>getInstance()</tt> calls have been deprecated in favour of obtaining the instance, either via a factory class or via the DI container. For example, within a controller you can use <tt>getModel()</tt> repeatedly to get different models (passing the relevant model names), which results in the MVCFactory class creating the Model classes.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there are currently some problems with replacing some getInstance calls. I expect that the Joomla team will resolve these issues over the course of the Joomla 4 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Categories::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is deprecated with a notice: "Use the ComponentInterface to get the categories". This means that we should get the category factory instance via the DI container. This is done in our services/provider.php by the lines:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Extension\Service\Provider\CategoryFactory;
...
$container->registerServiceProvider(new CategoryFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to put into our child DI container the closure which will create a Joomla\CMS\Categories\CategoryFactory instance, constructed with our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when our HelloworldComponent (Extension) instance is created:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We can then use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getCategoryFactory()->createCategory();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to create our Categories object, and in this way get access to the Categories APIs.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This createCategory method creates the instance by looking for the \\Site\\Service\\Category class within our namespace. The constructor in our class sets our extension ('com_helloworld') and table ('#__helloworld') and calls the parent Categories constructor with these options).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this means that the section of our code where we want to use the Categories APIs must have a pointer to a CategoryFactory instance. In the tutorial code for Joomla 3 there are 2 places where <tt>Categories::getInstance</tt> is used:
* in the custom router code, to handle building and parsing of the category parts of the SEF URL
* in the site category model, where the Categories APIs are used to obtain details of categories to display on the page.
For the custom router code, the CategoryFactory instance is passed as a parameter to the TraditionalRouter constructor so that it can be used there.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, the site category model is instantiated by the MVCFactory instance, and it doesn't make available a CategoryFactory instance. So in this category model the calls to <tt>Categories::getInstance()</tt> have been left, and you can still find a number of calls to <tt>Categories::getInstance</tt> within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Categories::getInstance()</tt> itself solves the problem of access to a CategoryFactory instance by rebooting our component again to get a pointer to our Extension instance, and thus to the category factory instance. However, this involves a lot of work, so <tt>getInstance</tt> caches locally the Categories instances and just returns one of them if it can.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Pushing the CategoryFactory to the model'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there is a way to get access to the CategoryFactory instance, by defining your own MVCFactory class, and pushing the instance down through it to the model. Here's how you can go about it:
* Define your own SuperMVCFactory class, which extends the Joomla Joomla\CMS\MVC\Factory\MVCFactory class, but which has a means of storing a CategoryFactory instance. Use the CategoryServiceTrait in libraries/src/Categories/CategoryServiceTrait.php
* Create your own version of the file libraries/src/Extension/Service/Provider/MVCFactory.php, which is the 'provider.php' like file for MVCFactory, but change it so that:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
becomes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new <namespace>\SuperMVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and include
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla creates a model such as CategoryModel it passes in its constructor the MVCFactory instance (so that the model can call createTable on it), so you can access it via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will return your SuperMVCFactory instance. So in this way within the model you can access the CategoryFactory, and use it to create the Categories instance via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()->getCategory() (from the CategoryServiceTrait)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you can get this working you can congratulate yourself on a good understanding of Joomla namespacing and dependency injection! A similar approach to address a similar problem is described [https://www.dionysopoulos.me/book/com-router-push-dependencies.html here]. If you get stuck you can always view the solution by viewing the github tutorial code selecting the branch [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial/tree/push-category-factory-to-mvc push-category-factory-to-mvc].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Table::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There are a couple of calls to <tt>Table::getInstance()</tt> within admin/src/Helper/AssociationsHelper.php in <tt>getItem()</tt>:
* <tt>Table::getInstance('Helloworld', 'Robbie\\Component\\Helloworld\\Administrator\\Table\\')</tt> to get an instance of our HelloworldTable class.
* <tt>Table::getInstance('Category')</tt> to get an instance of the Category table in libraries/src/Table/Category.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We could actually arrange for the AssociationsHelper class to get injected with the MVCFactory instance, so that the HelloworldTable class could be instantiated by it. However, we couldn't use the helloworld MVCFactory instance to create the Category table instance, as it's not in the helloworld namespace, and our MVCFactory instance creates table instances within our namespace only.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Toolbar::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The tutorial code uses <tt>Toolbar::getInstance()</tt> to get a Toolbar instance onto which it can attach the batch button in the helloworlds form. The Toolbar API documentation seems to suggest that we should replace
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Toolbar::getInstance('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
with
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this currently won't work. The problem is that all the other Joomla code uses <tt>getInstance('toolbar')</tt> to access the Toolbar class, including the code in administrator/modules/mod_toolbar/mod_toolbar.php which renders the toolbar. The <tt>getInstance</tt> method keeps track of the Toolbar instances in a local static variable <tt>$instances</tt>, and returns the same Toolbar instance on repeated invocations.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you use the second approach above you will get a Toolbar instance, but it won't be the same Toolbar instance as is stored in the <tt>$instances</tt> variable. It won't then be picked up by the Toolbar module, and so won't be rendered on the form.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Error Handling===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead of
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
JError::raiseError(500, implode('<br />', $errors));
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
you should throw an exception, using or extending one of the standard [https://www.php.net/manual/en/spl.exceptions.php PHP exceptions], eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
throw new \Exception(implode("\n", $errors), 500);
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===jimport===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
jimport is no longer necessary in order to get access to Path or File classes. All of the Joomla classes are found by the autoloader.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Methods related to Javascript===
'''JHtml::_('behavior.framework');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general, the use of JHtml::_('behavior.xxx') is now obsolete, and calls using this have been removed in the tutorial code. The 'behavior.framework' call referred to including jQuery. Where jQuery is necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.formvalidator');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by the <tt>form.validate</tt> javascript asset, and where necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It can also be included directly using the web asset manager:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$wa->useScript('form.validate')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.tooltip')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This no longer exists, and tooltips don't seem to be enabled by default in Joomla 4. This is replaced by the code in media/js/enable-tooltips.js.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('formbehavior.chosen')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The chosen js library seems to be no longer used, and using it will cause formatting issues if you include it in your tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''sortable'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The sortable js library provided the ability in the helloworlds view to drag rows up and down to change the ordering of the records. This has been replaced in Joomla 4 by the draggable library. To enable it you have to set:
* <tt>HTMLHelper::_('draggablelist.draggable');</tt>
* on your <tt><tbody></tt> element define the table in which dragging occurs and the URL of the Ajax call to set the ordering:
<source lang="php">
<tbody<?php if ($saveOrder) : ?> class="js-draggable" data-url="<?php echo $saveOrderingUrl; ?>" data-direction="<?php echo strtolower($listDirn); ?>" data-nested="true"
<?php endif; ?>>
</source>
* on your <tt>tr</tt> element within your <tt><tbody></tt> define the group of records in which dragging occurs (by category below):
<source lang="php">
<tr class="row<?php echo $i % 2; ?>" data-draggable-group="<?php echo $row->catid; ?>">
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==HTML Snippets==
There are two places in the tutorial where reusable snippets of HTML have beeen defined:
* For displaying the item associations in the helloworlds view:
* For displaying the position latitude and longitude fields within the batch options in the helloworlds view
These used different approaches:
* the item associations display was coded in an html helper file in admin/helpers/html/helloworlds.php and accessed via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JHtml::_('helloworlds.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
in the helloworlds tmpl file. (Although it did use a common joomla layout file underneath).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* the position field was coded as a layout in layouts/position.php, and rendered using
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JLayoutHelper::render('position', array());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When should you use one approach rather than the other? A significant difference is that layouts are designed so that an administrator can override them, via the Templates / Details and File functionality. So, for example, an administrator could change the position to show the longitude before the latitude. So it's more appropriate for layouts to focus on the html elements rather than functional logic, and particularly if you would want to allow an administrator to override the layout.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The layouts functionality in Joomla 4 hasn't changed significantly. One correction which has been made in the updated tutorial code has been to include the position.php file in a subfolder of layouts, ie in admin/layouts/helloworld/position.php rather than admin/layouts/position.php. It appears that in the Templates / Details and Files / Create Overrides tab the <tt>com_helloworld</tt> layout appears only if it's in a subfolder of /layouts.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>JHtml::_()</tt> approach has changed in Joomla 4. Rather than Joomla having to look for a helper file when it encounters something it doesn't recognise, it's expected that you should register such classes beforehand, and you do this by obtaining an instance of the Joomla\CMS\HTML\Registry class (it's a singleton class) and then calling <tt>register</tt> on it, passing
* the key you want to use
* an instance of your class
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Joomla pattern is to put the code in a file admin/src/Service/HTML/AdministratorService.php, and we have to ensure that our key won't be used elsewhere within Joomla, so in the tutorial we've used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Robbie\Component\Helloworld\Administrator\Service\HTML\AdministratorService;
...
register('helloworldadministrator', new AdministratorService)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when we call:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo HTMLHelper::_('helloworldadministrator.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will result in Joomla calling the <tt>association</tt> method in our class, passing the <tt>$row->id</tt> parameter.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We should get the Joomla\CMS\HTML\Registry class from the Dependency Injection container. Joomla components generally do this via their services/provider.php file, and then call <tt>register</tt> within the extension's <tt>boot</tt> function, described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Step_5_Call_boot.28.29_on_our_Component|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The extension uses HTMLRegistryAwareTrait which contains <tt>setRegistry</tt> and <tt>getRegistry methods</tt>. In services/provider.php there is:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\HTML\Registry;
...
$component->setRegistry($container->get(Registry::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets 'Joomla\CMS\HTML\Registry' out of the DI container and stores it within the
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
private $registry;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
variable of the HTMLRegistryAwareTrait included in the extension.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the <tt>boot</tt> function it calls
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getRegistry()->register('helloworldadministrator', new AdministratorService);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets the registry and calls <tt>register</tt> as required.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that <tt>boot</tt> is called whenever Joomla dispatches <tt>com_helloworld</tt>, both for the site and administrator, so it would make sense to check the Application <tt>isClient</tt> before deciding whether to register the HTML Helper service or not. This hasn't been included in the tutorial code though.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==User Interface Changes==
Joomla 4 introduced new templates, atum on administrator and cassiopeia on site, and in particular the administrator is built upon some UI rearrangements which affect the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Sidebar===
In Joomla 3 each component incorporated a sidebar which we coded in the <tt>addSubmenu</tt> function in admin/helpers/helloworld.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the administrator menu is in a vertical panel on the left hand side, and the Hello World submenu is built from entries in the helloworld.xml manifest file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<administration>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<submenu>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<menu link="option=com_categories&extension=com_helloworld">COM_HELLOWORLD_CATEGORIES</menu>
<menu link="option=com_fields&view=fields&context=com_helloworld.helloworld">MOD_MENU_FIELDS</menu>
<menu link="option=com_fields&view=groups&context=com_helloworld.helloworld">MOD_MENU_FIELDS_GROUP</menu>
</submenu>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===CSS Classes===
In several places the CSS classes defined in the html elements have been changed in Joomla 4. For example, for general layout the classes now align with the [https://getbootstrap.com/docs/3.4/css/ Bootstrap CSS Classes], and classes such as <tt>row-fluid</tt> and <tt>span3</tt> which were prominent in Joomla 3 have disappeared. If you're upgrading a Joomla 3 component then it's probably best (on the back-end at least) to find a similar Joomla component and use the overall html structure and css classes within its tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the tutorial code those classes which are specifically used by Bootstrap have been changed from eg 'data-target' to 'data-bs-target', and it has been necessary to change these to enable the functionality to work.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, not all of CSS class changes affecting solely the presentation have been reflected in the updated tutorial code. For example, in the <tt>helloworlds</tt> view, showing the list of helloworld messages, the display of the associations is different from that of other Joomla components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Fonts===
In Joomla 3 [[J3.x:Joomla_Standard_Icomoon_Fonts|Icomoon Fonts]] were used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 Font Awesome's free icons are used, and you can see what is available on their [https://fontawesome.com/v5/cheatsheet cheatsheet]. The icons are implemented using CSS pseudo-elements, as described [https://fontawesome.com/v5/docs/web/advanced/css-pseudo-elements here]. Basically they convert a CSS class into html content, namely a unicode value in the private use range. A couple of these have been implemented in the frontend form, in the Save and Cancel buttons, for example:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>span class="icon-cancel">/span <?php echo Text::_('JCANCEL') ?></tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(with angle brackets removed from the <tt>span</tt> tags to stop the icon just being displayed by the browser).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This class is defined in media/system/css/joomla-fontawesome.css (where you can find the list of icon classes supported):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
.icon-cancel:before {
content: "\f00d";
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so this includes in front of the text the unicode character <tt>f00d</tt>, which you can see on the cheatsheet as "times", and displayed as <span class="icon-cancel"></span>. You can also use <tt>fa-</tt> plus the icon name on the font awesome cheatsheet page. If you use Icomoon icon names in your code which you run under Joomla 4, then the icon displayed will be a Font Awesome icon (if there's one with the same name) or it will use a mapping which the Joomla team have defined to display a Font Awesome icon which resembles the Icomoon one.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Buttons and Links===
An accessibility principle is that <tt><a></tt> html elements should be used for links to other web pages, and <tt><button></tt> elements should be used for actions, eg on a form. To align with this, the <tt><a></tt> elements in the helloworld modal field (defined in admin/src/Field/Modal/Helloworld.php) have been changed to <tt><button></tt> elements. These are the Select and Clear buttons displayed when choosing a Helloworld record for a menuitem pointing to a Helloworld message. (The buttons also include fontawesome icons, by the way).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This change was actually made in Joomla in one of the Joomla 3 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Categories View===
In the Categories view of standard Joomla components there now appears columns which show for each category the number of items, split by published status. This is populated by <tt>com_categories</tt> calling each extension's <tt>countItems</tt> function, as described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_categories|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Miscellaneous Changes==
===Version History===
In Joomla 3 the tutorial code used the <tt>JTableObserver</tt> functionality to copy relevant changes from the Helloworld and Categories tables into the UCM tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it uses a plugin mechanism to subscribe to Table events 'onTableAfterStore' and 'onTableBeforeDelete'. The plugin can be found in plugins/behaviour/versionable, and it is activated by Joomla as part of its application initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The copying of fields from the table works roughly the same way as before, except that the name of the table where the versions are stored is now <tt>#__history</tt>, so the entries which have to be inserted into the <tt>#__content_types</tt> table are fairly similar. Because the folders in which forms are stored has changed in Joomla 4, the 'formFile' parameter is different (remember that this is where Joomla gets the field labels in order to display the Preview within the Versions modal window, otherwise just the names of the database columns will be output).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here's a summary of what needs to be done to enable versioning under Joomla 4. The Versioning Traits and Interface definitions are found in libraries/src/Versioning:
* Enter data into content_types database table
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Storing the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The Table class must implement VersionableTableInterface and provide <tt>getTypeAlias()</tt>, which returns 'com_helloworld.helloworld'. This type alias + the helloworld record id is used as the key to identify versions in the <tt>#__history</tt> table.
* Define <tt>save_history</tt> and <tt>history_limit</tt> options in config.php, and ensure these are both set.
* Add a <tt>version_note</tt> field into the output of the edit view's tmpl file (admin/tmpl/helloworld/edit.php).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Viewing and Restoring the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit Controller (admin/src/Controller/HelloworldController.php) should <tt>use VersionableControllerTrait</tt>.
* The edit Model (admin/src/Model/HelloworldModel.php) should <tt>use VersionableModelTrait</tt> and include a variable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public $typeAlias = 'com_helloworld.helloworld';
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit View (admin/src/View/Helloworld/HtmlView.php) – should display the Versions toolbar button if global config has <tt>save_history</tt> on.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Joomla 4 allows us to have different history version limits for helloworld items and categories, and this has been used in the configuration definition in admin/config.xml.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Setting Configuration Parameters in Install Script===
As you may remember, global configuration parameters relating to the Hello World component are defined in admin/config.xml and stored in the <tt>#__extensions</tt> table, in a JSON string in the params field of the record relating to <tt>com_helloworld</tt>. This means that when the component is first installed the params are not set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So, for example, even if the <tt>save_history</tt> is defined in config.xml to default to true, the versions won't be saved until an administrator actively saves the configuration parameters, because the Joomla versioning code assumes <tt>save_history</tt> to be false if it's not explicitly set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For this reason it makes sense to set any default configuration parameters in the install script.php, in the <tt>postflight</tt> method, and that has been done in this step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Tags===
Like version history, tags functionality has been changed to use a plugin – in plugins/behaviour/taggable – rather than the <tt>JTableObserver</tt> approach.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To enable tags the component table must implement TaggableTableInterface (in libraries/src/Tag), and provide the <tt>getTypeAlias()</tt> which is common to the Versioning functionality.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Whenever <tt>com_tags</tt> outputs helloworld messages or categories relating to a tag it displays them as links, and looks in the site/helpers/route.php file to find the route functions (as described above in [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_tags|com_tags]]). The class and method in this file must match the 'router' field within the data entered into the <tt>#__content_types</tt> table.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===media files===
Under Joomla 4 all of the media files are stored in the /media folder; these include javascript and css files (scss files too), as well as images such as the little flag symbols shown in the language switcher. Extensions being developed should store all of the js and css files in their /media folder, and then when the extension is installed these files are put under the extension's folder under the /media folder of the Joomla instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Patches==
Some bugs in Joomla were discovered during the course of updating the tutorial code to work under Joomla 4. If you find something doesn't work then make sure you're on at least Joomla 4.2.6 and check if you need one of the following patches:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
CategoryAssociationHelper.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39358/files
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
MediaField.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/issues/39203
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Category restore
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39474
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Contributors ==
*[[User:Robbiej|Robbie Jackson]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Prev: Adding Custom Fields|class=expand success}}</div>
</div>
</div>

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/19/it

2023-05-27T12:44:12Z

Ing Pulizzi: Created page with "'''Nota che le lettere maiuscole sono importanti nei namespace, nei nomi delle classi e nei nomi dei percorsi!'''"

'''Nota che le lettere maiuscole sono importanti nei namespace, nei nomi delle classi e nei nomi dei percorsi!'''

J3.x:Developing an MVC Component/Upgrading to Joomla4/it

2023-05-27T12:43:59Z

Ing Pulizzi: Created page with "<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> si troverà in components/com_helloworld/src/Model/CategoryModel.php"

<noinclude><languages /></noinclude>

{{:J3.1:Developing an MVC Component/it}}
Questo passaggio copre ciò che è coinvolto nell'aggiornamento del codice del tutorial per allinearlo con la versione 4 di Joomla.

== Introduzione ==
Questa pagina descrive i principali aspetti relativi allo sviluppo dei componenti che sono stati introdotti in Joomla 4 e descrive in dettaglio cosa è stato modificato nel codice del tutorial per allinearsi con v4.

Non è pratico dettagliare tutte le modifiche al codice sulla pagina Web come è stato fatto per i passaggi precedenti dell'esercitazione. Invece puoi trovare il codice come repository github su [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial Joomla 4 Tutorial code], e puoi confrontarlo con il codice del passaggio precedente del tutorial (Adding Custom Fields) su [https://github.com/robbiejackson/Joomla-3-MVC-Tutorial Joomla 3 MVC code]. Il codice di Joomla 4 replica tutte le funzionalità del codice di Joomla 3, con l'eccezione dell'implementazione dell'icona del piccolo pinguino introdotta in [[S:MyLanguage/J3.2:Developing an MVC Component/Adding decorations to the backend|Aggiunta di decorazioni al backend]] (che non è così rilevante data la modifica dell'interfaccia utente in Joomla 4 Administrator) e l'uso di un plug-in CAPTCHA ([[J3.x:Developing an MVC Component/Adding a frontend form|Adding a frontend form]] ). Probabilmente troverai utile avere a portata di mano questo codice Joomla 4 a cui fare riferimento mentre leggi questa pagina.

Il codice per questo passaggio è stato sviluppato seguendo ciascuno dei precedenti passaggi del tutorial e cercando di far funzionare ogni passaggio con Joomla 4.2.5. Poiché Joomla 4 si sta ancora evolvendo abbastanza velocemente, è possibile che alcuni aspetti qui citati vengano modificati durante la vita di Joomla 4. Sentiti libero di correggere gli aspetti in questa pagina e creare richieste pull su [https://github.com/robbiejackson /Joomla-4-MVC-Tutorial Joomla 4 github repository].

Se stai installando il codice del tutorial di Joomla 4 su una nuova istanza di Joomla, dovrai configurare la tua istanza per renderla multilingue e aggiungere le voci di menu nascoste di Ajax come descritto nel passaggio [[J3.x:Developing an MVC Component/ Utilizzo del filtro della lingua |Utilizzo del filtro della lingua]]. Assicurati inoltre che ogni record helloworld abbia una categoria valida.

=== Ulteriori letture ===
Puoi trovare [https://blog.astrid-guenther.de/en/der-weg-zu-joomla4-erweiterungen/ qui] un tutorial per lo sviluppo dei componenti di Joomla 4, simile a questo Joomla 3, e alcuni eccellenti Joomla 4 è disponibile anche la documentazione [https://www.dionysopoulos.me/book.html qui]. Entrambi questi riferimenti includono descrizioni degli impatti di Joomla 4 sullo sviluppo di altri tipi di estensioni Joomla (plugin, moduli e modelli), che non sono trattati qui.

Questo passaggio non copre tutto ciò che è necessario per aggiornare un componente da Joomla 3 a Joomla 4, solo gli aspetti coperti dal codice del tutorial. Se stai aggiornando il tuo componente Joomla 3, potresti trovare utile esaminare [[Potenziali problemi di compatibilità con le versioni precedenti in Joomla 4]].

== NameSpace ==
===NameSpace dei nomi dei componenti===
I NameSpace delle classi che utilizza la [https://www.php-fig.org/psr/psr-4/ PSR-4 recommendation] è stato gradualmente introdotto durante le versioni di Joomla 3 e con Joomla 4 è praticamente tutto con NameSpace

Ora è previsto che anche le estensioni di Joomla utilizzino i NameSpace di base per l'estensione definito nel suo file XML manifest. I componenti di Joomla usano uno NameSpace della forma <tt>Joomla\Component\<Nome componente></tt> es. <tt>Joomla\Component\Content</tt>, quindi seguendo questo schema ho dato una base al codice del tutorial spazio dei nomi di <tt>Robbie\Component\Helloworld</tt>. Ecco la riga nel file manifest helloworld.xml:

<namespace path="src">Robbie\Component\Helloworld</namespace>

(L'attributo <tt>path="src"</tt> indica che si aspetterà che le classi si trovino nella sottocartella <tt>src</tt>.)

Questo in realtà crea 2 prefissi dello spazio dei nomi, che puntano a cartelle specifiche nella nostra struttura di sviluppo helloworld e nella nostra istanza joomla live:

<tt>Robbie\Component\Helloworld\Administrator</tt> – punterà ad administrator/components/com_helloworld/src sull'istanza live ed è associato ad admin/src nella nostra area di sviluppo.

<tt>Robbie\Component\Helloworld\Site</tt> – punterà a components/com_helloworld/src sull'istanza live ed è associato a site/src nella nostra area di sviluppo.

Quindi Joomla ora si aspetta che tutti i nomi delle classi vengano trovati in quelle directory di base, con il nome del file che corrisponde al nome della classe e il nome della classe completo che corrisponde al percorso, ad esempio

<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> si troverà in
administrator/components/com_helloworld/src/Controller/DisplayController.php

<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> si troverà in
components/com_helloworld/src/Model/CategoryModel.php

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Note that capitalization is important in namespaces, names of classes and path names!'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla 3 wanted to call functions in your component it looked for certain file names in particular folders, and checked that the name of the class in that file matched what it expected.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it generates the fully qualified name of the class it wants to find, and then looks to find it in the location where the PSR-4 recommendation would expect it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Hence the namespace you specify in your class files must align with the file path to your PHP file, below the base <tt>src</tt> folder at your namespace prefix.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note in particular how the <tt>View</tt> class files are now organised.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Also if you use one of the PHP predefined classes (eg <tt>Exception</tt>) in your code, then add a backslash before it (eg <tt>\Exception</tt>), otherwise PHP will try and find it in your namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you use custom Field or Rule definitions in your form xml files then you have to indicate to PHP which namespace prefix to use to look for them, eg in <tt>site/forms/add-form.xml</tt>:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
addruleprefix="Robbie\Component\Helloworld\Administrator\Rule"
addfieldprefix="Robbie\Component\Helloworld\Administrator\Field"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and also in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> where the associations are added into the form dynamically to form the custom <tt>modal_helloworld</tt> type field:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Class Autoloading===
Joomla uses the PHP mechanism for [https://www.php.net/manual/en/language.oop5.autoload.php Autoloading Classes] and on startup registers a number of autoloaders – functions which get called when PHP can't find a given class. In particular the Joomla PSR-4 autoloader function (in <tt>libraries/loader.php</tt>) is responsible for finding classes of Joomla extensions whose code is in source files which are organised according to the PSR-4 recommendation. (Joomla library classes are autoloaded using a different autoloader – see <tt>libraries/vendor/composer/autoload_static.php</tt>).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can see the namespace prefixes of extensions on the Joomla instance by looking at <tt>administrator/cache/autoload_psr4.php</tt>. (These namespace strings have double backslashes, but in PHP they're the [https://stackoverflow.com/questions/25459197/single-or-double-slash-when-using-php-namespace same strings as those with single backslashes]). This is generated by Joomla looking through the component, module and plugin directories to find each extension's manifest file, and then processing these xml files to extract the <tt><namespace></tt> element – quite a lot of work, which is why it's cached I guess!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider what happens when Joomla wants our admin HelloworldController class. It might have something like
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$classname = 'Robbie\Component\Helloworld\Administrator\Controller\HelloworldController'
if (!class_exists($classname)) { …
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Assuming PHP doesn't already know about this class, the <tt>class_exists</tt> function will result in the classname being passed to the registered autoload function(s). The PSR-4 autoloader will then:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# go through its array of namespaces to try and match <tt>$classname</tt> from the start of the string.
# find 'Robbie\Component\Helloworld\Administrator' as a match
# see that this maps to "administrator/components/com_helloworld/src"
# extract the remainder of the classname: 'Controller\HelloworldController'
# treat this as the path down to the class file
# and so look for "administrator/components/com_helloworld/src/Controller/HelloworldController.php"
# check that in this file there's actually a class with that namespace + class name.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So in this way Joomla can go from a fully qualified class name to find the source code for that class. This makes it easier for us too when the core Joomla code is looking for one of our classes. We still need to know what class it's looking for, but once we know that, we know what we should call our class and where we should save the source code for it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Joomla Library classes===
Originally Joomla's core classes (beginning with a capital J) were global classes. Over the Joomla 3 versions and into Joomla 4 these migrated to their namespaced equivalents, but the original global classnames were still available as Joomla registered them as aliases (in the <tt>libraries/classmap.php</tt> file).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In a Joomla 4 extension you can still use these global classnames, except that in a namespaced file you'd have to prefix the name with a backslash to indicate a global class rather than one in your namespace (eg <tt>\JFactory</tt> instead of <tt>JFactory</tt>).
However it's pretty definite that the aliases will disappear at some stage, so the upgrade to Joomla 4 seems an appropriate opportunity to replace all your component's calls to the global JSomething classes to the namespaced equivalents. This involves adding the appropriate <tt>use</tt> statements, and all this has been done in the tutorial code. A useful mapping between the two can be found [https://github.com/nikosdion/joomlatypehints/blob/main/JoomlaObsoleteClasses.md here], where the new qualified classname can be copied and pasted into a <tt>use</tt> statement in your PHP file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
With reference to the [https://api.joomla.org/ Joomla API Documentation] there are 2 Joomla library namespaces:
* Joomla CMS classes – have namespaces <tt>Joomla\CMS\Something</tt> – are found under <tt>libraries/src/Something</tt>
* Joomla Framework classes – have namespaces <tt>Joomla\Something</tt> – are found under <tt>libraries/vendor/joomla/something/src</tt>
So a big advantage of namespacing is that you can immediately determine from the fully qualified class name in a PHP <tt>use</tt> statement where the source for that class exists in the <tt>libraries</tt> directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
On the other hand class names which aren't fully qualified don't have to be unique, eg <tt>MVCFactory</tt>
* occurs as <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in <tt>libraries/src/Extension/Service/Provider/MVCFactory.php</tt>
* occurs as <tt>Joomla\CMS\MVC\Factory\MVCFactory</tt> in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>
so sometimes you have to be careful to examine the <tt>use</tt> statement to identify the right class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly our FormModel class in <tt>site/src/Model/FormModel.php</tt> can have the same FormModel classname as the Joomla FormModel in <tt>libraries/src/MVC/Model/FormModel.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The API documentation gives the methods available in each of the [https://api.joomla.org/cms-4/namespaces/joomla.html Joomla CMS] and [https://api.joomla.org/framework-2/namespaces/joomla.html Framework] classes, but just be aware that a Joomla CMS class may extend a Framework class, and in this case some methods may not be visible under the Joomla CMS documentation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For example, <tt>$app->setHeader()</tt> which is used to set the HTTP response code is not listed under the [https://api.joomla.org/cms-4/classes/Joomla-CMS-Application-CMSApplication.html CMS Application class API], but is available as a method because it inherits from the Framework class [https://api.joomla.org/framework-2/classes/Joomla-Application-AbstractWebApplication.html AbstractWebApplication].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Vendor Namespaces===
These are also in <tt>libraries/vendor</tt>, eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Psr\Container\ContainerInterface;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
refers to <tt>libraries/vendor/psr/Container/src/ContainerInterface.php</tt>. However there are few of these in the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other File Rearrangements===
With all of the namespaced classes moving under the src directories, the <tt>tmpl</tt> layout files and <tt>form</tt> xml files have been moved out into their own directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Extension and Dispatcher classes ==
===Extension===
In Joomla 3 the point where the Joomla core handed over to your component code was when it ran your <tt>helloworld.php</tt> code; if it was the frontend it ran your site <tt>helloworld.php</tt> code, or if was the backend it ran your admin <tt>helloworld.php</tt> code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the entry point into your component code is your Extension class, both for site and admin, found in <tt>admin/src/Extension/HelloworldComponent.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When the Joomla core application wants to start executing the component code it creates an instance of <tt>HelloworldComponent</tt>, just to get a handle on the component code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly (as described below) other Joomla classes such as Router or Categories need to call certain Helloworld methods (eg custom router functions). In Joomla 3 these methods were written in certain Helper files etc. In Joomla 4 the principle is that the component creates an instance of the <tt>HelloworldComponent</tt> Extension class, and calls the required methods on that instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This Extension class isn't anything like a big container class for the component, it's more like a glue class, providing a way in to the Helloworld component, enabling the Joomla core and other components call the methods which they want to call.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla core wants to execute the component code, the key method it is looking for in your <tt>Extension</tt> instance is <tt>getDispatcher</tt>, and it expects to get back a <tt>Dispatcher</tt> instance. The <tt>HelloworldComponent</tt> extends <tt>MVCComponent</tt>, which in turn extends <tt>Component</tt>, and it is this class which defines <tt>getDispatcher</tt> for us.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Dispatcher===
When Joomla wants to run the Hello World component, it gets the <tt>Dispatcher</tt> instance as described above and then calls the <tt>dispatch</tt> method on it. It is this <tt>dispatch</tt> function which replaces the functionality in the admin and site <tt>helloworld.php</tt> files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's look at the main lines of code in our Joomla 3 admin <tt>helloworld.php</tt> file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="site/views/form/view.html.php">
<syntaxhighlight lang="php">
if (!JFactory::getUser()->authorise('core.manage', 'com_helloworld'))
{
throw new Exception(JText::_('JERROR_ALERTNOAUTHOR'));
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Get an instance of the controller
$controller = JControllerLegacy::getInstance('HelloWorld');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Execute the Request task method
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Redirect if set by the controller
$controller->redirect();
</syntaxhighlight>
</span>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code
* performs some permissions checks
* instantiates the appropriate Helloworld controller
* executes the appropriate method in that controller
* implements any redirect set by the controller
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Model-View-Controller]] for further details of how this works in Joomla 3. The second and third steps used the <tt>task</tt> parameter within the URL query to determine the correct controller class to instantiate and method to call. If no <tt>task</tt> parameter was present then it instantiated the controller in <tt>controller.php</tt> and called the <tt>display</tt> method. Otherwise it instantiated one of the controllers in the <tt>controllers</tt> subfolder (eg <tt>controllers/helloworld.php</tt>) and called the appropriate method on it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>ComponentDispatcher::dispatch</tt> method (in <tt>libraries/src/Dispatcher/ComponentDispatcher.php</tt>) now provides this functionality, but in a nicer way. After checking the permissions it uses the <tt>task</tt> by considering its parts as <tt><controller type>.<method></tt> (taking 'display' as default if either part is missing). It will then pass control to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* an instance of the class <Controller type>Controller
* calling the function <method>
* using the admin or site controller, as appropriate
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In this way the naming of the controllers is consistent - we have DisplayController, HelloworldController and HelloworldsController, all in the same folder.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Dispatcher class can thus be considered as providing some 'routing - execution' functionality, enabling us to find the right controller and function within that controller, and it is cleaner to have this in a separate class rather than in the <tt>JControllerLegacy</tt> class as it was in Joomla 3.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Since the Hello World tutorial uses the standard Joomla pattern for selecting the class and method based on the <tt>task</tt> and has the same permissions checks, we can use the <tt>dispatch</tt> code as it stands in <tt>ComponentDispatcher</tt>, and don't need to define a special class of our own.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Factory classes ==
In Joomla 3 many classes had static <tt>getInstance</tt> methods which returned an instance of that class, configured with the parameters passed to <tt>getInstance</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the <tt>getInstance</tt> methods have been deprecated in favour of using Factory classes. The preferred mechanism is now to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* get an instance of the appropriate Factory class (how we do that is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below)
* call the <tt>createSomething()</tt> method of the Factory class with relevant parameter values to generate an instance of the Something class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===MVC Factory===
In this section the <tt>MVCFactory</tt> class refers to the one in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory class will instantiate Controller, View, Model and Table instances on our behalf, and it does this by generating the classname of the class and then calling <tt>new</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The way it works is as follows:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Each component gets an individual MVCFactory instance which is constructed passing the component's namespace as a parameter (so in our case 'Robbie\Component\Helloworld'). (How this MVCFactory instance is created is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below).
# The MVCFactory createController / createView / createModel / createTable function is then called, passing the name of the Controller / Model / View / Table and the prefix (which specifies whether the administrator or site class is required).
# The create function forms the classname from this data and calls <tt>new</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory create functions just form the classname from the parameters they're passed. The intelligence for working out what name and prefix should be used to form the appropriate classes for an incoming HTTP request is
* in the dispatcher code for defining the controller to use
* in the controller for the view and model
* in the model for the table
and, for example, the names of the classes created for a request with URL query <tt>?option=com_helloworld&view=viewname</tt> and no <tt>task</tt> parameter will be
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<namespace>\Controller\DisplayController
<namespace>\View\Viewname\HtmlView
<namespace>\Model\ViewnameModel
<namespace>\Table\ViewnameTable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you need an alternative name then you can override the appropriate getView, getModel or getTable function – as for example was done in the [[J3.x:Developing an MVC Component/Adding Custom Fields#Front-end_Form|Adding Custom Fields step, frontend Form section]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So from the outside this is pretty much the same as in Joomla 3. However, note that the <tt>$prefix</tt> parameter in calls to <tt>getModel</tt> etc is subtly different
* in Joomla 3 this referred to a prefix to be applied to the classname – in the tutorial code we used 'HelloWorldTable' as the prefix part of the 'HelloWorldTableHelloWorld' classname.
* in Joomla 4 this refers to a prefix higher up the classname path, and should be set to either 'Site' or 'Administrator' (the capital letter at the start is optional), depending on whether you want the class under 'Robbie\Component\Helloworld\Site' or 'Robbie\Component\Helloworld\Administrator'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVC Factory class is now the Joomla recommended way to create the controller, view, model and table classes, by using the eg <tt>getModel()</tt> method, and the use of <tt>getInstance()</tt> for these classes is now deprecated. However, the use of these functions is restricted:
* in the controller class you can call <tt>$this->getView($viewname, $viewtype, $prefix, $config)</tt> to create a view and <tt>$this->getModel($modelname, $prefix, $config)</tt> to create a model.
* in the view class you can call <tt>$this->getModel($modelname)</tt>, but only for models which the controller has previously defined using <tt>$view->setModel($modelname, $default)</tt>. It doesn't create a new model instance.
* in the model class you can call <tt>$this->getTable($tableclass, $prefix, $options)</tt> to create a table instance. Controllers and views can access the table classes in this way, by going via a model.
These restrictions do have an impact on moving away from using <tt>getInstance()</tt>, and indeed in Joomla 4.2.6 you will still find several <tt>getInstance()</tt> calls within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Factory Classes===
Several other Factory classes have been introduced in Joomla 4, enabling you to get instances of core classes such as Form, User, CacheController, etc, usually by calling a createSomething function on the Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Associated with the Factory class is a FactoryInterface, a PHP Interface which specifies the key functions which the Factory class must implement. For example, with <tt>libraries/src/Categories</tt> we have:
* CategoryFactoryInterface – which specifies the <tt>createCategory</tt> function
* CategoryFactory implements CategoryFactoryInterface – which provides the <tt>createCategory</tt> function.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Dependency Injection ==
===Overview===
The DI container is one of the significant new additions to Joomla 4. It's basically a repository of key-value pairs where:
* the key is a string which is the name of a class or interface
* the value is an instance of the relevant class, or a function that returns an instance of that class.
You put things into the container using <tt>set()</tt> passing:
* the class name or interface name
* a function which returns an instance of the class (or an instance of the class)
* a boolean defining whether the class instance may be shared or not
* a boolean defining whether this entry into the DI container is protected or not (an error will be raised if you try to overwrite a protected entry by calling <tt>set()</tt> again using the same key).
The function <tt>share()</tt> is basically the same as <tt>set()</tt> with the <tt>shared</tt> boolean set to true.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You get things out of the container by calling <tt>get()</tt> passing the key of the resource you want. The container will
* find the key in the container
* if the value isn't already a class instance, then it will run the associated function to generate an instance of the class
* if the resource is shared, it will store the class instance, so that on subsequent invocations of <tt>get()</tt> it can just return the instance
* return the class instance to you
You can also define aliases for each key in the container, which means that you call <tt>get()</tt> passing either the key or an alias of the key.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The DI container is initialised in <tt>library/src/Factory.php createContainer()</tt> which results in the <tt>register()</tt> function being called in each of the class files in <tt>libraries/src/Service/Provider</tt>. By looking through those files you can see what gets put into the DI container upon initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===JConfig Example===
Let's consider the example of JConfig which holds the system global configuration. If you look inside <tt>libraries/src/Service/Provider/Config.php</tt> then you'll see the <tt>register()</tt> function and that it stores in the DI container a resource with:
* key = 'JConfig'
* value = an anonymous function - which loads what's in <tt>configuration.php</tt> into a <tt>Registry</tt> object, and returns it
* shared flag = true (because the <tt>share()</tt> function is used)
* protected flag = true
Then when you do
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$config = $container->get('JConfig');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will run the anonymous function and return the Registry object to you. As the 'shared' boolean is set it will also store a copy of the class instance locally in the container to be returned on subsequent calls of <tt>get('JConfig')</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Justification===
What's the point of all this?
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The advantage of dependency injection is that it allows classes to be easily mocked for testing. The file <tt>libraries/src/Service/Provider/Config.php</tt> can be replaced to return to a DI container <tt>get()</tt> call a mock class instead of the usual <tt>JConfig</tt>. This is in comparison to Joomla 3 where <tt>Factory::getConfig()</tt> code directly reads the <tt>configuration.php</tt> into a Registry structure and returns it – which makes it harder to mock.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The [https://api.joomla.org/cms-4/classes/Joomla-CMS-Factory.html Factory API] has several functions which are marked as deprecated with advice to get the object from the DI container instead.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Several of the other Factory classes (eg Form, Language, Menu, User) are in the DI container – so that we can get an instance of them via eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Factory::getContainer()->get('Joomla\CMS\Toolbar\ToolbarFactoryInterface')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to get a Toolbar instance. However, this only works for singleton classes which aren't specific to the needs of a particular extension. We'll see shortly how to make it work for class instances which need to be specific to a component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As indicated above, Joomla is moving away from using the class static <tt>getInstance()</tt> functions. We can see now that this is not only because it's more pure from an object oriented perspective. But also creating class instances from the DI container, or from Factory objects which are obtained from the DI container, builds in the dependency injection which allows classes to be more easily mocked, and hence more easily tested.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==services/provider.php==
We're now finally in a good position to understand what's happening in our services/provider.php file, and we'll explore this by walking through what happens whenever this line in libraries/src/Component/ComponentHelper.php <tt>renderComponent</tt> is run:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is run whenever Joomla has worked out which component is to be run on the requested web page, and it wants to run that component to capture its output.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 1 Create Child DI Container===
Joomla first creates another DI container (initially empty) just for this component, and links it to the main DI container via a parent field in the child DI container structure.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Now whenever <tt>set()</tt> is called on this DI container the key-value pair is inserted into the child container. Whenever <tt>get()</tt> is called on it, the resource is obtained from the child container, but if it's not found there then the parent container is searched also.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 2 Run register() in provider.php===
Next we encounter these lines (in <tt>libraries/src/Extension/ExtensionManagerTrait.php</tt>), where <tt>$path</tt> contains the path of our helloworld admin/services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$provider = require_once $path;
// Check if the extension supports the service provider interface
if ($provider instanceof ServiceProviderInterface) {
$provider->register($container);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here we see 3 things:
# our provider.php should return some object (so that <tt>$provider</tt> gets set to something)
# what is returned should implement ServiceProviderInterface (you can see in <tt>libraries/vendor/joomla/di/src/ServiceProviderInterface.php</tt> what is expected)
# the code then runs the <tt>register</tt> function on that object, passing as a parameter the child DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider a minimal version of our provider.php file. This would actually support steps in the Joomla 3 tutorial up to and including the [[J3.x:Developing an MVC Component/Adding AJAX|Adding Ajax step]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {

public function register(Container $container): void
{
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
}
};
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As you can see from the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
this file does indeed return something – it returns an instance of an anonymous class, one that implements <tt>ServiceProviderInterface</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it's not sufficient to just provide the <tt>register</tt> function in the class, we also need to explicity state that the class implements <tt>ServiceProviderInterface</tt>. This now happens in several places in Joomla, so if you're debugging your component and wondering why a function you expect to be called isn't being called, then check to make sure that you don't have to explicitly add the appropriate <tt>implements <Interface></tt> clause to your class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Next we look at the 3 lines in the <tt>register</tt> function
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3a Registering our MVC Factory===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here our <tt>MVCFactory</tt> refers to <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in libraries/src/Extension/Service/Provider/MVCFactory.php, and you should have a look at this file. This is a file similar to our provider.php file, but it's a named class, and it doesn't return anything. When we do:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
new MVCFactory('\\Robbie\\Component\\Helloworld')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it creates an instance of this class, and in the constructor it stores locally in <tt>$this->namespace</tt> our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>registerServiceProvider</tt> function then calls the <tt>register</tt> function of this instance, which runs (in its minimalist form):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
MVCFactoryInterface::class,
function (Container $container) {
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
return $factory;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So what gets entered into our child DI container is a key-value pair with:
* key = MVCFactoryInterface::class (this is just a shorthand form to obtain a string of the fully qualified name – ie 'Joomla\CMS\MVC\Factory\MVCFactoryInterface')
* value = a function which returns an instance of <tt>\Joomla\CMS\MVC\Factory\MVCFactory</tt>.
This is our MVCFactory class which generates our Controllers, Views, Models and Tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Notice that we're passing our namespace as a parameter <tt>$this->namespace</tt>. Because this function is a closure, this variable will still be available when we run this function later, and when the MVCFactory class is instantiated the namespace will be passed into the constructor, stored locally, and then subsequently used to form the fully qualified names of our Controllers, View, etc. So this is how we get instantiated the MVCFactory class which is specific to our component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3b Registering the Dispatcher Factory===
Careful: ComponentDispatcherFactory refers to two different classes here!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This ComponentDispatcherFactory is Joomla\CMS\Extension\Service\Provider\ComponentDispatcherFactory in libraries/src/Extension/Service/Provider/ComponentDispatcherFactory.php. Similar to the above, the ComponentDispatcherFactory service provider class stores locally our namespace, and then when <tt>register</tt> is called it executes:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentDispatcherFactoryInterface::class,
function (Container $container) {
return new \Joomla\CMS\Dispatcher\ComponentDispatcherFactory($this->namespace,$container->get(MVCFactoryInterface::class));
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so a second entry is added to the child DI container with:
* key = ComponentDispatcherFactoryInterface::class
* value = a function which returns an instance of the ComponentDispatcherFactory (the other ComponentDispatcherFactory class!), where the class constructor will be passed the namespace ('\\Robbie\\Component\\Helloworld') and an MVCFactory instance, retrieved from the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that the code
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->get(MVCFactoryInterface::class)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
will get from the container an entry with key = 'Joomla\CMS\MVC\Factory\MVCFactoryInterface' – which is what we entered into the container in step 3a – and will run the function associated with this key, and then return the object which this function returns. This returned object will be an instance of '\Joomla\CMS\MVC\Factory\MVCFactory', constructed using our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3c Including the Extension===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will put into the child DI container a key-value pair with
* key = ComponentInterface::class
* value = the function which will create an instance of our <tt>HelloworldComponent</tt> (ie our Extension class), and pass into the constructor an instance of the ComponentDispatcherFactory class, retrieving what was entered into the child DI container in Step 3b.
It will call <tt>$container->get(MVCFactoryInterface::class)</tt>, getting an MVC Factory instance from what was entered into the DI container in Step 3a.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It will then associate our component with this MVC Factory instance via the <tt>setMVCFactory</tt> call. Significantly this will then allow our component to access this instance later, via a call to <tt>getMVCFactory</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3 Summary===
We have now got 3 entries in our child DI container, keyed by
* key = MVCFactoryInterface::class, value is a function returning an MVCFactory instance
* key = ComponentDispatcherFactoryInterface::class, value is a function returning a ComponentDispatcherFactory instance
* key = ComponentInterface::class, value is a function returning our HelloworldComponent, an instance of our Extension class.
The important aspect is that these entries are all aware of our namespace '\Robbie\Component\Helloworld' and will return instances of these classes which are specific to our Helloworld component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 4 Retrieving from the DI Container===
Joomla will then execute the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $container->get($type);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
where <tt>$type</tt> contains 'Joomla\CMS\Extension\ComponentInterface'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This starts the process of retrieving from the DI container the 3 entries which we put in, and will run our code in services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We end up with a HelloworldComponent instance, which has:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. a ComponentDispatcherFactory instance passed into the constructor, and which is saved locally by the constructor code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function __construct(ComponentDispatcherFactoryInterface $dispatcherFactory)
{
$this->dispatcherFactory = $dispatcherFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This code is in libraries/src/Extension/Component.php, in the class which our HelloworldComponent extends, via the class MVCComponent).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. an MVC Factory instance, stored by the HelloworldComponent <tt>setMVCFactory</tt> call
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 5 Call boot() on our Component===
Joomla calls:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
if ($extension instanceof BootableExtensionInterface) {
$extension->boot($container);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will call <tt>boot</tt> within our HelloworldComponent, and allows us to perform some initialisation within our component. We'll return to this later, in the section on [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#HTML_Snippets|HTML snippets]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note again that Joomla checks that our HelloworldComponent class implements BootableExtensionInterface before calling <tt>boot</tt>. It's not sufficient to just provide the <tt>boot</tt> function, we have to explicitly declare that our HelloworldComponent implements the interface.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 6 Get the Dispatcher===
Returning to our key line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
we have now accomplished the first part <tt>bootComponent($option)</tt>, and this has returned our HelloworldComponent instance. Now we call <tt>getDispatcher($app)</tt> on this instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This code is also in libraries/src/Extension/Component.php, in the Component class which our HelloworldComponent extends:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function getDispatcher(CMSApplicationInterface $application): DispatcherInterface
{
return $this->dispatcherFactory->createDispatcher($application);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We call <tt>createDispatcher</tt> on our ComponentDispatcherFactory class instance which we saved in Step 4. This code is in libraries/src/Dispatcher/ComponentDispatcherFactory.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createDispatcher(CMSApplicationInterface $application, Input $input = null): DispatcherInterface
{
$name = ucfirst($application->getName());

$className = '\\' . trim($this->namespace, '\\') . '\\' . $name . '\\Dispatcher\\Dispatcher';

if (!class_exists($className)) {
if ($application->isClient('api')) {
$className = ApiDispatcher::class;
} else {
$className = ComponentDispatcher::class;
}
}

return new $className($application, $input ?: $application->input, $this->mvcFactory);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code checks if we have our own Dispatcher class (our Helloworld tutorial doesn't, but <tt>com_users</tt> for example has its own). So it creates a <tt>ComponentDispatcher</tt> instance, and passes into its constructor the MVC Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that this ComponentDispatcherFactory instance is what was instantiated when it was retrieved from our child DI Container (from being inserted in step 3b), and hence it already knows about our namespace, and has a pointer to our MVCFactory class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 7 call dispatch()===
This is the final aspect to our line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We're now back to what was described in the Dispatcher section above, except that now we can see that this Dispatcher instance has a pointer to our MVC Factory instance (which knows about our namespace prefix), so when the Dispatcher code wants to create a Controller it can use that MVC Factory instance to instantiate it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's been a long and tortuous journey to get here, but the significant thing is that all of our key class instances have been obtained via the DI Container. If we want to mock out any of those classes for testing then all we need to do is replace the relevant services/provider file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Javascript and the Web Asset Manager ==
The web asset manager has been introduced in Joomla 4 and is well documented [[J4.x:Web_Assets|here]]. It provides a much-improved means of managing JS and CSS resources, and a framework for handling their dependencies.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Component Javascript and CSS files should now be stored in the <tt>media</tt> folder, and the Web Asset Manager used to register them and output them on specific web pages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following assets have been registered in the tutorial <tt>joomla.asset.json</tt>, and you should have a look at that file now.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.validate-greeting===
This is the code for client validation of the helloworld greeting field using a regex, and it is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it is dependent upon jQuery and the Joomla <tt>form.validator</tt> script, so those both get included as dependencies.
If we didn't have specific validation on our form then we would need to include explicitly the <tt>form.validator</tt> script in order for the basic Joomla field validation to be included, eg in the tmpl file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->document->getWebAssetManager()->useScript('form.validate');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that this requires us to have a <tt>class="form-validate"</tt> on the </tt><form></tt> html element.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.fix-permissions-ajax-call===
This is the code which copies the value from the greeting field into the title field, so that the Ajax calls setting the permissions work correctly. The js code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.enable-tooltips===
This is the code which enables bootstrap tooltips to operate, including allowing them to include html code. It's used to display the image as a tooltip within the admin <tt>helloworlds</tt> view.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.openstreetmap===
This is defined as a preset, comprising the helloworld js and css code for the map display, as well as the dependency named 'com_helloworld.openlayers' relating to the openlayers CSS and js code. The code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.admin-helloworlds-modal===
This is the js code for selecting an individual helloworld record within a modal, and passing its details to the form in the main window. Its code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===submitbutton.js===
In the Joomla 3 code we introduced in [[Special:MyLanguage/J3.2:Developing_an_MVC_Component/Adding_verifications|Adding Verifications]] a js file which controlled when the form was submitted. It differentiated between buttons such as <tt>Save</tt> (which submitted the form) and <tt>Cancel</tt> (which didn't).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 there is a more sophisticated version of <tt>Joomla.submitbutton</tt> (found in media/system/js/core.js) which uses the CSS classes which the Toolbar functionality sets on the buttons to determine whether the form should be submitted or not. And you can override whether the validation is performed by adding a third parameter to the <tt>submitbutton</tt> js call. For example, to avoid validation being performed when a button is clicked you can set on the button element:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
onclick="Joomla.submitbutton('controller.method', '', false)"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As this is sufficient for what we need in the tutorial, the custom <tt>submitbutton.js</tt> has been removed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Interaction with other components ==
The way that Joomla interacts with components has changed in Joomla 4. In general the Joomla functionality will boot the component using something like:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $app->bootComponent($option);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and in our case this will return an instance of the <tt>HelloworldComponent</tt> class. It will then try to call certain methods on our extension object, as described below.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_categories===
In the backend the helloworld functionality can display to the administrator
* the view of the helloworld messages
* the view of the helloworld categories
The categories view is generated by <tt>com_categories</tt>, and in Joomla 4 these component categories views display the number of component records there are for each of the possible published status values. To do this the categories component executes the following code (in administrator/components/com_categories/src/Model/CategoriesModel.php):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof CategoryServiceInterface) {
$component->countItems($items, $section);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So our HelloworldComponent must:
* declare that it implements <tt>CategoryServiceInterface</tt>
* provide an implementation of <tt>countItems</tt>
We provide <tt>countItems</tt> by using a trait in libraries/src/Categories/CategoryServiceTrait.php, which (with the assistance of a helper function) does the query on our behalf. We just need to tell it:
* the name of our table – in the callback <tt>getTableNameForSection</tt>
* the database field in which we hold the published status – in <tt>getStateColumnForSection</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_associations===
Remember that <tt>com_associations</tt> is the component which is run whenever you click on Multilingual Associations in the admin backend.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Under Joomla 3 we provided an associations helper file as described in [[J3.x:Multilingual Associations/Developers|Multilingual Associations/Developers]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the helper file remains basically the same, but <tt>com_associations</tt> primarily tries to find the helper file via the extension class; here's the code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($extensionName);
if ($component instanceof AssociationServiceInterface) {
return $component->getAssociationsExtension();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's expecting that:
* the extension (HelloworldComponent in our case) implements <tt>AssociationServiceInterface</tt>
* its <tt>getAssociationsExtension</tt> method returns the helper class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The easiest thing would be just to code <tt>getAssociationsMethod</tt> and get it to return <tt>new AssociationsHelper</tt>. However, we follow the Joomla 4 principle of putting key classes into the Dependency Injection container, and retrieving them later, by having the following code in our services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(AssociationExtensionInterface::class, new AssociationsHelper());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The above line puts a key-value pair into our child DI container
* key = 'Joomla\CMS\Association\AssociationExtensionInterface'
* value is an instance of our <tt>AssociationsHelper</tt> class.
We then retrieve it later and use the setter:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setAssociationExtension($container->get(AssociationExtensionInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so that whenever
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getAssociationExtension()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
is called it returns the <tt>AssociationsHelper</tt> class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_fields===
<tt>com_fields</tt> is the component which is run when an administrator clicks on the Fields or Field Groups menuitem within the backend, and this functionality was included in the [[J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Adding Custom Fields]] tutorial step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>com_fields</tt> component stores the custom fields and field groups for all components in the database tables <tt>#__fields</tt> and <tt>#__fields_groups</tt>, and these tables are partitioned into "sections", one section per component. For our helloworld component the section is named "helloworld".
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within the section we have 2 "contexts" – one for the helloworld messages (called "com_helloworld.helloworld") and one for the helloworld categories (called "com_helloworld.categories"). This enables us to define custom fields for both our helloworld records and helloworld category records.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When <tt>com_fields</tt> runs it checks both the section and contexts at various times. For example, when an admin selects Helloworld / Fields on the backend then <tt>com_fields</tt> checks the section which was defined in the menuitem in the manifest file (see [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Sidebar|below]]). Here's the code in administrator/components/com_fields/src/Helpers/FieldsHelper <tt>extract</tt> function:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
$newSection = $component->validateSection($parts[1], $item);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And when <tt>com_fields</tt> wants to display the little dropdown menu of contexts (to allow the administrator to set custom fields on either helloworld items or categories) it calls (in administrator/components/com_fields/src/Fields/FieldcontextsField.php <tt>getOptions()</tt>):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
return $component->getContexts();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So it's clear that our component extension class must :
* implement <tt>FieldsServiceInterface</tt>
* provide the <tt>validateSection</tt> and <tt>getContexts</tt> methods
So in upgrading to Joomla 4 we've just moved those two methods from the helper file to the extension class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Router===
The Joomla router will access our custom router code:
* whenever it wants to parse an SEF route which it has identified as belonging to <tt>com_helloworld</tt>
* whenever it wants to build an SEF route from a call to <tt>Route::_()</tt> where the option = "com_helloworld".
To find our custom router it will:
* boot the <tt>com_helloworld</tt> extension
* check that the extension implements <tt>RouterServiceInterface</tt>
* call <tt>createRouter</tt> on our extension instance
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In our services/provider.php file we have (careful again - 2 different RouterFactory classes!):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new RouterFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which from libraries/src/Extension/Service/Provider/RouterFactory.php puts into our child DI container an entry with:
* key = "Joomla\CMS\Component\Router\RouterFactoryInterface"
* value is a <tt>\Joomla\CMS\Component\Router\RouterFactory</tt> instance, constructed with our namespace
We then retrieve this in the line in our services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setRouterFactory($container->get(RouterFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And then within our extension class we have
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use RouterServiceTrait;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which includes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function setRouterFactory(RouterFactoryInterface $routerFactory)
{
$this->routerFactory = $routerFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which stores the <tt>routerFactory</tt> locally and
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return $this->routerFactory->createRouter($application, $menu);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which provides our extension's <tt>createRouter</tt> call that the Joomla Router expects.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>routerFactory::createRouter</tt> method is in libraries/src/Component/Router/RouterFactory.php. It looks for a class in our site namespace </tt>Robbie\Component\Helloworld\Site\Service\Router</tt> which is in our site/src/Service/Router.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
At this stage we have a choice, we can either:
* provide a traditional custom router, with the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions, or
* use the more modern <tt>RouterView</tt> mechanism.
By default in the upgraded tutorial code the Router View option has been coded in the Router.php file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====RouterView====
In the <tt>RouterView</tt> case the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions are in the <tt>RouterView</tt> class which we extend, and we provide
* a constructor with router view configuration
* methods <tt>getHelloworldId</tt> and <tt>getCategoryId</tt> which are used to obtain from the SEF segment the <tt>id=</tt> and <tt>catid=</tt> parts of the internal URL
* methods <tt>getHelloworldSegment</tt> and <tt>getCategorySegment</tt> which are used to generate segments for the SEF URLs based on the <tt>id=</tt> and <tt>catid=</tt> parts within the <tt>Route::_()</tt> parameter.
Unfortunately there doesn't seem to be a good guide to configuring the RouterView class. There is some documentation available [https://www.dionysopoulos.me/book/com-router-routerview.html here].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the helloworld tutorial we have 3 views
* a view which displays a single helloworld record
* a view which displays a single helloworld category, and the helloworld records associated with it
* a view which displays the frontend form
So we need 3 Router Views associated with these.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'form' view doesn't have an associated id or catid so it's just a fixed URL, and the router just has to convert between the alias of the form menuitem and the Itemid / view parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'category' view has an associated id (of the category record), and an SEF URL will use the category path down the Categories Nested Set table structure, hence <tt>setNestable()</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'helloworld' view has an associated id (of the helloworld record), and in an SEF URL in the category view the helloworld record alias is added to the category path (hence <tt>setParent()</tt>). But although the helloworld records use a Nested Table structure in the database, the URLs just include the alias of the single record, and so <tt>setNestable()</tt> is not used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There doesn't seem to be a way to configure an additional SEF URL scheme which just displays a helloworld segment, without a category segment.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====Traditional Router====
To use the traditional router in the tutorial code you should uncomment the function in the extension class:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return new TraditionalRouter($application, $menu, $this->categoryFactory, $this->getDatabase());
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will cause the code in site/src/Service/TraditionalRouter.php to be used. However, changes in the Joomla 4 router mean that the interaction between it and the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> methods have changed. This requires significant changes to the <tt>preprocess</tt> and <tt>build</tt> methods, but only a minor change to <tt>parse</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. Previously Joomla injected into the <tt>$query</tt> parameters the <tt>Itemid</tt> of the active menuitem (ie the id of the menuitem the user is currently on). This meant that we had to change the <tt>Itemid</tt> for links generated by the Language Switcher module (which generates the flags for switching between languages), and these links being associated with a different language would obviously use a different <tt>Itemid</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 you get an <tt>Itemid</tt> in the <tt>$query</tt> parameters only if you specified an <tt>Itemid</tt> in the <tt>Route::_()</tt> call. For others you have to work out which menuitem to use yourself, by using the Joomla menu/menuitems API to find details of the configured menuitems, and work out which to use based on the other <tt>$query</tt> parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You do this in the <tt>preprocess</tt> method, and then the <tt>Itemid</tt> you set will be passed in the <tt>$query</tt> parameters to the <tt>build</tt> method.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. In some instances the <tt>Route::_()</tt> URL you're generating matches exactly one of the configured menuitems on the site. In this case the <tt>$query</tt> parameters will match those in the menuitem <tt>"query"</tt> array, and you have to remove explicitly remove the 'view', 'id' and 'catid' parameters so that they don't appear as URL query parameters after the normal SEF URL of the menuitem.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
3. The custom router will be used to build the URLs for the helloworld menuitems shown in menus on the page. For these the <tt>$query</tt> parameters will have the view / id / catid associated with those menuitems. Note that even if you remove these in your <tt>preprocess</tt> method, Joomla will inject them again into the <tt>$query</tt> array when it's passed to your <tt>build</tt> method, so you'll have to remove them again there!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
4. In the <tt>parse</tt> method you now have to unset the <tt>$segments</tt>, or else Joomla will return an HTTP 404 (page not found). Otherwise <tt>parse</tt> works as before.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
5. I've implemented <tt>build</tt> only for when Multilanguage is enabled on the site. If it's not enabled an empty <tt>$segments</tt> array is just returned, without doing unset on any of the <tt>$query</tt> parameters, so these will appear as URL parameters after the SEF URL. Also it's not coded properly to deal with items which have language set to <tt>*</tt>. These include helloworld records, categories or menuitems (eg the helloworld form).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that the <tt>categoryFactory</tt> is also now passed to the router. This is so that it can be used instead of <tt>Categories::getInstance()</tt> to get access to the Categories API calls.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_tags===
Whenever we setup a Tags Menu Item Type which displays items having a given tag or tags, then <tt>com_tags</tt> displays those items as links, and uses route helper functions to generate the URL parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The route helpers <tt>com_tags</tt> expects to find loaded into the data of the <tt>#__content_types</tt> table, in the router field, and these have been set to:
* For links to helloworld items: 'HelloworldHelperRoute::getHelloworldRoute'
* For links to helloworld categories: 'HelloworldHelperRoute::getCategoryRoute'
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, <tt>com_tags</tt> doesn't boot the helloworld extension to get access to these, but rather seeks to find them in site/helpers/route.php, so that's where they continue to be.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(We also had a <tt>getCategoryRoute</tt> which was used by <tt>com_categories</tt> in administrator/components/com_categories/src/Helper/CategoryAssociationHelper. When a category was displayed on the frontend then the Language Switcher module (now Language Filter) used this function to generate the links to the Associated Categories. Our <tt>getCategoryRoute</tt> previously was necessary to insert the <tt>lang=<language tag></tt> parameter into the link URL, but since [https://github.com/joomla/joomla-cms/pull/39358 this change] the calling function inserts the <tt>lang</tt> parameter itself, so our <tt>getCategoryRoute</tt> function for this purposes is superfluous.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Deprecated APIs ==
With Joomla 4 there are a number of methods which are deprecated, with a view to removing them in Joomla 5.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Factory Methods===
Many of the <tt>Factory</tt> methods for getting singleton classes have been deprecated in favour of getting these classes via the DI container, and it appears that only class instances which should be obtained via Factory methods are:
* the Application – <tt>Factory::getApplication()</tt>
* the DI container – <tt>Factory::getContainer()</tt>
Here is a list of what has been changed in the tutorial code. Note that with some calls there are variants available, through the aliases defined in the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDbo'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\Database\DatabaseInterface;
...
$db = Factory::getContainer()->get(DatabaseInterface::class);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, in many classes the database instance is more easily (and efficiently) returned via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$db = $this->getDatabase();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is available in Model classes, custom field definitions, etc.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getUser();'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get the current user use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = Factory::getApplication()->getIdentity()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get a different user (whose id you know):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\User\UserFactoryInterface;
...
$user = Factory::getContainer()->get(UserFactoryInterface::class)->loadUserById($userid);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within models which extend Joomla\CMS\MVC\Model\BaseDatabaseModel and views which extend Joomla\CMS\MVC\View\HtmlView you can also use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = $this->getCurrentUser()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDocument()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication()->getDocument()</tt>, or within a View you can use <tt>$this->document</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getConfig()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Two options have been used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->getConfig()</tt> – returns a Registry object containing all the configuration values
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->get('access')</tt> – returns the value of the 'access' configuration parameter
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getLanguage()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication->getLanguage()</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JFactory::getCache('com_example', <type>)'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Cache\CacheControllerFactoryInterface;
...
Factory::getContainer()->get(CacheControllerFactoryInterface::class)->createCacheController(<type>)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated getInstance Methods===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general <tt>getInstance()</tt> calls have been deprecated in favour of obtaining the instance, either via a factory class or via the DI container. For example, within a controller you can use <tt>getModel()</tt> repeatedly to get different models (passing the relevant model names), which results in the MVCFactory class creating the Model classes.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there are currently some problems with replacing some getInstance calls. I expect that the Joomla team will resolve these issues over the course of the Joomla 4 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Categories::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is deprecated with a notice: "Use the ComponentInterface to get the categories". This means that we should get the category factory instance via the DI container. This is done in our services/provider.php by the lines:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Extension\Service\Provider\CategoryFactory;
...
$container->registerServiceProvider(new CategoryFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to put into our child DI container the closure which will create a Joomla\CMS\Categories\CategoryFactory instance, constructed with our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when our HelloworldComponent (Extension) instance is created:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We can then use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getCategoryFactory()->createCategory();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to create our Categories object, and in this way get access to the Categories APIs.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This createCategory method creates the instance by looking for the \\Site\\Service\\Category class within our namespace. The constructor in our class sets our extension ('com_helloworld') and table ('#__helloworld') and calls the parent Categories constructor with these options).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this means that the section of our code where we want to use the Categories APIs must have a pointer to a CategoryFactory instance. In the tutorial code for Joomla 3 there are 2 places where <tt>Categories::getInstance</tt> is used:
* in the custom router code, to handle building and parsing of the category parts of the SEF URL
* in the site category model, where the Categories APIs are used to obtain details of categories to display on the page.
For the custom router code, the CategoryFactory instance is passed as a parameter to the TraditionalRouter constructor so that it can be used there.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, the site category model is instantiated by the MVCFactory instance, and it doesn't make available a CategoryFactory instance. So in this category model the calls to <tt>Categories::getInstance()</tt> have been left, and you can still find a number of calls to <tt>Categories::getInstance</tt> within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Categories::getInstance()</tt> itself solves the problem of access to a CategoryFactory instance by rebooting our component again to get a pointer to our Extension instance, and thus to the category factory instance. However, this involves a lot of work, so <tt>getInstance</tt> caches locally the Categories instances and just returns one of them if it can.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Pushing the CategoryFactory to the model'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there is a way to get access to the CategoryFactory instance, by defining your own MVCFactory class, and pushing the instance down through it to the model. Here's how you can go about it:
* Define your own SuperMVCFactory class, which extends the Joomla Joomla\CMS\MVC\Factory\MVCFactory class, but which has a means of storing a CategoryFactory instance. Use the CategoryServiceTrait in libraries/src/Categories/CategoryServiceTrait.php
* Create your own version of the file libraries/src/Extension/Service/Provider/MVCFactory.php, which is the 'provider.php' like file for MVCFactory, but change it so that:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
becomes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new <namespace>\SuperMVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and include
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla creates a model such as CategoryModel it passes in its constructor the MVCFactory instance (so that the model can call createTable on it), so you can access it via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will return your SuperMVCFactory instance. So in this way within the model you can access the CategoryFactory, and use it to create the Categories instance via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()->getCategory() (from the CategoryServiceTrait)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you can get this working you can congratulate yourself on a good understanding of Joomla namespacing and dependency injection! A similar approach to address a similar problem is described [https://www.dionysopoulos.me/book/com-router-push-dependencies.html here]. If you get stuck you can always view the solution by viewing the github tutorial code selecting the branch [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial/tree/push-category-factory-to-mvc push-category-factory-to-mvc].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Table::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There are a couple of calls to <tt>Table::getInstance()</tt> within admin/src/Helper/AssociationsHelper.php in <tt>getItem()</tt>:
* <tt>Table::getInstance('Helloworld', 'Robbie\\Component\\Helloworld\\Administrator\\Table\\')</tt> to get an instance of our HelloworldTable class.
* <tt>Table::getInstance('Category')</tt> to get an instance of the Category table in libraries/src/Table/Category.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We could actually arrange for the AssociationsHelper class to get injected with the MVCFactory instance, so that the HelloworldTable class could be instantiated by it. However, we couldn't use the helloworld MVCFactory instance to create the Category table instance, as it's not in the helloworld namespace, and our MVCFactory instance creates table instances within our namespace only.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Toolbar::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The tutorial code uses <tt>Toolbar::getInstance()</tt> to get a Toolbar instance onto which it can attach the batch button in the helloworlds form. The Toolbar API documentation seems to suggest that we should replace
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Toolbar::getInstance('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
with
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this currently won't work. The problem is that all the other Joomla code uses <tt>getInstance('toolbar')</tt> to access the Toolbar class, including the code in administrator/modules/mod_toolbar/mod_toolbar.php which renders the toolbar. The <tt>getInstance</tt> method keeps track of the Toolbar instances in a local static variable <tt>$instances</tt>, and returns the same Toolbar instance on repeated invocations.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you use the second approach above you will get a Toolbar instance, but it won't be the same Toolbar instance as is stored in the <tt>$instances</tt> variable. It won't then be picked up by the Toolbar module, and so won't be rendered on the form.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Error Handling===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead of
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
JError::raiseError(500, implode('<br />', $errors));
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
you should throw an exception, using or extending one of the standard [https://www.php.net/manual/en/spl.exceptions.php PHP exceptions], eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
throw new \Exception(implode("\n", $errors), 500);
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===jimport===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
jimport is no longer necessary in order to get access to Path or File classes. All of the Joomla classes are found by the autoloader.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Methods related to Javascript===
'''JHtml::_('behavior.framework');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general, the use of JHtml::_('behavior.xxx') is now obsolete, and calls using this have been removed in the tutorial code. The 'behavior.framework' call referred to including jQuery. Where jQuery is necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.formvalidator');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by the <tt>form.validate</tt> javascript asset, and where necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It can also be included directly using the web asset manager:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$wa->useScript('form.validate')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.tooltip')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This no longer exists, and tooltips don't seem to be enabled by default in Joomla 4. This is replaced by the code in media/js/enable-tooltips.js.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('formbehavior.chosen')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The chosen js library seems to be no longer used, and using it will cause formatting issues if you include it in your tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''sortable'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The sortable js library provided the ability in the helloworlds view to drag rows up and down to change the ordering of the records. This has been replaced in Joomla 4 by the draggable library. To enable it you have to set:
* <tt>HTMLHelper::_('draggablelist.draggable');</tt>
* on your <tt><tbody></tt> element define the table in which dragging occurs and the URL of the Ajax call to set the ordering:
<source lang="php">
<tbody<?php if ($saveOrder) : ?> class="js-draggable" data-url="<?php echo $saveOrderingUrl; ?>" data-direction="<?php echo strtolower($listDirn); ?>" data-nested="true"
<?php endif; ?>>
</source>
* on your <tt>tr</tt> element within your <tt><tbody></tt> define the group of records in which dragging occurs (by category below):
<source lang="php">
<tr class="row<?php echo $i % 2; ?>" data-draggable-group="<?php echo $row->catid; ?>">
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==HTML Snippets==
There are two places in the tutorial where reusable snippets of HTML have beeen defined:
* For displaying the item associations in the helloworlds view:
* For displaying the position latitude and longitude fields within the batch options in the helloworlds view
These used different approaches:
* the item associations display was coded in an html helper file in admin/helpers/html/helloworlds.php and accessed via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JHtml::_('helloworlds.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
in the helloworlds tmpl file. (Although it did use a common joomla layout file underneath).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* the position field was coded as a layout in layouts/position.php, and rendered using
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JLayoutHelper::render('position', array());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When should you use one approach rather than the other? A significant difference is that layouts are designed so that an administrator can override them, via the Templates / Details and File functionality. So, for example, an administrator could change the position to show the longitude before the latitude. So it's more appropriate for layouts to focus on the html elements rather than functional logic, and particularly if you would want to allow an administrator to override the layout.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The layouts functionality in Joomla 4 hasn't changed significantly. One correction which has been made in the updated tutorial code has been to include the position.php file in a subfolder of layouts, ie in admin/layouts/helloworld/position.php rather than admin/layouts/position.php. It appears that in the Templates / Details and Files / Create Overrides tab the <tt>com_helloworld</tt> layout appears only if it's in a subfolder of /layouts.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>JHtml::_()</tt> approach has changed in Joomla 4. Rather than Joomla having to look for a helper file when it encounters something it doesn't recognise, it's expected that you should register such classes beforehand, and you do this by obtaining an instance of the Joomla\CMS\HTML\Registry class (it's a singleton class) and then calling <tt>register</tt> on it, passing
* the key you want to use
* an instance of your class
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Joomla pattern is to put the code in a file admin/src/Service/HTML/AdministratorService.php, and we have to ensure that our key won't be used elsewhere within Joomla, so in the tutorial we've used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Robbie\Component\Helloworld\Administrator\Service\HTML\AdministratorService;
...
register('helloworldadministrator', new AdministratorService)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when we call:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo HTMLHelper::_('helloworldadministrator.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will result in Joomla calling the <tt>association</tt> method in our class, passing the <tt>$row->id</tt> parameter.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We should get the Joomla\CMS\HTML\Registry class from the Dependency Injection container. Joomla components generally do this via their services/provider.php file, and then call <tt>register</tt> within the extension's <tt>boot</tt> function, described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Step_5_Call_boot.28.29_on_our_Component|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The extension uses HTMLRegistryAwareTrait which contains <tt>setRegistry</tt> and <tt>getRegistry methods</tt>. In services/provider.php there is:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\HTML\Registry;
...
$component->setRegistry($container->get(Registry::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets 'Joomla\CMS\HTML\Registry' out of the DI container and stores it within the
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
private $registry;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
variable of the HTMLRegistryAwareTrait included in the extension.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the <tt>boot</tt> function it calls
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getRegistry()->register('helloworldadministrator', new AdministratorService);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets the registry and calls <tt>register</tt> as required.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that <tt>boot</tt> is called whenever Joomla dispatches <tt>com_helloworld</tt>, both for the site and administrator, so it would make sense to check the Application <tt>isClient</tt> before deciding whether to register the HTML Helper service or not. This hasn't been included in the tutorial code though.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==User Interface Changes==
Joomla 4 introduced new templates, atum on administrator and cassiopeia on site, and in particular the administrator is built upon some UI rearrangements which affect the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Sidebar===
In Joomla 3 each component incorporated a sidebar which we coded in the <tt>addSubmenu</tt> function in admin/helpers/helloworld.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the administrator menu is in a vertical panel on the left hand side, and the Hello World submenu is built from entries in the helloworld.xml manifest file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<administration>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<submenu>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<menu link="option=com_categories&extension=com_helloworld">COM_HELLOWORLD_CATEGORIES</menu>
<menu link="option=com_fields&view=fields&context=com_helloworld.helloworld">MOD_MENU_FIELDS</menu>
<menu link="option=com_fields&view=groups&context=com_helloworld.helloworld">MOD_MENU_FIELDS_GROUP</menu>
</submenu>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===CSS Classes===
In several places the CSS classes defined in the html elements have been changed in Joomla 4. For example, for general layout the classes now align with the [https://getbootstrap.com/docs/3.4/css/ Bootstrap CSS Classes], and classes such as <tt>row-fluid</tt> and <tt>span3</tt> which were prominent in Joomla 3 have disappeared. If you're upgrading a Joomla 3 component then it's probably best (on the back-end at least) to find a similar Joomla component and use the overall html structure and css classes within its tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the tutorial code those classes which are specifically used by Bootstrap have been changed from eg 'data-target' to 'data-bs-target', and it has been necessary to change these to enable the functionality to work.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, not all of CSS class changes affecting solely the presentation have been reflected in the updated tutorial code. For example, in the <tt>helloworlds</tt> view, showing the list of helloworld messages, the display of the associations is different from that of other Joomla components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Fonts===
In Joomla 3 [[J3.x:Joomla_Standard_Icomoon_Fonts|Icomoon Fonts]] were used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 Font Awesome's free icons are used, and you can see what is available on their [https://fontawesome.com/v5/cheatsheet cheatsheet]. The icons are implemented using CSS pseudo-elements, as described [https://fontawesome.com/v5/docs/web/advanced/css-pseudo-elements here]. Basically they convert a CSS class into html content, namely a unicode value in the private use range. A couple of these have been implemented in the frontend form, in the Save and Cancel buttons, for example:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>span class="icon-cancel">/span <?php echo Text::_('JCANCEL') ?></tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(with angle brackets removed from the <tt>span</tt> tags to stop the icon just being displayed by the browser).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This class is defined in media/system/css/joomla-fontawesome.css (where you can find the list of icon classes supported):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
.icon-cancel:before {
content: "\f00d";
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so this includes in front of the text the unicode character <tt>f00d</tt>, which you can see on the cheatsheet as "times", and displayed as <span class="icon-cancel"></span>. You can also use <tt>fa-</tt> plus the icon name on the font awesome cheatsheet page. If you use Icomoon icon names in your code which you run under Joomla 4, then the icon displayed will be a Font Awesome icon (if there's one with the same name) or it will use a mapping which the Joomla team have defined to display a Font Awesome icon which resembles the Icomoon one.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Buttons and Links===
An accessibility principle is that <tt><a></tt> html elements should be used for links to other web pages, and <tt><button></tt> elements should be used for actions, eg on a form. To align with this, the <tt><a></tt> elements in the helloworld modal field (defined in admin/src/Field/Modal/Helloworld.php) have been changed to <tt><button></tt> elements. These are the Select and Clear buttons displayed when choosing a Helloworld record for a menuitem pointing to a Helloworld message. (The buttons also include fontawesome icons, by the way).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This change was actually made in Joomla in one of the Joomla 3 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Categories View===
In the Categories view of standard Joomla components there now appears columns which show for each category the number of items, split by published status. This is populated by <tt>com_categories</tt> calling each extension's <tt>countItems</tt> function, as described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_categories|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Miscellaneous Changes==
===Version History===
In Joomla 3 the tutorial code used the <tt>JTableObserver</tt> functionality to copy relevant changes from the Helloworld and Categories tables into the UCM tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it uses a plugin mechanism to subscribe to Table events 'onTableAfterStore' and 'onTableBeforeDelete'. The plugin can be found in plugins/behaviour/versionable, and it is activated by Joomla as part of its application initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The copying of fields from the table works roughly the same way as before, except that the name of the table where the versions are stored is now <tt>#__history</tt>, so the entries which have to be inserted into the <tt>#__content_types</tt> table are fairly similar. Because the folders in which forms are stored has changed in Joomla 4, the 'formFile' parameter is different (remember that this is where Joomla gets the field labels in order to display the Preview within the Versions modal window, otherwise just the names of the database columns will be output).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here's a summary of what needs to be done to enable versioning under Joomla 4. The Versioning Traits and Interface definitions are found in libraries/src/Versioning:
* Enter data into content_types database table
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Storing the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The Table class must implement VersionableTableInterface and provide <tt>getTypeAlias()</tt>, which returns 'com_helloworld.helloworld'. This type alias + the helloworld record id is used as the key to identify versions in the <tt>#__history</tt> table.
* Define <tt>save_history</tt> and <tt>history_limit</tt> options in config.php, and ensure these are both set.
* Add a <tt>version_note</tt> field into the output of the edit view's tmpl file (admin/tmpl/helloworld/edit.php).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Viewing and Restoring the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit Controller (admin/src/Controller/HelloworldController.php) should <tt>use VersionableControllerTrait</tt>.
* The edit Model (admin/src/Model/HelloworldModel.php) should <tt>use VersionableModelTrait</tt> and include a variable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public $typeAlias = 'com_helloworld.helloworld';
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit View (admin/src/View/Helloworld/HtmlView.php) – should display the Versions toolbar button if global config has <tt>save_history</tt> on.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Joomla 4 allows us to have different history version limits for helloworld items and categories, and this has been used in the configuration definition in admin/config.xml.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Setting Configuration Parameters in Install Script===
As you may remember, global configuration parameters relating to the Hello World component are defined in admin/config.xml and stored in the <tt>#__extensions</tt> table, in a JSON string in the params field of the record relating to <tt>com_helloworld</tt>. This means that when the component is first installed the params are not set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So, for example, even if the <tt>save_history</tt> is defined in config.xml to default to true, the versions won't be saved until an administrator actively saves the configuration parameters, because the Joomla versioning code assumes <tt>save_history</tt> to be false if it's not explicitly set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For this reason it makes sense to set any default configuration parameters in the install script.php, in the <tt>postflight</tt> method, and that has been done in this step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Tags===
Like version history, tags functionality has been changed to use a plugin – in plugins/behaviour/taggable – rather than the <tt>JTableObserver</tt> approach.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To enable tags the component table must implement TaggableTableInterface (in libraries/src/Tag), and provide the <tt>getTypeAlias()</tt> which is common to the Versioning functionality.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Whenever <tt>com_tags</tt> outputs helloworld messages or categories relating to a tag it displays them as links, and looks in the site/helpers/route.php file to find the route functions (as described above in [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_tags|com_tags]]). The class and method in this file must match the 'router' field within the data entered into the <tt>#__content_types</tt> table.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===media files===
Under Joomla 4 all of the media files are stored in the /media folder; these include javascript and css files (scss files too), as well as images such as the little flag symbols shown in the language switcher. Extensions being developed should store all of the js and css files in their /media folder, and then when the extension is installed these files are put under the extension's folder under the /media folder of the Joomla instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Patches==
Some bugs in Joomla were discovered during the course of updating the tutorial code to work under Joomla 4. If you find something doesn't work then make sure you're on at least Joomla 4.2.6 and check if you need one of the following patches:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
CategoryAssociationHelper.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39358/files
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
MediaField.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/issues/39203
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Category restore
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39474
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Contributors ==
*[[User:Robbiej|Robbie Jackson]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Prev: Adding Custom Fields|class=expand success}}</div>
</div>
</div>

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/18/it

2023-05-27T12:43:56Z

Ing Pulizzi: Created page with "<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> si troverà in components/com_helloworld/src/Model/CategoryModel.php"

<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> si troverà in
components/com_helloworld/src/Model/CategoryModel.php

J3.x:Developing an MVC Component/Upgrading to Joomla4/it

2023-05-27T12:43:43Z

Ing Pulizzi: Created page with "<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> si troverà in administrator/components/com_helloworld/src/Controller/DisplayController.php"

<noinclude><languages /></noinclude>

{{:J3.1:Developing an MVC Component/it}}
Questo passaggio copre ciò che è coinvolto nell'aggiornamento del codice del tutorial per allinearlo con la versione 4 di Joomla.

== Introduzione ==
Questa pagina descrive i principali aspetti relativi allo sviluppo dei componenti che sono stati introdotti in Joomla 4 e descrive in dettaglio cosa è stato modificato nel codice del tutorial per allinearsi con v4.

Non è pratico dettagliare tutte le modifiche al codice sulla pagina Web come è stato fatto per i passaggi precedenti dell'esercitazione. Invece puoi trovare il codice come repository github su [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial Joomla 4 Tutorial code], e puoi confrontarlo con il codice del passaggio precedente del tutorial (Adding Custom Fields) su [https://github.com/robbiejackson/Joomla-3-MVC-Tutorial Joomla 3 MVC code]. Il codice di Joomla 4 replica tutte le funzionalità del codice di Joomla 3, con l'eccezione dell'implementazione dell'icona del piccolo pinguino introdotta in [[S:MyLanguage/J3.2:Developing an MVC Component/Adding decorations to the backend|Aggiunta di decorazioni al backend]] (che non è così rilevante data la modifica dell'interfaccia utente in Joomla 4 Administrator) e l'uso di un plug-in CAPTCHA ([[J3.x:Developing an MVC Component/Adding a frontend form|Adding a frontend form]] ). Probabilmente troverai utile avere a portata di mano questo codice Joomla 4 a cui fare riferimento mentre leggi questa pagina.

Il codice per questo passaggio è stato sviluppato seguendo ciascuno dei precedenti passaggi del tutorial e cercando di far funzionare ogni passaggio con Joomla 4.2.5. Poiché Joomla 4 si sta ancora evolvendo abbastanza velocemente, è possibile che alcuni aspetti qui citati vengano modificati durante la vita di Joomla 4. Sentiti libero di correggere gli aspetti in questa pagina e creare richieste pull su [https://github.com/robbiejackson /Joomla-4-MVC-Tutorial Joomla 4 github repository].

Se stai installando il codice del tutorial di Joomla 4 su una nuova istanza di Joomla, dovrai configurare la tua istanza per renderla multilingue e aggiungere le voci di menu nascoste di Ajax come descritto nel passaggio [[J3.x:Developing an MVC Component/ Utilizzo del filtro della lingua |Utilizzo del filtro della lingua]]. Assicurati inoltre che ogni record helloworld abbia una categoria valida.

=== Ulteriori letture ===
Puoi trovare [https://blog.astrid-guenther.de/en/der-weg-zu-joomla4-erweiterungen/ qui] un tutorial per lo sviluppo dei componenti di Joomla 4, simile a questo Joomla 3, e alcuni eccellenti Joomla 4 è disponibile anche la documentazione [https://www.dionysopoulos.me/book.html qui]. Entrambi questi riferimenti includono descrizioni degli impatti di Joomla 4 sullo sviluppo di altri tipi di estensioni Joomla (plugin, moduli e modelli), che non sono trattati qui.

Questo passaggio non copre tutto ciò che è necessario per aggiornare un componente da Joomla 3 a Joomla 4, solo gli aspetti coperti dal codice del tutorial. Se stai aggiornando il tuo componente Joomla 3, potresti trovare utile esaminare [[Potenziali problemi di compatibilità con le versioni precedenti in Joomla 4]].

== NameSpace ==
===NameSpace dei nomi dei componenti===
I NameSpace delle classi che utilizza la [https://www.php-fig.org/psr/psr-4/ PSR-4 recommendation] è stato gradualmente introdotto durante le versioni di Joomla 3 e con Joomla 4 è praticamente tutto con NameSpace

Ora è previsto che anche le estensioni di Joomla utilizzino i NameSpace di base per l'estensione definito nel suo file XML manifest. I componenti di Joomla usano uno NameSpace della forma <tt>Joomla\Component\<Nome componente></tt> es. <tt>Joomla\Component\Content</tt>, quindi seguendo questo schema ho dato una base al codice del tutorial spazio dei nomi di <tt>Robbie\Component\Helloworld</tt>. Ecco la riga nel file manifest helloworld.xml:

<namespace path="src">Robbie\Component\Helloworld</namespace>

(L'attributo <tt>path="src"</tt> indica che si aspetterà che le classi si trovino nella sottocartella <tt>src</tt>.)

Questo in realtà crea 2 prefissi dello spazio dei nomi, che puntano a cartelle specifiche nella nostra struttura di sviluppo helloworld e nella nostra istanza joomla live:

<tt>Robbie\Component\Helloworld\Administrator</tt> – punterà ad administrator/components/com_helloworld/src sull'istanza live ed è associato ad admin/src nella nostra area di sviluppo.

<tt>Robbie\Component\Helloworld\Site</tt> – punterà a components/com_helloworld/src sull'istanza live ed è associato a site/src nella nostra area di sviluppo.

Quindi Joomla ora si aspetta che tutti i nomi delle classi vengano trovati in quelle directory di base, con il nome del file che corrisponde al nome della classe e il nome della classe completo che corrisponde al percorso, ad esempio

<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> si troverà in
administrator/components/com_helloworld/src/Controller/DisplayController.php

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> will be found in
components/com_helloworld/src/Model/CategoryModel.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Note that capitalization is important in namespaces, names of classes and path names!'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla 3 wanted to call functions in your component it looked for certain file names in particular folders, and checked that the name of the class in that file matched what it expected.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it generates the fully qualified name of the class it wants to find, and then looks to find it in the location where the PSR-4 recommendation would expect it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Hence the namespace you specify in your class files must align with the file path to your PHP file, below the base <tt>src</tt> folder at your namespace prefix.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note in particular how the <tt>View</tt> class files are now organised.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Also if you use one of the PHP predefined classes (eg <tt>Exception</tt>) in your code, then add a backslash before it (eg <tt>\Exception</tt>), otherwise PHP will try and find it in your namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you use custom Field or Rule definitions in your form xml files then you have to indicate to PHP which namespace prefix to use to look for them, eg in <tt>site/forms/add-form.xml</tt>:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
addruleprefix="Robbie\Component\Helloworld\Administrator\Rule"
addfieldprefix="Robbie\Component\Helloworld\Administrator\Field"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and also in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> where the associations are added into the form dynamically to form the custom <tt>modal_helloworld</tt> type field:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Class Autoloading===
Joomla uses the PHP mechanism for [https://www.php.net/manual/en/language.oop5.autoload.php Autoloading Classes] and on startup registers a number of autoloaders – functions which get called when PHP can't find a given class. In particular the Joomla PSR-4 autoloader function (in <tt>libraries/loader.php</tt>) is responsible for finding classes of Joomla extensions whose code is in source files which are organised according to the PSR-4 recommendation. (Joomla library classes are autoloaded using a different autoloader – see <tt>libraries/vendor/composer/autoload_static.php</tt>).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can see the namespace prefixes of extensions on the Joomla instance by looking at <tt>administrator/cache/autoload_psr4.php</tt>. (These namespace strings have double backslashes, but in PHP they're the [https://stackoverflow.com/questions/25459197/single-or-double-slash-when-using-php-namespace same strings as those with single backslashes]). This is generated by Joomla looking through the component, module and plugin directories to find each extension's manifest file, and then processing these xml files to extract the <tt><namespace></tt> element – quite a lot of work, which is why it's cached I guess!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider what happens when Joomla wants our admin HelloworldController class. It might have something like
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$classname = 'Robbie\Component\Helloworld\Administrator\Controller\HelloworldController'
if (!class_exists($classname)) { …
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Assuming PHP doesn't already know about this class, the <tt>class_exists</tt> function will result in the classname being passed to the registered autoload function(s). The PSR-4 autoloader will then:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# go through its array of namespaces to try and match <tt>$classname</tt> from the start of the string.
# find 'Robbie\Component\Helloworld\Administrator' as a match
# see that this maps to "administrator/components/com_helloworld/src"
# extract the remainder of the classname: 'Controller\HelloworldController'
# treat this as the path down to the class file
# and so look for "administrator/components/com_helloworld/src/Controller/HelloworldController.php"
# check that in this file there's actually a class with that namespace + class name.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So in this way Joomla can go from a fully qualified class name to find the source code for that class. This makes it easier for us too when the core Joomla code is looking for one of our classes. We still need to know what class it's looking for, but once we know that, we know what we should call our class and where we should save the source code for it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Joomla Library classes===
Originally Joomla's core classes (beginning with a capital J) were global classes. Over the Joomla 3 versions and into Joomla 4 these migrated to their namespaced equivalents, but the original global classnames were still available as Joomla registered them as aliases (in the <tt>libraries/classmap.php</tt> file).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In a Joomla 4 extension you can still use these global classnames, except that in a namespaced file you'd have to prefix the name with a backslash to indicate a global class rather than one in your namespace (eg <tt>\JFactory</tt> instead of <tt>JFactory</tt>).
However it's pretty definite that the aliases will disappear at some stage, so the upgrade to Joomla 4 seems an appropriate opportunity to replace all your component's calls to the global JSomething classes to the namespaced equivalents. This involves adding the appropriate <tt>use</tt> statements, and all this has been done in the tutorial code. A useful mapping between the two can be found [https://github.com/nikosdion/joomlatypehints/blob/main/JoomlaObsoleteClasses.md here], where the new qualified classname can be copied and pasted into a <tt>use</tt> statement in your PHP file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
With reference to the [https://api.joomla.org/ Joomla API Documentation] there are 2 Joomla library namespaces:
* Joomla CMS classes – have namespaces <tt>Joomla\CMS\Something</tt> – are found under <tt>libraries/src/Something</tt>
* Joomla Framework classes – have namespaces <tt>Joomla\Something</tt> – are found under <tt>libraries/vendor/joomla/something/src</tt>
So a big advantage of namespacing is that you can immediately determine from the fully qualified class name in a PHP <tt>use</tt> statement where the source for that class exists in the <tt>libraries</tt> directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
On the other hand class names which aren't fully qualified don't have to be unique, eg <tt>MVCFactory</tt>
* occurs as <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in <tt>libraries/src/Extension/Service/Provider/MVCFactory.php</tt>
* occurs as <tt>Joomla\CMS\MVC\Factory\MVCFactory</tt> in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>
so sometimes you have to be careful to examine the <tt>use</tt> statement to identify the right class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly our FormModel class in <tt>site/src/Model/FormModel.php</tt> can have the same FormModel classname as the Joomla FormModel in <tt>libraries/src/MVC/Model/FormModel.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The API documentation gives the methods available in each of the [https://api.joomla.org/cms-4/namespaces/joomla.html Joomla CMS] and [https://api.joomla.org/framework-2/namespaces/joomla.html Framework] classes, but just be aware that a Joomla CMS class may extend a Framework class, and in this case some methods may not be visible under the Joomla CMS documentation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For example, <tt>$app->setHeader()</tt> which is used to set the HTTP response code is not listed under the [https://api.joomla.org/cms-4/classes/Joomla-CMS-Application-CMSApplication.html CMS Application class API], but is available as a method because it inherits from the Framework class [https://api.joomla.org/framework-2/classes/Joomla-Application-AbstractWebApplication.html AbstractWebApplication].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Vendor Namespaces===
These are also in <tt>libraries/vendor</tt>, eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Psr\Container\ContainerInterface;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
refers to <tt>libraries/vendor/psr/Container/src/ContainerInterface.php</tt>. However there are few of these in the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other File Rearrangements===
With all of the namespaced classes moving under the src directories, the <tt>tmpl</tt> layout files and <tt>form</tt> xml files have been moved out into their own directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Extension and Dispatcher classes ==
===Extension===
In Joomla 3 the point where the Joomla core handed over to your component code was when it ran your <tt>helloworld.php</tt> code; if it was the frontend it ran your site <tt>helloworld.php</tt> code, or if was the backend it ran your admin <tt>helloworld.php</tt> code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the entry point into your component code is your Extension class, both for site and admin, found in <tt>admin/src/Extension/HelloworldComponent.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When the Joomla core application wants to start executing the component code it creates an instance of <tt>HelloworldComponent</tt>, just to get a handle on the component code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly (as described below) other Joomla classes such as Router or Categories need to call certain Helloworld methods (eg custom router functions). In Joomla 3 these methods were written in certain Helper files etc. In Joomla 4 the principle is that the component creates an instance of the <tt>HelloworldComponent</tt> Extension class, and calls the required methods on that instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This Extension class isn't anything like a big container class for the component, it's more like a glue class, providing a way in to the Helloworld component, enabling the Joomla core and other components call the methods which they want to call.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla core wants to execute the component code, the key method it is looking for in your <tt>Extension</tt> instance is <tt>getDispatcher</tt>, and it expects to get back a <tt>Dispatcher</tt> instance. The <tt>HelloworldComponent</tt> extends <tt>MVCComponent</tt>, which in turn extends <tt>Component</tt>, and it is this class which defines <tt>getDispatcher</tt> for us.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Dispatcher===
When Joomla wants to run the Hello World component, it gets the <tt>Dispatcher</tt> instance as described above and then calls the <tt>dispatch</tt> method on it. It is this <tt>dispatch</tt> function which replaces the functionality in the admin and site <tt>helloworld.php</tt> files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's look at the main lines of code in our Joomla 3 admin <tt>helloworld.php</tt> file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="site/views/form/view.html.php">
<syntaxhighlight lang="php">
if (!JFactory::getUser()->authorise('core.manage', 'com_helloworld'))
{
throw new Exception(JText::_('JERROR_ALERTNOAUTHOR'));
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Get an instance of the controller
$controller = JControllerLegacy::getInstance('HelloWorld');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Execute the Request task method
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Redirect if set by the controller
$controller->redirect();
</syntaxhighlight>
</span>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code
* performs some permissions checks
* instantiates the appropriate Helloworld controller
* executes the appropriate method in that controller
* implements any redirect set by the controller
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Model-View-Controller]] for further details of how this works in Joomla 3. The second and third steps used the <tt>task</tt> parameter within the URL query to determine the correct controller class to instantiate and method to call. If no <tt>task</tt> parameter was present then it instantiated the controller in <tt>controller.php</tt> and called the <tt>display</tt> method. Otherwise it instantiated one of the controllers in the <tt>controllers</tt> subfolder (eg <tt>controllers/helloworld.php</tt>) and called the appropriate method on it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>ComponentDispatcher::dispatch</tt> method (in <tt>libraries/src/Dispatcher/ComponentDispatcher.php</tt>) now provides this functionality, but in a nicer way. After checking the permissions it uses the <tt>task</tt> by considering its parts as <tt><controller type>.<method></tt> (taking 'display' as default if either part is missing). It will then pass control to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* an instance of the class <Controller type>Controller
* calling the function <method>
* using the admin or site controller, as appropriate
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In this way the naming of the controllers is consistent - we have DisplayController, HelloworldController and HelloworldsController, all in the same folder.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Dispatcher class can thus be considered as providing some 'routing - execution' functionality, enabling us to find the right controller and function within that controller, and it is cleaner to have this in a separate class rather than in the <tt>JControllerLegacy</tt> class as it was in Joomla 3.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Since the Hello World tutorial uses the standard Joomla pattern for selecting the class and method based on the <tt>task</tt> and has the same permissions checks, we can use the <tt>dispatch</tt> code as it stands in <tt>ComponentDispatcher</tt>, and don't need to define a special class of our own.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Factory classes ==
In Joomla 3 many classes had static <tt>getInstance</tt> methods which returned an instance of that class, configured with the parameters passed to <tt>getInstance</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the <tt>getInstance</tt> methods have been deprecated in favour of using Factory classes. The preferred mechanism is now to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* get an instance of the appropriate Factory class (how we do that is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below)
* call the <tt>createSomething()</tt> method of the Factory class with relevant parameter values to generate an instance of the Something class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===MVC Factory===
In this section the <tt>MVCFactory</tt> class refers to the one in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory class will instantiate Controller, View, Model and Table instances on our behalf, and it does this by generating the classname of the class and then calling <tt>new</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The way it works is as follows:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Each component gets an individual MVCFactory instance which is constructed passing the component's namespace as a parameter (so in our case 'Robbie\Component\Helloworld'). (How this MVCFactory instance is created is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below).
# The MVCFactory createController / createView / createModel / createTable function is then called, passing the name of the Controller / Model / View / Table and the prefix (which specifies whether the administrator or site class is required).
# The create function forms the classname from this data and calls <tt>new</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory create functions just form the classname from the parameters they're passed. The intelligence for working out what name and prefix should be used to form the appropriate classes for an incoming HTTP request is
* in the dispatcher code for defining the controller to use
* in the controller for the view and model
* in the model for the table
and, for example, the names of the classes created for a request with URL query <tt>?option=com_helloworld&view=viewname</tt> and no <tt>task</tt> parameter will be
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<namespace>\Controller\DisplayController
<namespace>\View\Viewname\HtmlView
<namespace>\Model\ViewnameModel
<namespace>\Table\ViewnameTable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you need an alternative name then you can override the appropriate getView, getModel or getTable function – as for example was done in the [[J3.x:Developing an MVC Component/Adding Custom Fields#Front-end_Form|Adding Custom Fields step, frontend Form section]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So from the outside this is pretty much the same as in Joomla 3. However, note that the <tt>$prefix</tt> parameter in calls to <tt>getModel</tt> etc is subtly different
* in Joomla 3 this referred to a prefix to be applied to the classname – in the tutorial code we used 'HelloWorldTable' as the prefix part of the 'HelloWorldTableHelloWorld' classname.
* in Joomla 4 this refers to a prefix higher up the classname path, and should be set to either 'Site' or 'Administrator' (the capital letter at the start is optional), depending on whether you want the class under 'Robbie\Component\Helloworld\Site' or 'Robbie\Component\Helloworld\Administrator'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVC Factory class is now the Joomla recommended way to create the controller, view, model and table classes, by using the eg <tt>getModel()</tt> method, and the use of <tt>getInstance()</tt> for these classes is now deprecated. However, the use of these functions is restricted:
* in the controller class you can call <tt>$this->getView($viewname, $viewtype, $prefix, $config)</tt> to create a view and <tt>$this->getModel($modelname, $prefix, $config)</tt> to create a model.
* in the view class you can call <tt>$this->getModel($modelname)</tt>, but only for models which the controller has previously defined using <tt>$view->setModel($modelname, $default)</tt>. It doesn't create a new model instance.
* in the model class you can call <tt>$this->getTable($tableclass, $prefix, $options)</tt> to create a table instance. Controllers and views can access the table classes in this way, by going via a model.
These restrictions do have an impact on moving away from using <tt>getInstance()</tt>, and indeed in Joomla 4.2.6 you will still find several <tt>getInstance()</tt> calls within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Factory Classes===
Several other Factory classes have been introduced in Joomla 4, enabling you to get instances of core classes such as Form, User, CacheController, etc, usually by calling a createSomething function on the Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Associated with the Factory class is a FactoryInterface, a PHP Interface which specifies the key functions which the Factory class must implement. For example, with <tt>libraries/src/Categories</tt> we have:
* CategoryFactoryInterface – which specifies the <tt>createCategory</tt> function
* CategoryFactory implements CategoryFactoryInterface – which provides the <tt>createCategory</tt> function.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Dependency Injection ==
===Overview===
The DI container is one of the significant new additions to Joomla 4. It's basically a repository of key-value pairs where:
* the key is a string which is the name of a class or interface
* the value is an instance of the relevant class, or a function that returns an instance of that class.
You put things into the container using <tt>set()</tt> passing:
* the class name or interface name
* a function which returns an instance of the class (or an instance of the class)
* a boolean defining whether the class instance may be shared or not
* a boolean defining whether this entry into the DI container is protected or not (an error will be raised if you try to overwrite a protected entry by calling <tt>set()</tt> again using the same key).
The function <tt>share()</tt> is basically the same as <tt>set()</tt> with the <tt>shared</tt> boolean set to true.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You get things out of the container by calling <tt>get()</tt> passing the key of the resource you want. The container will
* find the key in the container
* if the value isn't already a class instance, then it will run the associated function to generate an instance of the class
* if the resource is shared, it will store the class instance, so that on subsequent invocations of <tt>get()</tt> it can just return the instance
* return the class instance to you
You can also define aliases for each key in the container, which means that you call <tt>get()</tt> passing either the key or an alias of the key.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The DI container is initialised in <tt>library/src/Factory.php createContainer()</tt> which results in the <tt>register()</tt> function being called in each of the class files in <tt>libraries/src/Service/Provider</tt>. By looking through those files you can see what gets put into the DI container upon initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===JConfig Example===
Let's consider the example of JConfig which holds the system global configuration. If you look inside <tt>libraries/src/Service/Provider/Config.php</tt> then you'll see the <tt>register()</tt> function and that it stores in the DI container a resource with:
* key = 'JConfig'
* value = an anonymous function - which loads what's in <tt>configuration.php</tt> into a <tt>Registry</tt> object, and returns it
* shared flag = true (because the <tt>share()</tt> function is used)
* protected flag = true
Then when you do
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$config = $container->get('JConfig');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will run the anonymous function and return the Registry object to you. As the 'shared' boolean is set it will also store a copy of the class instance locally in the container to be returned on subsequent calls of <tt>get('JConfig')</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Justification===
What's the point of all this?
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The advantage of dependency injection is that it allows classes to be easily mocked for testing. The file <tt>libraries/src/Service/Provider/Config.php</tt> can be replaced to return to a DI container <tt>get()</tt> call a mock class instead of the usual <tt>JConfig</tt>. This is in comparison to Joomla 3 where <tt>Factory::getConfig()</tt> code directly reads the <tt>configuration.php</tt> into a Registry structure and returns it – which makes it harder to mock.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The [https://api.joomla.org/cms-4/classes/Joomla-CMS-Factory.html Factory API] has several functions which are marked as deprecated with advice to get the object from the DI container instead.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Several of the other Factory classes (eg Form, Language, Menu, User) are in the DI container – so that we can get an instance of them via eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Factory::getContainer()->get('Joomla\CMS\Toolbar\ToolbarFactoryInterface')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to get a Toolbar instance. However, this only works for singleton classes which aren't specific to the needs of a particular extension. We'll see shortly how to make it work for class instances which need to be specific to a component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As indicated above, Joomla is moving away from using the class static <tt>getInstance()</tt> functions. We can see now that this is not only because it's more pure from an object oriented perspective. But also creating class instances from the DI container, or from Factory objects which are obtained from the DI container, builds in the dependency injection which allows classes to be more easily mocked, and hence more easily tested.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==services/provider.php==
We're now finally in a good position to understand what's happening in our services/provider.php file, and we'll explore this by walking through what happens whenever this line in libraries/src/Component/ComponentHelper.php <tt>renderComponent</tt> is run:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is run whenever Joomla has worked out which component is to be run on the requested web page, and it wants to run that component to capture its output.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 1 Create Child DI Container===
Joomla first creates another DI container (initially empty) just for this component, and links it to the main DI container via a parent field in the child DI container structure.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Now whenever <tt>set()</tt> is called on this DI container the key-value pair is inserted into the child container. Whenever <tt>get()</tt> is called on it, the resource is obtained from the child container, but if it's not found there then the parent container is searched also.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 2 Run register() in provider.php===
Next we encounter these lines (in <tt>libraries/src/Extension/ExtensionManagerTrait.php</tt>), where <tt>$path</tt> contains the path of our helloworld admin/services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$provider = require_once $path;
// Check if the extension supports the service provider interface
if ($provider instanceof ServiceProviderInterface) {
$provider->register($container);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here we see 3 things:
# our provider.php should return some object (so that <tt>$provider</tt> gets set to something)
# what is returned should implement ServiceProviderInterface (you can see in <tt>libraries/vendor/joomla/di/src/ServiceProviderInterface.php</tt> what is expected)
# the code then runs the <tt>register</tt> function on that object, passing as a parameter the child DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider a minimal version of our provider.php file. This would actually support steps in the Joomla 3 tutorial up to and including the [[J3.x:Developing an MVC Component/Adding AJAX|Adding Ajax step]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {

public function register(Container $container): void
{
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
}
};
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As you can see from the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
this file does indeed return something – it returns an instance of an anonymous class, one that implements <tt>ServiceProviderInterface</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it's not sufficient to just provide the <tt>register</tt> function in the class, we also need to explicity state that the class implements <tt>ServiceProviderInterface</tt>. This now happens in several places in Joomla, so if you're debugging your component and wondering why a function you expect to be called isn't being called, then check to make sure that you don't have to explicitly add the appropriate <tt>implements <Interface></tt> clause to your class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Next we look at the 3 lines in the <tt>register</tt> function
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3a Registering our MVC Factory===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here our <tt>MVCFactory</tt> refers to <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in libraries/src/Extension/Service/Provider/MVCFactory.php, and you should have a look at this file. This is a file similar to our provider.php file, but it's a named class, and it doesn't return anything. When we do:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
new MVCFactory('\\Robbie\\Component\\Helloworld')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it creates an instance of this class, and in the constructor it stores locally in <tt>$this->namespace</tt> our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>registerServiceProvider</tt> function then calls the <tt>register</tt> function of this instance, which runs (in its minimalist form):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
MVCFactoryInterface::class,
function (Container $container) {
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
return $factory;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So what gets entered into our child DI container is a key-value pair with:
* key = MVCFactoryInterface::class (this is just a shorthand form to obtain a string of the fully qualified name – ie 'Joomla\CMS\MVC\Factory\MVCFactoryInterface')
* value = a function which returns an instance of <tt>\Joomla\CMS\MVC\Factory\MVCFactory</tt>.
This is our MVCFactory class which generates our Controllers, Views, Models and Tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Notice that we're passing our namespace as a parameter <tt>$this->namespace</tt>. Because this function is a closure, this variable will still be available when we run this function later, and when the MVCFactory class is instantiated the namespace will be passed into the constructor, stored locally, and then subsequently used to form the fully qualified names of our Controllers, View, etc. So this is how we get instantiated the MVCFactory class which is specific to our component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3b Registering the Dispatcher Factory===
Careful: ComponentDispatcherFactory refers to two different classes here!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This ComponentDispatcherFactory is Joomla\CMS\Extension\Service\Provider\ComponentDispatcherFactory in libraries/src/Extension/Service/Provider/ComponentDispatcherFactory.php. Similar to the above, the ComponentDispatcherFactory service provider class stores locally our namespace, and then when <tt>register</tt> is called it executes:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentDispatcherFactoryInterface::class,
function (Container $container) {
return new \Joomla\CMS\Dispatcher\ComponentDispatcherFactory($this->namespace,$container->get(MVCFactoryInterface::class));
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so a second entry is added to the child DI container with:
* key = ComponentDispatcherFactoryInterface::class
* value = a function which returns an instance of the ComponentDispatcherFactory (the other ComponentDispatcherFactory class!), where the class constructor will be passed the namespace ('\\Robbie\\Component\\Helloworld') and an MVCFactory instance, retrieved from the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that the code
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->get(MVCFactoryInterface::class)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
will get from the container an entry with key = 'Joomla\CMS\MVC\Factory\MVCFactoryInterface' – which is what we entered into the container in step 3a – and will run the function associated with this key, and then return the object which this function returns. This returned object will be an instance of '\Joomla\CMS\MVC\Factory\MVCFactory', constructed using our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3c Including the Extension===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will put into the child DI container a key-value pair with
* key = ComponentInterface::class
* value = the function which will create an instance of our <tt>HelloworldComponent</tt> (ie our Extension class), and pass into the constructor an instance of the ComponentDispatcherFactory class, retrieving what was entered into the child DI container in Step 3b.
It will call <tt>$container->get(MVCFactoryInterface::class)</tt>, getting an MVC Factory instance from what was entered into the DI container in Step 3a.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It will then associate our component with this MVC Factory instance via the <tt>setMVCFactory</tt> call. Significantly this will then allow our component to access this instance later, via a call to <tt>getMVCFactory</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3 Summary===
We have now got 3 entries in our child DI container, keyed by
* key = MVCFactoryInterface::class, value is a function returning an MVCFactory instance
* key = ComponentDispatcherFactoryInterface::class, value is a function returning a ComponentDispatcherFactory instance
* key = ComponentInterface::class, value is a function returning our HelloworldComponent, an instance of our Extension class.
The important aspect is that these entries are all aware of our namespace '\Robbie\Component\Helloworld' and will return instances of these classes which are specific to our Helloworld component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 4 Retrieving from the DI Container===
Joomla will then execute the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $container->get($type);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
where <tt>$type</tt> contains 'Joomla\CMS\Extension\ComponentInterface'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This starts the process of retrieving from the DI container the 3 entries which we put in, and will run our code in services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We end up with a HelloworldComponent instance, which has:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. a ComponentDispatcherFactory instance passed into the constructor, and which is saved locally by the constructor code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function __construct(ComponentDispatcherFactoryInterface $dispatcherFactory)
{
$this->dispatcherFactory = $dispatcherFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This code is in libraries/src/Extension/Component.php, in the class which our HelloworldComponent extends, via the class MVCComponent).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. an MVC Factory instance, stored by the HelloworldComponent <tt>setMVCFactory</tt> call
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 5 Call boot() on our Component===
Joomla calls:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
if ($extension instanceof BootableExtensionInterface) {
$extension->boot($container);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will call <tt>boot</tt> within our HelloworldComponent, and allows us to perform some initialisation within our component. We'll return to this later, in the section on [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#HTML_Snippets|HTML snippets]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note again that Joomla checks that our HelloworldComponent class implements BootableExtensionInterface before calling <tt>boot</tt>. It's not sufficient to just provide the <tt>boot</tt> function, we have to explicitly declare that our HelloworldComponent implements the interface.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 6 Get the Dispatcher===
Returning to our key line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
we have now accomplished the first part <tt>bootComponent($option)</tt>, and this has returned our HelloworldComponent instance. Now we call <tt>getDispatcher($app)</tt> on this instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This code is also in libraries/src/Extension/Component.php, in the Component class which our HelloworldComponent extends:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function getDispatcher(CMSApplicationInterface $application): DispatcherInterface
{
return $this->dispatcherFactory->createDispatcher($application);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We call <tt>createDispatcher</tt> on our ComponentDispatcherFactory class instance which we saved in Step 4. This code is in libraries/src/Dispatcher/ComponentDispatcherFactory.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createDispatcher(CMSApplicationInterface $application, Input $input = null): DispatcherInterface
{
$name = ucfirst($application->getName());

$className = '\\' . trim($this->namespace, '\\') . '\\' . $name . '\\Dispatcher\\Dispatcher';

if (!class_exists($className)) {
if ($application->isClient('api')) {
$className = ApiDispatcher::class;
} else {
$className = ComponentDispatcher::class;
}
}

return new $className($application, $input ?: $application->input, $this->mvcFactory);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code checks if we have our own Dispatcher class (our Helloworld tutorial doesn't, but <tt>com_users</tt> for example has its own). So it creates a <tt>ComponentDispatcher</tt> instance, and passes into its constructor the MVC Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that this ComponentDispatcherFactory instance is what was instantiated when it was retrieved from our child DI Container (from being inserted in step 3b), and hence it already knows about our namespace, and has a pointer to our MVCFactory class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 7 call dispatch()===
This is the final aspect to our line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We're now back to what was described in the Dispatcher section above, except that now we can see that this Dispatcher instance has a pointer to our MVC Factory instance (which knows about our namespace prefix), so when the Dispatcher code wants to create a Controller it can use that MVC Factory instance to instantiate it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's been a long and tortuous journey to get here, but the significant thing is that all of our key class instances have been obtained via the DI Container. If we want to mock out any of those classes for testing then all we need to do is replace the relevant services/provider file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Javascript and the Web Asset Manager ==
The web asset manager has been introduced in Joomla 4 and is well documented [[J4.x:Web_Assets|here]]. It provides a much-improved means of managing JS and CSS resources, and a framework for handling their dependencies.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Component Javascript and CSS files should now be stored in the <tt>media</tt> folder, and the Web Asset Manager used to register them and output them on specific web pages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following assets have been registered in the tutorial <tt>joomla.asset.json</tt>, and you should have a look at that file now.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.validate-greeting===
This is the code for client validation of the helloworld greeting field using a regex, and it is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it is dependent upon jQuery and the Joomla <tt>form.validator</tt> script, so those both get included as dependencies.
If we didn't have specific validation on our form then we would need to include explicitly the <tt>form.validator</tt> script in order for the basic Joomla field validation to be included, eg in the tmpl file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->document->getWebAssetManager()->useScript('form.validate');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that this requires us to have a <tt>class="form-validate"</tt> on the </tt><form></tt> html element.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.fix-permissions-ajax-call===
This is the code which copies the value from the greeting field into the title field, so that the Ajax calls setting the permissions work correctly. The js code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.enable-tooltips===
This is the code which enables bootstrap tooltips to operate, including allowing them to include html code. It's used to display the image as a tooltip within the admin <tt>helloworlds</tt> view.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.openstreetmap===
This is defined as a preset, comprising the helloworld js and css code for the map display, as well as the dependency named 'com_helloworld.openlayers' relating to the openlayers CSS and js code. The code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.admin-helloworlds-modal===
This is the js code for selecting an individual helloworld record within a modal, and passing its details to the form in the main window. Its code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===submitbutton.js===
In the Joomla 3 code we introduced in [[Special:MyLanguage/J3.2:Developing_an_MVC_Component/Adding_verifications|Adding Verifications]] a js file which controlled when the form was submitted. It differentiated between buttons such as <tt>Save</tt> (which submitted the form) and <tt>Cancel</tt> (which didn't).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 there is a more sophisticated version of <tt>Joomla.submitbutton</tt> (found in media/system/js/core.js) which uses the CSS classes which the Toolbar functionality sets on the buttons to determine whether the form should be submitted or not. And you can override whether the validation is performed by adding a third parameter to the <tt>submitbutton</tt> js call. For example, to avoid validation being performed when a button is clicked you can set on the button element:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
onclick="Joomla.submitbutton('controller.method', '', false)"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As this is sufficient for what we need in the tutorial, the custom <tt>submitbutton.js</tt> has been removed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Interaction with other components ==
The way that Joomla interacts with components has changed in Joomla 4. In general the Joomla functionality will boot the component using something like:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $app->bootComponent($option);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and in our case this will return an instance of the <tt>HelloworldComponent</tt> class. It will then try to call certain methods on our extension object, as described below.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_categories===
In the backend the helloworld functionality can display to the administrator
* the view of the helloworld messages
* the view of the helloworld categories
The categories view is generated by <tt>com_categories</tt>, and in Joomla 4 these component categories views display the number of component records there are for each of the possible published status values. To do this the categories component executes the following code (in administrator/components/com_categories/src/Model/CategoriesModel.php):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof CategoryServiceInterface) {
$component->countItems($items, $section);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So our HelloworldComponent must:
* declare that it implements <tt>CategoryServiceInterface</tt>
* provide an implementation of <tt>countItems</tt>
We provide <tt>countItems</tt> by using a trait in libraries/src/Categories/CategoryServiceTrait.php, which (with the assistance of a helper function) does the query on our behalf. We just need to tell it:
* the name of our table – in the callback <tt>getTableNameForSection</tt>
* the database field in which we hold the published status – in <tt>getStateColumnForSection</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_associations===
Remember that <tt>com_associations</tt> is the component which is run whenever you click on Multilingual Associations in the admin backend.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Under Joomla 3 we provided an associations helper file as described in [[J3.x:Multilingual Associations/Developers|Multilingual Associations/Developers]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the helper file remains basically the same, but <tt>com_associations</tt> primarily tries to find the helper file via the extension class; here's the code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($extensionName);
if ($component instanceof AssociationServiceInterface) {
return $component->getAssociationsExtension();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's expecting that:
* the extension (HelloworldComponent in our case) implements <tt>AssociationServiceInterface</tt>
* its <tt>getAssociationsExtension</tt> method returns the helper class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The easiest thing would be just to code <tt>getAssociationsMethod</tt> and get it to return <tt>new AssociationsHelper</tt>. However, we follow the Joomla 4 principle of putting key classes into the Dependency Injection container, and retrieving them later, by having the following code in our services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(AssociationExtensionInterface::class, new AssociationsHelper());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The above line puts a key-value pair into our child DI container
* key = 'Joomla\CMS\Association\AssociationExtensionInterface'
* value is an instance of our <tt>AssociationsHelper</tt> class.
We then retrieve it later and use the setter:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setAssociationExtension($container->get(AssociationExtensionInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so that whenever
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getAssociationExtension()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
is called it returns the <tt>AssociationsHelper</tt> class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_fields===
<tt>com_fields</tt> is the component which is run when an administrator clicks on the Fields or Field Groups menuitem within the backend, and this functionality was included in the [[J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Adding Custom Fields]] tutorial step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>com_fields</tt> component stores the custom fields and field groups for all components in the database tables <tt>#__fields</tt> and <tt>#__fields_groups</tt>, and these tables are partitioned into "sections", one section per component. For our helloworld component the section is named "helloworld".
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within the section we have 2 "contexts" – one for the helloworld messages (called "com_helloworld.helloworld") and one for the helloworld categories (called "com_helloworld.categories"). This enables us to define custom fields for both our helloworld records and helloworld category records.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When <tt>com_fields</tt> runs it checks both the section and contexts at various times. For example, when an admin selects Helloworld / Fields on the backend then <tt>com_fields</tt> checks the section which was defined in the menuitem in the manifest file (see [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Sidebar|below]]). Here's the code in administrator/components/com_fields/src/Helpers/FieldsHelper <tt>extract</tt> function:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
$newSection = $component->validateSection($parts[1], $item);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And when <tt>com_fields</tt> wants to display the little dropdown menu of contexts (to allow the administrator to set custom fields on either helloworld items or categories) it calls (in administrator/components/com_fields/src/Fields/FieldcontextsField.php <tt>getOptions()</tt>):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
return $component->getContexts();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So it's clear that our component extension class must :
* implement <tt>FieldsServiceInterface</tt>
* provide the <tt>validateSection</tt> and <tt>getContexts</tt> methods
So in upgrading to Joomla 4 we've just moved those two methods from the helper file to the extension class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Router===
The Joomla router will access our custom router code:
* whenever it wants to parse an SEF route which it has identified as belonging to <tt>com_helloworld</tt>
* whenever it wants to build an SEF route from a call to <tt>Route::_()</tt> where the option = "com_helloworld".
To find our custom router it will:
* boot the <tt>com_helloworld</tt> extension
* check that the extension implements <tt>RouterServiceInterface</tt>
* call <tt>createRouter</tt> on our extension instance
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In our services/provider.php file we have (careful again - 2 different RouterFactory classes!):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new RouterFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which from libraries/src/Extension/Service/Provider/RouterFactory.php puts into our child DI container an entry with:
* key = "Joomla\CMS\Component\Router\RouterFactoryInterface"
* value is a <tt>\Joomla\CMS\Component\Router\RouterFactory</tt> instance, constructed with our namespace
We then retrieve this in the line in our services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setRouterFactory($container->get(RouterFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And then within our extension class we have
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use RouterServiceTrait;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which includes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function setRouterFactory(RouterFactoryInterface $routerFactory)
{
$this->routerFactory = $routerFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which stores the <tt>routerFactory</tt> locally and
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return $this->routerFactory->createRouter($application, $menu);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which provides our extension's <tt>createRouter</tt> call that the Joomla Router expects.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>routerFactory::createRouter</tt> method is in libraries/src/Component/Router/RouterFactory.php. It looks for a class in our site namespace </tt>Robbie\Component\Helloworld\Site\Service\Router</tt> which is in our site/src/Service/Router.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
At this stage we have a choice, we can either:
* provide a traditional custom router, with the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions, or
* use the more modern <tt>RouterView</tt> mechanism.
By default in the upgraded tutorial code the Router View option has been coded in the Router.php file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====RouterView====
In the <tt>RouterView</tt> case the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions are in the <tt>RouterView</tt> class which we extend, and we provide
* a constructor with router view configuration
* methods <tt>getHelloworldId</tt> and <tt>getCategoryId</tt> which are used to obtain from the SEF segment the <tt>id=</tt> and <tt>catid=</tt> parts of the internal URL
* methods <tt>getHelloworldSegment</tt> and <tt>getCategorySegment</tt> which are used to generate segments for the SEF URLs based on the <tt>id=</tt> and <tt>catid=</tt> parts within the <tt>Route::_()</tt> parameter.
Unfortunately there doesn't seem to be a good guide to configuring the RouterView class. There is some documentation available [https://www.dionysopoulos.me/book/com-router-routerview.html here].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the helloworld tutorial we have 3 views
* a view which displays a single helloworld record
* a view which displays a single helloworld category, and the helloworld records associated with it
* a view which displays the frontend form
So we need 3 Router Views associated with these.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'form' view doesn't have an associated id or catid so it's just a fixed URL, and the router just has to convert between the alias of the form menuitem and the Itemid / view parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'category' view has an associated id (of the category record), and an SEF URL will use the category path down the Categories Nested Set table structure, hence <tt>setNestable()</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'helloworld' view has an associated id (of the helloworld record), and in an SEF URL in the category view the helloworld record alias is added to the category path (hence <tt>setParent()</tt>). But although the helloworld records use a Nested Table structure in the database, the URLs just include the alias of the single record, and so <tt>setNestable()</tt> is not used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There doesn't seem to be a way to configure an additional SEF URL scheme which just displays a helloworld segment, without a category segment.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====Traditional Router====
To use the traditional router in the tutorial code you should uncomment the function in the extension class:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return new TraditionalRouter($application, $menu, $this->categoryFactory, $this->getDatabase());
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will cause the code in site/src/Service/TraditionalRouter.php to be used. However, changes in the Joomla 4 router mean that the interaction between it and the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> methods have changed. This requires significant changes to the <tt>preprocess</tt> and <tt>build</tt> methods, but only a minor change to <tt>parse</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. Previously Joomla injected into the <tt>$query</tt> parameters the <tt>Itemid</tt> of the active menuitem (ie the id of the menuitem the user is currently on). This meant that we had to change the <tt>Itemid</tt> for links generated by the Language Switcher module (which generates the flags for switching between languages), and these links being associated with a different language would obviously use a different <tt>Itemid</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 you get an <tt>Itemid</tt> in the <tt>$query</tt> parameters only if you specified an <tt>Itemid</tt> in the <tt>Route::_()</tt> call. For others you have to work out which menuitem to use yourself, by using the Joomla menu/menuitems API to find details of the configured menuitems, and work out which to use based on the other <tt>$query</tt> parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You do this in the <tt>preprocess</tt> method, and then the <tt>Itemid</tt> you set will be passed in the <tt>$query</tt> parameters to the <tt>build</tt> method.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. In some instances the <tt>Route::_()</tt> URL you're generating matches exactly one of the configured menuitems on the site. In this case the <tt>$query</tt> parameters will match those in the menuitem <tt>"query"</tt> array, and you have to remove explicitly remove the 'view', 'id' and 'catid' parameters so that they don't appear as URL query parameters after the normal SEF URL of the menuitem.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
3. The custom router will be used to build the URLs for the helloworld menuitems shown in menus on the page. For these the <tt>$query</tt> parameters will have the view / id / catid associated with those menuitems. Note that even if you remove these in your <tt>preprocess</tt> method, Joomla will inject them again into the <tt>$query</tt> array when it's passed to your <tt>build</tt> method, so you'll have to remove them again there!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
4. In the <tt>parse</tt> method you now have to unset the <tt>$segments</tt>, or else Joomla will return an HTTP 404 (page not found). Otherwise <tt>parse</tt> works as before.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
5. I've implemented <tt>build</tt> only for when Multilanguage is enabled on the site. If it's not enabled an empty <tt>$segments</tt> array is just returned, without doing unset on any of the <tt>$query</tt> parameters, so these will appear as URL parameters after the SEF URL. Also it's not coded properly to deal with items which have language set to <tt>*</tt>. These include helloworld records, categories or menuitems (eg the helloworld form).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that the <tt>categoryFactory</tt> is also now passed to the router. This is so that it can be used instead of <tt>Categories::getInstance()</tt> to get access to the Categories API calls.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_tags===
Whenever we setup a Tags Menu Item Type which displays items having a given tag or tags, then <tt>com_tags</tt> displays those items as links, and uses route helper functions to generate the URL parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The route helpers <tt>com_tags</tt> expects to find loaded into the data of the <tt>#__content_types</tt> table, in the router field, and these have been set to:
* For links to helloworld items: 'HelloworldHelperRoute::getHelloworldRoute'
* For links to helloworld categories: 'HelloworldHelperRoute::getCategoryRoute'
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, <tt>com_tags</tt> doesn't boot the helloworld extension to get access to these, but rather seeks to find them in site/helpers/route.php, so that's where they continue to be.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(We also had a <tt>getCategoryRoute</tt> which was used by <tt>com_categories</tt> in administrator/components/com_categories/src/Helper/CategoryAssociationHelper. When a category was displayed on the frontend then the Language Switcher module (now Language Filter) used this function to generate the links to the Associated Categories. Our <tt>getCategoryRoute</tt> previously was necessary to insert the <tt>lang=<language tag></tt> parameter into the link URL, but since [https://github.com/joomla/joomla-cms/pull/39358 this change] the calling function inserts the <tt>lang</tt> parameter itself, so our <tt>getCategoryRoute</tt> function for this purposes is superfluous.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Deprecated APIs ==
With Joomla 4 there are a number of methods which are deprecated, with a view to removing them in Joomla 5.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Factory Methods===
Many of the <tt>Factory</tt> methods for getting singleton classes have been deprecated in favour of getting these classes via the DI container, and it appears that only class instances which should be obtained via Factory methods are:
* the Application – <tt>Factory::getApplication()</tt>
* the DI container – <tt>Factory::getContainer()</tt>
Here is a list of what has been changed in the tutorial code. Note that with some calls there are variants available, through the aliases defined in the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDbo'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\Database\DatabaseInterface;
...
$db = Factory::getContainer()->get(DatabaseInterface::class);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, in many classes the database instance is more easily (and efficiently) returned via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$db = $this->getDatabase();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is available in Model classes, custom field definitions, etc.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getUser();'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get the current user use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = Factory::getApplication()->getIdentity()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get a different user (whose id you know):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\User\UserFactoryInterface;
...
$user = Factory::getContainer()->get(UserFactoryInterface::class)->loadUserById($userid);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within models which extend Joomla\CMS\MVC\Model\BaseDatabaseModel and views which extend Joomla\CMS\MVC\View\HtmlView you can also use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = $this->getCurrentUser()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDocument()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication()->getDocument()</tt>, or within a View you can use <tt>$this->document</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getConfig()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Two options have been used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->getConfig()</tt> – returns a Registry object containing all the configuration values
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->get('access')</tt> – returns the value of the 'access' configuration parameter
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getLanguage()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication->getLanguage()</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JFactory::getCache('com_example', <type>)'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Cache\CacheControllerFactoryInterface;
...
Factory::getContainer()->get(CacheControllerFactoryInterface::class)->createCacheController(<type>)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated getInstance Methods===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general <tt>getInstance()</tt> calls have been deprecated in favour of obtaining the instance, either via a factory class or via the DI container. For example, within a controller you can use <tt>getModel()</tt> repeatedly to get different models (passing the relevant model names), which results in the MVCFactory class creating the Model classes.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there are currently some problems with replacing some getInstance calls. I expect that the Joomla team will resolve these issues over the course of the Joomla 4 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Categories::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is deprecated with a notice: "Use the ComponentInterface to get the categories". This means that we should get the category factory instance via the DI container. This is done in our services/provider.php by the lines:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Extension\Service\Provider\CategoryFactory;
...
$container->registerServiceProvider(new CategoryFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to put into our child DI container the closure which will create a Joomla\CMS\Categories\CategoryFactory instance, constructed with our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when our HelloworldComponent (Extension) instance is created:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We can then use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getCategoryFactory()->createCategory();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to create our Categories object, and in this way get access to the Categories APIs.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This createCategory method creates the instance by looking for the \\Site\\Service\\Category class within our namespace. The constructor in our class sets our extension ('com_helloworld') and table ('#__helloworld') and calls the parent Categories constructor with these options).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this means that the section of our code where we want to use the Categories APIs must have a pointer to a CategoryFactory instance. In the tutorial code for Joomla 3 there are 2 places where <tt>Categories::getInstance</tt> is used:
* in the custom router code, to handle building and parsing of the category parts of the SEF URL
* in the site category model, where the Categories APIs are used to obtain details of categories to display on the page.
For the custom router code, the CategoryFactory instance is passed as a parameter to the TraditionalRouter constructor so that it can be used there.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, the site category model is instantiated by the MVCFactory instance, and it doesn't make available a CategoryFactory instance. So in this category model the calls to <tt>Categories::getInstance()</tt> have been left, and you can still find a number of calls to <tt>Categories::getInstance</tt> within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Categories::getInstance()</tt> itself solves the problem of access to a CategoryFactory instance by rebooting our component again to get a pointer to our Extension instance, and thus to the category factory instance. However, this involves a lot of work, so <tt>getInstance</tt> caches locally the Categories instances and just returns one of them if it can.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Pushing the CategoryFactory to the model'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there is a way to get access to the CategoryFactory instance, by defining your own MVCFactory class, and pushing the instance down through it to the model. Here's how you can go about it:
* Define your own SuperMVCFactory class, which extends the Joomla Joomla\CMS\MVC\Factory\MVCFactory class, but which has a means of storing a CategoryFactory instance. Use the CategoryServiceTrait in libraries/src/Categories/CategoryServiceTrait.php
* Create your own version of the file libraries/src/Extension/Service/Provider/MVCFactory.php, which is the 'provider.php' like file for MVCFactory, but change it so that:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
becomes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new <namespace>\SuperMVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and include
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla creates a model such as CategoryModel it passes in its constructor the MVCFactory instance (so that the model can call createTable on it), so you can access it via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will return your SuperMVCFactory instance. So in this way within the model you can access the CategoryFactory, and use it to create the Categories instance via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()->getCategory() (from the CategoryServiceTrait)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you can get this working you can congratulate yourself on a good understanding of Joomla namespacing and dependency injection! A similar approach to address a similar problem is described [https://www.dionysopoulos.me/book/com-router-push-dependencies.html here]. If you get stuck you can always view the solution by viewing the github tutorial code selecting the branch [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial/tree/push-category-factory-to-mvc push-category-factory-to-mvc].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Table::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There are a couple of calls to <tt>Table::getInstance()</tt> within admin/src/Helper/AssociationsHelper.php in <tt>getItem()</tt>:
* <tt>Table::getInstance('Helloworld', 'Robbie\\Component\\Helloworld\\Administrator\\Table\\')</tt> to get an instance of our HelloworldTable class.
* <tt>Table::getInstance('Category')</tt> to get an instance of the Category table in libraries/src/Table/Category.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We could actually arrange for the AssociationsHelper class to get injected with the MVCFactory instance, so that the HelloworldTable class could be instantiated by it. However, we couldn't use the helloworld MVCFactory instance to create the Category table instance, as it's not in the helloworld namespace, and our MVCFactory instance creates table instances within our namespace only.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Toolbar::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The tutorial code uses <tt>Toolbar::getInstance()</tt> to get a Toolbar instance onto which it can attach the batch button in the helloworlds form. The Toolbar API documentation seems to suggest that we should replace
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Toolbar::getInstance('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
with
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this currently won't work. The problem is that all the other Joomla code uses <tt>getInstance('toolbar')</tt> to access the Toolbar class, including the code in administrator/modules/mod_toolbar/mod_toolbar.php which renders the toolbar. The <tt>getInstance</tt> method keeps track of the Toolbar instances in a local static variable <tt>$instances</tt>, and returns the same Toolbar instance on repeated invocations.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you use the second approach above you will get a Toolbar instance, but it won't be the same Toolbar instance as is stored in the <tt>$instances</tt> variable. It won't then be picked up by the Toolbar module, and so won't be rendered on the form.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Error Handling===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead of
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
JError::raiseError(500, implode('<br />', $errors));
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
you should throw an exception, using or extending one of the standard [https://www.php.net/manual/en/spl.exceptions.php PHP exceptions], eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
throw new \Exception(implode("\n", $errors), 500);
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===jimport===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
jimport is no longer necessary in order to get access to Path or File classes. All of the Joomla classes are found by the autoloader.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Methods related to Javascript===
'''JHtml::_('behavior.framework');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general, the use of JHtml::_('behavior.xxx') is now obsolete, and calls using this have been removed in the tutorial code. The 'behavior.framework' call referred to including jQuery. Where jQuery is necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.formvalidator');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by the <tt>form.validate</tt> javascript asset, and where necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It can also be included directly using the web asset manager:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$wa->useScript('form.validate')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.tooltip')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This no longer exists, and tooltips don't seem to be enabled by default in Joomla 4. This is replaced by the code in media/js/enable-tooltips.js.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('formbehavior.chosen')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The chosen js library seems to be no longer used, and using it will cause formatting issues if you include it in your tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''sortable'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The sortable js library provided the ability in the helloworlds view to drag rows up and down to change the ordering of the records. This has been replaced in Joomla 4 by the draggable library. To enable it you have to set:
* <tt>HTMLHelper::_('draggablelist.draggable');</tt>
* on your <tt><tbody></tt> element define the table in which dragging occurs and the URL of the Ajax call to set the ordering:
<source lang="php">
<tbody<?php if ($saveOrder) : ?> class="js-draggable" data-url="<?php echo $saveOrderingUrl; ?>" data-direction="<?php echo strtolower($listDirn); ?>" data-nested="true"
<?php endif; ?>>
</source>
* on your <tt>tr</tt> element within your <tt><tbody></tt> define the group of records in which dragging occurs (by category below):
<source lang="php">
<tr class="row<?php echo $i % 2; ?>" data-draggable-group="<?php echo $row->catid; ?>">
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==HTML Snippets==
There are two places in the tutorial where reusable snippets of HTML have beeen defined:
* For displaying the item associations in the helloworlds view:
* For displaying the position latitude and longitude fields within the batch options in the helloworlds view
These used different approaches:
* the item associations display was coded in an html helper file in admin/helpers/html/helloworlds.php and accessed via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JHtml::_('helloworlds.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
in the helloworlds tmpl file. (Although it did use a common joomla layout file underneath).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* the position field was coded as a layout in layouts/position.php, and rendered using
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JLayoutHelper::render('position', array());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When should you use one approach rather than the other? A significant difference is that layouts are designed so that an administrator can override them, via the Templates / Details and File functionality. So, for example, an administrator could change the position to show the longitude before the latitude. So it's more appropriate for layouts to focus on the html elements rather than functional logic, and particularly if you would want to allow an administrator to override the layout.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The layouts functionality in Joomla 4 hasn't changed significantly. One correction which has been made in the updated tutorial code has been to include the position.php file in a subfolder of layouts, ie in admin/layouts/helloworld/position.php rather than admin/layouts/position.php. It appears that in the Templates / Details and Files / Create Overrides tab the <tt>com_helloworld</tt> layout appears only if it's in a subfolder of /layouts.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>JHtml::_()</tt> approach has changed in Joomla 4. Rather than Joomla having to look for a helper file when it encounters something it doesn't recognise, it's expected that you should register such classes beforehand, and you do this by obtaining an instance of the Joomla\CMS\HTML\Registry class (it's a singleton class) and then calling <tt>register</tt> on it, passing
* the key you want to use
* an instance of your class
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Joomla pattern is to put the code in a file admin/src/Service/HTML/AdministratorService.php, and we have to ensure that our key won't be used elsewhere within Joomla, so in the tutorial we've used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Robbie\Component\Helloworld\Administrator\Service\HTML\AdministratorService;
...
register('helloworldadministrator', new AdministratorService)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when we call:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo HTMLHelper::_('helloworldadministrator.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will result in Joomla calling the <tt>association</tt> method in our class, passing the <tt>$row->id</tt> parameter.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We should get the Joomla\CMS\HTML\Registry class from the Dependency Injection container. Joomla components generally do this via their services/provider.php file, and then call <tt>register</tt> within the extension's <tt>boot</tt> function, described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Step_5_Call_boot.28.29_on_our_Component|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The extension uses HTMLRegistryAwareTrait which contains <tt>setRegistry</tt> and <tt>getRegistry methods</tt>. In services/provider.php there is:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\HTML\Registry;
...
$component->setRegistry($container->get(Registry::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets 'Joomla\CMS\HTML\Registry' out of the DI container and stores it within the
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
private $registry;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
variable of the HTMLRegistryAwareTrait included in the extension.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the <tt>boot</tt> function it calls
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getRegistry()->register('helloworldadministrator', new AdministratorService);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets the registry and calls <tt>register</tt> as required.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that <tt>boot</tt> is called whenever Joomla dispatches <tt>com_helloworld</tt>, both for the site and administrator, so it would make sense to check the Application <tt>isClient</tt> before deciding whether to register the HTML Helper service or not. This hasn't been included in the tutorial code though.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==User Interface Changes==
Joomla 4 introduced new templates, atum on administrator and cassiopeia on site, and in particular the administrator is built upon some UI rearrangements which affect the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Sidebar===
In Joomla 3 each component incorporated a sidebar which we coded in the <tt>addSubmenu</tt> function in admin/helpers/helloworld.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the administrator menu is in a vertical panel on the left hand side, and the Hello World submenu is built from entries in the helloworld.xml manifest file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<administration>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<submenu>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<menu link="option=com_categories&extension=com_helloworld">COM_HELLOWORLD_CATEGORIES</menu>
<menu link="option=com_fields&view=fields&context=com_helloworld.helloworld">MOD_MENU_FIELDS</menu>
<menu link="option=com_fields&view=groups&context=com_helloworld.helloworld">MOD_MENU_FIELDS_GROUP</menu>
</submenu>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===CSS Classes===
In several places the CSS classes defined in the html elements have been changed in Joomla 4. For example, for general layout the classes now align with the [https://getbootstrap.com/docs/3.4/css/ Bootstrap CSS Classes], and classes such as <tt>row-fluid</tt> and <tt>span3</tt> which were prominent in Joomla 3 have disappeared. If you're upgrading a Joomla 3 component then it's probably best (on the back-end at least) to find a similar Joomla component and use the overall html structure and css classes within its tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the tutorial code those classes which are specifically used by Bootstrap have been changed from eg 'data-target' to 'data-bs-target', and it has been necessary to change these to enable the functionality to work.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, not all of CSS class changes affecting solely the presentation have been reflected in the updated tutorial code. For example, in the <tt>helloworlds</tt> view, showing the list of helloworld messages, the display of the associations is different from that of other Joomla components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Fonts===
In Joomla 3 [[J3.x:Joomla_Standard_Icomoon_Fonts|Icomoon Fonts]] were used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 Font Awesome's free icons are used, and you can see what is available on their [https://fontawesome.com/v5/cheatsheet cheatsheet]. The icons are implemented using CSS pseudo-elements, as described [https://fontawesome.com/v5/docs/web/advanced/css-pseudo-elements here]. Basically they convert a CSS class into html content, namely a unicode value in the private use range. A couple of these have been implemented in the frontend form, in the Save and Cancel buttons, for example:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>span class="icon-cancel">/span <?php echo Text::_('JCANCEL') ?></tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(with angle brackets removed from the <tt>span</tt> tags to stop the icon just being displayed by the browser).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This class is defined in media/system/css/joomla-fontawesome.css (where you can find the list of icon classes supported):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
.icon-cancel:before {
content: "\f00d";
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so this includes in front of the text the unicode character <tt>f00d</tt>, which you can see on the cheatsheet as "times", and displayed as <span class="icon-cancel"></span>. You can also use <tt>fa-</tt> plus the icon name on the font awesome cheatsheet page. If you use Icomoon icon names in your code which you run under Joomla 4, then the icon displayed will be a Font Awesome icon (if there's one with the same name) or it will use a mapping which the Joomla team have defined to display a Font Awesome icon which resembles the Icomoon one.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Buttons and Links===
An accessibility principle is that <tt><a></tt> html elements should be used for links to other web pages, and <tt><button></tt> elements should be used for actions, eg on a form. To align with this, the <tt><a></tt> elements in the helloworld modal field (defined in admin/src/Field/Modal/Helloworld.php) have been changed to <tt><button></tt> elements. These are the Select and Clear buttons displayed when choosing a Helloworld record for a menuitem pointing to a Helloworld message. (The buttons also include fontawesome icons, by the way).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This change was actually made in Joomla in one of the Joomla 3 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Categories View===
In the Categories view of standard Joomla components there now appears columns which show for each category the number of items, split by published status. This is populated by <tt>com_categories</tt> calling each extension's <tt>countItems</tt> function, as described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_categories|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Miscellaneous Changes==
===Version History===
In Joomla 3 the tutorial code used the <tt>JTableObserver</tt> functionality to copy relevant changes from the Helloworld and Categories tables into the UCM tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it uses a plugin mechanism to subscribe to Table events 'onTableAfterStore' and 'onTableBeforeDelete'. The plugin can be found in plugins/behaviour/versionable, and it is activated by Joomla as part of its application initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The copying of fields from the table works roughly the same way as before, except that the name of the table where the versions are stored is now <tt>#__history</tt>, so the entries which have to be inserted into the <tt>#__content_types</tt> table are fairly similar. Because the folders in which forms are stored has changed in Joomla 4, the 'formFile' parameter is different (remember that this is where Joomla gets the field labels in order to display the Preview within the Versions modal window, otherwise just the names of the database columns will be output).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here's a summary of what needs to be done to enable versioning under Joomla 4. The Versioning Traits and Interface definitions are found in libraries/src/Versioning:
* Enter data into content_types database table
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Storing the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The Table class must implement VersionableTableInterface and provide <tt>getTypeAlias()</tt>, which returns 'com_helloworld.helloworld'. This type alias + the helloworld record id is used as the key to identify versions in the <tt>#__history</tt> table.
* Define <tt>save_history</tt> and <tt>history_limit</tt> options in config.php, and ensure these are both set.
* Add a <tt>version_note</tt> field into the output of the edit view's tmpl file (admin/tmpl/helloworld/edit.php).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Viewing and Restoring the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit Controller (admin/src/Controller/HelloworldController.php) should <tt>use VersionableControllerTrait</tt>.
* The edit Model (admin/src/Model/HelloworldModel.php) should <tt>use VersionableModelTrait</tt> and include a variable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public $typeAlias = 'com_helloworld.helloworld';
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit View (admin/src/View/Helloworld/HtmlView.php) – should display the Versions toolbar button if global config has <tt>save_history</tt> on.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Joomla 4 allows us to have different history version limits for helloworld items and categories, and this has been used in the configuration definition in admin/config.xml.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Setting Configuration Parameters in Install Script===
As you may remember, global configuration parameters relating to the Hello World component are defined in admin/config.xml and stored in the <tt>#__extensions</tt> table, in a JSON string in the params field of the record relating to <tt>com_helloworld</tt>. This means that when the component is first installed the params are not set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So, for example, even if the <tt>save_history</tt> is defined in config.xml to default to true, the versions won't be saved until an administrator actively saves the configuration parameters, because the Joomla versioning code assumes <tt>save_history</tt> to be false if it's not explicitly set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For this reason it makes sense to set any default configuration parameters in the install script.php, in the <tt>postflight</tt> method, and that has been done in this step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Tags===
Like version history, tags functionality has been changed to use a plugin – in plugins/behaviour/taggable – rather than the <tt>JTableObserver</tt> approach.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To enable tags the component table must implement TaggableTableInterface (in libraries/src/Tag), and provide the <tt>getTypeAlias()</tt> which is common to the Versioning functionality.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Whenever <tt>com_tags</tt> outputs helloworld messages or categories relating to a tag it displays them as links, and looks in the site/helpers/route.php file to find the route functions (as described above in [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_tags|com_tags]]). The class and method in this file must match the 'router' field within the data entered into the <tt>#__content_types</tt> table.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===media files===
Under Joomla 4 all of the media files are stored in the /media folder; these include javascript and css files (scss files too), as well as images such as the little flag symbols shown in the language switcher. Extensions being developed should store all of the js and css files in their /media folder, and then when the extension is installed these files are put under the extension's folder under the /media folder of the Joomla instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Patches==
Some bugs in Joomla were discovered during the course of updating the tutorial code to work under Joomla 4. If you find something doesn't work then make sure you're on at least Joomla 4.2.6 and check if you need one of the following patches:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
CategoryAssociationHelper.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39358/files
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
MediaField.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/issues/39203
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Category restore
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39474
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Contributors ==
*[[User:Robbiej|Robbie Jackson]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Prev: Adding Custom Fields|class=expand success}}</div>
</div>
</div>

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/17/it

2023-05-27T12:43:37Z

<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> si troverà in
administrator/components/com_helloworld/src/Controller/DisplayController.php

J3.x:Developing an MVC Component/Upgrading to Joomla4/it

2023-05-27T12:43:14Z

Ing Pulizzi: Created page with "Quindi Joomla ora si aspetta che tutti i nomi delle classi vengano trovati in quelle directory di base, con il nome del file che corrisponde al nome della classe e il nome del..."

<noinclude><languages /></noinclude>

{{:J3.1:Developing an MVC Component/it}}
Questo passaggio copre ciò che è coinvolto nell'aggiornamento del codice del tutorial per allinearlo con la versione 4 di Joomla.

== Introduzione ==
Questa pagina descrive i principali aspetti relativi allo sviluppo dei componenti che sono stati introdotti in Joomla 4 e descrive in dettaglio cosa è stato modificato nel codice del tutorial per allinearsi con v4.

Non è pratico dettagliare tutte le modifiche al codice sulla pagina Web come è stato fatto per i passaggi precedenti dell'esercitazione. Invece puoi trovare il codice come repository github su [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial Joomla 4 Tutorial code], e puoi confrontarlo con il codice del passaggio precedente del tutorial (Adding Custom Fields) su [https://github.com/robbiejackson/Joomla-3-MVC-Tutorial Joomla 3 MVC code]. Il codice di Joomla 4 replica tutte le funzionalità del codice di Joomla 3, con l'eccezione dell'implementazione dell'icona del piccolo pinguino introdotta in [[S:MyLanguage/J3.2:Developing an MVC Component/Adding decorations to the backend|Aggiunta di decorazioni al backend]] (che non è così rilevante data la modifica dell'interfaccia utente in Joomla 4 Administrator) e l'uso di un plug-in CAPTCHA ([[J3.x:Developing an MVC Component/Adding a frontend form|Adding a frontend form]] ). Probabilmente troverai utile avere a portata di mano questo codice Joomla 4 a cui fare riferimento mentre leggi questa pagina.

Il codice per questo passaggio è stato sviluppato seguendo ciascuno dei precedenti passaggi del tutorial e cercando di far funzionare ogni passaggio con Joomla 4.2.5. Poiché Joomla 4 si sta ancora evolvendo abbastanza velocemente, è possibile che alcuni aspetti qui citati vengano modificati durante la vita di Joomla 4. Sentiti libero di correggere gli aspetti in questa pagina e creare richieste pull su [https://github.com/robbiejackson /Joomla-4-MVC-Tutorial Joomla 4 github repository].

Se stai installando il codice del tutorial di Joomla 4 su una nuova istanza di Joomla, dovrai configurare la tua istanza per renderla multilingue e aggiungere le voci di menu nascoste di Ajax come descritto nel passaggio [[J3.x:Developing an MVC Component/ Utilizzo del filtro della lingua |Utilizzo del filtro della lingua]]. Assicurati inoltre che ogni record helloworld abbia una categoria valida.

=== Ulteriori letture ===
Puoi trovare [https://blog.astrid-guenther.de/en/der-weg-zu-joomla4-erweiterungen/ qui] un tutorial per lo sviluppo dei componenti di Joomla 4, simile a questo Joomla 3, e alcuni eccellenti Joomla 4 è disponibile anche la documentazione [https://www.dionysopoulos.me/book.html qui]. Entrambi questi riferimenti includono descrizioni degli impatti di Joomla 4 sullo sviluppo di altri tipi di estensioni Joomla (plugin, moduli e modelli), che non sono trattati qui.

Questo passaggio non copre tutto ciò che è necessario per aggiornare un componente da Joomla 3 a Joomla 4, solo gli aspetti coperti dal codice del tutorial. Se stai aggiornando il tuo componente Joomla 3, potresti trovare utile esaminare [[Potenziali problemi di compatibilità con le versioni precedenti in Joomla 4]].

== NameSpace ==
===NameSpace dei nomi dei componenti===
I NameSpace delle classi che utilizza la [https://www.php-fig.org/psr/psr-4/ PSR-4 recommendation] è stato gradualmente introdotto durante le versioni di Joomla 3 e con Joomla 4 è praticamente tutto con NameSpace

Ora è previsto che anche le estensioni di Joomla utilizzino i NameSpace di base per l'estensione definito nel suo file XML manifest. I componenti di Joomla usano uno NameSpace della forma <tt>Joomla\Component\<Nome componente></tt> es. <tt>Joomla\Component\Content</tt>, quindi seguendo questo schema ho dato una base al codice del tutorial spazio dei nomi di <tt>Robbie\Component\Helloworld</tt>. Ecco la riga nel file manifest helloworld.xml:

<namespace path="src">Robbie\Component\Helloworld</namespace>

(L'attributo <tt>path="src"</tt> indica che si aspetterà che le classi si trovino nella sottocartella <tt>src</tt>.)

Questo in realtà crea 2 prefissi dello spazio dei nomi, che puntano a cartelle specifiche nella nostra struttura di sviluppo helloworld e nella nostra istanza joomla live:

<tt>Robbie\Component\Helloworld\Administrator</tt> – punterà ad administrator/components/com_helloworld/src sull'istanza live ed è associato ad admin/src nella nostra area di sviluppo.

<tt>Robbie\Component\Helloworld\Site</tt> – punterà a components/com_helloworld/src sull'istanza live ed è associato a site/src nella nostra area di sviluppo.

Quindi Joomla ora si aspetta che tutti i nomi delle classi vengano trovati in quelle directory di base, con il nome del file che corrisponde al nome della classe e il nome della classe completo che corrisponde al percorso, ad esempio

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> will be found in
administrator/components/com_helloworld/src/Controller/DisplayController.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> will be found in
components/com_helloworld/src/Model/CategoryModel.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Note that capitalization is important in namespaces, names of classes and path names!'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla 3 wanted to call functions in your component it looked for certain file names in particular folders, and checked that the name of the class in that file matched what it expected.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it generates the fully qualified name of the class it wants to find, and then looks to find it in the location where the PSR-4 recommendation would expect it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Hence the namespace you specify in your class files must align with the file path to your PHP file, below the base <tt>src</tt> folder at your namespace prefix.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note in particular how the <tt>View</tt> class files are now organised.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Also if you use one of the PHP predefined classes (eg <tt>Exception</tt>) in your code, then add a backslash before it (eg <tt>\Exception</tt>), otherwise PHP will try and find it in your namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you use custom Field or Rule definitions in your form xml files then you have to indicate to PHP which namespace prefix to use to look for them, eg in <tt>site/forms/add-form.xml</tt>:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
addruleprefix="Robbie\Component\Helloworld\Administrator\Rule"
addfieldprefix="Robbie\Component\Helloworld\Administrator\Field"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and also in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> where the associations are added into the form dynamically to form the custom <tt>modal_helloworld</tt> type field:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Class Autoloading===
Joomla uses the PHP mechanism for [https://www.php.net/manual/en/language.oop5.autoload.php Autoloading Classes] and on startup registers a number of autoloaders – functions which get called when PHP can't find a given class. In particular the Joomla PSR-4 autoloader function (in <tt>libraries/loader.php</tt>) is responsible for finding classes of Joomla extensions whose code is in source files which are organised according to the PSR-4 recommendation. (Joomla library classes are autoloaded using a different autoloader – see <tt>libraries/vendor/composer/autoload_static.php</tt>).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can see the namespace prefixes of extensions on the Joomla instance by looking at <tt>administrator/cache/autoload_psr4.php</tt>. (These namespace strings have double backslashes, but in PHP they're the [https://stackoverflow.com/questions/25459197/single-or-double-slash-when-using-php-namespace same strings as those with single backslashes]). This is generated by Joomla looking through the component, module and plugin directories to find each extension's manifest file, and then processing these xml files to extract the <tt><namespace></tt> element – quite a lot of work, which is why it's cached I guess!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider what happens when Joomla wants our admin HelloworldController class. It might have something like
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$classname = 'Robbie\Component\Helloworld\Administrator\Controller\HelloworldController'
if (!class_exists($classname)) { …
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Assuming PHP doesn't already know about this class, the <tt>class_exists</tt> function will result in the classname being passed to the registered autoload function(s). The PSR-4 autoloader will then:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# go through its array of namespaces to try and match <tt>$classname</tt> from the start of the string.
# find 'Robbie\Component\Helloworld\Administrator' as a match
# see that this maps to "administrator/components/com_helloworld/src"
# extract the remainder of the classname: 'Controller\HelloworldController'
# treat this as the path down to the class file
# and so look for "administrator/components/com_helloworld/src/Controller/HelloworldController.php"
# check that in this file there's actually a class with that namespace + class name.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So in this way Joomla can go from a fully qualified class name to find the source code for that class. This makes it easier for us too when the core Joomla code is looking for one of our classes. We still need to know what class it's looking for, but once we know that, we know what we should call our class and where we should save the source code for it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Joomla Library classes===
Originally Joomla's core classes (beginning with a capital J) were global classes. Over the Joomla 3 versions and into Joomla 4 these migrated to their namespaced equivalents, but the original global classnames were still available as Joomla registered them as aliases (in the <tt>libraries/classmap.php</tt> file).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In a Joomla 4 extension you can still use these global classnames, except that in a namespaced file you'd have to prefix the name with a backslash to indicate a global class rather than one in your namespace (eg <tt>\JFactory</tt> instead of <tt>JFactory</tt>).
However it's pretty definite that the aliases will disappear at some stage, so the upgrade to Joomla 4 seems an appropriate opportunity to replace all your component's calls to the global JSomething classes to the namespaced equivalents. This involves adding the appropriate <tt>use</tt> statements, and all this has been done in the tutorial code. A useful mapping between the two can be found [https://github.com/nikosdion/joomlatypehints/blob/main/JoomlaObsoleteClasses.md here], where the new qualified classname can be copied and pasted into a <tt>use</tt> statement in your PHP file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
With reference to the [https://api.joomla.org/ Joomla API Documentation] there are 2 Joomla library namespaces:
* Joomla CMS classes – have namespaces <tt>Joomla\CMS\Something</tt> – are found under <tt>libraries/src/Something</tt>
* Joomla Framework classes – have namespaces <tt>Joomla\Something</tt> – are found under <tt>libraries/vendor/joomla/something/src</tt>
So a big advantage of namespacing is that you can immediately determine from the fully qualified class name in a PHP <tt>use</tt> statement where the source for that class exists in the <tt>libraries</tt> directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
On the other hand class names which aren't fully qualified don't have to be unique, eg <tt>MVCFactory</tt>
* occurs as <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in <tt>libraries/src/Extension/Service/Provider/MVCFactory.php</tt>
* occurs as <tt>Joomla\CMS\MVC\Factory\MVCFactory</tt> in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>
so sometimes you have to be careful to examine the <tt>use</tt> statement to identify the right class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly our FormModel class in <tt>site/src/Model/FormModel.php</tt> can have the same FormModel classname as the Joomla FormModel in <tt>libraries/src/MVC/Model/FormModel.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The API documentation gives the methods available in each of the [https://api.joomla.org/cms-4/namespaces/joomla.html Joomla CMS] and [https://api.joomla.org/framework-2/namespaces/joomla.html Framework] classes, but just be aware that a Joomla CMS class may extend a Framework class, and in this case some methods may not be visible under the Joomla CMS documentation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For example, <tt>$app->setHeader()</tt> which is used to set the HTTP response code is not listed under the [https://api.joomla.org/cms-4/classes/Joomla-CMS-Application-CMSApplication.html CMS Application class API], but is available as a method because it inherits from the Framework class [https://api.joomla.org/framework-2/classes/Joomla-Application-AbstractWebApplication.html AbstractWebApplication].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Vendor Namespaces===
These are also in <tt>libraries/vendor</tt>, eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Psr\Container\ContainerInterface;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
refers to <tt>libraries/vendor/psr/Container/src/ContainerInterface.php</tt>. However there are few of these in the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other File Rearrangements===
With all of the namespaced classes moving under the src directories, the <tt>tmpl</tt> layout files and <tt>form</tt> xml files have been moved out into their own directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Extension and Dispatcher classes ==
===Extension===
In Joomla 3 the point where the Joomla core handed over to your component code was when it ran your <tt>helloworld.php</tt> code; if it was the frontend it ran your site <tt>helloworld.php</tt> code, or if was the backend it ran your admin <tt>helloworld.php</tt> code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the entry point into your component code is your Extension class, both for site and admin, found in <tt>admin/src/Extension/HelloworldComponent.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When the Joomla core application wants to start executing the component code it creates an instance of <tt>HelloworldComponent</tt>, just to get a handle on the component code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly (as described below) other Joomla classes such as Router or Categories need to call certain Helloworld methods (eg custom router functions). In Joomla 3 these methods were written in certain Helper files etc. In Joomla 4 the principle is that the component creates an instance of the <tt>HelloworldComponent</tt> Extension class, and calls the required methods on that instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This Extension class isn't anything like a big container class for the component, it's more like a glue class, providing a way in to the Helloworld component, enabling the Joomla core and other components call the methods which they want to call.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla core wants to execute the component code, the key method it is looking for in your <tt>Extension</tt> instance is <tt>getDispatcher</tt>, and it expects to get back a <tt>Dispatcher</tt> instance. The <tt>HelloworldComponent</tt> extends <tt>MVCComponent</tt>, which in turn extends <tt>Component</tt>, and it is this class which defines <tt>getDispatcher</tt> for us.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Dispatcher===
When Joomla wants to run the Hello World component, it gets the <tt>Dispatcher</tt> instance as described above and then calls the <tt>dispatch</tt> method on it. It is this <tt>dispatch</tt> function which replaces the functionality in the admin and site <tt>helloworld.php</tt> files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's look at the main lines of code in our Joomla 3 admin <tt>helloworld.php</tt> file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="site/views/form/view.html.php">
<syntaxhighlight lang="php">
if (!JFactory::getUser()->authorise('core.manage', 'com_helloworld'))
{
throw new Exception(JText::_('JERROR_ALERTNOAUTHOR'));
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Get an instance of the controller
$controller = JControllerLegacy::getInstance('HelloWorld');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Execute the Request task method
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Redirect if set by the controller
$controller->redirect();
</syntaxhighlight>
</span>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code
* performs some permissions checks
* instantiates the appropriate Helloworld controller
* executes the appropriate method in that controller
* implements any redirect set by the controller
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Model-View-Controller]] for further details of how this works in Joomla 3. The second and third steps used the <tt>task</tt> parameter within the URL query to determine the correct controller class to instantiate and method to call. If no <tt>task</tt> parameter was present then it instantiated the controller in <tt>controller.php</tt> and called the <tt>display</tt> method. Otherwise it instantiated one of the controllers in the <tt>controllers</tt> subfolder (eg <tt>controllers/helloworld.php</tt>) and called the appropriate method on it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>ComponentDispatcher::dispatch</tt> method (in <tt>libraries/src/Dispatcher/ComponentDispatcher.php</tt>) now provides this functionality, but in a nicer way. After checking the permissions it uses the <tt>task</tt> by considering its parts as <tt><controller type>.<method></tt> (taking 'display' as default if either part is missing). It will then pass control to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* an instance of the class <Controller type>Controller
* calling the function <method>
* using the admin or site controller, as appropriate
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In this way the naming of the controllers is consistent - we have DisplayController, HelloworldController and HelloworldsController, all in the same folder.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Dispatcher class can thus be considered as providing some 'routing - execution' functionality, enabling us to find the right controller and function within that controller, and it is cleaner to have this in a separate class rather than in the <tt>JControllerLegacy</tt> class as it was in Joomla 3.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Since the Hello World tutorial uses the standard Joomla pattern for selecting the class and method based on the <tt>task</tt> and has the same permissions checks, we can use the <tt>dispatch</tt> code as it stands in <tt>ComponentDispatcher</tt>, and don't need to define a special class of our own.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Factory classes ==
In Joomla 3 many classes had static <tt>getInstance</tt> methods which returned an instance of that class, configured with the parameters passed to <tt>getInstance</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the <tt>getInstance</tt> methods have been deprecated in favour of using Factory classes. The preferred mechanism is now to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* get an instance of the appropriate Factory class (how we do that is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below)
* call the <tt>createSomething()</tt> method of the Factory class with relevant parameter values to generate an instance of the Something class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===MVC Factory===
In this section the <tt>MVCFactory</tt> class refers to the one in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory class will instantiate Controller, View, Model and Table instances on our behalf, and it does this by generating the classname of the class and then calling <tt>new</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The way it works is as follows:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Each component gets an individual MVCFactory instance which is constructed passing the component's namespace as a parameter (so in our case 'Robbie\Component\Helloworld'). (How this MVCFactory instance is created is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below).
# The MVCFactory createController / createView / createModel / createTable function is then called, passing the name of the Controller / Model / View / Table and the prefix (which specifies whether the administrator or site class is required).
# The create function forms the classname from this data and calls <tt>new</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory create functions just form the classname from the parameters they're passed. The intelligence for working out what name and prefix should be used to form the appropriate classes for an incoming HTTP request is
* in the dispatcher code for defining the controller to use
* in the controller for the view and model
* in the model for the table
and, for example, the names of the classes created for a request with URL query <tt>?option=com_helloworld&view=viewname</tt> and no <tt>task</tt> parameter will be
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<namespace>\Controller\DisplayController
<namespace>\View\Viewname\HtmlView
<namespace>\Model\ViewnameModel
<namespace>\Table\ViewnameTable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you need an alternative name then you can override the appropriate getView, getModel or getTable function – as for example was done in the [[J3.x:Developing an MVC Component/Adding Custom Fields#Front-end_Form|Adding Custom Fields step, frontend Form section]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So from the outside this is pretty much the same as in Joomla 3. However, note that the <tt>$prefix</tt> parameter in calls to <tt>getModel</tt> etc is subtly different
* in Joomla 3 this referred to a prefix to be applied to the classname – in the tutorial code we used 'HelloWorldTable' as the prefix part of the 'HelloWorldTableHelloWorld' classname.
* in Joomla 4 this refers to a prefix higher up the classname path, and should be set to either 'Site' or 'Administrator' (the capital letter at the start is optional), depending on whether you want the class under 'Robbie\Component\Helloworld\Site' or 'Robbie\Component\Helloworld\Administrator'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVC Factory class is now the Joomla recommended way to create the controller, view, model and table classes, by using the eg <tt>getModel()</tt> method, and the use of <tt>getInstance()</tt> for these classes is now deprecated. However, the use of these functions is restricted:
* in the controller class you can call <tt>$this->getView($viewname, $viewtype, $prefix, $config)</tt> to create a view and <tt>$this->getModel($modelname, $prefix, $config)</tt> to create a model.
* in the view class you can call <tt>$this->getModel($modelname)</tt>, but only for models which the controller has previously defined using <tt>$view->setModel($modelname, $default)</tt>. It doesn't create a new model instance.
* in the model class you can call <tt>$this->getTable($tableclass, $prefix, $options)</tt> to create a table instance. Controllers and views can access the table classes in this way, by going via a model.
These restrictions do have an impact on moving away from using <tt>getInstance()</tt>, and indeed in Joomla 4.2.6 you will still find several <tt>getInstance()</tt> calls within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Factory Classes===
Several other Factory classes have been introduced in Joomla 4, enabling you to get instances of core classes such as Form, User, CacheController, etc, usually by calling a createSomething function on the Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Associated with the Factory class is a FactoryInterface, a PHP Interface which specifies the key functions which the Factory class must implement. For example, with <tt>libraries/src/Categories</tt> we have:
* CategoryFactoryInterface – which specifies the <tt>createCategory</tt> function
* CategoryFactory implements CategoryFactoryInterface – which provides the <tt>createCategory</tt> function.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Dependency Injection ==
===Overview===
The DI container is one of the significant new additions to Joomla 4. It's basically a repository of key-value pairs where:
* the key is a string which is the name of a class or interface
* the value is an instance of the relevant class, or a function that returns an instance of that class.
You put things into the container using <tt>set()</tt> passing:
* the class name or interface name
* a function which returns an instance of the class (or an instance of the class)
* a boolean defining whether the class instance may be shared or not
* a boolean defining whether this entry into the DI container is protected or not (an error will be raised if you try to overwrite a protected entry by calling <tt>set()</tt> again using the same key).
The function <tt>share()</tt> is basically the same as <tt>set()</tt> with the <tt>shared</tt> boolean set to true.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You get things out of the container by calling <tt>get()</tt> passing the key of the resource you want. The container will
* find the key in the container
* if the value isn't already a class instance, then it will run the associated function to generate an instance of the class
* if the resource is shared, it will store the class instance, so that on subsequent invocations of <tt>get()</tt> it can just return the instance
* return the class instance to you
You can also define aliases for each key in the container, which means that you call <tt>get()</tt> passing either the key or an alias of the key.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The DI container is initialised in <tt>library/src/Factory.php createContainer()</tt> which results in the <tt>register()</tt> function being called in each of the class files in <tt>libraries/src/Service/Provider</tt>. By looking through those files you can see what gets put into the DI container upon initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===JConfig Example===
Let's consider the example of JConfig which holds the system global configuration. If you look inside <tt>libraries/src/Service/Provider/Config.php</tt> then you'll see the <tt>register()</tt> function and that it stores in the DI container a resource with:
* key = 'JConfig'
* value = an anonymous function - which loads what's in <tt>configuration.php</tt> into a <tt>Registry</tt> object, and returns it
* shared flag = true (because the <tt>share()</tt> function is used)
* protected flag = true
Then when you do
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$config = $container->get('JConfig');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will run the anonymous function and return the Registry object to you. As the 'shared' boolean is set it will also store a copy of the class instance locally in the container to be returned on subsequent calls of <tt>get('JConfig')</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Justification===
What's the point of all this?
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The advantage of dependency injection is that it allows classes to be easily mocked for testing. The file <tt>libraries/src/Service/Provider/Config.php</tt> can be replaced to return to a DI container <tt>get()</tt> call a mock class instead of the usual <tt>JConfig</tt>. This is in comparison to Joomla 3 where <tt>Factory::getConfig()</tt> code directly reads the <tt>configuration.php</tt> into a Registry structure and returns it – which makes it harder to mock.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The [https://api.joomla.org/cms-4/classes/Joomla-CMS-Factory.html Factory API] has several functions which are marked as deprecated with advice to get the object from the DI container instead.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Several of the other Factory classes (eg Form, Language, Menu, User) are in the DI container – so that we can get an instance of them via eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Factory::getContainer()->get('Joomla\CMS\Toolbar\ToolbarFactoryInterface')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to get a Toolbar instance. However, this only works for singleton classes which aren't specific to the needs of a particular extension. We'll see shortly how to make it work for class instances which need to be specific to a component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As indicated above, Joomla is moving away from using the class static <tt>getInstance()</tt> functions. We can see now that this is not only because it's more pure from an object oriented perspective. But also creating class instances from the DI container, or from Factory objects which are obtained from the DI container, builds in the dependency injection which allows classes to be more easily mocked, and hence more easily tested.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==services/provider.php==
We're now finally in a good position to understand what's happening in our services/provider.php file, and we'll explore this by walking through what happens whenever this line in libraries/src/Component/ComponentHelper.php <tt>renderComponent</tt> is run:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is run whenever Joomla has worked out which component is to be run on the requested web page, and it wants to run that component to capture its output.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 1 Create Child DI Container===
Joomla first creates another DI container (initially empty) just for this component, and links it to the main DI container via a parent field in the child DI container structure.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Now whenever <tt>set()</tt> is called on this DI container the key-value pair is inserted into the child container. Whenever <tt>get()</tt> is called on it, the resource is obtained from the child container, but if it's not found there then the parent container is searched also.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 2 Run register() in provider.php===
Next we encounter these lines (in <tt>libraries/src/Extension/ExtensionManagerTrait.php</tt>), where <tt>$path</tt> contains the path of our helloworld admin/services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$provider = require_once $path;
// Check if the extension supports the service provider interface
if ($provider instanceof ServiceProviderInterface) {
$provider->register($container);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here we see 3 things:
# our provider.php should return some object (so that <tt>$provider</tt> gets set to something)
# what is returned should implement ServiceProviderInterface (you can see in <tt>libraries/vendor/joomla/di/src/ServiceProviderInterface.php</tt> what is expected)
# the code then runs the <tt>register</tt> function on that object, passing as a parameter the child DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider a minimal version of our provider.php file. This would actually support steps in the Joomla 3 tutorial up to and including the [[J3.x:Developing an MVC Component/Adding AJAX|Adding Ajax step]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {

public function register(Container $container): void
{
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
}
};
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As you can see from the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
this file does indeed return something – it returns an instance of an anonymous class, one that implements <tt>ServiceProviderInterface</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it's not sufficient to just provide the <tt>register</tt> function in the class, we also need to explicity state that the class implements <tt>ServiceProviderInterface</tt>. This now happens in several places in Joomla, so if you're debugging your component and wondering why a function you expect to be called isn't being called, then check to make sure that you don't have to explicitly add the appropriate <tt>implements <Interface></tt> clause to your class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Next we look at the 3 lines in the <tt>register</tt> function
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3a Registering our MVC Factory===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here our <tt>MVCFactory</tt> refers to <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in libraries/src/Extension/Service/Provider/MVCFactory.php, and you should have a look at this file. This is a file similar to our provider.php file, but it's a named class, and it doesn't return anything. When we do:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
new MVCFactory('\\Robbie\\Component\\Helloworld')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it creates an instance of this class, and in the constructor it stores locally in <tt>$this->namespace</tt> our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>registerServiceProvider</tt> function then calls the <tt>register</tt> function of this instance, which runs (in its minimalist form):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
MVCFactoryInterface::class,
function (Container $container) {
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
return $factory;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So what gets entered into our child DI container is a key-value pair with:
* key = MVCFactoryInterface::class (this is just a shorthand form to obtain a string of the fully qualified name – ie 'Joomla\CMS\MVC\Factory\MVCFactoryInterface')
* value = a function which returns an instance of <tt>\Joomla\CMS\MVC\Factory\MVCFactory</tt>.
This is our MVCFactory class which generates our Controllers, Views, Models and Tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Notice that we're passing our namespace as a parameter <tt>$this->namespace</tt>. Because this function is a closure, this variable will still be available when we run this function later, and when the MVCFactory class is instantiated the namespace will be passed into the constructor, stored locally, and then subsequently used to form the fully qualified names of our Controllers, View, etc. So this is how we get instantiated the MVCFactory class which is specific to our component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3b Registering the Dispatcher Factory===
Careful: ComponentDispatcherFactory refers to two different classes here!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This ComponentDispatcherFactory is Joomla\CMS\Extension\Service\Provider\ComponentDispatcherFactory in libraries/src/Extension/Service/Provider/ComponentDispatcherFactory.php. Similar to the above, the ComponentDispatcherFactory service provider class stores locally our namespace, and then when <tt>register</tt> is called it executes:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentDispatcherFactoryInterface::class,
function (Container $container) {
return new \Joomla\CMS\Dispatcher\ComponentDispatcherFactory($this->namespace,$container->get(MVCFactoryInterface::class));
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so a second entry is added to the child DI container with:
* key = ComponentDispatcherFactoryInterface::class
* value = a function which returns an instance of the ComponentDispatcherFactory (the other ComponentDispatcherFactory class!), where the class constructor will be passed the namespace ('\\Robbie\\Component\\Helloworld') and an MVCFactory instance, retrieved from the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that the code
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->get(MVCFactoryInterface::class)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
will get from the container an entry with key = 'Joomla\CMS\MVC\Factory\MVCFactoryInterface' – which is what we entered into the container in step 3a – and will run the function associated with this key, and then return the object which this function returns. This returned object will be an instance of '\Joomla\CMS\MVC\Factory\MVCFactory', constructed using our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3c Including the Extension===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will put into the child DI container a key-value pair with
* key = ComponentInterface::class
* value = the function which will create an instance of our <tt>HelloworldComponent</tt> (ie our Extension class), and pass into the constructor an instance of the ComponentDispatcherFactory class, retrieving what was entered into the child DI container in Step 3b.
It will call <tt>$container->get(MVCFactoryInterface::class)</tt>, getting an MVC Factory instance from what was entered into the DI container in Step 3a.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It will then associate our component with this MVC Factory instance via the <tt>setMVCFactory</tt> call. Significantly this will then allow our component to access this instance later, via a call to <tt>getMVCFactory</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3 Summary===
We have now got 3 entries in our child DI container, keyed by
* key = MVCFactoryInterface::class, value is a function returning an MVCFactory instance
* key = ComponentDispatcherFactoryInterface::class, value is a function returning a ComponentDispatcherFactory instance
* key = ComponentInterface::class, value is a function returning our HelloworldComponent, an instance of our Extension class.
The important aspect is that these entries are all aware of our namespace '\Robbie\Component\Helloworld' and will return instances of these classes which are specific to our Helloworld component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 4 Retrieving from the DI Container===
Joomla will then execute the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $container->get($type);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
where <tt>$type</tt> contains 'Joomla\CMS\Extension\ComponentInterface'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This starts the process of retrieving from the DI container the 3 entries which we put in, and will run our code in services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We end up with a HelloworldComponent instance, which has:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. a ComponentDispatcherFactory instance passed into the constructor, and which is saved locally by the constructor code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function __construct(ComponentDispatcherFactoryInterface $dispatcherFactory)
{
$this->dispatcherFactory = $dispatcherFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This code is in libraries/src/Extension/Component.php, in the class which our HelloworldComponent extends, via the class MVCComponent).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. an MVC Factory instance, stored by the HelloworldComponent <tt>setMVCFactory</tt> call
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 5 Call boot() on our Component===
Joomla calls:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
if ($extension instanceof BootableExtensionInterface) {
$extension->boot($container);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will call <tt>boot</tt> within our HelloworldComponent, and allows us to perform some initialisation within our component. We'll return to this later, in the section on [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#HTML_Snippets|HTML snippets]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note again that Joomla checks that our HelloworldComponent class implements BootableExtensionInterface before calling <tt>boot</tt>. It's not sufficient to just provide the <tt>boot</tt> function, we have to explicitly declare that our HelloworldComponent implements the interface.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 6 Get the Dispatcher===
Returning to our key line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
we have now accomplished the first part <tt>bootComponent($option)</tt>, and this has returned our HelloworldComponent instance. Now we call <tt>getDispatcher($app)</tt> on this instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This code is also in libraries/src/Extension/Component.php, in the Component class which our HelloworldComponent extends:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function getDispatcher(CMSApplicationInterface $application): DispatcherInterface
{
return $this->dispatcherFactory->createDispatcher($application);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We call <tt>createDispatcher</tt> on our ComponentDispatcherFactory class instance which we saved in Step 4. This code is in libraries/src/Dispatcher/ComponentDispatcherFactory.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createDispatcher(CMSApplicationInterface $application, Input $input = null): DispatcherInterface
{
$name = ucfirst($application->getName());

$className = '\\' . trim($this->namespace, '\\') . '\\' . $name . '\\Dispatcher\\Dispatcher';

if (!class_exists($className)) {
if ($application->isClient('api')) {
$className = ApiDispatcher::class;
} else {
$className = ComponentDispatcher::class;
}
}

return new $className($application, $input ?: $application->input, $this->mvcFactory);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code checks if we have our own Dispatcher class (our Helloworld tutorial doesn't, but <tt>com_users</tt> for example has its own). So it creates a <tt>ComponentDispatcher</tt> instance, and passes into its constructor the MVC Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that this ComponentDispatcherFactory instance is what was instantiated when it was retrieved from our child DI Container (from being inserted in step 3b), and hence it already knows about our namespace, and has a pointer to our MVCFactory class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 7 call dispatch()===
This is the final aspect to our line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We're now back to what was described in the Dispatcher section above, except that now we can see that this Dispatcher instance has a pointer to our MVC Factory instance (which knows about our namespace prefix), so when the Dispatcher code wants to create a Controller it can use that MVC Factory instance to instantiate it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's been a long and tortuous journey to get here, but the significant thing is that all of our key class instances have been obtained via the DI Container. If we want to mock out any of those classes for testing then all we need to do is replace the relevant services/provider file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Javascript and the Web Asset Manager ==
The web asset manager has been introduced in Joomla 4 and is well documented [[J4.x:Web_Assets|here]]. It provides a much-improved means of managing JS and CSS resources, and a framework for handling their dependencies.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Component Javascript and CSS files should now be stored in the <tt>media</tt> folder, and the Web Asset Manager used to register them and output them on specific web pages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following assets have been registered in the tutorial <tt>joomla.asset.json</tt>, and you should have a look at that file now.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.validate-greeting===
This is the code for client validation of the helloworld greeting field using a regex, and it is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it is dependent upon jQuery and the Joomla <tt>form.validator</tt> script, so those both get included as dependencies.
If we didn't have specific validation on our form then we would need to include explicitly the <tt>form.validator</tt> script in order for the basic Joomla field validation to be included, eg in the tmpl file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->document->getWebAssetManager()->useScript('form.validate');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that this requires us to have a <tt>class="form-validate"</tt> on the </tt><form></tt> html element.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.fix-permissions-ajax-call===
This is the code which copies the value from the greeting field into the title field, so that the Ajax calls setting the permissions work correctly. The js code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.enable-tooltips===
This is the code which enables bootstrap tooltips to operate, including allowing them to include html code. It's used to display the image as a tooltip within the admin <tt>helloworlds</tt> view.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.openstreetmap===
This is defined as a preset, comprising the helloworld js and css code for the map display, as well as the dependency named 'com_helloworld.openlayers' relating to the openlayers CSS and js code. The code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.admin-helloworlds-modal===
This is the js code for selecting an individual helloworld record within a modal, and passing its details to the form in the main window. Its code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===submitbutton.js===
In the Joomla 3 code we introduced in [[Special:MyLanguage/J3.2:Developing_an_MVC_Component/Adding_verifications|Adding Verifications]] a js file which controlled when the form was submitted. It differentiated between buttons such as <tt>Save</tt> (which submitted the form) and <tt>Cancel</tt> (which didn't).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 there is a more sophisticated version of <tt>Joomla.submitbutton</tt> (found in media/system/js/core.js) which uses the CSS classes which the Toolbar functionality sets on the buttons to determine whether the form should be submitted or not. And you can override whether the validation is performed by adding a third parameter to the <tt>submitbutton</tt> js call. For example, to avoid validation being performed when a button is clicked you can set on the button element:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
onclick="Joomla.submitbutton('controller.method', '', false)"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As this is sufficient for what we need in the tutorial, the custom <tt>submitbutton.js</tt> has been removed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Interaction with other components ==
The way that Joomla interacts with components has changed in Joomla 4. In general the Joomla functionality will boot the component using something like:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $app->bootComponent($option);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and in our case this will return an instance of the <tt>HelloworldComponent</tt> class. It will then try to call certain methods on our extension object, as described below.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_categories===
In the backend the helloworld functionality can display to the administrator
* the view of the helloworld messages
* the view of the helloworld categories
The categories view is generated by <tt>com_categories</tt>, and in Joomla 4 these component categories views display the number of component records there are for each of the possible published status values. To do this the categories component executes the following code (in administrator/components/com_categories/src/Model/CategoriesModel.php):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof CategoryServiceInterface) {
$component->countItems($items, $section);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So our HelloworldComponent must:
* declare that it implements <tt>CategoryServiceInterface</tt>
* provide an implementation of <tt>countItems</tt>
We provide <tt>countItems</tt> by using a trait in libraries/src/Categories/CategoryServiceTrait.php, which (with the assistance of a helper function) does the query on our behalf. We just need to tell it:
* the name of our table – in the callback <tt>getTableNameForSection</tt>
* the database field in which we hold the published status – in <tt>getStateColumnForSection</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_associations===
Remember that <tt>com_associations</tt> is the component which is run whenever you click on Multilingual Associations in the admin backend.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Under Joomla 3 we provided an associations helper file as described in [[J3.x:Multilingual Associations/Developers|Multilingual Associations/Developers]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the helper file remains basically the same, but <tt>com_associations</tt> primarily tries to find the helper file via the extension class; here's the code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($extensionName);
if ($component instanceof AssociationServiceInterface) {
return $component->getAssociationsExtension();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's expecting that:
* the extension (HelloworldComponent in our case) implements <tt>AssociationServiceInterface</tt>
* its <tt>getAssociationsExtension</tt> method returns the helper class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The easiest thing would be just to code <tt>getAssociationsMethod</tt> and get it to return <tt>new AssociationsHelper</tt>. However, we follow the Joomla 4 principle of putting key classes into the Dependency Injection container, and retrieving them later, by having the following code in our services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(AssociationExtensionInterface::class, new AssociationsHelper());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The above line puts a key-value pair into our child DI container
* key = 'Joomla\CMS\Association\AssociationExtensionInterface'
* value is an instance of our <tt>AssociationsHelper</tt> class.
We then retrieve it later and use the setter:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setAssociationExtension($container->get(AssociationExtensionInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so that whenever
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getAssociationExtension()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
is called it returns the <tt>AssociationsHelper</tt> class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_fields===
<tt>com_fields</tt> is the component which is run when an administrator clicks on the Fields or Field Groups menuitem within the backend, and this functionality was included in the [[J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Adding Custom Fields]] tutorial step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>com_fields</tt> component stores the custom fields and field groups for all components in the database tables <tt>#__fields</tt> and <tt>#__fields_groups</tt>, and these tables are partitioned into "sections", one section per component. For our helloworld component the section is named "helloworld".
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within the section we have 2 "contexts" – one for the helloworld messages (called "com_helloworld.helloworld") and one for the helloworld categories (called "com_helloworld.categories"). This enables us to define custom fields for both our helloworld records and helloworld category records.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When <tt>com_fields</tt> runs it checks both the section and contexts at various times. For example, when an admin selects Helloworld / Fields on the backend then <tt>com_fields</tt> checks the section which was defined in the menuitem in the manifest file (see [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Sidebar|below]]). Here's the code in administrator/components/com_fields/src/Helpers/FieldsHelper <tt>extract</tt> function:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
$newSection = $component->validateSection($parts[1], $item);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And when <tt>com_fields</tt> wants to display the little dropdown menu of contexts (to allow the administrator to set custom fields on either helloworld items or categories) it calls (in administrator/components/com_fields/src/Fields/FieldcontextsField.php <tt>getOptions()</tt>):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
return $component->getContexts();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So it's clear that our component extension class must :
* implement <tt>FieldsServiceInterface</tt>
* provide the <tt>validateSection</tt> and <tt>getContexts</tt> methods
So in upgrading to Joomla 4 we've just moved those two methods from the helper file to the extension class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Router===
The Joomla router will access our custom router code:
* whenever it wants to parse an SEF route which it has identified as belonging to <tt>com_helloworld</tt>
* whenever it wants to build an SEF route from a call to <tt>Route::_()</tt> where the option = "com_helloworld".
To find our custom router it will:
* boot the <tt>com_helloworld</tt> extension
* check that the extension implements <tt>RouterServiceInterface</tt>
* call <tt>createRouter</tt> on our extension instance
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In our services/provider.php file we have (careful again - 2 different RouterFactory classes!):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new RouterFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which from libraries/src/Extension/Service/Provider/RouterFactory.php puts into our child DI container an entry with:
* key = "Joomla\CMS\Component\Router\RouterFactoryInterface"
* value is a <tt>\Joomla\CMS\Component\Router\RouterFactory</tt> instance, constructed with our namespace
We then retrieve this in the line in our services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setRouterFactory($container->get(RouterFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And then within our extension class we have
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use RouterServiceTrait;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which includes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function setRouterFactory(RouterFactoryInterface $routerFactory)
{
$this->routerFactory = $routerFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which stores the <tt>routerFactory</tt> locally and
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return $this->routerFactory->createRouter($application, $menu);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which provides our extension's <tt>createRouter</tt> call that the Joomla Router expects.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>routerFactory::createRouter</tt> method is in libraries/src/Component/Router/RouterFactory.php. It looks for a class in our site namespace </tt>Robbie\Component\Helloworld\Site\Service\Router</tt> which is in our site/src/Service/Router.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
At this stage we have a choice, we can either:
* provide a traditional custom router, with the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions, or
* use the more modern <tt>RouterView</tt> mechanism.
By default in the upgraded tutorial code the Router View option has been coded in the Router.php file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====RouterView====
In the <tt>RouterView</tt> case the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions are in the <tt>RouterView</tt> class which we extend, and we provide
* a constructor with router view configuration
* methods <tt>getHelloworldId</tt> and <tt>getCategoryId</tt> which are used to obtain from the SEF segment the <tt>id=</tt> and <tt>catid=</tt> parts of the internal URL
* methods <tt>getHelloworldSegment</tt> and <tt>getCategorySegment</tt> which are used to generate segments for the SEF URLs based on the <tt>id=</tt> and <tt>catid=</tt> parts within the <tt>Route::_()</tt> parameter.
Unfortunately there doesn't seem to be a good guide to configuring the RouterView class. There is some documentation available [https://www.dionysopoulos.me/book/com-router-routerview.html here].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the helloworld tutorial we have 3 views
* a view which displays a single helloworld record
* a view which displays a single helloworld category, and the helloworld records associated with it
* a view which displays the frontend form
So we need 3 Router Views associated with these.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'form' view doesn't have an associated id or catid so it's just a fixed URL, and the router just has to convert between the alias of the form menuitem and the Itemid / view parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'category' view has an associated id (of the category record), and an SEF URL will use the category path down the Categories Nested Set table structure, hence <tt>setNestable()</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'helloworld' view has an associated id (of the helloworld record), and in an SEF URL in the category view the helloworld record alias is added to the category path (hence <tt>setParent()</tt>). But although the helloworld records use a Nested Table structure in the database, the URLs just include the alias of the single record, and so <tt>setNestable()</tt> is not used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There doesn't seem to be a way to configure an additional SEF URL scheme which just displays a helloworld segment, without a category segment.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====Traditional Router====
To use the traditional router in the tutorial code you should uncomment the function in the extension class:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return new TraditionalRouter($application, $menu, $this->categoryFactory, $this->getDatabase());
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will cause the code in site/src/Service/TraditionalRouter.php to be used. However, changes in the Joomla 4 router mean that the interaction between it and the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> methods have changed. This requires significant changes to the <tt>preprocess</tt> and <tt>build</tt> methods, but only a minor change to <tt>parse</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. Previously Joomla injected into the <tt>$query</tt> parameters the <tt>Itemid</tt> of the active menuitem (ie the id of the menuitem the user is currently on). This meant that we had to change the <tt>Itemid</tt> for links generated by the Language Switcher module (which generates the flags for switching between languages), and these links being associated with a different language would obviously use a different <tt>Itemid</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 you get an <tt>Itemid</tt> in the <tt>$query</tt> parameters only if you specified an <tt>Itemid</tt> in the <tt>Route::_()</tt> call. For others you have to work out which menuitem to use yourself, by using the Joomla menu/menuitems API to find details of the configured menuitems, and work out which to use based on the other <tt>$query</tt> parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You do this in the <tt>preprocess</tt> method, and then the <tt>Itemid</tt> you set will be passed in the <tt>$query</tt> parameters to the <tt>build</tt> method.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. In some instances the <tt>Route::_()</tt> URL you're generating matches exactly one of the configured menuitems on the site. In this case the <tt>$query</tt> parameters will match those in the menuitem <tt>"query"</tt> array, and you have to remove explicitly remove the 'view', 'id' and 'catid' parameters so that they don't appear as URL query parameters after the normal SEF URL of the menuitem.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
3. The custom router will be used to build the URLs for the helloworld menuitems shown in menus on the page. For these the <tt>$query</tt> parameters will have the view / id / catid associated with those menuitems. Note that even if you remove these in your <tt>preprocess</tt> method, Joomla will inject them again into the <tt>$query</tt> array when it's passed to your <tt>build</tt> method, so you'll have to remove them again there!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
4. In the <tt>parse</tt> method you now have to unset the <tt>$segments</tt>, or else Joomla will return an HTTP 404 (page not found). Otherwise <tt>parse</tt> works as before.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
5. I've implemented <tt>build</tt> only for when Multilanguage is enabled on the site. If it's not enabled an empty <tt>$segments</tt> array is just returned, without doing unset on any of the <tt>$query</tt> parameters, so these will appear as URL parameters after the SEF URL. Also it's not coded properly to deal with items which have language set to <tt>*</tt>. These include helloworld records, categories or menuitems (eg the helloworld form).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that the <tt>categoryFactory</tt> is also now passed to the router. This is so that it can be used instead of <tt>Categories::getInstance()</tt> to get access to the Categories API calls.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_tags===
Whenever we setup a Tags Menu Item Type which displays items having a given tag or tags, then <tt>com_tags</tt> displays those items as links, and uses route helper functions to generate the URL parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The route helpers <tt>com_tags</tt> expects to find loaded into the data of the <tt>#__content_types</tt> table, in the router field, and these have been set to:
* For links to helloworld items: 'HelloworldHelperRoute::getHelloworldRoute'
* For links to helloworld categories: 'HelloworldHelperRoute::getCategoryRoute'
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, <tt>com_tags</tt> doesn't boot the helloworld extension to get access to these, but rather seeks to find them in site/helpers/route.php, so that's where they continue to be.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(We also had a <tt>getCategoryRoute</tt> which was used by <tt>com_categories</tt> in administrator/components/com_categories/src/Helper/CategoryAssociationHelper. When a category was displayed on the frontend then the Language Switcher module (now Language Filter) used this function to generate the links to the Associated Categories. Our <tt>getCategoryRoute</tt> previously was necessary to insert the <tt>lang=<language tag></tt> parameter into the link URL, but since [https://github.com/joomla/joomla-cms/pull/39358 this change] the calling function inserts the <tt>lang</tt> parameter itself, so our <tt>getCategoryRoute</tt> function for this purposes is superfluous.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Deprecated APIs ==
With Joomla 4 there are a number of methods which are deprecated, with a view to removing them in Joomla 5.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Factory Methods===
Many of the <tt>Factory</tt> methods for getting singleton classes have been deprecated in favour of getting these classes via the DI container, and it appears that only class instances which should be obtained via Factory methods are:
* the Application – <tt>Factory::getApplication()</tt>
* the DI container – <tt>Factory::getContainer()</tt>
Here is a list of what has been changed in the tutorial code. Note that with some calls there are variants available, through the aliases defined in the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDbo'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\Database\DatabaseInterface;
...
$db = Factory::getContainer()->get(DatabaseInterface::class);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, in many classes the database instance is more easily (and efficiently) returned via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$db = $this->getDatabase();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is available in Model classes, custom field definitions, etc.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getUser();'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get the current user use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = Factory::getApplication()->getIdentity()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get a different user (whose id you know):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\User\UserFactoryInterface;
...
$user = Factory::getContainer()->get(UserFactoryInterface::class)->loadUserById($userid);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within models which extend Joomla\CMS\MVC\Model\BaseDatabaseModel and views which extend Joomla\CMS\MVC\View\HtmlView you can also use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = $this->getCurrentUser()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDocument()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication()->getDocument()</tt>, or within a View you can use <tt>$this->document</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getConfig()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Two options have been used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->getConfig()</tt> – returns a Registry object containing all the configuration values
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->get('access')</tt> – returns the value of the 'access' configuration parameter
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getLanguage()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication->getLanguage()</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JFactory::getCache('com_example', <type>)'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Cache\CacheControllerFactoryInterface;
...
Factory::getContainer()->get(CacheControllerFactoryInterface::class)->createCacheController(<type>)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated getInstance Methods===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general <tt>getInstance()</tt> calls have been deprecated in favour of obtaining the instance, either via a factory class or via the DI container. For example, within a controller you can use <tt>getModel()</tt> repeatedly to get different models (passing the relevant model names), which results in the MVCFactory class creating the Model classes.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there are currently some problems with replacing some getInstance calls. I expect that the Joomla team will resolve these issues over the course of the Joomla 4 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Categories::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is deprecated with a notice: "Use the ComponentInterface to get the categories". This means that we should get the category factory instance via the DI container. This is done in our services/provider.php by the lines:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Extension\Service\Provider\CategoryFactory;
...
$container->registerServiceProvider(new CategoryFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to put into our child DI container the closure which will create a Joomla\CMS\Categories\CategoryFactory instance, constructed with our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when our HelloworldComponent (Extension) instance is created:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We can then use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getCategoryFactory()->createCategory();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to create our Categories object, and in this way get access to the Categories APIs.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This createCategory method creates the instance by looking for the \\Site\\Service\\Category class within our namespace. The constructor in our class sets our extension ('com_helloworld') and table ('#__helloworld') and calls the parent Categories constructor with these options).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this means that the section of our code where we want to use the Categories APIs must have a pointer to a CategoryFactory instance. In the tutorial code for Joomla 3 there are 2 places where <tt>Categories::getInstance</tt> is used:
* in the custom router code, to handle building and parsing of the category parts of the SEF URL
* in the site category model, where the Categories APIs are used to obtain details of categories to display on the page.
For the custom router code, the CategoryFactory instance is passed as a parameter to the TraditionalRouter constructor so that it can be used there.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, the site category model is instantiated by the MVCFactory instance, and it doesn't make available a CategoryFactory instance. So in this category model the calls to <tt>Categories::getInstance()</tt> have been left, and you can still find a number of calls to <tt>Categories::getInstance</tt> within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Categories::getInstance()</tt> itself solves the problem of access to a CategoryFactory instance by rebooting our component again to get a pointer to our Extension instance, and thus to the category factory instance. However, this involves a lot of work, so <tt>getInstance</tt> caches locally the Categories instances and just returns one of them if it can.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Pushing the CategoryFactory to the model'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there is a way to get access to the CategoryFactory instance, by defining your own MVCFactory class, and pushing the instance down through it to the model. Here's how you can go about it:
* Define your own SuperMVCFactory class, which extends the Joomla Joomla\CMS\MVC\Factory\MVCFactory class, but which has a means of storing a CategoryFactory instance. Use the CategoryServiceTrait in libraries/src/Categories/CategoryServiceTrait.php
* Create your own version of the file libraries/src/Extension/Service/Provider/MVCFactory.php, which is the 'provider.php' like file for MVCFactory, but change it so that:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
becomes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new <namespace>\SuperMVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and include
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla creates a model such as CategoryModel it passes in its constructor the MVCFactory instance (so that the model can call createTable on it), so you can access it via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will return your SuperMVCFactory instance. So in this way within the model you can access the CategoryFactory, and use it to create the Categories instance via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()->getCategory() (from the CategoryServiceTrait)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you can get this working you can congratulate yourself on a good understanding of Joomla namespacing and dependency injection! A similar approach to address a similar problem is described [https://www.dionysopoulos.me/book/com-router-push-dependencies.html here]. If you get stuck you can always view the solution by viewing the github tutorial code selecting the branch [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial/tree/push-category-factory-to-mvc push-category-factory-to-mvc].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Table::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There are a couple of calls to <tt>Table::getInstance()</tt> within admin/src/Helper/AssociationsHelper.php in <tt>getItem()</tt>:
* <tt>Table::getInstance('Helloworld', 'Robbie\\Component\\Helloworld\\Administrator\\Table\\')</tt> to get an instance of our HelloworldTable class.
* <tt>Table::getInstance('Category')</tt> to get an instance of the Category table in libraries/src/Table/Category.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We could actually arrange for the AssociationsHelper class to get injected with the MVCFactory instance, so that the HelloworldTable class could be instantiated by it. However, we couldn't use the helloworld MVCFactory instance to create the Category table instance, as it's not in the helloworld namespace, and our MVCFactory instance creates table instances within our namespace only.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Toolbar::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The tutorial code uses <tt>Toolbar::getInstance()</tt> to get a Toolbar instance onto which it can attach the batch button in the helloworlds form. The Toolbar API documentation seems to suggest that we should replace
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Toolbar::getInstance('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
with
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this currently won't work. The problem is that all the other Joomla code uses <tt>getInstance('toolbar')</tt> to access the Toolbar class, including the code in administrator/modules/mod_toolbar/mod_toolbar.php which renders the toolbar. The <tt>getInstance</tt> method keeps track of the Toolbar instances in a local static variable <tt>$instances</tt>, and returns the same Toolbar instance on repeated invocations.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you use the second approach above you will get a Toolbar instance, but it won't be the same Toolbar instance as is stored in the <tt>$instances</tt> variable. It won't then be picked up by the Toolbar module, and so won't be rendered on the form.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Error Handling===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead of
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
JError::raiseError(500, implode('<br />', $errors));
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
you should throw an exception, using or extending one of the standard [https://www.php.net/manual/en/spl.exceptions.php PHP exceptions], eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
throw new \Exception(implode("\n", $errors), 500);
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===jimport===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
jimport is no longer necessary in order to get access to Path or File classes. All of the Joomla classes are found by the autoloader.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Methods related to Javascript===
'''JHtml::_('behavior.framework');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general, the use of JHtml::_('behavior.xxx') is now obsolete, and calls using this have been removed in the tutorial code. The 'behavior.framework' call referred to including jQuery. Where jQuery is necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.formvalidator');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by the <tt>form.validate</tt> javascript asset, and where necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It can also be included directly using the web asset manager:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$wa->useScript('form.validate')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.tooltip')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This no longer exists, and tooltips don't seem to be enabled by default in Joomla 4. This is replaced by the code in media/js/enable-tooltips.js.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('formbehavior.chosen')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The chosen js library seems to be no longer used, and using it will cause formatting issues if you include it in your tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''sortable'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The sortable js library provided the ability in the helloworlds view to drag rows up and down to change the ordering of the records. This has been replaced in Joomla 4 by the draggable library. To enable it you have to set:
* <tt>HTMLHelper::_('draggablelist.draggable');</tt>
* on your <tt><tbody></tt> element define the table in which dragging occurs and the URL of the Ajax call to set the ordering:
<source lang="php">
<tbody<?php if ($saveOrder) : ?> class="js-draggable" data-url="<?php echo $saveOrderingUrl; ?>" data-direction="<?php echo strtolower($listDirn); ?>" data-nested="true"
<?php endif; ?>>
</source>
* on your <tt>tr</tt> element within your <tt><tbody></tt> define the group of records in which dragging occurs (by category below):
<source lang="php">
<tr class="row<?php echo $i % 2; ?>" data-draggable-group="<?php echo $row->catid; ?>">
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==HTML Snippets==
There are two places in the tutorial where reusable snippets of HTML have beeen defined:
* For displaying the item associations in the helloworlds view:
* For displaying the position latitude and longitude fields within the batch options in the helloworlds view
These used different approaches:
* the item associations display was coded in an html helper file in admin/helpers/html/helloworlds.php and accessed via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JHtml::_('helloworlds.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
in the helloworlds tmpl file. (Although it did use a common joomla layout file underneath).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* the position field was coded as a layout in layouts/position.php, and rendered using
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JLayoutHelper::render('position', array());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When should you use one approach rather than the other? A significant difference is that layouts are designed so that an administrator can override them, via the Templates / Details and File functionality. So, for example, an administrator could change the position to show the longitude before the latitude. So it's more appropriate for layouts to focus on the html elements rather than functional logic, and particularly if you would want to allow an administrator to override the layout.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The layouts functionality in Joomla 4 hasn't changed significantly. One correction which has been made in the updated tutorial code has been to include the position.php file in a subfolder of layouts, ie in admin/layouts/helloworld/position.php rather than admin/layouts/position.php. It appears that in the Templates / Details and Files / Create Overrides tab the <tt>com_helloworld</tt> layout appears only if it's in a subfolder of /layouts.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>JHtml::_()</tt> approach has changed in Joomla 4. Rather than Joomla having to look for a helper file when it encounters something it doesn't recognise, it's expected that you should register such classes beforehand, and you do this by obtaining an instance of the Joomla\CMS\HTML\Registry class (it's a singleton class) and then calling <tt>register</tt> on it, passing
* the key you want to use
* an instance of your class
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Joomla pattern is to put the code in a file admin/src/Service/HTML/AdministratorService.php, and we have to ensure that our key won't be used elsewhere within Joomla, so in the tutorial we've used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Robbie\Component\Helloworld\Administrator\Service\HTML\AdministratorService;
...
register('helloworldadministrator', new AdministratorService)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when we call:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo HTMLHelper::_('helloworldadministrator.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will result in Joomla calling the <tt>association</tt> method in our class, passing the <tt>$row->id</tt> parameter.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We should get the Joomla\CMS\HTML\Registry class from the Dependency Injection container. Joomla components generally do this via their services/provider.php file, and then call <tt>register</tt> within the extension's <tt>boot</tt> function, described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Step_5_Call_boot.28.29_on_our_Component|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The extension uses HTMLRegistryAwareTrait which contains <tt>setRegistry</tt> and <tt>getRegistry methods</tt>. In services/provider.php there is:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\HTML\Registry;
...
$component->setRegistry($container->get(Registry::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets 'Joomla\CMS\HTML\Registry' out of the DI container and stores it within the
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
private $registry;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
variable of the HTMLRegistryAwareTrait included in the extension.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the <tt>boot</tt> function it calls
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getRegistry()->register('helloworldadministrator', new AdministratorService);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets the registry and calls <tt>register</tt> as required.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that <tt>boot</tt> is called whenever Joomla dispatches <tt>com_helloworld</tt>, both for the site and administrator, so it would make sense to check the Application <tt>isClient</tt> before deciding whether to register the HTML Helper service or not. This hasn't been included in the tutorial code though.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==User Interface Changes==
Joomla 4 introduced new templates, atum on administrator and cassiopeia on site, and in particular the administrator is built upon some UI rearrangements which affect the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Sidebar===
In Joomla 3 each component incorporated a sidebar which we coded in the <tt>addSubmenu</tt> function in admin/helpers/helloworld.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the administrator menu is in a vertical panel on the left hand side, and the Hello World submenu is built from entries in the helloworld.xml manifest file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<administration>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<submenu>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<menu link="option=com_categories&extension=com_helloworld">COM_HELLOWORLD_CATEGORIES</menu>
<menu link="option=com_fields&view=fields&context=com_helloworld.helloworld">MOD_MENU_FIELDS</menu>
<menu link="option=com_fields&view=groups&context=com_helloworld.helloworld">MOD_MENU_FIELDS_GROUP</menu>
</submenu>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===CSS Classes===
In several places the CSS classes defined in the html elements have been changed in Joomla 4. For example, for general layout the classes now align with the [https://getbootstrap.com/docs/3.4/css/ Bootstrap CSS Classes], and classes such as <tt>row-fluid</tt> and <tt>span3</tt> which were prominent in Joomla 3 have disappeared. If you're upgrading a Joomla 3 component then it's probably best (on the back-end at least) to find a similar Joomla component and use the overall html structure and css classes within its tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the tutorial code those classes which are specifically used by Bootstrap have been changed from eg 'data-target' to 'data-bs-target', and it has been necessary to change these to enable the functionality to work.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, not all of CSS class changes affecting solely the presentation have been reflected in the updated tutorial code. For example, in the <tt>helloworlds</tt> view, showing the list of helloworld messages, the display of the associations is different from that of other Joomla components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Fonts===
In Joomla 3 [[J3.x:Joomla_Standard_Icomoon_Fonts|Icomoon Fonts]] were used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 Font Awesome's free icons are used, and you can see what is available on their [https://fontawesome.com/v5/cheatsheet cheatsheet]. The icons are implemented using CSS pseudo-elements, as described [https://fontawesome.com/v5/docs/web/advanced/css-pseudo-elements here]. Basically they convert a CSS class into html content, namely a unicode value in the private use range. A couple of these have been implemented in the frontend form, in the Save and Cancel buttons, for example:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>span class="icon-cancel">/span <?php echo Text::_('JCANCEL') ?></tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(with angle brackets removed from the <tt>span</tt> tags to stop the icon just being displayed by the browser).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This class is defined in media/system/css/joomla-fontawesome.css (where you can find the list of icon classes supported):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
.icon-cancel:before {
content: "\f00d";
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so this includes in front of the text the unicode character <tt>f00d</tt>, which you can see on the cheatsheet as "times", and displayed as <span class="icon-cancel"></span>. You can also use <tt>fa-</tt> plus the icon name on the font awesome cheatsheet page. If you use Icomoon icon names in your code which you run under Joomla 4, then the icon displayed will be a Font Awesome icon (if there's one with the same name) or it will use a mapping which the Joomla team have defined to display a Font Awesome icon which resembles the Icomoon one.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Buttons and Links===
An accessibility principle is that <tt><a></tt> html elements should be used for links to other web pages, and <tt><button></tt> elements should be used for actions, eg on a form. To align with this, the <tt><a></tt> elements in the helloworld modal field (defined in admin/src/Field/Modal/Helloworld.php) have been changed to <tt><button></tt> elements. These are the Select and Clear buttons displayed when choosing a Helloworld record for a menuitem pointing to a Helloworld message. (The buttons also include fontawesome icons, by the way).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This change was actually made in Joomla in one of the Joomla 3 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Categories View===
In the Categories view of standard Joomla components there now appears columns which show for each category the number of items, split by published status. This is populated by <tt>com_categories</tt> calling each extension's <tt>countItems</tt> function, as described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_categories|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Miscellaneous Changes==
===Version History===
In Joomla 3 the tutorial code used the <tt>JTableObserver</tt> functionality to copy relevant changes from the Helloworld and Categories tables into the UCM tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it uses a plugin mechanism to subscribe to Table events 'onTableAfterStore' and 'onTableBeforeDelete'. The plugin can be found in plugins/behaviour/versionable, and it is activated by Joomla as part of its application initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The copying of fields from the table works roughly the same way as before, except that the name of the table where the versions are stored is now <tt>#__history</tt>, so the entries which have to be inserted into the <tt>#__content_types</tt> table are fairly similar. Because the folders in which forms are stored has changed in Joomla 4, the 'formFile' parameter is different (remember that this is where Joomla gets the field labels in order to display the Preview within the Versions modal window, otherwise just the names of the database columns will be output).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here's a summary of what needs to be done to enable versioning under Joomla 4. The Versioning Traits and Interface definitions are found in libraries/src/Versioning:
* Enter data into content_types database table
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Storing the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The Table class must implement VersionableTableInterface and provide <tt>getTypeAlias()</tt>, which returns 'com_helloworld.helloworld'. This type alias + the helloworld record id is used as the key to identify versions in the <tt>#__history</tt> table.
* Define <tt>save_history</tt> and <tt>history_limit</tt> options in config.php, and ensure these are both set.
* Add a <tt>version_note</tt> field into the output of the edit view's tmpl file (admin/tmpl/helloworld/edit.php).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Viewing and Restoring the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit Controller (admin/src/Controller/HelloworldController.php) should <tt>use VersionableControllerTrait</tt>.
* The edit Model (admin/src/Model/HelloworldModel.php) should <tt>use VersionableModelTrait</tt> and include a variable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public $typeAlias = 'com_helloworld.helloworld';
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit View (admin/src/View/Helloworld/HtmlView.php) – should display the Versions toolbar button if global config has <tt>save_history</tt> on.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Joomla 4 allows us to have different history version limits for helloworld items and categories, and this has been used in the configuration definition in admin/config.xml.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Setting Configuration Parameters in Install Script===
As you may remember, global configuration parameters relating to the Hello World component are defined in admin/config.xml and stored in the <tt>#__extensions</tt> table, in a JSON string in the params field of the record relating to <tt>com_helloworld</tt>. This means that when the component is first installed the params are not set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So, for example, even if the <tt>save_history</tt> is defined in config.xml to default to true, the versions won't be saved until an administrator actively saves the configuration parameters, because the Joomla versioning code assumes <tt>save_history</tt> to be false if it's not explicitly set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For this reason it makes sense to set any default configuration parameters in the install script.php, in the <tt>postflight</tt> method, and that has been done in this step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Tags===
Like version history, tags functionality has been changed to use a plugin – in plugins/behaviour/taggable – rather than the <tt>JTableObserver</tt> approach.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To enable tags the component table must implement TaggableTableInterface (in libraries/src/Tag), and provide the <tt>getTypeAlias()</tt> which is common to the Versioning functionality.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Whenever <tt>com_tags</tt> outputs helloworld messages or categories relating to a tag it displays them as links, and looks in the site/helpers/route.php file to find the route functions (as described above in [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_tags|com_tags]]). The class and method in this file must match the 'router' field within the data entered into the <tt>#__content_types</tt> table.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===media files===
Under Joomla 4 all of the media files are stored in the /media folder; these include javascript and css files (scss files too), as well as images such as the little flag symbols shown in the language switcher. Extensions being developed should store all of the js and css files in their /media folder, and then when the extension is installed these files are put under the extension's folder under the /media folder of the Joomla instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Patches==
Some bugs in Joomla were discovered during the course of updating the tutorial code to work under Joomla 4. If you find something doesn't work then make sure you're on at least Joomla 4.2.6 and check if you need one of the following patches:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
CategoryAssociationHelper.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39358/files
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
MediaField.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/issues/39203
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Category restore
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39474
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Contributors ==
*[[User:Robbiej|Robbie Jackson]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Prev: Adding Custom Fields|class=expand success}}</div>
</div>
</div>

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/16/it

2023-05-27T12:43:10Z

Quindi Joomla ora si aspetta che tutti i nomi delle classi vengano trovati in quelle directory di base, con il nome del file che corrisponde al nome della classe e il nome della classe completo che corrisponde al percorso, ad esempio

J3.x:Developing an MVC Component/Upgrading to Joomla4/it

2023-05-27T12:43:08Z

Ing Pulizzi: Created page with "<tt>Robbie\Component\Helloworld\Site</tt> – punterà a components/com_helloworld/src sull'istanza live ed è associato a site/src nella nostra area di sviluppo."

<noinclude><languages /></noinclude>

{{:J3.1:Developing an MVC Component/it}}
Questo passaggio copre ciò che è coinvolto nell'aggiornamento del codice del tutorial per allinearlo con la versione 4 di Joomla.

== Introduzione ==
Questa pagina descrive i principali aspetti relativi allo sviluppo dei componenti che sono stati introdotti in Joomla 4 e descrive in dettaglio cosa è stato modificato nel codice del tutorial per allinearsi con v4.

Non è pratico dettagliare tutte le modifiche al codice sulla pagina Web come è stato fatto per i passaggi precedenti dell'esercitazione. Invece puoi trovare il codice come repository github su [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial Joomla 4 Tutorial code], e puoi confrontarlo con il codice del passaggio precedente del tutorial (Adding Custom Fields) su [https://github.com/robbiejackson/Joomla-3-MVC-Tutorial Joomla 3 MVC code]. Il codice di Joomla 4 replica tutte le funzionalità del codice di Joomla 3, con l'eccezione dell'implementazione dell'icona del piccolo pinguino introdotta in [[S:MyLanguage/J3.2:Developing an MVC Component/Adding decorations to the backend|Aggiunta di decorazioni al backend]] (che non è così rilevante data la modifica dell'interfaccia utente in Joomla 4 Administrator) e l'uso di un plug-in CAPTCHA ([[J3.x:Developing an MVC Component/Adding a frontend form|Adding a frontend form]] ). Probabilmente troverai utile avere a portata di mano questo codice Joomla 4 a cui fare riferimento mentre leggi questa pagina.

Il codice per questo passaggio è stato sviluppato seguendo ciascuno dei precedenti passaggi del tutorial e cercando di far funzionare ogni passaggio con Joomla 4.2.5. Poiché Joomla 4 si sta ancora evolvendo abbastanza velocemente, è possibile che alcuni aspetti qui citati vengano modificati durante la vita di Joomla 4. Sentiti libero di correggere gli aspetti in questa pagina e creare richieste pull su [https://github.com/robbiejackson /Joomla-4-MVC-Tutorial Joomla 4 github repository].

Se stai installando il codice del tutorial di Joomla 4 su una nuova istanza di Joomla, dovrai configurare la tua istanza per renderla multilingue e aggiungere le voci di menu nascoste di Ajax come descritto nel passaggio [[J3.x:Developing an MVC Component/ Utilizzo del filtro della lingua |Utilizzo del filtro della lingua]]. Assicurati inoltre che ogni record helloworld abbia una categoria valida.

=== Ulteriori letture ===
Puoi trovare [https://blog.astrid-guenther.de/en/der-weg-zu-joomla4-erweiterungen/ qui] un tutorial per lo sviluppo dei componenti di Joomla 4, simile a questo Joomla 3, e alcuni eccellenti Joomla 4 è disponibile anche la documentazione [https://www.dionysopoulos.me/book.html qui]. Entrambi questi riferimenti includono descrizioni degli impatti di Joomla 4 sullo sviluppo di altri tipi di estensioni Joomla (plugin, moduli e modelli), che non sono trattati qui.

Questo passaggio non copre tutto ciò che è necessario per aggiornare un componente da Joomla 3 a Joomla 4, solo gli aspetti coperti dal codice del tutorial. Se stai aggiornando il tuo componente Joomla 3, potresti trovare utile esaminare [[Potenziali problemi di compatibilità con le versioni precedenti in Joomla 4]].

== NameSpace ==
===NameSpace dei nomi dei componenti===
I NameSpace delle classi che utilizza la [https://www.php-fig.org/psr/psr-4/ PSR-4 recommendation] è stato gradualmente introdotto durante le versioni di Joomla 3 e con Joomla 4 è praticamente tutto con NameSpace

Ora è previsto che anche le estensioni di Joomla utilizzino i NameSpace di base per l'estensione definito nel suo file XML manifest. I componenti di Joomla usano uno NameSpace della forma <tt>Joomla\Component\<Nome componente></tt> es. <tt>Joomla\Component\Content</tt>, quindi seguendo questo schema ho dato una base al codice del tutorial spazio dei nomi di <tt>Robbie\Component\Helloworld</tt>. Ecco la riga nel file manifest helloworld.xml:

<namespace path="src">Robbie\Component\Helloworld</namespace>

(L'attributo <tt>path="src"</tt> indica che si aspetterà che le classi si trovino nella sottocartella <tt>src</tt>.)

Questo in realtà crea 2 prefissi dello spazio dei nomi, che puntano a cartelle specifiche nella nostra struttura di sviluppo helloworld e nella nostra istanza joomla live:

<tt>Robbie\Component\Helloworld\Administrator</tt> – punterà ad administrator/components/com_helloworld/src sull'istanza live ed è associato ad admin/src nella nostra area di sviluppo.

<tt>Robbie\Component\Helloworld\Site</tt> – punterà a components/com_helloworld/src sull'istanza live ed è associato a site/src nella nostra area di sviluppo.

<div lang="en" dir="ltr" class="mw-content-ltr">
So Joomla now expects all classes names will be found under those base directories, with file name matching the class name, and the fully qualified classname matching the path eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> will be found in
administrator/components/com_helloworld/src/Controller/DisplayController.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> will be found in
components/com_helloworld/src/Model/CategoryModel.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Note that capitalization is important in namespaces, names of classes and path names!'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla 3 wanted to call functions in your component it looked for certain file names in particular folders, and checked that the name of the class in that file matched what it expected.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it generates the fully qualified name of the class it wants to find, and then looks to find it in the location where the PSR-4 recommendation would expect it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Hence the namespace you specify in your class files must align with the file path to your PHP file, below the base <tt>src</tt> folder at your namespace prefix.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note in particular how the <tt>View</tt> class files are now organised.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Also if you use one of the PHP predefined classes (eg <tt>Exception</tt>) in your code, then add a backslash before it (eg <tt>\Exception</tt>), otherwise PHP will try and find it in your namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you use custom Field or Rule definitions in your form xml files then you have to indicate to PHP which namespace prefix to use to look for them, eg in <tt>site/forms/add-form.xml</tt>:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
addruleprefix="Robbie\Component\Helloworld\Administrator\Rule"
addfieldprefix="Robbie\Component\Helloworld\Administrator\Field"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and also in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> where the associations are added into the form dynamically to form the custom <tt>modal_helloworld</tt> type field:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Class Autoloading===
Joomla uses the PHP mechanism for [https://www.php.net/manual/en/language.oop5.autoload.php Autoloading Classes] and on startup registers a number of autoloaders – functions which get called when PHP can't find a given class. In particular the Joomla PSR-4 autoloader function (in <tt>libraries/loader.php</tt>) is responsible for finding classes of Joomla extensions whose code is in source files which are organised according to the PSR-4 recommendation. (Joomla library classes are autoloaded using a different autoloader – see <tt>libraries/vendor/composer/autoload_static.php</tt>).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can see the namespace prefixes of extensions on the Joomla instance by looking at <tt>administrator/cache/autoload_psr4.php</tt>. (These namespace strings have double backslashes, but in PHP they're the [https://stackoverflow.com/questions/25459197/single-or-double-slash-when-using-php-namespace same strings as those with single backslashes]). This is generated by Joomla looking through the component, module and plugin directories to find each extension's manifest file, and then processing these xml files to extract the <tt><namespace></tt> element – quite a lot of work, which is why it's cached I guess!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider what happens when Joomla wants our admin HelloworldController class. It might have something like
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$classname = 'Robbie\Component\Helloworld\Administrator\Controller\HelloworldController'
if (!class_exists($classname)) { …
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Assuming PHP doesn't already know about this class, the <tt>class_exists</tt> function will result in the classname being passed to the registered autoload function(s). The PSR-4 autoloader will then:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# go through its array of namespaces to try and match <tt>$classname</tt> from the start of the string.
# find 'Robbie\Component\Helloworld\Administrator' as a match
# see that this maps to "administrator/components/com_helloworld/src"
# extract the remainder of the classname: 'Controller\HelloworldController'
# treat this as the path down to the class file
# and so look for "administrator/components/com_helloworld/src/Controller/HelloworldController.php"
# check that in this file there's actually a class with that namespace + class name.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So in this way Joomla can go from a fully qualified class name to find the source code for that class. This makes it easier for us too when the core Joomla code is looking for one of our classes. We still need to know what class it's looking for, but once we know that, we know what we should call our class and where we should save the source code for it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Joomla Library classes===
Originally Joomla's core classes (beginning with a capital J) were global classes. Over the Joomla 3 versions and into Joomla 4 these migrated to their namespaced equivalents, but the original global classnames were still available as Joomla registered them as aliases (in the <tt>libraries/classmap.php</tt> file).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In a Joomla 4 extension you can still use these global classnames, except that in a namespaced file you'd have to prefix the name with a backslash to indicate a global class rather than one in your namespace (eg <tt>\JFactory</tt> instead of <tt>JFactory</tt>).
However it's pretty definite that the aliases will disappear at some stage, so the upgrade to Joomla 4 seems an appropriate opportunity to replace all your component's calls to the global JSomething classes to the namespaced equivalents. This involves adding the appropriate <tt>use</tt> statements, and all this has been done in the tutorial code. A useful mapping between the two can be found [https://github.com/nikosdion/joomlatypehints/blob/main/JoomlaObsoleteClasses.md here], where the new qualified classname can be copied and pasted into a <tt>use</tt> statement in your PHP file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
With reference to the [https://api.joomla.org/ Joomla API Documentation] there are 2 Joomla library namespaces:
* Joomla CMS classes – have namespaces <tt>Joomla\CMS\Something</tt> – are found under <tt>libraries/src/Something</tt>
* Joomla Framework classes – have namespaces <tt>Joomla\Something</tt> – are found under <tt>libraries/vendor/joomla/something/src</tt>
So a big advantage of namespacing is that you can immediately determine from the fully qualified class name in a PHP <tt>use</tt> statement where the source for that class exists in the <tt>libraries</tt> directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
On the other hand class names which aren't fully qualified don't have to be unique, eg <tt>MVCFactory</tt>
* occurs as <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in <tt>libraries/src/Extension/Service/Provider/MVCFactory.php</tt>
* occurs as <tt>Joomla\CMS\MVC\Factory\MVCFactory</tt> in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>
so sometimes you have to be careful to examine the <tt>use</tt> statement to identify the right class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly our FormModel class in <tt>site/src/Model/FormModel.php</tt> can have the same FormModel classname as the Joomla FormModel in <tt>libraries/src/MVC/Model/FormModel.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The API documentation gives the methods available in each of the [https://api.joomla.org/cms-4/namespaces/joomla.html Joomla CMS] and [https://api.joomla.org/framework-2/namespaces/joomla.html Framework] classes, but just be aware that a Joomla CMS class may extend a Framework class, and in this case some methods may not be visible under the Joomla CMS documentation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For example, <tt>$app->setHeader()</tt> which is used to set the HTTP response code is not listed under the [https://api.joomla.org/cms-4/classes/Joomla-CMS-Application-CMSApplication.html CMS Application class API], but is available as a method because it inherits from the Framework class [https://api.joomla.org/framework-2/classes/Joomla-Application-AbstractWebApplication.html AbstractWebApplication].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Vendor Namespaces===
These are also in <tt>libraries/vendor</tt>, eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Psr\Container\ContainerInterface;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
refers to <tt>libraries/vendor/psr/Container/src/ContainerInterface.php</tt>. However there are few of these in the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other File Rearrangements===
With all of the namespaced classes moving under the src directories, the <tt>tmpl</tt> layout files and <tt>form</tt> xml files have been moved out into their own directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Extension and Dispatcher classes ==
===Extension===
In Joomla 3 the point where the Joomla core handed over to your component code was when it ran your <tt>helloworld.php</tt> code; if it was the frontend it ran your site <tt>helloworld.php</tt> code, or if was the backend it ran your admin <tt>helloworld.php</tt> code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the entry point into your component code is your Extension class, both for site and admin, found in <tt>admin/src/Extension/HelloworldComponent.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When the Joomla core application wants to start executing the component code it creates an instance of <tt>HelloworldComponent</tt>, just to get a handle on the component code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly (as described below) other Joomla classes such as Router or Categories need to call certain Helloworld methods (eg custom router functions). In Joomla 3 these methods were written in certain Helper files etc. In Joomla 4 the principle is that the component creates an instance of the <tt>HelloworldComponent</tt> Extension class, and calls the required methods on that instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This Extension class isn't anything like a big container class for the component, it's more like a glue class, providing a way in to the Helloworld component, enabling the Joomla core and other components call the methods which they want to call.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla core wants to execute the component code, the key method it is looking for in your <tt>Extension</tt> instance is <tt>getDispatcher</tt>, and it expects to get back a <tt>Dispatcher</tt> instance. The <tt>HelloworldComponent</tt> extends <tt>MVCComponent</tt>, which in turn extends <tt>Component</tt>, and it is this class which defines <tt>getDispatcher</tt> for us.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Dispatcher===
When Joomla wants to run the Hello World component, it gets the <tt>Dispatcher</tt> instance as described above and then calls the <tt>dispatch</tt> method on it. It is this <tt>dispatch</tt> function which replaces the functionality in the admin and site <tt>helloworld.php</tt> files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's look at the main lines of code in our Joomla 3 admin <tt>helloworld.php</tt> file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="site/views/form/view.html.php">
<syntaxhighlight lang="php">
if (!JFactory::getUser()->authorise('core.manage', 'com_helloworld'))
{
throw new Exception(JText::_('JERROR_ALERTNOAUTHOR'));
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Get an instance of the controller
$controller = JControllerLegacy::getInstance('HelloWorld');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Execute the Request task method
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Redirect if set by the controller
$controller->redirect();
</syntaxhighlight>
</span>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code
* performs some permissions checks
* instantiates the appropriate Helloworld controller
* executes the appropriate method in that controller
* implements any redirect set by the controller
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Model-View-Controller]] for further details of how this works in Joomla 3. The second and third steps used the <tt>task</tt> parameter within the URL query to determine the correct controller class to instantiate and method to call. If no <tt>task</tt> parameter was present then it instantiated the controller in <tt>controller.php</tt> and called the <tt>display</tt> method. Otherwise it instantiated one of the controllers in the <tt>controllers</tt> subfolder (eg <tt>controllers/helloworld.php</tt>) and called the appropriate method on it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>ComponentDispatcher::dispatch</tt> method (in <tt>libraries/src/Dispatcher/ComponentDispatcher.php</tt>) now provides this functionality, but in a nicer way. After checking the permissions it uses the <tt>task</tt> by considering its parts as <tt><controller type>.<method></tt> (taking 'display' as default if either part is missing). It will then pass control to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* an instance of the class <Controller type>Controller
* calling the function <method>
* using the admin or site controller, as appropriate
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In this way the naming of the controllers is consistent - we have DisplayController, HelloworldController and HelloworldsController, all in the same folder.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Dispatcher class can thus be considered as providing some 'routing - execution' functionality, enabling us to find the right controller and function within that controller, and it is cleaner to have this in a separate class rather than in the <tt>JControllerLegacy</tt> class as it was in Joomla 3.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Since the Hello World tutorial uses the standard Joomla pattern for selecting the class and method based on the <tt>task</tt> and has the same permissions checks, we can use the <tt>dispatch</tt> code as it stands in <tt>ComponentDispatcher</tt>, and don't need to define a special class of our own.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Factory classes ==
In Joomla 3 many classes had static <tt>getInstance</tt> methods which returned an instance of that class, configured with the parameters passed to <tt>getInstance</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the <tt>getInstance</tt> methods have been deprecated in favour of using Factory classes. The preferred mechanism is now to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* get an instance of the appropriate Factory class (how we do that is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below)
* call the <tt>createSomething()</tt> method of the Factory class with relevant parameter values to generate an instance of the Something class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===MVC Factory===
In this section the <tt>MVCFactory</tt> class refers to the one in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory class will instantiate Controller, View, Model and Table instances on our behalf, and it does this by generating the classname of the class and then calling <tt>new</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The way it works is as follows:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Each component gets an individual MVCFactory instance which is constructed passing the component's namespace as a parameter (so in our case 'Robbie\Component\Helloworld'). (How this MVCFactory instance is created is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below).
# The MVCFactory createController / createView / createModel / createTable function is then called, passing the name of the Controller / Model / View / Table and the prefix (which specifies whether the administrator or site class is required).
# The create function forms the classname from this data and calls <tt>new</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory create functions just form the classname from the parameters they're passed. The intelligence for working out what name and prefix should be used to form the appropriate classes for an incoming HTTP request is
* in the dispatcher code for defining the controller to use
* in the controller for the view and model
* in the model for the table
and, for example, the names of the classes created for a request with URL query <tt>?option=com_helloworld&view=viewname</tt> and no <tt>task</tt> parameter will be
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<namespace>\Controller\DisplayController
<namespace>\View\Viewname\HtmlView
<namespace>\Model\ViewnameModel
<namespace>\Table\ViewnameTable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you need an alternative name then you can override the appropriate getView, getModel or getTable function – as for example was done in the [[J3.x:Developing an MVC Component/Adding Custom Fields#Front-end_Form|Adding Custom Fields step, frontend Form section]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So from the outside this is pretty much the same as in Joomla 3. However, note that the <tt>$prefix</tt> parameter in calls to <tt>getModel</tt> etc is subtly different
* in Joomla 3 this referred to a prefix to be applied to the classname – in the tutorial code we used 'HelloWorldTable' as the prefix part of the 'HelloWorldTableHelloWorld' classname.
* in Joomla 4 this refers to a prefix higher up the classname path, and should be set to either 'Site' or 'Administrator' (the capital letter at the start is optional), depending on whether you want the class under 'Robbie\Component\Helloworld\Site' or 'Robbie\Component\Helloworld\Administrator'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVC Factory class is now the Joomla recommended way to create the controller, view, model and table classes, by using the eg <tt>getModel()</tt> method, and the use of <tt>getInstance()</tt> for these classes is now deprecated. However, the use of these functions is restricted:
* in the controller class you can call <tt>$this->getView($viewname, $viewtype, $prefix, $config)</tt> to create a view and <tt>$this->getModel($modelname, $prefix, $config)</tt> to create a model.
* in the view class you can call <tt>$this->getModel($modelname)</tt>, but only for models which the controller has previously defined using <tt>$view->setModel($modelname, $default)</tt>. It doesn't create a new model instance.
* in the model class you can call <tt>$this->getTable($tableclass, $prefix, $options)</tt> to create a table instance. Controllers and views can access the table classes in this way, by going via a model.
These restrictions do have an impact on moving away from using <tt>getInstance()</tt>, and indeed in Joomla 4.2.6 you will still find several <tt>getInstance()</tt> calls within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Factory Classes===
Several other Factory classes have been introduced in Joomla 4, enabling you to get instances of core classes such as Form, User, CacheController, etc, usually by calling a createSomething function on the Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Associated with the Factory class is a FactoryInterface, a PHP Interface which specifies the key functions which the Factory class must implement. For example, with <tt>libraries/src/Categories</tt> we have:
* CategoryFactoryInterface – which specifies the <tt>createCategory</tt> function
* CategoryFactory implements CategoryFactoryInterface – which provides the <tt>createCategory</tt> function.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Dependency Injection ==
===Overview===
The DI container is one of the significant new additions to Joomla 4. It's basically a repository of key-value pairs where:
* the key is a string which is the name of a class or interface
* the value is an instance of the relevant class, or a function that returns an instance of that class.
You put things into the container using <tt>set()</tt> passing:
* the class name or interface name
* a function which returns an instance of the class (or an instance of the class)
* a boolean defining whether the class instance may be shared or not
* a boolean defining whether this entry into the DI container is protected or not (an error will be raised if you try to overwrite a protected entry by calling <tt>set()</tt> again using the same key).
The function <tt>share()</tt> is basically the same as <tt>set()</tt> with the <tt>shared</tt> boolean set to true.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You get things out of the container by calling <tt>get()</tt> passing the key of the resource you want. The container will
* find the key in the container
* if the value isn't already a class instance, then it will run the associated function to generate an instance of the class
* if the resource is shared, it will store the class instance, so that on subsequent invocations of <tt>get()</tt> it can just return the instance
* return the class instance to you
You can also define aliases for each key in the container, which means that you call <tt>get()</tt> passing either the key or an alias of the key.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The DI container is initialised in <tt>library/src/Factory.php createContainer()</tt> which results in the <tt>register()</tt> function being called in each of the class files in <tt>libraries/src/Service/Provider</tt>. By looking through those files you can see what gets put into the DI container upon initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===JConfig Example===
Let's consider the example of JConfig which holds the system global configuration. If you look inside <tt>libraries/src/Service/Provider/Config.php</tt> then you'll see the <tt>register()</tt> function and that it stores in the DI container a resource with:
* key = 'JConfig'
* value = an anonymous function - which loads what's in <tt>configuration.php</tt> into a <tt>Registry</tt> object, and returns it
* shared flag = true (because the <tt>share()</tt> function is used)
* protected flag = true
Then when you do
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$config = $container->get('JConfig');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will run the anonymous function and return the Registry object to you. As the 'shared' boolean is set it will also store a copy of the class instance locally in the container to be returned on subsequent calls of <tt>get('JConfig')</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Justification===
What's the point of all this?
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The advantage of dependency injection is that it allows classes to be easily mocked for testing. The file <tt>libraries/src/Service/Provider/Config.php</tt> can be replaced to return to a DI container <tt>get()</tt> call a mock class instead of the usual <tt>JConfig</tt>. This is in comparison to Joomla 3 where <tt>Factory::getConfig()</tt> code directly reads the <tt>configuration.php</tt> into a Registry structure and returns it – which makes it harder to mock.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The [https://api.joomla.org/cms-4/classes/Joomla-CMS-Factory.html Factory API] has several functions which are marked as deprecated with advice to get the object from the DI container instead.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Several of the other Factory classes (eg Form, Language, Menu, User) are in the DI container – so that we can get an instance of them via eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Factory::getContainer()->get('Joomla\CMS\Toolbar\ToolbarFactoryInterface')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to get a Toolbar instance. However, this only works for singleton classes which aren't specific to the needs of a particular extension. We'll see shortly how to make it work for class instances which need to be specific to a component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As indicated above, Joomla is moving away from using the class static <tt>getInstance()</tt> functions. We can see now that this is not only because it's more pure from an object oriented perspective. But also creating class instances from the DI container, or from Factory objects which are obtained from the DI container, builds in the dependency injection which allows classes to be more easily mocked, and hence more easily tested.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==services/provider.php==
We're now finally in a good position to understand what's happening in our services/provider.php file, and we'll explore this by walking through what happens whenever this line in libraries/src/Component/ComponentHelper.php <tt>renderComponent</tt> is run:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is run whenever Joomla has worked out which component is to be run on the requested web page, and it wants to run that component to capture its output.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 1 Create Child DI Container===
Joomla first creates another DI container (initially empty) just for this component, and links it to the main DI container via a parent field in the child DI container structure.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Now whenever <tt>set()</tt> is called on this DI container the key-value pair is inserted into the child container. Whenever <tt>get()</tt> is called on it, the resource is obtained from the child container, but if it's not found there then the parent container is searched also.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 2 Run register() in provider.php===
Next we encounter these lines (in <tt>libraries/src/Extension/ExtensionManagerTrait.php</tt>), where <tt>$path</tt> contains the path of our helloworld admin/services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$provider = require_once $path;
// Check if the extension supports the service provider interface
if ($provider instanceof ServiceProviderInterface) {
$provider->register($container);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here we see 3 things:
# our provider.php should return some object (so that <tt>$provider</tt> gets set to something)
# what is returned should implement ServiceProviderInterface (you can see in <tt>libraries/vendor/joomla/di/src/ServiceProviderInterface.php</tt> what is expected)
# the code then runs the <tt>register</tt> function on that object, passing as a parameter the child DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider a minimal version of our provider.php file. This would actually support steps in the Joomla 3 tutorial up to and including the [[J3.x:Developing an MVC Component/Adding AJAX|Adding Ajax step]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {

public function register(Container $container): void
{
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
}
};
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As you can see from the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
this file does indeed return something – it returns an instance of an anonymous class, one that implements <tt>ServiceProviderInterface</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it's not sufficient to just provide the <tt>register</tt> function in the class, we also need to explicity state that the class implements <tt>ServiceProviderInterface</tt>. This now happens in several places in Joomla, so if you're debugging your component and wondering why a function you expect to be called isn't being called, then check to make sure that you don't have to explicitly add the appropriate <tt>implements <Interface></tt> clause to your class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Next we look at the 3 lines in the <tt>register</tt> function
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3a Registering our MVC Factory===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here our <tt>MVCFactory</tt> refers to <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in libraries/src/Extension/Service/Provider/MVCFactory.php, and you should have a look at this file. This is a file similar to our provider.php file, but it's a named class, and it doesn't return anything. When we do:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
new MVCFactory('\\Robbie\\Component\\Helloworld')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it creates an instance of this class, and in the constructor it stores locally in <tt>$this->namespace</tt> our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>registerServiceProvider</tt> function then calls the <tt>register</tt> function of this instance, which runs (in its minimalist form):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
MVCFactoryInterface::class,
function (Container $container) {
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
return $factory;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So what gets entered into our child DI container is a key-value pair with:
* key = MVCFactoryInterface::class (this is just a shorthand form to obtain a string of the fully qualified name – ie 'Joomla\CMS\MVC\Factory\MVCFactoryInterface')
* value = a function which returns an instance of <tt>\Joomla\CMS\MVC\Factory\MVCFactory</tt>.
This is our MVCFactory class which generates our Controllers, Views, Models and Tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Notice that we're passing our namespace as a parameter <tt>$this->namespace</tt>. Because this function is a closure, this variable will still be available when we run this function later, and when the MVCFactory class is instantiated the namespace will be passed into the constructor, stored locally, and then subsequently used to form the fully qualified names of our Controllers, View, etc. So this is how we get instantiated the MVCFactory class which is specific to our component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3b Registering the Dispatcher Factory===
Careful: ComponentDispatcherFactory refers to two different classes here!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This ComponentDispatcherFactory is Joomla\CMS\Extension\Service\Provider\ComponentDispatcherFactory in libraries/src/Extension/Service/Provider/ComponentDispatcherFactory.php. Similar to the above, the ComponentDispatcherFactory service provider class stores locally our namespace, and then when <tt>register</tt> is called it executes:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentDispatcherFactoryInterface::class,
function (Container $container) {
return new \Joomla\CMS\Dispatcher\ComponentDispatcherFactory($this->namespace,$container->get(MVCFactoryInterface::class));
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so a second entry is added to the child DI container with:
* key = ComponentDispatcherFactoryInterface::class
* value = a function which returns an instance of the ComponentDispatcherFactory (the other ComponentDispatcherFactory class!), where the class constructor will be passed the namespace ('\\Robbie\\Component\\Helloworld') and an MVCFactory instance, retrieved from the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that the code
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->get(MVCFactoryInterface::class)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
will get from the container an entry with key = 'Joomla\CMS\MVC\Factory\MVCFactoryInterface' – which is what we entered into the container in step 3a – and will run the function associated with this key, and then return the object which this function returns. This returned object will be an instance of '\Joomla\CMS\MVC\Factory\MVCFactory', constructed using our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3c Including the Extension===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will put into the child DI container a key-value pair with
* key = ComponentInterface::class
* value = the function which will create an instance of our <tt>HelloworldComponent</tt> (ie our Extension class), and pass into the constructor an instance of the ComponentDispatcherFactory class, retrieving what was entered into the child DI container in Step 3b.
It will call <tt>$container->get(MVCFactoryInterface::class)</tt>, getting an MVC Factory instance from what was entered into the DI container in Step 3a.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It will then associate our component with this MVC Factory instance via the <tt>setMVCFactory</tt> call. Significantly this will then allow our component to access this instance later, via a call to <tt>getMVCFactory</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3 Summary===
We have now got 3 entries in our child DI container, keyed by
* key = MVCFactoryInterface::class, value is a function returning an MVCFactory instance
* key = ComponentDispatcherFactoryInterface::class, value is a function returning a ComponentDispatcherFactory instance
* key = ComponentInterface::class, value is a function returning our HelloworldComponent, an instance of our Extension class.
The important aspect is that these entries are all aware of our namespace '\Robbie\Component\Helloworld' and will return instances of these classes which are specific to our Helloworld component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 4 Retrieving from the DI Container===
Joomla will then execute the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $container->get($type);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
where <tt>$type</tt> contains 'Joomla\CMS\Extension\ComponentInterface'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This starts the process of retrieving from the DI container the 3 entries which we put in, and will run our code in services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We end up with a HelloworldComponent instance, which has:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. a ComponentDispatcherFactory instance passed into the constructor, and which is saved locally by the constructor code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function __construct(ComponentDispatcherFactoryInterface $dispatcherFactory)
{
$this->dispatcherFactory = $dispatcherFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This code is in libraries/src/Extension/Component.php, in the class which our HelloworldComponent extends, via the class MVCComponent).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. an MVC Factory instance, stored by the HelloworldComponent <tt>setMVCFactory</tt> call
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 5 Call boot() on our Component===
Joomla calls:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
if ($extension instanceof BootableExtensionInterface) {
$extension->boot($container);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will call <tt>boot</tt> within our HelloworldComponent, and allows us to perform some initialisation within our component. We'll return to this later, in the section on [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#HTML_Snippets|HTML snippets]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note again that Joomla checks that our HelloworldComponent class implements BootableExtensionInterface before calling <tt>boot</tt>. It's not sufficient to just provide the <tt>boot</tt> function, we have to explicitly declare that our HelloworldComponent implements the interface.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 6 Get the Dispatcher===
Returning to our key line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
we have now accomplished the first part <tt>bootComponent($option)</tt>, and this has returned our HelloworldComponent instance. Now we call <tt>getDispatcher($app)</tt> on this instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This code is also in libraries/src/Extension/Component.php, in the Component class which our HelloworldComponent extends:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function getDispatcher(CMSApplicationInterface $application): DispatcherInterface
{
return $this->dispatcherFactory->createDispatcher($application);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We call <tt>createDispatcher</tt> on our ComponentDispatcherFactory class instance which we saved in Step 4. This code is in libraries/src/Dispatcher/ComponentDispatcherFactory.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createDispatcher(CMSApplicationInterface $application, Input $input = null): DispatcherInterface
{
$name = ucfirst($application->getName());

$className = '\\' . trim($this->namespace, '\\') . '\\' . $name . '\\Dispatcher\\Dispatcher';

if (!class_exists($className)) {
if ($application->isClient('api')) {
$className = ApiDispatcher::class;
} else {
$className = ComponentDispatcher::class;
}
}

return new $className($application, $input ?: $application->input, $this->mvcFactory);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code checks if we have our own Dispatcher class (our Helloworld tutorial doesn't, but <tt>com_users</tt> for example has its own). So it creates a <tt>ComponentDispatcher</tt> instance, and passes into its constructor the MVC Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that this ComponentDispatcherFactory instance is what was instantiated when it was retrieved from our child DI Container (from being inserted in step 3b), and hence it already knows about our namespace, and has a pointer to our MVCFactory class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 7 call dispatch()===
This is the final aspect to our line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We're now back to what was described in the Dispatcher section above, except that now we can see that this Dispatcher instance has a pointer to our MVC Factory instance (which knows about our namespace prefix), so when the Dispatcher code wants to create a Controller it can use that MVC Factory instance to instantiate it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's been a long and tortuous journey to get here, but the significant thing is that all of our key class instances have been obtained via the DI Container. If we want to mock out any of those classes for testing then all we need to do is replace the relevant services/provider file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Javascript and the Web Asset Manager ==
The web asset manager has been introduced in Joomla 4 and is well documented [[J4.x:Web_Assets|here]]. It provides a much-improved means of managing JS and CSS resources, and a framework for handling their dependencies.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Component Javascript and CSS files should now be stored in the <tt>media</tt> folder, and the Web Asset Manager used to register them and output them on specific web pages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following assets have been registered in the tutorial <tt>joomla.asset.json</tt>, and you should have a look at that file now.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.validate-greeting===
This is the code for client validation of the helloworld greeting field using a regex, and it is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it is dependent upon jQuery and the Joomla <tt>form.validator</tt> script, so those both get included as dependencies.
If we didn't have specific validation on our form then we would need to include explicitly the <tt>form.validator</tt> script in order for the basic Joomla field validation to be included, eg in the tmpl file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->document->getWebAssetManager()->useScript('form.validate');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that this requires us to have a <tt>class="form-validate"</tt> on the </tt><form></tt> html element.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.fix-permissions-ajax-call===
This is the code which copies the value from the greeting field into the title field, so that the Ajax calls setting the permissions work correctly. The js code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.enable-tooltips===
This is the code which enables bootstrap tooltips to operate, including allowing them to include html code. It's used to display the image as a tooltip within the admin <tt>helloworlds</tt> view.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.openstreetmap===
This is defined as a preset, comprising the helloworld js and css code for the map display, as well as the dependency named 'com_helloworld.openlayers' relating to the openlayers CSS and js code. The code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.admin-helloworlds-modal===
This is the js code for selecting an individual helloworld record within a modal, and passing its details to the form in the main window. Its code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===submitbutton.js===
In the Joomla 3 code we introduced in [[Special:MyLanguage/J3.2:Developing_an_MVC_Component/Adding_verifications|Adding Verifications]] a js file which controlled when the form was submitted. It differentiated between buttons such as <tt>Save</tt> (which submitted the form) and <tt>Cancel</tt> (which didn't).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 there is a more sophisticated version of <tt>Joomla.submitbutton</tt> (found in media/system/js/core.js) which uses the CSS classes which the Toolbar functionality sets on the buttons to determine whether the form should be submitted or not. And you can override whether the validation is performed by adding a third parameter to the <tt>submitbutton</tt> js call. For example, to avoid validation being performed when a button is clicked you can set on the button element:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
onclick="Joomla.submitbutton('controller.method', '', false)"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As this is sufficient for what we need in the tutorial, the custom <tt>submitbutton.js</tt> has been removed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Interaction with other components ==
The way that Joomla interacts with components has changed in Joomla 4. In general the Joomla functionality will boot the component using something like:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $app->bootComponent($option);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and in our case this will return an instance of the <tt>HelloworldComponent</tt> class. It will then try to call certain methods on our extension object, as described below.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_categories===
In the backend the helloworld functionality can display to the administrator
* the view of the helloworld messages
* the view of the helloworld categories
The categories view is generated by <tt>com_categories</tt>, and in Joomla 4 these component categories views display the number of component records there are for each of the possible published status values. To do this the categories component executes the following code (in administrator/components/com_categories/src/Model/CategoriesModel.php):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof CategoryServiceInterface) {
$component->countItems($items, $section);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So our HelloworldComponent must:
* declare that it implements <tt>CategoryServiceInterface</tt>
* provide an implementation of <tt>countItems</tt>
We provide <tt>countItems</tt> by using a trait in libraries/src/Categories/CategoryServiceTrait.php, which (with the assistance of a helper function) does the query on our behalf. We just need to tell it:
* the name of our table – in the callback <tt>getTableNameForSection</tt>
* the database field in which we hold the published status – in <tt>getStateColumnForSection</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_associations===
Remember that <tt>com_associations</tt> is the component which is run whenever you click on Multilingual Associations in the admin backend.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Under Joomla 3 we provided an associations helper file as described in [[J3.x:Multilingual Associations/Developers|Multilingual Associations/Developers]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the helper file remains basically the same, but <tt>com_associations</tt> primarily tries to find the helper file via the extension class; here's the code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($extensionName);
if ($component instanceof AssociationServiceInterface) {
return $component->getAssociationsExtension();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's expecting that:
* the extension (HelloworldComponent in our case) implements <tt>AssociationServiceInterface</tt>
* its <tt>getAssociationsExtension</tt> method returns the helper class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The easiest thing would be just to code <tt>getAssociationsMethod</tt> and get it to return <tt>new AssociationsHelper</tt>. However, we follow the Joomla 4 principle of putting key classes into the Dependency Injection container, and retrieving them later, by having the following code in our services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(AssociationExtensionInterface::class, new AssociationsHelper());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The above line puts a key-value pair into our child DI container
* key = 'Joomla\CMS\Association\AssociationExtensionInterface'
* value is an instance of our <tt>AssociationsHelper</tt> class.
We then retrieve it later and use the setter:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setAssociationExtension($container->get(AssociationExtensionInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so that whenever
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getAssociationExtension()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
is called it returns the <tt>AssociationsHelper</tt> class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_fields===
<tt>com_fields</tt> is the component which is run when an administrator clicks on the Fields or Field Groups menuitem within the backend, and this functionality was included in the [[J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Adding Custom Fields]] tutorial step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>com_fields</tt> component stores the custom fields and field groups for all components in the database tables <tt>#__fields</tt> and <tt>#__fields_groups</tt>, and these tables are partitioned into "sections", one section per component. For our helloworld component the section is named "helloworld".
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within the section we have 2 "contexts" – one for the helloworld messages (called "com_helloworld.helloworld") and one for the helloworld categories (called "com_helloworld.categories"). This enables us to define custom fields for both our helloworld records and helloworld category records.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When <tt>com_fields</tt> runs it checks both the section and contexts at various times. For example, when an admin selects Helloworld / Fields on the backend then <tt>com_fields</tt> checks the section which was defined in the menuitem in the manifest file (see [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Sidebar|below]]). Here's the code in administrator/components/com_fields/src/Helpers/FieldsHelper <tt>extract</tt> function:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
$newSection = $component->validateSection($parts[1], $item);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And when <tt>com_fields</tt> wants to display the little dropdown menu of contexts (to allow the administrator to set custom fields on either helloworld items or categories) it calls (in administrator/components/com_fields/src/Fields/FieldcontextsField.php <tt>getOptions()</tt>):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
return $component->getContexts();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So it's clear that our component extension class must :
* implement <tt>FieldsServiceInterface</tt>
* provide the <tt>validateSection</tt> and <tt>getContexts</tt> methods
So in upgrading to Joomla 4 we've just moved those two methods from the helper file to the extension class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Router===
The Joomla router will access our custom router code:
* whenever it wants to parse an SEF route which it has identified as belonging to <tt>com_helloworld</tt>
* whenever it wants to build an SEF route from a call to <tt>Route::_()</tt> where the option = "com_helloworld".
To find our custom router it will:
* boot the <tt>com_helloworld</tt> extension
* check that the extension implements <tt>RouterServiceInterface</tt>
* call <tt>createRouter</tt> on our extension instance
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In our services/provider.php file we have (careful again - 2 different RouterFactory classes!):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new RouterFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which from libraries/src/Extension/Service/Provider/RouterFactory.php puts into our child DI container an entry with:
* key = "Joomla\CMS\Component\Router\RouterFactoryInterface"
* value is a <tt>\Joomla\CMS\Component\Router\RouterFactory</tt> instance, constructed with our namespace
We then retrieve this in the line in our services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setRouterFactory($container->get(RouterFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And then within our extension class we have
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use RouterServiceTrait;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which includes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function setRouterFactory(RouterFactoryInterface $routerFactory)
{
$this->routerFactory = $routerFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which stores the <tt>routerFactory</tt> locally and
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return $this->routerFactory->createRouter($application, $menu);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which provides our extension's <tt>createRouter</tt> call that the Joomla Router expects.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>routerFactory::createRouter</tt> method is in libraries/src/Component/Router/RouterFactory.php. It looks for a class in our site namespace </tt>Robbie\Component\Helloworld\Site\Service\Router</tt> which is in our site/src/Service/Router.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
At this stage we have a choice, we can either:
* provide a traditional custom router, with the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions, or
* use the more modern <tt>RouterView</tt> mechanism.
By default in the upgraded tutorial code the Router View option has been coded in the Router.php file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====RouterView====
In the <tt>RouterView</tt> case the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions are in the <tt>RouterView</tt> class which we extend, and we provide
* a constructor with router view configuration
* methods <tt>getHelloworldId</tt> and <tt>getCategoryId</tt> which are used to obtain from the SEF segment the <tt>id=</tt> and <tt>catid=</tt> parts of the internal URL
* methods <tt>getHelloworldSegment</tt> and <tt>getCategorySegment</tt> which are used to generate segments for the SEF URLs based on the <tt>id=</tt> and <tt>catid=</tt> parts within the <tt>Route::_()</tt> parameter.
Unfortunately there doesn't seem to be a good guide to configuring the RouterView class. There is some documentation available [https://www.dionysopoulos.me/book/com-router-routerview.html here].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the helloworld tutorial we have 3 views
* a view which displays a single helloworld record
* a view which displays a single helloworld category, and the helloworld records associated with it
* a view which displays the frontend form
So we need 3 Router Views associated with these.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'form' view doesn't have an associated id or catid so it's just a fixed URL, and the router just has to convert between the alias of the form menuitem and the Itemid / view parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'category' view has an associated id (of the category record), and an SEF URL will use the category path down the Categories Nested Set table structure, hence <tt>setNestable()</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'helloworld' view has an associated id (of the helloworld record), and in an SEF URL in the category view the helloworld record alias is added to the category path (hence <tt>setParent()</tt>). But although the helloworld records use a Nested Table structure in the database, the URLs just include the alias of the single record, and so <tt>setNestable()</tt> is not used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There doesn't seem to be a way to configure an additional SEF URL scheme which just displays a helloworld segment, without a category segment.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====Traditional Router====
To use the traditional router in the tutorial code you should uncomment the function in the extension class:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return new TraditionalRouter($application, $menu, $this->categoryFactory, $this->getDatabase());
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will cause the code in site/src/Service/TraditionalRouter.php to be used. However, changes in the Joomla 4 router mean that the interaction between it and the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> methods have changed. This requires significant changes to the <tt>preprocess</tt> and <tt>build</tt> methods, but only a minor change to <tt>parse</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. Previously Joomla injected into the <tt>$query</tt> parameters the <tt>Itemid</tt> of the active menuitem (ie the id of the menuitem the user is currently on). This meant that we had to change the <tt>Itemid</tt> for links generated by the Language Switcher module (which generates the flags for switching between languages), and these links being associated with a different language would obviously use a different <tt>Itemid</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 you get an <tt>Itemid</tt> in the <tt>$query</tt> parameters only if you specified an <tt>Itemid</tt> in the <tt>Route::_()</tt> call. For others you have to work out which menuitem to use yourself, by using the Joomla menu/menuitems API to find details of the configured menuitems, and work out which to use based on the other <tt>$query</tt> parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You do this in the <tt>preprocess</tt> method, and then the <tt>Itemid</tt> you set will be passed in the <tt>$query</tt> parameters to the <tt>build</tt> method.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. In some instances the <tt>Route::_()</tt> URL you're generating matches exactly one of the configured menuitems on the site. In this case the <tt>$query</tt> parameters will match those in the menuitem <tt>"query"</tt> array, and you have to remove explicitly remove the 'view', 'id' and 'catid' parameters so that they don't appear as URL query parameters after the normal SEF URL of the menuitem.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
3. The custom router will be used to build the URLs for the helloworld menuitems shown in menus on the page. For these the <tt>$query</tt> parameters will have the view / id / catid associated with those menuitems. Note that even if you remove these in your <tt>preprocess</tt> method, Joomla will inject them again into the <tt>$query</tt> array when it's passed to your <tt>build</tt> method, so you'll have to remove them again there!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
4. In the <tt>parse</tt> method you now have to unset the <tt>$segments</tt>, or else Joomla will return an HTTP 404 (page not found). Otherwise <tt>parse</tt> works as before.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
5. I've implemented <tt>build</tt> only for when Multilanguage is enabled on the site. If it's not enabled an empty <tt>$segments</tt> array is just returned, without doing unset on any of the <tt>$query</tt> parameters, so these will appear as URL parameters after the SEF URL. Also it's not coded properly to deal with items which have language set to <tt>*</tt>. These include helloworld records, categories or menuitems (eg the helloworld form).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that the <tt>categoryFactory</tt> is also now passed to the router. This is so that it can be used instead of <tt>Categories::getInstance()</tt> to get access to the Categories API calls.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_tags===
Whenever we setup a Tags Menu Item Type which displays items having a given tag or tags, then <tt>com_tags</tt> displays those items as links, and uses route helper functions to generate the URL parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The route helpers <tt>com_tags</tt> expects to find loaded into the data of the <tt>#__content_types</tt> table, in the router field, and these have been set to:
* For links to helloworld items: 'HelloworldHelperRoute::getHelloworldRoute'
* For links to helloworld categories: 'HelloworldHelperRoute::getCategoryRoute'
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, <tt>com_tags</tt> doesn't boot the helloworld extension to get access to these, but rather seeks to find them in site/helpers/route.php, so that's where they continue to be.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(We also had a <tt>getCategoryRoute</tt> which was used by <tt>com_categories</tt> in administrator/components/com_categories/src/Helper/CategoryAssociationHelper. When a category was displayed on the frontend then the Language Switcher module (now Language Filter) used this function to generate the links to the Associated Categories. Our <tt>getCategoryRoute</tt> previously was necessary to insert the <tt>lang=<language tag></tt> parameter into the link URL, but since [https://github.com/joomla/joomla-cms/pull/39358 this change] the calling function inserts the <tt>lang</tt> parameter itself, so our <tt>getCategoryRoute</tt> function for this purposes is superfluous.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Deprecated APIs ==
With Joomla 4 there are a number of methods which are deprecated, with a view to removing them in Joomla 5.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Factory Methods===
Many of the <tt>Factory</tt> methods for getting singleton classes have been deprecated in favour of getting these classes via the DI container, and it appears that only class instances which should be obtained via Factory methods are:
* the Application – <tt>Factory::getApplication()</tt>
* the DI container – <tt>Factory::getContainer()</tt>
Here is a list of what has been changed in the tutorial code. Note that with some calls there are variants available, through the aliases defined in the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDbo'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\Database\DatabaseInterface;
...
$db = Factory::getContainer()->get(DatabaseInterface::class);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, in many classes the database instance is more easily (and efficiently) returned via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$db = $this->getDatabase();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is available in Model classes, custom field definitions, etc.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getUser();'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get the current user use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = Factory::getApplication()->getIdentity()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get a different user (whose id you know):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\User\UserFactoryInterface;
...
$user = Factory::getContainer()->get(UserFactoryInterface::class)->loadUserById($userid);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within models which extend Joomla\CMS\MVC\Model\BaseDatabaseModel and views which extend Joomla\CMS\MVC\View\HtmlView you can also use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = $this->getCurrentUser()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDocument()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication()->getDocument()</tt>, or within a View you can use <tt>$this->document</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getConfig()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Two options have been used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->getConfig()</tt> – returns a Registry object containing all the configuration values
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->get('access')</tt> – returns the value of the 'access' configuration parameter
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getLanguage()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication->getLanguage()</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JFactory::getCache('com_example', <type>)'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Cache\CacheControllerFactoryInterface;
...
Factory::getContainer()->get(CacheControllerFactoryInterface::class)->createCacheController(<type>)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated getInstance Methods===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general <tt>getInstance()</tt> calls have been deprecated in favour of obtaining the instance, either via a factory class or via the DI container. For example, within a controller you can use <tt>getModel()</tt> repeatedly to get different models (passing the relevant model names), which results in the MVCFactory class creating the Model classes.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there are currently some problems with replacing some getInstance calls. I expect that the Joomla team will resolve these issues over the course of the Joomla 4 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Categories::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is deprecated with a notice: "Use the ComponentInterface to get the categories". This means that we should get the category factory instance via the DI container. This is done in our services/provider.php by the lines:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Extension\Service\Provider\CategoryFactory;
...
$container->registerServiceProvider(new CategoryFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to put into our child DI container the closure which will create a Joomla\CMS\Categories\CategoryFactory instance, constructed with our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when our HelloworldComponent (Extension) instance is created:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We can then use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getCategoryFactory()->createCategory();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to create our Categories object, and in this way get access to the Categories APIs.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This createCategory method creates the instance by looking for the \\Site\\Service\\Category class within our namespace. The constructor in our class sets our extension ('com_helloworld') and table ('#__helloworld') and calls the parent Categories constructor with these options).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this means that the section of our code where we want to use the Categories APIs must have a pointer to a CategoryFactory instance. In the tutorial code for Joomla 3 there are 2 places where <tt>Categories::getInstance</tt> is used:
* in the custom router code, to handle building and parsing of the category parts of the SEF URL
* in the site category model, where the Categories APIs are used to obtain details of categories to display on the page.
For the custom router code, the CategoryFactory instance is passed as a parameter to the TraditionalRouter constructor so that it can be used there.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, the site category model is instantiated by the MVCFactory instance, and it doesn't make available a CategoryFactory instance. So in this category model the calls to <tt>Categories::getInstance()</tt> have been left, and you can still find a number of calls to <tt>Categories::getInstance</tt> within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Categories::getInstance()</tt> itself solves the problem of access to a CategoryFactory instance by rebooting our component again to get a pointer to our Extension instance, and thus to the category factory instance. However, this involves a lot of work, so <tt>getInstance</tt> caches locally the Categories instances and just returns one of them if it can.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Pushing the CategoryFactory to the model'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there is a way to get access to the CategoryFactory instance, by defining your own MVCFactory class, and pushing the instance down through it to the model. Here's how you can go about it:
* Define your own SuperMVCFactory class, which extends the Joomla Joomla\CMS\MVC\Factory\MVCFactory class, but which has a means of storing a CategoryFactory instance. Use the CategoryServiceTrait in libraries/src/Categories/CategoryServiceTrait.php
* Create your own version of the file libraries/src/Extension/Service/Provider/MVCFactory.php, which is the 'provider.php' like file for MVCFactory, but change it so that:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
becomes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new <namespace>\SuperMVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and include
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla creates a model such as CategoryModel it passes in its constructor the MVCFactory instance (so that the model can call createTable on it), so you can access it via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will return your SuperMVCFactory instance. So in this way within the model you can access the CategoryFactory, and use it to create the Categories instance via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()->getCategory() (from the CategoryServiceTrait)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you can get this working you can congratulate yourself on a good understanding of Joomla namespacing and dependency injection! A similar approach to address a similar problem is described [https://www.dionysopoulos.me/book/com-router-push-dependencies.html here]. If you get stuck you can always view the solution by viewing the github tutorial code selecting the branch [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial/tree/push-category-factory-to-mvc push-category-factory-to-mvc].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Table::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There are a couple of calls to <tt>Table::getInstance()</tt> within admin/src/Helper/AssociationsHelper.php in <tt>getItem()</tt>:
* <tt>Table::getInstance('Helloworld', 'Robbie\\Component\\Helloworld\\Administrator\\Table\\')</tt> to get an instance of our HelloworldTable class.
* <tt>Table::getInstance('Category')</tt> to get an instance of the Category table in libraries/src/Table/Category.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We could actually arrange for the AssociationsHelper class to get injected with the MVCFactory instance, so that the HelloworldTable class could be instantiated by it. However, we couldn't use the helloworld MVCFactory instance to create the Category table instance, as it's not in the helloworld namespace, and our MVCFactory instance creates table instances within our namespace only.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Toolbar::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The tutorial code uses <tt>Toolbar::getInstance()</tt> to get a Toolbar instance onto which it can attach the batch button in the helloworlds form. The Toolbar API documentation seems to suggest that we should replace
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Toolbar::getInstance('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
with
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this currently won't work. The problem is that all the other Joomla code uses <tt>getInstance('toolbar')</tt> to access the Toolbar class, including the code in administrator/modules/mod_toolbar/mod_toolbar.php which renders the toolbar. The <tt>getInstance</tt> method keeps track of the Toolbar instances in a local static variable <tt>$instances</tt>, and returns the same Toolbar instance on repeated invocations.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you use the second approach above you will get a Toolbar instance, but it won't be the same Toolbar instance as is stored in the <tt>$instances</tt> variable. It won't then be picked up by the Toolbar module, and so won't be rendered on the form.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Error Handling===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead of
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
JError::raiseError(500, implode('<br />', $errors));
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
you should throw an exception, using or extending one of the standard [https://www.php.net/manual/en/spl.exceptions.php PHP exceptions], eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
throw new \Exception(implode("\n", $errors), 500);
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===jimport===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
jimport is no longer necessary in order to get access to Path or File classes. All of the Joomla classes are found by the autoloader.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Methods related to Javascript===
'''JHtml::_('behavior.framework');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general, the use of JHtml::_('behavior.xxx') is now obsolete, and calls using this have been removed in the tutorial code. The 'behavior.framework' call referred to including jQuery. Where jQuery is necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.formvalidator');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by the <tt>form.validate</tt> javascript asset, and where necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It can also be included directly using the web asset manager:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$wa->useScript('form.validate')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.tooltip')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This no longer exists, and tooltips don't seem to be enabled by default in Joomla 4. This is replaced by the code in media/js/enable-tooltips.js.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('formbehavior.chosen')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The chosen js library seems to be no longer used, and using it will cause formatting issues if you include it in your tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''sortable'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The sortable js library provided the ability in the helloworlds view to drag rows up and down to change the ordering of the records. This has been replaced in Joomla 4 by the draggable library. To enable it you have to set:
* <tt>HTMLHelper::_('draggablelist.draggable');</tt>
* on your <tt><tbody></tt> element define the table in which dragging occurs and the URL of the Ajax call to set the ordering:
<source lang="php">
<tbody<?php if ($saveOrder) : ?> class="js-draggable" data-url="<?php echo $saveOrderingUrl; ?>" data-direction="<?php echo strtolower($listDirn); ?>" data-nested="true"
<?php endif; ?>>
</source>
* on your <tt>tr</tt> element within your <tt><tbody></tt> define the group of records in which dragging occurs (by category below):
<source lang="php">
<tr class="row<?php echo $i % 2; ?>" data-draggable-group="<?php echo $row->catid; ?>">
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==HTML Snippets==
There are two places in the tutorial where reusable snippets of HTML have beeen defined:
* For displaying the item associations in the helloworlds view:
* For displaying the position latitude and longitude fields within the batch options in the helloworlds view
These used different approaches:
* the item associations display was coded in an html helper file in admin/helpers/html/helloworlds.php and accessed via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JHtml::_('helloworlds.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
in the helloworlds tmpl file. (Although it did use a common joomla layout file underneath).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* the position field was coded as a layout in layouts/position.php, and rendered using
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JLayoutHelper::render('position', array());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When should you use one approach rather than the other? A significant difference is that layouts are designed so that an administrator can override them, via the Templates / Details and File functionality. So, for example, an administrator could change the position to show the longitude before the latitude. So it's more appropriate for layouts to focus on the html elements rather than functional logic, and particularly if you would want to allow an administrator to override the layout.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The layouts functionality in Joomla 4 hasn't changed significantly. One correction which has been made in the updated tutorial code has been to include the position.php file in a subfolder of layouts, ie in admin/layouts/helloworld/position.php rather than admin/layouts/position.php. It appears that in the Templates / Details and Files / Create Overrides tab the <tt>com_helloworld</tt> layout appears only if it's in a subfolder of /layouts.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>JHtml::_()</tt> approach has changed in Joomla 4. Rather than Joomla having to look for a helper file when it encounters something it doesn't recognise, it's expected that you should register such classes beforehand, and you do this by obtaining an instance of the Joomla\CMS\HTML\Registry class (it's a singleton class) and then calling <tt>register</tt> on it, passing
* the key you want to use
* an instance of your class
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Joomla pattern is to put the code in a file admin/src/Service/HTML/AdministratorService.php, and we have to ensure that our key won't be used elsewhere within Joomla, so in the tutorial we've used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Robbie\Component\Helloworld\Administrator\Service\HTML\AdministratorService;
...
register('helloworldadministrator', new AdministratorService)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when we call:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo HTMLHelper::_('helloworldadministrator.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will result in Joomla calling the <tt>association</tt> method in our class, passing the <tt>$row->id</tt> parameter.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We should get the Joomla\CMS\HTML\Registry class from the Dependency Injection container. Joomla components generally do this via their services/provider.php file, and then call <tt>register</tt> within the extension's <tt>boot</tt> function, described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Step_5_Call_boot.28.29_on_our_Component|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The extension uses HTMLRegistryAwareTrait which contains <tt>setRegistry</tt> and <tt>getRegistry methods</tt>. In services/provider.php there is:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\HTML\Registry;
...
$component->setRegistry($container->get(Registry::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets 'Joomla\CMS\HTML\Registry' out of the DI container and stores it within the
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
private $registry;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
variable of the HTMLRegistryAwareTrait included in the extension.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the <tt>boot</tt> function it calls
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getRegistry()->register('helloworldadministrator', new AdministratorService);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets the registry and calls <tt>register</tt> as required.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that <tt>boot</tt> is called whenever Joomla dispatches <tt>com_helloworld</tt>, both for the site and administrator, so it would make sense to check the Application <tt>isClient</tt> before deciding whether to register the HTML Helper service or not. This hasn't been included in the tutorial code though.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==User Interface Changes==
Joomla 4 introduced new templates, atum on administrator and cassiopeia on site, and in particular the administrator is built upon some UI rearrangements which affect the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Sidebar===
In Joomla 3 each component incorporated a sidebar which we coded in the <tt>addSubmenu</tt> function in admin/helpers/helloworld.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the administrator menu is in a vertical panel on the left hand side, and the Hello World submenu is built from entries in the helloworld.xml manifest file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<administration>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<submenu>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<menu link="option=com_categories&extension=com_helloworld">COM_HELLOWORLD_CATEGORIES</menu>
<menu link="option=com_fields&view=fields&context=com_helloworld.helloworld">MOD_MENU_FIELDS</menu>
<menu link="option=com_fields&view=groups&context=com_helloworld.helloworld">MOD_MENU_FIELDS_GROUP</menu>
</submenu>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===CSS Classes===
In several places the CSS classes defined in the html elements have been changed in Joomla 4. For example, for general layout the classes now align with the [https://getbootstrap.com/docs/3.4/css/ Bootstrap CSS Classes], and classes such as <tt>row-fluid</tt> and <tt>span3</tt> which were prominent in Joomla 3 have disappeared. If you're upgrading a Joomla 3 component then it's probably best (on the back-end at least) to find a similar Joomla component and use the overall html structure and css classes within its tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the tutorial code those classes which are specifically used by Bootstrap have been changed from eg 'data-target' to 'data-bs-target', and it has been necessary to change these to enable the functionality to work.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, not all of CSS class changes affecting solely the presentation have been reflected in the updated tutorial code. For example, in the <tt>helloworlds</tt> view, showing the list of helloworld messages, the display of the associations is different from that of other Joomla components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Fonts===
In Joomla 3 [[J3.x:Joomla_Standard_Icomoon_Fonts|Icomoon Fonts]] were used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 Font Awesome's free icons are used, and you can see what is available on their [https://fontawesome.com/v5/cheatsheet cheatsheet]. The icons are implemented using CSS pseudo-elements, as described [https://fontawesome.com/v5/docs/web/advanced/css-pseudo-elements here]. Basically they convert a CSS class into html content, namely a unicode value in the private use range. A couple of these have been implemented in the frontend form, in the Save and Cancel buttons, for example:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>span class="icon-cancel">/span <?php echo Text::_('JCANCEL') ?></tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(with angle brackets removed from the <tt>span</tt> tags to stop the icon just being displayed by the browser).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This class is defined in media/system/css/joomla-fontawesome.css (where you can find the list of icon classes supported):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
.icon-cancel:before {
content: "\f00d";
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so this includes in front of the text the unicode character <tt>f00d</tt>, which you can see on the cheatsheet as "times", and displayed as <span class="icon-cancel"></span>. You can also use <tt>fa-</tt> plus the icon name on the font awesome cheatsheet page. If you use Icomoon icon names in your code which you run under Joomla 4, then the icon displayed will be a Font Awesome icon (if there's one with the same name) or it will use a mapping which the Joomla team have defined to display a Font Awesome icon which resembles the Icomoon one.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Buttons and Links===
An accessibility principle is that <tt><a></tt> html elements should be used for links to other web pages, and <tt><button></tt> elements should be used for actions, eg on a form. To align with this, the <tt><a></tt> elements in the helloworld modal field (defined in admin/src/Field/Modal/Helloworld.php) have been changed to <tt><button></tt> elements. These are the Select and Clear buttons displayed when choosing a Helloworld record for a menuitem pointing to a Helloworld message. (The buttons also include fontawesome icons, by the way).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This change was actually made in Joomla in one of the Joomla 3 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Categories View===
In the Categories view of standard Joomla components there now appears columns which show for each category the number of items, split by published status. This is populated by <tt>com_categories</tt> calling each extension's <tt>countItems</tt> function, as described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_categories|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Miscellaneous Changes==
===Version History===
In Joomla 3 the tutorial code used the <tt>JTableObserver</tt> functionality to copy relevant changes from the Helloworld and Categories tables into the UCM tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it uses a plugin mechanism to subscribe to Table events 'onTableAfterStore' and 'onTableBeforeDelete'. The plugin can be found in plugins/behaviour/versionable, and it is activated by Joomla as part of its application initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The copying of fields from the table works roughly the same way as before, except that the name of the table where the versions are stored is now <tt>#__history</tt>, so the entries which have to be inserted into the <tt>#__content_types</tt> table are fairly similar. Because the folders in which forms are stored has changed in Joomla 4, the 'formFile' parameter is different (remember that this is where Joomla gets the field labels in order to display the Preview within the Versions modal window, otherwise just the names of the database columns will be output).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here's a summary of what needs to be done to enable versioning under Joomla 4. The Versioning Traits and Interface definitions are found in libraries/src/Versioning:
* Enter data into content_types database table
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Storing the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The Table class must implement VersionableTableInterface and provide <tt>getTypeAlias()</tt>, which returns 'com_helloworld.helloworld'. This type alias + the helloworld record id is used as the key to identify versions in the <tt>#__history</tt> table.
* Define <tt>save_history</tt> and <tt>history_limit</tt> options in config.php, and ensure these are both set.
* Add a <tt>version_note</tt> field into the output of the edit view's tmpl file (admin/tmpl/helloworld/edit.php).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Viewing and Restoring the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit Controller (admin/src/Controller/HelloworldController.php) should <tt>use VersionableControllerTrait</tt>.
* The edit Model (admin/src/Model/HelloworldModel.php) should <tt>use VersionableModelTrait</tt> and include a variable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public $typeAlias = 'com_helloworld.helloworld';
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit View (admin/src/View/Helloworld/HtmlView.php) – should display the Versions toolbar button if global config has <tt>save_history</tt> on.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Joomla 4 allows us to have different history version limits for helloworld items and categories, and this has been used in the configuration definition in admin/config.xml.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Setting Configuration Parameters in Install Script===
As you may remember, global configuration parameters relating to the Hello World component are defined in admin/config.xml and stored in the <tt>#__extensions</tt> table, in a JSON string in the params field of the record relating to <tt>com_helloworld</tt>. This means that when the component is first installed the params are not set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So, for example, even if the <tt>save_history</tt> is defined in config.xml to default to true, the versions won't be saved until an administrator actively saves the configuration parameters, because the Joomla versioning code assumes <tt>save_history</tt> to be false if it's not explicitly set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For this reason it makes sense to set any default configuration parameters in the install script.php, in the <tt>postflight</tt> method, and that has been done in this step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Tags===
Like version history, tags functionality has been changed to use a plugin – in plugins/behaviour/taggable – rather than the <tt>JTableObserver</tt> approach.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To enable tags the component table must implement TaggableTableInterface (in libraries/src/Tag), and provide the <tt>getTypeAlias()</tt> which is common to the Versioning functionality.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Whenever <tt>com_tags</tt> outputs helloworld messages or categories relating to a tag it displays them as links, and looks in the site/helpers/route.php file to find the route functions (as described above in [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_tags|com_tags]]). The class and method in this file must match the 'router' field within the data entered into the <tt>#__content_types</tt> table.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===media files===
Under Joomla 4 all of the media files are stored in the /media folder; these include javascript and css files (scss files too), as well as images such as the little flag symbols shown in the language switcher. Extensions being developed should store all of the js and css files in their /media folder, and then when the extension is installed these files are put under the extension's folder under the /media folder of the Joomla instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Patches==
Some bugs in Joomla were discovered during the course of updating the tutorial code to work under Joomla 4. If you find something doesn't work then make sure you're on at least Joomla 4.2.6 and check if you need one of the following patches:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
CategoryAssociationHelper.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39358/files
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
MediaField.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/issues/39203
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Category restore
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39474
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Contributors ==
*[[User:Robbiej|Robbie Jackson]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Prev: Adding Custom Fields|class=expand success}}</div>
</div>
</div>

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/15/it

2023-05-27T12:42:57Z

Ing Pulizzi: Created page with "<tt>Robbie\Component\Helloworld\Site</tt> – punterà a components/com_helloworld/src sull'istanza live ed è associato a site/src nella nostra area di sviluppo."

<tt>Robbie\Component\Helloworld\Site</tt> – punterà a components/com_helloworld/src sull'istanza live ed è associato a site/src nella nostra area di sviluppo.

J3.x:Developing an MVC Component/Upgrading to Joomla4/it

2023-05-27T12:42:48Z

Ing Pulizzi: Created page with "<tt>Robbie\Component\Helloworld\Administrator</tt> – punterà ad administrator/components/com_helloworld/src sull'istanza live ed è associato ad admin/src nella nostra area..."

<noinclude><languages /></noinclude>

{{:J3.1:Developing an MVC Component/it}}
Questo passaggio copre ciò che è coinvolto nell'aggiornamento del codice del tutorial per allinearlo con la versione 4 di Joomla.

== Introduzione ==
Questa pagina descrive i principali aspetti relativi allo sviluppo dei componenti che sono stati introdotti in Joomla 4 e descrive in dettaglio cosa è stato modificato nel codice del tutorial per allinearsi con v4.

Non è pratico dettagliare tutte le modifiche al codice sulla pagina Web come è stato fatto per i passaggi precedenti dell'esercitazione. Invece puoi trovare il codice come repository github su [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial Joomla 4 Tutorial code], e puoi confrontarlo con il codice del passaggio precedente del tutorial (Adding Custom Fields) su [https://github.com/robbiejackson/Joomla-3-MVC-Tutorial Joomla 3 MVC code]. Il codice di Joomla 4 replica tutte le funzionalità del codice di Joomla 3, con l'eccezione dell'implementazione dell'icona del piccolo pinguino introdotta in [[S:MyLanguage/J3.2:Developing an MVC Component/Adding decorations to the backend|Aggiunta di decorazioni al backend]] (che non è così rilevante data la modifica dell'interfaccia utente in Joomla 4 Administrator) e l'uso di un plug-in CAPTCHA ([[J3.x:Developing an MVC Component/Adding a frontend form|Adding a frontend form]] ). Probabilmente troverai utile avere a portata di mano questo codice Joomla 4 a cui fare riferimento mentre leggi questa pagina.

Il codice per questo passaggio è stato sviluppato seguendo ciascuno dei precedenti passaggi del tutorial e cercando di far funzionare ogni passaggio con Joomla 4.2.5. Poiché Joomla 4 si sta ancora evolvendo abbastanza velocemente, è possibile che alcuni aspetti qui citati vengano modificati durante la vita di Joomla 4. Sentiti libero di correggere gli aspetti in questa pagina e creare richieste pull su [https://github.com/robbiejackson /Joomla-4-MVC-Tutorial Joomla 4 github repository].

Se stai installando il codice del tutorial di Joomla 4 su una nuova istanza di Joomla, dovrai configurare la tua istanza per renderla multilingue e aggiungere le voci di menu nascoste di Ajax come descritto nel passaggio [[J3.x:Developing an MVC Component/ Utilizzo del filtro della lingua |Utilizzo del filtro della lingua]]. Assicurati inoltre che ogni record helloworld abbia una categoria valida.

=== Ulteriori letture ===
Puoi trovare [https://blog.astrid-guenther.de/en/der-weg-zu-joomla4-erweiterungen/ qui] un tutorial per lo sviluppo dei componenti di Joomla 4, simile a questo Joomla 3, e alcuni eccellenti Joomla 4 è disponibile anche la documentazione [https://www.dionysopoulos.me/book.html qui]. Entrambi questi riferimenti includono descrizioni degli impatti di Joomla 4 sullo sviluppo di altri tipi di estensioni Joomla (plugin, moduli e modelli), che non sono trattati qui.

Questo passaggio non copre tutto ciò che è necessario per aggiornare un componente da Joomla 3 a Joomla 4, solo gli aspetti coperti dal codice del tutorial. Se stai aggiornando il tuo componente Joomla 3, potresti trovare utile esaminare [[Potenziali problemi di compatibilità con le versioni precedenti in Joomla 4]].

== NameSpace ==
===NameSpace dei nomi dei componenti===
I NameSpace delle classi che utilizza la [https://www.php-fig.org/psr/psr-4/ PSR-4 recommendation] è stato gradualmente introdotto durante le versioni di Joomla 3 e con Joomla 4 è praticamente tutto con NameSpace

Ora è previsto che anche le estensioni di Joomla utilizzino i NameSpace di base per l'estensione definito nel suo file XML manifest. I componenti di Joomla usano uno NameSpace della forma <tt>Joomla\Component\<Nome componente></tt> es. <tt>Joomla\Component\Content</tt>, quindi seguendo questo schema ho dato una base al codice del tutorial spazio dei nomi di <tt>Robbie\Component\Helloworld</tt>. Ecco la riga nel file manifest helloworld.xml:

<namespace path="src">Robbie\Component\Helloworld</namespace>

(L'attributo <tt>path="src"</tt> indica che si aspetterà che le classi si trovino nella sottocartella <tt>src</tt>.)

Questo in realtà crea 2 prefissi dello spazio dei nomi, che puntano a cartelle specifiche nella nostra struttura di sviluppo helloworld e nella nostra istanza joomla live:

<tt>Robbie\Component\Helloworld\Administrator</tt> – punterà ad administrator/components/com_helloworld/src sull'istanza live ed è associato ad admin/src nella nostra area di sviluppo.

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Robbie\Component\Helloworld\Site</tt> – will point to components/com_helloworld/src on the live instance, and is associated with site/src in our development area.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So Joomla now expects all classes names will be found under those base directories, with file name matching the class name, and the fully qualified classname matching the path eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> will be found in
administrator/components/com_helloworld/src/Controller/DisplayController.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> will be found in
components/com_helloworld/src/Model/CategoryModel.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Note that capitalization is important in namespaces, names of classes and path names!'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla 3 wanted to call functions in your component it looked for certain file names in particular folders, and checked that the name of the class in that file matched what it expected.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it generates the fully qualified name of the class it wants to find, and then looks to find it in the location where the PSR-4 recommendation would expect it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Hence the namespace you specify in your class files must align with the file path to your PHP file, below the base <tt>src</tt> folder at your namespace prefix.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note in particular how the <tt>View</tt> class files are now organised.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Also if you use one of the PHP predefined classes (eg <tt>Exception</tt>) in your code, then add a backslash before it (eg <tt>\Exception</tt>), otherwise PHP will try and find it in your namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you use custom Field or Rule definitions in your form xml files then you have to indicate to PHP which namespace prefix to use to look for them, eg in <tt>site/forms/add-form.xml</tt>:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
addruleprefix="Robbie\Component\Helloworld\Administrator\Rule"
addfieldprefix="Robbie\Component\Helloworld\Administrator\Field"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and also in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> where the associations are added into the form dynamically to form the custom <tt>modal_helloworld</tt> type field:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Class Autoloading===
Joomla uses the PHP mechanism for [https://www.php.net/manual/en/language.oop5.autoload.php Autoloading Classes] and on startup registers a number of autoloaders – functions which get called when PHP can't find a given class. In particular the Joomla PSR-4 autoloader function (in <tt>libraries/loader.php</tt>) is responsible for finding classes of Joomla extensions whose code is in source files which are organised according to the PSR-4 recommendation. (Joomla library classes are autoloaded using a different autoloader – see <tt>libraries/vendor/composer/autoload_static.php</tt>).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can see the namespace prefixes of extensions on the Joomla instance by looking at <tt>administrator/cache/autoload_psr4.php</tt>. (These namespace strings have double backslashes, but in PHP they're the [https://stackoverflow.com/questions/25459197/single-or-double-slash-when-using-php-namespace same strings as those with single backslashes]). This is generated by Joomla looking through the component, module and plugin directories to find each extension's manifest file, and then processing these xml files to extract the <tt><namespace></tt> element – quite a lot of work, which is why it's cached I guess!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider what happens when Joomla wants our admin HelloworldController class. It might have something like
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$classname = 'Robbie\Component\Helloworld\Administrator\Controller\HelloworldController'
if (!class_exists($classname)) { …
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Assuming PHP doesn't already know about this class, the <tt>class_exists</tt> function will result in the classname being passed to the registered autoload function(s). The PSR-4 autoloader will then:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# go through its array of namespaces to try and match <tt>$classname</tt> from the start of the string.
# find 'Robbie\Component\Helloworld\Administrator' as a match
# see that this maps to "administrator/components/com_helloworld/src"
# extract the remainder of the classname: 'Controller\HelloworldController'
# treat this as the path down to the class file
# and so look for "administrator/components/com_helloworld/src/Controller/HelloworldController.php"
# check that in this file there's actually a class with that namespace + class name.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So in this way Joomla can go from a fully qualified class name to find the source code for that class. This makes it easier for us too when the core Joomla code is looking for one of our classes. We still need to know what class it's looking for, but once we know that, we know what we should call our class and where we should save the source code for it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Joomla Library classes===
Originally Joomla's core classes (beginning with a capital J) were global classes. Over the Joomla 3 versions and into Joomla 4 these migrated to their namespaced equivalents, but the original global classnames were still available as Joomla registered them as aliases (in the <tt>libraries/classmap.php</tt> file).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In a Joomla 4 extension you can still use these global classnames, except that in a namespaced file you'd have to prefix the name with a backslash to indicate a global class rather than one in your namespace (eg <tt>\JFactory</tt> instead of <tt>JFactory</tt>).
However it's pretty definite that the aliases will disappear at some stage, so the upgrade to Joomla 4 seems an appropriate opportunity to replace all your component's calls to the global JSomething classes to the namespaced equivalents. This involves adding the appropriate <tt>use</tt> statements, and all this has been done in the tutorial code. A useful mapping between the two can be found [https://github.com/nikosdion/joomlatypehints/blob/main/JoomlaObsoleteClasses.md here], where the new qualified classname can be copied and pasted into a <tt>use</tt> statement in your PHP file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
With reference to the [https://api.joomla.org/ Joomla API Documentation] there are 2 Joomla library namespaces:
* Joomla CMS classes – have namespaces <tt>Joomla\CMS\Something</tt> – are found under <tt>libraries/src/Something</tt>
* Joomla Framework classes – have namespaces <tt>Joomla\Something</tt> – are found under <tt>libraries/vendor/joomla/something/src</tt>
So a big advantage of namespacing is that you can immediately determine from the fully qualified class name in a PHP <tt>use</tt> statement where the source for that class exists in the <tt>libraries</tt> directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
On the other hand class names which aren't fully qualified don't have to be unique, eg <tt>MVCFactory</tt>
* occurs as <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in <tt>libraries/src/Extension/Service/Provider/MVCFactory.php</tt>
* occurs as <tt>Joomla\CMS\MVC\Factory\MVCFactory</tt> in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>
so sometimes you have to be careful to examine the <tt>use</tt> statement to identify the right class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly our FormModel class in <tt>site/src/Model/FormModel.php</tt> can have the same FormModel classname as the Joomla FormModel in <tt>libraries/src/MVC/Model/FormModel.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The API documentation gives the methods available in each of the [https://api.joomla.org/cms-4/namespaces/joomla.html Joomla CMS] and [https://api.joomla.org/framework-2/namespaces/joomla.html Framework] classes, but just be aware that a Joomla CMS class may extend a Framework class, and in this case some methods may not be visible under the Joomla CMS documentation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For example, <tt>$app->setHeader()</tt> which is used to set the HTTP response code is not listed under the [https://api.joomla.org/cms-4/classes/Joomla-CMS-Application-CMSApplication.html CMS Application class API], but is available as a method because it inherits from the Framework class [https://api.joomla.org/framework-2/classes/Joomla-Application-AbstractWebApplication.html AbstractWebApplication].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Vendor Namespaces===
These are also in <tt>libraries/vendor</tt>, eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Psr\Container\ContainerInterface;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
refers to <tt>libraries/vendor/psr/Container/src/ContainerInterface.php</tt>. However there are few of these in the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other File Rearrangements===
With all of the namespaced classes moving under the src directories, the <tt>tmpl</tt> layout files and <tt>form</tt> xml files have been moved out into their own directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Extension and Dispatcher classes ==
===Extension===
In Joomla 3 the point where the Joomla core handed over to your component code was when it ran your <tt>helloworld.php</tt> code; if it was the frontend it ran your site <tt>helloworld.php</tt> code, or if was the backend it ran your admin <tt>helloworld.php</tt> code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the entry point into your component code is your Extension class, both for site and admin, found in <tt>admin/src/Extension/HelloworldComponent.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When the Joomla core application wants to start executing the component code it creates an instance of <tt>HelloworldComponent</tt>, just to get a handle on the component code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly (as described below) other Joomla classes such as Router or Categories need to call certain Helloworld methods (eg custom router functions). In Joomla 3 these methods were written in certain Helper files etc. In Joomla 4 the principle is that the component creates an instance of the <tt>HelloworldComponent</tt> Extension class, and calls the required methods on that instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This Extension class isn't anything like a big container class for the component, it's more like a glue class, providing a way in to the Helloworld component, enabling the Joomla core and other components call the methods which they want to call.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla core wants to execute the component code, the key method it is looking for in your <tt>Extension</tt> instance is <tt>getDispatcher</tt>, and it expects to get back a <tt>Dispatcher</tt> instance. The <tt>HelloworldComponent</tt> extends <tt>MVCComponent</tt>, which in turn extends <tt>Component</tt>, and it is this class which defines <tt>getDispatcher</tt> for us.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Dispatcher===
When Joomla wants to run the Hello World component, it gets the <tt>Dispatcher</tt> instance as described above and then calls the <tt>dispatch</tt> method on it. It is this <tt>dispatch</tt> function which replaces the functionality in the admin and site <tt>helloworld.php</tt> files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's look at the main lines of code in our Joomla 3 admin <tt>helloworld.php</tt> file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="site/views/form/view.html.php">
<syntaxhighlight lang="php">
if (!JFactory::getUser()->authorise('core.manage', 'com_helloworld'))
{
throw new Exception(JText::_('JERROR_ALERTNOAUTHOR'));
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Get an instance of the controller
$controller = JControllerLegacy::getInstance('HelloWorld');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Execute the Request task method
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Redirect if set by the controller
$controller->redirect();
</syntaxhighlight>
</span>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code
* performs some permissions checks
* instantiates the appropriate Helloworld controller
* executes the appropriate method in that controller
* implements any redirect set by the controller
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Model-View-Controller]] for further details of how this works in Joomla 3. The second and third steps used the <tt>task</tt> parameter within the URL query to determine the correct controller class to instantiate and method to call. If no <tt>task</tt> parameter was present then it instantiated the controller in <tt>controller.php</tt> and called the <tt>display</tt> method. Otherwise it instantiated one of the controllers in the <tt>controllers</tt> subfolder (eg <tt>controllers/helloworld.php</tt>) and called the appropriate method on it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>ComponentDispatcher::dispatch</tt> method (in <tt>libraries/src/Dispatcher/ComponentDispatcher.php</tt>) now provides this functionality, but in a nicer way. After checking the permissions it uses the <tt>task</tt> by considering its parts as <tt><controller type>.<method></tt> (taking 'display' as default if either part is missing). It will then pass control to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* an instance of the class <Controller type>Controller
* calling the function <method>
* using the admin or site controller, as appropriate
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In this way the naming of the controllers is consistent - we have DisplayController, HelloworldController and HelloworldsController, all in the same folder.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Dispatcher class can thus be considered as providing some 'routing - execution' functionality, enabling us to find the right controller and function within that controller, and it is cleaner to have this in a separate class rather than in the <tt>JControllerLegacy</tt> class as it was in Joomla 3.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Since the Hello World tutorial uses the standard Joomla pattern for selecting the class and method based on the <tt>task</tt> and has the same permissions checks, we can use the <tt>dispatch</tt> code as it stands in <tt>ComponentDispatcher</tt>, and don't need to define a special class of our own.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Factory classes ==
In Joomla 3 many classes had static <tt>getInstance</tt> methods which returned an instance of that class, configured with the parameters passed to <tt>getInstance</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the <tt>getInstance</tt> methods have been deprecated in favour of using Factory classes. The preferred mechanism is now to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* get an instance of the appropriate Factory class (how we do that is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below)
* call the <tt>createSomething()</tt> method of the Factory class with relevant parameter values to generate an instance of the Something class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===MVC Factory===
In this section the <tt>MVCFactory</tt> class refers to the one in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory class will instantiate Controller, View, Model and Table instances on our behalf, and it does this by generating the classname of the class and then calling <tt>new</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The way it works is as follows:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Each component gets an individual MVCFactory instance which is constructed passing the component's namespace as a parameter (so in our case 'Robbie\Component\Helloworld'). (How this MVCFactory instance is created is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below).
# The MVCFactory createController / createView / createModel / createTable function is then called, passing the name of the Controller / Model / View / Table and the prefix (which specifies whether the administrator or site class is required).
# The create function forms the classname from this data and calls <tt>new</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory create functions just form the classname from the parameters they're passed. The intelligence for working out what name and prefix should be used to form the appropriate classes for an incoming HTTP request is
* in the dispatcher code for defining the controller to use
* in the controller for the view and model
* in the model for the table
and, for example, the names of the classes created for a request with URL query <tt>?option=com_helloworld&view=viewname</tt> and no <tt>task</tt> parameter will be
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<namespace>\Controller\DisplayController
<namespace>\View\Viewname\HtmlView
<namespace>\Model\ViewnameModel
<namespace>\Table\ViewnameTable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you need an alternative name then you can override the appropriate getView, getModel or getTable function – as for example was done in the [[J3.x:Developing an MVC Component/Adding Custom Fields#Front-end_Form|Adding Custom Fields step, frontend Form section]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So from the outside this is pretty much the same as in Joomla 3. However, note that the <tt>$prefix</tt> parameter in calls to <tt>getModel</tt> etc is subtly different
* in Joomla 3 this referred to a prefix to be applied to the classname – in the tutorial code we used 'HelloWorldTable' as the prefix part of the 'HelloWorldTableHelloWorld' classname.
* in Joomla 4 this refers to a prefix higher up the classname path, and should be set to either 'Site' or 'Administrator' (the capital letter at the start is optional), depending on whether you want the class under 'Robbie\Component\Helloworld\Site' or 'Robbie\Component\Helloworld\Administrator'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVC Factory class is now the Joomla recommended way to create the controller, view, model and table classes, by using the eg <tt>getModel()</tt> method, and the use of <tt>getInstance()</tt> for these classes is now deprecated. However, the use of these functions is restricted:
* in the controller class you can call <tt>$this->getView($viewname, $viewtype, $prefix, $config)</tt> to create a view and <tt>$this->getModel($modelname, $prefix, $config)</tt> to create a model.
* in the view class you can call <tt>$this->getModel($modelname)</tt>, but only for models which the controller has previously defined using <tt>$view->setModel($modelname, $default)</tt>. It doesn't create a new model instance.
* in the model class you can call <tt>$this->getTable($tableclass, $prefix, $options)</tt> to create a table instance. Controllers and views can access the table classes in this way, by going via a model.
These restrictions do have an impact on moving away from using <tt>getInstance()</tt>, and indeed in Joomla 4.2.6 you will still find several <tt>getInstance()</tt> calls within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Factory Classes===
Several other Factory classes have been introduced in Joomla 4, enabling you to get instances of core classes such as Form, User, CacheController, etc, usually by calling a createSomething function on the Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Associated with the Factory class is a FactoryInterface, a PHP Interface which specifies the key functions which the Factory class must implement. For example, with <tt>libraries/src/Categories</tt> we have:
* CategoryFactoryInterface – which specifies the <tt>createCategory</tt> function
* CategoryFactory implements CategoryFactoryInterface – which provides the <tt>createCategory</tt> function.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Dependency Injection ==
===Overview===
The DI container is one of the significant new additions to Joomla 4. It's basically a repository of key-value pairs where:
* the key is a string which is the name of a class or interface
* the value is an instance of the relevant class, or a function that returns an instance of that class.
You put things into the container using <tt>set()</tt> passing:
* the class name or interface name
* a function which returns an instance of the class (or an instance of the class)
* a boolean defining whether the class instance may be shared or not
* a boolean defining whether this entry into the DI container is protected or not (an error will be raised if you try to overwrite a protected entry by calling <tt>set()</tt> again using the same key).
The function <tt>share()</tt> is basically the same as <tt>set()</tt> with the <tt>shared</tt> boolean set to true.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You get things out of the container by calling <tt>get()</tt> passing the key of the resource you want. The container will
* find the key in the container
* if the value isn't already a class instance, then it will run the associated function to generate an instance of the class
* if the resource is shared, it will store the class instance, so that on subsequent invocations of <tt>get()</tt> it can just return the instance
* return the class instance to you
You can also define aliases for each key in the container, which means that you call <tt>get()</tt> passing either the key or an alias of the key.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The DI container is initialised in <tt>library/src/Factory.php createContainer()</tt> which results in the <tt>register()</tt> function being called in each of the class files in <tt>libraries/src/Service/Provider</tt>. By looking through those files you can see what gets put into the DI container upon initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===JConfig Example===
Let's consider the example of JConfig which holds the system global configuration. If you look inside <tt>libraries/src/Service/Provider/Config.php</tt> then you'll see the <tt>register()</tt> function and that it stores in the DI container a resource with:
* key = 'JConfig'
* value = an anonymous function - which loads what's in <tt>configuration.php</tt> into a <tt>Registry</tt> object, and returns it
* shared flag = true (because the <tt>share()</tt> function is used)
* protected flag = true
Then when you do
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$config = $container->get('JConfig');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will run the anonymous function and return the Registry object to you. As the 'shared' boolean is set it will also store a copy of the class instance locally in the container to be returned on subsequent calls of <tt>get('JConfig')</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Justification===
What's the point of all this?
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The advantage of dependency injection is that it allows classes to be easily mocked for testing. The file <tt>libraries/src/Service/Provider/Config.php</tt> can be replaced to return to a DI container <tt>get()</tt> call a mock class instead of the usual <tt>JConfig</tt>. This is in comparison to Joomla 3 where <tt>Factory::getConfig()</tt> code directly reads the <tt>configuration.php</tt> into a Registry structure and returns it – which makes it harder to mock.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The [https://api.joomla.org/cms-4/classes/Joomla-CMS-Factory.html Factory API] has several functions which are marked as deprecated with advice to get the object from the DI container instead.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Several of the other Factory classes (eg Form, Language, Menu, User) are in the DI container – so that we can get an instance of them via eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Factory::getContainer()->get('Joomla\CMS\Toolbar\ToolbarFactoryInterface')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to get a Toolbar instance. However, this only works for singleton classes which aren't specific to the needs of a particular extension. We'll see shortly how to make it work for class instances which need to be specific to a component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As indicated above, Joomla is moving away from using the class static <tt>getInstance()</tt> functions. We can see now that this is not only because it's more pure from an object oriented perspective. But also creating class instances from the DI container, or from Factory objects which are obtained from the DI container, builds in the dependency injection which allows classes to be more easily mocked, and hence more easily tested.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==services/provider.php==
We're now finally in a good position to understand what's happening in our services/provider.php file, and we'll explore this by walking through what happens whenever this line in libraries/src/Component/ComponentHelper.php <tt>renderComponent</tt> is run:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is run whenever Joomla has worked out which component is to be run on the requested web page, and it wants to run that component to capture its output.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 1 Create Child DI Container===
Joomla first creates another DI container (initially empty) just for this component, and links it to the main DI container via a parent field in the child DI container structure.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Now whenever <tt>set()</tt> is called on this DI container the key-value pair is inserted into the child container. Whenever <tt>get()</tt> is called on it, the resource is obtained from the child container, but if it's not found there then the parent container is searched also.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 2 Run register() in provider.php===
Next we encounter these lines (in <tt>libraries/src/Extension/ExtensionManagerTrait.php</tt>), where <tt>$path</tt> contains the path of our helloworld admin/services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$provider = require_once $path;
// Check if the extension supports the service provider interface
if ($provider instanceof ServiceProviderInterface) {
$provider->register($container);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here we see 3 things:
# our provider.php should return some object (so that <tt>$provider</tt> gets set to something)
# what is returned should implement ServiceProviderInterface (you can see in <tt>libraries/vendor/joomla/di/src/ServiceProviderInterface.php</tt> what is expected)
# the code then runs the <tt>register</tt> function on that object, passing as a parameter the child DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider a minimal version of our provider.php file. This would actually support steps in the Joomla 3 tutorial up to and including the [[J3.x:Developing an MVC Component/Adding AJAX|Adding Ajax step]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {

public function register(Container $container): void
{
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
}
};
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As you can see from the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
this file does indeed return something – it returns an instance of an anonymous class, one that implements <tt>ServiceProviderInterface</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it's not sufficient to just provide the <tt>register</tt> function in the class, we also need to explicity state that the class implements <tt>ServiceProviderInterface</tt>. This now happens in several places in Joomla, so if you're debugging your component and wondering why a function you expect to be called isn't being called, then check to make sure that you don't have to explicitly add the appropriate <tt>implements <Interface></tt> clause to your class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Next we look at the 3 lines in the <tt>register</tt> function
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3a Registering our MVC Factory===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here our <tt>MVCFactory</tt> refers to <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in libraries/src/Extension/Service/Provider/MVCFactory.php, and you should have a look at this file. This is a file similar to our provider.php file, but it's a named class, and it doesn't return anything. When we do:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
new MVCFactory('\\Robbie\\Component\\Helloworld')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it creates an instance of this class, and in the constructor it stores locally in <tt>$this->namespace</tt> our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>registerServiceProvider</tt> function then calls the <tt>register</tt> function of this instance, which runs (in its minimalist form):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
MVCFactoryInterface::class,
function (Container $container) {
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
return $factory;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So what gets entered into our child DI container is a key-value pair with:
* key = MVCFactoryInterface::class (this is just a shorthand form to obtain a string of the fully qualified name – ie 'Joomla\CMS\MVC\Factory\MVCFactoryInterface')
* value = a function which returns an instance of <tt>\Joomla\CMS\MVC\Factory\MVCFactory</tt>.
This is our MVCFactory class which generates our Controllers, Views, Models and Tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Notice that we're passing our namespace as a parameter <tt>$this->namespace</tt>. Because this function is a closure, this variable will still be available when we run this function later, and when the MVCFactory class is instantiated the namespace will be passed into the constructor, stored locally, and then subsequently used to form the fully qualified names of our Controllers, View, etc. So this is how we get instantiated the MVCFactory class which is specific to our component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3b Registering the Dispatcher Factory===
Careful: ComponentDispatcherFactory refers to two different classes here!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This ComponentDispatcherFactory is Joomla\CMS\Extension\Service\Provider\ComponentDispatcherFactory in libraries/src/Extension/Service/Provider/ComponentDispatcherFactory.php. Similar to the above, the ComponentDispatcherFactory service provider class stores locally our namespace, and then when <tt>register</tt> is called it executes:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentDispatcherFactoryInterface::class,
function (Container $container) {
return new \Joomla\CMS\Dispatcher\ComponentDispatcherFactory($this->namespace,$container->get(MVCFactoryInterface::class));
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so a second entry is added to the child DI container with:
* key = ComponentDispatcherFactoryInterface::class
* value = a function which returns an instance of the ComponentDispatcherFactory (the other ComponentDispatcherFactory class!), where the class constructor will be passed the namespace ('\\Robbie\\Component\\Helloworld') and an MVCFactory instance, retrieved from the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that the code
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->get(MVCFactoryInterface::class)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
will get from the container an entry with key = 'Joomla\CMS\MVC\Factory\MVCFactoryInterface' – which is what we entered into the container in step 3a – and will run the function associated with this key, and then return the object which this function returns. This returned object will be an instance of '\Joomla\CMS\MVC\Factory\MVCFactory', constructed using our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3c Including the Extension===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will put into the child DI container a key-value pair with
* key = ComponentInterface::class
* value = the function which will create an instance of our <tt>HelloworldComponent</tt> (ie our Extension class), and pass into the constructor an instance of the ComponentDispatcherFactory class, retrieving what was entered into the child DI container in Step 3b.
It will call <tt>$container->get(MVCFactoryInterface::class)</tt>, getting an MVC Factory instance from what was entered into the DI container in Step 3a.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It will then associate our component with this MVC Factory instance via the <tt>setMVCFactory</tt> call. Significantly this will then allow our component to access this instance later, via a call to <tt>getMVCFactory</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3 Summary===
We have now got 3 entries in our child DI container, keyed by
* key = MVCFactoryInterface::class, value is a function returning an MVCFactory instance
* key = ComponentDispatcherFactoryInterface::class, value is a function returning a ComponentDispatcherFactory instance
* key = ComponentInterface::class, value is a function returning our HelloworldComponent, an instance of our Extension class.
The important aspect is that these entries are all aware of our namespace '\Robbie\Component\Helloworld' and will return instances of these classes which are specific to our Helloworld component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 4 Retrieving from the DI Container===
Joomla will then execute the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $container->get($type);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
where <tt>$type</tt> contains 'Joomla\CMS\Extension\ComponentInterface'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This starts the process of retrieving from the DI container the 3 entries which we put in, and will run our code in services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We end up with a HelloworldComponent instance, which has:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. a ComponentDispatcherFactory instance passed into the constructor, and which is saved locally by the constructor code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function __construct(ComponentDispatcherFactoryInterface $dispatcherFactory)
{
$this->dispatcherFactory = $dispatcherFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This code is in libraries/src/Extension/Component.php, in the class which our HelloworldComponent extends, via the class MVCComponent).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. an MVC Factory instance, stored by the HelloworldComponent <tt>setMVCFactory</tt> call
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 5 Call boot() on our Component===
Joomla calls:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
if ($extension instanceof BootableExtensionInterface) {
$extension->boot($container);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will call <tt>boot</tt> within our HelloworldComponent, and allows us to perform some initialisation within our component. We'll return to this later, in the section on [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#HTML_Snippets|HTML snippets]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note again that Joomla checks that our HelloworldComponent class implements BootableExtensionInterface before calling <tt>boot</tt>. It's not sufficient to just provide the <tt>boot</tt> function, we have to explicitly declare that our HelloworldComponent implements the interface.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 6 Get the Dispatcher===
Returning to our key line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
we have now accomplished the first part <tt>bootComponent($option)</tt>, and this has returned our HelloworldComponent instance. Now we call <tt>getDispatcher($app)</tt> on this instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This code is also in libraries/src/Extension/Component.php, in the Component class which our HelloworldComponent extends:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function getDispatcher(CMSApplicationInterface $application): DispatcherInterface
{
return $this->dispatcherFactory->createDispatcher($application);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We call <tt>createDispatcher</tt> on our ComponentDispatcherFactory class instance which we saved in Step 4. This code is in libraries/src/Dispatcher/ComponentDispatcherFactory.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createDispatcher(CMSApplicationInterface $application, Input $input = null): DispatcherInterface
{
$name = ucfirst($application->getName());

$className = '\\' . trim($this->namespace, '\\') . '\\' . $name . '\\Dispatcher\\Dispatcher';

if (!class_exists($className)) {
if ($application->isClient('api')) {
$className = ApiDispatcher::class;
} else {
$className = ComponentDispatcher::class;
}
}

return new $className($application, $input ?: $application->input, $this->mvcFactory);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code checks if we have our own Dispatcher class (our Helloworld tutorial doesn't, but <tt>com_users</tt> for example has its own). So it creates a <tt>ComponentDispatcher</tt> instance, and passes into its constructor the MVC Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that this ComponentDispatcherFactory instance is what was instantiated when it was retrieved from our child DI Container (from being inserted in step 3b), and hence it already knows about our namespace, and has a pointer to our MVCFactory class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 7 call dispatch()===
This is the final aspect to our line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We're now back to what was described in the Dispatcher section above, except that now we can see that this Dispatcher instance has a pointer to our MVC Factory instance (which knows about our namespace prefix), so when the Dispatcher code wants to create a Controller it can use that MVC Factory instance to instantiate it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's been a long and tortuous journey to get here, but the significant thing is that all of our key class instances have been obtained via the DI Container. If we want to mock out any of those classes for testing then all we need to do is replace the relevant services/provider file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Javascript and the Web Asset Manager ==
The web asset manager has been introduced in Joomla 4 and is well documented [[J4.x:Web_Assets|here]]. It provides a much-improved means of managing JS and CSS resources, and a framework for handling their dependencies.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Component Javascript and CSS files should now be stored in the <tt>media</tt> folder, and the Web Asset Manager used to register them and output them on specific web pages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following assets have been registered in the tutorial <tt>joomla.asset.json</tt>, and you should have a look at that file now.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.validate-greeting===
This is the code for client validation of the helloworld greeting field using a regex, and it is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it is dependent upon jQuery and the Joomla <tt>form.validator</tt> script, so those both get included as dependencies.
If we didn't have specific validation on our form then we would need to include explicitly the <tt>form.validator</tt> script in order for the basic Joomla field validation to be included, eg in the tmpl file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->document->getWebAssetManager()->useScript('form.validate');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that this requires us to have a <tt>class="form-validate"</tt> on the </tt><form></tt> html element.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.fix-permissions-ajax-call===
This is the code which copies the value from the greeting field into the title field, so that the Ajax calls setting the permissions work correctly. The js code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.enable-tooltips===
This is the code which enables bootstrap tooltips to operate, including allowing them to include html code. It's used to display the image as a tooltip within the admin <tt>helloworlds</tt> view.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.openstreetmap===
This is defined as a preset, comprising the helloworld js and css code for the map display, as well as the dependency named 'com_helloworld.openlayers' relating to the openlayers CSS and js code. The code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.admin-helloworlds-modal===
This is the js code for selecting an individual helloworld record within a modal, and passing its details to the form in the main window. Its code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===submitbutton.js===
In the Joomla 3 code we introduced in [[Special:MyLanguage/J3.2:Developing_an_MVC_Component/Adding_verifications|Adding Verifications]] a js file which controlled when the form was submitted. It differentiated between buttons such as <tt>Save</tt> (which submitted the form) and <tt>Cancel</tt> (which didn't).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 there is a more sophisticated version of <tt>Joomla.submitbutton</tt> (found in media/system/js/core.js) which uses the CSS classes which the Toolbar functionality sets on the buttons to determine whether the form should be submitted or not. And you can override whether the validation is performed by adding a third parameter to the <tt>submitbutton</tt> js call. For example, to avoid validation being performed when a button is clicked you can set on the button element:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
onclick="Joomla.submitbutton('controller.method', '', false)"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As this is sufficient for what we need in the tutorial, the custom <tt>submitbutton.js</tt> has been removed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Interaction with other components ==
The way that Joomla interacts with components has changed in Joomla 4. In general the Joomla functionality will boot the component using something like:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $app->bootComponent($option);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and in our case this will return an instance of the <tt>HelloworldComponent</tt> class. It will then try to call certain methods on our extension object, as described below.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_categories===
In the backend the helloworld functionality can display to the administrator
* the view of the helloworld messages
* the view of the helloworld categories
The categories view is generated by <tt>com_categories</tt>, and in Joomla 4 these component categories views display the number of component records there are for each of the possible published status values. To do this the categories component executes the following code (in administrator/components/com_categories/src/Model/CategoriesModel.php):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof CategoryServiceInterface) {
$component->countItems($items, $section);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So our HelloworldComponent must:
* declare that it implements <tt>CategoryServiceInterface</tt>
* provide an implementation of <tt>countItems</tt>
We provide <tt>countItems</tt> by using a trait in libraries/src/Categories/CategoryServiceTrait.php, which (with the assistance of a helper function) does the query on our behalf. We just need to tell it:
* the name of our table – in the callback <tt>getTableNameForSection</tt>
* the database field in which we hold the published status – in <tt>getStateColumnForSection</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_associations===
Remember that <tt>com_associations</tt> is the component which is run whenever you click on Multilingual Associations in the admin backend.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Under Joomla 3 we provided an associations helper file as described in [[J3.x:Multilingual Associations/Developers|Multilingual Associations/Developers]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the helper file remains basically the same, but <tt>com_associations</tt> primarily tries to find the helper file via the extension class; here's the code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($extensionName);
if ($component instanceof AssociationServiceInterface) {
return $component->getAssociationsExtension();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's expecting that:
* the extension (HelloworldComponent in our case) implements <tt>AssociationServiceInterface</tt>
* its <tt>getAssociationsExtension</tt> method returns the helper class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The easiest thing would be just to code <tt>getAssociationsMethod</tt> and get it to return <tt>new AssociationsHelper</tt>. However, we follow the Joomla 4 principle of putting key classes into the Dependency Injection container, and retrieving them later, by having the following code in our services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(AssociationExtensionInterface::class, new AssociationsHelper());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The above line puts a key-value pair into our child DI container
* key = 'Joomla\CMS\Association\AssociationExtensionInterface'
* value is an instance of our <tt>AssociationsHelper</tt> class.
We then retrieve it later and use the setter:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setAssociationExtension($container->get(AssociationExtensionInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so that whenever
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getAssociationExtension()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
is called it returns the <tt>AssociationsHelper</tt> class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_fields===
<tt>com_fields</tt> is the component which is run when an administrator clicks on the Fields or Field Groups menuitem within the backend, and this functionality was included in the [[J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Adding Custom Fields]] tutorial step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>com_fields</tt> component stores the custom fields and field groups for all components in the database tables <tt>#__fields</tt> and <tt>#__fields_groups</tt>, and these tables are partitioned into "sections", one section per component. For our helloworld component the section is named "helloworld".
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within the section we have 2 "contexts" – one for the helloworld messages (called "com_helloworld.helloworld") and one for the helloworld categories (called "com_helloworld.categories"). This enables us to define custom fields for both our helloworld records and helloworld category records.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When <tt>com_fields</tt> runs it checks both the section and contexts at various times. For example, when an admin selects Helloworld / Fields on the backend then <tt>com_fields</tt> checks the section which was defined in the menuitem in the manifest file (see [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Sidebar|below]]). Here's the code in administrator/components/com_fields/src/Helpers/FieldsHelper <tt>extract</tt> function:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
$newSection = $component->validateSection($parts[1], $item);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And when <tt>com_fields</tt> wants to display the little dropdown menu of contexts (to allow the administrator to set custom fields on either helloworld items or categories) it calls (in administrator/components/com_fields/src/Fields/FieldcontextsField.php <tt>getOptions()</tt>):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
return $component->getContexts();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So it's clear that our component extension class must :
* implement <tt>FieldsServiceInterface</tt>
* provide the <tt>validateSection</tt> and <tt>getContexts</tt> methods
So in upgrading to Joomla 4 we've just moved those two methods from the helper file to the extension class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Router===
The Joomla router will access our custom router code:
* whenever it wants to parse an SEF route which it has identified as belonging to <tt>com_helloworld</tt>
* whenever it wants to build an SEF route from a call to <tt>Route::_()</tt> where the option = "com_helloworld".
To find our custom router it will:
* boot the <tt>com_helloworld</tt> extension
* check that the extension implements <tt>RouterServiceInterface</tt>
* call <tt>createRouter</tt> on our extension instance
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In our services/provider.php file we have (careful again - 2 different RouterFactory classes!):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new RouterFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which from libraries/src/Extension/Service/Provider/RouterFactory.php puts into our child DI container an entry with:
* key = "Joomla\CMS\Component\Router\RouterFactoryInterface"
* value is a <tt>\Joomla\CMS\Component\Router\RouterFactory</tt> instance, constructed with our namespace
We then retrieve this in the line in our services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setRouterFactory($container->get(RouterFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And then within our extension class we have
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use RouterServiceTrait;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which includes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function setRouterFactory(RouterFactoryInterface $routerFactory)
{
$this->routerFactory = $routerFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which stores the <tt>routerFactory</tt> locally and
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return $this->routerFactory->createRouter($application, $menu);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which provides our extension's <tt>createRouter</tt> call that the Joomla Router expects.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>routerFactory::createRouter</tt> method is in libraries/src/Component/Router/RouterFactory.php. It looks for a class in our site namespace </tt>Robbie\Component\Helloworld\Site\Service\Router</tt> which is in our site/src/Service/Router.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
At this stage we have a choice, we can either:
* provide a traditional custom router, with the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions, or
* use the more modern <tt>RouterView</tt> mechanism.
By default in the upgraded tutorial code the Router View option has been coded in the Router.php file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====RouterView====
In the <tt>RouterView</tt> case the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions are in the <tt>RouterView</tt> class which we extend, and we provide
* a constructor with router view configuration
* methods <tt>getHelloworldId</tt> and <tt>getCategoryId</tt> which are used to obtain from the SEF segment the <tt>id=</tt> and <tt>catid=</tt> parts of the internal URL
* methods <tt>getHelloworldSegment</tt> and <tt>getCategorySegment</tt> which are used to generate segments for the SEF URLs based on the <tt>id=</tt> and <tt>catid=</tt> parts within the <tt>Route::_()</tt> parameter.
Unfortunately there doesn't seem to be a good guide to configuring the RouterView class. There is some documentation available [https://www.dionysopoulos.me/book/com-router-routerview.html here].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the helloworld tutorial we have 3 views
* a view which displays a single helloworld record
* a view which displays a single helloworld category, and the helloworld records associated with it
* a view which displays the frontend form
So we need 3 Router Views associated with these.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'form' view doesn't have an associated id or catid so it's just a fixed URL, and the router just has to convert between the alias of the form menuitem and the Itemid / view parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'category' view has an associated id (of the category record), and an SEF URL will use the category path down the Categories Nested Set table structure, hence <tt>setNestable()</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'helloworld' view has an associated id (of the helloworld record), and in an SEF URL in the category view the helloworld record alias is added to the category path (hence <tt>setParent()</tt>). But although the helloworld records use a Nested Table structure in the database, the URLs just include the alias of the single record, and so <tt>setNestable()</tt> is not used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There doesn't seem to be a way to configure an additional SEF URL scheme which just displays a helloworld segment, without a category segment.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====Traditional Router====
To use the traditional router in the tutorial code you should uncomment the function in the extension class:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return new TraditionalRouter($application, $menu, $this->categoryFactory, $this->getDatabase());
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will cause the code in site/src/Service/TraditionalRouter.php to be used. However, changes in the Joomla 4 router mean that the interaction between it and the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> methods have changed. This requires significant changes to the <tt>preprocess</tt> and <tt>build</tt> methods, but only a minor change to <tt>parse</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. Previously Joomla injected into the <tt>$query</tt> parameters the <tt>Itemid</tt> of the active menuitem (ie the id of the menuitem the user is currently on). This meant that we had to change the <tt>Itemid</tt> for links generated by the Language Switcher module (which generates the flags for switching between languages), and these links being associated with a different language would obviously use a different <tt>Itemid</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 you get an <tt>Itemid</tt> in the <tt>$query</tt> parameters only if you specified an <tt>Itemid</tt> in the <tt>Route::_()</tt> call. For others you have to work out which menuitem to use yourself, by using the Joomla menu/menuitems API to find details of the configured menuitems, and work out which to use based on the other <tt>$query</tt> parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You do this in the <tt>preprocess</tt> method, and then the <tt>Itemid</tt> you set will be passed in the <tt>$query</tt> parameters to the <tt>build</tt> method.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. In some instances the <tt>Route::_()</tt> URL you're generating matches exactly one of the configured menuitems on the site. In this case the <tt>$query</tt> parameters will match those in the menuitem <tt>"query"</tt> array, and you have to remove explicitly remove the 'view', 'id' and 'catid' parameters so that they don't appear as URL query parameters after the normal SEF URL of the menuitem.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
3. The custom router will be used to build the URLs for the helloworld menuitems shown in menus on the page. For these the <tt>$query</tt> parameters will have the view / id / catid associated with those menuitems. Note that even if you remove these in your <tt>preprocess</tt> method, Joomla will inject them again into the <tt>$query</tt> array when it's passed to your <tt>build</tt> method, so you'll have to remove them again there!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
4. In the <tt>parse</tt> method you now have to unset the <tt>$segments</tt>, or else Joomla will return an HTTP 404 (page not found). Otherwise <tt>parse</tt> works as before.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
5. I've implemented <tt>build</tt> only for when Multilanguage is enabled on the site. If it's not enabled an empty <tt>$segments</tt> array is just returned, without doing unset on any of the <tt>$query</tt> parameters, so these will appear as URL parameters after the SEF URL. Also it's not coded properly to deal with items which have language set to <tt>*</tt>. These include helloworld records, categories or menuitems (eg the helloworld form).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that the <tt>categoryFactory</tt> is also now passed to the router. This is so that it can be used instead of <tt>Categories::getInstance()</tt> to get access to the Categories API calls.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_tags===
Whenever we setup a Tags Menu Item Type which displays items having a given tag or tags, then <tt>com_tags</tt> displays those items as links, and uses route helper functions to generate the URL parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The route helpers <tt>com_tags</tt> expects to find loaded into the data of the <tt>#__content_types</tt> table, in the router field, and these have been set to:
* For links to helloworld items: 'HelloworldHelperRoute::getHelloworldRoute'
* For links to helloworld categories: 'HelloworldHelperRoute::getCategoryRoute'
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, <tt>com_tags</tt> doesn't boot the helloworld extension to get access to these, but rather seeks to find them in site/helpers/route.php, so that's where they continue to be.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(We also had a <tt>getCategoryRoute</tt> which was used by <tt>com_categories</tt> in administrator/components/com_categories/src/Helper/CategoryAssociationHelper. When a category was displayed on the frontend then the Language Switcher module (now Language Filter) used this function to generate the links to the Associated Categories. Our <tt>getCategoryRoute</tt> previously was necessary to insert the <tt>lang=<language tag></tt> parameter into the link URL, but since [https://github.com/joomla/joomla-cms/pull/39358 this change] the calling function inserts the <tt>lang</tt> parameter itself, so our <tt>getCategoryRoute</tt> function for this purposes is superfluous.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Deprecated APIs ==
With Joomla 4 there are a number of methods which are deprecated, with a view to removing them in Joomla 5.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Factory Methods===
Many of the <tt>Factory</tt> methods for getting singleton classes have been deprecated in favour of getting these classes via the DI container, and it appears that only class instances which should be obtained via Factory methods are:
* the Application – <tt>Factory::getApplication()</tt>
* the DI container – <tt>Factory::getContainer()</tt>
Here is a list of what has been changed in the tutorial code. Note that with some calls there are variants available, through the aliases defined in the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDbo'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\Database\DatabaseInterface;
...
$db = Factory::getContainer()->get(DatabaseInterface::class);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, in many classes the database instance is more easily (and efficiently) returned via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$db = $this->getDatabase();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is available in Model classes, custom field definitions, etc.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getUser();'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get the current user use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = Factory::getApplication()->getIdentity()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get a different user (whose id you know):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\User\UserFactoryInterface;
...
$user = Factory::getContainer()->get(UserFactoryInterface::class)->loadUserById($userid);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within models which extend Joomla\CMS\MVC\Model\BaseDatabaseModel and views which extend Joomla\CMS\MVC\View\HtmlView you can also use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = $this->getCurrentUser()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDocument()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication()->getDocument()</tt>, or within a View you can use <tt>$this->document</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getConfig()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Two options have been used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->getConfig()</tt> – returns a Registry object containing all the configuration values
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->get('access')</tt> – returns the value of the 'access' configuration parameter
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getLanguage()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication->getLanguage()</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JFactory::getCache('com_example', <type>)'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Cache\CacheControllerFactoryInterface;
...
Factory::getContainer()->get(CacheControllerFactoryInterface::class)->createCacheController(<type>)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated getInstance Methods===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general <tt>getInstance()</tt> calls have been deprecated in favour of obtaining the instance, either via a factory class or via the DI container. For example, within a controller you can use <tt>getModel()</tt> repeatedly to get different models (passing the relevant model names), which results in the MVCFactory class creating the Model classes.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there are currently some problems with replacing some getInstance calls. I expect that the Joomla team will resolve these issues over the course of the Joomla 4 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Categories::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is deprecated with a notice: "Use the ComponentInterface to get the categories". This means that we should get the category factory instance via the DI container. This is done in our services/provider.php by the lines:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Extension\Service\Provider\CategoryFactory;
...
$container->registerServiceProvider(new CategoryFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to put into our child DI container the closure which will create a Joomla\CMS\Categories\CategoryFactory instance, constructed with our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when our HelloworldComponent (Extension) instance is created:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We can then use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getCategoryFactory()->createCategory();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to create our Categories object, and in this way get access to the Categories APIs.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This createCategory method creates the instance by looking for the \\Site\\Service\\Category class within our namespace. The constructor in our class sets our extension ('com_helloworld') and table ('#__helloworld') and calls the parent Categories constructor with these options).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this means that the section of our code where we want to use the Categories APIs must have a pointer to a CategoryFactory instance. In the tutorial code for Joomla 3 there are 2 places where <tt>Categories::getInstance</tt> is used:
* in the custom router code, to handle building and parsing of the category parts of the SEF URL
* in the site category model, where the Categories APIs are used to obtain details of categories to display on the page.
For the custom router code, the CategoryFactory instance is passed as a parameter to the TraditionalRouter constructor so that it can be used there.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, the site category model is instantiated by the MVCFactory instance, and it doesn't make available a CategoryFactory instance. So in this category model the calls to <tt>Categories::getInstance()</tt> have been left, and you can still find a number of calls to <tt>Categories::getInstance</tt> within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Categories::getInstance()</tt> itself solves the problem of access to a CategoryFactory instance by rebooting our component again to get a pointer to our Extension instance, and thus to the category factory instance. However, this involves a lot of work, so <tt>getInstance</tt> caches locally the Categories instances and just returns one of them if it can.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Pushing the CategoryFactory to the model'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there is a way to get access to the CategoryFactory instance, by defining your own MVCFactory class, and pushing the instance down through it to the model. Here's how you can go about it:
* Define your own SuperMVCFactory class, which extends the Joomla Joomla\CMS\MVC\Factory\MVCFactory class, but which has a means of storing a CategoryFactory instance. Use the CategoryServiceTrait in libraries/src/Categories/CategoryServiceTrait.php
* Create your own version of the file libraries/src/Extension/Service/Provider/MVCFactory.php, which is the 'provider.php' like file for MVCFactory, but change it so that:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
becomes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new <namespace>\SuperMVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and include
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla creates a model such as CategoryModel it passes in its constructor the MVCFactory instance (so that the model can call createTable on it), so you can access it via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will return your SuperMVCFactory instance. So in this way within the model you can access the CategoryFactory, and use it to create the Categories instance via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()->getCategory() (from the CategoryServiceTrait)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you can get this working you can congratulate yourself on a good understanding of Joomla namespacing and dependency injection! A similar approach to address a similar problem is described [https://www.dionysopoulos.me/book/com-router-push-dependencies.html here]. If you get stuck you can always view the solution by viewing the github tutorial code selecting the branch [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial/tree/push-category-factory-to-mvc push-category-factory-to-mvc].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Table::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There are a couple of calls to <tt>Table::getInstance()</tt> within admin/src/Helper/AssociationsHelper.php in <tt>getItem()</tt>:
* <tt>Table::getInstance('Helloworld', 'Robbie\\Component\\Helloworld\\Administrator\\Table\\')</tt> to get an instance of our HelloworldTable class.
* <tt>Table::getInstance('Category')</tt> to get an instance of the Category table in libraries/src/Table/Category.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We could actually arrange for the AssociationsHelper class to get injected with the MVCFactory instance, so that the HelloworldTable class could be instantiated by it. However, we couldn't use the helloworld MVCFactory instance to create the Category table instance, as it's not in the helloworld namespace, and our MVCFactory instance creates table instances within our namespace only.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Toolbar::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The tutorial code uses <tt>Toolbar::getInstance()</tt> to get a Toolbar instance onto which it can attach the batch button in the helloworlds form. The Toolbar API documentation seems to suggest that we should replace
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Toolbar::getInstance('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
with
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this currently won't work. The problem is that all the other Joomla code uses <tt>getInstance('toolbar')</tt> to access the Toolbar class, including the code in administrator/modules/mod_toolbar/mod_toolbar.php which renders the toolbar. The <tt>getInstance</tt> method keeps track of the Toolbar instances in a local static variable <tt>$instances</tt>, and returns the same Toolbar instance on repeated invocations.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you use the second approach above you will get a Toolbar instance, but it won't be the same Toolbar instance as is stored in the <tt>$instances</tt> variable. It won't then be picked up by the Toolbar module, and so won't be rendered on the form.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Error Handling===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead of
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
JError::raiseError(500, implode('<br />', $errors));
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
you should throw an exception, using or extending one of the standard [https://www.php.net/manual/en/spl.exceptions.php PHP exceptions], eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
throw new \Exception(implode("\n", $errors), 500);
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===jimport===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
jimport is no longer necessary in order to get access to Path or File classes. All of the Joomla classes are found by the autoloader.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Methods related to Javascript===
'''JHtml::_('behavior.framework');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general, the use of JHtml::_('behavior.xxx') is now obsolete, and calls using this have been removed in the tutorial code. The 'behavior.framework' call referred to including jQuery. Where jQuery is necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.formvalidator');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by the <tt>form.validate</tt> javascript asset, and where necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It can also be included directly using the web asset manager:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$wa->useScript('form.validate')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.tooltip')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This no longer exists, and tooltips don't seem to be enabled by default in Joomla 4. This is replaced by the code in media/js/enable-tooltips.js.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('formbehavior.chosen')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The chosen js library seems to be no longer used, and using it will cause formatting issues if you include it in your tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''sortable'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The sortable js library provided the ability in the helloworlds view to drag rows up and down to change the ordering of the records. This has been replaced in Joomla 4 by the draggable library. To enable it you have to set:
* <tt>HTMLHelper::_('draggablelist.draggable');</tt>
* on your <tt><tbody></tt> element define the table in which dragging occurs and the URL of the Ajax call to set the ordering:
<source lang="php">
<tbody<?php if ($saveOrder) : ?> class="js-draggable" data-url="<?php echo $saveOrderingUrl; ?>" data-direction="<?php echo strtolower($listDirn); ?>" data-nested="true"
<?php endif; ?>>
</source>
* on your <tt>tr</tt> element within your <tt><tbody></tt> define the group of records in which dragging occurs (by category below):
<source lang="php">
<tr class="row<?php echo $i % 2; ?>" data-draggable-group="<?php echo $row->catid; ?>">
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==HTML Snippets==
There are two places in the tutorial where reusable snippets of HTML have beeen defined:
* For displaying the item associations in the helloworlds view:
* For displaying the position latitude and longitude fields within the batch options in the helloworlds view
These used different approaches:
* the item associations display was coded in an html helper file in admin/helpers/html/helloworlds.php and accessed via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JHtml::_('helloworlds.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
in the helloworlds tmpl file. (Although it did use a common joomla layout file underneath).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* the position field was coded as a layout in layouts/position.php, and rendered using
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JLayoutHelper::render('position', array());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When should you use one approach rather than the other? A significant difference is that layouts are designed so that an administrator can override them, via the Templates / Details and File functionality. So, for example, an administrator could change the position to show the longitude before the latitude. So it's more appropriate for layouts to focus on the html elements rather than functional logic, and particularly if you would want to allow an administrator to override the layout.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The layouts functionality in Joomla 4 hasn't changed significantly. One correction which has been made in the updated tutorial code has been to include the position.php file in a subfolder of layouts, ie in admin/layouts/helloworld/position.php rather than admin/layouts/position.php. It appears that in the Templates / Details and Files / Create Overrides tab the <tt>com_helloworld</tt> layout appears only if it's in a subfolder of /layouts.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>JHtml::_()</tt> approach has changed in Joomla 4. Rather than Joomla having to look for a helper file when it encounters something it doesn't recognise, it's expected that you should register such classes beforehand, and you do this by obtaining an instance of the Joomla\CMS\HTML\Registry class (it's a singleton class) and then calling <tt>register</tt> on it, passing
* the key you want to use
* an instance of your class
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Joomla pattern is to put the code in a file admin/src/Service/HTML/AdministratorService.php, and we have to ensure that our key won't be used elsewhere within Joomla, so in the tutorial we've used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Robbie\Component\Helloworld\Administrator\Service\HTML\AdministratorService;
...
register('helloworldadministrator', new AdministratorService)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when we call:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo HTMLHelper::_('helloworldadministrator.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will result in Joomla calling the <tt>association</tt> method in our class, passing the <tt>$row->id</tt> parameter.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We should get the Joomla\CMS\HTML\Registry class from the Dependency Injection container. Joomla components generally do this via their services/provider.php file, and then call <tt>register</tt> within the extension's <tt>boot</tt> function, described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Step_5_Call_boot.28.29_on_our_Component|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The extension uses HTMLRegistryAwareTrait which contains <tt>setRegistry</tt> and <tt>getRegistry methods</tt>. In services/provider.php there is:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\HTML\Registry;
...
$component->setRegistry($container->get(Registry::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets 'Joomla\CMS\HTML\Registry' out of the DI container and stores it within the
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
private $registry;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
variable of the HTMLRegistryAwareTrait included in the extension.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the <tt>boot</tt> function it calls
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getRegistry()->register('helloworldadministrator', new AdministratorService);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets the registry and calls <tt>register</tt> as required.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that <tt>boot</tt> is called whenever Joomla dispatches <tt>com_helloworld</tt>, both for the site and administrator, so it would make sense to check the Application <tt>isClient</tt> before deciding whether to register the HTML Helper service or not. This hasn't been included in the tutorial code though.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==User Interface Changes==
Joomla 4 introduced new templates, atum on administrator and cassiopeia on site, and in particular the administrator is built upon some UI rearrangements which affect the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Sidebar===
In Joomla 3 each component incorporated a sidebar which we coded in the <tt>addSubmenu</tt> function in admin/helpers/helloworld.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the administrator menu is in a vertical panel on the left hand side, and the Hello World submenu is built from entries in the helloworld.xml manifest file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<administration>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<submenu>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<menu link="option=com_categories&extension=com_helloworld">COM_HELLOWORLD_CATEGORIES</menu>
<menu link="option=com_fields&view=fields&context=com_helloworld.helloworld">MOD_MENU_FIELDS</menu>
<menu link="option=com_fields&view=groups&context=com_helloworld.helloworld">MOD_MENU_FIELDS_GROUP</menu>
</submenu>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===CSS Classes===
In several places the CSS classes defined in the html elements have been changed in Joomla 4. For example, for general layout the classes now align with the [https://getbootstrap.com/docs/3.4/css/ Bootstrap CSS Classes], and classes such as <tt>row-fluid</tt> and <tt>span3</tt> which were prominent in Joomla 3 have disappeared. If you're upgrading a Joomla 3 component then it's probably best (on the back-end at least) to find a similar Joomla component and use the overall html structure and css classes within its tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the tutorial code those classes which are specifically used by Bootstrap have been changed from eg 'data-target' to 'data-bs-target', and it has been necessary to change these to enable the functionality to work.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, not all of CSS class changes affecting solely the presentation have been reflected in the updated tutorial code. For example, in the <tt>helloworlds</tt> view, showing the list of helloworld messages, the display of the associations is different from that of other Joomla components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Fonts===
In Joomla 3 [[J3.x:Joomla_Standard_Icomoon_Fonts|Icomoon Fonts]] were used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 Font Awesome's free icons are used, and you can see what is available on their [https://fontawesome.com/v5/cheatsheet cheatsheet]. The icons are implemented using CSS pseudo-elements, as described [https://fontawesome.com/v5/docs/web/advanced/css-pseudo-elements here]. Basically they convert a CSS class into html content, namely a unicode value in the private use range. A couple of these have been implemented in the frontend form, in the Save and Cancel buttons, for example:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>span class="icon-cancel">/span <?php echo Text::_('JCANCEL') ?></tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(with angle brackets removed from the <tt>span</tt> tags to stop the icon just being displayed by the browser).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This class is defined in media/system/css/joomla-fontawesome.css (where you can find the list of icon classes supported):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
.icon-cancel:before {
content: "\f00d";
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so this includes in front of the text the unicode character <tt>f00d</tt>, which you can see on the cheatsheet as "times", and displayed as <span class="icon-cancel"></span>. You can also use <tt>fa-</tt> plus the icon name on the font awesome cheatsheet page. If you use Icomoon icon names in your code which you run under Joomla 4, then the icon displayed will be a Font Awesome icon (if there's one with the same name) or it will use a mapping which the Joomla team have defined to display a Font Awesome icon which resembles the Icomoon one.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Buttons and Links===
An accessibility principle is that <tt><a></tt> html elements should be used for links to other web pages, and <tt><button></tt> elements should be used for actions, eg on a form. To align with this, the <tt><a></tt> elements in the helloworld modal field (defined in admin/src/Field/Modal/Helloworld.php) have been changed to <tt><button></tt> elements. These are the Select and Clear buttons displayed when choosing a Helloworld record for a menuitem pointing to a Helloworld message. (The buttons also include fontawesome icons, by the way).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This change was actually made in Joomla in one of the Joomla 3 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Categories View===
In the Categories view of standard Joomla components there now appears columns which show for each category the number of items, split by published status. This is populated by <tt>com_categories</tt> calling each extension's <tt>countItems</tt> function, as described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_categories|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Miscellaneous Changes==
===Version History===
In Joomla 3 the tutorial code used the <tt>JTableObserver</tt> functionality to copy relevant changes from the Helloworld and Categories tables into the UCM tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it uses a plugin mechanism to subscribe to Table events 'onTableAfterStore' and 'onTableBeforeDelete'. The plugin can be found in plugins/behaviour/versionable, and it is activated by Joomla as part of its application initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The copying of fields from the table works roughly the same way as before, except that the name of the table where the versions are stored is now <tt>#__history</tt>, so the entries which have to be inserted into the <tt>#__content_types</tt> table are fairly similar. Because the folders in which forms are stored has changed in Joomla 4, the 'formFile' parameter is different (remember that this is where Joomla gets the field labels in order to display the Preview within the Versions modal window, otherwise just the names of the database columns will be output).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here's a summary of what needs to be done to enable versioning under Joomla 4. The Versioning Traits and Interface definitions are found in libraries/src/Versioning:
* Enter data into content_types database table
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Storing the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The Table class must implement VersionableTableInterface and provide <tt>getTypeAlias()</tt>, which returns 'com_helloworld.helloworld'. This type alias + the helloworld record id is used as the key to identify versions in the <tt>#__history</tt> table.
* Define <tt>save_history</tt> and <tt>history_limit</tt> options in config.php, and ensure these are both set.
* Add a <tt>version_note</tt> field into the output of the edit view's tmpl file (admin/tmpl/helloworld/edit.php).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Viewing and Restoring the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit Controller (admin/src/Controller/HelloworldController.php) should <tt>use VersionableControllerTrait</tt>.
* The edit Model (admin/src/Model/HelloworldModel.php) should <tt>use VersionableModelTrait</tt> and include a variable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public $typeAlias = 'com_helloworld.helloworld';
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit View (admin/src/View/Helloworld/HtmlView.php) – should display the Versions toolbar button if global config has <tt>save_history</tt> on.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Joomla 4 allows us to have different history version limits for helloworld items and categories, and this has been used in the configuration definition in admin/config.xml.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Setting Configuration Parameters in Install Script===
As you may remember, global configuration parameters relating to the Hello World component are defined in admin/config.xml and stored in the <tt>#__extensions</tt> table, in a JSON string in the params field of the record relating to <tt>com_helloworld</tt>. This means that when the component is first installed the params are not set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So, for example, even if the <tt>save_history</tt> is defined in config.xml to default to true, the versions won't be saved until an administrator actively saves the configuration parameters, because the Joomla versioning code assumes <tt>save_history</tt> to be false if it's not explicitly set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For this reason it makes sense to set any default configuration parameters in the install script.php, in the <tt>postflight</tt> method, and that has been done in this step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Tags===
Like version history, tags functionality has been changed to use a plugin – in plugins/behaviour/taggable – rather than the <tt>JTableObserver</tt> approach.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To enable tags the component table must implement TaggableTableInterface (in libraries/src/Tag), and provide the <tt>getTypeAlias()</tt> which is common to the Versioning functionality.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Whenever <tt>com_tags</tt> outputs helloworld messages or categories relating to a tag it displays them as links, and looks in the site/helpers/route.php file to find the route functions (as described above in [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_tags|com_tags]]). The class and method in this file must match the 'router' field within the data entered into the <tt>#__content_types</tt> table.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===media files===
Under Joomla 4 all of the media files are stored in the /media folder; these include javascript and css files (scss files too), as well as images such as the little flag symbols shown in the language switcher. Extensions being developed should store all of the js and css files in their /media folder, and then when the extension is installed these files are put under the extension's folder under the /media folder of the Joomla instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Patches==
Some bugs in Joomla were discovered during the course of updating the tutorial code to work under Joomla 4. If you find something doesn't work then make sure you're on at least Joomla 4.2.6 and check if you need one of the following patches:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
CategoryAssociationHelper.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39358/files
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
MediaField.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/issues/39203
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Category restore
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39474
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Contributors ==
*[[User:Robbiej|Robbie Jackson]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Prev: Adding Custom Fields|class=expand success}}</div>
</div>
</div>

Translations:J3.x:Developing an MVC Component/Upgrading to Joomla4/14/it

2023-05-27T12:42:47Z

<tt>Robbie\Component\Helloworld\Administrator</tt> – punterà ad administrator/components/com_helloworld/src sull'istanza live ed è associato ad admin/src nella nostra area di sviluppo.

J3.x:Developing an MVC Component/Upgrading to Joomla4/it

2023-05-27T12:42:43Z

Ing Pulizzi: Created page with "Questo in realtà crea 2 prefissi dello spazio dei nomi, che puntano a cartelle specifiche nella nostra struttura di sviluppo helloworld e nella nostra istanza joomla live:"

<noinclude><languages /></noinclude>

{{:J3.1:Developing an MVC Component/it}}
Questo passaggio copre ciò che è coinvolto nell'aggiornamento del codice del tutorial per allinearlo con la versione 4 di Joomla.

== Introduzione ==
Questa pagina descrive i principali aspetti relativi allo sviluppo dei componenti che sono stati introdotti in Joomla 4 e descrive in dettaglio cosa è stato modificato nel codice del tutorial per allinearsi con v4.

Non è pratico dettagliare tutte le modifiche al codice sulla pagina Web come è stato fatto per i passaggi precedenti dell'esercitazione. Invece puoi trovare il codice come repository github su [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial Joomla 4 Tutorial code], e puoi confrontarlo con il codice del passaggio precedente del tutorial (Adding Custom Fields) su [https://github.com/robbiejackson/Joomla-3-MVC-Tutorial Joomla 3 MVC code]. Il codice di Joomla 4 replica tutte le funzionalità del codice di Joomla 3, con l'eccezione dell'implementazione dell'icona del piccolo pinguino introdotta in [[S:MyLanguage/J3.2:Developing an MVC Component/Adding decorations to the backend|Aggiunta di decorazioni al backend]] (che non è così rilevante data la modifica dell'interfaccia utente in Joomla 4 Administrator) e l'uso di un plug-in CAPTCHA ([[J3.x:Developing an MVC Component/Adding a frontend form|Adding a frontend form]] ). Probabilmente troverai utile avere a portata di mano questo codice Joomla 4 a cui fare riferimento mentre leggi questa pagina.

Il codice per questo passaggio è stato sviluppato seguendo ciascuno dei precedenti passaggi del tutorial e cercando di far funzionare ogni passaggio con Joomla 4.2.5. Poiché Joomla 4 si sta ancora evolvendo abbastanza velocemente, è possibile che alcuni aspetti qui citati vengano modificati durante la vita di Joomla 4. Sentiti libero di correggere gli aspetti in questa pagina e creare richieste pull su [https://github.com/robbiejackson /Joomla-4-MVC-Tutorial Joomla 4 github repository].

Se stai installando il codice del tutorial di Joomla 4 su una nuova istanza di Joomla, dovrai configurare la tua istanza per renderla multilingue e aggiungere le voci di menu nascoste di Ajax come descritto nel passaggio [[J3.x:Developing an MVC Component/ Utilizzo del filtro della lingua |Utilizzo del filtro della lingua]]. Assicurati inoltre che ogni record helloworld abbia una categoria valida.

=== Ulteriori letture ===
Puoi trovare [https://blog.astrid-guenther.de/en/der-weg-zu-joomla4-erweiterungen/ qui] un tutorial per lo sviluppo dei componenti di Joomla 4, simile a questo Joomla 3, e alcuni eccellenti Joomla 4 è disponibile anche la documentazione [https://www.dionysopoulos.me/book.html qui]. Entrambi questi riferimenti includono descrizioni degli impatti di Joomla 4 sullo sviluppo di altri tipi di estensioni Joomla (plugin, moduli e modelli), che non sono trattati qui.

Questo passaggio non copre tutto ciò che è necessario per aggiornare un componente da Joomla 3 a Joomla 4, solo gli aspetti coperti dal codice del tutorial. Se stai aggiornando il tuo componente Joomla 3, potresti trovare utile esaminare [[Potenziali problemi di compatibilità con le versioni precedenti in Joomla 4]].

== NameSpace ==
===NameSpace dei nomi dei componenti===
I NameSpace delle classi che utilizza la [https://www.php-fig.org/psr/psr-4/ PSR-4 recommendation] è stato gradualmente introdotto durante le versioni di Joomla 3 e con Joomla 4 è praticamente tutto con NameSpace

Ora è previsto che anche le estensioni di Joomla utilizzino i NameSpace di base per l'estensione definito nel suo file XML manifest. I componenti di Joomla usano uno NameSpace della forma <tt>Joomla\Component\<Nome componente></tt> es. <tt>Joomla\Component\Content</tt>, quindi seguendo questo schema ho dato una base al codice del tutorial spazio dei nomi di <tt>Robbie\Component\Helloworld</tt>. Ecco la riga nel file manifest helloworld.xml:

<namespace path="src">Robbie\Component\Helloworld</namespace>

(L'attributo <tt>path="src"</tt> indica che si aspetterà che le classi si trovino nella sottocartella <tt>src</tt>.)

Questo in realtà crea 2 prefissi dello spazio dei nomi, che puntano a cartelle specifiche nella nostra struttura di sviluppo helloworld e nella nostra istanza joomla live:

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Robbie\Component\Helloworld\Administrator</tt> – will point to administrator/components/com_helloworld/src on the live instance and is associated with admin/src in our development area.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Robbie\Component\Helloworld\Site</tt> – will point to components/com_helloworld/src on the live instance, and is associated with site/src in our development area.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So Joomla now expects all classes names will be found under those base directories, with file name matching the class name, and the fully qualified classname matching the path eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Robbie\Component\Helloworld\Administrator\Controller\DisplayController</tt> will be found in
administrator/components/com_helloworld/src/Controller/DisplayController.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Robbie\Component\Helloworld\Site\Model\CategoryModel</tt> will be found in
components/com_helloworld/src/Model/CategoryModel.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Note that capitalization is important in namespaces, names of classes and path names!'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla 3 wanted to call functions in your component it looked for certain file names in particular folders, and checked that the name of the class in that file matched what it expected.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it generates the fully qualified name of the class it wants to find, and then looks to find it in the location where the PSR-4 recommendation would expect it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Hence the namespace you specify in your class files must align with the file path to your PHP file, below the base <tt>src</tt> folder at your namespace prefix.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note in particular how the <tt>View</tt> class files are now organised.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Also if you use one of the PHP predefined classes (eg <tt>Exception</tt>) in your code, then add a backslash before it (eg <tt>\Exception</tt>), otherwise PHP will try and find it in your namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you use custom Field or Rule definitions in your form xml files then you have to indicate to PHP which namespace prefix to use to look for them, eg in <tt>site/forms/add-form.xml</tt>:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
addruleprefix="Robbie\Component\Helloworld\Administrator\Rule"
addfieldprefix="Robbie\Component\Helloworld\Administrator\Field"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and also in <tt>admin/src/Model/HelloworldModel::preprocessForm</tt> where the associations are added into the form dynamically to form the custom <tt>modal_helloworld</tt> type field:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$fieldset->addAttribute('addfieldprefix', 'Robbie\Component\Helloworld\Administrator\Field');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Class Autoloading===
Joomla uses the PHP mechanism for [https://www.php.net/manual/en/language.oop5.autoload.php Autoloading Classes] and on startup registers a number of autoloaders – functions which get called when PHP can't find a given class. In particular the Joomla PSR-4 autoloader function (in <tt>libraries/loader.php</tt>) is responsible for finding classes of Joomla extensions whose code is in source files which are organised according to the PSR-4 recommendation. (Joomla library classes are autoloaded using a different autoloader – see <tt>libraries/vendor/composer/autoload_static.php</tt>).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can see the namespace prefixes of extensions on the Joomla instance by looking at <tt>administrator/cache/autoload_psr4.php</tt>. (These namespace strings have double backslashes, but in PHP they're the [https://stackoverflow.com/questions/25459197/single-or-double-slash-when-using-php-namespace same strings as those with single backslashes]). This is generated by Joomla looking through the component, module and plugin directories to find each extension's manifest file, and then processing these xml files to extract the <tt><namespace></tt> element – quite a lot of work, which is why it's cached I guess!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider what happens when Joomla wants our admin HelloworldController class. It might have something like
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$classname = 'Robbie\Component\Helloworld\Administrator\Controller\HelloworldController'
if (!class_exists($classname)) { …
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Assuming PHP doesn't already know about this class, the <tt>class_exists</tt> function will result in the classname being passed to the registered autoload function(s). The PSR-4 autoloader will then:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# go through its array of namespaces to try and match <tt>$classname</tt> from the start of the string.
# find 'Robbie\Component\Helloworld\Administrator' as a match
# see that this maps to "administrator/components/com_helloworld/src"
# extract the remainder of the classname: 'Controller\HelloworldController'
# treat this as the path down to the class file
# and so look for "administrator/components/com_helloworld/src/Controller/HelloworldController.php"
# check that in this file there's actually a class with that namespace + class name.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So in this way Joomla can go from a fully qualified class name to find the source code for that class. This makes it easier for us too when the core Joomla code is looking for one of our classes. We still need to know what class it's looking for, but once we know that, we know what we should call our class and where we should save the source code for it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Joomla Library classes===
Originally Joomla's core classes (beginning with a capital J) were global classes. Over the Joomla 3 versions and into Joomla 4 these migrated to their namespaced equivalents, but the original global classnames were still available as Joomla registered them as aliases (in the <tt>libraries/classmap.php</tt> file).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In a Joomla 4 extension you can still use these global classnames, except that in a namespaced file you'd have to prefix the name with a backslash to indicate a global class rather than one in your namespace (eg <tt>\JFactory</tt> instead of <tt>JFactory</tt>).
However it's pretty definite that the aliases will disappear at some stage, so the upgrade to Joomla 4 seems an appropriate opportunity to replace all your component's calls to the global JSomething classes to the namespaced equivalents. This involves adding the appropriate <tt>use</tt> statements, and all this has been done in the tutorial code. A useful mapping between the two can be found [https://github.com/nikosdion/joomlatypehints/blob/main/JoomlaObsoleteClasses.md here], where the new qualified classname can be copied and pasted into a <tt>use</tt> statement in your PHP file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
With reference to the [https://api.joomla.org/ Joomla API Documentation] there are 2 Joomla library namespaces:
* Joomla CMS classes – have namespaces <tt>Joomla\CMS\Something</tt> – are found under <tt>libraries/src/Something</tt>
* Joomla Framework classes – have namespaces <tt>Joomla\Something</tt> – are found under <tt>libraries/vendor/joomla/something/src</tt>
So a big advantage of namespacing is that you can immediately determine from the fully qualified class name in a PHP <tt>use</tt> statement where the source for that class exists in the <tt>libraries</tt> directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
On the other hand class names which aren't fully qualified don't have to be unique, eg <tt>MVCFactory</tt>
* occurs as <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in <tt>libraries/src/Extension/Service/Provider/MVCFactory.php</tt>
* occurs as <tt>Joomla\CMS\MVC\Factory\MVCFactory</tt> in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>
so sometimes you have to be careful to examine the <tt>use</tt> statement to identify the right class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly our FormModel class in <tt>site/src/Model/FormModel.php</tt> can have the same FormModel classname as the Joomla FormModel in <tt>libraries/src/MVC/Model/FormModel.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The API documentation gives the methods available in each of the [https://api.joomla.org/cms-4/namespaces/joomla.html Joomla CMS] and [https://api.joomla.org/framework-2/namespaces/joomla.html Framework] classes, but just be aware that a Joomla CMS class may extend a Framework class, and in this case some methods may not be visible under the Joomla CMS documentation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For example, <tt>$app->setHeader()</tt> which is used to set the HTTP response code is not listed under the [https://api.joomla.org/cms-4/classes/Joomla-CMS-Application-CMSApplication.html CMS Application class API], but is available as a method because it inherits from the Framework class [https://api.joomla.org/framework-2/classes/Joomla-Application-AbstractWebApplication.html AbstractWebApplication].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Vendor Namespaces===
These are also in <tt>libraries/vendor</tt>, eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Psr\Container\ContainerInterface;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
refers to <tt>libraries/vendor/psr/Container/src/ContainerInterface.php</tt>. However there are few of these in the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other File Rearrangements===
With all of the namespaced classes moving under the src directories, the <tt>tmpl</tt> layout files and <tt>form</tt> xml files have been moved out into their own directories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Extension and Dispatcher classes ==
===Extension===
In Joomla 3 the point where the Joomla core handed over to your component code was when it ran your <tt>helloworld.php</tt> code; if it was the frontend it ran your site <tt>helloworld.php</tt> code, or if was the backend it ran your admin <tt>helloworld.php</tt> code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the entry point into your component code is your Extension class, both for site and admin, found in <tt>admin/src/Extension/HelloworldComponent.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When the Joomla core application wants to start executing the component code it creates an instance of <tt>HelloworldComponent</tt>, just to get a handle on the component code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Similarly (as described below) other Joomla classes such as Router or Categories need to call certain Helloworld methods (eg custom router functions). In Joomla 3 these methods were written in certain Helper files etc. In Joomla 4 the principle is that the component creates an instance of the <tt>HelloworldComponent</tt> Extension class, and calls the required methods on that instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This Extension class isn't anything like a big container class for the component, it's more like a glue class, providing a way in to the Helloworld component, enabling the Joomla core and other components call the methods which they want to call.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla core wants to execute the component code, the key method it is looking for in your <tt>Extension</tt> instance is <tt>getDispatcher</tt>, and it expects to get back a <tt>Dispatcher</tt> instance. The <tt>HelloworldComponent</tt> extends <tt>MVCComponent</tt>, which in turn extends <tt>Component</tt>, and it is this class which defines <tt>getDispatcher</tt> for us.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Dispatcher===
When Joomla wants to run the Hello World component, it gets the <tt>Dispatcher</tt> instance as described above and then calls the <tt>dispatch</tt> method on it. It is this <tt>dispatch</tt> function which replaces the functionality in the admin and site <tt>helloworld.php</tt> files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's look at the main lines of code in our Joomla 3 admin <tt>helloworld.php</tt> file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="site/views/form/view.html.php">
<syntaxhighlight lang="php">
if (!JFactory::getUser()->authorise('core.manage', 'com_helloworld'))
{
throw new Exception(JText::_('JERROR_ALERTNOAUTHOR'));
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Get an instance of the controller
$controller = JControllerLegacy::getInstance('HelloWorld');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Execute the Request task method
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
// Redirect if set by the controller
$controller->redirect();
</syntaxhighlight>
</span>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code
* performs some permissions checks
* instantiates the appropriate Helloworld controller
* executes the appropriate method in that controller
* implements any redirect set by the controller
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Model-View-Controller]] for further details of how this works in Joomla 3. The second and third steps used the <tt>task</tt> parameter within the URL query to determine the correct controller class to instantiate and method to call. If no <tt>task</tt> parameter was present then it instantiated the controller in <tt>controller.php</tt> and called the <tt>display</tt> method. Otherwise it instantiated one of the controllers in the <tt>controllers</tt> subfolder (eg <tt>controllers/helloworld.php</tt>) and called the appropriate method on it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>ComponentDispatcher::dispatch</tt> method (in <tt>libraries/src/Dispatcher/ComponentDispatcher.php</tt>) now provides this functionality, but in a nicer way. After checking the permissions it uses the <tt>task</tt> by considering its parts as <tt><controller type>.<method></tt> (taking 'display' as default if either part is missing). It will then pass control to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* an instance of the class <Controller type>Controller
* calling the function <method>
* using the admin or site controller, as appropriate
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In this way the naming of the controllers is consistent - we have DisplayController, HelloworldController and HelloworldsController, all in the same folder.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Dispatcher class can thus be considered as providing some 'routing - execution' functionality, enabling us to find the right controller and function within that controller, and it is cleaner to have this in a separate class rather than in the <tt>JControllerLegacy</tt> class as it was in Joomla 3.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Since the Hello World tutorial uses the standard Joomla pattern for selecting the class and method based on the <tt>task</tt> and has the same permissions checks, we can use the <tt>dispatch</tt> code as it stands in <tt>ComponentDispatcher</tt>, and don't need to define a special class of our own.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Factory classes ==
In Joomla 3 many classes had static <tt>getInstance</tt> methods which returned an instance of that class, configured with the parameters passed to <tt>getInstance</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the <tt>getInstance</tt> methods have been deprecated in favour of using Factory classes. The preferred mechanism is now to
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* get an instance of the appropriate Factory class (how we do that is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below)
* call the <tt>createSomething()</tt> method of the Factory class with relevant parameter values to generate an instance of the Something class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===MVC Factory===
In this section the <tt>MVCFactory</tt> class refers to the one in <tt>libraries/src/MVC/Factory/MVCFactory.php</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory class will instantiate Controller, View, Model and Table instances on our behalf, and it does this by generating the classname of the class and then calling <tt>new</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The way it works is as follows:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Each component gets an individual MVCFactory instance which is constructed passing the component's namespace as a parameter (so in our case 'Robbie\Component\Helloworld'). (How this MVCFactory instance is created is covered in the [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#services.2Fprovider.php|services/provider.php section]] below).
# The MVCFactory createController / createView / createModel / createTable function is then called, passing the name of the Controller / Model / View / Table and the prefix (which specifies whether the administrator or site class is required).
# The create function forms the classname from this data and calls <tt>new</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVCFactory create functions just form the classname from the parameters they're passed. The intelligence for working out what name and prefix should be used to form the appropriate classes for an incoming HTTP request is
* in the dispatcher code for defining the controller to use
* in the controller for the view and model
* in the model for the table
and, for example, the names of the classes created for a request with URL query <tt>?option=com_helloworld&view=viewname</tt> and no <tt>task</tt> parameter will be
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<namespace>\Controller\DisplayController
<namespace>\View\Viewname\HtmlView
<namespace>\Model\ViewnameModel
<namespace>\Table\ViewnameTable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you need an alternative name then you can override the appropriate getView, getModel or getTable function – as for example was done in the [[J3.x:Developing an MVC Component/Adding Custom Fields#Front-end_Form|Adding Custom Fields step, frontend Form section]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So from the outside this is pretty much the same as in Joomla 3. However, note that the <tt>$prefix</tt> parameter in calls to <tt>getModel</tt> etc is subtly different
* in Joomla 3 this referred to a prefix to be applied to the classname – in the tutorial code we used 'HelloWorldTable' as the prefix part of the 'HelloWorldTableHelloWorld' classname.
* in Joomla 4 this refers to a prefix higher up the classname path, and should be set to either 'Site' or 'Administrator' (the capital letter at the start is optional), depending on whether you want the class under 'Robbie\Component\Helloworld\Site' or 'Robbie\Component\Helloworld\Administrator'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The MVC Factory class is now the Joomla recommended way to create the controller, view, model and table classes, by using the eg <tt>getModel()</tt> method, and the use of <tt>getInstance()</tt> for these classes is now deprecated. However, the use of these functions is restricted:
* in the controller class you can call <tt>$this->getView($viewname, $viewtype, $prefix, $config)</tt> to create a view and <tt>$this->getModel($modelname, $prefix, $config)</tt> to create a model.
* in the view class you can call <tt>$this->getModel($modelname)</tt>, but only for models which the controller has previously defined using <tt>$view->setModel($modelname, $default)</tt>. It doesn't create a new model instance.
* in the model class you can call <tt>$this->getTable($tableclass, $prefix, $options)</tt> to create a table instance. Controllers and views can access the table classes in this way, by going via a model.
These restrictions do have an impact on moving away from using <tt>getInstance()</tt>, and indeed in Joomla 4.2.6 you will still find several <tt>getInstance()</tt> calls within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Other Factory Classes===
Several other Factory classes have been introduced in Joomla 4, enabling you to get instances of core classes such as Form, User, CacheController, etc, usually by calling a createSomething function on the Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Associated with the Factory class is a FactoryInterface, a PHP Interface which specifies the key functions which the Factory class must implement. For example, with <tt>libraries/src/Categories</tt> we have:
* CategoryFactoryInterface – which specifies the <tt>createCategory</tt> function
* CategoryFactory implements CategoryFactoryInterface – which provides the <tt>createCategory</tt> function.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Dependency Injection ==
===Overview===
The DI container is one of the significant new additions to Joomla 4. It's basically a repository of key-value pairs where:
* the key is a string which is the name of a class or interface
* the value is an instance of the relevant class, or a function that returns an instance of that class.
You put things into the container using <tt>set()</tt> passing:
* the class name or interface name
* a function which returns an instance of the class (or an instance of the class)
* a boolean defining whether the class instance may be shared or not
* a boolean defining whether this entry into the DI container is protected or not (an error will be raised if you try to overwrite a protected entry by calling <tt>set()</tt> again using the same key).
The function <tt>share()</tt> is basically the same as <tt>set()</tt> with the <tt>shared</tt> boolean set to true.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You get things out of the container by calling <tt>get()</tt> passing the key of the resource you want. The container will
* find the key in the container
* if the value isn't already a class instance, then it will run the associated function to generate an instance of the class
* if the resource is shared, it will store the class instance, so that on subsequent invocations of <tt>get()</tt> it can just return the instance
* return the class instance to you
You can also define aliases for each key in the container, which means that you call <tt>get()</tt> passing either the key or an alias of the key.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The DI container is initialised in <tt>library/src/Factory.php createContainer()</tt> which results in the <tt>register()</tt> function being called in each of the class files in <tt>libraries/src/Service/Provider</tt>. By looking through those files you can see what gets put into the DI container upon initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===JConfig Example===
Let's consider the example of JConfig which holds the system global configuration. If you look inside <tt>libraries/src/Service/Provider/Config.php</tt> then you'll see the <tt>register()</tt> function and that it stores in the DI container a resource with:
* key = 'JConfig'
* value = an anonymous function - which loads what's in <tt>configuration.php</tt> into a <tt>Registry</tt> object, and returns it
* shared flag = true (because the <tt>share()</tt> function is used)
* protected flag = true
Then when you do
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$config = $container->get('JConfig');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will run the anonymous function and return the Registry object to you. As the 'shared' boolean is set it will also store a copy of the class instance locally in the container to be returned on subsequent calls of <tt>get('JConfig')</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Justification===
What's the point of all this?
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The advantage of dependency injection is that it allows classes to be easily mocked for testing. The file <tt>libraries/src/Service/Provider/Config.php</tt> can be replaced to return to a DI container <tt>get()</tt> call a mock class instead of the usual <tt>JConfig</tt>. This is in comparison to Joomla 3 where <tt>Factory::getConfig()</tt> code directly reads the <tt>configuration.php</tt> into a Registry structure and returns it – which makes it harder to mock.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The [https://api.joomla.org/cms-4/classes/Joomla-CMS-Factory.html Factory API] has several functions which are marked as deprecated with advice to get the object from the DI container instead.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Several of the other Factory classes (eg Form, Language, Menu, User) are in the DI container – so that we can get an instance of them via eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Factory::getContainer()->get('Joomla\CMS\Toolbar\ToolbarFactoryInterface')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to get a Toolbar instance. However, this only works for singleton classes which aren't specific to the needs of a particular extension. We'll see shortly how to make it work for class instances which need to be specific to a component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As indicated above, Joomla is moving away from using the class static <tt>getInstance()</tt> functions. We can see now that this is not only because it's more pure from an object oriented perspective. But also creating class instances from the DI container, or from Factory objects which are obtained from the DI container, builds in the dependency injection which allows classes to be more easily mocked, and hence more easily tested.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==services/provider.php==
We're now finally in a good position to understand what's happening in our services/provider.php file, and we'll explore this by walking through what happens whenever this line in libraries/src/Component/ComponentHelper.php <tt>renderComponent</tt> is run:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is run whenever Joomla has worked out which component is to be run on the requested web page, and it wants to run that component to capture its output.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 1 Create Child DI Container===
Joomla first creates another DI container (initially empty) just for this component, and links it to the main DI container via a parent field in the child DI container structure.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Now whenever <tt>set()</tt> is called on this DI container the key-value pair is inserted into the child container. Whenever <tt>get()</tt> is called on it, the resource is obtained from the child container, but if it's not found there then the parent container is searched also.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 2 Run register() in provider.php===
Next we encounter these lines (in <tt>libraries/src/Extension/ExtensionManagerTrait.php</tt>), where <tt>$path</tt> contains the path of our helloworld admin/services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$provider = require_once $path;
// Check if the extension supports the service provider interface
if ($provider instanceof ServiceProviderInterface) {
$provider->register($container);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here we see 3 things:
# our provider.php should return some object (so that <tt>$provider</tt> gets set to something)
# what is returned should implement ServiceProviderInterface (you can see in <tt>libraries/vendor/joomla/di/src/ServiceProviderInterface.php</tt> what is expected)
# the code then runs the <tt>register</tt> function on that object, passing as a parameter the child DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Let's consider a minimal version of our provider.php file. This would actually support steps in the Joomla 3 tutorial up to and including the [[J3.x:Developing an MVC Component/Adding AJAX|Adding Ajax step]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {

public function register(Container $container): void
{
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
}
};
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As you can see from the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
return new class implements ServiceProviderInterface {
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
this file does indeed return something – it returns an instance of an anonymous class, one that implements <tt>ServiceProviderInterface</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it's not sufficient to just provide the <tt>register</tt> function in the class, we also need to explicity state that the class implements <tt>ServiceProviderInterface</tt>. This now happens in several places in Joomla, so if you're debugging your component and wondering why a function you expect to be called isn't being called, then check to make sure that you don't have to explicitly add the appropriate <tt>implements <Interface></tt> clause to your class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Next we look at the 3 lines in the <tt>register</tt> function
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3a Registering our MVC Factory===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new MVCFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here our <tt>MVCFactory</tt> refers to <tt>Joomla\CMS\Extension\Service\Provider\MVCFactory</tt> in libraries/src/Extension/Service/Provider/MVCFactory.php, and you should have a look at this file. This is a file similar to our provider.php file, but it's a named class, and it doesn't return anything. When we do:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
new MVCFactory('\\Robbie\\Component\\Helloworld')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it creates an instance of this class, and in the constructor it stores locally in <tt>$this->namespace</tt> our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>registerServiceProvider</tt> function then calls the <tt>register</tt> function of this instance, which runs (in its minimalist form):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
MVCFactoryInterface::class,
function (Container $container) {
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
return $factory;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So what gets entered into our child DI container is a key-value pair with:
* key = MVCFactoryInterface::class (this is just a shorthand form to obtain a string of the fully qualified name – ie 'Joomla\CMS\MVC\Factory\MVCFactoryInterface')
* value = a function which returns an instance of <tt>\Joomla\CMS\MVC\Factory\MVCFactory</tt>.
This is our MVCFactory class which generates our Controllers, Views, Models and Tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Notice that we're passing our namespace as a parameter <tt>$this->namespace</tt>. Because this function is a closure, this variable will still be available when we run this function later, and when the MVCFactory class is instantiated the namespace will be passed into the constructor, stored locally, and then subsequently used to form the fully qualified names of our Controllers, View, etc. So this is how we get instantiated the MVCFactory class which is specific to our component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3b Registering the Dispatcher Factory===
Careful: ComponentDispatcherFactory refers to two different classes here!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new ComponentDispatcherFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This ComponentDispatcherFactory is Joomla\CMS\Extension\Service\Provider\ComponentDispatcherFactory in libraries/src/Extension/Service/Provider/ComponentDispatcherFactory.php. Similar to the above, the ComponentDispatcherFactory service provider class stores locally our namespace, and then when <tt>register</tt> is called it executes:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentDispatcherFactoryInterface::class,
function (Container $container) {
return new \Joomla\CMS\Dispatcher\ComponentDispatcherFactory($this->namespace,$container->get(MVCFactoryInterface::class));
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so a second entry is added to the child DI container with:
* key = ComponentDispatcherFactoryInterface::class
* value = a function which returns an instance of the ComponentDispatcherFactory (the other ComponentDispatcherFactory class!), where the class constructor will be passed the namespace ('\\Robbie\\Component\\Helloworld') and an MVCFactory instance, retrieved from the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that the code
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->get(MVCFactoryInterface::class)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
will get from the container an entry with key = 'Joomla\CMS\MVC\Factory\MVCFactoryInterface' – which is what we entered into the container in step 3a – and will run the function associated with this key, and then return the object which this function returns. This returned object will be an instance of '\Joomla\CMS\MVC\Factory\MVCFactory', constructed using our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3c Including the Extension===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(
ComponentInterface::class,
function (Container $container) {
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
}
);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will put into the child DI container a key-value pair with
* key = ComponentInterface::class
* value = the function which will create an instance of our <tt>HelloworldComponent</tt> (ie our Extension class), and pass into the constructor an instance of the ComponentDispatcherFactory class, retrieving what was entered into the child DI container in Step 3b.
It will call <tt>$container->get(MVCFactoryInterface::class)</tt>, getting an MVC Factory instance from what was entered into the DI container in Step 3a.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It will then associate our component with this MVC Factory instance via the <tt>setMVCFactory</tt> call. Significantly this will then allow our component to access this instance later, via a call to <tt>getMVCFactory</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 3 Summary===
We have now got 3 entries in our child DI container, keyed by
* key = MVCFactoryInterface::class, value is a function returning an MVCFactory instance
* key = ComponentDispatcherFactoryInterface::class, value is a function returning a ComponentDispatcherFactory instance
* key = ComponentInterface::class, value is a function returning our HelloworldComponent, an instance of our Extension class.
The important aspect is that these entries are all aware of our namespace '\Robbie\Component\Helloworld' and will return instances of these classes which are specific to our Helloworld component.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 4 Retrieving from the DI Container===
Joomla will then execute the line:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $container->get($type);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
where <tt>$type</tt> contains 'Joomla\CMS\Extension\ComponentInterface'.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This starts the process of retrieving from the DI container the 3 entries which we put in, and will run our code in services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = new HelloworldComponent($container->get(ComponentDispatcherFactoryInterface::class));
$component->setMVCFactory($container->get(MVCFactoryInterface::class));
return $component;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We end up with a HelloworldComponent instance, which has:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. a ComponentDispatcherFactory instance passed into the constructor, and which is saved locally by the constructor code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function __construct(ComponentDispatcherFactoryInterface $dispatcherFactory)
{
$this->dispatcherFactory = $dispatcherFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This code is in libraries/src/Extension/Component.php, in the class which our HelloworldComponent extends, via the class MVCComponent).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. an MVC Factory instance, stored by the HelloworldComponent <tt>setMVCFactory</tt> call
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 5 Call boot() on our Component===
Joomla calls:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
if ($extension instanceof BootableExtensionInterface) {
$extension->boot($container);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will call <tt>boot</tt> within our HelloworldComponent, and allows us to perform some initialisation within our component. We'll return to this later, in the section on [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#HTML_Snippets|HTML snippets]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note again that Joomla checks that our HelloworldComponent class implements BootableExtensionInterface before calling <tt>boot</tt>. It's not sufficient to just provide the <tt>boot</tt> function, we have to explicitly declare that our HelloworldComponent implements the interface.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 6 Get the Dispatcher===
Returning to our key line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
we have now accomplished the first part <tt>bootComponent($option)</tt>, and this has returned our HelloworldComponent instance. Now we call <tt>getDispatcher($app)</tt> on this instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This code is also in libraries/src/Extension/Component.php, in the Component class which our HelloworldComponent extends:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function getDispatcher(CMSApplicationInterface $application): DispatcherInterface
{
return $this->dispatcherFactory->createDispatcher($application);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We call <tt>createDispatcher</tt> on our ComponentDispatcherFactory class instance which we saved in Step 4. This code is in libraries/src/Dispatcher/ComponentDispatcherFactory.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createDispatcher(CMSApplicationInterface $application, Input $input = null): DispatcherInterface
{
$name = ucfirst($application->getName());

$className = '\\' . trim($this->namespace, '\\') . '\\' . $name . '\\Dispatcher\\Dispatcher';

if (!class_exists($className)) {
if ($application->isClient('api')) {
$className = ApiDispatcher::class;
} else {
$className = ComponentDispatcher::class;
}
}

return new $className($application, $input ?: $application->input, $this->mvcFactory);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The code checks if we have our own Dispatcher class (our Helloworld tutorial doesn't, but <tt>com_users</tt> for example has its own). So it creates a <tt>ComponentDispatcher</tt> instance, and passes into its constructor the MVC Factory instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Remember that this ComponentDispatcherFactory instance is what was instantiated when it was retrieved from our child DI Container (from being inserted in step 3b), and hence it already knows about our namespace, and has a pointer to our MVCFactory class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Step 7 call dispatch()===
This is the final aspect to our line of code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$app->bootComponent($option)->getDispatcher($app)->dispatch();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We're now back to what was described in the Dispatcher section above, except that now we can see that this Dispatcher instance has a pointer to our MVC Factory instance (which knows about our namespace prefix), so when the Dispatcher code wants to create a Controller it can use that MVC Factory instance to instantiate it.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's been a long and tortuous journey to get here, but the significant thing is that all of our key class instances have been obtained via the DI Container. If we want to mock out any of those classes for testing then all we need to do is replace the relevant services/provider file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Javascript and the Web Asset Manager ==
The web asset manager has been introduced in Joomla 4 and is well documented [[J4.x:Web_Assets|here]]. It provides a much-improved means of managing JS and CSS resources, and a framework for handling their dependencies.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Component Javascript and CSS files should now be stored in the <tt>media</tt> folder, and the Web Asset Manager used to register them and output them on specific web pages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following assets have been registered in the tutorial <tt>joomla.asset.json</tt>, and you should have a look at that file now.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.validate-greeting===
This is the code for client validation of the helloworld greeting field using a regex, and it is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that it is dependent upon jQuery and the Joomla <tt>form.validator</tt> script, so those both get included as dependencies.
If we didn't have specific validation on our form then we would need to include explicitly the <tt>form.validator</tt> script in order for the basic Joomla field validation to be included, eg in the tmpl file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->document->getWebAssetManager()->useScript('form.validate');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that this requires us to have a <tt>class="form-validate"</tt> on the </tt><form></tt> html element.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.fix-permissions-ajax-call===
This is the code which copies the value from the greeting field into the title field, so that the Ajax calls setting the permissions work correctly. The js code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.enable-tooltips===
This is the code which enables bootstrap tooltips to operate, including allowing them to include html code. It's used to display the image as a tooltip within the admin <tt>helloworlds</tt> view.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.openstreetmap===
This is defined as a preset, comprising the helloworld js and css code for the map display, as well as the dependency named 'com_helloworld.openlayers' relating to the openlayers CSS and js code. The code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_helloworld.admin-helloworlds-modal===
This is the js code for selecting an individual helloworld record within a modal, and passing its details to the form in the main window. Its code is unchanged.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===submitbutton.js===
In the Joomla 3 code we introduced in [[Special:MyLanguage/J3.2:Developing_an_MVC_Component/Adding_verifications|Adding Verifications]] a js file which controlled when the form was submitted. It differentiated between buttons such as <tt>Save</tt> (which submitted the form) and <tt>Cancel</tt> (which didn't).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 there is a more sophisticated version of <tt>Joomla.submitbutton</tt> (found in media/system/js/core.js) which uses the CSS classes which the Toolbar functionality sets on the buttons to determine whether the form should be submitted or not. And you can override whether the validation is performed by adding a third parameter to the <tt>submitbutton</tt> js call. For example, to avoid validation being performed when a button is clicked you can set on the button element:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
onclick="Joomla.submitbutton('controller.method', '', false)"
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As this is sufficient for what we need in the tutorial, the custom <tt>submitbutton.js</tt> has been removed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Interaction with other components ==
The way that Joomla interacts with components has changed in Joomla 4. In general the Joomla functionality will boot the component using something like:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$extension = $app->bootComponent($option);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and in our case this will return an instance of the <tt>HelloworldComponent</tt> class. It will then try to call certain methods on our extension object, as described below.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_categories===
In the backend the helloworld functionality can display to the administrator
* the view of the helloworld messages
* the view of the helloworld categories
The categories view is generated by <tt>com_categories</tt>, and in Joomla 4 these component categories views display the number of component records there are for each of the possible published status values. To do this the categories component executes the following code (in administrator/components/com_categories/src/Model/CategoriesModel.php):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof CategoryServiceInterface) {
$component->countItems($items, $section);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So our HelloworldComponent must:
* declare that it implements <tt>CategoryServiceInterface</tt>
* provide an implementation of <tt>countItems</tt>
We provide <tt>countItems</tt> by using a trait in libraries/src/Categories/CategoryServiceTrait.php, which (with the assistance of a helper function) does the query on our behalf. We just need to tell it:
* the name of our table – in the callback <tt>getTableNameForSection</tt>
* the database field in which we hold the published status – in <tt>getStateColumnForSection</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_associations===
Remember that <tt>com_associations</tt> is the component which is run whenever you click on Multilingual Associations in the admin backend.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Under Joomla 3 we provided an associations helper file as described in [[J3.x:Multilingual Associations/Developers|Multilingual Associations/Developers]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the helper file remains basically the same, but <tt>com_associations</tt> primarily tries to find the helper file via the extension class; here's the code:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($extensionName);
if ($component instanceof AssociationServiceInterface) {
return $component->getAssociationsExtension();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It's expecting that:
* the extension (HelloworldComponent in our case) implements <tt>AssociationServiceInterface</tt>
* its <tt>getAssociationsExtension</tt> method returns the helper class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The easiest thing would be just to code <tt>getAssociationsMethod</tt> and get it to return <tt>new AssociationsHelper</tt>. However, we follow the Joomla 4 principle of putting key classes into the Dependency Injection container, and retrieving them later, by having the following code in our services/provider.php:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->set(AssociationExtensionInterface::class, new AssociationsHelper());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The above line puts a key-value pair into our child DI container
* key = 'Joomla\CMS\Association\AssociationExtensionInterface'
* value is an instance of our <tt>AssociationsHelper</tt> class.
We then retrieve it later and use the setter:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setAssociationExtension($container->get(AssociationExtensionInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so that whenever
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getAssociationExtension()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
is called it returns the <tt>AssociationsHelper</tt> class instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_fields===
<tt>com_fields</tt> is the component which is run when an administrator clicks on the Fields or Field Groups menuitem within the backend, and this functionality was included in the [[J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Adding Custom Fields]] tutorial step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>com_fields</tt> component stores the custom fields and field groups for all components in the database tables <tt>#__fields</tt> and <tt>#__fields_groups</tt>, and these tables are partitioned into "sections", one section per component. For our helloworld component the section is named "helloworld".
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within the section we have 2 "contexts" – one for the helloworld messages (called "com_helloworld.helloworld") and one for the helloworld categories (called "com_helloworld.categories"). This enables us to define custom fields for both our helloworld records and helloworld category records.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When <tt>com_fields</tt> runs it checks both the section and contexts at various times. For example, when an admin selects Helloworld / Fields on the backend then <tt>com_fields</tt> checks the section which was defined in the menuitem in the manifest file (see [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Sidebar|below]]). Here's the code in administrator/components/com_fields/src/Helpers/FieldsHelper <tt>extract</tt> function:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
$newSection = $component->validateSection($parts[1], $item);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And when <tt>com_fields</tt> wants to display the little dropdown menu of contexts (to allow the administrator to set custom fields on either helloworld items or categories) it calls (in administrator/components/com_fields/src/Fields/FieldcontextsField.php <tt>getOptions()</tt>):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component = Factory::getApplication()->bootComponent($parts[0]);
if ($component instanceof FieldsServiceInterface) {
return $component->getContexts();
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So it's clear that our component extension class must :
* implement <tt>FieldsServiceInterface</tt>
* provide the <tt>validateSection</tt> and <tt>getContexts</tt> methods
So in upgrading to Joomla 4 we've just moved those two methods from the helper file to the extension class.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Router===
The Joomla router will access our custom router code:
* whenever it wants to parse an SEF route which it has identified as belonging to <tt>com_helloworld</tt>
* whenever it wants to build an SEF route from a call to <tt>Route::_()</tt> where the option = "com_helloworld".
To find our custom router it will:
* boot the <tt>com_helloworld</tt> extension
* check that the extension implements <tt>RouterServiceInterface</tt>
* call <tt>createRouter</tt> on our extension instance
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In our services/provider.php file we have (careful again - 2 different RouterFactory classes!):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$container->registerServiceProvider(new RouterFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which from libraries/src/Extension/Service/Provider/RouterFactory.php puts into our child DI container an entry with:
* key = "Joomla\CMS\Component\Router\RouterFactoryInterface"
* value is a <tt>\Joomla\CMS\Component\Router\RouterFactory</tt> instance, constructed with our namespace
We then retrieve this in the line in our services/provider.php file:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setRouterFactory($container->get(RouterFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
And then within our extension class we have
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use RouterServiceTrait;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which includes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function setRouterFactory(RouterFactoryInterface $routerFactory)
{
$this->routerFactory = $routerFactory;
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which stores the <tt>routerFactory</tt> locally and
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return $this->routerFactory->createRouter($application, $menu);
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which provides our extension's <tt>createRouter</tt> call that the Joomla Router expects.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>routerFactory::createRouter</tt> method is in libraries/src/Component/Router/RouterFactory.php. It looks for a class in our site namespace </tt>Robbie\Component\Helloworld\Site\Service\Router</tt> which is in our site/src/Service/Router.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
At this stage we have a choice, we can either:
* provide a traditional custom router, with the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions, or
* use the more modern <tt>RouterView</tt> mechanism.
By default in the upgraded tutorial code the Router View option has been coded in the Router.php file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====RouterView====
In the <tt>RouterView</tt> case the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> functions are in the <tt>RouterView</tt> class which we extend, and we provide
* a constructor with router view configuration
* methods <tt>getHelloworldId</tt> and <tt>getCategoryId</tt> which are used to obtain from the SEF segment the <tt>id=</tt> and <tt>catid=</tt> parts of the internal URL
* methods <tt>getHelloworldSegment</tt> and <tt>getCategorySegment</tt> which are used to generate segments for the SEF URLs based on the <tt>id=</tt> and <tt>catid=</tt> parts within the <tt>Route::_()</tt> parameter.
Unfortunately there doesn't seem to be a good guide to configuring the RouterView class. There is some documentation available [https://www.dionysopoulos.me/book/com-router-routerview.html here].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the helloworld tutorial we have 3 views
* a view which displays a single helloworld record
* a view which displays a single helloworld category, and the helloworld records associated with it
* a view which displays the frontend form
So we need 3 Router Views associated with these.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'form' view doesn't have an associated id or catid so it's just a fixed URL, and the router just has to convert between the alias of the form menuitem and the Itemid / view parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'category' view has an associated id (of the category record), and an SEF URL will use the category path down the Categories Nested Set table structure, hence <tt>setNestable()</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The 'helloworld' view has an associated id (of the helloworld record), and in an SEF URL in the category view the helloworld record alias is added to the category path (hence <tt>setParent()</tt>). But although the helloworld records use a Nested Table structure in the database, the URLs just include the alias of the single record, and so <tt>setNestable()</tt> is not used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There doesn't seem to be a way to configure an additional SEF URL scheme which just displays a helloworld segment, without a category segment.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
====Traditional Router====
To use the traditional router in the tutorial code you should uncomment the function in the extension class:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public function createRouter(CMSApplicationInterface $application, AbstractMenu $menu): RouterInterface
{
return new TraditionalRouter($application, $menu, $this->categoryFactory, $this->getDatabase());
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will cause the code in site/src/Service/TraditionalRouter.php to be used. However, changes in the Joomla 4 router mean that the interaction between it and the <tt>preprocess</tt>, <tt>build</tt> and <tt>parse</tt> methods have changed. This requires significant changes to the <tt>preprocess</tt> and <tt>build</tt> methods, but only a minor change to <tt>parse</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
1. Previously Joomla injected into the <tt>$query</tt> parameters the <tt>Itemid</tt> of the active menuitem (ie the id of the menuitem the user is currently on). This meant that we had to change the <tt>Itemid</tt> for links generated by the Language Switcher module (which generates the flags for switching between languages), and these links being associated with a different language would obviously use a different <tt>Itemid</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 you get an <tt>Itemid</tt> in the <tt>$query</tt> parameters only if you specified an <tt>Itemid</tt> in the <tt>Route::_()</tt> call. For others you have to work out which menuitem to use yourself, by using the Joomla menu/menuitems API to find details of the configured menuitems, and work out which to use based on the other <tt>$query</tt> parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You do this in the <tt>preprocess</tt> method, and then the <tt>Itemid</tt> you set will be passed in the <tt>$query</tt> parameters to the <tt>build</tt> method.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
2. In some instances the <tt>Route::_()</tt> URL you're generating matches exactly one of the configured menuitems on the site. In this case the <tt>$query</tt> parameters will match those in the menuitem <tt>"query"</tt> array, and you have to remove explicitly remove the 'view', 'id' and 'catid' parameters so that they don't appear as URL query parameters after the normal SEF URL of the menuitem.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
3. The custom router will be used to build the URLs for the helloworld menuitems shown in menus on the page. For these the <tt>$query</tt> parameters will have the view / id / catid associated with those menuitems. Note that even if you remove these in your <tt>preprocess</tt> method, Joomla will inject them again into the <tt>$query</tt> array when it's passed to your <tt>build</tt> method, so you'll have to remove them again there!
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
4. In the <tt>parse</tt> method you now have to unset the <tt>$segments</tt>, or else Joomla will return an HTTP 404 (page not found). Otherwise <tt>parse</tt> works as before.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
5. I've implemented <tt>build</tt> only for when Multilanguage is enabled on the site. If it's not enabled an empty <tt>$segments</tt> array is just returned, without doing unset on any of the <tt>$query</tt> parameters, so these will appear as URL parameters after the SEF URL. Also it's not coded properly to deal with items which have language set to <tt>*</tt>. These include helloworld records, categories or menuitems (eg the helloworld form).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note also that the <tt>categoryFactory</tt> is also now passed to the router. This is so that it can be used instead of <tt>Categories::getInstance()</tt> to get access to the Categories API calls.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===com_tags===
Whenever we setup a Tags Menu Item Type which displays items having a given tag or tags, then <tt>com_tags</tt> displays those items as links, and uses route helper functions to generate the URL parameters.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The route helpers <tt>com_tags</tt> expects to find loaded into the data of the <tt>#__content_types</tt> table, in the router field, and these have been set to:
* For links to helloworld items: 'HelloworldHelperRoute::getHelloworldRoute'
* For links to helloworld categories: 'HelloworldHelperRoute::getCategoryRoute'
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, <tt>com_tags</tt> doesn't boot the helloworld extension to get access to these, but rather seeks to find them in site/helpers/route.php, so that's where they continue to be.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(We also had a <tt>getCategoryRoute</tt> which was used by <tt>com_categories</tt> in administrator/components/com_categories/src/Helper/CategoryAssociationHelper. When a category was displayed on the frontend then the Language Switcher module (now Language Filter) used this function to generate the links to the Associated Categories. Our <tt>getCategoryRoute</tt> previously was necessary to insert the <tt>lang=<language tag></tt> parameter into the link URL, but since [https://github.com/joomla/joomla-cms/pull/39358 this change] the calling function inserts the <tt>lang</tt> parameter itself, so our <tt>getCategoryRoute</tt> function for this purposes is superfluous.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Deprecated APIs ==
With Joomla 4 there are a number of methods which are deprecated, with a view to removing them in Joomla 5.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Factory Methods===
Many of the <tt>Factory</tt> methods for getting singleton classes have been deprecated in favour of getting these classes via the DI container, and it appears that only class instances which should be obtained via Factory methods are:
* the Application – <tt>Factory::getApplication()</tt>
* the DI container – <tt>Factory::getContainer()</tt>
Here is a list of what has been changed in the tutorial code. Note that with some calls there are variants available, through the aliases defined in the DI container.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDbo'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\Database\DatabaseInterface;
...
$db = Factory::getContainer()->get(DatabaseInterface::class);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, in many classes the database instance is more easily (and efficiently) returned via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$db = $this->getDatabase();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is available in Model classes, custom field definitions, etc.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getUser();'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get the current user use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = Factory::getApplication()->getIdentity()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To get a different user (whose id you know):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\User\UserFactoryInterface;
...
$user = Factory::getContainer()->get(UserFactoryInterface::class)->loadUserById($userid);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Within models which extend Joomla\CMS\MVC\Model\BaseDatabaseModel and views which extend Joomla\CMS\MVC\View\HtmlView you can also use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$user = $this->getCurrentUser()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getDocument()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication()->getDocument()</tt>, or within a View you can use <tt>$this->document</tt>.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getConfig()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Two options have been used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->getConfig()</tt> – returns a Registry object containing all the configuration values
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Factory::getApplication->get('access')</tt> – returns the value of the 'access' configuration parameter
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Factory::getLanguage()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by <tt>Factory::getApplication->getLanguage()</tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JFactory::getCache('com_example', <type>)'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Replaced by
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Cache\CacheControllerFactoryInterface;
...
Factory::getContainer()->get(CacheControllerFactoryInterface::class)->createCacheController(<type>)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated getInstance Methods===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general <tt>getInstance()</tt> calls have been deprecated in favour of obtaining the instance, either via a factory class or via the DI container. For example, within a controller you can use <tt>getModel()</tt> repeatedly to get different models (passing the relevant model names), which results in the MVCFactory class creating the Model classes.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there are currently some problems with replacing some getInstance calls. I expect that the Joomla team will resolve these issues over the course of the Joomla 4 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Categories::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is deprecated with a notice: "Use the ComponentInterface to get the categories". This means that we should get the category factory instance via the DI container. This is done in our services/provider.php by the lines:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\Extension\Service\Provider\CategoryFactory;
...
$container->registerServiceProvider(new CategoryFactory('\\Robbie\\Component\\Helloworld'));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to put into our child DI container the closure which will create a Joomla\CMS\Categories\CategoryFactory instance, constructed with our namespace.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when our HelloworldComponent (Extension) instance is created:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We can then use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$component->getCategoryFactory()->createCategory();
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
to create our Categories object, and in this way get access to the Categories APIs.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(This createCategory method creates the instance by looking for the \\Site\\Service\\Category class within our namespace. The constructor in our class sets our extension ('com_helloworld') and table ('#__helloworld') and calls the parent Categories constructor with these options).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this means that the section of our code where we want to use the Categories APIs must have a pointer to a CategoryFactory instance. In the tutorial code for Joomla 3 there are 2 places where <tt>Categories::getInstance</tt> is used:
* in the custom router code, to handle building and parsing of the category parts of the SEF URL
* in the site category model, where the Categories APIs are used to obtain details of categories to display on the page.
For the custom router code, the CategoryFactory instance is passed as a parameter to the TraditionalRouter constructor so that it can be used there.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, the site category model is instantiated by the MVCFactory instance, and it doesn't make available a CategoryFactory instance. So in this category model the calls to <tt>Categories::getInstance()</tt> have been left, and you can still find a number of calls to <tt>Categories::getInstance</tt> within Joomla core components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>Categories::getInstance()</tt> itself solves the problem of access to a CategoryFactory instance by rebooting our component again to get a pointer to our Extension instance, and thus to the category factory instance. However, this involves a lot of work, so <tt>getInstance</tt> caches locally the Categories instances and just returns one of them if it can.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Pushing the CategoryFactory to the model'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, there is a way to get access to the CategoryFactory instance, by defining your own MVCFactory class, and pushing the instance down through it to the model. Here's how you can go about it:
* Define your own SuperMVCFactory class, which extends the Joomla Joomla\CMS\MVC\Factory\MVCFactory class, but which has a means of storing a CategoryFactory instance. Use the CategoryServiceTrait in libraries/src/Categories/CategoryServiceTrait.php
* Create your own version of the file libraries/src/Extension/Service/Provider/MVCFactory.php, which is the 'provider.php' like file for MVCFactory, but change it so that:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
becomes
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory = new <namespace>\SuperMVCFactory($this->namespace);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
and include
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$factory->setCategoryFactory($container->get(CategoryFactoryInterface::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When Joomla creates a model such as CategoryModel it passes in its constructor the MVCFactory instance (so that the model can call createTable on it), so you can access it via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This will return your SuperMVCFactory instance. So in this way within the model you can access the CategoryFactory, and use it to create the Categories instance via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getMVCFactory()->getCategory() (from the CategoryServiceTrait)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you can get this working you can congratulate yourself on a good understanding of Joomla namespacing and dependency injection! A similar approach to address a similar problem is described [https://www.dionysopoulos.me/book/com-router-push-dependencies.html here]. If you get stuck you can always view the solution by viewing the github tutorial code selecting the branch [https://github.com/robbiejackson/Joomla-4-MVC-Tutorial/tree/push-category-factory-to-mvc push-category-factory-to-mvc].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Table::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There are a couple of calls to <tt>Table::getInstance()</tt> within admin/src/Helper/AssociationsHelper.php in <tt>getItem()</tt>:
* <tt>Table::getInstance('Helloworld', 'Robbie\\Component\\Helloworld\\Administrator\\Table\\')</tt> to get an instance of our HelloworldTable class.
* <tt>Table::getInstance('Category')</tt> to get an instance of the Category table in libraries/src/Table/Category.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We could actually arrange for the AssociationsHelper class to get injected with the MVCFactory instance, so that the HelloworldTable class could be instantiated by it. However, we couldn't use the helloworld MVCFactory instance to create the Category table instance, as it's not in the helloworld namespace, and our MVCFactory instance creates table instances within our namespace only.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Toolbar::getInstance()'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The tutorial code uses <tt>Toolbar::getInstance()</tt> to get a Toolbar instance onto which it can attach the batch button in the helloworlds form. The Toolbar API documentation seems to suggest that we should replace
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Toolbar::getInstance('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
with
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$bar = Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar('toolbar');
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, this currently won't work. The problem is that all the other Joomla code uses <tt>getInstance('toolbar')</tt> to access the Toolbar class, including the code in administrator/modules/mod_toolbar/mod_toolbar.php which renders the toolbar. The <tt>getInstance</tt> method keeps track of the Toolbar instances in a local static variable <tt>$instances</tt>, and returns the same Toolbar instance on repeated invocations.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So if you use the second approach above you will get a Toolbar instance, but it won't be the same Toolbar instance as is stored in the <tt>$instances</tt> variable. It won't then be picked up by the Toolbar module, and so won't be rendered on the form.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Error Handling===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead of
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
JError::raiseError(500, implode('<br />', $errors));
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
you should throw an exception, using or extending one of the standard [https://www.php.net/manual/en/spl.exceptions.php PHP exceptions], eg
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<source lang="php">
throw new \Exception(implode("\n", $errors), 500);
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===jimport===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
jimport is no longer necessary in order to get access to Path or File classes. All of the Joomla classes are found by the autoloader.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Deprecated Methods related to Javascript===
'''JHtml::_('behavior.framework');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In general, the use of JHtml::_('behavior.xxx') is now obsolete, and calls using this have been removed in the tutorial code. The 'behavior.framework' call referred to including jQuery. Where jQuery is necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.formvalidator');'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has been replaced by the <tt>form.validate</tt> javascript asset, and where necessary it has now been included as a dependency in an entry within the helloworld joomla.asset.json file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It can also be included directly using the web asset manager:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$wa->useScript('form.validate')
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('behavior.tooltip')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This no longer exists, and tooltips don't seem to be enabled by default in Joomla 4. This is replaced by the code in media/js/enable-tooltips.js.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''JHtml::_('formbehavior.chosen')'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The chosen js library seems to be no longer used, and using it will cause formatting issues if you include it in your tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''sortable'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The sortable js library provided the ability in the helloworlds view to drag rows up and down to change the ordering of the records. This has been replaced in Joomla 4 by the draggable library. To enable it you have to set:
* <tt>HTMLHelper::_('draggablelist.draggable');</tt>
* on your <tt><tbody></tt> element define the table in which dragging occurs and the URL of the Ajax call to set the ordering:
<source lang="php">
<tbody<?php if ($saveOrder) : ?> class="js-draggable" data-url="<?php echo $saveOrderingUrl; ?>" data-direction="<?php echo strtolower($listDirn); ?>" data-nested="true"
<?php endif; ?>>
</source>
* on your <tt>tr</tt> element within your <tt><tbody></tt> define the group of records in which dragging occurs (by category below):
<source lang="php">
<tr class="row<?php echo $i % 2; ?>" data-draggable-group="<?php echo $row->catid; ?>">
</source>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==HTML Snippets==
There are two places in the tutorial where reusable snippets of HTML have beeen defined:
* For displaying the item associations in the helloworlds view:
* For displaying the position latitude and longitude fields within the batch options in the helloworlds view
These used different approaches:
* the item associations display was coded in an html helper file in admin/helpers/html/helloworlds.php and accessed via
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JHtml::_('helloworlds.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
in the helloworlds tmpl file. (Although it did use a common joomla layout file underneath).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* the position field was coded as a layout in layouts/position.php, and rendered using
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo JLayoutHelper::render('position', array());
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When should you use one approach rather than the other? A significant difference is that layouts are designed so that an administrator can override them, via the Templates / Details and File functionality. So, for example, an administrator could change the position to show the longitude before the latitude. So it's more appropriate for layouts to focus on the html elements rather than functional logic, and particularly if you would want to allow an administrator to override the layout.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The layouts functionality in Joomla 4 hasn't changed significantly. One correction which has been made in the updated tutorial code has been to include the position.php file in a subfolder of layouts, ie in admin/layouts/helloworld/position.php rather than admin/layouts/position.php. It appears that in the Templates / Details and Files / Create Overrides tab the <tt>com_helloworld</tt> layout appears only if it's in a subfolder of /layouts.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The <tt>JHtml::_()</tt> approach has changed in Joomla 4. Rather than Joomla having to look for a helper file when it encounters something it doesn't recognise, it's expected that you should register such classes beforehand, and you do this by obtaining an instance of the Joomla\CMS\HTML\Registry class (it's a singleton class) and then calling <tt>register</tt> on it, passing
* the key you want to use
* an instance of your class
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The Joomla pattern is to put the code in a file admin/src/Service/HTML/AdministratorService.php, and we have to ensure that our key won't be used elsewhere within Joomla, so in the tutorial we've used:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Robbie\Component\Helloworld\Administrator\Service\HTML\AdministratorService;
...
register('helloworldadministrator', new AdministratorService)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Then when we call:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
echo HTMLHelper::_('helloworldadministrator.association', $row->id);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
it will result in Joomla calling the <tt>association</tt> method in our class, passing the <tt>$row->id</tt> parameter.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We should get the Joomla\CMS\HTML\Registry class from the Dependency Injection container. Joomla components generally do this via their services/provider.php file, and then call <tt>register</tt> within the extension's <tt>boot</tt> function, described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#Step_5_Call_boot.28.29_on_our_Component|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The extension uses HTMLRegistryAwareTrait which contains <tt>setRegistry</tt> and <tt>getRegistry methods</tt>. In services/provider.php there is:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
use Joomla\CMS\HTML\Registry;
...
$component->setRegistry($container->get(Registry::class));
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets 'Joomla\CMS\HTML\Registry' out of the DI container and stores it within the
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
private $registry;
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
variable of the HTMLRegistryAwareTrait included in the extension.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the <tt>boot</tt> function it calls
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
$this->getRegistry()->register('helloworldadministrator', new AdministratorService);
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
which gets the registry and calls <tt>register</tt> as required.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that <tt>boot</tt> is called whenever Joomla dispatches <tt>com_helloworld</tt>, both for the site and administrator, so it would make sense to check the Application <tt>isClient</tt> before deciding whether to register the HTML Helper service or not. This hasn't been included in the tutorial code though.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==User Interface Changes==
Joomla 4 introduced new templates, atum on administrator and cassiopeia on site, and in particular the administrator is built upon some UI rearrangements which affect the tutorial code.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Sidebar===
In Joomla 3 each component incorporated a sidebar which we coded in the <tt>addSubmenu</tt> function in admin/helpers/helloworld.php.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 the administrator menu is in a vertical panel on the left hand side, and the Hello World submenu is built from entries in the helloworld.xml manifest file.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<administration>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<submenu>
<menu link="option=com_helloworld">COM_HELLOWORLD_MENU</menu>
<menu link="option=com_categories&extension=com_helloworld">COM_HELLOWORLD_CATEGORIES</menu>
<menu link="option=com_fields&view=fields&context=com_helloworld.helloworld">MOD_MENU_FIELDS</menu>
<menu link="option=com_fields&view=groups&context=com_helloworld.helloworld">MOD_MENU_FIELDS_GROUP</menu>
</submenu>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===CSS Classes===
In several places the CSS classes defined in the html elements have been changed in Joomla 4. For example, for general layout the classes now align with the [https://getbootstrap.com/docs/3.4/css/ Bootstrap CSS Classes], and classes such as <tt>row-fluid</tt> and <tt>span3</tt> which were prominent in Joomla 3 have disappeared. If you're upgrading a Joomla 3 component then it's probably best (on the back-end at least) to find a similar Joomla component and use the overall html structure and css classes within its tmpl files.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In the tutorial code those classes which are specifically used by Bootstrap have been changed from eg 'data-target' to 'data-bs-target', and it has been necessary to change these to enable the functionality to work.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
However, not all of CSS class changes affecting solely the presentation have been reflected in the updated tutorial code. For example, in the <tt>helloworlds</tt> view, showing the list of helloworld messages, the display of the associations is different from that of other Joomla components.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Fonts===
In Joomla 3 [[J3.x:Joomla_Standard_Icomoon_Fonts|Icomoon Fonts]] were used.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 Font Awesome's free icons are used, and you can see what is available on their [https://fontawesome.com/v5/cheatsheet cheatsheet]. The icons are implemented using CSS pseudo-elements, as described [https://fontawesome.com/v5/docs/web/advanced/css-pseudo-elements here]. Basically they convert a CSS class into html content, namely a unicode value in the private use range. A couple of these have been implemented in the frontend form, in the Save and Cancel buttons, for example:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<tt>span class="icon-cancel">/span <?php echo Text::_('JCANCEL') ?></tt>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(with angle brackets removed from the <tt>span</tt> tags to stop the icon just being displayed by the browser).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This class is defined in media/system/css/joomla-fontawesome.css (where you can find the list of icon classes supported):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
.icon-cancel:before {
content: "\f00d";
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
so this includes in front of the text the unicode character <tt>f00d</tt>, which you can see on the cheatsheet as "times", and displayed as <span class="icon-cancel"></span>. You can also use <tt>fa-</tt> plus the icon name on the font awesome cheatsheet page. If you use Icomoon icon names in your code which you run under Joomla 4, then the icon displayed will be a Font Awesome icon (if there's one with the same name) or it will use a mapping which the Joomla team have defined to display a Font Awesome icon which resembles the Icomoon one.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Buttons and Links===
An accessibility principle is that <tt><a></tt> html elements should be used for links to other web pages, and <tt><button></tt> elements should be used for actions, eg on a form. To align with this, the <tt><a></tt> elements in the helloworld modal field (defined in admin/src/Field/Modal/Helloworld.php) have been changed to <tt><button></tt> elements. These are the Select and Clear buttons displayed when choosing a Helloworld record for a menuitem pointing to a Helloworld message. (The buttons also include fontawesome icons, by the way).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This change was actually made in Joomla in one of the Joomla 3 releases.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Categories View===
In the Categories view of standard Joomla components there now appears columns which show for each category the number of items, split by published status. This is populated by <tt>com_categories</tt> calling each extension's <tt>countItems</tt> function, as described [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_categories|above]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Miscellaneous Changes==
===Version History===
In Joomla 3 the tutorial code used the <tt>JTableObserver</tt> functionality to copy relevant changes from the Helloworld and Categories tables into the UCM tables.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In Joomla 4 it uses a plugin mechanism to subscribe to Table events 'onTableAfterStore' and 'onTableBeforeDelete'. The plugin can be found in plugins/behaviour/versionable, and it is activated by Joomla as part of its application initialisation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The copying of fields from the table works roughly the same way as before, except that the name of the table where the versions are stored is now <tt>#__history</tt>, so the entries which have to be inserted into the <tt>#__content_types</tt> table are fairly similar. Because the folders in which forms are stored has changed in Joomla 4, the 'formFile' parameter is different (remember that this is where Joomla gets the field labels in order to display the Preview within the Versions modal window, otherwise just the names of the database columns will be output).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Here's a summary of what needs to be done to enable versioning under Joomla 4. The Versioning Traits and Interface definitions are found in libraries/src/Versioning:
* Enter data into content_types database table
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Storing the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The Table class must implement VersionableTableInterface and provide <tt>getTypeAlias()</tt>, which returns 'com_helloworld.helloworld'. This type alias + the helloworld record id is used as the key to identify versions in the <tt>#__history</tt> table.
* Define <tt>save_history</tt> and <tt>history_limit</tt> options in config.php, and ensure these are both set.
* Add a <tt>version_note</tt> field into the output of the edit view's tmpl file (admin/tmpl/helloworld/edit.php).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Viewing and Restoring the history:'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit Controller (admin/src/Controller/HelloworldController.php) should <tt>use VersionableControllerTrait</tt>.
* The edit Model (admin/src/Model/HelloworldModel.php) should <tt>use VersionableModelTrait</tt> and include a variable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
public $typeAlias = 'com_helloworld.helloworld';
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The edit View (admin/src/View/Helloworld/HtmlView.php) – should display the Versions toolbar button if global config has <tt>save_history</tt> on.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Joomla 4 allows us to have different history version limits for helloworld items and categories, and this has been used in the configuration definition in admin/config.xml.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Setting Configuration Parameters in Install Script===
As you may remember, global configuration parameters relating to the Hello World component are defined in admin/config.xml and stored in the <tt>#__extensions</tt> table, in a JSON string in the params field of the record relating to <tt>com_helloworld</tt>. This means that when the component is first installed the params are not set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So, for example, even if the <tt>save_history</tt> is defined in config.xml to default to true, the versions won't be saved until an administrator actively saves the configuration parameters, because the Joomla versioning code assumes <tt>save_history</tt> to be false if it's not explicitly set.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For this reason it makes sense to set any default configuration parameters in the install script.php, in the <tt>postflight</tt> method, and that has been done in this step.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Tags===
Like version history, tags functionality has been changed to use a plugin – in plugins/behaviour/taggable – rather than the <tt>JTableObserver</tt> approach.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To enable tags the component table must implement TaggableTableInterface (in libraries/src/Tag), and provide the <tt>getTypeAlias()</tt> which is common to the Versioning functionality.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Whenever <tt>com_tags</tt> outputs helloworld messages or categories relating to a tag it displays them as links, and looks in the site/helpers/route.php file to find the route functions (as described above in [[J3.x:Developing_an_MVC_Component/Upgrading_to_Joomla4#com_tags|com_tags]]). The class and method in this file must match the 'router' field within the data entered into the <tt>#__content_types</tt> table.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===media files===
Under Joomla 4 all of the media files are stored in the /media folder; these include javascript and css files (scss files too), as well as images such as the little flag symbols shown in the language switcher. Extensions being developed should store all of the js and css files in their /media folder, and then when the extension is installed these files are put under the extension's folder under the /media folder of the Joomla instance.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==Patches==
Some bugs in Joomla were discovered during the course of updating the tutorial code to work under Joomla 4. If you find something doesn't work then make sure you're on at least Joomla 4.2.6 and check if you need one of the following patches:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
CategoryAssociationHelper.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39358/files
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
MediaField.php
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/issues/39203
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Category restore
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
https://github.com/joomla/joomla-cms/pull/39474
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Contributors ==
*[[User:Robbiej|Robbie Jackson]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|Prev: Adding Custom Fields|class=expand success}}</div>
</div>
</div>