Propojení C++, Qt, HTML a Javascriptu

11.6.2014 11:30 | Přečteno: 2201× | Počítače | | poslední úprava: 11.6.2014 11:26

Kterak propojit C++ a Web v praktické aplikaci.

Ve firmě Hobrasoft vyvíjíme distribuovaný CRM systém Deko the CRM. Různých CRM systémů jsou na světě mraky, takže přijít s něčím novým je obtížné. Za výhodu našeho CRM považujeme nezávislost na připojení k internetu. Databáze CouchDB, na které je aplikace postavená, dovolí uživatelům pracovat offline a přitom nejsou nijak omezení ve sdílení dat. Deko je určené jak pro Windows, tak pro Linux.

Jedním z úkolů, před které nás potřeby aplikace postavily, byly tiskové sestavy. Celá aplikace je napsaná v C++ a Qt, takže se nabízela možnost použít C++ i pro tvorbu sestav. Ale tvořit něco v C++ je nepružné i pro nás a představa, že by si mohl uživatel sám vytvořit sdílenou knihovnu se sestavou je čirá utopie. Jak z takové situace ven?

Můj první nápad byl vlastní tabulkový kalkulátor vestavěný v aplikaci. Uživatelé jsou na tabulky zvyklí, nemuselo by jim to činit potíže. Malý průzkum bojem ale ukázal, že potíže by mohl činit tabulkový kalkulátor nám - naprogramovat něco použitelného je pracné.

Druhý nápad bylo použít HTML. Něco vzdáleně podobného už jsme měli hotové:

http://weko.hobrasoft.cz/timesheet/default/288KFTU

Ale to je napsané v PHP a potřebuje to celý ten veliký cirkus spojený s webovými aplikacemi - http server, php interpreter a napojení na databázi (u každého uživatele jiné).

Naštěstí k provádění nějakého programu ve webovém prohlížeči není potřeba PHP, webové prohlížeče už léta dokáží zpracovávat JavaScript a knihoven pro manipulaci HTML stránek je spousta. Spousta je i programátorů - na rozdíl od C++ dnes HTML a Javascript zvládá velké množství lidí.

Takže stačí už jen napsat a připojit k aplikaci webový prohlížeč. V Qt je situace jednoduchá: stačí přilinkovat webkit.

Sestavy obvykle čerpají své podklady z nějaké databáze. Databázi je proto nutné zpřístupnit i do webového prohlížeče. Prohlížeče získávají data dvojím způsobem: pomocí url, například:

http://hobrasoft.cz/cs/deko

nebo přes JavaScript, každý prohlížeč ve speciálním objektu document zpřístupňuje zobrazovanou html stránku:

var html = document.documentElement.outerHTML;

V aplikaci Deko jsme databázi zpřístupnili podobně. Jednak přes speciální url:

deko:///id-dokumentu-v-databazi

nebo přes objekt JavaScriptu:

var dokument = deko.get('id-dokumentu-v-databazi');

Vestavěný webkit se k tomu dá donutit poměrně snadno.

Speciální URL schéma deko

Třída WebView obsahuje webovou stránku, u níž musíme přepsat třídu QNetworkAccessManager, aby rozuměla i našemu schematu deko, zajistí to pár řádků kódu:

QNetworkAccessManager *om = f_view->page()->networkAccessManager();
REPORT_access_manager *nm = new REPORT_access_manager(om, this);
f_view->page()->setNetworkAccessManager(nm);

Původní QNetworkAccessManager je nahrazený naším vlastním. Nedělá nic jiného, než že ověří url schema a pokud je schéma deko, vytvoří vlastní odpověď, jinak zavolá standardní proceduru:

class REPORT_access_manager : public QNetworkAccessManager {
    Q_OBJECT
  public:
    REPORT_access_manager(QNetworkAccessManager *, QObject *);
    QNetworkReply *createRequest( QNetworkAccessManager::Operation, 
                                  const QNetworkRequest&, 
                                  QIODevice*);
};

REPORT_access_manager::REPORT_access_manager(
                QNetworkAccessManager *manager, 
                QObject *parent) : QNetworkAccessManager(parent) {
    setCache        (manager->cache());
    setCookieJar    (manager->cookieJar());
    setProxy        (manager->proxy());
    setProxyFactory (manager->proxyFactory());
}

QNetworkReply *REPORT_access_manager::createRequest(
        QNetworkAccessManager::Operation operation, const QNetworkRequest &request,
        QIODevice *device) {
    if (request.url().scheme() != "deko") {
        return QNetworkAccessManager::createRequest(operation, request, device);
        }

    if (operation != GetOperation) {
        return QNetworkAccessManager::createRequest(operation, request, device);
        }

    return new REPORT_reply (request.url());
}

