Unify themes and mods behaviour?

Unify themes and mods behaviour? Started by emanuele · December 23, 2012, 05:17:10 am · Read 24917 times 0 Members and 1 Guest are viewing this topic. previous topic - next topic

Unify themes and mods behaviour?

December 23, 2012, 05:17:10 am

Moving here as new feature request.

Quote from: emanuele – December 23, 2012, 04:58:40 ammmm...would be scary to "unify" themes and mods and give them (almost) the same powers?
It shouldn't be too difficult, I already changed theme installation to use the xmlArray class (or whatever it is) and some of the packages related functions. Give them the remaining power would allow to unify the interface too and the versioning...

Re: Unify themes and mods behaviour?

Reply #1 – December 23, 2012, 06:12:14 am

Thanks! We've been contemplating this one way or the other for a long time.

Lets see...

Essentially, they are two different beasts: one changes behavior/functionality, the other presentation. That aside. We need to discuss specificities.
What can be brought closer?

[just brainstorming]

# Installation.
Sure. Installers on one side (package manager and theme installer), "drop files and it just works" on the other side (we have some bits, package manager can install from /Packages/package_name subfolder; works for addons following dispatcher patterns and/or hooks)
# Removal.
The forum is good enough without a theme (well it works, and you'll crawl to change the theme), same without an addon that would only use the dispatcher (but that's a simple one or fully external pages), respectively for an extra-subscription (same principle, dynamic loading); it doesn't work for addons based on hooks even.
# Package manager and theme installer.
At the level of code: make them a single installer.
At the level of behavior: for a mod with files in a subdirectory of /Packages, respectively for a theme added manually to /Themes, can we unify behavior of the installer.
Extra-functionality. Package servers for themes.
# Versioning...
Two issues: make theme installer recognize and compare version of the forum with the version the theme works for; and, versioning system for themes (recognize an update, install it).

A few more questions.
# Do themes use hooks? Is it recommended to?
# Do we need or want template hooks?

Re: Unify themes and mods behaviour?

Reply #2 – December 23, 2012, 07:32:21 am

Pre-question: will addons (is that the name of mods for D?) be allowed to edit files as in SMF or will they just use hooks and similar things?

Re: Unify themes and mods behaviour?

Reply #3 – December 23, 2012, 09:06:57 am

TestMonkey didn't realize this question may be asked for the next version... and it's surprised that Ema asks it.

My personal take: I think it's obvious for 1.0 it's supported just like any SMF mod. ('tis not on the roadmap either). I think it's the almost the same for 2.0, from my perspective. (don't shoot me, please remember I'm hardwired in a two-versions-ahead mode atm, lol, the other topic stretches it). I can see the possibility it will change for 2.0, for all or a part of the core software.

But I don't know about many of the details or intentions you folks have so far. And, you can always change it when I ain't looking, hey.

It's a feature of package manager, and while it's not making me happy (in a way), it's our current most used "extensibility mechanism" (yeah it's not "extensibility"), and it works. Why would we change it, soon?

Re: Unify themes and mods behaviour?

Reply #4 – December 23, 2012, 02:06:27 pm

Quote from: TestMonkey – December 23, 2012, 06:12:14 amThanks! We've been contemplating this one way or the other for a long time.

Lets see...

Essentially, they are two different beasts: one changes behavior/functionality, the other presentation.

You just made your first mistake. In fact, it's common for themes to change functionality and it's common for mods to change presentation. The boundaries between mod and theme are a bit blurry sometimes.

QuoteThat aside. We need to discuss specificities.
What can be brought closer?

[just brainstorming]

# Package manager and theme installer.
At the level of code: make them a single installer.
At the level of behavior: for a mod with files in a subdirectory of /Packages, respectively for a theme added manually to /Themes, can we unify behavior of the installer.
Extra-functionality. Package servers for themes.
# Versioning...
Two issues: make theme installer recognize and compare version of the forum with the version the theme works for; and, versioning system for themes (recognize an update, install it).

