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
Hanami modules structure / layout
  • So, I mentioned this in another thread: about different types of modules. There seems to be some kind of "disagreement" (more a varied discussion) on the level of examples to be included. This is what I hope is a sensible, laid back solution to the problem.

    We could divide Hanami into 2 strands: "structure" and "implementation" modules. The structure modules provide functionality of some kind (say auth, data etc.) but NO examples and no working controllers/views etc. Then we build a couple of implementation modules which use the structure modules to make working examples.

    The reasoning for this is that we can keep the "structure" strand as abstract as possible (so no blog library :P): just pure data manipulation and no styling. Then the implementations can 1) show best practices & examples for use and b) be used as plug-and-play modules for a site.

    So my suggestions (for example) might be: Structure modules: - auth / acl - data (as I mentioned before and abstract data module for saving info,pages etc.) - dbsettings (cfg settings in a database) - theme module (to switch between themes and so on)

    The the implementations - Hanami (a simple CMS system with a "plugin" interface to plug the other implementations into) - Hanami Admin (as above but for the admin side of things) - Blog - Wiki

    And so on...

    Thoughts?

  • If I understand you correctly, you have only data processing modules. The implementations goes in the front-/backend app.

    • backend
      • Blog - requires acl and "data manipulation"
      • Comments - requires acl and "data manipulation"
      • Wiki - requires acl and "data manipulation"

    • frontend
      • Blog - requires "data select"
      • Comments - requires "data manipulation" with spamcheck (while this can be a library in a common shared module or in "data saving"
      • Wiki - requires acl and "data manipulation"

    • modules
      • auth
      • acl - requires auth
      • data definition and manipulation

    • ...


    Am I right?
  • I think I understand the 'starting out abstract' part . The benefits being in my understanding that by creating really nice classes for saving and retrieving data that might include 'un-deleting' or rollback kind-of-functionality we can later allow ALL content Models to have this advanced abillity....

    is that correctly understood?

  • yeh something like that.

    The way I have done (somethign similar) before is to have a couple of database tables:

    Content (stores raw data with relevant info) Id is unique (like a revisions id on WP) whilst tagid refers to a specific piece of content (so you can have multiple revisions of the content).

    Table: content id | tagid | content | author | date etc...

    then you have some pivot tables.... say for forumn posts, blog posts, page revisions whatever..

    Table: blog_posts id | tagid | etc...

    So then our blog, forum, wiki (or whatever) libs pass the content module a tagid and it knows what to look for (eg; you could have get_latest, get_revision(id), list_revisions(),rollback(id) etc.....)

    Or something like that :)

    As you say using something like that means we have a quickly extensible data model to make use of all over (both in our examples and when developing with Hanami)

  • Errant your a goldmine! and I so value your contributions..

  • It would not be difficult to implement an 'acts as versioned' behaviour into ORM or another standardized model. I was going to link to the Ruby wiki but it's down (typical ;) ). Anyway, this explains it sort of. This would be a generic solution to provide get_latest(), revert(x) etc. and thus can be useful to more than one project. I have done such behaviours before in ORM such as trees and nested sets. Acts as versioned, or do undelete stuff would not be difficult to implement.

    Multiple behaviours per model should be possible.

    Ps. the ruby page in Google cache
  • Yeh that's exactly the sort of thing :D

    (We can probably get a lot of inspiration from the rails stuff - looking @ it).

  • I'll start with my intention of the start app/module at the branch.
  • @dlib Fantastic!

  • @ Dyron it's great that you start! I however have no idea if it's a good idea to start with an installer. It's not that I think it's a bad Idea... I really have no idea.. :) Can anybody tell me ? If guess if it's in a branch then it can always be merged in to the trunk afterwards right, so that makes it fine right , so go for it !.

    And I don't know if it's a good Idea to start coding before we have more of a master plan that we have agreed on. I would think that we need to plan it out a bit more before we spring into coding action...Can someone help me on that one to? Or am I the only one that does not have a crystal clear vision of how Hanami is structured ???

    However that last thing I want to do is prevent someone from doing good work on the project..I really like your 'wanting to get started' Dyron!!! :-) :-)

    would apreciate any help with this.

  • Yeh I'm a bit confused....

    Dyron are you starting a whole new app.. a module.. or what? It's a little confusing :P

  • A branch is a new line of the whole app. I'll built the hanami installation inside the app, we can discuss about it and when we get to a result i can commit the changes to the trunk.

    May have a look at the branches of Kohana.

    Actual the installation is planned as own app but modules are apps to, so if we want as module, i change it.
    As i said, it's my way how it's realised. If it's to complicated or you have another view, please tell me.
  • I just wasn't sure based on the naming what it was about :D - so this an installation library? Or the Hanami app? (I'm still a bit confused sorry).

    If it's the main Hanami app then it might be best to keep that as the Head revision (The way I have seen them used branches are only really for major work that will break concurrency). An Install lib sounds exciting though (if that's what your going for).

    What are you thoughts on it's syntax and API (for others building modules that might rely, integrate or use it)

  • the install app is NO hanami app itself. it's inside app or will be a module...
  • All right cool.

    Let us know of any naming conventions or files your creating so we dont clash :)

  • A quick update: I got some free time today.. so I am going to read up dlibs links and make a start on Versioned_Model - which will be a form of the acts_as_versioned model that RoR's uses. :) That's if no-one else wanted the task?

  • well, beside the install build i have made some "restrictions":

    My folder structure:

    • backend
    • frontend
    • modules
      • hanami
    • system


    or would you prefer hanami at the app level, included via

    $config['modules'] = array(
    DOCROOT.'hanami', // Hanami Core - should always stay last item!
    );
  • Cool, I'd say keep things in the module directoy. Too many top level file paths could be confusing :)

  • Umm can you make any core changes to the trunk rather than just to your branch. When we come to merge this in it's easier if you haven't broken concurrency with files that others might well change in the core.

    Regarding this install app: in intrigued still as to what it is :P (it does sound interesting).

    So is this an installer ot be run whenever you make a Hanami based site (ite to set up some core db stuff etc.) or is it designed to be an interface via which you can install Hanami modules? Whilst I think thats an ace idea I think that the former should be a simple library and the latter should be part of the admin controller. Adding a separate app just for some sort of install could well be overkill as well as a major security risk (because chances are it means that the install cfg's for all the modules are littered across the Hanami folders - as well as it makes removing the installation scripts tougher than just deleting one folder... [for a start it would mean editign the .htaccess file])

    Thoughts? Anyone else got comments on this?

  • Posted By: Errant

    Regarding this install app: in intrigued still as to what it is :P (it does sound interesting).



    It's was an app a while, but now it's gone inside the hanami core.... This is the core installer, no module installer (may can extend to it).

    My plan is, if you setup once correctly, you'll never get access to the install again. maybe only removing the install.php and routes to 'install' gone to nowhere...


    Sure, i can work directly at the trunk, but at the moment, their were to many undone things. A merge isn't that much i think.. Maybe the core devs can give us some experience about it.
  • cool snds ace :)

    I didnt mean work it all inside the core.. but you made some directories and files that are generic and other people will work with :) it seemed better to put them into the trunk :D (I put some of them in when I added my start to the versioned model).

  • Actually I just had an idea about this!

    You could kill 2 birds with one stone and jsut check the IN_PRODUCTION constant in the install library. If it is false it allwos you to run an install - if not it quits out.

    Then when doing the install it could edit the common.php settings file (see here for discussion about that file: http://forum.kohanaphp.com/comments.php?DiscussionID=664&page=1#Item_1) and set IN_PRODUCTION to true..

    or something like that :) thoughts?

  • Idea of install and IN_PRODUCTION sounds very good. Maybe we can merge all "accessing" file, while the common.php is unnecessary. Comment in that specific thread.
  • Well, after some time thinking over the module-plugin-thing my opinons about that:

    Modules should only serve the functionality and a Demo_Controller, while plugin serves all stuff they need to work.
    For example an user management:

    Module:


    backend/
    frontend/
    modules/
    user_manager/
    controllers/
    user_demo_controller.php
    libraries/
    user_management.php
    user.php
    user_roles.php
    models/
    user.php
    user_roles.php
    user_details.php
    views/
    user.php
    system/


    A plugin has to check it's dependencies, needed other modules, libraries, DB-tables, something else...

    Besides the module itself, a plugin has to provide frontend and backend controllers! So it's a real plugin.


    backend/
    controllers/
    user_edit_controller.php // Includes it's app level views
    views/
    users/
    index.php
    table.php // Overview of users
    details.php // Used for editing user details
    delete.php
    frontend/
    controllers/
    user_list_controller.php // Includes it's app level views
    views/
    users/
    index.php
    list.php // Overview of users
    details.php // Used for displaying user details
    modules/
    user_manager/
    controllers/
    user_demo_controller.php // Only demonstrate the functionality
    libraries/
    user_management.php
    user.php
    user_roles.php
    models/
    user.php
    user_roles.php
    user_details.php
    views/
    user.php
    system/
  • This is a though one.. I'm thinking about it.

  • I'm not sure if modules should be more application or more system style like. This means which one would you prefer?

    Hanami blog module (controller example):

    class Controller_Blog extends Controller_Frontend {}


    or


    class Controller_Blog extends Controller_Template {}


    First one based on the Hanami frontend controller, which is a problem to port Hanami modules to other Kohana apps. The other needs to declare extend Controller_Frontend in the app. rather a Hanami module creator have to create the module + app specific controller/views.

    Is there a way to implement this in a Kohana app?


    class Controller_Blog extends Controller_Frontend [implements Controller_Blog (from the module)] {
    // behavior like the module Controller, but based on the frontend controller not the template or core controller
    }
  • More thoughts about this topic:

    If someone want to create a module for Hanami, he has to create 2 modules (one for frontend, the second for backend) or he has to nest the controller like controllers/ and controllers/admin/, but i decided to split the Hanami front- and backend, because i wanted to avoid this. So now you have to create 2 modules, which is too much work. Besides the modules are a logical item, so why splitting? May i havn't enough understanding of OOP, so a question at the pros:

    Should all functionality goes into a lib?

    Module:
    <?php<br />
    class Blog {
    function list(){
    return Model::factory('blog_post')->find_all();
    }
    }

    class Blog_Demo_Controller extends Controller {
    function index() {
    echo Blog::factory()->list();
    }

    ?>

    Frontend app:
    <?php<br />
    class Blog_Controller extends Frontend_Controller {
    function index() {
    echo Blog::factory()->list();
    }

    ?>


    Backend app:
    <?php<br />
    class Blog_Controller extends Backend_Controller {
    function index() {
    echo Blog::factory()->admin()->list();
    }

    ?>

    So the module provides only functionality, and the controller belongs to ther specific app.

    Otherwise i like a 'thin app - thick module' thinking, or is this a bit too tinking a module is like a plugin?

Howdy, Stranger!

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

In this Discussion