This would also mean that CMSPluginBase would also need to have a method for invalidating the cache. The developers writing their own plugins could call this cache invalidating method in post_save hooks.
If you don't find this as being a good idea, what would you guys do for improving the front end view's response time?
> This would also mean that CMSPluginBase would also need to have a method > for invalidating the cache. The developers writing their own plugins could > call this cache invalidating method in post_save hooks.
> If you don't find this as being a good idea, what would you guys do for > improving the front end view's response time?
There's nothing inherently slow within the cms itself. The problem is when you have pages with dozens of plugins the rendering simply takes time.
Most of the times, the problem is within the plugin itself. For example cmsplugin-feed <https://bitbucket.org/yml/cmsplugin-feed>uses the feedparser <http://pypi.python.org/pypi/feedparser/> library that needs around 2s to parse a medium sized rss feed. You can obviously try to improve the performance of each plugin by optimizing parsing algorithms and so on, but that would obviously take a lot of time and it might require forking third-partly libraries.
The easiest way would be to implement caching for each plugin, but then you'd have to write very similar logic in all plugins, so I thought it would be a nice feature for django-cms to offer this feature.
>> This would also mean that CMSPluginBase would also need to have a method >> for invalidating the cache. The developers writing their own plugins could >> call this cache invalidating method in post_save hooks.
>> If you don't find this as being a good idea, what would you guys do for >> improving the front end view's response time?
