On Dec 27, 2013, at 8:27 PM, Matthew Walker <[email protected]> wrote:

> Owen,
> 
> That's really nifty actually -- can you talk a little about how y'all
> manage the i18n issues? Do you prerender all the messages outside of the
> template? Or do you use Mustache lambda's to do some formatting inside the
> template itself?
> 

Hi, sorry for the delay.  Holiday vacation. :) 

We have a simple Controller framework to go along with the templates.   When we 
originally proposed it we were going to put 100% of the logic and data inside 
the controller side of things and pass it to the template.  However, that just 
creates more boilerplate/temp variables and makes the resulting code and 
templates a lot harder to read 6 months later.  For example doing messages in 
the controller and passing the data to the template:

$message = wfMessage(‘message’);
$template->setVal($message);

And then the template would have something like:

<?php echo $message ?>

vs:  _nothing_ necessary in the controller and calling the message functions 
directly in the template:

<?php echo wfMessage(‘message’) ?>

In the first case you actually have no idea whether the source for $message is 
actually a mediawiki i18n message or something else, but in the second case 
it’s a lot more clear.  And from a readability perspective the best code is no 
code at all. :)

So that’s why we put message calls in the template.  Since we allow function 
calls, theoretically you can call any function, but we prevent the developers 
from doing that by shooting them with nerf darts when they try.  Unlike the 
built in Quick template stuff, our templates are not objects, but they still 
have access to global variables and functions.  

> Additionally, where and how do you draw the line between using a template,
> and having additional logic outside of the template?
> 

The only logic we put in templates is simple conditional stuff and loops.  
isset(), empty(), foreach() etc.  No point in having a separate template 
language when you’re already doing PHP on the back end.

> I'm also curious how you manage the coupling between layers -- do you pass
> in all variables to all templates; or is there some sort of management /
> documentation layer that specifies what data (and what format the data
> needs to be in) should be provided to a template.
> 

The documentation is a bit of a mess, we just use PHP docstrings.   We did 
originally propose a more strict validation/documentation framework to go along 
with it, and some of that code was written but we aren’t using it yet.  The 
self-documenting nature of the Mediawiki API classes is a particularly nice 
feature, and we would have preferred to do something like that but we haven’t 
gotten around to it… 

When writing very complex multi-function Special Pages (almost all of our 
internal tools are built as special pages) it gets kind of unwieldy with the 
special page class that just has a single execute() function and the redundant 
boilerplate to define ajax functions etc.  Since most of our front end is 
javascript now and we sometimes want templates/html or json data from the same 
controllers, we have a 1:1 mapping between methods and templates and every 
controller method is automatically an ajax function that can return json or 
html.  The front end can call ANY back end method and ask for json data or the 
html with the data applied to it.  When the Controller gets “too unwieldy” (the 
threshold for this depends on the developer) we generally refactor them into a 
single Controller and a set of Helper classes so that we retain the same 
external end points, just moving the code around.  

Here’s an example of that:

On every content page, there’s a right rail module that shows the latest photos 
uploaded to the wiki:

http://fallout.wikia.com/wiki/Nikola_Tesla_and_You_(Fallout_3)

on the back end, that’s entirely self contained in this LatestPhotosController 
which is dropped into the skin with a render() function.  However, the data 
that it generates can be used in other places:

http://fallout.wikia.com/wikia.php?controller=LatestPhotos   (call controller, 
combine data with html and return it)
http://fallout.wikia.com/wikia.php?controller=LatestPhotos&format=json (call 
controller, just return the data that would have been in the template)

The default method is executeIndex() and the default template is 
<controller>_Index.  Here’s the controller code:

https://github.com/Wikia/app/blob/dev/skins/oasis/modules/LatestPhotosController.class.php#L21

And the template:

https://github.com/Wikia/app/blob/dev/skins/oasis/modules/templates/LatestPhotos_Index.php

Hope that helps provide a bit more context for how this is actually used in the 
application.  

-Owen


> ~Matt Walker
> Wikimedia Foundation
> Fundraising Technology Team
> 
> 
> On Fri, Dec 27, 2013 at 6:44 PM, Owen Davis <[email protected]> wrote:
> 
>> Ha.  Well, we’ve been using mustache at Wikia for a while, but not
>> heavily.  The backstory is that we’ve written approximately 270 extensions
>> over the years and we have written a few simple frameworks to keep that
>> code manageable.  One of those things is a pseudo-mvc framework.  The
>> template itself is not an object, and it can be either a PHP or mustache
>> template.  A mustache template has more limitations, but in many cases it
>> is sufficient and in general I feel like it’s a better idea to just pass
>> data to a simple template rather than having a lot of logic in the
>> template.  Additionally, being able to share the same template between
>> front end and back end has advantages.
>> 
>> In my opinion, backwards compatibility with the existing quick template
>> stuff is impossible to avoid, so retaining a PHP option is essential but
>> the mustache option gives a lot of power to the front end developers which
>> is where a lot of the work is being done now…
>> 
>> For example, the modal dialog that pops up at the end of the new wiki
>> creation process is a mustache template:
>> 
>> 
>> https://github.com/Wikia/app/blob/dev/extensions/wikia/CreateNewWiki/templates/FinishCreateWiki_WikiWelcomeModal.mustache
>> 
>> On Dec 27, 2013, at 8:41 AM, Niklas Laxström <[email protected]>
>> wrote:
>> 
>>> 2013/12/27 Tyler Romeo <[email protected]>
>>> 
>>>> If we want a comprehensive templating system in PHP core,
>>>> 
>>> 
>>> I want a templating system that can be used both in PHP and JavaScript
>> and
>>> fits in our way of doing i18n. And a bunny.
>>> 
>>> -Niklas
>>> _______________________________________________
>>> Wikitech-l mailing list
>>> [email protected]
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> 
>> 
>> _______________________________________________
>> Wikitech-l mailing list
>> [email protected]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> 
> _______________________________________________
> Wikitech-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to