The framework relies heavily on the placement of class files and naming of classes and tables. There are some specific naming conventions that the framework uses for its default "magic" implementation.
The Object Manager in combination with the Class Locator packages helps locate and load the appropriate files that your application is trying to use.
Classes in the framework (located in joomlatools/library/) follow a very simple naming convention. They are the camelcase of each part of their directory path with the file name appended to the end:
There is one exception, a file can go into a subdirectory as long as it has the exact same name with the directory:
Components are currently located in three places:
Note: Components in libraries/joomlatools-components directory are non-dispatchable and serve as a building block for extensions.
Class names for Components are very similar to Library classes in how they relate to the above directories, but always take the
Depending on which domain or application you are working in the
Com part will be interpreted as your components directory.
Controllers are always singular, this is due in part to the fact that the BREAD actions (more on that later) refer to a single resource type, eg, an article, or a post.
controller classes go in the
controller directory of your component:
For the magic to work
model names are always plural.
model classes go in the
model directory of your component:
The View naming conventions are slightly different in how the Class names are constructed in relation and how the files are named and names of the views themselves.
First though, let's summarize their major characteristics:
- Singular or plural depending upon the view being requested.
- Singular item views require the model state to be unique.
- Plural views refer to multiple items, and may be filtered by states defined in the model.
- Generally map to a database table
- Either return multiple rows or a single row (The "Browse" and the "Read" in BREAD).
- Have several possible format types: HTML, JSON, CSV, RSS.
Your component views go into their own directory in the
views directory. The file names of the actual view classes correspond directly to the
format they are meant to represent. Also, singular and plural views (and their directories) are separated and named accordingly, so if we keep running with our current
com_foo/views/bars/html.php: list view (plural)
com_foo/views/bar/html.php: item view (singular)
If we wanted to specify our own
bars we would do so as follows:
In our other Component parts, the file name and object name match up. In the case of a view, the object name matches its directory.
This is what allows your component to have different format representations.
You can use underscores in the file name as well. The framework treats them exactly the same as a lowercase letter:
The database table naming conventions are also a central piece. Using them properly frees you from the need to write code related to models or tables if you are doing nothing out of the ordinary.
The table name convention is quite simple:
#__ is replaced with your already defined
Following our com_foo example:
There is a related convention for the primary keys for your tables as well:
Following our com_foo example:
Note: The framework will automatically translate the primary key into a property of the name
id. You can just refer to it as
When data is requested by the model from the database, data will be returned as an entity object.
This is a single object that represents an instance of a row from the database. Entities can be saved or deleted and hold the data from the database internally. Columns are accessible as if they were public variables. The name of the entity within the view will be the name of the singular view by default.
This is a collection of entities from the database. You can iterate through the object for specific entities.
The name of rowset within the view will be the name of the plural view.