I had a chat with Timo in person about this patch: https://gerrit.wikimedia.org/r/111250
He still feels strongly that adding this to core in a generic blob form is not very helpful and adding it to core without a standard JavaScript templating library would also be an incomplete job.
As a result, it seems the best way forward might me to move the code that MobileFrontend is using for this into an extension MediaWikiTemplates that both Flow and MobileFrontend can depend on. We'll make a few modifications to it so it supports both template libraries - Hogan and Handlebars.
This would allow code sharing and iteration on the code and hopefully will lend itself nicely as a shared repository where we can experiment with different templating languages.
Thoughts?
Two points:
1) The amount of code currently in MobileFrontend that Flow could use is very minimal. May not be worth putting into an extension (as soon as it is in an extension, you have a dependency and a requirement to follow it, you can't have Flow and MobileFrontend using different versions of the same extension).
It's about 20 lines of code to extend ResourceLoaderModule (define resource array 'templates', and load those from disk in the script implementation).
2) All it would provide is "template.add( key, htmlString )" and "template.get( key )" returning said htmlString, it wouldn't invoke the template engine because that's not yet shared. Also at this time, MobileFrontend's version defines this add/get interface as "mw.template" which seems too generic (should probably be mw.mobileFrontend.template or mw.mfTemplate).
— Timo
On 9 Apr 2014, at 15:14, Jon Robson jrobson@wikimedia.org wrote:
I had a chat with Timo in person about this patch: https://gerrit.wikimedia.org/r/111250
He still feels strongly that adding this to core in a generic blob form is not very helpful and adding it to core without a standard JavaScript templating library would also be an incomplete job.
As a result, it seems the best way forward might me to move the code that MobileFrontend is using for this into an extension MediaWikiTemplates that both Flow and MobileFrontend can depend on. We'll make a few modifications to it so it supports both template libraries - Hogan and Handlebars.
This would allow code sharing and iteration on the code and hopefully will lend itself nicely as a shared repository where we can experiment with different templating languages.
Thoughts?
+S since he brought this up during today's scrum of scrums.
On Wed, Apr 9, 2014 at 3:24 PM, Timo Tijhof ttijhof@wikimedia.org wrote:
Two points:
- The amount of code currently in MobileFrontend that Flow could use is
very minimal. May not be worth putting into an extension (as soon as it is in an extension, you have a dependency and a requirement to follow it, you can't have Flow and MobileFrontend using different versions of the same extension).
It's about 20 lines of code to extend ResourceLoaderModule (define resource array 'templates', and load those from disk in the script implementation).
- All it would provide is "template.add( key, htmlString )" and
"template.get( key )" returning said htmlString, it wouldn't invoke the template engine because that's not yet shared. Also at this time, MobileFrontend's version defines this add/get interface as "mw.template" which seems too generic (should probably be mw.mobileFrontend.template or mw.mfTemplate).
-- Timo
On 9 Apr 2014, at 15:14, Jon Robson jrobson@wikimedia.org wrote:
I had a chat with Timo in person about this patch: https://gerrit.wikimedia.org/r/111250
He still feels strongly that adding this to core in a generic blob form is not very helpful and adding it to core without a standard JavaScript templating library would also be an incomplete job.
As a result, it seems the best way forward might me to move the code that MobileFrontend is using for this into an extension MediaWikiTemplates that both Flow and MobileFrontend can depend on. We'll make a few modifications to it so it supports both template libraries - Hogan and Handlebars.
This would allow code sharing and iteration on the code and hopefully will lend itself nicely as a shared repository where we can experiment with different templating languages.
Thoughts?
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
- All it would provide is "template.add( key, htmlString )" and
"template.get( key )" returning said htmlString, it wouldn't invoke the template engine because that's not yet shared. Also at this time, MobileFrontend's version defines this add/get interface as "mw.template" which seems too generic (should probably be mw.mobileFrontend.template or mw.mfTemplate).
Agreed on this point. I know that Gabriel and I's solution is not quite ready and no one is using it yet; but we're going to need a custom RL module anyways at some point down the line. Our templates get compiled into an intermediate form which RL will deliver -- so it'll eventually have a LESS style pipeline.
In any case, my solution's templates will not be compatible with your templates. So; perhaps mw.mustacheTemplate.get or something?
mw.template = { add: function(name, engineName){ // used by RL }, get: function(name) { if ( this.isCompiledTemplate( name ) ) { return this._compileTemplate( name ); } else { return this._compiledTemplates[name]; } } } mw.template.addEngine( 'Hogan', { compile: function( templateBody ) {Hogan.compile( templateBody ); } } );
$wgResourceModule['myfoo'] = array( 'dependencies' => array( 'mediawiki.template', 'mediawiki.templates.knockoff', 'mediawiki.templates.hogan' ), 'templates' => array( 'templates/foo.hogan', 'templates/foo.knockoff' )
I was imagining something like the above - a template system which in theory could support multiple template languages. The end result should be a MediaWiki instance which can be configured by the owner to choose their preferred template language or support multiple template languages.
Wikimedia instances / core should only promote/use __one__ of these template languages but our code should be generic and flexible enough.
The LESS implementation was done in such a generic way that SASS could be used instead (I have an outstanding TODO with the Wikia guys to help make this happen). Our template system should be no different.
On Wed, Apr 9, 2014 at 5:49 PM, Matthew Walker mwalker@wikimedia.org wrote:
- All it would provide is "template.add( key, htmlString )" and
"template.get( key )" returning said htmlString, it wouldn't invoke the template engine because that's not yet shared. Also at this time, MobileFrontend's version defines this add/get interface as "mw.template" which seems too generic (should probably be mw.mobileFrontend.template or mw.mfTemplate).
Agreed on this point. I know that Gabriel and I's solution is not quite ready and no one is using it yet; but we're going to need a custom RL module anyways at some point down the line. Our templates get compiled into an intermediate form which RL will deliver -- so it'll eventually have a LESS style pipeline.
In any case, my solution's templates will not be compatible with your templates. So; perhaps mw.mustacheTemplate.get or something?
There's a couple of long-term goals here. The first is to begin sharing Mobile code with other teams, so as to get ourselves in a position to merge Mobile with desktop responsively -- likely a few years down the line. The second is to get cross-team usage of common libraries, as opposed to constantly "reinventing the wheel" in each product.
I think this is a great moment for us to begin the long road of accomplishing both of those things. While it isn't a significant amount of code, coming up with a way for us to have this usable cross-product is very important. We really don't want to have to maintain this in two repositories, and to address Timo's first concern, we also will never want to end up in a situation where "Mobile is using version A, and Flow is using version B". That is counterproductive.
What kind of solution could we plausibly use across both products?
--Shahyar
On Thu, Apr 10, 2014 at 12:16 PM, Jon Robson jrobson@wikimedia.org wrote:
mw.template = { add: function(name, engineName){ // used by RL }, get: function(name) { if ( this.isCompiledTemplate( name ) ) { return this._compileTemplate( name ); } else { return this._compiledTemplates[name]; } } } mw.template.addEngine( 'Hogan', { compile: function( templateBody ) {Hogan.compile( templateBody ); } } );
$wgResourceModule['myfoo'] = array( 'dependencies' => array( 'mediawiki.template', 'mediawiki.templates.knockoff', 'mediawiki.templates.hogan' ), 'templates' => array( 'templates/foo.hogan', 'templates/foo.knockoff' )
I was imagining something like the above - a template system which in theory could support multiple template languages. The end result should be a MediaWiki instance which can be configured by the owner to choose their preferred template language or support multiple template languages.
Wikimedia instances / core should only promote/use __one__ of these template languages but our code should be generic and flexible enough.
The LESS implementation was done in such a generic way that SASS could be used instead (I have an outstanding TODO with the Wikia guys to help make this happen). Our template system should be no different.
On Wed, Apr 9, 2014 at 5:49 PM, Matthew Walker mwalker@wikimedia.org wrote:
- All it would provide is "template.add( key, htmlString )" and
"template.get( key )" returning said htmlString, it wouldn't invoke the template engine because that's not yet shared. Also at this time, MobileFrontend's version defines this add/get interface as "mw.template" which seems too generic (should probably be mw.mobileFrontend.template
or
mw.mfTemplate).
Agreed on this point. I know that Gabriel and I's solution is not quite ready and no one is using it yet; but we're going to need a custom RL
module
anyways at some point down the line. Our templates get compiled into an intermediate form which RL will deliver -- so it'll eventually have a
LESS
style pipeline.
In any case, my solution's templates will not be compatible with your templates. So; perhaps mw.mustacheTemplate.get or something?
When discussing with Timo we noticed VisualEditor was doing something very similar to mobile with parsed messages but was actually doing it a lot better. So yes I think the current existing model of bunging things into extensions is bad. It decreases visibility of work and leads to various incompatible forks as we end up working in silos.
I would love us to reverse this anti-pattern and start putting stuff like this straight into core and iterating on it together. MobileFrontend is already in many ways dependent on VisualEditor, Echo, Thanks and various other extensions. We've seen this issue with styling across extensions (which has led to the construction of mediawiki.ui in core) and I would like us to see us take this approach for other basic things (another one coming to mind is some kind of JS framework - the fact mobile is using its own lightweight framework, VisualEditor is using OOJS and various other extensions are cutting their own versions / pulling in some sort of framework also highlights a problem.
The problem with both Flow and MobileFrontend being dependent on another extension is that when yet another new extension is built it won't necessarily think to use this extension and will end up using its own templating language/method of shipping templates to the client when it sees there is nothing like that in core.
If we are worried about providing incomplete features to 3rd party users e.g. templating without a standard library maybe we should be maintaining a Wikimedia fork of MediaWiki where we can do this stuff but I don't think this kind of behaviour can continue.
On Mon, Apr 14, 2014 at 11:53 AM, Jon Robson jrobson@wikimedia.org wrote:
The problem with both Flow and MobileFrontend being dependent on another extension is that when yet another new extension is built it won't necessarily think to use this extension and will end up using its own templating language/method of shipping templates to the client when it sees there is nothing like that in core.
Shahyar mentioned this, teams doing work useful to other groups that's "hidden" in their extension. The revived Tech talks are a way to expose big-ticket features over time. Extensions should list their "interesting" technology on-wiki somewhere, it's on my TODO list for Flow.
If we are worried about providing incomplete features to 3rd party users e.g. templating without a standard library maybe we should be maintaining a Wikimedia fork of MediaWiki where we can do this stuff but I don't think this kind of behaviour can continue.
Two other workarounds:
1. One extension can call the feature from the other. Right now you do that by require OtherExtension.php which triggers DB updates and tests; is there a lighter-weight way to say "I want a function from MobileFrontend/includes/modules/MFResourceLoaderModule.php" ?
2. We create extensions/WikimediaFeaturesTeam for shared code.