Vrácená odpověď je mírně rozšířená třída QNetworkReply

class REPORT_reply : public  QNetworkReply {
    Q_OBJECT
  public:
    REPORT_reply(const QUrl&);
    void    abort() {} ;
    qint64  bytesAvailable() const;
    bool    isSequential() const { return true; }
  protected:
    qint64 readData(char *data, qint64 maxSize);

  private:
    QByteArray content;
    qint64 offset;
};

REPORT_reply::REPORT_reply(const QUrl& url) {
    offset = 0;
    open(ReadOnly | Unbuffered);

    // REQUEST je naše třída pro přístup do databáze, vrací obvykle JSON řetězec
    // Při vaší vlastní implementaci sem doplňte vlastní přístup do databáze
    REQUEST rq;
    rq.setBinary(true);
    rq.get(url.path().toUtf8());
    content = rq.data();

    setHeader(QNetworkRequest::ContentTypeHeader, rq.contentType().toString());
    setHeader(QNetworkRequest::ContentLengthHeader, QVariant(content.size()));

    QTimer::singleShot(0, this, SIGNAL(metaDataChanged()));
    QTimer::singleShot(0, this, SIGNAL(readyRead()));
    QTimer::singleShot(0, this, SIGNAL(finished()));
}

qint64 REPORT_reply::bytesAvailable() const {
    qint64 bc = content.size() - offset;
    return bc;
}

qint64 REPORT_reply::readData(char *data, qint64 maxSize) {
    if (offset < content.size()) {
        qint64 number = qMin(maxSize, content.size() - offset);
        memcpy(data, content.constData() + offset, number);
        offset += number;
        return number;
    } else {
        return -1;
        }
}

Objekt deko v JavaScriptu

K webové stránce zobrazené ve webkitu lze snadno připojit libovolný QObject:

QWebFrame *frame = f_view->page()->mainFrame();
frame->addToJavaScriptWindowObject("deko", m_report_script);

Pod jménem deko bude objekt m_report_script přístupný ve webové stránce pomocí JavaScriptu.

U tohoto objektu uvedu pouze deklaraci, samotný kód už není tak důležitý:

class REPORT_SCRIPT : public QObject {
    Q_OBJECT
  public:
    REPORT_SCRIPT(QObject *parent);

    Q_INVOKABLE QString     id();
    Q_INVOKABLE QVariant    get(const QString& id);
    Q_INVOKABLE QVariant    document(const QString& id);
    Q_INVOKABLE QVariant    linksToMe(const QString& id);
    Q_INVOKABLE QVariant    linksFromMe(const QString& id);
    Q_INVOKABLE QString     hash(const QString& text);
    Q_INVOKABLE void        begin() { emit jobBegin(); }
    Q_INVOKABLE void        end()   { emit jobEnd(); }
    Q_INVOKABLE QString     userid();

  signals:
    void        jobBegin();
    void        jobEnd();

};

Makrem Q_INVOKABLE deklaruji metodu jako přístupnou z JavaScriptu. Zajímavé je předávání výsledné hodnoty (podobně lze předávat i parametry). Vrací-li metoda QVariant, použije se v JavaScriptu taková hodnota jako objekt. V C++ vypadá vytvoření takového objektu například takto:

QVariantMap data;
data["_id"] = "id-meho-objektu";
data["name"] = "Jmeno objektu";

QVariantList list;
list << "abcd" << "1234";
data["list"] = list;

return data;

V Javascriptu se interpretuje stejně, jako by se interpretoval tento JSON literár:

{ "_id": "id-meho-objektu", "name": "Jmeno objektu", "list": [ "abcd", "1234"] }

V Javascriptu je použití snadné:

var x = deko.metoda();
var id = x._id;
var name = x.name;
for (var i=0; i<x.list.length; i++) {
    // Udělej něco
    neco( deko.list[i] );
    }

Jak může vypadat výsledek

Nakonec několik ukázek: Vestavěná google mapa, hotová sestava a kus zdrojového tvaru sestavy. S webkitem dostanete i luxusní debugger - ten je vidět na posledním obrázku.

       

Obrázky

Komentáře

[unicode]

Uf, ty názvy tříd, to je teda něco

[Lemon]

+1, očividně práce nějakého brigádníka

[theo]

Názvy tříd jsou úplně normální (to, že se ti nelíbí kombinace podtržítek a velkých a malých písmen je tvůj problém). Když autor nechce z nějakého důvodu používat jmenné prostory (což chápu, protože to dokáže - v rozporu s všeobecným přesvědčením - kód znepřehlednit), tak je tenhle model docela jednoduchý, přímočarý a snadný na pochopení. Podstatné je přeci to, aby to bylo v celém kódu konzistentní, ne to, jestli je to psáno nějak jak se zrovna tobě nelíbí.

