Odpověď

Upozornění: do tohoto tématu bylo naposledy přispěno před 120 dny.
Zvažte prosím založení nového tématu.
Jméno:
E-mail:
Předmět:
Ikona zprávy:

Ověření:
Datový typ v Delphi, který má True a False:

Zkratky: stiskněte shift+alt+s pro odeslání nebo shift+alt+p pro prohlédnutí


Shrnutí tématu

Poslal: Delfin
« kdy: 24-12-2017, 10:38:29 »

Citace
Chci rict, ze mam za to ze ta aplikace bude mit spoustu shodneho a ze by se mohla casova investice do vlastniho maleho frameworku vyplatit.
Ja mel dojem, ze se zabyvas obecnejsim frameworkem, ktery mj. by sel pouzit na ten management bydleni...

To ano. Jen se ted snazim lobbovat za nepotrebnost deklarace entit v kodu. Samozrejme v pripade nutnosti bys je nadeklarovat v kodu mohl - napr. uplne stejne jako ted programatori deklaruji tridy entit a tvori jejich instance z radku objektu datasetu. A pohledy na takovou entitu samozrejme nejsou podminkou :)
Poslal: pf1957
« kdy: 23-12-2017, 19:33:53 »

ne jak se da co nejrychleji sestavit ze skladovych zasob dodavatelu raketoplan ;D
No tuhle cast resi asynchronne pracujici nevizualni service, nicmene BFU musi mit moznost rucne do vygenerovanych objednavek zasahovat + objednavky potvrzovat :)

Citace
Chci rict, ze mam za to ze ta aplikace bude mit spoustu shodneho a ze by se mohla casova investice do vlastniho maleho frameworku vyplatit.
Ja mel dojem, ze se zabyvas obecnejsim frameworkem, ktery mj. by sel pouzit na ten management bydleni...
Poslal: Stanislav Hruška
« kdy: 23-12-2017, 16:16:59 »

Citace
Ako dlho s tym pracujes?
0 sekúnd 8)  Sú tu ľudia, ktorí to majú nasadené ostro. Chvália si to.
Poslal: Miroslav Baláž
« kdy: 23-12-2017, 15:48:41 »

Poznámka: pre tvorbu SQL príkazov užívateľom plánujem použiť jedine FastCube. Tomu by užívatelia mohli rozumieť. Prípadní užívatelia budú totálni analfabeti v IT s rôznym stupňom vzdelania a IQ.
Pozrel som FastCube. Vyzera slusne. Si s tym spokojny? Ako dlho s tym pracujes?
Poslal: Delfin
« kdy: 23-12-2017, 15:05:00 »

Poznámka: pre tvorbu SQL príkazov užívateľom plánujem použiť jedine FastCube. Tomu by užívatelia mohli rozumieť. Prípadní užívatelia budú totálni analfabeti v IT s rôznym stupňom vzdelania a IQ.

Vsak tim "uzivatelem" muzes byt Ty. Jen budes fakturovat za "slozitou" upravu aplikace ;) Dlouze jsem se diky podobnemu reseni "houpal na zidli" :)
Poslal: Stanislav Hruška
« kdy: 23-12-2017, 13:04:24 »

Poznámka: pre tvorbu SQL príkazov užívateľom plánujem použiť jedine FastCube. Tomu by užívatelia mohli rozumieť. Prípadní užívatelia budú totálni analfabeti v IT s rôznym stupňom vzdelania a IQ.
Poslal: Stanislav Hruška
« kdy: 23-12-2017, 11:13:25 »

Citace
Pointou k zamysleni v tomto pripade je, jaka extra logika je treba pro aplikaci spravy domu (coz je pro me z majoritni casti "jen" editor tabulek plus nejake agregaty a reporty)
Ten editor tabuliek sa uplatní hlavne pri zakladní SVB. Tých tabuliek je zhruba 16. Okrem podružných - s občasným editovaním. Potom už len občas podľa zmien.
Hlavná činnosť spočíva
  • zmena vo vlastníctve bytov a zmene v bytoch (počty a plochy) - to nie sú časté prípady
  • vo vystavení záloh nájomného pre každý mesiac. Ak dôjde k zmene, je potrebné to dať aj vlastníkovi bytu.
  • v úhradách nájomného
  • v dodatočnom editovaní predpisov záloh a ich úhrad
  • vystavenie vyúčtovania vlastníkom. Raz ročne
