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

Re: Template layers

Reply #15

Yup. And so it was with us too, the road Elk is walking down is much the same as the path we took ourselves. First making it so that you don't need both the _above and_below pairs (but not changing flow order), then allowing multiple items in the main area, and ultimately turning into the beast you see before you, which is really only an extension of the concept of template layers, just taken several steps further.

I suggest it here mostly as a 'we had the same problem, this is what we did, perhaps it is of use to you to consider this direction, though I suspect you'll find your own path that does its own bold and imaginative thing'.

Re: Template layers

Reply #16

Hey there...

What needs to be understood, is the basic concept through which I wrote the skeleton system.

Everything is a layer.

A 'layer' is a container. You can put anything you want in it: an assortment of layers and blocks. You can also define _before and _after functions for a specific layer.

A 'block' (aka sub-template in SMF terminology) is a self-closed layer (those that are defined through <layer />), and executes the template_block function. If template_block_before and _after exist, they're run too. (It's not _above and _below in Wedge, because you could just as well show the 'before' block AFTER the main block, with CSS floating, grid and flexbox or other tricks...)

So, a layer either contains other elements to be parsed, or a function to be executed. It's as simple as that... And works much better than the very weak layer system in SMF.

Not that I'm suggesting that Elk uses the same system... I like that we each have our own sets of exclusive features to boast about :P But since Pete was discussing it... I might as well join the conversation, eh?

Re: Template layers

Reply #17

See, even I don't understand the subtleties at times laughs

This is what I like, that the different ideas and explorations are being shared around - and everyone benefits. We share our experiences, Elk shares theirs, and we both end up benefiting out of it :)

Re: Template layers

Reply #18

Quote from: Arantor – See, even I don't understand the subtleties at times laughs
Oh, that's why I figured it'd be best explained by saying it's just an assortment of layers...
It's hard to explain mini-skeletons, though...! Because they requirement code to be run multiple times. (Which is the whole point of them -- a mini-rendering system to be able to change the structure of a post, or whatever else that shows up multiple times in a page, and, should I say, not on all pages, either...)

QuoteThis is what I like, that the different ideas and explorations are being shared around - and everyone benefits. We share our experiences, Elk shares theirs, and we both end up benefiting out of it :)
Well, I dunno, I think I liked lurking on the Elk forums because I didn't HAVE to answer anything, unlike the Wedge forum where I feel really bad when I don't comment a topic, and I don't always have time to jump into long talks with you...   ;D

Re: Template layers

Reply #19

Or, you know what be a lot nicer than writing yet another template system? Using a pre-existing one. I am partial to handlebars (and it compiles to the root language so it is quite fast). The current system could have templates under the theme's control if the themes were made as classes and used an autoloader or use some naming conventions and create your own procedural autoloader via something like function showTemplate($template) { // break down the name and find what file to load }

Since the "theme" is the view in Elk/SMF architecture, you could allow the view to make those changes and not be "wrong". If you implemented a proper MVC architecture and abstracted the template system from the view, it would be very wrong to do "layer" manipulation at the template level.

Re: Template layers

Reply #20

I love your little sermons about how everything is wrong and that you know best. What we have and what was suggested is merely one option. It is an option that works very well for us and does exactly what we want it to do and meets our requirements in terms of things like plugins.

When you've actually implemented what you're talking about, and can demonstrate it in practical use, come talk to me.

Re: Template layers

Reply #21

Fair 'nuf. Though, I wasn't talking about Wedge or what was already done. I was talking about the possibility of writing yet another template system here.

Re: Template layers

Reply #22

lol, I am not voluntaring writing/converting a new template language. I like the SMF's system, which Elk(is that the new acronym? :) ) wants to expand upon, and Wedge already have.

It would not be nicer either...because I'll assume you want existing SMF users to join onboard your new system? You better make something they can convert their old SMF systems from then, AND be able to figure it out too when they want to change their themes.

But Arantor is right about different ideas etc. Its up to each participant here how to use the exchange of thoughts, I know I have found renewed interest and ideas by it. The good thing (so far at least) is that we are staying within the SMF legacy, in varying degrees. That means we talk the same "language". :)

Re: Template layers

Reply #23