That all sounds pretty good as a starting point (haven't thought about it in great detail). Something like this has been talked about for ages, and in general I think it makes sense.

QuoteA few more questions.
# Do themes use hooks? Is it recommended to?
# Do we need or want template hooks?

If by the first you mean "Should themes rely on hooks for any template changes they make to default?" then I would very definitely say "No." In fact, if you go down that route I would have no interest in working on such a beast.

If you mean "Should custom themes include, as far as possible, any hooks which are also in default templates?" then sure, that makes sense.

Re: Unify themes and mods behaviour?

Reply #5 – December 23, 2012, 02:08:03 pm

Quote from: emanuele – December 23, 2012, 07:32:21 amPre-question: will addons (is that the name of mods for D?) be allowed to edit files as in SMF or will they just use hooks and similar things?

They should be allowed to edit files, but they should also avoid it as much as possible. Again, if you totally disallow editing of files then I'm out the door.

Re: Unify themes and mods behaviour?

Reply #6 – December 23, 2012, 04:22:41 pm

Quote from: TestMonkey – December 23, 2012, 09:06:57 am
TestMonkey didn't realize this question may be asked for the next version... and it's surprised that Ema asks it.

emanuele likes to ask innocent questions...

Quote from: TestMonkey – December 23, 2012, 09:06:57 amBut I don't know about many of the details or intentions you folks have so far.

Me neither and that's why I asked!

Quote from: TestMonkey – December 23, 2012, 09:06:57 amIt's a feature of package manager, and while it's not making me happy (in a way), it's our current most used "extensibility mechanism" (yeah it's not "extensibility"), and it works. Why would we change it, soon?

Good.

Quote from: Antechinus – December 23, 2012, 02:06:27 pm
QuoteEssentially, they are two different beasts: one changes behavior/functionality, the other presentation.
You just made your first mistake. In fact, it's common for themes to change functionality and it's common for mods to change presentation. The boundaries between mod and theme are a bit blurry sometimes.

In theory the separation should be very well defined.
Unfortunately with SMF is not.
The theory is: you want to create a theme with new functionality? You create a mod and you create a theme that works with that mod.

But: I have to partially agree with Ant and I feel a mod with a template is somehow not so different from a theme with an addon.
Yes, the mod shouldn't replace an entire template, but at the moment nothing forbids them to do so.

So another way to ask my question is: how far we want to push the distinction "for now" (see the end of the post)?

Quote from: TestMonkey – December 23, 2012, 09:06:57 am# Do themes use hooks? Is it recommended to?

I think themes should be encouraged to use some of the available functions.
What I have in mind at the moment more than anything else is loadCSSFile and loadJavascriptFile (and equivalent for inline js and js variables).
Unfortunately at the moment I don't think it's so easy (themes can use them easily, but if they have to load something on a specific action it could be annoying).
Not sure of other ways to "use hooks" in themes.

Quote from: TestMonkey – December 23, 2012, 09:06:57 am# Do we need or want template hooks?

Depends on how they would work.
A thing I like (and I used in some of my mods) is the custom fields system: in other words I add something to $context['custom_field'] (or whatever it is) "source-side" and these things are displayed somewhere in the template with a predefined style.
But I would avoid the use of call_integration_hook in templates (this facilitates the misuse of the separation between presentation and computation). If someone wants to add something to the template there are already layers (that in some cases would take advantage of a bit more granular subdivision).
For example the "advanced and other options" thing here below would be much cooler if converted to an array of variables moved to source (/me hears Ant screaming) and a foreach of sort for the display, that would give mods a much easier way to add things to the template.
The moment mods will have enough possibilities to add/remove things from the interface without touching a theme file, then a clear distinction between mods and themes would make sense.

tl;dr: I'm still very confused and I don't have an answer yet... lol

Re: Unify themes and mods behaviour?

Reply #7 – December 23, 2012, 04:47:19 pm

Quote from: Antechinus – December 23, 2012, 02:06:27 pm
Quote from: TestMonkey – December 23, 2012, 06:12:14 amThanks! We've been contemplating this one way or the other for a long time.

Lets see...

Essentially, they are two different beasts: one changes behavior/functionality, the other presentation.
You just made your first mistake. In fact, it's common for themes to change functionality and it's common for mods to change presentation. The boundaries between mod and theme are a bit blurry sometimes.

I didn't know. I didn't spend hundreds of hours on broken installations because they do exactly that. I didn't fix endless conflicts because they do exactly that. I didn't contemplate dozens of potential security issues because themes write to superglobals even. None of them does it in a standard, extensible, friendly to the other, way.

I am well aware that the mods vs themes system is broken, thank you for the news.

