These forums are read-only and for archival purposes only!
Please join our new forums at
General usage and file placement
  • Sorry this might be a bit vague, I'm new to MVC in general and Kohana.

    So I'm setting up my first app using Kohana 3.3, I have basic routing working, have my main pages with corresponding controllers and have a template working with views loading correctly for the main page.

    One problem I have, and I don't know the best way to deal with it, is that some sections of my web pages are the same on each page, but are generated from the database. So for example I have a header with logo and static links, all in the template for now. I then have the main section of the page in the middle, which is generated dynamically by the controllers as dictated by the routing, but I also have two sidebars - one to the left and one to the right of the main page content. These sidebars are what needs to be the same for each page, but one is generated from the database (a list o product categories) and the other has shopping cart and user account information. So I don't want to add the code to generate these into the main controllers, as I would have to repeat that for each controller/page. So what is the best way to implement this?

    I have figured out how to have each controller extend a main controller, and the main controller has a before() method which is working, but it feels wrong to put all the logic for the sidebars in there (currently is in APPATH/classes/controller/Base.php and all my other page controllers extend this controller, which itself extends Controller_Template).

    So really my question is should I be doing something like calling another class from my base controller eg APPATH/classes/sidebarclass.php and put all my code for that there, or should it be somewhere else (in the Models? or what) ? ?

    I'm trying to refine my coding in general, not repeating myself and follow best practices but struggling to do so here as MVC in general and Kohana specifically are both new to me.

    Any advice on this would be much appreciated.

  • I think we're about the same level in using PHP, and I think you have touched the solution yourself: extend your controllers, put all 'general stuff' in the parent controller and call the child controllers.
    If the app only has 1 layout, you could make a Controller_Main and let all other pages extend this one.
    If the app has different layouts, make more than 1 parent controller (composition), or better yet: extend Controller_Main with f.e. Controller_Main_twoCols and Controller_Main_threeCols and extend these into Controller_About, Controller_Home etc. (inheritance)

    This seems as a perfect case in which inheritance should be used instead of composition.

  • thanks for your thoughts, I appreciate it. (I'd also like to hear thoughts and opinions from others too).

    Another thing. So in my base controller there are a few vars to setup for each page: page title, the content for the two sidebars etc. How can I call an already existing controller from within my base class eg the controller to return the list of product categories (which I already have as a dedicated controller and route in the normal way)?

    I tried $catlist = new Controller_Categories but that threw an error Catchable fatal error: Argument 1 passed to Kohana_Controller::__construct() must be an instance of Request, none given…

    I'm sure I'm missing something obvious here…

  • @arumdev public function __construct(Request $request, Response $response)

  • thank you WS.

  • so what I'm still not getting, is where I'm meant to be putting my 'business logic'. for example I want a page that draws new products in each category from the database since a certain date. As far as I understand this should be part of my categories page (as that's where it's shown, as an option, along with each specific category as isolated options), but where and how should I put the logic for that? by my understanding of MVC model, it should go in the model class, but how exactly? it's easy enough putting this in the controller files, but then they're ending up messy and bloated.

  • Classic example:
    1. C send request data in M
    2. M work with data and return result in C
    3. C send M result in V


    don't pay attention to the details, look at the general

  • Controller:

     $m = new Model_Products;
     $result = $m->get_categories() ;
    // Make $result available to the view.


    public function get_categories()
     // Query the database and return the result.

    N.B. 1. Very simplified.
    N.B. 2. Improve the naming conventions.

  • @arumdev, now I think I'm a little ahead of you. I just spent my whole holiday on the beach reading through PHP objects, design patterns etc. This book from the hand of Matt Zandstra is very good, but be prepared for a very long and difficult read...

    The way you model your business logic is very specific to the needs of your project and even a question of personal preference. I'm still dabbering with structuring my code into a rewrite (yesterday I upgraded one of my servers to Debian WHeezy and along came with PHP 5.4 and my app apparently my app does not work anymore... the rewrite that has been planned for more than two years is becoming quite urgent), but in any case I think it would be best to write down the structure of your app in an UML scheme and keep all your classes as concise as possible. Whenever a class has grown too big, it's time to split up the responsibilities (but everyone has their own opinion of when it has grown too big).

    For example: if you want to do something with files, you can have a Model_File(), a Model_File_List(), a Model_File_Category, etc. instead of 1 big class Model_File(). That way you can make the Model_File_List()-class implement the iterator-pattern.

    The most difficult thing is to know how you should instantiate every class (or more general: how to define the relations between your models: inheritance or composition and in the latter case: f.e. factory, delegation, observer etc.). I'm hoping to find some answers on that topic from reading through example applications (for example the one that has been posted to this forum very recently).

  • Business logic doesn't go in models. In fact, business logic doesn't even belong in the framework at all. You should be defining your domain, not the framework. Business logic also doesn't have anything to do with "pages" or "html" or anything like that. Abstract your BL away from all this and your application will become easier to maintain and have less bugs.

  • ok thanks. so if the BL is to be separated from the main MVC structure, how would I actually do that. just include from the base controller?

    and if that is nothing to do with the pages and the HTML, then where do I put code that for example determines what to show on the page based on certain criteria (as in my example above), does that all just go in the controller then?

    sorry if my questions seem a bit haphazard and basic - it's partly because I'm away at the moment and only working on this sporadically, and also partly because as I said I'm trying to get my head around a lot of new concepts etc.

    thanks again for everything so far.

  • @zombor, now I'm really confused - do you have any (online) resource that I could read through? Just when I thought I was getting the big picture... Should the model then be nothing more than a gateway/API to your business logic?

  • @zenlord sure, you can read through my blog, there's a good video by Uncle Bob there:

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion