First off, I have just started using FuelPHP so I can have misunderstood the internals and design principals of Fuel.
We have put our GUI controllers into a separate module. There will eventually be other types of GUIs and we already have an other module for an external API that apps can call. However all the models are located in app/. So different customized GUIs/APIs in different modules work on the same models in app/. There is no sharing between modules. This works without problems (consistent with Fuel design?)
We use mustache for template rendering (but this problem seems to exist for other parsers as well). If I correctly understand how configurations work in Fuel is that they are all merged but with the module configuration last, i.e inheritance.
So if the router points to a module's controller that is a template controller, an instance of View_Mustache (or View_Smarty for example) is created and the template engine is loaded with appropriate settings from the configuration of that module. And then the template engine instance is stored as a static ($_parser) in View_Mustache (or View_Smarty etc) for future rendering.
However if that module controller throws an HttpNotFoundException and routes back to the 404 for app/ (which is configured in the apps routing config and therefore inherited to the module) and try to render app's 404 with the same template engine, an instance already exists as static but configured with the previous module's parser configuration, which can be totally different (paths etc).
I guess this should also be a problem if you do an HMVC call to another controller in a different module. Or is HMVC cross module calls bad design?
Is this scenario not supported? Is this missuse of Fuel modules? Or should this work by having template engines staticlly saved per module?
If Fuel, configuration is global, as you have noticed, so this is not the way to approach this.
Instead, leave the default view type to "php", and use the extension to identify which template engine you want to use to render the view. This works on a per-view basis, so that's exactly what you need.
This will change in Fuel v2, where every module has it's own Config instance, and you no longer have this issue.
Currently, for views want you want is still not supported in the alpha codebase. The issue here is that Fuel uses lazy rendering for views. This means the view file is actually only rendered when needed, which is usually when you echo out the response. So if no type is given in the view name, the View instance should store the current active default view type, so that when the time comes to render it, it still knows what the view type was.
Technically this can be done in v1 too, but we keep new features in v1 to a minimum at the moment, to spend as much time as possible on v2. But you're free to send in a pull request if you want this functionality in the core.
Donate
