Autor Téma: Hlúpy formulár - ako naň  (Přečteno 3602 krát)

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 7392
  • Karma: 44
    • Verze Delphi: W11 + D11.3.1
Hlúpy formulár - ako naň
« kdy: 07-09-2017, 11:43:10 »
Podľa tohto fóra a múdrej knihy má byť formulár totálne hlúpy = nemá nič robiť.
Z môjho pohľadu to delím na dve časti:
  1) interface - type
    a) definovanie vlastných typov. Typicky record pre VST.
    b) definície tried
  2) Všetky udalosti všetkých komponentov na formulári

Bod 1) To by som mal v budúcnosti vyriešiť vďaka Delfin pomocou MVC

Bod 2) Tu som úplne mimo obraz. Nemám žiadnu predstavu ako na to. Veď každý formulár je úplne iný a tých udalostí má požehnane. Verziu, že formulár má byť prázdny a jeho obsah mám vytvoriť dynamicky (pomocou MVC) som okamžite zavrhol.

Ako sa to vlastne robí? Nejaký odkaz, typ, kľúčové slová pre hľadanie na internete... Jednoducho hocčo čo by mi pomohlo.
Ďakujem.
Win11 64b, Delphi 11.3.1, FireBird 4.01
Expert na kladenie nejasne formulovaných otázok.

Offline pepak

  • Padawan
  • ******
  • Příspěvků: 1574
  • Karma: 37
    • Pepak.net
Re:Hlúpy formulár - ako naň
« Odpověď #1 kdy: 07-09-2017, 19:14:53 »
Podľa tohto fóra a múdrej knihy má byť formulár totálne hlúpy = nemá nič robiť.
Podle mě je to totální blbost. Sice v souladu s moderními programovacími technikami a odpovídá to technice MVC, ale přesto totální blbost. Tam, kde chci mít hloupé UI, to snad jakž takž dává smysl, ale pokud chci uživateli nabídnout pohodlí, tak to dokážu leda s vynaložením naprosto absurdního množství úsilí a krajně nepřehledného kódu. Ano, MVC má i své výhody, ale upřímně - za svou programátorskou praxi jsem se setkal maximálně v jednotkách případů, že to nebylo YAGNI.

Citace
Bod 2) Tu som úplne mimo obraz. Nemám žiadnu predstavu ako na to. Veď každý formulár je úplne iný a tých udalostí má požehnane. Verziu, že formulár má byť prázdny a jeho obsah mám vytvoriť dynamicky (pomocou MVC) som okamžite zavrhol.
No a jsi u toho, kde je slabina MVC...

96899

  • Host
Re:Hlúpy formulár - ako naň
« Odpověď #2 kdy: 07-09-2017, 19:28:11 »
Bod 2) Tu som úplne mimo obraz. Nemám žiadnu predstavu ako na to. Veď každý formulár je úplne iný a tých udalostí má požehnane. Verziu, že formulár má byť prázdny a jeho obsah mám vytvoriť dynamicky (pomocou MVC) som okamžite zavrhol.

Opravdu je kazdy uplne jiny? Myslim tim funkcionalitou? Nebo delaji to same jen kazdy s jinou sadou typu nad ruznymi tabulkami?

S tim modelem se daji tvorit oba zpusoby. Tedy bud psat pro kazdy form kod separatne (s tim ze pokud je funkcionalita shodna, kod opakujici se). Ten model bude mit pro storage pristup pres As<T> accessory (jak jsme se dohodli). Takze i s tim modelem budes moci vytvorit recordy a z modelu je nasypat (coz prinese riziko chyb upsanim se a zvysi vyuziti pameti). Ale zvaz zda maji ty typy opravdu smysl.

Bud neco ve stylu ktery nejspis pouzivas:

Kód: Delphi [Vybrat]
  1. type
  2.   PNodeData = ^TNodeData;
  3.   TNodeData = record
  4.     MyInt8: Int8;
  5.     MyInt16: Int16;
  6.     MyString: string;
  7.   end;
  8.  
  9. var
  10.   Row: IDataRow;
  11.   Data: PNodeData;
  12.   Node: PVirtualNode;
  13. begin
  14.   Row := DataView.Rows[0];
  15.   Node := VirtualTree.AddChild(nil);
  16.  
  17.   Data := VirtualTree.GetNodeData(Node);
  18.   Data.MyInt8 := Row.AsInt8['Col1'];
  19.   Data.MyInt16 := Row.AsInt16['Col2'];
  20.   Data.MyString := Row.AsString['Col3'];
  21. end;
  22.  
  23. procedure TForm1.VirtualTreeGetText(Sender: TBaseVirtualTree; Node: PVirtualNode;
  24.   Column: TColumnIndex; TextType: TVSTTextType; var CellText: string);
  25. var
  26.   Data: PNodeData;
  27. begin
  28.   Data := Sender.GetNodeData(Node);
  29.   case Column of
  30.     0: CellText := IntToStr(Data.MyInt8);
  31.     1: CellText := IntToStr(Data.MyInt16);
  32.     2: CellText := IntToStr(Data.MyString);
  33.   end;
  34. end;

Nebo jednoduse prilinkujes k VT radky (implementace metody IDataRow.ToString bude prevadet hodnotu na text a to i s moznosti pouzit predany formatovaci objekt):

