Lack of interest Hierarchical MVC

This suggestion has been closed automatically because it did not receive enough votes over an extended period of time. If you wish to see this, please search for an open suggestion and, if you don't find any, post a new one.

Astrum

Active member
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.
 
Upvote 2
This suggestion has been closed. Votes are no longer accepted.
It has been the dream of a lot of people to do widgets and to enable to have any content in any place and to mix and match anything. My experience is that the level of abstraction that is needed generalizes too much and turns the product to be unusable. Sure, highly flexible, but unusable.

I have seen this going wrong in so many ways, I have seen it by enabling configuration flags for almost anything, by enabling a master xml layout template, by enabling a master template with xslt transformation, and last ... by what you name, widgets.

The fact is that, though portals are not dead, they are a developer dream, not the users'. Google found with iGoogle that few people customized the layout, and Yahoo also found that people did not customize the my.yahoo page, other than changing the weather and setting the country for the news. Widgets are completely out.

I think we should have an easy to use product that does one thing really well, instead of attempting to have the most flexibility that only a few would use. The MVC model is good enough. For those people that really need to change and move things around, they can code and modify the software.
 
Was going to post more or less the same thing that Rigel did. In most scenarios, modularity comes at the expense of usability. Not always the case, but more often than not it is.
 
It has been the dream of a lot of people to do widgets and to enable to have any content in any place and to mix and match anything. My experience is that the level of abstraction that is needed generalizes too much and turns the product to be unusable. Sure, highly flexible, but unusable.

Alright, I don't want to sound insulting but isn't that statement a bit hypocritical? XenForo itself is already highly abstracted. It uses the front controller, MVC, and dependency injection design patterns, not to mention that it's almost completely object oriented. I won't even go into other systems which are themselves highly abstracted. Just a few years ago there were plenty of arguments against the general MVC (+front controller) design because it was believed to be too abstract or redundant.

HMVC is not that much more abstract than MVC. With MVC a page request will hit the front controller and be routed to the appropriate page controller. This will load data from the appropriate models and render the view which is a bunch of view partials combined together in one way or another (generally speaking). HMVC at its most terse is one controller which loads data from one model to render one view which can then be included in other views created by other MVC triads (hence the hierarchical nature). I realize I made it sound a bit more complex but a lot of it was merely an idea of how not to hard code the hierarchy and leverage a database to make it more malleable.

Basically with MVC the models are quite specific to their purpose. Controllers are quasi-specific, that is they represent a page which needs data from many different models leading to some instances where controller actions are quite large and to keep the design DRY quite a few things are pushed into helpers. The hierarchy is then largely pushed into the view section. With HMVC the MVC triads themselves form the hierarchy and become quite specific.

I have seen this going wrong in so many ways, I have seen it by enabling configuration flags for almost anything, by enabling a master xml layout template, by enabling a master template with xslt transformation, and last ... by what you name, widgets.

If you could elaborate a bit on this I'd be grateful. As it stands I'm not sure where that comes into an HMVC design.

The fact is that, though portals are not dead, they are a developer dream, not the users'. Google found with iGoogle that few people customized the layout, and Yahoo also found that people did not customize the my.yahoo page, other than changing the weather and setting the country for the news. Widgets are completely out.

I think we're talking about different things now. Perhaps in my post I wasn't clear on some aspects. Sorry about any confusion. HMVC would very much be a back-end change. I'm not suggesting forum users be able to change widgets. This is for the benefit of developers and website administrators. While I'm sure someone could come up with a way for forum users to change the way the page looks for them in an HMVC design this was not the goal of my suggestion, far from it in fact.

In most scenarios, modularity comes at the expense of usability. Not always the case, but more often than not it is.

You're going to have to define usability with respect to some group. HMVC would be great for add-on developers as its a more modular approach than what is currently offered. It would allow website administrators to change the way the website looks and functions far more easily than is currently possible. When it comes to the forum users there would essentially be no real difference between a stock install of an MVC or HMVC version of XenForo. The HTML, CSS, and Javascript would be identical or close to it. The forum users would benefit from the greater flexibility provided to the add-on developers and website administrators which should "trickle down" for a better experience.
 
You're going to have to define usability with respect to some group. HMVC would be great for add-on developers as its a more modular approach than what is currently offered. It would allow website administrators to change the way the website looks and functions far more easily than is currently possible. When it comes to the forum users there would essentially be no real difference between a stock install of an MVC or HMVC version of XenForo. The HTML, CSS, and Javascript would be identical or close to it. The forum users would benefit from the greater flexibility provided to the add-on developers and website administrators which should "trickle down" for a better experience.
Well as an addon developer myself, I have not run into anything in XF that needed an extra layer of abstraction in order to do it. Most likely an extra abstraction layer is just going to slow things down slightly since things would need to pass through that layer as well.

I could be wrong of course, but can you think of anything that you need an HMVC type abstraction in order to do it from a developer standpoint? The only thing I can see it being useful for would be admins that don't want to do any development or muck with their HTML... they could just move blocks around... but again, that would come at a cost of increase overhead/resources needed.
 
Most likely an extra abstraction layer is just going to slow things down slightly since things would need to pass through that layer as well.

Of course, which is why I included this in my original post. Now without making a prototype implementation of this suggestion I couldn't tell you much beyond a complete guess. Object allocation and deallocation would almost definitely be increased. Method call overheads may or may not increase depending on the situation. There are plenty of optimizations XenForo does to mitigate the cost of using an object-oriented MVC architecture, I'm sure similar things could be done for an HMVC architecture.

I could be wrong of course, but can you think of anything that you need an HMVC type abstraction in order to do it from a developer standpoint? The only thing I can see it being useful for would be admins that don't want to do any development or muck with their HTML... they could just move blocks around... but again, that would come at a cost of increase overhead/resources needed.

There's really nothing you can't do currently, or with any other architecture or programming paradigm for that matter. Having said that doing some things could be a difficult in one and much easier in another. For instance making an add-on for vBulletin 3 and 4 (at least early on, haven't touched it in a long time) was quite annoying for me. When I did a few things in XenForo it almost felt like I was cheating since XenForo abstracts away so much and does a lot of the heavy lifting for me.

I believe this benefits programmers the most. They would see a very direct benefit from this change and since HMVC is just MVC with more triads (and a structure of course) the learning curve would be fairly low switching over. Website administrators could get a lot of nifty new features because of the benefits for the programmers (either official or third party). End (forum) users would receive an indirect benefit of having a more enjoyable experience on your website.

Perhaps I'll try working on a prototype to show a few of these things off.
 
Top Bottom