Wome... is your fwiend!

Znáte sandman? Ten mě inspiroval k vytvoření jednoduché ukázky modellerkitu. Abych připomněl o co jde: Chci systém, pro tvorbu uživatelských rozhraní, ve kterém při změně dat nemusím říkat: Zaktualizuj to tady a tady, pak přepočítej tamto, a zobraz to. Naopak, jak je v MVC zvykem, při změně dat (čili modelu) ta data řeknou: Změnili jsme se!, a kdo poslouchá, ten může patřičně reagovat. Jestli chcete, projděte si detaily…

Cítím jistou potřebu napsat, jak celá věc s modelováním pokračuje, ikdyž teď v létě mám poněkud méně času, než jsem myslel. Tentokrát ani nebudu dávat odkaz na předchozí díl, jen připomenu o co se snažím: Udělat v Pythonu takovou datovou strukturu, která při změně vygeneruje událost. V Pythonu je ovšem problém odchytávat obecně přiřazení a změny hodnot v proměnných. Na nejvyšší úrovni (object_a.data = 382) to jde, ale jakmile udělám object_a.data = [1, 2, 3,], tak odchytit object_a.data[2] = 56 

Nejprve bych rád poděkoval pajovi, který mě svými komentáři navedl na deskriptory. Vypadá to, že dost zjednoduší zápis. Ale o tom až jindy. Minule jsem slíbil, že vyzkouším jiný přístup, kdy view se tváří jako model. Můžeme jít na to: sidestep01. Tentokrát tedy nebudeme dělat žádný oddělený model, ale naše okno naučíme normálně reagovat na přiřazení, ať už jako levou nebo pravou stranu…

V minulém díle jsme si udělali hierarchii a přidali malý nástroj na mapování události na obslužnou funkci. Dnes si to můžeme dát všechno dohromady, ať konečně vidíme, o co mi celou tu dobu jde. Opět tedy github/modellerkit, tentokrát step06. Zase k tomu budeme potřebovat wxPython. Tak rovnou do toho. Spusťte si view01.py. To hlavní, čeho jsem chtěl dosáhnout najdeme navěšené na tlačítka…

Minule jsme už měli horké objekty uvnitř horkých objektů – např. HotList v HotObject, ale když přišlo na to, pověsit si event listenery, tak jsme se dostali do slepé uličky. Připomeňme si, co vlastně děláme. Náš model vypadá logicky takto: /---pre class ProductModel(object): def __init__(self, server): self.server = server self.article = "" self.sn = 0 self.process = [] self.operations = [] \---

S novým Firefoxem mi začaly chodit požadavky, zda bych přece jen ještě ten SEO Profesional Toolbar (dál mu budu říkat SEOP) nezaktualizovat. Přemluvili mě docela snadno. Přes 2 roky jsem na to ani nešáhl, a taky jsem skoro všechno zapomněl. Sem napíšu pár poznámek o tom, jak to vlastně šlo. addon-bar ne, nav-bar ano

Začnu jinak, než jak jsem minule zamýšlel. Zkusím se rovnou zaměřit na skoro skutečnou situaci. No, dobře, ne úplně skutečnou, ale podobnou tomu, co občas sám dělám. Budu chtít implementovat celý model jako jeden objekt, který mi bude při změně „vystřelovat“ nějaké události. A teď ta skoro skutečná situace: Máme nějakou sadu výrobků. Při přečtení čárového kódu na výrobku chceme zobrazit informace o něm…

Minule jsem zmínil, že můžeme chtít také v modelu spravovat vybranou položku. Tady už nastává oboustraná komunikace mezi view (neboli tím vlastním oknem nebo ovládacím prvkem) a modelem. View musí modelu sdělit, že se změnila vybraná položka, naopak model musí „odpálit“ zprávu když se změní vybraná položka. Jenže tady nám vzniká potenciální problém. View řekne modelu: nastav výběr na pátou položku…

Když jsem tak před deseti lety viděl Java Swing, bylo to jako zjevení. V porovnání s tím, jak se bastlilo uživatelské rozhraní jinde (GTK, YAST, MFC), tohle mělo hlavu a patu. Pro neznalé: Figurují v tom modely a listenery. Ovládací prvek (Komponenta UI, Widget, Control, ať už tomu říkáme jak chceme) má model. Obsah prvků neměníme na tom prvku, ale úpravou obsahu modelu…

V komentářích za mým předchozím blogpostem se objevila otázka na to, jak velký projekt se dá zvládat ve vimu (nebo obecně textovém editoru) bez IDE. Tak jsem se rozhodl spočítat soubory a řádky ve svých největších projektech. Vyšlo mi toto: Projekt Souborů Řádků Desktopový klient 193 49000 Webový výrobní IS 307 64000 Jiný webový výrobní IS 144 21000 Webový interface k ERP 174 35000