Kód: Delphi [Vybrat]
  1. type
  2.   PDataRow = ^IDataRow;
  3.  
  4. var
  5.   Data: PDataRow;
  6.   Node: PVirtualNode;
  7. begin
  8.   Node := VirtualTree.AddChild(nil);
  9.   Data := VirtualTree.GetNodeData(Node);
  10.   Data^ := DataView.Rows[0];
  11. end;
  12.  
  13. procedure TForm1.VirtualTreeGetText(Sender: TBaseVirtualTree; Node: PVirtualNode;
  14.   Column: TColumnIndex; TextType: TVSTTextType; var CellText: string);
  15. var
  16.   Row: PDataRow;
  17. begin
  18.   Row := Sender.GetNodeData(Node);
  19.   CellText := Row.ToString(Column);
  20. end;

Za pouziti bindingu nebude treba kodu zadneho. Uzivatel si umisti VT na prazdny form a navazbi ho na view. VT si pak dotahne sloupce z modelu (moznosti nastaveni je po k***t bez jedine radky kodu).

96901

  • Host
Re:Hlúpy formulár - ako naň
« Odpověď #3 kdy: 07-09-2017, 19:42:37 »
Podle mě je to totální blbost. Sice v souladu s moderními programovacími technikami a odpovídá to technice MVC, ale přesto totální blbost. Tam, kde chci mít hloupé UI, to snad jakž takž dává smysl, ale pokud chci uživateli nabídnout pohodlí, tak to dokážu leda s vynaložením naprosto absurdního množství úsilí a krajně nepřehledného kódu. Ano, MVC má i své výhody, ale upřímně - za svou programátorskou praxi jsem se setkal maximálně v jednotkách případů, že to nebylo YAGNI.

Z toho co pises jsem nepochopil na ktere strane jsi. Jsi tedy pro opakovani stale stejneho kodu? MVC ma spoustu vyhod a nikdo ti nebere moznost psat pri jeho vyuziti kod nebo navrhovat neco co povazujes za inteligentni UI (v tu chvili ti muze MVC nabidnout napr. "jen" centralizovany refresh). Navic pokud si napises jednoduchy framework, nepotrebujes ani programatory "kodery" (ti co pro kazdy form opakuji stale stejny kod).

No a jsi u toho, kde je slabina MVC...

To neni zadna slabina. Vse muze zustat pri starem, model muzes ovladat manualne psanym kodem a poslouchat udalosti tak jak bys to ted delal bindingem s datasetem.

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 7392
  • Karma: 44
    • Verze Delphi: W11 + D11.3.1
Re:Hlúpy formulár - ako naň
« Odpověď #4 kdy: 07-09-2017, 21:19:53 »
Ešte som nevidel aplikáciu, kde by všetky formuláre boli na jedno kopyto. Zhruba to mám takto:
  • Formuláre a VST ktoré pracujú priamo s tabuľkami. Pri VST je to doslovne len občas. V drvivej väčšine používam FDQuery. Dosť často ťahám údaje z viacerých tabuliek. Na zobrazenie pomocných údajov - lepšia orientácia užívateľa.
  • VST čosi zobrazia. Potom na základe ich stavu a iných vecí pracujem s tabuľkami (insert, update). Niekedy aj s viacerými naraz.
  • Jedná sa o pomocné VST, ktoré slúžia na lepšiu orientáciu užívateľa a výber patričného záznamu. Ale ten sa môže robiť ja priamo v tabuľkovom VST. Mám ich navzájom prepojené. Pre prácu s DB sú tieto pomocné VST nepodstatné.
  • Samozrejme mám aj formuláre bez VST ale pracujúce s DB. Tých sa to MVC asi netýka.
Keby si chcel mať lepší prehľad, tak by som Ti musel poslať samotný program. Aj by si pochopil o čom píšem ;D
Citace
Myslim tim funkcionalitou? Nebo delaji to same jen kazdy s jinou sadou typu nad ruznymi tabulkami?
Pre 1. platí odpoveď áno
Citace
Opravdu je kazdy uplne jiny?
Pre 2. platí v podstate odpoveď áno
Citace
Ten model bude mit pro storage pristup pres As<T> accessory (jak jsme se dohodli)
Ja si žiadnu dohodu nepamätám ;D ;D ;D . Ja to nechávam plne na Tebe. Veď koľkokrát si len zhruba domýšľam o čom píšeš. Tak princíp.

Až dostanem do rúk nejakú verziu, tak to začnem študovať a až potom snáď budem vedieť o čom to je. Aj nefunkčnú, v podstate stačia rozhodujúce pas súbory.
Túto tému som založil preto, aby mi pomohla rozhodnúť sa či robiť úplne hlúpe formuláre, alebo aspoň čiastočne.
Prípadne môžem zaslať len snímky jednotlivých typov formulárov.
« Poslední změna: 07-09-2017, 21:21:36 od Stanislav Hruška »
Win11 64b, Delphi 11.3.1, FireBird 4.01
Expert na kladenie nejasne formulovaných otázok.

96923

  • Host
Re:Hlúpy formulár - ako naň
« Odpověď #5 kdy: 08-09-2017, 19:19:39 »
VST čosi zobrazia. Potom na základe ich stavu a iných vecí pracujem s tabuľkami (insert, update). Niekedy aj s viacerými naraz.

Dokazu si pod timto predstavit ze ve strome zobrazujes co uroven vetvi, to tabulka. A mas obavy co se stane kdyz napr. smazes vetev u korene. Pokud tomu tak je, zkus si predstavit ze kazdy node ukazuje na radek (ktery ma unikatni klic) ne na "bezduchy" typ record (ktery nevi nic o tabulce a okolnich vazbach), a VT vi jaka uroven ukazuje na jaky model (tabulku) a zna vazebni tabulky mezi urovnemi. Viz.:



