Warning: this is a *very* technical post. It also spoils a lot of things about Wedge's internals, eheh.Quote from Dragooon on March 31st, 2011, 05:31 PM I don't see your point...
Let's take this example. Edit Load.php, loadSubTemplate().
Code: [Select]
Into this...
Code: [Select]
That basically allows us to load any kind of overriding template indicated by the styling (in settings.xml, let's say), and then we can completely override the existing function.
We could also have two other functions: $theme_function_before and $theme_function_after, which would be executed respectively before and after the target template function -- without preventing the original function from being run, allowing themers to insert data easily.
Of course, these functions could be added to each other (e.g. a mod adds a _before function to a template function, and the current function also overrides it -- let's just say themes always have priority over mods so their code is run first, then all mods in whatever order.)
Of course, it's not practical for very specific areas like adding buttons to a strip, but in these cases we always have proper hooks with the list of variables, so mods will use hooks for these, and for areas without a hook, they can use _before, _after and/or _override. Then our job is to simply split template functions into many smaller functions.
...Or we could just add template hooks here and there in important areas of the template, of course.
The solution I gave is just a quick one to allow themers to override any single function without us needing to add hooks everywhere.Quote WeCSS also has the same features and limitations, somehow. Because it's preparsed, it gave me great freedom to develop it into an object-oriented version of CSS, and it made it so much simpler for me to manipulate objects with common parents, it's really impressive... However, it also puts an extra burden when it comes to inherited stylings -- if I want to restyle an object that is already parent to others, but I only want to restyle that particular object, I have to careful consider whether or not I'll specifically prevent inheritance for my rules. All in all, more power also means more complexity. Because most of the important objects in Wedge's CSS are linked to others through inheritance, themers will be required to learn how inheritance works, which is basically the whole point of having extra sample stylings that show how it works.
(And in that respect, I'm really glad I made Wine the main styling and pushed Warm to an inherited styling, because it shows how to... pretty much get rid of all the bells and whistles in Wine, so people don't have to worry about making designs that are too close to Wine. At this point, I could even rework Warm to make it even more removed from the Wine style. Something like WordPress's awful default themes.)Quote Correct me if I'm wrong, but it's only hookable by splitting functions into many, right...? Or does it allow one to take the sub-template's HTML and manipulate it as a string before reinjecting it to Tox-G's parser? Which is the only way I can see for Tox-G to be superior to SMF/Wedge's current implementation...
TBH manually positioning every hook in every bit of template is a very impractical practice, it may seem workable in theory but I don't see it actually working out. Hooks in actual workflow is a lot more sensible and practical thing.
Let's take this example. Edit Load.php, loadSubTemplate().
$theme_function = 'template_' . $sub_template_name;
if (function_exists($theme_function))
$theme_function();Into this...
$theme_function = 'template_' . $sub_template_name;
$theme_function_override = $theme_function . '_override';
if (function_exists($theme_function_override))
$theme_function_override();
elseif (function_exists($theme_function))
$theme_function();That basically allows us to load any kind of overriding template indicated by the styling (in settings.xml, let's say), and then we can completely override the existing function.
We could also have two other functions: $theme_function_before and $theme_function_after, which would be executed respectively before and after the target template function -- without preventing the original function from being run, allowing themers to insert data easily.
Of course, these functions could be added to each other (e.g. a mod adds a _before function to a template function, and the current function also overrides it -- let's just say themes always have priority over mods so their code is run first, then all mods in whatever order.)
Of course, it's not practical for very specific areas like adding buttons to a strip, but in these cases we always have proper hooks with the list of variables, so mods will use hooks for these, and for areas without a hook, they can use _before, _after and/or _override. Then our job is to simply split template functions into many smaller functions.
...Or we could just add template hooks here and there in important areas of the template, of course.
The solution I gave is just a quick one to allow themers to override any single function without us needing to add hooks everywhere.
The thing is, Tox-G adds a lot of possibilities otherwise which I consider to be quite hard doing with pure PHP without actually limiting a designer.
(And in that respect, I'm really glad I made Wine the main styling and pushed Warm to an inherited styling, because it shows how to... pretty much get rid of all the bells and whistles in Wine, so people don't have to worry about making designs that are too close to Wine. At this point, I could even rework Warm to make it even more removed from the Wine style. Something like WordPress's awful default themes.)
I haven't encountered a thing that I can't do with pure TOX-G. But to each it's own, PHP got its own advantages. One of my main motives of advocating TOX-G is because of it's hookable nature,
