First off, what is Knife?
It's a Command Line Interface tool. This means you'll need to get into your terminal where you can see that nice '$ <blinkingcursor>
Besides that, it's a tool created by Jelmer Snoeck to work faster (or less, that depends on how you see things). For those familiar with Fork CMS, if you use it on a daily base for your projects and you need to create your folder structure over and over again, you'll get bored. It's also a big waste of time... If you're making those folders and files, you're not doing anything else, while you should actually be coding.
So to make it short, it's an improvement to your workflow.
In this tutorial, I'll assume you've already checked out how to use Knife (installing etc.) and what it can (not) do. If you haven't, check it out here. Besides that, I won't go into detail for the actions, I'll just show you how to use Knife to make it easier to create those actions. In fact, I won't write any code myself. You can check out the full tutorial for the mini blog here.
Creating the module
Creating the module is really easy. The way I usually do this is start with the backend and build the frontend later on. So, let's think about which actions we need in the backend.
Our mini blog contains a CRUD, so we want a create, read, update and delete action. We'll use the read action for the frontend so we won't create this in the backend. Though, we need a 'get' function for the backend update/delete action. Luckily, this is already taken care of in Knife.
You might have noticed that I didn't specifie the 'index' action. This is because Knife will automatically create this action.
Now, if we look in our backend model, we'll see that we already have some methods aswell. These are the basic CRUD methods.
This is basically all we need for our backend. For bigger modules, we'll manually add some data here, but for small modules that's all you'll need. Note that we also have a `getUrl` method, this is used to create our meta data.
The backend actions
We've created some basic backend actions. Though, they're not fully functional. Because we've used the Fork CLI tool, all these actions contain some basic structure. The example below is from the edit action. There's already a check to see if the specified item exists, if not, it will redirect to the index action of that module, saying the item does not exist. Besides that there are some basic fields already added to the form and there's a basic form validation setup.
These are things that mostly come back in modules I create, so I've put them in there. Now and then I need to remove some data, but it saves me more time to have this as a basic setup and delete some stuff now and then than creating everything from scratch over and over again.
Note that all the backend actions will automatically come in your module installer (and in the database). This way, you won't have any troubles with action rights when you reinstall the module.
The frontend actions
Now, we need to create our frontend actions. This is an index and detail action. We also have some ajax and widgets to build, which is practically the same as creating an action.
As with the backend, the index action is created by default, so we actually only need to create our detail action. To do this, we need to think about the fact if we want it to be a seperate block or not (although this can be done afterwards aswell). I prefer using seperate blocks, this way we can add additional information to the index/detail page without interfering with the other actions layout.
As you can see, our installer has also been updated. This contains the block change. It will automatically insert the data that is needed to create a module extra into the installer so if we install the module on another website, we'll do it correctly and setup our blocks aswell.
As I've said before, creating ajax handlers is almost the same as creating actions.
Note that when you have no ajax actions, there won't be any /ajax/ folder. This isn't initially created.
Creating widgets is also the same as creating actions. When we create a widget though, we'll always update the installer. The module extra is also directly inserted into the database so you can start coupling your widget via blocks.
When you've completed your module, you'll probably want to export it so you can use it for other projects. Since we can also export themes (which isn't covered in this tutorial), we need to specify we want to export a module.
The module will always be exported to your document root, that means the base directory of your Fork, even if you're in another directory.