Oprav me pokud se pletu, ale nejak si porad nedokazu pripustit jaka specialni logika je treba pro aplikaci pro spravu bytu (byt jsou nektere z akci provadene ve stromove strukture). Podle me jde porad jen o editaci tabulek. Tim samozrejme nechci projekt nejako znevazovat :)
Zkus kdyztak popsat vic okolo te specialni logiky resp. stavu ktere zminujes.

Ešte som nevidel aplikáciu, kde by všetky formuláre boli na jedno kopyto.

Ja ano. ERP je typicky priklad. Nedokazu si predstavit kolik by toho museli "koderi" naklikat a nakodovat (koder je clovek ktery pise opakujici se kod a tvrdi ze programuje) pro kazdy pohled na data, kdyz delaji temer vsechny pohledy to same.

Dokazu si predstavit ze base form pohledu na data bude schopen byt "editovatelny" pro model a jen hrstka implementaci si v potomcich prida neco extra (pomoci rucne psaneho kodu) a jeste mensi hrstka jej nepouzije a z gruntu si pomoci rucne psaneho kodu slozi form.
« Poslední změna: 08-09-2017, 19:43:34 od 96923 »

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 7392
  • Karma: 44
    • Verze Delphi: W11 + D11.3.1
Re:Hlúpy formulár - ako naň
« Odpověď #6 kdy: 08-09-2017, 22:07:48 »
Citace
Oprav me pokud se pletu, ale nejak si porad nedokazu pripustit jaka specialni logika je treba pro aplikaci pro spravu bytu
Len tak narýchlo čo mi príde na um.
Najzaujímavejšia je kapitola predpisov/záloh. Tam je toho najviac. Pripomínam, čo služba, obdobie (mesiac) a Vlastník_Byt, to nový riadok do tabuľky DEPOSITS.
Kód: Delphi [Vybrat]
  1. CREATE TABLE DEPOSITS (
  2.   IDDEPOSITS PRIMARYKEY NOT NULL,
  3.   FKFOCS FOREIGNKEY NOT NULL,
  4.   FKLANDLORD_FLAT FOREIGNKEY NOT NULL,
  5.   FKSERVICEPARAMETERS FOREIGNKEY NOT NULL,
  6.   DEPOSIT CURRENCY DEFAULT '0.0' NOT NULL,
  7.   PERIOD DATEFROM NOT NULL,
  8.   PAY CURRENCY DEFAULT 0 NOT NULL);
  9. ALTER TABLE DEPOSITS ADD CONSTRAINT PK_DEPOSITS PRIMARY KEY (IDDEPOSITS);
  10. ALTER TABLE DEPOSITS ADD CONSTRAINT FK_DEPOSITS_FOCS FOREIGN KEY (FKFOCS) REFERENCES FOCS(IDFOCS);
  11. ALTER TABLE DEPOSITS ADD CONSTRAINT FK_DEPOSITS_LANDLORD_FLAT FOREIGN KEY (FKLANDLORD_FLAT) REFERENCES LANDLORD_FLAT(IDLANDLORD_FLAT);
  12. ALTER TABLE DEPOSITS ADD CONSTRAINT FK_DEPOSIT_SERPARAM FOREIGN KEY (FKSERVICEPARAMETERS) REFERENCES SERVICEPARAMETERS(IDSERVICEPARAMETERS);
  13. CREATE INDEX DEPOSITS_IDX1 ON DEPOSITS(PERIOD);
  14. COMMENT ON COLUMN DEPOSITS.PERIOD IS 'Pre SIPO len celé mesiace. Pre vyúčtovanie podľa dní.';
  15. GRANT SELECT, INSERT, DELETE, REFERENCES, UPDATE ON DEPOSITS TO SYSDBA WITH GRANT OPTION;
  • Prvotné vytvorenie predpisu a jeho úprava.
  • SIPO - platba nájomného cez poštu. Nedá sa uhradiť iná suma, než je predpis. Pošta zašle zoznam prijatých/neprijatých platieb. Užívateľ si v strome zruší zaškrtnutie pri neplatičoch. Stlačí tlačidlo a program vykoná zápis úhrad.
  • Nie všetky predpisy sú uhradené v predpísanej výške. Niektoré viac a iné menej. Mám na to formulár, kde sa to automaticky "vyrovná". Tým pádom voči banke nevyskočia neplatiči. Pri pôžičkách si banky pýtajú prehľad o platobnej disciplíne.
  • Samostatné uhradenie predpisu podľa jednotlivých vlastníkov. Viď. 1. ukážka. Jedná sa o tých, čo neuhradili SIPO. Alebo SVB nemá s poštou podpísanú dohodu. Užívateľ si vyberie vlastníka, napíše sumu a tá sa automaticky rozhodí podľa služieb. Aj cez viac mesiacov
  • Zmena vlastníka bytu. Vytvárajú sa nové väzby Vlastník_Byt a zakladajú im počiatočné predpisy.
  • Zmena dátumu vlastnenia bytu. Viď. 2. ukážka. Vykonáva sa grafickým spôsobom. Aby som to mal pod kontrolou. To bol boj trvajúci asi 2 mesiace
Ja rozlišujem formuláre zhruba na typ Register = zápis základných údajov (byt, vlastník, služba...), "číselníky" apod. a ostatné.
Citace
a jeste mensi hrstka jej nepouzije a z gruntu si pomoci rucne psaneho kodu slozi form.
Ale ja tie svoje formuláre mám "kompozitné". Čo záložka, to pôvodne samostatný formulár. A to mi poriadne komplikuje situáciu.
« Poslední změna: 08-09-2017, 22:11:10 od Stanislav Hruška »
Win11 64b, Delphi 11.3.1, FireBird 4.01
Expert na kladenie nejasne formulovaných otázok.