Vzhľadom na skutočnosť, že tabuľka záloh je riadková, tak pre s ňou sa nedá použiť editor tabuliek. Komplikuje to aj získavanie údajov z nej, ale nie je to problematické.
Neviem čo máš na mysli pod agregátmi. Predpokladám, že spracovanie samotného vyúčtovania. To je kapitola sama o sebe.
Potom už naozaj nasledujú rôzne zostavy: samotné vyúčtovanie, prehľady číselníkov a registrov (zoznamy vytvorené užívateľom - byty, vlastníci...) a všelijaké štatistiky a prehľady podľa požiadaviek praxe.
Poslal: Delfin
« kdy: 23-12-2017, 10:24:30 »

Ja myslel v Delphi kodu. Viz napr. posledni navrh, proc bych v pripade entit s nimiz by se pracovalo naprosto stejnym zpusobem potreboval jejich definice kdyz bych na ne (v tom kodu) nikde ani nesahl
No to je to, cemu nerozumim: vezmi napr. kalendar svatku v dane zemi - ten prece v aplikaci nemam kvuli tomu, abych ho prohlizel a editoval v CRUD, ale proto, ze zbytek aplikace potrebuje s temi svatky pracovat napr. kdyz zkouma chovani trhu v ruzne dny v tydnu, planuje objednavky jen na pracovni dny, velikost objednavky zalezi na tom, jake dny nasleduji atd.

U aplikace planujici objednavky toho moc nesjednotis treba s ovladanim vyroby. Holt musis napsat funkcionalitu separatne, protoze neni co sjednocovat. Pointou k zamysleni v tomto pripade je, jaka extra logika je treba pro aplikaci spravy domu (coz je pro me z majoritni casti "jen" editor tabulek plus nejake agregaty a reporty), ne jak se da co nejrychleji sestavit ze skladovych zasob dodavatelu raketoplan ;D Chci rict, ze mam za to ze ta aplikace bude mit spoustu shodneho a ze by se mohla casova investice do vlastniho maleho frameworku vyplatit.
Poslal: pf1957
« kdy: 23-12-2017, 08:21:24 »

Ja myslel v Delphi kodu. Viz napr. posledni navrh, proc bych v pripade entit s nimiz by se pracovalo naprosto stejnym zpusobem potreboval jejich definice kdyz bych na ne (v tom kodu) nikde ani nesahl
No to je to, cemu nerozumim: vezmi napr. kalendar svatku v dane zemi - ten prece v aplikaci nemam kvuli tomu, abych ho prohlizel a editoval v CRUD, ale proto, ze zbytek aplikace potrebuje s temi svatky pracovat napr. kdyz zkouma chovani trhu v ruzne dny v tydnu, planuje objednavky jen na pracovni dny, velikost objednavky zalezi na tom, jake dny nasleduji atd.

Ale uznavam, nejsem datar a muj pohledem na svet DB je prioritne objektovy, takze ja entitu nenavrhuju *jen* kvuli CRUD, ale predevsim kvuli zbytku aplikace. To, ze na ciselnik potrebuju CRUD, je uz jenom podruzna zalezitost. A v takove aplikaci nejaky automatismus na CRUD moc nevyresi, tech ciselniku nebyva velke mnozstvi, jednoduche "tabulky" k editovani se jinak moc nevyskytuji - jsou naopak dost slozite a treba s verzovanim dat a slozitost/pracnost vlastni aplikace je radove jinde nez CRUD pro par desitek ciselniku.

Jeste detail k tomu prikladu: tam jsem predokladal ze 1 entita = 1 DM = 1 CDS. S tou namitkou s typovosti mas pravdu, ale proto preferuju ty ORM vsude, kde je to jen trochu mozne.
Poslal: Delfin
« kdy: 23-12-2017, 03:13:29 »

Nebo deklarovat v Delphi kodu kazdou entitu kdyz by pak byly de-facto nevyuzite v pripade spolecne funkcionality.
Tomu nerozumim. Ja v DB zadne nevyuzite entity nemam

Ja myslel v Delphi kodu. Viz napr. posledni navrh, proc bych v pripade entit s nimiz by se pracovalo naprosto stejnym zpusobem potreboval jejich definice kdyz bych na ne (v tom kodu) nikde ani nesahl (tim jsem myslel ze by byly [tedy z pohledu kodu] nevyuzite). Nebo zkracene, proc vubec deklarovat napr. takoveto 2 datasety kdyz budou ve finale fungovat uplne stejne a muzu si jejich definici ziskat ze sablony:

