Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :)
Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags.
Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not.
We identified the new skin system will have two long term goals: 1) We would like to get to the point where a new skin can be built by simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing)
As next steps we agreed to do the following:
1) Trevor is going to build a watch star widget on client and server. We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September.
2) We need a templating system in core. Trevor is going to do some research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
[1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
Thanks for summarizing the meeting Jon.
So, let's get Twig/Swig into core then, eh? :)
- Trevor
On Tue, Aug 26, 2014 at 3:53 PM, Jon Robson jrobson@wikimedia.org wrote:
Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :)
Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags.
Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not.
We identified the new skin system will have two long term goals:
- We would like to get to the point where a new skin can be built by
simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing)
As next steps we agreed to do the following:
- Trevor is going to build a watch star widget on client and server.
We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September.
- We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
[1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Aug 26, 2014 at 6:21 PM, Trevor Parscal tparscal@wikimedia.org wrote:
Thanks for summarizing the meeting Jon.
So, let's get Twig/Swig into core then, eh? :)
It would be trivially simple to add twig (or any other Composer managed templating library) to mediawiki/vendor.git following the process outlined in the recently accepted Composer managed libraries RFC [0].
[0]: https://www.mediawiki.org/wiki/Requests_for_comment/Composer_managed_librari...
On Tue, Aug 26, 2014 at 8:21 PM, Trevor Parscal tparscal@wikimedia.org wrote:
Thanks for summarizing the meeting Jon.
So, let's get Twig/Swig into core then, eh? :)
Please yes. Twig is really powerful, pretty fast, and is supported by a major company.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
Someone in one of our meetings mentioned that Twig is a PHP implementation of Mustache. This doesn't seem to be the case though. We need a templating solution that works both on the server and the client.
On Tue, Aug 26, 2014 at 5:21 PM, Trevor Parscal tparscal@wikimedia.org wrote:
Thanks for summarizing the meeting Jon.
So, let's get Twig/Swig into core then, eh? :)
- Trevor
On Tue, Aug 26, 2014 at 3:53 PM, Jon Robson jrobson@wikimedia.org wrote:
Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :)
Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags.
Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not.
We identified the new skin system will have two long term goals:
- We would like to get to the point where a new skin can be built by
simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing)
As next steps we agreed to do the following:
- Trevor is going to build a watch star widget on client and server.
We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September.
- We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
[1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Someone in the meeting also claimed that Swig and Twig were compatible, and that does appear to be generally true, but I think there are some deviations.
- Trevor
On Wed, Aug 27, 2014 at 1:39 PM, Juliusz Gonera jgonera@wikimedia.org wrote:
Someone in one of our meetings mentioned that Twig is a PHP implementation of Mustache. This doesn't seem to be the case though. We need a templating solution that works both on the server and the client.
On Tue, Aug 26, 2014 at 5:21 PM, Trevor Parscal tparscal@wikimedia.org wrote:
Thanks for summarizing the meeting Jon.
So, let's get Twig/Swig into core then, eh? :)
- Trevor
On Tue, Aug 26, 2014 at 3:53 PM, Jon Robson jrobson@wikimedia.org
wrote:
Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :)
Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags.
Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not.
We identified the new skin system will have two long term goals:
- We would like to get to the point where a new skin can be built by
simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing)
As next steps we agreed to do the following:
- Trevor is going to build a watch star widget on client and server.
We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September.
- We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
[1]
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
I've finished the SVGs-to-font and font-to-SVGs scripts. I'll document and post these in the next couple days.
On Wed, Aug 27, 2014 at 2:26 PM, Trevor Parscal tparscal@wikimedia.org wrote:
Someone in the meeting also claimed that Swig and Twig were compatible, and that does appear to be generally true, but I think there are some deviations.
- Trevor
On Wed, Aug 27, 2014 at 1:39 PM, Juliusz Gonera jgonera@wikimedia.org wrote:
Someone in one of our meetings mentioned that Twig is a PHP implementation of Mustache. This doesn't seem to be the case though. We need a templating solution that works both on the server and the client.
On Tue, Aug 26, 2014 at 5:21 PM, Trevor Parscal tparscal@wikimedia.org wrote:
Thanks for summarizing the meeting Jon.
So, let's get Twig/Swig into core then, eh? :)
- Trevor
On Tue, Aug 26, 2014 at 3:53 PM, Jon Robson jrobson@wikimedia.org
wrote:
Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :)
Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags.
Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not.
We identified the new skin system will have two long term goals:
- We would like to get to the point where a new skin can be built by
simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing)
As next steps we agreed to do the following:
- Trevor is going to build a watch star widget on client and server.
We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September.
- We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
[1]
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On 08/27/2014 05:51 PM, Monte Hurd wrote:
I've finished the SVGs-to-font and font-to-SVGs scripts. I'll document and post these in the next couple days.
Is this just a temporary solution since the SVGs for some fonts have been lost?
If not, why do we need a font->SVG workflow? My understanding is that SVG is always the source code, even for WikiFont (which generates font file output from SVG source code).
Matt Flaschen
It came out in a meeting about icons, that a major impetus of Wikifont was the workflow for designers being easier if all icons are sourced from a single font file, and not individual SVG files. The SVG-to-font workflow is helpful for the iOS app which uses the font (apparently the Android app does not). The font-to-SVG workflow was an idea to try and make it possible for designers to use their "font is the source" workflow.
I personally believe that being a designer at Wikimedia should mean working with open formats (SVG, CSS, HTML), checking assets into git repositories, and seeking to make community contribution easier, not more difficult. The idea that a font file, which is a big blob of binary data, be the official source of all icons just doesn't scale, and makes contribution much more difficult.
In the meeting we seemed to agree that it was worth developing further the tools to have more features and an easier workflow when working with SVG (with PNG fallbacks). Work is already underway to achieve this, and I am looking forward to us having an easy to use, easy to contribute to and well performing system for designing, refining and delivering icons.
- Trevor
On Wed, Sep 3, 2014 at 6:43 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 08/27/2014 05:51 PM, Monte Hurd wrote:
I've finished the SVGs-to-font and font-to-SVGs scripts. I'll document and post these in the next couple days.
Is this just a temporary solution since the SVGs for some fonts have been lost?
If not, why do we need a font->SVG workflow? My understanding is that SVG is always the source code, even for WikiFont (which generates font file output from SVG source code).
Matt Flaschen
On Sep 3, 2014, at 8:46 PM, Trevor Parscal tparscal@wikimedia.org wrote:
The font-to-SVG workflow was an idea to try and make it possible for designers to use their "font is the source" workflow.
Not quite. The point of the conversion scripts (which are done and seem to work pretty well) is to make it possible for designers (and me) to use a "svg is the source" workflow and pipe these svgs through the scripts if we happen to need a font representation.
On Sep 3, 2014, at 6:43 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
WikiFont (which generates font file output from SVG source code).
tl:dr SVGs yay!
The problem was WikiFont did not generate itself (magic?) from svgs. The svgs had to be fairly painstakingly imported into a font forge project which was then used to generate the font.
The font forge importation workflow was sticky enough (importing svgs and mapping them, etc) that small visual tweaks (baseline offsets and such) ended up being made in the font forge project itself as well, thus diverging from the source svgs.
I think this workflow stickiness was what led the designer to see the font forge project as canonical.
So... the 2 scripts I wrote.
One automates creating a font from a folder of svgs. Svgs are canonical as they should be, but hey, you want a font? You got it.
The second script, just for fun, reverses the process and creates a folder of svgs from the font.
I've been dogfooding these for the last week for a supplemental font the iOS app uses.
I'll post them hopefully next week when I get a chance to document them. If you can't wait and are in the SF office stop by my desk and I can demo it in about 2 minutes.
On 09/04/2014 03:29 AM, Monte Hurd wrote:
The font forge importation workflow was sticky enough (importing svgs and mapping them, etc) that small visual tweaks (baseline offsets and such) ended up being made in the font forge project itself as well, thus diverging from the source svgs.
This is why automation and having a clear understanding of what the source code is are both so important.
I think this workflow stickiness was what led the designer to see the font forge project as canonical.
Actually, it was somewhat ambiguous what the source code is. Read https://gerrit.wikimedia.org/r/#/c/137888/ if you want to know what I mean.
One automates creating a font from a folder of svgs. Svgs are canonical as they should be, but hey, you want a font? You got it.
Great. This will be useful for the app, and if we ever decide to revisit the decision about icons on web (I completely agree SVG is better as source code, but we could still use generated fonts on desktop if we decided that approach was suitable).
Matt Flaschen
2014-08-27 1:53 GMT+03:00 Jon Robson jrobson@wikimedia.org:
- We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
[1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
At this point about everyone needs templating library as soon as possible and do not want to get blocked by the RFC. Please, let's all work together to complete the RFC for the benefit of everyone.
-Niklas
Le 27/08/2014 08:59, Niklas Laxström a écrit :
2014-08-27 1:53 GMT+03:00 Jon Robson jrobson@wikimedia.org:
- We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
[1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
At this point about everyone needs templating library as soon as possible and do not want to get blocked by the RFC. Please, let's all work together to complete the RFC for the benefit of everyone.
-Niklas
Hello,
I am backing up Niklas on this point. The future of skins depends on a HTML templating system which, once agreed and implemented, will land in the mediawiki/core platform. From there future of skin can build on top of it.
As I understand Jon summary, the idea is a proof of concept based on Mustache that would be out of mediawiki/core. Any experience acquired in that experiment would help move forward the HTML templating library RFC in one way (twig) or an other (mustache).
On Wed, Aug 27, 2014 at 12:17 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 27/08/2014 08:59, Niklas Laxström a écrit :
At this point about everyone needs templating library as soon as possible and do not want to get blocked by the RFC.
You can use Handlebars templates, implemented by Lightncandy in PHP and provided as ResourceLoader modules by the Mantle extension.[1] Tested, working, passed security review, fast according to the table in the templating RFC. Flow uses the same templates in both PHP and JS, though of course we have to implement helper functions in both languages.
There are genuine benefits to Gabriel Wicke's Knockoff-Tassembly approach[2] including DOM-based templating and reactive updates in JavaScript if you use full knockout.js. So the Flow team hasn't been involved in the RFC, assuming that Knockoff-Tassembly will be the eventual approach. Are we now reevaluating?
As I understand Jon summary, the idea is a proof of concept based on
Mustache that would be out of mediawiki/core. Any experience acquired in that experiment would help move forward the HTML templating library RFC in one way (twig) or an other (mustache).
AIUI I don't see much win in mustache. It's not faster and does less than handlebars. Twig/Swig does more (macros, parent, extends, more?) which can result in worse separation of concerns.
"There can be only one" (Highlander), or two or three in the meantime :-) Cheers,
[1] https://www.mediawiki.org/wiki/Extension:Mantle#Templates [2] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/...
-- =S Page Features engineer
Hi,
On Wed, 27 Aug 2014, at 16:59, Niklas Laxström wrote:
2014-08-27 1:53 GMT+03:00 Jon Robson jrobson@wikimedia.org:
- We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
[1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
At this point about everyone needs templating library as soon as possible and do not want to get blocked by the RFC. Please, let's all work together to complete the RFC for the benefit of everyone.
-Niklas
I'm not very familiar with the topic. 1) Which of those involve clear separation of PHP and HTML, so that editing layout only involves editing a file with markup? 2) Which of those are closer to MVC approach? 3) How many of the currently deployed extensions have the features mentioned above (uploadwizard, flow, etc) making it easy for a designer (not a programmer) to edit how they look and what their layout is?
svetlana
Niklas Laxström wrote:
At this point about everyone needs templating library as soon as possible and do not want to get blocked by the RFC. Please, let's all work together to complete the RFC for the benefit of everyone.
-Niklas
I've opened https://www.mediawiki.org/wiki/Category:All_skins . I am in the process of notifying each skin maintainers of this RfC immediately.
svetlana
On 08/27/2014 02:59 AM, Niklas Laxström wrote:
At this point about everyone needs templating library as soon as possible and do not want to get blocked by the RFC. Please, let's all work together to complete the RFC for the benefit of everyone.
-Niklas
I completely agree. We can't continue just ignoring the RFC and implementing temporary solutions.
Nor should we ignore the RFC and implement a permanent solution.
Has this RFC been scheduled for one of the weekly RFC chats yet?
In addition to that, let me know how I can help. The RFC is definitely relevant to the Growth team as well.
Matt Flaschen
Sure, we are still keen to see the RFC resolved, we just worry that it is not progressing at the speed we would like. It's not a case of ignoring it but a case of not letting ourselves be blocked on it whilst we have momentum.
I was merely stating that we are not afraid of continuing down the Mustache based templating route, if we get to the point we need to use templates for skins, since it is already available, has passed security review and performance review and can easily be swapped out for another language if necessary.
We are not scared of the RFC resolving to decide on using another template language. Having to batch convert templates from one template language to whatever language we standardise on can be done via a script if the resulting template language is not Mustache based.
Both Flow and MobileFrontend are heavily using Mustache based templates so we would have to write such a script anyway.
I just wanted to be open about this. On 4 Sep 2014 02:50, "Matthew Flaschen" mflaschen@wikimedia.org wrote:
On 08/27/2014 02:59 AM, Niklas Laxström wrote:
At this point about everyone needs templating library as soon as possible and do not want to get blocked by the RFC. Please, let's all work together to complete the RFC for the benefit of everyone.
-Niklas
I completely agree. We can't continue just ignoring the RFC and implementing temporary solutions.
Nor should we ignore the RFC and implement a permanent solution.
Has this RFC been scheduled for one of the weekly RFC chats yet?
In addition to that, let me know how I can help. The RFC is definitely relevant to the Growth team as well.
Matt Flaschen
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hey Jon, You mentioned that you might want to experiment with Knockoff support in Mantle. Are you still planning on doing that? Apparently Knockoff is more mature now than when I tested it in MobileFrontend, so it would be good to give it another trial run (and a 2nd opinion).
On Thu, Sep 4, 2014 at 3:25 AM, Jon Robson jdlrobson@gmail.com wrote:
Sure, we are still keen to see the RFC resolved, we just worry that it is not progressing at the speed we would like. It's not a case of ignoring it but a case of not letting ourselves be blocked on it whilst we have momentum.
I was merely stating that we are not afraid of continuing down the Mustache based templating route, if we get to the point we need to use templates for skins, since it is already available, has passed security review and performance review and can easily be swapped out for another language if necessary.
We are not scared of the RFC resolving to decide on using another template language. Having to batch convert templates from one template language to whatever language we standardise on can be done via a script if the resulting template language is not Mustache based.
Both Flow and MobileFrontend are heavily using Mustache based templates so we would have to write such a script anyway.
I just wanted to be open about this. On 4 Sep 2014 02:50, "Matthew Flaschen" mflaschen@wikimedia.org wrote:
On 08/27/2014 02:59 AM, Niklas Laxström wrote:
At this point about everyone needs templating library as soon as possible and do not want to get blocked by the RFC. Please, let's all work together to complete the RFC for the benefit of everyone.
-Niklas
I completely agree. We can't continue just ignoring the RFC and implementing temporary solutions.
Nor should we ignore the RFC and implement a permanent solution.
Has this RFC been scheduled for one of the weekly RFC chats yet?
In addition to that, let me know how I can help. The RFC is definitely relevant to the Growth team as well.
Matt Flaschen
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Yes. Please do. Someone just needs to find the time to do it! On 4 Sep 2014 18:35, "Ryan Kaldari" rkaldari@wikimedia.org wrote:
Hey Jon, You mentioned that you might want to experiment with Knockoff support in Mantle. Are you still planning on doing that? Apparently Knockoff is more mature now than when I tested it in MobileFrontend, so it would be good to give it another trial run (and a 2nd opinion).
On Thu, Sep 4, 2014 at 3:25 AM, Jon Robson jdlrobson@gmail.com wrote:
Sure, we are still keen to see the RFC resolved, we just worry that it is not progressing at the speed we would like. It's not a case of ignoring
it
but a case of not letting ourselves be blocked on it whilst we have momentum.
I was merely stating that we are not afraid of continuing down the
Mustache
based templating route, if we get to the point we need to use templates for skins, since it is already available, has passed security review and performance review and can easily be swapped out for another language if necessary.
We are not scared of the RFC resolving to decide on using another
template
language. Having to batch convert templates from one template language to whatever language we standardise on can be done via a script if the resulting template language is not Mustache based.
Both Flow and MobileFrontend are heavily using Mustache based templates
so
we would have to write such a script anyway.
I just wanted to be open about this. On 4 Sep 2014 02:50, "Matthew Flaschen" mflaschen@wikimedia.org wrote:
On 08/27/2014 02:59 AM, Niklas Laxström wrote:
At this point about everyone needs templating library as soon as possible and do not want to get blocked by the RFC. Please, let's all work together to complete the RFC for the benefit of everyone.
-Niklas
I completely agree. We can't continue just ignoring the RFC and implementing temporary solutions.
Nor should we ignore the RFC and implement a permanent solution.
Has this RFC been scheduled for one of the weekly RFC chats yet?
In addition to that, let me know how I can help. The RFC is definitely relevant to the Growth team as well.
Matt Flaschen
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Jon Robson wrote:
- We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
[1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
Could someone please review the RfC for accuracy? Is the information up-to-date? I'd like to translate it to other languages to get international feedback, but I was told that the RfC may need a review by a pair of critical eyes first.
svetlana
- Trevor is going to build a watch star widget on client and server.
We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September.
- We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
Hey Trevor Are you able to update us on the current status of the above? Have you begun work on them? Are there any patches you can point at us (even if they are work in progress patches?)
wikitech-l@lists.wikimedia.org