Offline Daniel_Andrascik

  • Guru
  • *****
  • Příspěvků: 575
  • Karma: 20
    • Verze Delphi: D2007, D10.4
Re:Hlúpy formulár - ako naň
« Odpověď #7 kdy: 09-09-2017, 14:35:31 »
Stano, aby si sa uplne nezamotal. Kod formularov ma byt co najjednoduchsi, to mas pravdu a viac menej ti to tu vsetci odporucame. Ale Win VCL aplikacia nie je web aplikacia. Vacsinou nejaky ten kod v tych formularoch ti asi vzdy ostane. Ide o to aby tam ostal len nevyhnutny kod reagujuci na udalosti komponent a spravujuci dalsie vlastnosti komponent (enablovanie/disablovanie vizualnych komponent, nastavovania captionov, podfarbeni atd atd).

Podstatne je si myslim predavat tomu formularu data v takom formate aby nad nimi ten formular nemusel premyslat. Aby mal uz vsetko pripravene a aplikoval len priamu logiku a akcie nad komponentami. Cize ak ma formular zobrazit byty z jedneho konkretneho domu, tak mu neposielaj byty zo vsetkych domov aby ich ten formular nemusel triedit. To je len priklad. A ak ma formular moznost nejakym prekliknutim zobrazit byty aj z ineho domu tak to urob tak aby formular len jednoduchym zavolanim nejakej funkcie jadra vyziadal novu davku dat z ineho domu a zase ju nanovo spracuje jednoduchou priamou logikou ako to urobil pri svojom prvom zobrazeni.

Proste ked pozriem na svoje formulare tak vidim aha aha, tu sa spracovavaju udalosti, aha aha tu sa nacitaju data a aha aha tu sa posielaju naspat. Preletim kod formularu a do dvoch troch minut viem presne co robi, vidim krasne ake volania vykonava a kde ich vykonava ale nebori sa zo ziadnymi algoritmami spracovania dat a aplikacnou logikou jadra aplikacie.

Nerobis ziadnu enterprise aplikaciu. Robis aplikaciu pre nejakeho spravcu domov a bytov. Najdi si nejaku unosnu mieru co nechas este vo formularoch a co uz nie. Moje formulare maju zvycajne tychto niekolo metod:

Clear - vycisti vsetky naplnene komponty (tabulk, stromy, edity, checboxy, proste vsetko)
ShowData alebo RefreshData- tejto procedure predam nejaky typ datasetu, pole recordov, nejaky TList alebo TDictionary a ta procedura proste naplni vsetky vizualne komponenty datami. Pripadne jej predam este nejake upresnujuce informacie o tom ako si zelam tie data zobrazit. Ale to uz zalezi od potrieb apky.

Vacsinou na zaciatku procedury showdata je volana najprv Clear procka. Tymto systemom mozem proceduru ShowData volat viackrat so stale inymi datami a formular sa poslusne prekresluje.

Potom zvcajne ma u mna formular este proceduru SaveData, alebo UpdateData. Proste procku ktora ulozi vykonane zmeny. Ale tato procka je vacsinou jednoriadkova, proste len posle zmenene data nejakemu spravcovi a ten sa uz postara o fyzicke ulozenie. Ako vies, ja Datasety nepouzivam. Dataset by mohol aktualizovat data online okamzite po uprave hodntoy akeholkvek fieldu. No ja to takto nikdy nepouzivam. Vzdy ked vo vizualnych komponentoch upravim nejake data musim ich ulozenie spustit nejakym tlacidlom Uloz, Ok atd. A to tlacidlo len jednducho posle upravene data spat do jadra aplikacie a to uz vie ako na to.

Cize ako vidis nejaky ten kod tam mam, ale je to na jednu dve tri A4 textu v ktorom sa zorientujem za zlomok casu. Nenachadza sa v nom ziadna komplikovana logika, len priame reakcie na akcie uzivatela ktore zvycajne volaju aj tak nejake procedury a funkcie jadra.

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 7392
  • Karma: 44
    • Verze Delphi: W11 + D11.3.1
Re:Hlúpy formulár - ako naň
« Odpověď #8 kdy: 09-09-2017, 15:07:33 »
Daniel, čakal som na Teba :)  Vďaka Tvojmu príspevku už v tom mám jasno. Udalosti komponentov vo formulári. Ostatné podľa možnosti von. Aj som to tak nejako tušil, čo vidieť aj na príspevku. A reakcie k téme k tomu buď priamo alebo nepriamo nabádali.
Tým je pre mňa táto diskusia uzatvorená.
Win11 64b, Delphi 11.3.1, FireBird 4.01
Expert na kladenie nejasne formulovaných otázok.

96927

  • Host
Re:Hlúpy formulár - ako naň
« Odpověď #9 kdy: 10-09-2017, 07:04:25 »
Udalosti komponentov vo formulári. Ostatné podľa možnosti von.

Ano, idealne spolecnem (spolecnych). Samozrejme ze je lepsi takovy(e) form(y) navrhnout v IDE (tvoreni v runtime by bylo peklo), a obsluhovat udalosti (resp. reagovat na udalosti modelu a modely ovladat - co je v nich ale neresit, byt na nich nezavisly).