Sounds like you're not aware of what code design principles are. Here's a bit for you: mods/addons extend or change the functionality, and should be able to format their output and send it over (where they lose control over it, the theme may choose not to display it). Themes shouldn't provide extra-functionality, but be able to process data and extra-data on their own, including extra-output from mods/addons.
"mods" shouldn't just replace code in the templates, to provide the display of their data. And "themes" shouldn't just replace everything, at install/loading, without accepting extra data for sections or sections entirely.

Quote
QuoteA few more questions.
# Do themes use hooks? Is it recommended to?
# Do we need or want template hooks?
If by the first you mean "Should themes rely on hooks for any template changes they make to default?" then I would very definitely say "No." In fact, if you go down that route I would have no interest in working on such a beast.

If you mean "Should custom themes include, as far as possible, any hooks which are also in default templates?" then sure, that makes sense.

I have a different suggestion: take a deep breath and calm down. I don't appreciate you put words in my mouth. And out of the blue, at that. Sounds like this is your day of doing exactly that, then bitching at it.

To the point: I'm not convinced we should add template hooks. That's what a question is, you know: I am asking if others think we should and why.

Re: Unify themes and mods behaviour?

Reply #8 – December 23, 2012, 05:13:47 pm

Quote from: emanuele – December 23, 2012, 04:22:41 pm
Quote from: Antechinus – December 23, 2012, 02:06:27 pmYou just made your first mistake. In fact, it's common for themes to change functionality and it's common for mods to change presentation. The boundaries between mod and theme are a bit blurry sometimes.
In theory the separation should be very well defined.
Unfortunately with SMF is not.
The theory is: you want to create a theme with new functionality? You create a mod and you create a theme that works with that mod.

Ok, but I can see a problem with that. What if you only want the extra functionality on one theme? At the moment it's easy.

QuoteBut: I have to partially agree with Ant and I feel a mod with a template is somehow not so different from a theme with an addon.
Yes, the mod shouldn't replace an entire template, but at the moment nothing forbids them to do so.

One of mine does.

It was simply the cleanest and easiest way of dealing with it.

Re: Unify themes and mods behaviour?

Reply #9 – December 23, 2012, 05:21:29 pm

Quote from: TestMonkey – December 23, 2012, 04:47:19 pm
Quote from: Antechinus – December 23, 2012, 02:06:27 pm
Quote from: TestMonkey – December 23, 2012, 06:12:14 amThanks! We've been contemplating this one way or the other for a long time.

Lets see...

Essentially, they are two different beasts: one changes behavior/functionality, the other presentation.
You just made your first mistake. In fact, it's common for themes to change functionality and it's common for mods to change presentation. The boundaries between mod and theme are a bit blurry sometimes.

I didn't know. I didn't spend hundreds of hours on broken installations because they do exactly that. I didn't fix endless conflicts because they do exactly that. I didn't contemplate dozens of potential security issues because themes write to superglobals even. None of them does it in a standard, extensible, friendly to the other, way.

I am well aware that the mods vs themes system is broken, thank you for the news.

You're welcome.

QuoteSounds like you're not aware of what code design principles are. Here's a bit for you: mods/addons extend or change the functionality, and should be able to format their output and send it over (where they lose control over it, the theme may choose not to display it). Themes shouldn't provide extra-functionality, but be able to process data and extra-data on their own, including extra-output from mods/addons.

Well that's great as a principle, but unfortunately it doesn't work like that in practice. Case in point: that test theme I've been working on. It relies on adding new functionality in the theme itself.

Could it be done another way, by installing a separate mod and them calling that functionality into the theme? Sure, it could, but that's an extra layer of complication for absolutely no benefit. Why on earth would anyone bother?

Quote
Quote
QuoteA few more questions.
# Do themes use hooks? Is it recommended to?
# Do we need or want template hooks?
If by the first you mean "Should themes rely on hooks for any template changes they make to default?" then I would very definitely say "No." In fact, if you go down that route I would have no interest in working on such a beast.

If you mean "Should custom themes include, as far as possible, any hooks which are also in default templates?" then sure, that makes sense.

I have a different suggestion: take a deep breath and calm down. I don't appreciate you put words in my mouth. And out of the blue, at that. Sounds like this is your day of doing exactly that, then bitching at it.

To the point: I'm not convinced we should add template hooks. That's what a question is, you know: I am asking if others think we should and why.

I wasn't bitching. I was asking what you meant.