Quote from: groundup – am partial to handlebars (and it compiles to the root language so it is quite fast).
Requires JS...

Quote from: Bloc – lol, I am not voluntaring writing/converting a new template language. I like the SMF's system, which Elk(is that the new acronym? :) ) wants to expand upon, and Wedge already have.
Yeah, Wedge builds upon SMF's system, because I improved the existing system instead of rewriting it, although it's very different now; but the rendering code is still similar.
Elk is the name we all give to ElkArte, I think...
I don't know where that name comes from, anyway... Elk? It's a tree, right? Arte? It's Art in Italian, or something..? What's the connection? It doesn't even sound good... I thought that 'Dialogo' sounded much, much nicer...

QuoteIt would not be nicer either...because I'll assume you want existing SMF users to join onboard your new system?
I'm sure they do... Elk, after all, is pretty much SMF 2.2... Same development team as SMF 2.1, right..? Only with new names, to get away from the SM board's influence... (I'm not exactly sure what's the point of maintaining both in parallel, at this point...)

QuoteYou better make something they can convert their old SMF systems from then, AND be able to figure it out too when they want to change their themes.
Conversion is critical, indeed. Even Wedge supports converting from SMF 2.0 (not sure about Elk, probably not; ask TE what he's up to on that front...), although themes will definitely need an overhaul, and mods need a complete rewrite. Oh well, we could afford that, couldn't we..? (At least 3 years ago... Wedge is getting a bit old to afford NOT being documented right now... My bad :P)

QuoteBut Arantor is right about different ideas etc. Its up to each participant here how to use the exchange of thoughts, I know I have found renewed interest and ideas by it. The good thing (so far at least) is that we are staying within the SMF legacy, in varying degrees. That means we talk the same "language". :)
SMF is a good basis to work on.

Re: Template layers

Reply #24

Quote from: Nao – Conversion is critical, indeed. Even Wedge supports converting from SMF 2.0 (not sure about Elk, probably not; ask TE what he's up to on that front...),
Sure, Elk will be supported, too....
Thorsten "TE" Eurich
------------------------

Re: Template layers

Reply #25

As far as theme portability is concerned, no-one worries about SMF themes not working in IPB or XenForo themes not working in SMF, for example... or even YaBB themes not working on SMF... so why should we worry about keeping compatibility as such?

Re: Template layers

Reply #26

Ok, had some inspiration to code in some of the ideas discussed here in my fork project. I landed on a two-way approach though, with Boardindex as an example I converted that to 3 extra layers (newsfader,boards and infocenter)and made it such that layers don't need "above"/"below" - and that they are added to an array, easily accessible to mods. I also added a plugin option where a plugin can specify which layer it wants to be inserted after(need to write an interface for adding plugins now lol). Since the major templates will have a above/below first, there's no need for inserting it "before" a layer,only "after".

Next I added a check to see if the theme wants its own layout of layers, which it starts off by adding that layout to the template_init() of for example Boardindex. If it exists it will use that instead of the normal layer array.But, it checks against the layers array to see if any specified by the theme are actually turned off. It also adds plugin specific layers onto a designated area and finally allow the theme with its own custom layers/subtemplate functions. The reason i want this layout option is that I want all subtemplates(which are put in layers) to work on their own, more or less, and by adding the layout code outside of them I keep that versatility. I also use a grid-based CSS so its easy to construct them in the same fashion across themes and sections. If the theme doesn't use a own layout, then it will follow the original ordering of layers, which I also plan to be able to manipulate. But, a layout must not exist or be turned off, for it to be in effect...

For index.template I'm keeping the simplicity of just writing the whole shebang in the existing html/body layers though(with of course linktree and main menu as separate calls) - I feel the need to chop it up is less there than in the other subtemplates, since it stays the same throughout the site.


Re: Template layers

Reply #27

Since the best way to define if something is useful, is to actually use it the way it should, I found my method was pretty weak (at least for how I wanted to use it), so I'm now working on improving it a bit.
Last Edit: May 28, 2013, 04:33:34 pm by emanuele
Bugs creator.
Features destroyer.
Template killer.

Re: Template layers

Reply #28

Yup, there is really no better way to figure out if something really is up to the job is to use it, and to keep trying to push it ever further. ;)