Talk:Requests for comment/HTML templating library

=Ideas about stuff to maybe consider=

Existing PHP templating in core
You might want to compare templates' PHP functioning to existing PHP solutions in Mediawiki core, like QuickTemplate. AndrewRussellGreen (talk) 02:52, 19 December 2013 (UTC)

I18n
I was very happy about mustache when I tried it out in one MediaWiki extension. For frontend it is pretty easy to include i18n support by using data-i18n attributes and jquery.i18n (though message loading is still not in core (nor is template loading yet)), but haven't figured how to do i18n in PHP. --Nikerabbit (talk) 12:17, 27 December 2013 (UTC)

Beyond templating
I have this feeling that AngularJS like stuff with controller bindings to the DOM etc is going to be next years thing. Have we considered/looked into this and what it means for templating ? I think it is too early for that right now perhaps, as far as I know there are no winners yet when it comes to MVW + template bindings as a combination. I just wanted to throw it out there and make sure that it was on people's radar before we pick a template engine. TheDJ (talk) 13:51, 4 January 2014 (UTC)


 * +1 on raising this aspect. Dynamic forms with client-side validation and help are another example where something like AngularJS might be helpful. -- Gabriel Wicke (GWicke) (talk) 19:59, 9 January 2014 (UTC)

Other aspects to consider
Some aspects that I am missing somewhat in this RFC:


 * form handling and -validation and its interaction with the template library
 * systematic user content sanitization in DOM context

In the longer term, there could be overlap with content HTML templating as planned in Parsoid. Some extra and possibly differing requirements there are:


 * Visual editing: should support visual editing (so no magic syntax in templates, only HTML, simplicity)
 * Encourage data abstraction: access to JSON data sources and data-generating code modules instead of templated data in page content
 * Performance:
 * scoped variable definitions for efficient re-rendering of dynamic parts
 * integration with caching (dependency tracking, purges, incremental fragment updates)
 * Security: no infinite loops (only iteration), no unsanitized content injection

Overall it is not clear that the same solution can work well for HTML templating in both content and UI. There is no reason for this RFC to block on the Parsoid work, but it might be useful to keep content templating in mind. -- Gabriel Wicke (GWicke) (talk) 23:10, 7 January 2014 (UTC)