Z takto krátké ukázky to nemusí být jasné, ale má to svoji logiku: QNetworkAccessManager je Qt komponenta a REPORT_access_manager je komponenta aplikace. Určitě by se to dalo napsat i jinak, ale v zásadě v tom nevidím problém.

Jestli vývojáře, nebo kvalitu kódu posuzuješ podle toho jak jsou pojmenované třídy, tak nad knihovnou VMime budeš patrně ucvrnkávat blahem až do chvíle, kdy se s ní pokusíš něco skutečně naprogramovat...

[herberd]

No pakliže ti přijde normální pojmenovávat třídu stylem makra, tak se prosím identifikuj, abych na tebe nikde u nějakého projektu nenarazil

[Rezza]

Ha, ja se na ten kod mrknul jen mrknutim a rikam si, co tam maji za REPORT makro :D.

[unicode]

To snad ani nemá cenu komentovat, chce to klid chlape

[Josef Kufner]

Je to proti zavedeným konvencím a ztěžuje to orientaci novým programátorům, tvým budoucím kolegům, což zvyšuje náklady na budoucí vývoj a tím pádem se připravuješ o peníze. A navíc je to hnusný.

Qt třídy jsou identifikovány velkým Q na začátku. Takže QNetworkAccessManager a ReportAccessManager, nebo ještě lépe Report::NetworkAccessManager.

[Marvin]

CamelCase... jdu blejt...

[leo]

U tříd se to snese

[Petr Bravenec]

Přijde mi to jako první příspěvek k věci. Popřemýšlím

[kralyk z abclinuxu]

+1

[leo]

a jéje, ostřílený PHP kodér nám dává lekce z C/C++ konvencí

[xkucf03]

Díky za zápisek. Taky se chystám pustit do jednoho projektu s Qt(WebKitem), tak mě potěšilo, že tam jsou tyhle věci celkem jednoduché.

Ta VELKÁ písmena a podtržítka v názvech tříd se mi taky nelíbí, ale nevím, jaké jsou konvence v okolním kódu, tak to nechci hodnotit.

Mám ale jednu věcnou připomínku k návrhu: jak funguje třída REQUEST („…je naše třída pro přístup do databáze“)? To je nějaký singleton? Kde vezme spojení do databáze nebo jiné zdroje? IMHO by bylo lepší, aby je dostávala jako parametr z toho kontextu, ve kterém je používána, ne že si je někde obstará sama.

[Petr Bravenec]

Ta třída REQUEST singleton není. Spojení do databáze si obstarává z konfiguračních souborů (zjednodušeně řečeno). Podle kontextu, kde se třída používá, se dá nastavení samozřejmě změnit.

Ve většině případů se aplikace připojuje na jedinou databázi, parametry jsou pořád stejné. Jen vyjímečně se připojuje jinam - pak se parametry berou obvykle z nějakého formuláře a nastavují se extra.

Qt něco podobného používá pro SQL databáze. Třída QSqlDatabase se dá jednou na začátku nastavit a pak se pro připojení používá pořád stejný objekt, který se instancuje pouze v jiných vláknech.

Jinak souhlasím s tím, že webkit se v Qt používá celkem snadno a umí spoustu věcí. Kdysi jsem řešil třeba grafy pro Qt, neúspěšně. Dneska bych jen udělal most do c++ a přehodil grafy na kolegu, který dělá s HighCharts weby. Umí v tom dělat kouzelné věci:

http://www.hobrasoft.cz/cs/teplomer

Normálně to ukazuje graf dva dni dozadu, ale nešťastně jsem si zrušil data.

[WNJ]

Nema CouchDB zabudovane RESTove api? Pak by mohlo byt lehci z toho javascriptu sahat rovnou tam, nez to honit pres api webkitu?

[Petr Bravenec]

No to samozřejmě CouchDB má. Ale v momentě, kdy to udělám, není taková sestava přenosná z jedné databáze do druhé, protože součástí takové sestavy by byla i absolutní adresa na jeden konkrétní databázový server. Při tomto řešení mám adresu zcela nezávislou na databázi, databáze je všude přístupná přes url deko:/// nebo Javascriptový objekt deko.

[Josef Kufner]

Pokud chceš přenositelnost, tak deko:// nepoužívej v HTML kódu a k databázi jen přes Javascriptový objekt. Jinak budeš mít problémy, jakmile to budeš chtít zveřejnit na obyčejném webu. Tam deko:// nedostaneš, ale udělat proxy objekt je relativně snadné. Vlastní protokol je dobrý na zpřístupnění obsahu v rámci aplikace, ale není dobré na to odkazovat.

[Petr Bravenec]

...proxy objekt...

