Как у нас построен процесс разработки.

Когда я только начинал делать что-то в web, в принципе не было понятия “верстальщик”. Каждый, кто делал сайты, делал весь спектр задач: от настройки базы данных до написания javascript кода.

Сейчас индустрия web настолько обширна, что узкая специализация - это норма. Например, у нас в компании есть служба эксплуатации, у них даже есть отдельный DBA. Server side программисты и Frontend программисты, однако, выделенных верстальщиков у нас нет.

Вообще я, общаясь с разработчиками из разных компаний, встречаю две основных схемы работы с людьми, которых называют верстальщиками.

В первой схеме есть основной workflow выполнения задачи. За техническую часть отвечает программист, server side программист. Когда для задачи нужна верстка - верстальщику отдают макет, а он программисту отдает HTML.

У этой схемы есть плюсы:
— можно сильно снизить требование к квалификации верстальщика;
— с первого взгляда задачи легко отдаются на outsource.

Но минусы этой схемы куда серьезнее плюсов:
— создает код один человек (CSS, JS, картинки), а организовывает его другой человек.
— на production баг, в макете от верстальщика все хорошо, а на сайте нет - что делать?

Есть другой вариант — повысить требование к верстальщику и отдать в его ответственность инструмент, который генерирует конечный код для браузера. Я не правильно выразился, верстальщику надо самому повысить свою квалификацию и сделать это.

При такой схеме вы уже не верстальщик, а Frontend разработчик. Работа server side программиста заканчивается генерацией некоторого документа (XML, JSON ...), который вы превращаете во что-то, что понимает браузер. Никто лучше вас не знает client side, вам и надо полностью контролировать, что туда уходит. Вопроса “К кому идти, если в браузере что-то не так?” больше нет, виноваты всегда вы, если виноват сервер сайд - придут к вам, а вы уже разберетесь что к чему.


Frontik

Итак, с целью определились, ее надо как-то достичь..

Что нам надо:
— возможность забирать данные от программистов;
— мощный шаблонизатор;
— удобный инструмент для написания логики представления.

Вообще весь мой опыт говорит о том, что server side и frontend плюс client side - это два очень разных мира. С разными задачами, и их лучше не смешивать, а самое лучшее - технически разнести как можно дальше друг от друга. Плюс время, когда один проект живет на одном сервере, давно прошло. Сейчас сайт - это несколько программных продуктов, которые взаимодействуют между собой. Раз мы уже имеем сетевое взаимодействие, то и frontend c server side мы решили отделить друг от друга посредством http протокола.

Естественно мы не первые кто пытался решить эту задачу. Более того в 2007 году было два решения от ведущих российских компаний:
— XScript, Янндекс
— FEST, Mail.ru

Оба решения поддерживали работу по HTTP, что нас полностью устраивало.

Мы выбрали решение от Яндекса:
— оно уже тогда было c открытом коде;
— успешно работало несколько лет;
— давало вестальщикам не скудный самописный шаблонизатор, а всю мощь и силу XSLT.

Мы успешно прожили на нем около года, но к сожалению он удовлетворял только двум требованиям из трех. Писать на нем более менее сложную логику очень не удобно. А для решения некоторых задач требовалось модифицировать сам XScript.

Раз встала необходимость его модификации, нам захотелось решить задачу совсем по другому — взять язык программирования и добавить в него все то что нам нравилось в XScript.

Существует множество инструментов для удобной работы по http, за базу мы взяли tornado. Tornado позволяет сходить по HTTP за документом и выполнить функцию, когда этот документ будет получен, отдав ей на вход этот самый документ.

Теперь шаблонизатор. Тут вариантов не было, однозначно XSLT.

Бонусом ко всему мы получаем полноценный язык, на котором мы можем как-то работать с данными от сервера — Python.

В остатке, frontik обеспечивает:
— диспетчеризацию урлов;
— HTTP опрос backend;
— парсинг, обработку и интеграцию ответов в xml;
— XSLT трансформацию.

Пример страницы “Hello world”.
class Page(frontik.page.PageHandler):
  @set_xsl('helloworld.xsl')
  def get_page(self, request):
    res = etree.Element('hello')
    res.text = 'world'
    self.doc.put(res)

Или пример с походом за данными
def cb(xml, response):
  nodes = xpath.Evaluate(..., xml)
  if not nodes:
    finish('Nothing found!')
  else:
    ...
self.get_url(request, cb)

Легкая вставка данных в результирующий xml документ
placeholder = self.get_url(...)
self.doc.put(placeholder)

self.get_url возвращает plaseholder, который будет заполнен данными, когда ответит сервер


Гибкость разработки

Обычно frontend очень сильно ограничен узким набором инструментов. В случае с frontik у нас в распоряжении python и мы можем себе многое позволить.

Например, у нас сайт мультиязычный - это означает, что в верстке у нас есть ключи, а варианты текстов хранятся в базе. Но браузеру мы должны отдавать страницу с текстами, а не с ключами.

Сначала мы на frontik вместе с данными запрашивали и тексты переводов, передавая все ключи, которые могли встретиться на странице. Это очень неудобно, замедляло разработку, а самое неприятное что логика выбора ключа сосредоточена именно в xsl. Однако после xsl мы уже знаем, какие из переводов понадобились и других точно не будет.

XSL трансформация - это всего-лишь одна из стадий работы frontik, и мы просто добавили еще одну стадию.

Было: XML → XSL → HTML
Стало: XML → XSL → Пост-обработка → HTML

Логика выбора переводов осталась на XSL, где ей самое и место, но оперирует она только с ключами. Пост-обработка берет HTML и заменяет в нем ключи на конечные тексты.

Заключение

Еще один из больших плюсов frontik - это сквозной python. Вы кадый день что-то пишете и дебажите на python. Если что-то не так в самом frontik или даже tornado, то вы как обычно берете и дебажите python, что вы и так делаете каждый день по много часов.

Frontik на github
http://github.com/hhru/frontik

Проект на frontik (hh api + yaru api).
http://github.com/AndrewSumin/hephaestus