TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
What should the Hanami Conventions be?
  • In order to separate things a bit I'm setting up distinct treads for each main area in witch we need to reach some sort of agreement.

    Hanami will be 'Convention over configuration' So this thread is for discussion ideas for conventions.
  • One I would love to see is the especial use of models for data manipulation rather than a load of libraries. For example I have been putting together a form builder similar to forge: but implemented using models.

    Models are better than libraries because for data they make more sense :) I dislike the way some people (esp CI types) consider models "database only".

    Thoughts on that?

  • My understanding of models is the getting and setting of data from a storage (db, file, whatever). Controllers process or prepare them, how they are displayed to the user.
  • Yeh. Though I'd disagree about loading it from a file.. it's easy enough to have abstract (unloaded) data or user input.

    My point was more that there is a huge thinking that there has to be a library: rather than just a model (which usually will do fine!)

  • Which are the advantages of an own "model module", can't we extend the Model class itself (like ORM)?
    Perhaps my OOP or abstract thinking isn't your level yet.
  • My understanding is that Models often need the ability to store and retrieve data but they could also be responsible for further manipulation of that data. example: A Person model could have 'virtual attribute' like 'full_name' that concatenates database columns 'first_name' and 'last_name' and maybe create a middle initial if first_name has spaces in it.

  • Sure, so there's no need for a data manipulation module this way.
  • Which are the advantages of an own "model module", can't we extend the Model class itself (like ORM)?

    Not quite what I was saying....

    I meant when we are coding Hanami a nice convention might be to use models where possible / appropriate...

  • Posted By: Errantconvention might be to use models where possible / appropriate...

  • I suggest that the common and shared module folder should called "hanami".

    As the Kohana Boostrap.php can Hanami have an file/class, which contains version infos ore codenames?
  • Posted By: dyron

    My understanding of models is the getting and setting of data from a storage

    I was taught that in MVC it is the model that is responsible for validating data. So I have it done in my models, not controllers.

    I even extended my model class for that purpose.

  • Indent array items like

    protected static $paths = array
    'all' => array(),
    'img' => array(),
    'css' => array(),
    'js' => array(),
    'php' => array()

    and please

    Kohana CodingStyle


    You must use tabs to indent your code. Using spaces for tabbing is strictly forbidden.

    Vertical spacing (for multi-line) is done with spaces. Tabs are not good for vertical alignment because different people have different tab widths.

  • Damn :( I'll have to remember to fix all my code before commits (tabbing is a REALLY big no-no in larger scale projects so I have NP++ setup to use 4 spaces :P) - bearing in mind I might also be coding with VI so you'll have to forgive a load of spaces here and there (till I can remove them en-masse)

    I'll indent those arrays (it was quick coding) :P

  • Based on my earlier projects i'll integrate my two Template_Controller extensions called Frontend_Controller and Backend_Controller (hardly surprising), while Backend_Controller extends Frontend_Controller.

    What do you think about it? Do you have a cleaner way?

    What's about documentation? Should we store it in the wiki @ googlecode?
  • Yeh I was considering that earlier. I suppose the wiki @ googlecode will do for now :)

  • Yes, lets use the wiki for documentation.

  • What do you feel about dlibs 'head' class should we use that?

  • I'm not familiar with that, where can i have a look? Does the library genereates the <head>?
  • http://code.google.com/p/kohana-mptt/source/browse/trunk/test/Head.php

    You can do stuff like

    echo $d;
  • Thanks dlib.

    Why we put CSS, JS, images in one folder? In my understanding they have equal rights or claims then application or system... Do you think our filesystem bloats?

    • backend
    • frontend
    • images
    • installation
    • modules
    • scripts
    • styles
    • system
    • templates

    Well maybe i haven't got the clue why they put together.

    The Head class looks fine, while i was on an other way handling such things.
  • Using a structure like this makes the root install directory a lot cleaner:


    Personally, I believe media files should always be grouped together.

  • Well, then you can put the frontend and backend together in on hanami folder. But why is JS (client-sided script language) is grouped in media while PHP (server-sided script language) supplies a system folder. In previsionto templates i agree with you to put the CSS and the design dependent image folder together, e.g. templates/[template name]/css/ and templates/[template name]/images/.

    templates/ - preparing backend templates
    templates/ - preparing frontend templates
    installation/ - should be deleted after itself
    hanami/ - Hanami Core - strictly required
    scripts/ - recommend an own JS folder
    style/ - generic layout or fallback if no template is given
    or should this fallback placed in the hanami module view?
    images/ - images of the template fallback if no template is given
    admin.php - can renamed in backend, because the app has the same name

    results a IN_PRODUCTION docroot

  • My controller conventions:

    Frontend_Controller extends Template_Controller {
    // Fills template file, set doctype, language and basic Hanami settings
    // Maybe create an basic Hanami_Controller between them, but not nessecary
    // Used in frontend

    Backend_Controller extends Frontend_Controller {
    // Overrides the template, page_id, login_required and other preferences
    // Used in backend

    Ajax_Controller extends Controller {
    // Handling ajay request, or should they go into the contollers, where it belongs?
    // Can used everywhere

    [Module]_Demo_Controller extends Controller {
    // Demonstrate module functionality (like Auth_Demo_Controller)
    // Used in modules
  • I think ajax requests should be handled by the most appropriate controller. E.g. a user delete ajax request should be placed in the user controller. (Possible even in the same method as the ordinary delete() method and making it non-obtrusive so the site will function as normal even when javascript is turned off.
  • Here it is my variant of directory tree:


    views/ - backend templates

    views/ - frontend templates
    hanami/ - Hanami Core
    resources/ - resources, they can be also placed in hanami module folder...
    js/ - place for js-libraries (specific js-files will be stored in templates or in module folder)
    css/ - place for common css-files (like famous reset.css, that we can use by convension in all templates)
    reset.css default teplate should be placed in hanami module folder


    I like js and css, instead of scripts and styles, its shorter:)
    In frontend/views are stored only template folders.
    Common view files are stored in hanami or specific module folders.

Howdy, Stranger!

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

In this Discussion