And providing my opinion on answers to the possible meanings of your questions.

Ok, what, exactly, do you mean by "template hooks"? How do you envisage them working?

Re: Unify themes and mods behaviour?

Reply #10 – December 25, 2012, 10:13:23 am

Quote from: Antechinus – December 23, 2012, 05:21:29 pm
QuoteSounds like you're not aware of what code design principles are. Here's a bit for you: mods/addons extend or change the functionality, and should be able to format their output and send it over (where they lose control over it, the theme may choose not to display it). Themes shouldn't provide extra-functionality, but be able to process data and extra-data on their own, including extra-output from mods/addons.
Well that's great as a principle, but unfortunately it doesn't work like that in practice. Case in point: that test theme I've been working on. It relies on adding new functionality in the theme itself.

Could it be done another way, by installing a separate mod and them calling that functionality into the theme? Sure, it could, but that's an extra layer of complication for absolutely no benefit. Why on earth would anyone bother?

The question is, how are themes doing it. Lets imagine this (roughly), for the sake of the experiment:
# you write a theme, where you display your wanted functionality nicely
# you provide a php file where you implement your wanted functionality, using only hooks (lets say you can, the hooks system is great yada-yada)
# your implementation sends all kinds of extra-data to $context, where your theme picks them up
# you provide a function, to install the hooks, and one to remove them
# the admin will install your theme using Teh New Theme Installer (emanuele @ 2013)
# Profit.

Lets have at this scenario. :)

Re: Unify themes and mods behaviour?

Reply #11 – December 25, 2012, 01:12:21 pm

Sounds awfully complicated, for absolutely no benefit over the current way of doing it. I ask again, why would anyone bother? If you want to change something to a more complicated way of doing things, it's up to you to be convincing about the benefits.

Ok, having at it:

# Yay! I like this bit.

# Why would I bother? Seriously. Your assuming I want to write and support mods, not make a theme.

# Same question again. For some things there's no need to go anywhere near $context.

# See 2. Talk about convoluted.

# That's the general idea.

# Not in it for the money.

You have to remember the way I tend to code themes: ruthlessly, cleanly, and with absolutely no qualms about ditching crap I don't need. If it's not directly useful to me, it wont stay in the templates.

That even extends as far as language strings. For a default theme that has to handle i18n, language strings are essential. However, for custom work on sites where the interface is basically monolingual, hard coding text is easier and is better for performance.

Re: Unify themes and mods behaviour?

Reply #12 – December 25, 2012, 01:22:49 pm

Quote from: Antechinus – December 25, 2012, 01:12:21 pmYour assuming I want to write and support mods, not make a theme.

Well, you cannot assume we are writing a forum for your own use.

We are writing it for anyone and it should have "a way to work" that works.

Re: Unify themes and mods behaviour?

Reply #13 – December 25, 2012, 01:38:04 pm

Well. To implement functionality, addons use hooks. (lets say it's usual)
To implement functionality, why would themes break that (in addition to implementing functionality itself, which isn't 'display existing functionality any way you freaking please').
Mods could be written without hooks, too. (and some will). We're talking about trying to make the core approach give people tools to do the job differently. What they do with the tools is up to them in the end, but that's not really the point.

But I agree that "if it's too complicated then I won't do it", this is a fair point. Lets make it less complicated (if it is).
What is currently complicated about hooks? (I has a couple beefs tbh).
What is complicated about setting variables to $context?¹

For the record, this is the recommended standard for core: to implement functionality separately from presentation of the functionality. (where 'recommended' = 'required').
This is the recommended standard for addons: to implement functionality separately from presentation of the functionality.
(where 'recommended' = 'recommended').
In the context of this discussion, I will propose the following statement: themes are about presentation of existing functionality, but if they implement new functionality, then they should do it separately (at file/code design/implementation level) from the presentation of the functionality.

¹ we could also provide a gateway function if it makes any sense... it could also help the core track what the extension [addon/theme] are adding... probably not a good idea though

Re: Unify themes and mods behaviour?

Reply #14 – December 26, 2012, 03:02:00 pm

Quote from: emanuele – December 25, 2012, 01:22:49 pmWell, you cannot assume we are writing a forum for your own use.
We are writing it for anyone and it should have "a way to work" that works.

Yeah sure. I get that. I'm just saying that people should still have the option to code things how they like, without being locked into one path because somebody thought that was the right way.