Propojení C++, Qt, HTML a Javascriptu (diskuse)

[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.