To mě zajímá. Nevyznám se příliš ve webových technologiích, nevím, co si pod tím představit.

Jinak vlastní protokol používám právě proto, že nepředpokládám použití jinde, než v rámci aplikace. Navíc v režimu, kdy předem nevím, jak připojení k databázi vypadá a kdy jednu sestavu může používat více lidí s naprosto odlišným připojením k databázi.

[Josef Kufner]

Vlastní protokol je fajn pro předání dat do QWebView. Ale samotné stránky by měly používat jen URL od lomítka dál. Tedy buď relativní, nebo jen absolutní cesty bez protokolu i serveru. Například /hello/world namísto http://example.org/hello/world či deko:/hello/world. Pak je můžeš vzít jak jsou a poslat po HTTP do běžného prohlížeče.

No a aby fungovalo připojení k databázi, tak místo deko objektu, který máš teď, tam dáš proxy objekt, což je v Javascriptu implementovaný obyčejný objekt přeposílající volání metod na server a vracející obdržené odpovědi. Na serveru pak bude za nějakým HTTP API schovaný skutečný deko objekt, který udělá všechnu dřinu. Pokud proxy i originál budou mít stejné API, můžeš bezezměn zveřejnit tiskové sestavy na webu i v aplikaci a navíc to bude skoro bez práce (stačí udělat jen ten proxy objekt a aplikaci spustit jako démona bez GUI).

Pointa je v tom, aby jsi si teď nezadělal na problémy v budoucnu, kdy s tím budeš chtít něco dělat a budeš mít spoustu hotových sestav.

[Petr Bravenec]

Aha, díky. Už rozumím. Je zajímavé, že to nejjednodušší řešení mě nenapadlo. Upravit NetworkAccessManager by mělo být jednoduché - prostě budu hledat místo protokolu deko url bez protokolu. A zbavovat se objektu deko v JavaScriptu není nutné - knihovnu s api můžu doplnit později, aniž by se musely sestavy upravovat.

[Josef Kufner]

V NetworkAccessManageru nemusíš nic upravovat, QWebView relativní adresy přeloží na absolutní před tím, než se NetworkAccessManageru zeptá na jejich obsah. Jde jen o to, co je napsané v HTML, aby to fungovalo i na http:// i na deko://.

Objektu deko v Javascriptu se nezbavuj, naopak, používej ho pro veškerou komunikaci, abys nemusel používat deko protokol. Právě proto, že vyměnit implementaci JS objektu a zachovat jeho API je snadné, kdežto implementovat deko:// v prohlížečích je obtížné.

[Petr Bravenec]

QWebView relativní adresy přeloží... ale má to potíž. Musím nějak doplnit ten úvod - nastavit baseUrl. V aplikaci můžu nastavit deko:// a pak to funguje dobře. Je předpoklad, že to bude fungovat dobře i v prohlížeči, když tomu poskytnu ty relativní cesty.

Moc se s tím ale nevyrovná debugger webkitu, místo zdrojového tvaru skriptu mi ukáže jen nějaké base64 smetí (následek změny baseUrl). Ráno jsem se s tím chvíli trápil. Zkusím rozeznávat požadavky do mojí aplikace třeba podle http://localhost/, ale chce to trochu času a testů.

Objektu deko se samozřejmě zbavovat nebudu - že můžu vyměnit implementaci v C++ za JS si uvědomuji velice dobře.

Každopádně díky za nápad. Tohle ze zřetele jen tak nepustím.

[Josef Kufner]

Nějaké baseUrl by vůbec nemělo být potřeba nastavovat. Prosté QWebView::setUrl("deko:/hello/world/"); by mělo stačit.

[Petr Bravenec]

QWebView::setHtml( html, QUrl("deko:///hello/world") );

Html se bere z externího editoru

[Josef Kufner]

A proč to nenecháš jít celé přes NetworkAccessManager?

[WNJ]

Aha, bral jsem to tak, ze ta CouchDB bezi na lokale u klienta spolu s tou QT aplikaci, takze se k ni da pripojit nejak lokalne.

Ono na tom nesejde, to rozhrani mezi webkitem a zbytkem vypada prekvapive prijemne, jenom jsem se zajimal proc to neudelat takhle.

[Petr Bravenec]

Ve většině případů to tak je - aplikace i databáze skutečně běží lokálně. Ale v principu to tak být nemusí, navíc se může databáze jmenovat jakkoliv - a dávat do sestavy parametry pro připojení, to se mi opravdu nechce.

Napadla mě ještě jedna věc - cache. CouchDB je pomalá, aplikace díky keším ?dokáže sestavu hodně urychlit.

A nakonec mě napadla ještě jedna věc - vytáhnout z databáze některé informace není triviální. Pokud to může udělat aplikace, je to jen dobře.