Re: Template layers
Reply #1 –
Well...if you remove the above/below requirements, how can one be able to embrace several layers in the templates? Meaning that a theme cannot be certain to fully encapsulate unknown layers simply because there are no "below" function. It may start a embracing div, but where to close it? It can check the layers - but thats a hack really, it should be seamless that new layers start up and close themselves up, so that any later layers are indeed put inbetween. if not then it will just be a list of layers after each other..but no way for say layer "mylayer" to put the next layer(the actual content for example) in a floated container for example.
Unless I misunderstood your intention with this change.
Re: Template layers
Reply #3 –
Could be..I am certain it wasn't meant to cripple it though.
Layers are a heavily underused feature, some mods use it, but I suspect people(or themers that is) don't really know what to do with it(not that they CAN do much other than setting up more layers in the xml file). In the time I've been working with them, I've fallen to the same line of thinking.
Re: Template layers
Reply #4 –
It won't cripple it either.
Part of why it's underused is because of having to do extra work like creating two functions when you only actually need one. If you just need _above, you shouldn't have to declare _below just for it to be empty.
SimpleDesk did it, in a couple of places, and I hated it.
Thing is, though, layers actually are very limited in their current setup because you can only use them to wrap around the main page content. Now consider, for a moment, that every block of content is a layer too. Now imagine the possibilities.
Now go one further, breaking even existing units down. I seem to recall we ended up with over a dozen layers in the post/user information display. If you can insert new layers into that, or juggle them around at will or dynamically include stuff... that's when its real power becomes evident.
Re: Template layers
Reply #5 –
Layers were not explicit made just to wrap around the main content - but to allow mods/extra functions to wrap around each other, like the layers of an onion, with the main content as the innermost layer. The drawback is that the theme don't really know what layers are actually present at any given time(without checking)..but if made correctly they should not need to.
But yes, I understand what you mean about total freedom in shuffling the subtemplates around to change the layout , and possibly inject easily plugin template code without manual changes to the template. For the latter I very much agreed its a powerful feature..but not so sure about the former - for theme makers that is. Not that they can't use/understand it, but rather: do they want to?
Themes are like artwork, you create a perfect look and work hard to get that as optimised to your vision as possible. Imagine then adding the possibility to totally move that perfect layout around - its not something a theme maker would do, not at first anyway, but the admin might love it. So the added freedom is for admin foremost, by that logic, which brings me back to what actually would interest the theme maker - if the goal is to empower them more.
I once thought as you(if I may be as so bold to say so lol) in that the added freedom would be absolutely great. But after working with a home-brewed setup using this, I've landed on other things that are MORE useful than the actual shuffling of subtemplates. That is, the option to control most of the theme markup bits, less "cooked" code that the theme has no chance to change, and to pinpoint just the functions it needs - without changing anything else. The first is not so hard, just loosen the more hardened built-in dependacies, like what javascript library(or at least make things work even if its removed), remove using css from default theme, making sources not rely on specific elements in the templates.. and so on. The other part requires more work, making it possible to target a single function by a naming scheme AND build the default templates in such a way that a long as you use specific css classes, whatever bits you change will work perfectly along with the default bits. Current SMF and it seems: elKarte does not work well in this area, mainly since they rely so much using id's for everything. IMO the use f id's should be reserved for a custom theme, the default should just have them in the templates, but avoid them as much as possible to allow any custom theme to expand upon it. Almost like OOP coding lol. Of course, using multiple classes isn't the greatest idea, but its possible to use more classes but not strip them down too much.
Of course this shouldn't limit the possibility for plugins/mods to inject themselves into templates - meaning it has to combine the two goals in order to enhance current template/theme system. IMO anyway.