Not planned XF2 - Make all Page-Elements Widgets: give us complete layout freedom

Alpha1

Well-known member
If all page elements / blocks would be widgets, then we would be able to order all page elements in any position we like. Not just sidebar blocks, but any page element.

This will allow us to place any block anywhere.
We could reorder page elements to our liking and easily create unique pages.
It will also allow us to easily turn page elements off by deactivating the widget.
Or replace a page element by sticking a new widget on the same location as the deactivated widget.

Please consider to add this feature, as it will greatly enhance xenforo as a whole.
 
Upvote 33
This suggestion has been closed. Votes are no longer accepted.
I wished for this a long time ago. :)

I would love to have the entire XenForo (2.x) nothing but widgets. :)
  • Define a route, configure a layout for it, and add widgets of your choice in it.
  • Customize the style globally, overwrite it with route level styles, and widget level styles respectively.
  • Every widget does one thing and does it well. Data provider modules can be shared or each widget can have its own data provider in place.
  • Default installation can ship pre-configured to mimic the current functionality, layout, and components.
 
That's exactly what BEM enables you to do. But I guess that's not possible globally, since some variables are passed from one template to another. In any case, this gets my vote.
 
If all page elements / blocks would be widgets, then we would be able to order all page elements in any position we like. Not just sidebar blocks, but any page element.

This will allow us to place any block anywhere.
We could reorder page elements to our liking and easily create unique pages.
It will also allow us to easily turn page elements off by deactivating the widget.
Or replace a page element by sticking a new widget on the same location as the deactivated widget.

Please consider to add this feature, as it will greatly enhance xenforo as a whole.
Love the idea
 
While I like the idea, unfortunately I'm going to have to call this "not planned". This just isn't technically viable within the context of "ALL page elements". There's some overlap in reasoning with my response to an unrelated suggestion, but the reasons here are likely more fatal overall.

Widgets are essentially self contained units on a page. This works really well when what you're displaying is an independent unit, but the reality is that, despite appearances, the individual sections of a page aren't necessarily that independent. They may depend on multiple variables. For example, the behavior of quick reply depends not only on the thread being viewed, but the specific posts that have been displayed. Even the URL for behaviors is a form of dependency; if code assumes that you're viewing a thread when something happens, doing that elsewhere will invalidate that assumption. It might actually require all sorts of variables to be passed in to cover eventualities.

This doesn't handle the fact that we also need to change how we fetch and access data as doing it outside the widget (in the controller) limits the advantage of using a widget. This then rather significantly changes the entire access structure of the code. Being able to pass in all these params in a consistent way, when it wouldn't be known whether it makes sense to a widget or not (or how the widget will interpret it), is a significant problem.

So essentially, IMO, there are fundamental technical problems with this even getting off the ground. Further, it would likely make developing anything (add-ons or core) a good bit more complex because of increased configurability, especially as the widget gets more complex. A great sounding idea, but unlikely to ever come to fruition.
 
If we change the context from "ALL page elements" to "As many as possible", would that make it a viable suggestion?
Likely not, since "as many as possible" would likely more represent "a few very specific situations", which I don't think is what you mean.
 
Back
Top Bottom