Widget Sytem Improvements

[Kirby]

The widget system is great, but I still think there a few (simple) things that could make it even more awesome:

Allow users to override the template
Doing this would allow to use the same widget definition in various places possible having completely different looks

Caching
Some widgets might benefit from caching, so if the base class would already offer caching functionality this would be a plus

Permissions/Usergroup Selection
Sometimes it is desirable to show certain widgets to certain users/uergroups only.
For example their could be a "Unread Posts in Staff Forum" widget,.
As it is right now the widget would (uselessly) query the data for every visitor and end up with "You have no unread posts." for everyone (except staff).

 

[RobParker]

Can't the permission stuff be done with template conditionals?

Yeah it's not as nice but it's possible.

Very strongly agree about caching, that could make a massive difference if implemented.

 

[Kirby]

Can't the permission stuff be done with template conditionals?

Not really. You can hide the output, but it would still run the code to generate it which is wasting resources

 

[Alpha1]

Can't the permission stuff be done with template conditionals?

I dont think the minimum requirements for buying xenforo would need to be that you are comfortable with template edits.

 

[Mike]

Just in regards to caching: we discussed this beforehand, but we didn't believe there was anything that should really be implemented at a general level. The only thing that is really cacheable there is HTML output, which is not really appropriate as a generic cache element (this would vary per user and per style). Beyond that, anything cacheable is widget specific. We wouldn't recommend caching entity data (and we have blocked direct caching of entities by blocking serialization of them), so at that point, you should really just be caching IDs, but then you need to potentially take into account varying user permissions, so you should be overfetching and filtering down when you get the data...

So yeah, if caching is desired, it'd best be done within the entity, likely using the standard caching framework.

 

[RobParker]

Just in regards to caching: we discussed this beforehand, but we didn't believe there was anything that should really be implemented at a general level. The only thing that is really cacheable there is HTML output, which is not really appropriate as a generic cache element (this would vary per user and per style). Beyond that, anything cacheable is widget specific. We wouldn't recommend caching entity data (and we have blocked direct caching of entities by blocking serialization of them), so at that point, you should really just be caching IDs, but then you need to potentially take into account varying user permissions, so you should be overfetching and filtering down when you get the data...

So yeah, if caching is desired, it'd best be done within the entity, likely using the standard caching framework.

Still curious about this if you have a chance to elaborate.

From a non-developer point of view I've always considered caching to be important (vital?). For XF1 we used XenPorta and without the block/widget caching our site performance was awful but sticking a 5 minute cache on the blocks made a huge difference.

I appreciate some things can't be simply cached (for example, when different users have different permissions) but surely caching as much as possible is a good thing?

 

[Jaxel]

Still curious about this if you have a chance to elaborate.

From a non-developer point of view I've always considered caching to be important (vital?). For XF1 we used XenPorta and without the block/widget caching our site performance was awful but sticking a 5 minute cache on the blocks made a huge difference.

I appreciate some things can't be simply cached (for example, when different users have different permissions) but surely caching as much as possible is a good thing?

It really depends on what widgets you were using. Widgets that fetched data from outside sources using cURL or things like that, greatly benefitted from caching. When I built XenPorta for XF1, I made the decision to make caching a general feature of the widget system itself. So every widget had the same caching mechanisms.

XF2's widget system doesn't do this. This of course doesn't mean you CAN'T cache things anymore... it just means that the caching has to be done on an individual basis, instead of being done on a general basis within the entire framework. It really doesn't change anything... as any widget which needs caching, would still have it. The creator of the widget just needs to program for it themselves.

 

[Jaxel]

I understand why the XenForo team does things the way they do. They do things for the purpose of general use... to make things easier for the average end user. When I made XenPorta for XF1, everyone who made a widget, needed to understand the difference between cached data and uncached data. It created a barrier of entry that most people couldn't mount. So many people asked me for widgets, and I always asked "why can't you make that widget yourself?"... well most people don't have the innate programming knowledge needed, for even basic stuff.

With XF2, to make a widget, you really don't need any programming knowledge at all... if you want to make a widget with caching mechanisms, that's when you need programming knowledge. And if you're interested in that kind of stuff, chances are, you already have the basic knowledge needed to get it done... without being a hindrance on others who don't.

 

[Robust]

@Jaxel Off-topic note, I feel like a lot of developers (not just in XF, but in general, and just as common with very experienced ones too) miss the point you mentioned in paragraph 1. After really realising that, a developer can significantly improve the quality and end user experience of their products.