Nekompatibilní rozšíření Flasku

Flask netřeba dlouze představovat. Ve zkratce se jedná se o mikroframework pro programování webových aplikací v Pythonu a nutno dodat, že velice povedený (o čemž svědčí i jeho rostoucí popularita [1]).

Slovíčko „mikro“ v názvu je velice podstatné, neboť Flask samotný nabízí pouze základní funkce pro obsluhu requestů a navíc přidává integrovaný jinja2 šablonovací systém (IMHO nejlepší šablonovací systém pro python, ten z djanga se s ním nemůže rovnat). Důležité je, že když potřebujete další funkcionalitu (v rámci flasku), musíte si ji buď napsat sami, nebo sáhnout po nějakém z rozšíření (kterých rozhodně není málo).

Jenže… Tak jako „mikro“-kernel většinou trpí přílišnou roztříštěností, tak byla jen otázka času, než něco podobného potká i „mikro“-framework. Vše by bylo v pořádku, kdyby se tvůrci rozšíření mezi sebou gentlemansky dohodli a stanovili si jasná pravidla. Jenže…

Když například chcete použít skvělé rozšíření Flask-Admin, musíte k němu použít i Flask-BabelEx (pro i18n). Flask-BabelEx je rozšíření, které vzniklo forknutím Flask-Babel a to proto, že původní verze neobsahovala možnost cachování překladů. Pro vícejazyčné weby, které překládají desítky řetězců na stránce docela podstatná věc. Říkáte si, ok, tak se použije Flask-BabelEx. Jenže… Když chcete použít Flask-WTF (integrující skvělou knihovnu WTForms) pro validaci a zpracování formulářů, narazíte na problém. Flask-WTF totiž používá Flask-Babel… Přepíšete proto nastavení překladů v kontextu „wtforms_translations“ na funkce gettext a ngettext z Flask-BabelEx a ejhle: sem tam to vyhodí výjimku (při doplňování parametrů do překládáného řetězce)…

Čímdál častěji uvažuji nad tím, jestli by nestálo za to vzít to nejlepší z Flasku (routování cest, přístup ke kontextovým proměnným, jinja2 atp.) a udělat nový monolitický framework… Django mi totiž vadí v několika ohledech: mizerné ORM, horší šablonovací systém a právě routování URL cest. Ale tuhle pohádku až někdy příště…

[1] http://flask.pocoo.org/com­munity/poweredby/