Pokud naucis trebas konstruktor takoveho "spolecneho" formulare prijimat dejme tomu data source (kolekce modelu), binding na view (vazby modelu na vizualni komponenty, vcetne treba formatovacu textu, barev apod. podle hodnot dat) a trebas balik s nastavenim formu (jako jeho pozice, ktere komponenty maji byt videt a kde), vytvoris tim univerzalni form ktery bude delat vzdy to same.

Vyhody:

- neopakujes se
- uprava spolecnych formu z jednoho mista
- formy se daji dedit a tvorit upravene nebo rozsirene varianty
- vysledna binarka je o neco mensi (i kdyz to neni v dnesni dobe podstatne)
- ohromna pruznost - kdysi jsem vyplodil jednoduchy klikaci framework kde si uzivatele mohli napr. v gridech nastavovat podle hodnot dat barvy radku, sloupcu, bunek, fontu, tvorit pocitane sloupce, agregaty atd. a to vse v podstate za cenu ulozeni a nacteni takove konfigurace (manazeri se tehdy citili jako programatori a ja se mohl houpat na zidli, predstirajic praci) - pribyly nove tabulky, ja bez jakehokoliv zasahu do kodu vytvoril pohled, napsal pro nej dotaz, nastavil prava (samozrejme ze mi to vzdy trvalo nekolik hodin) a zbytek si naklikaly spokojene opicky :)

Offline Daniel_Andrascik

  • Guru
  • *****
  • Příspěvků: 575
  • Karma: 20
    • Verze Delphi: D2007, D10.4
Re:Hlúpy formulár - ako naň
« Odpověď #10 kdy: 11-09-2017, 12:53:04 »
To Delfin: Tvorba vlastnych konstruktorov formularov je v podstate nevyhnutnost. Teda da sa robit apka i bez toho, ale 80% mojich formov tvorim pomocou vlastnych konstruktorov ktore ocakavaju dalsie parametre pripadne i data.

To Stano: Este si treba vcelku dobre rozmysliet a roztriedit co vsetko maju jednotlive formulare poskytovat. Ono nie je moc dobre ak koli hoc akej akcii sa musi otvarat nejaky subform, ale zase tiez nie je dobre ak vsetko mozne i nemozne mas aplikovane v ramci jedneho formulara. Treba tiez najst nejaky zdravy stred medzi tym. A od toho sa ti dost podstatne odvinie aj mnozstvo kodu kotre budes musiet pisat v ramci formulara, co chceme vlastne obmedzit.

Napriklad skusim nieco nadhodit z tvojej oblasti, aj ked nie som v nej moc orientovay, tak to ber s rezevou.

Ak mas formular kotry ti zobrazuje zoznam bytov v dome, tak by to mal byt len formular ktory ti zobrazuje tento zoznam a pri nom nejake dalsie doplnkove informacie k bytom. Ale na editovanie parametrov bytu (majitel, vymera, pocet izieb, atd atd) by mal byt uz iny formular. Taky ktory zase nedokaze zobrazit viacero bytov, ale ked mu posles aky byt chces editovat tak ti proste pripravy data daneho bytu do editov, checboxov, comboboxov atd atd.

Vies ono by sa to dalo urobit v jednom forme, proste mas cast formulara kde mas tabulkovy alebo stromovy zoznam bytov a v druhej casti budes mat moznost editovat parametre prave oznaceneho bytu. Ale takyto formular uz proste bude obsahovat nevyhnutne viac kodu. Ale i to sa da riesit este "ekonomicky a sikovne" ak mas dobre jadro aplikacie (napriklad pomocou formulara vo formulari, cize nieco ako TFrame, alebo proste len TFrame), alebo motanicou ktorej sa chces vyhnut. 

Proste ale je to zase o tom ze si musis najst zlatu strednu cestu, aby aplikacia bola dobre uzivatelsky ovladatelna a prehladna, ale aby sa aj dobre programovala, myslim tym priamocaro bez motanic, pretoze ak mas v akpe motanice, je vacsia pravdepodobnost ze tam budes mat zasite chyby a tazko sa to potom modifikuje a preraba a potom vznikaju len dalsie chyby a ja vidim ze sa im chces vyhnut...

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 7392
  • Karma: 44
    • Verze Delphi: W11 + D11.3.1
Re:Hlúpy formulár - ako naň
« Odpověď #11 kdy: 11-09-2017, 14:05:59 »
Citace
Ak mas formular kotry ti zobrazuje zoznam bytov v dome, tak by to mal byt len formular ktory ti zobrazuje tento zoznam a pri nom nejake dalsie doplnkove informacie k bytom.

Citace
Ale na editovanie parametrov bytu (majitel, vymera, pocet izieb, atd atd) by mal byt uz iny formular. Taky ktory zase nedokaze zobrazit viacero bytov
Ako som už písal. Mám to všetko na jednom mieste. Ja si myslím, že tak užívateľ okamžite vidí, čo všetko vlastne môže robiť. Čiže čo mu ponúka samotná aplikácia. Videl som niekoľko aplikácii, ktoré užívateľ musí tvrdo naštudovať, či už skusmo, alebo z helpu, aby zistil čo má vlastne k dispozícii. A kde to zakaždým hľadať.

Tak isto nemám rád, ak robím súvisiace činnosti a musím si vyvolať iné okno. Hľadať to napr. v menu a pod.
A som taký malý odporca zobrazenia viacerých okien naraz. Doteraz mám v aplikácii naraz vytvorené maximálne dva formuláre. Asi na 2 - 3 miestach. Okrem hlavného.

