Poslední příspěvky

Stran: 1 ... 8 9 [10]
91
Obecné / Re:Identifikátor pre volanie procedúry a pod. Aký typ to má byť?
« Poslední příspěvek od Delfin kdy 20-08-2017, 11:35:55 »
A čo si mám predstaviť pod pojmom "uzivatelem definovatelny grid"?

Vytvori se potomek VT ktery rozumi modelu, resp. bude shopny data bindingu s nim (ano, jde o zjednodusenou custom kopii LiveBindings), tj. dokaze pri spojeni s modelem vycist jeho sloupce, zobrazit radky a reagovat na urcite situace (napr. refresh radku). O datech modelu ale nic nevi. Co ma z dat zobrazit se pak da zajistit (uzivatelskou) konfiguraci.

Napr. vytvorim interface ktery bude obsahovat format textu node prip. bunky (tj. pro node/column pujde uzivatelsky nadefinovat ze se ma zobrazit napr. text z hodnoty radku slozeny ze sloupcu ve formatu "<ColumnName>" + " " + "<ColumnSurname>"), pro hint se da vytvorit to same. Mimo to se daji nadefinovat pravidla podle kterych je mozne vetve nebo bunky podbarvovat (spolu s fontem) podle urciteho stavu radku. No a ten samy interface se da pouzit treba i pro edit control.

Všetky doteraz vytvorené formuláre slúžia na zadávanie a zmenu údajov.

Ucelem toho model view patternu je oddeleni view od modelu. Model muze byt tabulka ktera z DB cte data a umi je zapsat. View pak muze byt nekolik (v nekolika formularich nezavisle). Dojde-li pak k update modelu (tabulky), obnovi se vsechna view (at je to graf, edit box nebo VT grid). Kazdy z tech view muze delat neco jineho. Vytvorim napr. form k editaci, vlozim do nej model, form zobrazi ve svych view (edit boxech) data, a jakmile editaci obsouhlasim (tlacitkem OK), poprosim model napr. o insert, model data zapise, a pokud bude uspesny posle notifikaci o zmene vsem jeho pozorovatelum, vsem view ktere o reakce na tuto zmenu maji zajem. Vse se tak deje z jednoho mista nebot model je "vzdy jen jeden, spolecny pro vsechna view".
92
Obecné / Re:Declaration of 'Create' differs from previous declaration
« Poslední příspěvek od Stanislav Hruška kdy 20-08-2017, 10:49:48 »
Už mi to je jasné TCustomObject je základnej hierarchii Delphi. Takže to musím premenovať.
93
Obecné / Re:Declaration of 'Create' differs from previous declaration
« Poslední příspěvek od Stanislav Hruška kdy 20-08-2017, 10:47:19 »
Dal som tam AVarOfCustomObjects: TObjectList<TObject>. Vôbec sa mi to nepáči.
94
Obecné / Re:Declaration of 'Create' differs from previous declaration
« Poslední příspěvek od Stanislav Hruška kdy 20-08-2017, 10:27:33 »
Tak som zistil, že mu vadia argumenty AVarOfCustomObjects: TObjectList<TCustomObject> aj ApRecord: Tlist<Pointer>. Ale nie som z toho múdrejší.

Už mu vadí len AVarOfCustomObjects: TObjectList<TCustomObject>
Už mu vadí len TCustomObject. Definícia TCustomObject = class(TObject)
95
Obecné / Declaration of 'Create' differs from previous declaration
« Poslední příspěvek od Stanislav Hruška kdy 20-08-2017, 10:03:31 »
Už som z toho úplne mimo:
Kód: Delphi [Vybrat]
  1.   TMakeForms = class(TCustomMakeForms)
  2.   public
  3.     constructor Create(ATypeForms: TTypeForms; ApRecord: Tlist<Pointer>; AVarOfCustomObjects: TObjectList<TCustomObject>;
  4.       AEditWinCtrls: TList<TWinControl>); virtual;
  5.   end;
  6. ...
  7. constructor TMakeForms.Create(ATypeForms: TTypeForms; ApRecord: Tlist<Pointer>;
  8.   AVarOfCustomObjects: TObjectList<TCustomObject>; AEditWinCtrls: TList<TWinControl>);
  9. begin
  10. end;
  11.  
Nerozumiem prečo a ako to opraviť. Ak constructor odstránim, tak kompilácia prebehne bez problémov.
97
Obecné / Re:Identifikátor pre volanie procedúry a pod. Aký typ to má byť?
« Poslední příspěvek od Stanislav Hruška kdy 19-08-2017, 21:33:14 »
Nakreslil som nejakú svoju predstavu ako by mala vyzerať schéma objektov pre generovanie objektov a spol. Snáď som to pochopil dobre. Nezamýšľal som sa nad implementáciou. Teraz to je zbytočné.
Prosím o pripomienky. Potom by som mal dať dlhší čas pokoj.
Citace
Obrazky pro predstavu pomahaji. Me jde o to, ze se pro urcite struktury dat da navrhnout interface. A pro ten interface i uzivatelem definovatelny grid (i VT se da pouzit jako grid).

