Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Modules without Namespaces
  • agentphoenixagentphoenix
    Long story short, I'm porting a pretty massive project from CI to Kohana, but Fuel intrigues me, so I'd like to do due diligence and make sure that I'm going the right route when I do a massive refactoring. I use KO's cascading file system like no one's business and I know Fuel uses a similar system. The way I have things set up now, my system's core classes are in a module to keep the system core away from any changes that admins would be making. (The separation makes it significantly easier to update the system if they don't need to be stepping around their own files, especially important since some of the admins aren't great with this kind of stuff.) In Kohana, storing all that code in a module works beautifully and with the cascading filesystem, admins can override views and stuff from the application or a special override module. Perfect. Enter Fuel. I'd like to do a similar type of thing, but the problem is that A) packages aren't supposed to have controllers, and B) modules are namespaced. Honestly, I don't want a URL that looks like: [url=http://something/module/controller/action]http://something/module/controller/action[/url]. I also don't want to route this to high heaven just to get around that. I think that's a pretty poor way to handle things and is absolutely going to have an impact on performance if the system has to figure out where to send the user for every single request. So really, I think the question now is if there's any way to use modules in a non-namespaced way so that I can duplicate my application setup now or do I just need to stick with Kohana and focus on porting something like the Fuel ORM over to Kohana (because let's face it, it's pretty spectacular). I'm open to all kinds of suggestions, so I'd love to hear what people have to say/think. Thanks!
  • Dan HorriganDan Horrigan
    Hey agentphoenix, It is hard to make an app designed for another framework (such as Kohana) work with another framework. This is not just true for Fuel, but for any framework. The issue is that you are going into this thinking "How can I make Fuel act like Kohana?" when you should be asking "What is the best way to do X in Fuel?" What you are looking to do is certainly possible in Fuel. For instance: If the Module Controller's name is the same as the Module itself, then the controller name can be left out of the URL (e.g. /core/action). However, it won't be as easy to do. Simply because your application was designed for Kohana. How I would handle this issue (allowing other people to extend the core), would be Events. This way, you have complete control over when an Event is fired or not fired (do you really want them extending your auth login handling method?). You can see the documentation for how to use these: http://fuelphp.com/docs/classes/event.html Thanks,
    Dan
  • agentphoenixagentphoenix
    Yeah, I realized after spending some time thinking about it that I was trying to tackle the problem the wrong way and was thinking about Fuel in a Kohana mindset, which limited the framework unnecessarily. In the process of looking through the docs, I realized that I could add paths for Fuel to use in the file system which opened up a lot of different possibilities (namely two application directories ... one for general stuff and another for the actual application core). The more I use Fuel, the more I realize some of the cool little things that are tucked away in different corners. Once I got myself into a Fuel mindset, things started to fall in to place. Thanks for the great framework!
  • WanWizardWanWizard
    In Fuel, packages are meant to extend the Core, where modules are meant to extend the application. This means your systems core classes go into a package. You can alias the package to the global namespace, so you don't have to prefix its classes when you use them in the application. The "Auth" package does this. As to modules, Fuel requires a module to be namespaced. This is done to prevent class name collisions. It's not a huge job to add a namespace, and it's a one-time conversion job. I don't understand what you mean with 'something' in that URL. Namespacing is a code thing, and completely invisible from the outside. The URL to a module will be [url=http://website/module/controller/action]http://website/module/controller/action[/url]. Not containing the module also leads to all kinds of side effects, like loading the wrong controller, model or view, in case two modules use the same name. Namespacing makes sure the module remains a separate entity within your application, and is easy to port to another one. I also don't understand your performance issues. Namespacing a module actually makes it a lot faster. Where Kohana has to look in several places to find the required controller, Fuel loads it in one go. Maybe if you can go into more detail about what exactly your issues are (you are very vague in your statements), we can give more to the point answers.
  • agentphoenixagentphoenix
    I was doing my best to not write a novel explaining everything, but clearly that attempt failed. When I'm talking about the system core, I'm talking about classes, models and controllers. Like you said, packages are intended to extend the core and not include controllers. (I've seen discussions where it's possible but not the way it was intended to be used; I'd like to avoid breaking convention if possible.) All of the work I do is in the core "module" and is done that way so that any piece of the system can be overridden. For instance, the core has a main controller that has pages for welcome, credits, news and contact. Those are the defaults and how the system behaves, but an admin may want to override the welcome method with their own that pulls in other pieces of information from the database. With Kohana, I have a core module that has a main controller. If someone wants to override that, they can create a main controller in the application folder and use the cascading file system to use the version of the file in the application folder instead of what's in the core module. This is an essential component to the system. In a similar way, classes, models and even views can override the core. That means that I actually want the system to look around for the right file. I understand there's a performance hit, but that's the whole idea of the system setup that admins can override just about anything in the system with their own code while still leaving the core intact. When an update comes up, they end up having to just delete the old system core and upload the newer version. Their changes stay intact but the system core is updated. As an illustration, here's an abbreviated version of the file system: - application
    - nova
    -- kohana
    --- [all the kohana modules]
    -- nova
    --- core
    --- setup
    --- wiki
    -- system [ko 3.1] So currently, I have a Controller_Main in the nova/core module that has everything that should be the "default" for the system. But if I wanted to override that, I'd add a Controller_Main to the application/classes/controller directory and then the system would use that since it's higher in the cascading file system. That's what I'm aiming for and all my attempts so far to pull that off with Fuel have failed, probably because I'm less familiar with it than I am with Kohana (mainly because I've been using Kohana for this project for a few months now). When it comes to Fuel though, modules are namespaced. When I try to do the above and go to http://example.com/main/index [when Controller_Main is in a module called "core"], Fuel throws a 404 because the controller isn't in the module namespace. When I add it to the module namespace, I have to go to http://example.com/core/main/index to get to the page and that's what I don't want. I want to keep the namespace out of the URL and just have the controller and action (there are situations where that isn't the case, but no sense complicating this any more right now). I also don't want to route the crap out of this and set up routing for every controller in the core module just to get the URL to behave correctly. I don't think that's the right way to do it and it'll raise the barrier to entry more than it's already been raised. I think what I'm looking to find out is if something like this is possible with Fuel or if I'm just better off sticking with the setup I have with Kohana. I'd love to use Fuel because I do like what you guys have done (the ORM is awesome). I don't want to abandon Fuel for this project unless it's absolutely necessary, but I definitely need feedback from someone intimately familiar with Fuel, so any advice you can offer would be fantastic. Thanks!
  • WanWizardWanWizard
    Reading this my first reaction would be: "If you want something like Kohana, you should use Kohana". Fuel works differently, and has a different design philosophy. If you want to use Fuel, you have to adhere to it. For me, the way Kohana has implemented modules (I don't even call it modules) has it's flaws, as it lacks separation. It's just one big application where a cascading filesystem with fuzzy logic searching is used in an attempt to create some structure. It also means that if you request [url=http://website/main/something,]http://website/main/something,[/url] Kohana has to search through an entire file structure to locate something called main. It might find it in 'core' now, but as soon as you add a 'module' called 'about', and it contains a controller called 'main', you're screwed, because it's going to find that one first. In Fuel, you can create the same type of structure within your application, but the structure is 'reversed', since all controllers live in classes/controller. Nobody's stopping you from creating a Core_Main_Controller, which would reside in app/classes/controller/core, and is called main.php. Same for models, views, etc. This is a lot faster than the fuzzy search Kohana uses to locate files, a class name can be directly related to a file on disc, no searching needed. It also means that with [url=http://website/main/something,]http://website/main/something,[/url] main.php should be in app/classes/controller. Also, in Fuel more specific items override general items. So in case of 'core/main', a 'main' controller in module 'core' is loaded instead of a global Core_Main controller. It is not in Fuel's architecture to have modules replace application classes. And finally, processing custom routes is a lot faster and more precise than searching for files and hoping to find the correct one.
  • agentphoenixagentphoenix
    Thanks for your quick responses! Unfortunately, I just don't think Fuel can do what I need it to do while adhering to the requirements for the project. Kohana definitely gives me a lot more flexibility in how I implement the system. I'll certainly have to find another project to get my feet wet with Fuel though. Thanks again for your help.
Add a Comment

Howdy, Stranger!

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

Sign In Apply for Membership

Categories

In this Discussion