To všetko mi samozrejme komplikuje život.

Základná predstava sa dá urobiť z vzhľadu hlavného formulára.
« Poslední změna: 11-09-2017, 14:07:55 od Stanislav Hruška »
Win11 64b, Delphi 11.3.1, FireBird 4.01
Expert na kladenie nejasne formulovaných otázok.

Offline Daniel_Andrascik

  • Guru
  • *****
  • Příspěvků: 575
  • Karma: 20
    • Verze Delphi: D2007, D10.4
Re:Hlúpy formulár - ako naň
« Odpověď #12 kdy: 13-09-2017, 11:14:21 »
Tak isto nemám rád, ak robím súvisiace činnosti a musím si vyvolať iné okno. Hľadať to napr. v menu a pod.

Nuz ano. Ako horovis, toto ti komplikuje zivot. Ja nehovorim ze som proti tomu, mnohi uzivatelia ocenia ze nemusia kadeco rozklikavat a zatvarat okna. Ale cenou za to je ze tvoje formulare sa ti budu komplikovat a jednoduche asi nikdy nebudu.

Osobne ak aplikacia umoznuje otvorit viacero okien naraz tak jednoznacne uprednostnujem ich umiestnovanie na karty komponenty TPageControl, TTabControl a im podobnym. Ziadne plavajuce okna. Vid napr. velmi pekny Radkov clanok http://delphi.cz/post/Jak-jsem-modernizoval-UI-a-UX.aspx. Plavajuce okna pouzivam ale su vzdy modalne. Proste sa v nich nieco musi urobit, potvrdit alebo stronovat a odist.

Ja nehovorim ze zmyslas zle, len ono vzdy treba najst tu spravnu mieru, co vsetko pchat na jeden formular a co uz porozdelovat do viacerych. Na prvom mieste pri vyvoji je vzdy bezpecna, stabilna a bezchybna praca s datami. Len raz sa ti stane ze sa uzivatelovi tvojich aplikacii koli nejakej internej chybe v programe stratia nejake data, zaznamy, zmeny, pripadne ti padne cela hierarchia dat a dovera v tvoju aplikaciu utrzi velke rany.

Takze ak trosku utrpi komfort ovladania aplikacie na ukor bezpecnosti prace s datami tak budis, som za. Samozrejme ze UI nesmie byt neprijeme a nemotorne, ale preferujem bezpecnost pred privetivostou UI. Ono ale tiez mat milion okienok a klikaciek na jednom okne tiez nie je bezpecne ani pre uzivatela. Nie keazdy uzivatel je informatik a orientuje sa s lahkosotu v neprebernom mnozstve ovladacich prvkov. Vsimni si sucasne trendy vo vizualnom rozhrani, vsetky tie jednoducho metro styly, vsetko treba rozklikavat. Prepracovat sa k nejakej funkcii je hlavni koli mobilnym zariadeniam casto seria viacerych rozkliknuti. Osobne to vobec nemam rad a dostavam z toho osipky. Je to hlavne vina vsetkych tych povacsinou malych mobilnych zariadeni, ale som prekvapeny jak bezni ludia proti tomu vobec neprotestuju a vyhovuje im to.

Je to nezriedka dost velky kumst najst tu spravnu mieru na zorganizovanie vsekych funkcionalit aplikacie. Mnozstvo skusenosti spolu s uzivatelskym feedbackom je v tomto pripade na nezaplatenie. Tak drzim prsty...

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 7392
  • Karma: 44
    • Verze Delphi: W11 + D11.3.1
Re:Hlúpy formulár - ako naň
« Odpověď #13 kdy: 13-09-2017, 11:26:36 »
Citace
Ja nehovorim ze zmyslas zle,
To mi ani na um neprišlo. Ja som len poukázal ako rozmýšľam a aký to má dopad na vzhľad aplikácie. A s tým samozrejme sprievodné problémy.
Citace
Takze ak trosku utrpi komfort ovladania aplikacie na ukor bezpecnosti prace s datami tak budis, som za.
Akonáhle začne užívateľ čosi robiť s dátami, tak sa nedá prekliknúť na inú záložku. Tým si zaisťujem integritu údajov.
Citace
Tak drzim prsty...
Ďakujem. Aj za príspevok.
Win11 64b, Delphi 11.3.1, FireBird 4.01
Expert na kladenie nejasne formulovaných otázok.

96944

  • Host
Re:Hlúpy formulár - ako naň
« Odpověď #14 kdy: 13-09-2017, 12:57:05 »
Citace
Takze ak trosku utrpi komfort ovladania aplikacie na ukor bezpecnosti prace s datami tak budis, som za.
Akonáhle začne užívateľ čosi robiť s dátami, tak sa nedá prekliknúť na inú záložku. Tým si zaisťujem integritu údajov.

Myslel jsi na editaci stejneho zaznamu vicero uzivateli? Mas operace nad vicero tabulkami uvnitr transakci?

To prvni se doporucuje resit za pomoci separatni tabulky se zamky. Ano, databazovi experti radi aby se nezamykaly zaznamy primo v tabulce za pomoci zamku nabizeneho DBMS (zda se ze DBMS v tomto ohledu neveri, ma to ale i sve vyhody z pohledu ultimate administratora), ale kazdou editaci doporucuji zaznamenat do separatni tabulky (s koncem zaznam odebrat) a s kazdou zacinajici editaci se do ni podivat a pripadne uzivatele poslat do... cukrarny pro neco dobreho :) Deadlocky pak sbira periodicky nebo manualne spoustena procedura namisto DBMS nad svymi zamky.

