Skip to main content ↑ ↓
Topic: Template callback functions only for themes? (Read 3611 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Template callback functions only for themes?

I see the handy call_template_callback() is used in a few template files - are those meant to also be something addons/mods can tap into as well? Or is it just for the theme?

If its meant for addons too, it would be good if it had a "generic" html skeleton...so a theme could change its "skeleton" for a different HTML output, but still show the requested info. As its now the smaller th_ subtemplates are hardcoded with the needed HTML...I am going to change that to a "skeleton" so its bit more versatile should I need to change it for a theme(or even change it depending on medium or theme options/variants), but wanted to know your guys plans with it. (if any, beyond what it does now)

Re: Template callback functions only for themes?

Reply #1 –

Pardon me..I didn't study it close enough. :)

I see it does indeed work with addons. But it still be useful to have a skeleton function, preferably specific to the template(index.template would have its own, Boardindex.template another).

The problem now is that existing addons (or core functions that use the callback) would already be using hardcoded html in them...

Re: Template callback functions only for themes?

Reply #3 –

Its similar to that. :)

Let say I want the search and login to appear somewhere else, like in a grid. I need to call those functions separately and your solution works there: empty the login and render your own login. But I also need to render the remaining functions(from addons etc) in a third place. I also need to surround those each with some HTML code.

Ended up with expanding the callback function:
Code: [Select]
/**
 * Simplify the use of callbacks in the templates.
 * @param string $id - A prefix for the template functions the final name
 *                     should look like:
 *                     template_{$id}_{$array[n]}
 * @param string[] $skeleton - The framing for HTML, themes should be 
						able to frame the content as they need:
						'pre' => HTML code before the output of the function
						'post' => HTML code after
 * @param string[] $array - The array of function suffixes
 * @param string[] $find - Array of specific function suffixes to fetch
 * @param bool $filter_out - false: keep only the specific functions, true: remove the specific functions
 */
function call_template_callbacks($id, $array, $skeleton = array('pre' => '', 'post' => ''), $find = array(), $filter_out = false)
{
	if (empty($array))
		return;
	
	if (!empty($find))
	{
		if ($filter_out)
		{
			$b = array_diff($array, $find);
			$array = array_values($b);
		}
		else
			$array = $find;
	}
	
	foreach ($array as $callback)
	{
		$func = 'template_' . $id . '_' . $callback;
		if (function_exists($func))
		{
			if (!empty($skeleton['pre']))
				echo $skeleton['pre'];
			$func();
			if (!empty($skeleton['post']))
				echo $skeleton['post'];
		}
	}
}

It adds 1) optionally render one or more specified functions and 2) render all functions, EXCEPT those specified functions, and finally 3) adding some HTML on the spot, which allows my theme to encapsulate each one with needed code.

In this way I can keep the most of original functions and new ones can be added in the format already established. I don't want to rewrite potential addon's/mod's callback functions, and this solves that. :)

Re: Template callback functions only for themes?

Reply #4 –

Ahhh, okay in that sense!

Re: skeleton - actually, while writing the code at the time, I think I was planning to add a container around the blocks, but then either I forgot or changed my mine for some reason, something like:
Code: [Select]
	foreach ($array as $callback)
	{
		$func = 'template_' . $id . '_' . $callback;
		if (function_exists($func))
		{
			echo '
			<div class="template_callback" id="', $id, '_', $callback, '">';
			$func();
			echo '
			</div>';
		}
	}
Something very simple, but it should have been enough for most of the styling needs, and considering the call_template_callbacks is in index it would be easy to change for any theme.
Yes, in case of special needs like different "containers" for different areas it would require to create a new function... true.


Re: filters - that reminds me something I think I proposed a while ago for the button strips I think. Yes, it would quite make sense in most of these... "aggregation of stuff" (menus, buttons, "blocks", etc.).
I would love to see something more organic and homogeneous, but things can always be improved. :P
Bugs creator.
Features destroyer.
Template killer.

Re: Template callback functions only for themes?

Reply #5 –

It would be great if things are what they are primary meant for I think..if button_strips is meant for buttons, while it could contain other things too, its much more reliable for themes that it contains just buttons.

If blocks and stuff are meant to be injected , its very important that theme are "aware" of it - just to be able to render things correctly for different mediums. So I would rather  have a hook for HTML code and a separate hook for just buttons, rather than 2 hooks that can do both.

Suki replied in a topic on SMF that hooks aren't really bound by anything, you can do anything really(which of course is true). But again, from the themers perspective - and user's experience dictated by that themers ability to show the best theme possible - its bad news to never be quite certain what will appear from the hook.

I favor hooks that do one thing only, and do it consistently. :D Thats the only way themes can thrive, being at the end of the processing chain. 

Re: Template callback functions only for themes?

Reply #6 –

I'm not sure where you pick the button_strips meant for two things in my comment, but okay. :P

What I said is: I remember I proposed a solution similar to yours, but applied to button_strips. Nothing less, nothing more. ;)

Of course hooks are (should be) as much specific as possible. On the other hand, there are few that are meant to be wide enough to let you "hack"  things when there is no specific hook for them (e.g. all the action_something hooks for example).

Regarding the processing chain, when it comes to presentation, I have always seen it that way:
1) core,
2) addons/themes,
3) admins,
4) users.

That should be read that way: the core gives a default "good for everything" structure just because anything has to have a structure, addons can change this structure adding/removing/altering, themes could "decide" where things are shown (e.g. giving multiple placements for menus or buttons, etc.), but still giving addons the option to pick a preferred one (if it makes sense, if an addon wants to show a particular button in a position the theme should consider that need, unless it's impossible for other reasons[1]), then it comes the admin, because he is the one that has to build the website the way he wants it[2], and finally, it is the end user that is actually browsing the site that can decide (to a certain extent) where he wants to see things[3].

[/emanuele's ideal world]

 ;D  ;D
1 This sort of mutual agreement is needed because both addons and themes don't really know what they actually have to do, so they should cooperate in finding the most appropriate way to present what available.↵
2 Sorry, it's neither core developers, nor themers, nor addon creators the ones that have the power to decide how the admin should present his website, we can give ways to achieve things, but the final decision is in the admin's hands.↵
3 This is an option layer, actually. On certain cases it makes sense to let the end-user decide how to look at the website the way it was in the old days (do you remember the portals letting you move around blocks and stuff?), of course, in other cases, it's not possible/worth (e.g. in case of ads or menu entries, I don't see an admin let the members move the ads to the bottom of the page and I don't see members thinking of reorganizing the menu/buttons around to suite their needs).↵
Bugs creator.
Features destroyer.
Template killer.
 

Re: Template callback functions only for themes?

Reply #7 –

nods Exactly what I meant. :) Collaboration is the key.

As for admin/users I agreed they come after addons/themes..but they are more the "client" in my mind. If the theme hasn't done its job, building on what the core/addons supply, then the admin and lastly, the user(s), will be one unhappy customer(s)...

No, I don't think you said that button_strip should have "everything" - I think I misread it a bit - and anyway, I was probably thinking about that comment by Suki, which struck me as something a dev should not say. At least if the things you just described about specificity is important.