Kód: Delphi [Vybrat]
  1. type
  2.   TDataModuleXyz = class(TDataModule)
  3.     ...
  4.     cdsAbc: TClientDataSet;
  5.     cdsAbcId: TIntegerField;
  6.     cdsAbcSomething: TStringField;
  7.     cdsAbcSomethingElse: TStringField;
  8.     ...
  9.     cdsXyz: TClientDataSet;
  10.     cdsXyzId: TIntegerField;
  11.     cdsXyzIdent: TStringField;
  12.     ...
  13. end;

A kdybych v tom navrhovanem framework pro nektery dataset dopsat extra funkcionalitu v kodu, mohl bych si fixni definici datasetu ulozit do stejne konfiguracni sablony (ktera by se jinak naklikala v runtime aplikace) napr. do resources aplikace a vytvorit instanci daneho datasetu a pracovat s nim v kodu. Ano, ztraci se tim typovost v kodu, nicmene porad myslim jen na "jednoduchy editor tabulek" se spolecnou funkcionalitou jez znacne prevazuje psani specifickeho kodu.

Navic, i s tou deklaraci dataset objektu v design-time ses uz typovosti dobrovolne vzdal; napr. proti tomuto by kompilator nemel co rict:

Kód: Delphi [Vybrat]
  1. var
  2.   TheMoment: TDateTime;
  3. begin
  4.   TheMoment := cdsAbcSomething.AsDateTime; // jde o string field
  5. end;

Takze kdybych napsal se svym teoretickym framework pro dataset objekt vytvoreny v runtime za pomoci kodu (definovany napr. sablonou ulozenou v resources aplikace) neco takoveho, nebude v tom pro kopilator zadny rozdil (jen MyRuntimeOnlyDataset by tady byl deklarovany jako TClientDataSet jehoz plny popis [jako napr. zdrojova entita, jake ma vazby, atd.] pochazi z "fixne" ulozene sablony, ne z design-time deklarace):

Kód: Delphi [Vybrat]
  1. var
  2.   TheMoment: TDateTime;
  3. begin
  4.   TheMoment := MyRuntimeOnlyDataset.FieldByName('Something').AsDateTime; // jde o string field
  5. end;
Poslal: pf1957
« kdy: 22-12-2017, 21:14:50 »

Me totiz porad unika proc pro "jednoduchy editor" tabulek a reportovac psat a buildovat dokola aplikaci pro kazdou z nich :P Nebo deklarovat v Delphi kodu kazdou entitu kdyz by pak byly de-facto nevyuzite v pripade spolecne funkcionality.
No ja nevim, nikdy jsem nepsal bezne DB aplikace, ale jednoduche tabulky, to jsou akorat nejake ciselniky a tech nebyva moc - ostatne kdyz je to web, tak VS je spolu s pouzivanym frameworkem schopen schopen vyprasit z ViewModelu nejakou default HTML stranku pro CRUD.

Nebo deklarovat v Delphi kodu kazdou entitu kdyz by pak byly de-facto nevyuzite v pripade spolecne funkcionality.
Tomu nerozumim. Ja v DB zadne nevyuzite entity nemam
Poslal: Delfin
« kdy: 22-12-2017, 19:55:25 »

...
Stejne jako definice pohledu na nej (vcetne pravidel pro stylovani podle hodnot). Samozrejme pro specialni pripady by byla stale moznost si takovou entitu vytvorit a pracovat s ni v kodu. Pro jednoduche editory tabulek bys ale nemusel napsat ani carku kodu, natoz aplikaci znovu buildovat - namisto toho bys jen nejakym runtime editorem naklikal co chces zobrazit a jak.
Neni mi jasne, k cemu by to melo byt dobre:
  • Uz pred Delphi existovaly zanikle VisualObjects, ktere umely automaticky z DB dat vytvorit CRUD editor s nejakym default layoutem, i kdyz kompilovanym

Asi neco takoveho. Jen bez nutnosti kompilace, vlastnorucne napsane (a tudiz upravitelne i pro pripad tvorby extra funkcionality, kde je treba psat extra Delphi kod s buildem aplikace); vzdyt muzu potrebne vytvorit "nazivo" v runtime s okamzitym pohledem na vysledek - a navrhovat by slo i oboustranne - ze schematu nabidnout modely tabulek pro tvorbu pohledu, nebo z "naklikaneho" modelu tabulky ji vytvorit v DBMS pomoci vygenerovaneho CREATE prikazu.

