Today I tackle Chapter 4 of "Reliable Extensions", which involves building a(nother) basic extension with Extension Builder. To review, building an extension involves the following steps:
1. Create a directory structure and the basic configuration files.
2. Model the problem domain.
3. Configure the persistence layer:
a) define the database tables.
b) configure the backend forms.
c) set up the repositories.
4. Define the inner processes of the extension (design the controllers and their action methods).
5. Design and implement HTML templates to present data.
6. Create plugins ("plugins" in Typo3 always refer to the frontend) for listing data.
7. Install and test extension.
Wait a minute... why does testing the extension come last in the steps? If I want to use test-driven-development in creating an extension, what's the best approach? Do I test everything, or only the controllers and their action methods? I'm guessing that testing these, at least, would be a good start, but should I generate test-cases after the code for the extension is generated by Extension Builder, or beforehand?
Extension Builder (from now on referred to as "EB" to spare me some typing) takes care of all the above-listed steps except for 7: basic configuration (step 1), plugin - frontend - configuration (step 6), and domain-modelling (step 2) are done through EB's graphical interface. On saving, EB generates the directory structure (step 1) with the following folders: Classes/Controller, Classes/Domain/Model, Classes/Domain/Repository, Configuration/TCA, Resources/Private/Templates/Product, Tests/Unit, and some others.
Under "Configuration/TCA/", the PHP class, "Product", is configured to allow us to determine how the forms in the backend should be shown (step 3b). Additionally, in "Classes/Domain/Repository/ProductRepository.php", EB has generated a class for us that will allow us to access the data of our persisted models (step 3c).
In "Classes/Controller/ProductController.php", EB has generated a controller and its action methods for us (step 4) as we have determined them in the "default actions" section of the EB graphical interface. Here, the action methods access our model data through a repository, and then assign this data to a view for presentation. A basic first template for the view for the "list" action has been created for us (step 5 - thanks, EB) under "Resources/Private/Templates/Product/list.html".
Basic configuration files are saved in the main directory named after our extension key - in this case, "inventory" - and are all preceded with the prefix "ext_". For instance, the file "inventory/ext_tables.sql" provides the SQL commands necessary to set up the database tables accomodating our domain model (step 3a), "inventory/ext_localconf.php" defines for our frontend plugin which controller-actions are allowed, and "inventory/ext_tables.php" registers the plugin for the frontend.
The entire generated directory structure is stored in the main directory for our local extension: "inventory". This, in turn, is stored where all local extensions are stored, in typo3conf/ext. In contrast, global extensions, which are globally available to every page, are stored in typo3/ext, and system extensions, which are valid for the entire TYPO3 installation, are saved in typo3/sysext.
Finally, we reach a point where we actually have to do something ourselves: install the extension. Under "Extension Manager" / "Manage Extensions", you'll find the "Inventory" extension - click on the icon to activate. Logout, and login again - if you're lucky, nothing's broken.
Set up a system folder in your page tree. I'm calling mine "Inventory" (duh). Once it's created, add a new record to this folder of the type "Product" - in the list of plugins, you should see this under the plugin "Inventory". You can repeat this last step to insert as many products as you like into our new inventory database.
Now you can set up pages that use the plugin. Just add a page of type standard in the page tree, go into the list view on this new page, and add a new content record of type "Insert Plugin". Choose "Product List" as the "type" under the tab "Plugin". Also set the "Record Storage Page" (under the tab "Behavior") to the system folder "Inventory", and you should see our list of inventory records in the frontend.
Unless you're using TemplaVoila: then you'll just see the ID of the page's content-record. I'll have to figure this out tomorrow.
Today I've accomplished my goal of working through chapter 4 of "Reliable Extensions". I also read a chapter from "Advanced PHP" on saving session variables to the database instead of the file-system, during my lunch "break". Tonight I'll see if I have the energy and the desire to finish Code School's "Git Real" course after dinner. Or if I decide to just crash on the couch and engage in staring contests with my cats. What I do know is that I am the most unhip programmer in Berlin for admitting that last bit.