Skip to main content ↑ ↓
Topic: Template layers (Read 4745 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Template layers

Does Elk still use template_layers to allow adding say site_above and site_below for integration with non-forum content?

Re: Template layers

Reply #1 –

Yep, pretty much.
To add layers, there is a (singleton) "class": Template_Layers.
There is a bit of documentation here:
https://github.com/elkarte/Elkarte/wiki/Template-layers

Though I just noticed the documentation doesn't cover "how" to actually use the class... :-\

Well, quick&dirty:
Code: [Select]
$template_layers = Template_Layers::getInstance();
$template_layers->add('your_layer');
The "add" method supports also a "priority" parameter that allows you to a certain extent to define "where" the layer should be placed, for example:
Code: [Select]
$template_layers = Template_Layers::getInstance();
$template_layers->add('first_layer');
$template_layers->add('second_layer');
"first_layer" will be the external one, while "second_layer" will be the internal.
Instead:
Code: [Select]
$template_layers = Template_Layers::getInstance();
$template_layers->add('first_layer', 50);
$template_layers->add('second_layer', 500);
"second_layer" will be the external one (higher priority), and "first_layer" will be the internal one.

There are also some more methods that... well: http://elkarte.github.io/Doc/class-Template_Layers.html ;D
Bugs creator.
Features destroyer.
Template killer.

Re: Template layers

Reply #2 –

Does anyone in the Elk team have plans to replace this outdated 'layer' crap with a decent flexible skeleton system, like in some other software I won't mention..? :P

Re: Template layers

Reply #3 –

Actually there are two views I think.
One is mine that since I'm reading a bit about Java I'm leaning towards things able to draw themselves plus some kind of "layout manage" put "somewhere" (I haven't wrote a single line of code yet, so just an idea that I'll probably not be able to develop lol), and @groundup that instead is suggesting another approach with a different kind of flexibility https://github.com/elkarte/Elkarte/pull/1414
Bugs creator.
Features destroyer.
Template killer.

Re: Template layers

Reply #4 –

Quote from: emanuele – Actually there are two views I think.
One is mine that since I'm reading a bit about Java I'm leaning towards things able to draw themselves plus some kind of "layout manage" put "somewhere" (I haven't wrote a single line of code yet, so just an idea that I'll probably not be able to develop lol), and @groundup that instead is suggesting another approach with a different kind of flexibility https://github.com/elkarte/Elkarte/pull/1414
A different kind..? It's just a subset of Wedge's template system. It needs more if you want to make modders enthusiastic. Otherwise they'll just keep editing template files anytime they find a place they can't easily change.

Sorry, I feel like I'm an ayatollah... I probably am.
And ema, if you have any answer to any point in my index.php topic, please feel free to answer just that one... ^^ oh also, I sent you a great pm yesterday but the pm system was broken for most of the day... :(

Re: Template layers

Reply #5 –

I wouldn't call it a subset because I have no idea WTF Wedge's template system looks like.

Re: Template layers

Reply #6 –

Well there's a skeleton.xml file which holds a pseudo-xml tree of tags. Each of these tags represents a block. Each block can either be empty (in which case it maps to a template_block_name function), or hold other blocks/layers, in which case it acts as a placeholder. Any block or layer can be overridden or code can be executed before or after them. You can even override a 'before', or write 'before' an 'after', etc. In addition to this, there's an api for manipulating blocks: move, rename, remove, surround, add, etc. You can also declare sub-skeletons -- for instance, each topic post uses a skeleton of its own. There are more features but I'm doing this from memory.

Actually, the only problem with such power is that it can be scary at first, even though I went through many rewrites to ensure it was easy to do any skeleton manipulation any want you want. (Either through php, or a pseudo-xml command that maps to the php api.)

Thus the reason I can't comprehend the point of layers in SMF terminology. You can only have Russian dolls of layers. Not an actual tree. It's so limited... :(

Re: Template layers

Reply #7 –

You can define the template as a tree. You don't need _before/_after(). Actually, it wouldn't even be a tree. A tree can go off in multiple ways at the same time. Neither yours nor Elkarte's or SMF's can branch off in two ways. It needs to have 1 path that goes forwards and backwards. They are stacks.

Yeah, my changes implement pretty much the exact same thing as yours but it doesn't have an XML file from the beginning. You just work with the templates with events.

Re: Template layers

Reply #8 –

But then you have to work within the constraints of templates. You can't move a block of HTML around without resorting to js or a copy of the template. Meaning mods can't do it without modifying the php files themselves... :-/

Re: Template layers

Reply #9 –

You'd use the hooks to add a template before/after a template and then you can also prevent that template from being executed. Works the same but it doesn't require learning a different format. In your mod, you'd register a new hook "template_infocenter__execute" which would return false. That prevents the infocenter template (or whatever it is called) from executing. Then you would add one called "template_infocenter__pre" which would output a different infocenter template. Or instead of registering another hook (listener), just call the template you want in there. Or, with my other option, where the themes are classes, you'd register a different template and all of the subtemplates could be overloaded.

My plan for the event system is to make it pretty much like Symfony EventDispatcher.

Two topics for your reading:
Theme/template class: http://www.elkarte.net/community/index.php?topic=832.0
Hooker: http://www.elkarte.net/community/index.php?topic=1049.0

Re: Template layers

Reply #10 –

I'm afraid I don't really see how this is superior or even on par with my skeleton system in terms of flexibility.
I hope for elk that it is, though. It would be a shame if modders dropped it for that even though it has plenty of goodies for them. The reason I wrote the skeleton system was because I needed it. Maybe I'm too demanding or lazy as a modder. I dunno.

Re: Template layers

Reply #11 –

I don't know anything about your system so I can't compare.

I don't understand how you can't see that by using $theme->template_call('template_name', $parameters); and registering an event listener for 'template_name__exec' gives you the maximum amount of flexibility because you essentially control every template call there is. You can completely change the entire theme by only using events. The event system contains priorities so you can even prioritize which templates are called first.

Oh well, that's why there are a multitude of forks. So people can go off and do things differently.

Re: Template layers

Reply #12 –

I guess it's not a bad idea to allow for hooks to cancel the execution of the 'default' template, but usually that'd be because you want to replace it with something else, in which case 'override' is all you want. And template_call() doesn't seem to account for the possibility of wanting to override an override. Maybe it's a silly idea, but I've accounted for it because, again, I needed it at some point. (Although I changed my mind after that, but had no reason to remove that.)

Re: Template layers

Reply #13 –

In a future version it will use the event system that I showed elsewhere. That allows for priorities and propagation stop which allows you to do all of that with ease. You can always override an override though. More difficult, but still possible. I wouldn't advise it just because you don't know the outcome, but I can think of two ways: use output buffering to capture the output and throw it away or have your event listener (hook) remove the other listeners on that event.