Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Modules + ORM
  • So I'm working on a project that seems to have gotten a bit big with lots of sections and I'm thinking i should use Modules to organize it better. I have never used it before so it will be a good learning experience. I just need some help understanding it and how it will work with the ORM, also any advice on file structure to keep from repeating code. Modules With modules I'm not sue how best to access the ORM Models, for example if I create a music module it needs Model_Music, Model_List, Model_Tag to create the results, but if 'Model_Tag' is in a separate module, would it be able to access it? and how if it has a relationship.
    File structure There are listings: Music, Movies, Shows. (http://domain.com/music/view/1)
    It supports Tags for each listing. (http://domain.com/tag/view/rock) So far that's easy, but features like 'likes' and 'recommendations' confuse me, as in I could have 'likes' in each listing's controller. Example (http://domain.com/music/like/1) or in its own controller (http://domain.com/like/music/1). Also each listing has 'recommendations' which list similar listings with reviews and 'Likes' for each recommendation. So 'likes' can be for listings and recommendations. Music (Model_Music)[one-to-one Model_List]
    -- Likes
    -- Tags (many-to-many)
    -- Recommendations (cross-reference by UNION)
    -- List (in this case all tracks and the song name) [one-to-many] Shows (Model_Shows)[one-to-one Model_List]
    -- Likes
    -- Tags (many-to-many)
    -- Recommendations (cross-reference by UNION)
    -- List (in this case all episode names and number)[one-to-many]
    As you can tell most of it will be the same code just with different URL structure and some changes on which table to use. I'm just not sure how to handle things best, just need a more experienced view on handling all these additional features to each listing music.php, shows.php, movies.php any any others that will be added.
  • To be able to load something from a module that's not active you need to load that module first:
    \Fuel::add_module("module");
    

    After that you can use their classes by prefixing their namespaces:
    \Module\Class::method();
    

    Or load stuff like config and lang files:
    \Config::load('module::configfile');
    

    When relating models to each other you don't have to configure them if they're in the same namespace and keeping to convention. But if you do want to relate models to models from other models (or a module model to an app model) you need to configure it, and you need to use the FULL classname. That includes the namespace, but no prefixed backslash. Thus the class \Module\Model_Example, which you might call as just Model_Example when called from its own namespace is "Module\\Model_Example" when configuring a relation.
  • Thanks for the reply, ill give it a try. Any ideas on what i can do to improve to file structure to minimize repeated code? it Doesn't need to be modules, just someway I can utilize and share the features (likes, recommended, lists, tags) between the other controllers like Music, Movies, Shows etc ? I have been thinking of extending it by using (non-modular):
    [music]
    |__ like.php (class Controller_Music_Like extends Controller_Like)
    |__ tag.php (class Controller_Music_Tag extends Controller_tag)
    
    music.php
    like.php
    tag.php
    

    Where tag.php has all the 'tag' controllers and music\tag.php has variables that modifies the parent tag.php. However im left with tag.php just sitting there and accessible from http://domain.com/tag/ I'm really inexperienced with structuring the system, and I want to write better code, without repeating things unnecessary. Any advice is appreciated.
  • Would you be able to use an abstract class and implement them in each controller?
    // Tags.php
    abstract class Tags {
        public function do() {}
    }
    
    // Controller.php...
    class Controller_Something extends \Controller implements Tags {}
    
  • Frank Bardon wrote on Wednesday 11th of May 2011:
    Would you be able to use an abstract class and implement them in each controller?
    // Tags.php
    abstract class Tags {
        public function do() {}
    }
    
    // Controller.php...
    class Controller_Something extends \Controller implements Tags {}
    

    I could try that, thought i'm not sure if it would be the right way to handle the problem, but it in an interesting approach
  • Actually the most interesting thing about it is that it won't work :P An abstract class is still a class and you can't extend more than 1 class in PHP, but judging from the use of "implements" in the code I think the intention was an interface.
  • Well, you're right... and since you're right that means I am wrong. Boy I hate that. I need to get used to OO PHP programming. I'm still stuck back at PHP 4.3 when I stopped using it.
  • Haha, that explains alot *sigh* Any more ideas I can try, I want to learn the proper way to handle such a system. Can't be writing crappy code with Fuel
  • I think an interface would be a good solution actually... it's clean, and you can implement the code in multiple controllers without ever needing to duplicate it...
  • As far as I know, interfaces don't prevent you to repeating code.
    Form the manual
    Object interfaces allow you to create code which specifies which methods a class must implement, without having to define how these methods are handled.
    Then you have to implement (write or copy) the code in each class that implements the interface. Theres no 'parent' or shared logic. Shared features sounds to me more like models/classes than controllers.
    Or using a base controller with aggregation on the shared features and then extended to modify the default behavior if needed.
  • Well, maybe there's a better solution... but here's something I did in my models. I created a Tagable interface and a Tag class. In my models I put a few methods with some basic functionality. Each model knew if it could take one or several tags, ... Inside of the interface functions I use the Tag class methods... I guess I could just make the Tag class more dynamic, perhaps just use the table name as the ... but it definitely worked. I just kind of used the interface as a way to standardize the tag implementation across multiple models.
  • Frank Bardon wrote on Thursday 12th of May 2011:
    Well, maybe there's a better solution... but here's something I did in my models. I created a Tagable interface and a Tag class. In my models I put a few methods with some basic functionality. Each model knew if it could take one or several tags, ... Inside of the interface functions I use the Tag class methods... I guess I could just make the Tag class more dynamic, perhaps just use the table name as the ... but it definitely worked. I just kind of used the interface as a way to standardize the tag implementation across multiple models.

    I'm trying it out now ^^ I wonder if Model with the ORM can have Normal Models too.

Howdy, Stranger!

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

In this Discussion