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/LatestPhotosContr…
And the template:
https://github.com/Wikia/app/blob/dev/skins/oasis/modules/templates/LatestP…
Hope that helps provide a bit more context for how this is actually used in the
application.
This is very cool, Owen. Once we have a templating engine picked out, conventions like
this make life easier.