Me totiz porad unika proc pro "jednoduchy editor" tabulek a reportovac psat a buildovat dokola aplikaci pro kazdou z nich :P Nebo deklarovat v Delphi kodu kazdou entitu kdyz by pak byly de-facto nevyuzite v pripade spolecne funkcionality.
Poslal: pf1957
« kdy: 22-12-2017, 18:11:22 »

...
Stejne jako definice pohledu na nej (vcetne pravidel pro stylovani podle hodnot). Samozrejme pro specialni pripady by byla stale moznost si takovou entitu vytvorit a pracovat s ni v kodu. Pro jednoduche editory tabulek bys ale nemusel napsat ani carku kodu, natoz aplikaci znovu buildovat - namisto toho bys jen nejakym runtime editorem naklikal co chces zobrazit a jak.
Neni mi jasne, k cemu by to melo byt dobre:
  • Uz pred Delphi existovaly zanikle VisualObjects, ktere umely automaticky z DB dat vytvorit CRUD editor s nejakym default layoutem, i kdyz kompilovanym
  • Jestli si to dobre pamatuju, tak ve frameworku Django byly vsechny CRUD v cele administratorske sekci, kde prd zalezelo na grafickem designu, taky generovany automaticky. A neprekladalo se, protoze Python...
  • Kdyz to nechces kompilovat, chces snad vytvaret neco jako FastReport s moznosti CRUD? Tomu taky predhodis nejaky model v podobe datasetu, ma klikatko a vysledek nacpe do XML s nejakymi proprietarnimi zmolky dat
  • Nebo se chystas na neco jako XAML z WPF, ktery se take nepreklada, view ma widgety zhruba na urovni Opice, triggery, styly, binding na model etc...  a misto na objektovym modelem chces radit nad datasetem
  • nebo...
Nejak my smysl takoveho zameru unika...

Citace
IMHO se budou drzet samotne definice ORM, a to je konverze dat do objektu, tedy definic trid znamych pri prekladu a psani kodu s nimi.
Ano, ORM neni nic jineho nez ten relacni svet dostat do objektoveho a zpatky. Ale v tom objektovem svete muzes anotovat, pouzivat introspekci a vsechno co ti moderni jazyky a prostredi nabizeji a pokud se toho ucastni prekladac, tak zkontrolovat radu veci v dobe prekladu a ne az pri ladeni
Poslal: Delfin
« kdy: 22-12-2017, 15:20:16 »

No a kdyz uz jsme to dotahli sem, tak je otazka, jestli jeste stale na neco potrebujeme TFields nebo mame pokracovat v navrhu a nebo se na to vybodnout a pouzivat nejaky existujici ORM :-)

K te ukazce; ja myslel jeste na jeste abstraktnejsi reseni :)

Co uvadis jsou definice poli entity v kodu, byt u nich uz odpadla nutnost tvorit pohled (coz by se specifickymi tridami entit obecne slo leda pomoci RTTI) - byly by soucasti dataset objektu ktery je zobrazitelny a daji se pro nej vytvorit agregacni vypocty ba dokonce reporty. Nicmene, i ten dataset se da popsat pomoci nejake konfiguracni sablony (napr. v souboru) vcetne formatu poli etc. a vytvorit v runtime. Stejne jako definice pohledu na nej (vcetne pravidel pro stylovani podle hodnot). Samozrejme pro specialni pripady by byla stale moznost si takovou entitu vytvorit a pracovat s ni v kodu. Pro jednoduche editory tabulek bys ale nemusel napsat ani carku kodu, natoz aplikaci znovu buildovat - namisto toho bys jen nejakym runtime editorem naklikal co chces zobrazit a jak.

ORM pro Delphi jsem nezkoumal a nevim jestli je nektery natolik abstraktni. IMHO se budou drzet samotne definice ORM, a to je konverze dat do objektu, tedy definic trid znamych pri prekladu a psani kodu s nimi.
Poslal: pf1957
« kdy: 22-12-2017, 14:19:35 »

