Page MenuHomePhabricator

Helper functions don't work because core doesn't support this feature.
Closed, DeclinedPublic

Description

There are two helper functions stringOrArray and msg.
They are used in Skin.mustache.
They are placed in function BlueprintSkinTemplate::getTemplate() but this function is never called now.
The function getTemlate was called when BlueprintSkinTemplate class was child of LightNCandyTemplate class and it was until the commit Switch to core's server-side HTML templating.

It cannot be fixed fast because core's server-side HTML templating doesn't support helpers.
If you are going to use helper functions I can send patch to add this feature to core and patch to fix it in Blueprint Skin.

I just need a confirmation that this is really a necessary thing.

Event Timeline

Pastakhov raised the priority of this task from to Needs Triage.
Pastakhov updated the task description. (Show Details)
Pastakhov added a project: Blueprint.
Pastakhov subscribed.
Volker_E added subscribers: Volker_E, Spage.

@Spage This is the issue, that you were finding out as well, right? Or didn't at least stringOrArray keep working?

Thanks for the diagnosis. You're right, so

<li role="menuitem"><a href="{{href}}" class="{{stringOrArray class}}">{{text}}</a></li>

just turns into <a class="" href="/wiki/index.php/Special:Notifications">0</a>, and Echo notification counts aren't styled.

I think MediaWiki devs should have a discussion about supporting helpers in templates. Flow is full of helpers and thus has to maintain a local LightnCandy implementation to support them. So sure, propose the patch to core. But the safest thing to do is to move the logic out of the templates in Blueprint.

Meanwhile getTemplate() should be removed from src/BlueprintSkinTemplate.php, sorry I left it around.

Should I propose the patch only for single tag {{xxx}} or a section {{#yyy}} ... {{/yyy}} too?

@Pastakhov In my understanding, it should be pretty clear, how important in the sense of how many use cases the change can provide and how much maintenance the code might need in future. I'd weigh in importance for bigger projects and would generally recommend to rather start small. Or are sections something widely used?

@Volker_E: It needs few code, but I don't know why MW Core isn't support it still. Maybe MW devs decided don't allow it or just don't make this until it does not is used.
Also BP skin can don't use this feature and if I propose the patch then MW devs can ask me "For what is it?". Therefore you (BP devs) should decide how much this feature is needed. I don't need it, I just can help if you need it.

MediaWiki purposely does not support helpers as Mustache doesn't support helpers. Long discussion here if interested.

In the example:

<li role="menuitem"><a href="{{href}}" class="{{stringOrArray class}}">{{text}}</a></li>

You should turn {{class}} into as tring before sending it.

Mustache does support sections but only if the value is a boolean

e.g. {{#isReadable}}hello world{{/isReadable}} prints 'hello world' if isReadable is a boolean variable. if it's a string, even an empty string it will always print "hello world"

@Jdlrobson but Mustache supports helpers. Thanks for the link but I cannot find there info about MediaWiki is not going support helpers.

Unless I'm misunderstanding what you mean by helpers it doesn't [1] - it's a logic less template language.
If you mean lambda sections they are an optional part of the spec.

Frustratingly I cannot find the exact link to the RFC discussion about templates inside that wiki page (and its talk page) but I was in the meeting and the move to Mustache over Handlebars was primarily to keep logic out of templates. This like anything is always up for reconsideration but would need to go through the RFC route.

[1] https://github.com/janl/mustache.js/issues/480

Prtksxna subscribed.

The skin is no longer maintained