Všetko v čom sú zobrazené nejaké údaje je VST. Nič iné nepoužívam. Samozrejme okrem komponentov na editáciu.
A čo si mám predstaviť pod pojmom "uzivatelem definovatelny grid"? Vlastním FastCube2, ktorý chcem v budúcnosti použiť. Tak niečo také snáď nepotrebujem.
Všetky doteraz vytvorené formuláre slúžia na zadávanie a zmenu údajov.
Tie formuláre ktoré robia nejaké automatické úkony nad dátami nezvyknú mať grid na výber údajov. Ak ho majú, tak musí byť pevne daný a slúži prevažne na určenie parametrov.
98
Obecné / Re:Identifikátor pre volanie procedúry a pod. Aký typ to má byť?
« Poslední příspěvek od Delfin kdy 19-08-2017, 21:18:45 »
Položky predpisov mám v riadkoch. To je najdlhšia tabuľka. Bude rásť veľmi rýchlo. Prevádzam ich na stĺpce.

Obrazky pro predstavu pomahaji. Me jde o to, ze se pro urcite struktury dat da navrhnout interface. A pro ten interface i uzivatelem definovatelny grid (i VT se da pouzit jako grid).

Nicmene citace zavani spis vazebni tabulkou. Pokud muze mit vice uzivatelu stejne predpisy, pak je vice nez vhodne ji pouzit (ostatne vazebni tabulky uz by v DBMS mely existovat touhle dobou).
99
Obecné / Re:Identifikátor pre volanie procedúry a pod. Aký typ to má byť?
« Poslední příspěvek od pf1957 kdy 19-08-2017, 21:12:36 »
A čo váš názor na SP.
Jsou k tomu ruzne pristupy: mi mame treba rodinu aplikaci, kde se s DB komunikuje vyhradne pres SP a ty jsou implementovany na ruznych RDBMS. Vsechny SP jsou pristupne jen volanim service, takze kazdy, kdo ma implementovaneho klienta k te service, muze komunikovat s DB v podstate odkudkoli, jinak se k ni nedostane. To je jeden extrem, ktery mj. ma za nasledek, ze kdyz model potrebuje filtrovana data buhvi podle kolika kriterii vcetne paginatoru, tak se v prislusne SP sestavuje where klauzule podle techto podminek... V archaickem impotentnim jazyku jako SQL docela hruza... Taky to ma za nasledek, ze kdyz se cokoli meni, musi kazdy udelat zmenu k-krat pro kazdy typ RDBMS, musi se to pretestovat atd.

Pak je takovy normalni pristup, ze co je vyhodne ev. nutne z hlediska vykonu se nacpe do SP, zbytek se udela tradicne.

No a pak treba opacny extrem: ORM na bazi nejakeho vyspeleho frameworku jako je MS Entity Framework, kde se pouziva vyspely jazyk C# s LINQ, takze o nejake blboucke SQL se clovek nemusi starat, o konkretni typ RDBMS teoreticky taky ne. Samozrejme dynamickemu sestavovani Where klauzule se clovek neutece nikdy, ale aspon do dela ve slusnem jazyku a nastroji. No a to uz je  pohledu MVC takrka ideal: v modelech jsou objekty, z DB lezou objekty, do DB se zapisuji objekty (cele hierarchie). Sa,ozrejme tohle neni vhodne pro vsechno, ale IMHO se to hodi pro vetsinu aplikaci s ksichtem a BFU pred obrazovkou.

Jo a bez profesionalniho nastroje, ktery umoznuje SP ladit (trasovat) a vytvaret evolucni scripty DB schematu pri zmenach, bych se o SP ani nepokousel...
100
Obecné / Re:Identifikátor pre volanie procedúry a pod. Aký typ to má byť?
« Poslední příspěvek od Stanislav Hruška kdy 19-08-2017, 20:50:32 »
Nikdy sa nebude ťahať extrémne množstvo údajov. Je to program na vyúčtovanie nájomného v dome - SVB. Zoberme príklad:
Nech má dom (presnejšie SVB) 200 bytov. V mojom meste (30 tis. obyv.) také neexistuje.
Existuje 25 položiek vo vyúčtovaní/predpisov - nevidel som také
Vždy sa pracuje len s jedným SVB a rokom
Položky predpisov mám v riadkoch. To je najdlhšia tabuľka. Bude rásť veľmi rýchlo. Prevádzam ich na stĺpce.

Takže 200 bytov x 25 položiek x 12 mesiacov = 6 000 ťahaných záznamov. Zároveň je počet záznamov pridaných pre jedno SVB počas roka. A do 1 mil. záznamov sa vraj nemám s tým vôbec zaoberať - výkon.
A to prevediem na tabuľku o 12 riadkoch a 30 stĺpcov (nejaké info naviac) pre jedného vlastníka

Počet ostatných záznamov je limitovaný počtom bytov.
Byty x počet vlastníkov alebo užívateľov

Takže okrem prvého (prehnaného) prípadu žiadne veľké čísla. Takže technicky nie je problém natiahnuť naraz všetky záznamy pre celý formulár.
Dobre viete kedy sa ide do základných údajov. Byt, vlastníci, merače vody a pod. Pri zakladaní SVB a nejakej zmene.
Ináč sa počas roka pracuje len s položkami predpisov. Aj to väčšinou hromadne. Príde informácia o SIPO z pošty a program sa o to postará. Akurát treba dodatočne nahodiť neplatičov. Aj to je automatizované.

Samotné vyúčtovanie je samostatná kapitola a nespadá do nadhodenej problematiky.
Dnes som sa akosi rozkecal ;D
Prikladám ukážku dvoch najväčších žrútov údajov. Pripomínam, že každá záložka je vlastne jeden formulár. Ako je spomenuté hore, ich použitie bude občasné.
Stran: 1 ... 8 9 [10]