Jde zkratka o situaci kdy se dvema uzivatelum zobrazi napr. modalni okno s editaci stejneho zaznamu kterou pak s ruznymi daty oba odeslou. Prekvapeni! :)

Transakce jsou samozrejme pro udrzeni konzistence dat..
« Poslední změna: 13-09-2017, 12:59:38 od 96944 »

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 7392
  • Karma: 44
    • Verze Delphi: W11 + D11.3.1
Re:Hlúpy formulár - ako naň
« Odpověď #15 kdy: 13-09-2017, 13:52:53 »
Citace
Myslel jsi na editaci stejneho zaznamu vicero uzivateli?
Myslel, ale ešte som to nijako neriešil. Tomu sa chcem venovať až dosiahnem cieľ.
Ja problematiku viacnásobného prístupu neovládam. Musím si ju najprv naštudovať.

Mám dve teoretické možnosti:
  1) riešiť to tak ako sa to má.
  2) k SVB môže v jednom čase pristupovať (pracovať s ním) len jediný užívateľ. Ale tomu nie som naklonený.

A prečo ponúkaš komplikované riešenia :D  = pomocná tabuľka...
« Poslední změna: 13-09-2017, 13:55:08 od Stanislav Hruška »
Win11 64b, Delphi 11.3.1, FireBird 4.01
Expert na kladenie nejasne formulovaných otázok.

96972

  • Host
Re:Hlúpy formulár - ako naň
« Odpověď #16 kdy: 14-09-2017, 23:24:10 »
Citace
Myslel jsi na editaci stejneho zaznamu vicero uzivateli?
Myslel, ale ešte som to nijako neriešil.

Zachovani veskerych editaci stejneho zaznamu se da bezpecne vyresit verzovanim (tj. ze se uchova kazda modifikace radku napr. s loginem autora a casem zmeny). Coz ma zjevnou nevyhodu v objemu dat. Na druhou stranu odpadnou snad za cenu disku (nebo diskoveho pole) dohady o tom kdo a kdy jaka data upravil. To samozrejme neni vsemocne.

Typicky scenar konkurencni editace muze vypadat takto:

Uzivatel zapocne editaci (napr. otevrenim modalniho okna), aplikace zamkne zaznam (je jedno jestli DBMS zamkem nebo jen virtualne separatni tabulkou) a ten debil odejde treba na obed (nebo bude zodpovedny, avsak jeho mene inteligentni kolega mu znenadani rozseka pocitac bouracim kladivem). O par dveri stranou se pak bude vyhradne atraktivni sekretarka snazit upravit ten samy zaznam. Kdyz z aplikace vyskoci dialog informujic o zakazu operace kvuli editaci zapocate kolegou, rozhodne se zavolat svemu vlidnemu firemnimu IT administratorovi ktery ji s ochotou (diky jeji atraktivnosti) zaznam bez dalsiho badani odemkne. Jenze co v takovem pripade delat s aplikaci?

Zaznam byl zamcen zapocetim editace, to je vse co databaze vi. Uz ale nemuze tusit zda takova editace kdy skonci (nasyceny kolega by to zvladnout mohl, pocitac upraveny bouracim kladivem uz nejspis ne). Muze tim dojit k deadlocku zaznamu.

Da se vymyslet spousta zpusobu jak takovou situaci z pohledu UI vyresit. Bude vsak vyhodnejsi moznost kdy se data neprepisi, ale vytvori se nova verze zaznamu, cimz ani slicna sekretarka neprijde o svou upravu v pripade navratu hodujiciho kolegy.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3527
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Hlúpy formulár - ako naň
« Odpověď #17 kdy: 15-09-2017, 07:33:19 »
Da se vymyslet spousta zpusobu jak takovou situaci z pohledu UI vyresit. Bude vsak vyhodnejsi moznost kdy se data neprepisi, ale vytvori se nova verze zaznamu,
Ale tim prece nic nevyresis - stejne bude muset nekdo rozhodnout o tom, ktera z tech verzi je platna, protoze vetsinou nemuzou existovat v jeden cas ruzne varianty tehoz,
takze do aplikace budes muset navic implementovat funkcionalitu pro sefa, aby mohl vyresit kolize verzi.

Ja bych to resil vuci BFU ofenzivne tj. pomoci OCC (Optimistic Currency Control) zahrnutim detekce konfliktu a vyfuckovanim zmen pri konfliktu tj. do DB modelu bych pridal pole s verzi radku (rada RDBMS neco takoveho podporuje, ja se s tim potkal u DB/2 a MSSQL), pri fetch si ho nacetl a v prikazu, ktery zkousi menit data bych do where klauzule pridal podminku na shodu verze radku mezi fetchnutou hodnotou a skutecnou hodnotou v DB v okamziku modifikujici transakce. A v pripade rozdilu bych nedovolil DB modifikovat a zobrazil BFU, ze zatim co byl na obede, uz to nekdo zmenil a at si to resi. Kdyz bych na nej chtel byt hodne friendly, tak bych mu pres mechnismus validace zobrazil, co se zmenilo.

Mam dojem, ze Delphi obsahuje nekde na urovni  Data Snap nejakou podporu pro OCC, ktera nejak obhospodaruje stary/novy zaznam a nejakou podporu pro reseni , ale nikdy jsem s tim nic nedelal.


96976

  • Host
