How to arrange business logic in a Kohana 3 project

Question

I'm looking for advice, tutorials and links at how to set up a mid-sized web application with Kohana 3. I have implemented MVC patterns in the past but never worked against a "formalized" MVC framework so I'm still getting my head around the terminology - toying around with basic examples, building views and templates, and so on.

I'm progressing fairly well but I want to set up a real-world web project (one of my own that I've been planning for quite some time now) as a learning object.

I learn best by example, but example-based documentation is a bit sparse for Kohana 3 right now - they say so themselves on the site. While I'm not worried about learning the framework as I go along, I want to make sure the code base is healthily structured from the start - i.e. controllers are split nicely, named well and according to standards, and most importantly the business logic is separated into appropriately sized models.

My application could, in its core, be described as a business directory with a range of search and listing functions, and a login area for each entry owner. The actual administrative database backend is already taken care of.

Supposing I have all the API worked out and in place already - list all businesses, edit business, list businesses by street name, create offer logged in as business, and so on, and I'm just looking for how to fit the functionality into a MVC pattern and into a Kohana application structure that can be easily extended.

• Do you know real-life examples of "database-heavy" applications like directories, online communities... with a log-in area built on Kohana 3, preferably Open Source so I could take a peek how they do it?

• Are there conventions or best practices on how to structure an extendable login area for end users in a Kohana project that is not only able to handle a business directory page, but further products on separate pages as well?

• Do you know any good resources on building complex applications with Kohana?

• Have you built something similar and could give me recommendations on a project structure?

Bounty

I'm awarding the bounty to @antpaw because he provided me with a Kohana application with some business logic that is giving me a lot of examples. Cheers @Pixel Developer for your excellent input as well - as so often, I'd wish one could split a bounty!

Answer 1

i would use the auth module that comes with kohana for the login. This will give you the roles table where you can setup the possible permission options and relating them to the users later. After that you can check inside the __constructor() or action_function() of each controller whether the user has the required role e.g. with the ->has() function. You also should use the ORM module, its just awesome, since you have many relations between the tables. Also the __get() method inside an ORM object can be extremely handy.

Its also pretty easy to extend a controller function by setting the new parameter to NULL and checking for that in a if statement. e.g. you need only one function for editing a old entry or adding a new one.

public funciton action_manage($id = NULL)
{
    $entry = ORM::factory('entry', $id); // if id is null a new entry will be returned 
}

It's also important that you structure the views into sub folders to avoid a messy view directory.

Answer 2

Lots of questions to answer here, I'll try my best.

Do you know real-life examples of "database-heavy" applications like directories, online communities... with a log-in area built on Kohana 3 where I could take a peek how they do it?

There's a few example applications out there. Woody Gilk (Kohana founder) has published the code to his personal website on github. For the login area he assigns a cookie value. Kohana 3 / 2.4 sign the cookies which makes it safe and removes the requirement for sessions. This might not be up to everyone's tastes so you can always use built in authentication library that uses both sessions and cookies.

Here are some other projects you might be interested in:

• Shindig - Light weight blog module for kohana 3
• Kohanut - An extensible CMS written in Kohana 3

Are there conventions or best practices on how to structure an extendable login area for end users in a Kohana project that is not only able to handle a business directory page, but further products on separate pages as well?

If I understand you correctly you want to generate a login box for each of those pages? This is easy with Kohana 3 as we can take advantage of the H in HMVC. Sam de Fressyinet wrote an article detailing what this all about on the iBuilding Tech Blog. Scaling Web Applications with HMVC.

What you can then do is perform an internal request to the login controller or action and dump the response into your view page.

$login = Request::factory('login')->execute()->response;

$login now contains the login form, which you can put anywhere you like. You may want to return a different response if the request is internal which is why this piece of code can be useful:

if (Request::instance() !== $this->request)
{
    print 'Internal called made with Request::factory';
}

Do you know any good resources on building complex applications with Kohana?

There's not going to be documentation showing you how to build complicated applications. The view of the Kohana community is that you're a PHP developer and should be able to solve these problems for yourself. If you can't, well you shouldn't be using Kohana then.

Have you built something similar and could give me recommendations on a project structure?

Once you understand how Kohana 3 finds files things are easy to understand.

|- classes
|-- controller
|-- model
|- views

For example:

Controller_Mathew extends Controller 

Will look for a file called mathew.php in:

classes/controller

Underscores can be used to specify deeper directories. Example:

Controller_Mathew_Davies extends Controller

will look for a file called davies.php in:

classes/controller/mathew/

As you can see, the underscores in the controller name act as directory separators. This rings true for models and vanilla classes.