Hlúpy formulár - ako naň

[Stanislav Hruška]

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.

[pepak]

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.

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]

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]

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.

[Stanislav Hruška]

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

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

Pre 1. platí odpoveď áno

Opravdu je kazdy uplne jiny?

Pre 2. platí v podstate odpoveď áno

Ten model bude mit pro storage pristup pres As<T> accessory (jak jsme se dohodli)

Ja si žiadnu dohodu nepamätám . 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.

[96923]

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.

[Stanislav Hruška]

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

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.

[Daniel_Andrascik]

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.

[Stanislav Hruška]

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

[96927]

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

[Daniel_Andrascik]

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

[Stanislav Hruška]

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

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.

[Daniel_Andrascik]

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

[Stanislav Hruška]

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.

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.

Tak drzim prsty...

Ďakujem. Aj za príspevok.

[96944]

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