Re:Hlúpy formulár - ako naň
« Odpověď #18 kdy: 15-09-2017, 14:37:36 »
[quote  link=topic=15806.msg96972#msg96972 date=1505424250]
Da se vymyslet spousta zpusobu jak takovou situaci z pohledu UI vyresit. Bude vsak vyhodnejsi moznost kdy se data neprepisi, ale vytvori se nova verze zaznamu,
Ale tim prece nic nevyresis - stejne bude muset nekdo rozhodnout o tom, ktera z tech verzi je platna, protoze vetsinou nemuzou existovat v jeden cas ruzne varianty tehoz,
takze do aplikace budes muset navic implementovat funkcionalitu pro sefa, aby mohl vyresit kolize verzi.
[/quote]

To ano. Zbavis se tim ale volani zakaznika "ono to nefunguje, ztratila se nam data" :) Navic se muzes podivat i do historie.
Hloupost nekterych uzivatelu prekracuje limit chapani vesmiru jako celku a i pres vselijaka varovani jsou schopni vse bezhlave odklikat a nasledne reklamovat. Za cenu disku bych spis volil variantu verzovani.

On i tento projekt de-facto verzovani uz pouziva. Kdyz se vymeni najemnici, ve vazebnich tabulkach pribude zaznam o zmene s tim ze se muzu zpetne podivat kdo v byte v danou dobu bydlel.
« Poslední změna: 15-09-2017, 14:41:40 od 96976 »

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3527
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Hlúpy formulár - ako naň
« Odpověď #19 kdy: 15-09-2017, 14:49:23 »
Hloupost nekterych uzivatelu prekracuje limit chapani vesmiru jako celku a i pres vselijaka varovani jsou schopni vse bezhlave odklikat a nasledne reklamovat.
Kdyz si to plati, at reklamuji, ne?

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 7392
  • Karma: 44
    • Verze Delphi: W11 + D11.3.1
Re:Hlúpy formulár - ako naň
« Odpověď #20 kdy: 17-09-2017, 13:19:49 »
To Radek
Citace
Vid napr. velmi pekny Radkov clanok http://delphi.cz/post/Jak-jsem-modernizoval-UI-a-UX.aspx.
Prosím Ťa, akú veľkosť ikôn si použil v bočnom strome. Na 16 x 16 to nevyzerá.
Ďakujem.
Win11 64b, Delphi 11.3.1, FireBird 4.01
Expert na kladenie nejasne formulovaných otázok.

Offline Daniel_Andrascik

  • Guru
  • *****
  • Příspěvků: 575
  • Karma: 20
    • Verze Delphi: D2007, D10.4
Re:Hlúpy formulár - ako naň
« Odpověď #21 kdy: 17-09-2017, 13:32:26 »
Celkom podnetna debata pani. Osetrit bezpecnoct prace s datami na urovni db je samozrejmost a aj som sa vcelku zamyslel nad vasimi odporucaniami.

Ale ja som v kontexte tohto vlakna narazal aj na fakt ze na komplikovanom formulary kde sa mozu motat rozne pohlady a zavislosti je mozne data stratit alebo skor hlavne pomotat uz na hornej urovni aplikacnej logiky vramci formulara. Ale to som spominal len tak na okraj, ako dalsie potencionalne riziko komplikovanych formularov. Podarilo sa mi to uz aj u jednoduchych formularov. Myslim ze kazdy kto vyvyjate UI ste raz alebo viackrat boli velmi prekvapeni ake nemyslitelne kombinacie dokazu uzivatelia poklikat na takom formulari, co by sa vam ako developerovy ani vo sne nesnivalo. A napriek velkej snahe vsetko mozne i nemozne osetrit sa predsa len moze stat ze nejaka zamotana situacia ostane neosetrena. A u prekomplikovaneho formulara si clovek moze byt takmer isty ze tam bude mat zasite nejake tie neosetrene nebezpecne kombinacie akcii a reakcii... 

96984

  • Host
Re:Hlúpy formulár - ako naň
« Odpověď #22 kdy: 17-09-2017, 15:18:31 »
Ale ja som v kontexte tohto vlakna narazal aj na fakt ze na komplikovanom formulary kde sa mozu motat rozne pohlady a zavislosti je mozne data stratit alebo skor hlavne pomotat uz na hornej urovni aplikacnej logiky vramci formulara.

Muzu se zeptat na konkretni priklad? Za predpokladu, kdy:

- model umi vazby (dokaze napr. kaskadove mazat zaznamy)
- model ma i moznost manualniho linkovani udalosti a stavu "mimovazebnich" modelu (muzu tak napr. zamykat i "nesouvisejici" model)
- pohledy na model samozrejme obsahuji "jen" odkazy na jeho zaznamy
- zaznam modelu je editovan vstupem pres re-entrantni zamek (BeginEdit) s moznosti jej vypnout a posilat uzivatele do haje s tim ze se uz nekde v prave spustene aplikaci presne ten samy zaznam snazi editovat
- vse je transakcni na urovni modelu, ne pohledu; dokud se nerekne modelu "commit", jsou radky jen ve stavech "upraven", "smazan" atd. (viz. DataRowState)

Ad verzovani:

Nejhorsi je pouzit verzovani jen nekde a uzivateli nabidnout pohled do minulosti. A nemusi jit zrovna o konkurencni pristup. Napr. uchovas verze vazeb byt/najemnik a najemnika nechas bez verzovani. Hledej potom podle jmena Annu Blazkovou ze ktere se presitim stal se vsim vsudy Adam Blazek ;D Neni to sice vhodny priklad, ale pro vysvetleni principu staci :)
« Poslední změna: 17-09-2017, 15:34:39 od 96984 »