9 minutos de lectura ( 1714 palabras)

Tools to build a Component - 8: Extension Generator

Tools to build a component - part 8

 In this episode we will look at Extension Generator as a tool to to build a component.

Our journey until now

In this series we want to show some tools that can help to build components for Joomla. 

In episode one and two we introduced  our example, an event schedule, and implemented it  without building a component. We implemented it with core Joomla, with Seblod and Fabrik.

In episode three and four we built a component, without using much tools. We explored how relationships between entities are implemented in Joomla itself and we listed additional features, built-in into Joomla.

In episode five and six we used Component Creator and Component Generator to build our example event schedule component.

In episode seven we created our example event schedule with Joomla Component Builder. At the moment this is by far the most powerful and versatile tool to produce a component.

Extension Generator

Extension Generator is a work in progress by me. It is intended to give extra possibilities, beyond Joomla Component Builder. Unfortunately it is still not yet production-ready. In this article I’ll introduce this Extension Generator, but will deviate from the schema of the previous editions by not implementing our recurring example of an event schedule with this tool. Instead, I’ll show some of the different principles behind it, especially on the meta-level.

Model-Driven

Extension Generator is a Joomla component that builds upon earlier work in Model Driven Development like JooMDD 1. The core of Model-Driven Development (MDD) is that you don’t directly code an application, but first make a model and have your software generated from this model. The term Model-Driven Engineering (MDE) is also widely used, meaning the same, but emphasising that the generation of software is automated. 

The “model” here is not exactly the same concept as Joomla’s Model class that is part of the Model-View-Controller structure of a component. A model in MDE is a blueprint for a component, defining all the things you want to have in that component. Like a construction drawing is a model of a building. It is an abstraction, leaving out irrelevant details.

For instance with the event schedule example we used in our previous editions, our model would define the entities used to build the event schedule: events, actors, event types, containers and sections. 

Besides those entities, their fields and relations, we must define all other information that is needed to make a component: what pages (“views”) do we want to see, what type of extension, what namespace do we use, etc. This is all stored in the model in such a way that the information can be used by a generator to produce the component from it. 

In a model-driven approach the model you build is formalised. It is not some free style sketch of what you want to build, but a strictly defined bunch of information from which a component can be generated automatically.

Tools with an implicit model

In this series we saw several tools to make a component: Component Creator, Component Generator and Joomla Component Builder. They all use this principle to first collect all information (the “model”) needed to build the component and then generate the component from that information. By analysing the screens you have to fill in in order to produce a component, you can see what information is stored in their models. 

What you can put in the model of such a tool is a given, you cannot change that. It is an implicit part of the application.

Meta-level

The main difference with general MDE-tools, like Xtext (where JooMDD was made in) or JetBrains MPS, is that with them you explicitly tell what you want to put in your model. This is done  by defining a “modelling language”, generally known as a “domain specific language” (DSL). This is a meta-level that lets you create any model you want.

Simpler: using forms

In the Extension Generator everything is put into the model with forms. That is the same as with other tools (Component Creator, Component Generator and Joomla Component Builder). Initially the forms that are used now in Extension Generator were based on the modelling language of JooMDD, so the Extension Generator gathered exactly the same information in its model as JooMDD did. 

Creating a modelling language to explicitly define what you want to store in your model is not easy. In the Extension Generator that is done simpler by using forms, also on the meta-level: it uses forms to define the forms you use to put information in the model. Those meta-forms are called Project Forms in the Extension Generator.

Generating a generator

Once you have put everything into your model, the component is generated from it. In Component Creator, Component Generator, and Joomla Component Builder,  this generator is again a black box, implicitly given by the tool. You cannot alter that.

In  the Extension Generator the generator part can be edited. A generator mainly is a mapping of the information in the model to variables in a template-file. Boilerplate code, like the default way to code the Model, View and Controller classes is kept in Twig-templates in the Extension Generator. The word “template” is used here in a broader sense than a template in Joomla: it is any piece of code in which variables are inserted.

Until now the mapping of the information in the model to those templates is done in code, but I’m working on getting that all done with forms. 

So, in the Extension Generator both what you put in the model (the Project Forms)  and what is generated from the model can be edited.

Creating a component with Extension Generator

Currently the Extension Generator still uses the model that was used in JooMDD to define what component you want to have. A good property of that model is that it is not specific for Joomla, but more general.  In that way this same model can also be used with other generators, like for WordPress, Laravel or whatever.

That current model consists of 3 parts:

  1. Data: entities and their relationships.
  2. Interaction: what pages (“views”) you want in your component and which entities are used on those pages.
  3. General info: what type of extension you want, what pages do you want to use in frontend and backend, general parameters, namespace etc.

In the episode 4 of this series I listed features (“Bells & Whistles”) that are built-in into Joomla and can be used in a custom component, like locking, alias handling, item ordering, tags, pagination etcetera. In Component Creator, Component Generator, and Joomla Component Builder, a lot of those features are generated by default. Standard fields like state, ordering, checked_out, checked_out_time, created_by, or modified_by are automatically created by those tools, as is code to make those options work. But maybe you don’t need all those standard fields and code chunks for all entities. For instance, a shopping cart is only used by one user, so locking-information and information about who created or modified the cart is needless overhead. At the moment I’m cleaning the model and generator to make all those extra features optional and only adding them when necessary. So that only code that is needed is generated, nothing more, nothing less.

In Joomla Component Builder you can insert custom code, like view layout templates, in several points of your model. I will add the same possibility in the Extension Generator.

Collaboration and sharing tools

In the model-driven world different tools are used. In 2022 an initiative 2 was taken to create a meta-model with which the models of those diverse tools can be exchanged. As a result you can now use one tool to create a model, another to further edit it and yet another to generate from that model. So, instead of competing with each other and inventing the same wheel, you can now use the strong points of different tools. 


I have the same ideal in mind for tools to create a component. That is why I’m now defining the model used by Joomla Component Builder in this Extension Generator. In order to be able to exchange models, create them in one tool and generate them in another or use features like JCB Super Powers elsewhere. 

A meta-model is a powerful tool. This technique has also been used to integrate information from several CMSs 3.

Extension Generator

  • Goal is: easier to make Joomla components (model with forms).
  • Not only Joomla specific modelling.
  • Unlimited flexibility:
    • Generate generators (using forms).
    • Generate meta-level forms (project forms) to put information in the model

Possibilities to use as a meta-model for different tools. But not yet production-ready.

Next month

In the next episode (May  2025 edition) we will close this series with an overview and some comparisons of the tools.


Notes

  1. JooMDD was also the subject of the dissertation of Dennis Priefer, a real “Doctor Joomla”!
  2. Towards an ecosystem of interoperable components for modelling tools on the web. The LionWeb initiative: https://lionweb.io/.
  3. A paper from 2022 in which a meta-model was used to integrate information from Drupal, WordPress and Joomla: https://modeling-languages.com/wp-content/uploads/2022/03/Enabling-CMS-as-a-content-source.pdf 

Resources

Extension Generator:

Building a component:

Articles in this series about Tools to build a Component:

Extra material like the code for our example event schedule component can be found in the repository for this series.

Some articles published on the Joomla Community Magazine represent the personal opinion or experience of the Author on the specific topic and might not be aligned to the official position of the Joomla Project

5
The April Issue
 

Comentarios

¿Ya està registrado? Ingresa Aquí
No hay comentarios por el momento. Sé el primero en enviar un comentario.

By accepting you will be accessing a service provided by a third-party external to https://magazine.joomla.org/