Confused about HMVC and CMS seperation/integration

[eluser]gh0st[/eluser]
I am looking at using HMVC for Modular seperation for our new CMS.

We want to have "modules" but each "project" (or web build) requires a CMS.

However I am very confused about where the CMS is meant to live, and how it interacts with
modules; and worse how to manage projects/code adequantly.

It's all very frustrating and confusing. I have posted a picture on imageshack to clarify my thinking process.



Image Shack:
http://img94.imageshack.us/img94/9525/confusion.png


Let's assume for example:

Lets assume a project has 3 modules.

Modules/
1. Blog
2. News
3. Gallery

Here are the problems.

1. Where does the CMS live?

Each of these modules requires a CMS - so does this mean:

a. Every module has its own CMS?

ie:
/modules/blog/
/modules/blogcms/??

i. Why am I repeating the same module/functionality twice?

b. The CMS itself is a module?

ie.
/modules/cms/

i. But if this is true, then where is the seperation that modules promises?
ii. Where does blog module live?

ie:
/modules/cms/blog


2. Let's assume you have more than 1 module that does the same job.

ie:
Blog, which is copy/pasted to create:
News

And it has features you want to replicate.

ie:
Print list of records.

Problem:

I would be repeating the same code twice.
I would have a problem of ensuring all code is up-to-date.

---

I'm really confused about how the CMS and Modular systems are meant to work.

If I do a /module/cms/ it is restrictive
If I do a /controllers/cms/ I have to repurpose code for specific modules
If I do /module/blog/ and /module/news/ which are "clones" of each other, I am repeating the same code.

What I'd like to know is:

1. What is the correct way to create modules, each having a CMS?
2. How do I make it so that I don't have to repeat myself/code over and over?
3. Would this all be better delivered as a library?

My colleague says the best way to do this is:

1. Have common things and then extend them to do what you want, but this really isn't modular seperation; its just OOP.

What's the best way to solve this issue?

[eluser]gh0st[/eluser]
I was hoping that they'd be a solution for this.

All I'm after is:

If I'm using module seperation -- where does the CMS live?

a. It lives inside each of the modules
i. This means there are 2 files (blog for frontend and blog_admin for backend? Is that right?)

b. It lives outside of the module
i. If I put it outside then won't I be repeating myself in 2 areas?

c. It doesn't live anywhere and you just extend the CMS controller/method?

There must be a right way to solve this.

[eluser]Phil Sturgeon[/eluser]
What on earth are you talking about?

A CMS is just a Content Management System. That means its a general term for an application that manages content. You can create forms, capture data and output stuff to the user.

You can create a blog module and your CMS will manage blogs. You can create a page module and your CMS will manage pages.

A CMS is not a module or a controller... I think you might be a little confused lol.

[eluser]gh0st[/eluser]
Yeah I think I might be!

I understand that CMS is just a generic term for managing content.

You can create a blog module and your CMS will manage blogs. You can create a page module and your CMS will manage pages.

Am I right in thinking what you're saying is that every module, blogs, pages, etc would have their own CMS built into the modules themselves?

Perhaps if I break it down:

The Goal:

We want to use re-usable modules in our projects.
The projects will have a CMS, this will an an Auth layer. It will allow the user to manage content.

The set-up:

We create a Blog module that allows users to CRUD content. Let's call this the BlogCMS.
We create another Blog module - this is used for front-end purposes and has no auth layer.

Let's now repeat this process for 2 other modules. It doesn't matter what they are called.

The problem(s):

1. Each module now it's own CMS with its own Module.
2. If one or more modules share the same code you would end up repeating yourself
3. The CMS itself becomes a module??

---

I believe what you're referring to is an approach it like Wordpress treats it's plugins; the plugins are self-contained, including all CRUD functionality?

Is that right?

[eluser]gh0st[/eluser]
Okay, I think I have a resolution.

I downloaded:

1) CI-CMS
2) SyntaxCMS
3) PyroCMS

