Welcome Guest, Not a member yet? Register   Sign In
HMVC the right way ?!
#11

Thanks guys for your input.

Because of the problems controllers calling controllers 'may' cause, I'm going to get rid of all the
PHP Code:
echo modules::run("module/controller"); 
stuff!

I have a good idea how to get the solution which will give me the same output, without doing things to CI which is frowned upon.  Tongue
And I will definitely try out the Bays addon... thanks kilishan! 

-Roger
Reply
#12

(05-27-2015, 12:18 PM)frocco Wrote: I am not understanding this. If you have an Auth Module, most likely every module in your app might require it.
Are you talking controller to controller calls or a view calling different controllers?

Authentication/authorization are often core functionality for any application which uses them. In that case, I would probably lean towards making a library (or libraries) which provides an interface (and probably a basic implementation) for this functionality. The library could be structured similar to the database library or session library, allowing "drivers" to define the underlying implementation, and some careful planning could allow those "drivers" to be loaded from modules, based on configuration. Supplying a basic implementation with the library also permits failover to that basic implementation when the module is not available (though proper configuration should make that an uncommon occurrence).

In the end, though, that level of effort is only really going to be appropriate for certain situations (or when you're building a base which you plan to reuse indefinitely on multiple projects). In a simplified system, your use of that particular feature can be easily tied to a base controller, which could act as the intermediary provided by the library in my more complicated example.
Reply
#13

(05-27-2015, 10:29 PM)kilishan Wrote: In WireDesignz' HMVC solution, you can call Modules::run() to call a controller from another module and get some content back. This is a bad thing in CodeIgniter's case, because it wasn't designed to work that way and can cause problems with multiple instance of the CI singleton in play, confusing things horribly.

Sorry to post two replies instead of covering this in my last post...

In WireDesignz HMVC specifically, this isn't really much of a problem, as long as you use the supplied MX base classes (especially the controller). As you (@kilishan) may remember, the problem arose when we attempted to move away from those base classes in Bonfire, but the /MX/Base.php, /MX/Controller.php, and /MX/Loader.php contain some very specific code to address that issue, though it's not always pretty or easy to understand/debug.

Still, I would certainly recommend avoiding calling Modules::Run() unless you have a very specific need for it, and it should never be done if any of the controllers involved do not extend MX_Controller (or a base class which extends MX_Controller). If I were drawing a map, the intersection of CI_Controller and Modules::Run() would be a stormy region guarded by the hydra.
Reply
#14

Ha that's funny! I guess maybe there are some CI 'Titans' from this forum guarding the same intersection...  Big Grin

So I've moved some code to a library. I'm not sure if loading models within a library will give problems, so is the following example allowed or bad practice..?

PHP Code:
   function getTemplateName($id NULL) {
 
       
        
// ... some code ...
    
 
       $this->ci->load->model('Templates/Templates_m');
 
       $templateData $this->ci->Templates_m->get($id);

 
       // ... maybe some more;
 
       
    


Thanks again for your input.

-Roger
Reply
#15

I don't see any problems with loading models from a library, personally.
Reply
#16

(This post was last modified: 05-29-2015, 08:05 AM by mwhitney.)

(05-29-2015, 07:30 AM)kilishan Wrote: I don't see any problems with loading models from a library, personally.

Agreed. Libraries are there to fill the gaps in the MVC structure when building an application. By using a model from within the library, not only is the library staying out of a clearly-defined role in the MVC structure, it's also allowing the data access to remain consistent if a controller or some other part of the application needs to access the same data, as it should use the same model.

I also feel like I should elaborate on the hydra reference. When we tried to cut the MX_Controller out of Bonfire's use of HMVC, especially in my own application where some of the code is now nearly 3 years old (but the newest module was written yesterday), some bugs popped up which eventually came back to CI_Controller being attached to multiple points in the class hierarchy when calling $this->{whatever}. Essentially, what was a singleton under MX_Controller became a multi-headed monster when using CI_Controller and Modules::Run(), and attempting to squash the bug just lead to finding more bugs.
Reply
#17
Smile 

Thanks guys for the useful responses!

-Roger
Reply
#18

(05-29-2015, 08:05 AM)mwhitney Wrote:
(05-29-2015, 07:30 AM)kilishan Wrote: I don't see any problems with loading models from a library, personally.

Agreed. Libraries are there to fill the gaps in the MVC structure when building an application. By using a model from within the library, not only is the library staying out of a clearly-defined role in the MVC structure, it's also allowing the data access to remain consistent if a controller or some other part of the application needs to access the same data, as it should use the same model.

I disagree ... Libraries are supposed to be portable, not dependable on the application that uses them and you don't get that when a library uses a model.
Reply
#19

(05-29-2015, 09:50 AM)Narf Wrote: I disagree ... Libraries are supposed to be portable, not dependable on the application that uses them and you don't get that when a library uses a model.

The portability of the library is not improved by accessing the database through the database library instead of a model. You would still need to specify the database structure (in a migration or documentation), and you have other problems to deal with if your library isn't the only access point for that data (and if it is the only access point for that data, what's it doing that makes it a library instead of a model?).
Reply
#20

(05-29-2015, 12:09 PM)mwhitney Wrote:
(05-29-2015, 09:50 AM)Narf Wrote: I disagree ... Libraries are supposed to be portable, not dependable on the application that uses them and you don't get that when a library uses a model.

The portability of the library is not improved by accessing the database through the database library instead of a model. You would still need to specify the database structure (in a migration or documentation), and you have other problems to deal with if your library isn't the only access point for that data (and if it is the only access point for that data, what's it doing that makes it a library instead of a model?).

Who said a library has to use a database? Or that it is a data access point at all?

You should be able to take a library, drop it in another application and work with it with no changes necessary. A model on the other hand is designed for a specific application. That's the only difference between the two.
Reply




Theme © iAndrew 2016 - Forum software by © MyBB