Joomla Magazine

Original Article

In the previous 8 episodes we looked at tools to build a Joomla component. In this last episode we’ll look back at the previous series and wrap it up.

Overview

Episode 1: Introduction and Core Solution

We introduced our example, an event schedule, for instance for a Joomla Day. We explored the basic entities and made an implementation with core functionality (mainly Additional Fields). We were not yet building a component and didn’t use any tools other than Joomla itself.

Episode 2: An Embedded Application in Joomla

We showed an embedded implementation, using a Content Construction Kit (CCK) and Application Builder (Seblod and Fabrik). So, we still didn’t build a component, but we used some tools.

Episode 3: Creating a Component

We finally started building a component. We did that “by hand”, not using specific tools to build Joomla components. We also spent some time on relationships between entities and how those are implemented in the Joomla core components.

Episode 4: Built-in extras and some setup tools

We listed additional features (“bells & whistles”), built-in into Joomla, that you can use in your component. And showed some smaller tools to help set up a component.

Episode 5: Component Creator & 6: Component Generator

We used the online services of Component Creator and Component Generator to build our example event schedule component.

Episode 7: Joomla Component Builder

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.

Episode 8: Extension Generator

We introduced the Extension Generator and told a bit more about the background of the model-driven approach. A “model” in this sense is a simplification. On a meta-level you can define what to put in your model. And from the model the software is generated. Configuration (model input, model meta-level and generator) is done as much as possible with HTML forms instead of code.

So much can be done with Additional Fields!

Entities and relations can all be made with Additional Fields. By adding custom fields to an existing article (or other core entity) to morph it into another entity plus add the relations between those entities with an SQL-field. Or by embedding an entity into another by using subforms. You can build complete applications with that.

Additional Fields have taken over most of the role of Content Creation Kits (CCKs), like K2, FlexiContent and Seblod. Still, the more advanced CCKs (like Seblod) and embedded applications builders (like Fabrik) can do more than adding fields: they can also create custom tables. Fabrik even automatically makes pivot/junction tables for many-to-many relations.

Additional Fields are great for adding some fields to existing components. But they are not primarily meant to build a highly customised application.

Performance, maintenance and more

A lot is done in the background, every time when using those custom fields: for each field a plugin is called, the information about the field is looked up in the database, the values of that field are retrieved and those fields and values are added to the main content. When using a lot of custom fields, that takes its time. It can slow down your website. Of course, you can boost performance by using a cache well, but it is still putting the cart before the horse. A custom component gets all fields and values much more directly, which is faster.

In order to display the values of custom fields in the way you want it, you’ll make template overrides and alike. In episode one I showed some code to render the different values of our containers and sections in the schedule view. That is code that should be in a Model, not in a View, but because we cannot override the core model, only the template layout, this mixing of Model-responsibilities into the View is necessary. Anything is possible in those template overrides, but you can easily compromise the clean separation of business logic in a model and displaying values in a view. Although initially Additional Fields are easy to use, with extensive template overrides they can become quite messy and hard to maintain. A custom component better separates different responsibilities.

With Additional Fields we can add relations between entities: or by adding an SQL-field that links to another entity or by embedding a subform representing the other entity. When you implement a many-to-many relationship (see episode three) with custom fields, you can only edit values from one side. For instance in our event schedule example, when an actor can do multiple events and an event can be done by multiple actors, then when adding an actor to an event, that event is not automatically also added to the actor. A real two-way implementation of a many-to-many relationship needs a pivot table, also known as a junction table: an extra table in which all combinations of actors and events are registered. You can see the code for that in the repository of this series. In a custom component such a many-to-many relationship can be properly implemented.

Many of the disadvantages of Additional Fields also apply to CCks and Application Builders. A custom component is often the best way to implement something very specific.

Components difficult?

As seen in the last section, custom components have advantages above other solutions. But creating a component is generally seen as difficult. At least more difficult than using Additional Fields. Here is where the tools described in episodes five (Component Creator), six (Component Generator), seven (Joomla Component Builder) and eight (Extension Generator) in this series come into play. What to use?

• When you easily want to set up the basic files of a component, you can use Component Creator and Component Generator. They are not open source, but online services.  For a simple one-entity component they are free to use. If you want to set up a more complex component, you’ll have to pay for a subscription. Of those two tools Component Creator is more advanced than Component Generator (for instance: the possibility to create web services, general parameters, versioning or Finder plugins).

  Both tools provide a “scaffold” for a component: a standard way to create, read, update or delete (CRUD) data in a Joomla component. If you want to have some custom ways to handle your data, want to use other libraries, or display the output in a custom way (like for instance our event schedule example), then you’ll have to manually change the output of the code and/or provide template overrides. But that means that you have to again apply those changes after you have regenerated your code (for instance for a new Joomla version or when adding new things). So, for more complex and very specific applications those tools can be useful as a “starter”, as a first setup for your component.

• Joomla Component Builder: (JCB) is a more complete tool and it is built as a free and open source Joomla component. But it is a tool for developers. So it needs some time to learn how to use it. Best to use it when you know how to build a Joomla component. Then it can save you a lot of time. You can add your own code and template layouts, which will be reused when regenerating your component.

  You get a lot of extras when using JCB, some extra utilities, even some empty files that you could use for future development. The downside is that it is a bit verbose; the generated component has more lines of code than strictly necessary. JCB has a loyal fan base, a small community on its own. It is being actively developed.

• Extension Generator: is a newer tool that aims to specify everything you need with forms. It is also built as a free and open source Joomla component. The current Joomla generator is intended to produce code as lean and clean as possible.  The Extension Generator provides flexibility of what you model, on the meta-level, as well as for the generators that you can make with it. The tool offers possibilities for collaboration. So, promising, but still unfinished and a one man project.

My take on this is that we need two things to make component development for Joomla easier: to keep working on tools and… to invest time in better documentation. In itself making a component is not that difficult, but you have to figure out a lot before coming up to speed with coding a Joomla extension.

What about AI?

Vibe Coding, producing code with the help of Artificial Intelligence (AI), is a hype at the moment. I’ve played around a bit to produce Joomla extensions in that way, but until now not with much success. When prompting a large language model (LLM) to generate some code for Joomla 5, it still produces a lot of Joomla 3 reminiscents. One of the causes of that is, again: the lack of good, actual documentation.

Having code produced by AI has another problem: many of the people who use AI for code generation cannot check the correctness of that code themselves. This whole field has to evolve to assure code quality.This code quality can now better be guaranteed by good model-driven tools.

The Future?

To improve component development for Joomla we’ll have to invest time in:

• Better documentation. Good tutorials and examples.
• Model-driven tools, preferably with easier user interfaces instead of code.
• Collaboration and sharing of tools.

Notes

1. In episode one I explained why I use the term “Additional Fields” instead of  “Custom Fields”. I use “Form Fields” for the fields that we use in our forms in the components we build. Both Additional Fields and Form Fields can be standard and custom.