Controllers as Module? (not HMVC)

[eluser]MpaK69[/eluser]
Hello!

(sorry for my english, Iam from Russia)

I have some problem with HMVC and modules (I use 4.0, because cant use 4.1 at my project)
HMVC have some big problem with namespace, someday he cant saw some models or views, it is ugly (sorry)

And now I think, why not use Controllers as Module, and have one question did some write this thing to write code to call some controllers (modules) from ONE (core extends controller) controller like this:

Code:

$data['content'] = call_controller( 'news', 'index', $params );

$this->load->view( $layout, $data );

that will be greate function call_controller which will be load my controller News and call method of object index and return results of work to me.

???

[eluser]xwero[/eluser]
Check out the Wick library. It does what you demostrated.

[eluser]Colin Williams[/eluser]
Here's the problem with this: The "public" methods of a controller (in CI) serve the purpose of serving the result of the client request. They don't serve the purpose of returning objects to other controllers. So, I'm not sure how you could expect a controller method to return data when called in one context, then serve content in a different context. It's messy.

Of course, you don't want to duplicate your code too much, but twice or even three times is not so evil. If it's a very common result you need, I would turn your attention to creating a Model/View combo (call to a model, pass result to a view) or Library that abstracts as much of the process as possible, perhaps even a Hook or Helper will suffice too.

[eluser]wiredesignz[/eluser]
@MpaK69, There is no problem with Modular Extensions if you design your code correctly, just as CI itself has some limitations, you must code accordingly. Maybe learning the MVC design pattern would help you.

@xwero, Wick has more severe limitations when attempting to load models/libraries, so I wouldn't recommend that.

@Colin, Controllers are libraries and can be used for any purpose, wether serving a request or returning data.

[eluser]Colin Williams[/eluser]
[quote author="wiredesignz" date="1215087376"]@Colin, Controllers are libraries and can be used for any purpose, wether serving a request or returning data.[/quote]

Call me old fashioned, but "Controllers are the heart of your application, as they determine how HTTP requests should be handled". But, looking into what Modular Extensions does, I guess it can be stretched to say that HMVC controllers are still handling HTTP requests, just via proxy of another controller.

I think when people start thinking about "calling other controllers," what they're really getting into is creating an aspect-oriented application, and they should approach it as such. A true module should be able to exist on its own with only the core functionality needing to know whether it's "turned on" or not for the given context. I would encourage developers to try to create event-based systems that invoke hooks in as many places as needed so modules can easily extend functionality in these contexts in a very discreet way.

I've yet to do this with Controllers but typically do it for my core Models, so that other "modules," when enabled, can extend the data object before it is returned to the Controller, and ultimately the View, where "theming" happens.

Here's an abridged and annotated example from a current project I'm working on:

Code:

class Blog_model extends Model {
  
   function get($pid)
   {
      // This code just determines the request and performs a simple retrieval  
      $post = FALSE;
      if (is_numeric($pid))
      {
         $this->db->where('bid', $this->blog_id);
         $this->db->where('pid', $pid);
         $this->db->where('status >', 0);
         $query = $this->db->get($this->table['posts']);
         if ($query->num_rows() == 1)
         {
            $post = $query->row();
         }
      }

      /* If retrieval is a success, we invoke the 'build' hook.
         Any modules that implement the 'build' hook will receive
         the $post object as an argument passed by reference, so
         it can alter the $post object before it is sent to a view */
      if ($post)
      {
         $this->fuego->invoke('build', $post);
         // $this->fuego is the library that manages modules and invokes the hook points
      }
      return $post;
   }
}

So then, this is an example of a module implementing the 'build' hook:

Code:

class Comments_plugin {
  
   function Comments_plugin()
   {
      // Comments Plugin Constructor
   }
  
   // All we must do to implement a 'hook' is name our method respectively:

   function build(&$post)
   {
      /* So, here we would want to use $post->id to query the comments
         table, then append an array of the comments to $post->comments,
         which we could then loop through in our view to display these
         comments. */
      $post->title .= ' - With Comments!';
   }
  
}

So, by the time any View gets passed the $post object, $post->title would have " - With Comments!" appended to the end of whatever title was stored in the database. Again, this shows the concept used for extending models, but it could easily be used to extend controller methods, too.