Submodules, yay or nay?
Moderator: General Moderators
Submodules, yay or nay?
So I've been trying to decide if this is a good idea or a bad idea for quite some time:
http://www.dohdoh.net/2008/04/04/zend-f ... trap-file/
The potential upside to doing it is separation of code into more manageable smaller tasks, with better organization ( a "store" module may have a "extensions" module that may have a "payments" module ), or should this hierarchy go into the domain ( the models )
I guess the potential downside is added complexity for routing, possible added confusion in the long run and performance issues
any input? Specifically I'm trying to find a good solution to the idea of a "store" module for instance having multiple "sub modules" ( payment modules, shipping modules ). Likewise an accounting module may also need to use the same shipping module. I could theoretically subclass controllers across modules, but is there a better way to solve this?
In other words, what is the standard accepted practice of handling logical "route branching" in the controller past the "module" "controller" "task" limit of 3 layers?
http://www.dohdoh.net/2008/04/04/zend-f ... trap-file/
The potential upside to doing it is separation of code into more manageable smaller tasks, with better organization ( a "store" module may have a "extensions" module that may have a "payments" module ), or should this hierarchy go into the domain ( the models )
I guess the potential downside is added complexity for routing, possible added confusion in the long run and performance issues
any input? Specifically I'm trying to find a good solution to the idea of a "store" module for instance having multiple "sub modules" ( payment modules, shipping modules ). Likewise an accounting module may also need to use the same shipping module. I could theoretically subclass controllers across modules, but is there a better way to solve this?
In other words, what is the standard accepted practice of handling logical "route branching" in the controller past the "module" "controller" "task" limit of 3 layers?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Submodules, yay or nay?
I prefer modules. They just organize things better and allow me to scope models and views to where they belong.
(#10850)
Re: Submodules, yay or nay?
So you find its best to just create sub controllers within the module to the Nth level or whatever you need ( and not use the modules within modules concept )? Is it best to create more generalized modules or more specific modules? How do you decide when a controller has grown large enough to need to be it's own module?
Should a controller from one module every subclass a controller from another module? what is a good resource for learning more of this abstract theory and not the technical aspects of using a framework ( besides going to college lol )
Should a controller from one module every subclass a controller from another module? what is a good resource for learning more of this abstract theory and not the technical aspects of using a framework ( besides going to college lol )
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Submodules, yay or nay?
Not sure what you mean by a "sub controller" or "module" for that matter? I think of a "module" as a directory that contains a set of related MVC classes -- Models, View and Controller, plus Helpers, Templates, etc. So an application can just have one default module which would have the path './' I guess. Or you can organize the application into multiple MVC directories and specify the directory with an addition parameter.jshpro2 wrote:So you find its best to just create sub controllers within the module to the Nth level or whatever you need ( and not use the modules within modules concept )? Is it best to create more generalized modules or more specific modules?
Sub-controller would be some sort of framework specific construct. From the URL point of view there are really only controllers. The might be called Helpers too. You can also organize controllers into sub-directories within the 'controllers' directory, but you then need some character other than '/' for a path separator (e.g. Skeleton uses '_').
I don't think there is a rule for this. If related actions share common supporting methods then keeping them together makes sense because you open the file and everything is in one place.jshpro2 wrote:How do you decide when a controller has grown large enough to need to be it's own module?
I think that any code shared by multiple modules should be moved out of the modules to a higher level to make clear it is shared.jshpro2 wrote:Should a controller from one module every subclass a controller from another module? what is a good resource for learning more of this abstract theory and not the technical aspects of using a framework ( besides going to college lol )
(#10850)
Re: Submodules, yay or nay?
Thanks, you've cleared a few things up for me. I'm going to try to stray away from the "submodules" concept as the way you've explained it it kinda seems like it'd be creating a paradigm within a paradigm.
The original problem that got me thinking about it was, should I make "admin" it's own module, and if so should each "frontend" module be a "submodule" of that admin module. I guess I was overlooking that controllers, models, and views can have unlimited sub directories.
So if an admin controller needs to use a model from a frontend module, Its best to locate those models in my libraries folder somewhere? ( or create an application wide "models" directory that all my modules can use?, right?)... I guess familiarizing myself with more frameworks will help me look at the problem from different angles too, huh?
Edit: So basically I should avoid logical branching within controllers and map routes directly to tasks as much as possible?
The original problem that got me thinking about it was, should I make "admin" it's own module, and if so should each "frontend" module be a "submodule" of that admin module. I guess I was overlooking that controllers, models, and views can have unlimited sub directories.
So if an admin controller needs to use a model from a frontend module, Its best to locate those models in my libraries folder somewhere? ( or create an application wide "models" directory that all my modules can use?, right?)... I guess familiarizing myself with more frameworks will help me look at the problem from different angles too, huh?
Edit: So basically I should avoid logical branching within controllers and map routes directly to tasks as much as possible?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Submodules, yay or nay?
Admin it typically the reason that you use a module. That way you can separate out that code and have any Access Control specific to that module. And yes, common classes could go in a global libraries or Models or Views directory.
(#10850)
- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: Submodules, yay or nay?
In this scenario, "payment" and "shipping" sound like business logic. In my opinion, the meat of that code should be in domain objects, and not in controllers. These can be used in many different contexts. If you have "admin" and "frontend" modules, I see those as shells on a core domain. Anything application-wide, such as ACL, permissions, etc., should be kept in your controllers and out of your business logic so you can concentrate on the "good stuff", ie payment and shipping. That should leave you with context-specific controllers that won't typically need to be shared across contexts/presentations, but a reusable domain layer that is context-independent.jshpro2 wrote:Specifically I'm trying to find a good solution to the idea of a "store" module for instance having multiple "sub modules" ( payment modules, shipping modules ). Likewise an accounting module may also need to use the same shipping module. I could theoretically subclass controllers across modules, but is there a better way to solve this?
I've never been a fan of the [module/]controller/task/param routing. Arborint has recommended Horde Routes in the past. I prefer Konstrukt.jshpro2 wrote:In other words, what is the standard accepted practice of handling logical "route branching" in the controller past the "module" "controller" "task" limit of 3 layers?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Submodules, yay or nay?
Not sure what the real difference is -- maybe you can clarify. As I recall with Konstrukt you have to map everything. You can certainly do the same kind of mapping with any of these other frameworks. But being able to just put controllers in directories without have to create mappings certainly helps with large projects and makes refactoring easier.allspiritseve wrote:I've never been a fan of the [module/]controller/task/param routing. Arborint has recommended Horde Routes in the past. I prefer Konstrukt.
(#10850)
- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: Submodules, yay or nay?
The difference between... Horde Route and Konstrukt?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Submodules, yay or nay?
Well the Konstrukt router. I think most frameworks can do Konstruckt style mappings, but they can also do filesystem based ones too.
(#10850)
- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: Submodules, yay or nay?
I think the biggest difference is that in Konstrukt, the routes are distributed between many different controllers (each controller has an array of child controllers kept within it). In most frameworks, the routing is defined all at once in a central location. Sure, you could probably implement konstrukt mapping in another framework, but as far as I know none of them do.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Submodules, yay or nay?
Yes, but I don't think they really get used that way in Konsturkt. I know what Troels was aiming for. But in reality you end up forwarding instead. Then you have just done two controller loads for a request. And a lot of what you are doing for reuse is really Model/View stuff anyway. At least that was my experience with Konstrukt when I used it a while back.allspiritseve wrote:I think the biggest difference is that in Konstrukt, the routes are distributed between many different controllers (each controller has an array of child controllers kept within it). In most frameworks, the routing is defined all at once in a central location. Sure, you could probably implement konstrukt mapping in another framework, but as far as I know none of them do.
'[/module]/controller/action/' works because it maps directly to a [directory]/class/method. That is a natural association with OO languages. You certainly don't need to do that -- hence routers. But is certainly makes things easy.
(#10850)
Re: Submodules, yay or nay?
Gotchya, even though my URL hierarchy and user interface may be more then 3 levels deep, its best to try to keep 1 module / controller / task so it doesn't take extra gymnastics to figure out where stuffs going. Makes sense.
- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: Submodules, yay or nay?
You actually end up with as many controller loads as there are sections in the url /one/two/three/four/five/six/ etc., barring the occaisonal parameter. I actually like it that way. Parent controllers can set up context for child controllers, and modify the logic in case the subspace that is left in the URL contains parameters and not handles to more controllers. It works well with having one controller per page, instead of one controller method per page.arborint wrote:Yes, but I don't think they really get used that way in Konsturkt. I know what Troels was aiming for. But in reality you end up forwarding instead. Then you have just done two controller loads for a request. And a lot of what you are doing for reuse is really Model/View stuff anyway. At least that was my experience with Konstrukt when I used it a while back.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Submodules, yay or nay?
I agree that it sometimes works well with having one controller per page. I don't agree that it does not work well to have 'one controller method per page' as you imply. You can do one controller per 'page' with other frameworks as well. Konstrukt goes for a kind of purity were everything is the same kind of controller. That forces you to do a lot of forwarding. Being able to associate a request with a method is very handy. Especially when a 'page' is CRUD, has multiple states, Ajax calls, etc.allspiritseve wrote:It works well with having one controller per page, instead of one controller method per page.
(#10850)