add TEMPLATE_DOKUWIKI_PAGETOOLFLOAT_DISPLAY event to template #236
Conversation
This adds a custom event to the 'dokuwiki' template that allows plugin authors to easily integrate custom pagetool buttons into the template.
|
In general it would be very good to have something like this. But there are 3 issues with this approach:
|
|
The name was chosen this way because it's not a core event. It's an event for this one particular template and in there the pagetools float. Other templates will have different pagetools and I wanted to make that absolutely clear. IMHO this should not be in the core. Template authors should have full design control and can decide what and how things are exposed via action hooks. Plugin authors should decide if and which templates they want to support out of the box by implementing the appropriate template specific hooks and implementing the according styles to match the template's design. Additional hooks can be added later. |
|
The page tools only float for you, because you have CSS enabled. And as there are only one set of page tools, there is no harm in dropping the "float". If there is something specific for this template, then I agree, it should only be in this template. But many templates have the tools split up in exactly those categories, because they make sense. Why should a plugin be able to hook into one template and not another? It will get really messy when plugins need to support 50 different hooks which are doing all the same, e.g. I agree that other hooks don't need to be part of this PR. |
|
Sofar i experienced adding the pagetools manually by the wiki administrator as messy. So i like integration in core. But because templates differ, i think that an implementation in the core requires that the images that are supplied should have a default, but that a wider set of template specific images can also be supplied via the plugin ... |
|
The images are template-specific, so shouldn't be set (or be made available to overwrite) by the core. I agree that a generic default image makes sense (even independent of this PR). But template-specific images provided by plugins? Or plugin-specific images provided by templates? Both sound dodgy, although the latter a bit less... And if both provide them, which one wins? |
|
I should prefer configuring images per plugin, so that a plugin manager has only one place to update it. And when the plugin author maintains his/her stuff, it will probably be included in the plugin too. |
|
also made it more secure against copy'n'paste
add TEMPLATE_DOKUWIKI_PAGETOOLFLOAT_DISPLAY event to template
|
Just thinking further about this... Does it make sense to have the same event in main.php and detail.php? I'd say 98% of all plugins would not want to add anything to the pagetools of the detail page. If you'd want to support it, they should get a different name, as those two are not the same... |
This will open up the discussion from #236 again and I'm not sure how to solve this best. The TEMPLATE_PAGETOOLS_DISPLAY event is very specific to the dokuwiki template in theory. In practice many other templates implemented not only the same event but also use the same HTML (and often even the same CSS). Which makes the event more like a core event. This branch now changes the HTML the event expects back from handlers. When merged it would immeadiately break all plugins implementing this event (and by broken I mean the layout/design of the template breaks). Since the expected data changes, I would argue this should be a new event or at least be implemented in a way to not break the design by installing an old plugin and by giving the plugin a chance to know if it's running on the old or the new code. This is what this commit does. By changing the view names, old plugins should not display (because they hopefull do not handle those views) but gives them an easy way to handle the old and new views in one plugin. However, I'm not perfectly happy with it, yet. The way I implemented the new SVG handling is by means of a new class dokuwiki\template\dokuwiki\tpl which provides a pageToolAction() method. Plugins could use this method to easily return the proper HTML for the pagetool items and we could adjust this method later on to make adjustments to the pagetools without breaking anything again. However this method is template specific again. While it would possible for plugins to use this method even when the wiki runs another plugin emitting the event, it would be a bit weird. A better way would be for the event to not expect HTML at all, but instead a data structure of the data currently passed to pageToolAction(). Templates could then decide to implement the event, but still render the data in a completely different way... OTOH this means plugins are no longer free to add whatever they want into the pagetools. We once argued plugins might want to add submenus or other fancy stuff there. But in fact no plugin ever did. If we decide to go this new way of making the event more of a first class citizen of template development, then we would probably have to move parts or all of the tpl class back to the core.
show display value in diffs. fixes #236
This adds a custom event to the 'dokuwiki' template that allows plugin
authors to easily integrate custom pagetool buttons into the template.