Myslel jsem na vlastni framework ktery vsak nebude pracovat s tridami entit, ale abstraktnejsim data storage (ala dataset).
Mozna, ze i s tou myslenkou by se dalo udelat neco pokrokoveho  ;)
Design-Time editor datasetu vytahava odkazy na pole z datasetu do formu nebo DM, aby se obesla nutnost je vyhledavat v run-time at uz pomoci FieldByName nebo Fields[ i ] (ty hnusny zavorky kolem [ a ] tam davam protoze tomu softu neumim rict, aby to neintepretoval jako tagy):
Kód: Delphi [Vybrat]
  1. TDataModuleXyz = class(TDataModule)
  2.     cdsXyz: TClientDataSet;
  3.     cdsXyzId: TIntegerField;
  4.     cdsXyzIdent: TStringField;
  5.     ...
  6. end;
  7.  

Takze mozna by se z toho dal udelat anotovany ViewModel (nemam to rozmysleno, jen napad):
Kód: Delphi [Vybrat]
  1. [ ViewModel ... ]
  2. TDataModuleXyz = class(TDataModule)
  3.     cdsXyz: TClientDataSet;
  4.  
  5.     cdsXyzId: TIntegerField;
  6.  
  7.     [ Display(Name = "View_Orders_XyzIdentLabel", Prompt = "View_Orders_XyzIdentPrompt", Hint="View_Orders_XyzIdentPromptHint" ResourceType = typeof(WebGui)) ]
  8.     [ RegularExpression('^[ A-Z ]\d+$',
  9.       ErrorMessageResourceType = typeof(WebMsg), ErrorMessageResourceName = "ModelErr_Xxx_InvalidXyzIdent") ]
  10.     cdsXyzIdent: TStringField;
  11.     ...
  12.     [ Display(Name = "View_Orders_EventFromLabel", Prompt = "View_Orders_EventFromPrompt", Prompt = "View_Orders_EventFromHint", ResourceType = typeof(WebGui)) ]
  13.     [ Format(typeof(WebGui), nil, nil, ClientFormat = "d") ]
  14.     [ DateRange(DynamicMinimum = "minEventFromRange", DynamicMaximum = "maxEventFromRange") ]
  15.     cdsXyzEventFrom: TDateField;
  16.  
  17.     [ NotMapped ]
  18.     minEventFromRange: TDateTime;
  19.     [ NotMapped ]
  20.     maxEventFromRange: TDateTime;
  21.  
  22. end;
  23.  
To by sice trpelo neduhem, ze se neco musi naklikat a neco napsat v kodu, takze se samozrejme nabizi pridani dalsi anotace s vlastni definicí pole a vyrazeni debilniho klikani:
Kód: Delphi [Vybrat]
  1. [ ViewModel ... ]
  2. TDataModuleXyz = class(TDataModule)
  3.     cdsXyz: TClientDataSet;
  4.  
  5.     [ FieldDef(Name=Id, Type=tfInteger,  Nullable=False) ]
  6.     cdsXyzId: TIntegerField;
  7.  
  8.     [ FieldDef(Name=(Ident, Type=tfString, Size=64, Nullable=False) ]
  9.     [ Display(Name = "View_Orders_XyzIdentLabel", Prompt = "View_Orders_XyzIdentPrompt", Hint="View_Orders_XyzIdentPromptHint" ResourceType = typeof(WebGui)) ]
  10.     [ RegularExpression('^[ A-Z ]\d+$',
  11.       ErrorMessageResourceType = typeof(WebMsg), ErrorMessageResourceName = "ModelErr_Xxx_InvalidXyzIdent") ]
  12.     cdsXyzIdent: TStringField;
  13.     ...
  14.     [ FieldDef(Name=(EventFrom, Type=ftDate, Nullable=True) ]
  15.     [ Display(Name = "View_Orders_EventFromLabel", Prompt = "View_Orders_EventFromPrompt", Prompt = "View_Orders_EventFromHint", ResourceType = typeof(WebGui)) ]
  16.     [ Format(typeof(WebGui), nil, nil, ClientFormat = "d") ]
  17.     [ DateRange(DynamicMinimum = "minEventFromRange", DynamicMaximum = "maxEventFromRange") ]
  18.     cdsXyzEventFrom: TDateField;
  19.     ...
  20. end;
  21.  
No a kdyz uz jsme to dotahli sem, tak je otazka, jestli jeste stale na neco potrebujeme TFields nebo mame pokracovat v navrhu a nebo se na to vybodnout a pouzivat nejaky existujici ORM :-)