All 3 promise a modular approach, although I have not gone through all the code or analysed it thoroughly; it appears that the modules are self-contained, and the CMS' are also part of the module itself.

This appears to be the best way forward?

Thanks.

[eluser]danijelb[/eluser]
I think that gh0st wants to know how to make a modular CMS.

Like first he makes a base, then add blog module, then add contact module, like plugins

Is that what you want, gh0st?

[eluser]rogierb[/eluser]
Hi gh0st, you are over complicating this in your mind. You see the 'CMS' as a seperate entity from the 'front'.
It is not. CMS stands for 'Content Management System'. It is just a means to an end, letting someone CRUD some content. This content can be a blog or a gallery.

If you want a modular approach, stick al of your 'CMS' (CUD) and the 'front'® part in a single module.
The fact that they are modules imply they are selfcontained.

[eluser]gh0st[/eluser]

I think that gh0st wants to know how to make a modular CMS.

Yes, that is right.

you are over complicating this in your mind.

I agree.

The fact that they are modules imply they are self contained.

I think the penny has dropped now.

Make the modules self-contained with all their contained functionality.

Thanks.

[eluser]Fabdrol[/eluser]
gh0st,

I've got some tips for you regarding *not* repeating code..
(Although you will be repeating some code, it's a bit of a downside of CI, it has a few constraints which stand in the way of full, 100% abstraction)

First, make a plan for each module, like this:

Code:

Module: blog
    this module has to:
      - list blog posts
      - be able to delete posts
      - be able to edit posts
      - be able to create posts
      - etc

Module: news
    this module has to:
      - list news entries
      - be able to delete entries
      - be able to edit entries
      - be able to create entries
      - be able to deactivate entries
      - etc

Now, create some models to ease things up a bit, like a DB manipulation model, might sound like over-abstraction, but I have found it really easy, since my database tables always contain a few standard fields like created_at, last_update and more. When I edit fields like that, I only have to edit the Sql model for it to work across my app.

Code:

class Sql extends Model {
    
     private $_blogtable = '';
     private $_newstable = '';

     public function __construct() {
          $this->_blogtable = $this->config->item('blogtable');
          $this->_newstable = $this->config->item('newstable');
     }

     public function insert($module, $data) {
          if(!is_array($data)) return false;
          
          $insert = $data;
          $insert['standard_field_1'] = 'value';
          // etc
          
          switch($module) {
               case 'blog':
                    $ins = $this->db->insert($this->_blogtable, $insert);
               break;

               case 'news':
                    $ins = $this->db->insert($this->_newstable, $insert);
               break;
          }
     }

     // and so on for the other CRUD methods.
     // for where and order statements: pass an array to the method
}

The next thing you might want to do is automate certain views. For instance, lot's of modules use a 'list' view. It makes things a lot easier if you'd had some methods to load that view automatically. I do not reccomend this for forms though, they are too custom, especcially if you use a lot of javascript magic.
Useually I use a library for this, I autoload it and then I can call it very easily... something like this:

Code:

$initialize = array(
    'buttons' => array('new', 'edit', 'delete', 'deactivate', 'activate'),
    'custom_js' => 'js/module/scripts.js',
    'notification' => '',
    // and any other config stuff your template needs to know
);

// $list_array contains the actual list data.
$this->template->render('list', $list_array, $initialize);

And in general, try to automate everything you use in all modules. (for instance, and very important, notifications to the user!)

I hope this helps you a bit! It's how I do things, and I think it works like a charm :-)

[eluser]gh0st[/eluser]
@Fabdrol -- Thank you for posting your hints and tips, I was finding it difficult trying to wade through all the forum trying to find something that would help reduce the DRY element whilst giving us at least a very basic skeleton to work on.

With regards to the admin side, I feel extending MY_Controller, as explained in this email seems to indicate a route which I am testing/following.

http://davidwinter.me.uk/articles/2009/0...deigniter/

Thanks to all who helped.