I'd like to start out by saying that this is a really big suggestion. It's so big that this would be a XenForo 2.0 type suggestion. It's also a very technical suggestion which unfortunately wouldn't have any discernible benefit by itself to the end (forum) user, though coupled with other things it definitely would, especially to website administrators and programmers. More on that later. Please feel free to ask any questions about my suggestion if something is unclear or offer criticisms. Lastly, sorry for the size of this post, brevity is lost on me.
Currently XenForo uses the Model-View-Controller (MVC) design pattern. I'm suggesting that this be changed to the more generalized Hierarchical Model-View-Controller (HMVC) design pattern (Presentation-Abstraction-Control (PAC)) or something similar to it. In essence I'm suggesting the widgetization of XenForo. Traditionally in an HMVC architecture subordinate MVC triads are called from the controller or view of its parent, kind of like a template include but for an entire triad rather than just a view partial. While this would make XenForo much more modular in nature and perhaps more maintainable, it wouldn't do much for modding except maybe make it worse. For this to work the hierarchy shouldn't be hard coded, at least not for disparate MVC triads.
When you think about a webpage it's basically just a bunch of nested boxes. Take for instance the XenForo community page. At the top there's the header which has a logo and underneath it the navigation bar. Then there's the content area which is split into two columns; on the left you have the bread crumb, forum list, and another breadcrumb, and on the right you have the profile statistics, staff online now, members online now, etc… widgets. Then at the bottom you have the footer of which XenForo has two. Granted this is a very broad overview, but this is the general structure.
I understand the purpose of Pages in XenForo but I'd like to offer a suggestion for what I think they could be. Perhaps Pages could be this general structure in which MVC triads fit. To do this they would need to be linked with routes and essentially they'd need an inheritance hierarchy. The inheritance would be there so you could easily keep the same structure throughout the site (or not if you want to override it) while still changing what is actually displayed on a page or parts of it. So for instance you could keep that right side bar full of widgets (staff online, members online, etc…) on the entire site or perhaps just on the forum section and not on the help, members, or other sections you may have. I don't have a specific suggestion for how this could be done. I've thought about it a while but don't have anything concrete. The point is that Pages would contain which widgets (MVC triads) are called, not other MVC triads. Of course MVC triads could still hard code requests to other MVC triads if it's appropriate.
So what would this solve? Well one feature that people have been clamoring for is a CMS to go with this fine forum software. Of course what constitutes a CMS varies from person to person. The holy grail of websites, at least to me, is to have one piece of software that does everything rather than having multiple different pieces of software which communicate through bridges or not at all. Of course one could argue that the latter way of doing things has benefits as well since each piece of software is purpose built whereas one piece of software will quickly become bloated including too much functionality and end up excelling at none of them. This leads us to people who do not want a CMS built into XenForo at all.
I believe this suggestion is a good middle ground. This would essentially make XenForo a very, very basic CMS - which it already kind of is - but it would really be a side effect of having a more generalized architecture, not the purpose of it. It most definitely wouldn't be a contender with other CMS software as is, but it would make it much easier for add-on developers or even the XenForo team to make a really great CMS as an add-on or a separate product.
Another suggestion I've seen pop up is the desire for widgets, specifically widgets that can easily be placed on a page and all pages under it. This would be something that my suggestion excels at.
As far as potential problems go there's the really big one, specifically I may not have thought this through very well to realize all of the potential problems . Even if my suggestion is workable there is the question of performance.
Currently an HTTP request will hit the front controller and be routed to the appropriate controller and action, i.e. Request->Route->Response. With HMVC it's not that simple. An HTTP request will hit the front controller and be routed just as before, but rather than returning a response right away there may be more internal requests that have to go through the same process to get all of the page content before returning the response. This would definitely increase object memory allocation/deallocation and method call overhead. So this suggestion is potentially great for design, but perhaps not so great for performance. There are many things that could be done to help alleviate the performance penalties of this design, but in all likelihood it would generally be slower. I doubt it would slow a website to a crawl, it may not even be noticeably slower, but it is something to consider. Of course not too long ago MVC was considered pretty inefficient, so perhaps that should be kept in mind as well.
Now that we have some potential problems out of the way let's look to the future assuming this suggestion was implemented. One interesting addition in HTML5 was history.pushState and history.replaceState which has since been wrapped up in the third-party History.js script for convenience. It's clear that when you visit a webpage for the first time you need to load the entirety of that page, i.e. the header, content area, footer, etc... However, after this is done when you click an internal link many parts of the page don't actually change. The header probably doesn't change, which navigational tab is highlighted may or may not change, the footer probably doesn't change, and if you have a sidebar full of widgets they probably don't change either. Yet when we click on an internal link we send a request to the server for the entire page to be rendered and sent to us, not just the part that actually changes. Of course this doesn't cost a lot of computing resources or bandwidth to do, but over time it would definitely add up.
AJAX helps out on this front quite a bit, XenForo uses a lot of AJAX in fact, but it doesn't do it to the extent that I believe it could with the new HTML5 history API. Just as a quick example you could be viewing the forum list, click on a specific forum, and have an AJAX request call up the thread list for that particular forum while updating the address of the website you're on to allow for things such as bookmarks. Nothing else would change or load and HMVC would make this type of request quite nice to do since most everything would be an MVC triad.
Another potential benefit would basically be a WYSIWYG editor for the website as a whole. The website would be separated into various sections as described above. Adding a new widget to a side bar column could be as easy as dragging and dropping one in under AdminCP. Adding a new navigational tab could be as easy as clicking a little "+" button next to the other tabs and specifying its properties. Of course you can do this with the current architecture, but I believe it would be simpler to do with HMVC in the way that I've described.
Well that's my suggestion, I hope it didn't bore you too much to read it.
Currently XenForo uses the Model-View-Controller (MVC) design pattern. I'm suggesting that this be changed to the more generalized Hierarchical Model-View-Controller (HMVC) design pattern (Presentation-Abstraction-Control (PAC)) or something similar to it. In essence I'm suggesting the widgetization of XenForo. Traditionally in an HMVC architecture subordinate MVC triads are called from the controller or view of its parent, kind of like a template include but for an entire triad rather than just a view partial. While this would make XenForo much more modular in nature and perhaps more maintainable, it wouldn't do much for modding except maybe make it worse. For this to work the hierarchy shouldn't be hard coded, at least not for disparate MVC triads.
When you think about a webpage it's basically just a bunch of nested boxes. Take for instance the XenForo community page. At the top there's the header which has a logo and underneath it the navigation bar. Then there's the content area which is split into two columns; on the left you have the bread crumb, forum list, and another breadcrumb, and on the right you have the profile statistics, staff online now, members online now, etc… widgets. Then at the bottom you have the footer of which XenForo has two. Granted this is a very broad overview, but this is the general structure.
I understand the purpose of Pages in XenForo but I'd like to offer a suggestion for what I think they could be. Perhaps Pages could be this general structure in which MVC triads fit. To do this they would need to be linked with routes and essentially they'd need an inheritance hierarchy. The inheritance would be there so you could easily keep the same structure throughout the site (or not if you want to override it) while still changing what is actually displayed on a page or parts of it. So for instance you could keep that right side bar full of widgets (staff online, members online, etc…) on the entire site or perhaps just on the forum section and not on the help, members, or other sections you may have. I don't have a specific suggestion for how this could be done. I've thought about it a while but don't have anything concrete. The point is that Pages would contain which widgets (MVC triads) are called, not other MVC triads. Of course MVC triads could still hard code requests to other MVC triads if it's appropriate.
So what would this solve? Well one feature that people have been clamoring for is a CMS to go with this fine forum software. Of course what constitutes a CMS varies from person to person. The holy grail of websites, at least to me, is to have one piece of software that does everything rather than having multiple different pieces of software which communicate through bridges or not at all. Of course one could argue that the latter way of doing things has benefits as well since each piece of software is purpose built whereas one piece of software will quickly become bloated including too much functionality and end up excelling at none of them. This leads us to people who do not want a CMS built into XenForo at all.
I believe this suggestion is a good middle ground. This would essentially make XenForo a very, very basic CMS - which it already kind of is - but it would really be a side effect of having a more generalized architecture, not the purpose of it. It most definitely wouldn't be a contender with other CMS software as is, but it would make it much easier for add-on developers or even the XenForo team to make a really great CMS as an add-on or a separate product.
Another suggestion I've seen pop up is the desire for widgets, specifically widgets that can easily be placed on a page and all pages under it. This would be something that my suggestion excels at.
As far as potential problems go there's the really big one, specifically I may not have thought this through very well to realize all of the potential problems . Even if my suggestion is workable there is the question of performance.
Currently an HTTP request will hit the front controller and be routed to the appropriate controller and action, i.e. Request->Route->Response. With HMVC it's not that simple. An HTTP request will hit the front controller and be routed just as before, but rather than returning a response right away there may be more internal requests that have to go through the same process to get all of the page content before returning the response. This would definitely increase object memory allocation/deallocation and method call overhead. So this suggestion is potentially great for design, but perhaps not so great for performance. There are many things that could be done to help alleviate the performance penalties of this design, but in all likelihood it would generally be slower. I doubt it would slow a website to a crawl, it may not even be noticeably slower, but it is something to consider. Of course not too long ago MVC was considered pretty inefficient, so perhaps that should be kept in mind as well.
Now that we have some potential problems out of the way let's look to the future assuming this suggestion was implemented. One interesting addition in HTML5 was history.pushState and history.replaceState which has since been wrapped up in the third-party History.js script for convenience. It's clear that when you visit a webpage for the first time you need to load the entirety of that page, i.e. the header, content area, footer, etc... However, after this is done when you click an internal link many parts of the page don't actually change. The header probably doesn't change, which navigational tab is highlighted may or may not change, the footer probably doesn't change, and if you have a sidebar full of widgets they probably don't change either. Yet when we click on an internal link we send a request to the server for the entire page to be rendered and sent to us, not just the part that actually changes. Of course this doesn't cost a lot of computing resources or bandwidth to do, but over time it would definitely add up.
AJAX helps out on this front quite a bit, XenForo uses a lot of AJAX in fact, but it doesn't do it to the extent that I believe it could with the new HTML5 history API. Just as a quick example you could be viewing the forum list, click on a specific forum, and have an AJAX request call up the thread list for that particular forum while updating the address of the website you're on to allow for things such as bookmarks. Nothing else would change or load and HMVC would make this type of request quite nice to do since most everything would be an MVC triad.
Another potential benefit would basically be a WYSIWYG editor for the website as a whole. The website would be separated into various sections as described above. Adding a new widget to a side bar column could be as easy as dragging and dropping one in under AdminCP. Adding a new navigational tab could be as easy as clicking a little "+" button next to the other tabs and specifying its properties. Of course you can do this with the current architecture, but I believe it would be simpler to do with HMVC in the way that I've described.
Well that's my suggestion, I hope it didn't bore you too much to read it.
Upvote
2