There are some specific naming conventions that Nooku uses for its default "Magic" implementation.
Understanding these is the key to getting things working!
Because the Framework relies HEAVILY on the proper placement of class files and naming of class and naming of tables, if you get them wrong, you may end up scratching your head saying “why isn’t this class being included?” or "Why is my View not being shown". Your best, first stop in figuring out what happened to you class is to check these conventions.
When we talk about Naming Conventions for classes, really, what we are describing is the work being done by the Object Manager in combination with the Class Locator packages of the Framework. These structures help locate and load the appropriate files that your application is trying to use. Step through them to really get a sense of what is happening.
Classes in the framework (located in koowa/libraries/) 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.
koowa/libraries/controller/model.php -> K + Controller + Model = KControllerModel
the 'K' is interpreted as the koowa/libraries/ folder.
KViewHtml -> koowa/libraries/view/html.php
There is one exception, a file can go into a subfolder as long as it has the exact same name with the folder. e.g:
KCommandChain -> koowa/libraries/command/chain/chain.php
Components are currently located in three places:
administrator/components/com_(package) site/components/com_(package) libraries/koowa/components/com_(package)
We should note that Components in libraries/koowa/components folder 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 (site, administrator or something of your own creation) the
Com part will
be interpreted as your components directory.
site/components/com_foo/controller/bar.php -> ComFoo + Controller + Bar -> ComFooControllerBar site/components/com_foo/model/bars.php -> ComFooModelBars
and the same in reverse.
ComFooControllerBar -> site/components/com_foo/controller/bar.php ComFooModelBars -> site/components/com_foo/model/bars.php
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.
Your controller classes always go in the in the
./controller directory of your component; NOT the plural ./controllers.
ComFooControllerBar -> site/components/com_foo/controller/bar.php
Your Model classes go in the
./model folder of your component's directory.
For the Magic to work Models names are always plural. The rationale being that they map to an associated database table by default, and that database table always has more than one row.
com_foo/model/bars.php -> ComFoo + Model + Bars -> ComFooModelBars
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:
Your component views go into their own folder in the
./views folder. 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/bar/html.php, is our singular HTML view . com_foo/views/bars/html.php, is our plural or list HTML view .
If we wanted to specify our own
bars we would do so as follows:
The Difference: 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.
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. We'll talk more about Model States in later sections of the Guide.
You can use underscores in the file name as well. In this context, Nooku treats them exactly the same as a lowercase letter.
An example mapping could look like
site/components/com_foo/model/baz_bars.php -> ComFoo + Model + Baz_bars -> ComFooModelBaz_bars
The Database table naming conventions are also a central piece to making Magic with Nooku. Using them properly frees you from the need to write one line of code related to models or tables if you are doing nothing out of the ordinary.
The table name convention is quite simple:
component name +
plural entity name
#__ is replaced with your already defined
JConfig::$dbprefix, and the
component name is without the
Following our Foo component example:
#__foo_bars #__foo_documents #__foo_cars #__foo_baz_bars
There is a related convention for the primary keys for your tables as well:
component name +
singular entity name +
So that's the component name (again no,
com_), followed by an underscore, and the singular of the table name. Respectively, of Foo component
tables get the following primary keys:
foo_bar_id foo_document_id foo_car_id foo_baz_bar_id
Note: Nooku will automatically translate the primary key into a property of the name ‘id’. So from your code point of view, you can just refer to it as $object->id;
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 rowsets within the view will be the name of the plural view.