View extensions do not recieve view triggers

When I extend an existing view with

elgg_extend_view('original_view', 'my_view');

and afterwards I set up a trigger on my new view extension

elgg_register_plugin_hook('view', 'my_view', 'my_handler);

The 'my_handler' function will not execute when 'my_view' gets displayed.

If this is intentional, then all is well. If this is a miss, I'm happy to provide a fix on github.

 

 

  • register_plugin_hook() is deprecated @ 1.8

  • This change would definitely hit performance a bit. Given that the extending view almost always under control of the author of the hook handler, I'd lean towards leaving it as-is: register for [view, original_view] and alter my_view by adding logic to its PHP file.

  • @Dhrup: Beg your pardon? I said elgg_register_plugin_hook() :)

    @Steve: very valid point. I had a quite specific use-case, I guess I'll just have to handle that without hooks.

    Though I'd love to hear one of the core devs on this as well.

  • What's the use case? Would it help if elgg_view passed the view handler a list of views that were used for rendering? Like [extending_view_499, original_view, extending_view_501]?

  • ;-) Aww - heck - excuse mois ! I was not reading that code straight ! I guess I did a 'deprecated error' on my own eyes ;-) => Let me take my brains out of the over-night packaging! subtract  my bad eye-sight (for today) - Your point is valid - I might do some more code research later; but... sounds like Steve's point re: performance might be the issue. Also -- the '..Control of the Author of Hook Handler' that would worry me some as well..

     

  • Ok folks, just did some statistics, and on an average Elgg page (give or take) there are about 10x more views invoked than view extensions. This, of course, might drastically change with installed plugins, but still indicates that including view extension in the hook trigger would not be that heavy on performance.

    The use case is roles. We (Arck Interactive) had a stab at a general implementation for user roles, which is almost ready to be released in the community. As our roles implementation uses built-in triggers and event listeners to implement granual access, it is quite crucial for some of our permission definitions that every (base or extended) view will generate the appropriate view hook trigger.