One of the basic questions when designing a MVC base application is what
kind of a Controller to use. There are mainly two choices:
- Front Controller basically boils down to having one "index.php" that
takes all requests and decides what to do with them.
- Page Controller is when you have a separate script for each "page",
like a "view_thread.php" and a "view_page.php" and a "submit_post.php".
Some argue that in a web application, the webserver is the Front
Controller who looks at the request (the URL) and decides which page to
use. If that is the case, it would be unnecessary to code another Front
Controller in PHP, because Apache is much better at that job.
On the other hand, all Page Controllers will have to include some files
for functions common to every page, like authentication, logging, etc.
leading to redundancy and possible mistakes if something changes and one
forgets to update every singe Page Controller. With a central index.php,
any change will immediately be in effect for the whole app.
You might be able to tell that I'm in favour of the Front Controller.
Objections anyone?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After looking at MANY CMS's in the previous month, I have found that the central index.php clouds how code is executed and results in long URLS with many parameters.
If we go down that road we MUST make it easy to see, WHAT is going on and why. It is of extreme importance that the code is readable and understandable for someont, who just has an idea to a module without the big knowledge about MVC or XOOPS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've used both a front controller and page controller approach and find they both can work. Page approach is good for small canned features. Front approach is good for lots of dynamic pages.
I wouldn't mind using a front controller as long as
1- URLs remain short and manageable.
2- I can create php scripts that can be called directly and they can still make use of xoops classes. by-passing the front controller when need be.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
mithyt2:
"I have found that the central index.php clouds how code is executed and results in long URLS with many parameters."
It's true that centeral index.php blinds the process, but perhaps if someone's interested in how it works, you can provide link to MVC or XOOPS.org.
it hasn't been long since I started looking into XOOPS core files, but i think it's fairly understandable, that's if you actually want to know more about it. Diagrams explaining relationships between classes and how it works, might be better idea then to have people look into every file to search for relationships.
it's just way i think.. hehe..
sincerely
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
in terms of design - I usually prefer the front controller as well. To URLs manageable, we could break large controllers into a couple smaller ones based on functionality grouping (user management pages in /admin/user.php, group management in /admin/group.php etc)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not too many controllers, but perhaps the *nuke way of having some three pages, but my point was that we should not do too much processing in that page, but have clear, well-named files to include for pre-page processing and API inclusion.
As long as the front page controller is clear, concise and does not contain too much code, I will not go against that decision.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This would be my choice. I've been thinking more on this topic.
I think individual modules could also benefit from their own front controller?
I think it was Mithy who recently said that part of the reason he uses xoops is because he can essentially approach module development however the situation required. I have found the same thing.
Using a front controller should be the convention of xoops but having only 1 global file to access everything running in a xoops site limits your approaches to module development. Having a front controller 'model' to follow when doing mod dev removes these limitations.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm a front controller guy myself. I've done both, but after many years of doing this, I prefer the front controller. I find front controller is easier to implement in an object oriented system, mainly for the reasons Jochen has mentioned.
It can sometimes make for messy URLs. This can't be completely avoided, but it can be reduced with a good design.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One of the basic questions when designing a MVC base application is what
kind of a Controller to use. There are mainly two choices:
- Front Controller basically boils down to having one "index.php" that
takes all requests and decides what to do with them.
- Page Controller is when you have a separate script for each "page",
like a "view_thread.php" and a "view_page.php" and a "submit_post.php".
Some argue that in a web application, the webserver is the Front
Controller who looks at the request (the URL) and decides which page to
use. If that is the case, it would be unnecessary to code another Front
Controller in PHP, because Apache is much better at that job.
On the other hand, all Page Controllers will have to include some files
for functions common to every page, like authentication, logging, etc.
leading to redundancy and possible mistakes if something changes and one
forgets to update every singe Page Controller. With a central index.php,
any change will immediately be in effect for the whole app.
You might be able to tell that I'm in favour of the Front Controller.
Objections anyone?
After looking at MANY CMS's in the previous month, I have found that the central index.php clouds how code is executed and results in long URLS with many parameters.
If we go down that road we MUST make it easy to see, WHAT is going on and why. It is of extreme importance that the code is readable and understandable for someont, who just has an idea to a module without the big knowledge about MVC or XOOPS.
I've used both a front controller and page controller approach and find they both can work. Page approach is good for small canned features. Front approach is good for lots of dynamic pages.
I wouldn't mind using a front controller as long as
1- URLs remain short and manageable.
2- I can create php scripts that can be called directly and they can still make use of xoops classes. by-passing the front controller when need be.
mithyt2:
"I have found that the central index.php clouds how code is executed and results in long URLS with many parameters."
It's true that centeral index.php blinds the process, but perhaps if someone's interested in how it works, you can provide link to MVC or XOOPS.org.
it hasn't been long since I started looking into XOOPS core files, but i think it's fairly understandable, that's if you actually want to know more about it. Diagrams explaining relationships between classes and how it works, might be better idea then to have people look into every file to search for relationships.
it's just way i think.. hehe..
sincerely
in terms of design - I usually prefer the front controller as well. To URLs manageable, we could break large controllers into a couple smaller ones based on functionality grouping (user management pages in /admin/user.php, group management in /admin/group.php etc)
Not too many controllers, but perhaps the *nuke way of having some three pages, but my point was that we should not do too much processing in that page, but have clear, well-named files to include for pre-page processing and API inclusion.
As long as the front page controller is clear, concise and does not contain too much code, I will not go against that decision.
This would be my choice. I've been thinking more on this topic.
I think individual modules could also benefit from their own front controller?
I think it was Mithy who recently said that part of the reason he uses xoops is because he can essentially approach module development however the situation required. I have found the same thing.
Using a front controller should be the convention of xoops but having only 1 global file to access everything running in a xoops site limits your approaches to module development. Having a front controller 'model' to follow when doing mod dev removes these limitations.
I'm a front controller guy myself. I've done both, but after many years of doing this, I prefer the front controller. I find front controller is easier to implement in an object oriented system, mainly for the reasons Jochen has mentioned.
It can sometimes make for messy URLs. This can't be completely avoided, but it can be reduced with a good design.