developer toolbox » harbour

što se samog developmenta tiče to je sada ok

međutim juče sam zarovio u bazu pa sam tu sa ovim netio zaglavio ...

većina stvari ne radi. tom prilikom sam rovio po fmk_lib (uglavnom) i ... šta da kažem nego da je to brate zbrkano do boli :(

1. linux i windows klijent (odgovarajući GT odabrati)
2. dbf koji će omogućiti jednostavno portiranje clipper projekata, ali koji će omogućiti da se i problemi tipa - reindex e sad izađite svi uđite riješe ...
   • poznato je da je to jedan od glavnih problema kod korisnika - reindeksiranje i pucanje integriteta baze

NETIO mi može u tome puno pomoći pa obziljno razmišljam da zarovim malo žešće po fmk_lib-u a ne samo da to zakrpim sa namjerom da netio proradi

netio nije klasičan client-server databaza.

međutim sa netiom se određene stvari mogu implementirati kao client server. tako recimo kreiranje baza može da se definiše da ih obavlja server, a da ih (ovlašteni klijent) samo inicira

i upravo to razmišljam da promjenim u odnosu na postojeću client-only strukturu.

sve je krenulo od problema kod kreiranja baza gdje sada stoji

if file(dbf_taj_i_taj) ... db_create() ... endif

ne funkcinoše jer se gleda lokalna baza a netio pravi bazu na serveru ...

to se može ispraviti ali ja sada kontam da to napravim čestitije, da se sve te stvari prebace na srv_fmk koji je već sada netio server.

pored čišćenja samih naziva fajlova, i njihovog razbijanja na manje cjeline ako su ogromni kao gore ...

krećem i u promjenu naziva funkcija - više nisam ograničen na 10 slova

recimo CreKorisn => db_create_korisn ...

DBCREATE2 => db_fmk_create

CreFmkSvi => db_create_common_fmk_tables()

OFmkSvi => open_common_fmk_tables()

Ernad Husremović je napisao/la:

CreFmkSvi => db_create_common_fmk_tables()

OFmkSvi => open_base_fmk_tables()

logično bi bilo:

OFMKSvi => open_common_fmk_tables()

upravo sam to ispravio vsasa

više firmi, više sezona, više korisnika¶

više firmi¶

ako na server kažemo u nekom ini fajlu

; baza firme bringout
[db_bringout] 
BASE=bringout
ADMIN=hernad
USERS=bjasko vsasa vzeljka

znaćemo da trebamo na server_base/bringout kreirati bazu

svaki od korisnika ima svoj korisnički dir bringout/hernad, bringout/bjasko itd ...

e sad dolazimo do tabela ...

to je do sada bilo priv_path, kum_path, sif_path

kako je to najpametnije ?

korisnički direktorij je logično mjesto i za privpath .. međutim mi sada imamo pripr tabelu u fin, u kalk u fakt ....

da li da to ostavimo ? hm meni se to čini jedna od nepotrebnih komplikacija ...

puno je elegantnije - prirodnije da bude bringout/hernad/fin_pripr.dbf, bringout/hernad/kalk_pripr.dbf

a šta to znači što se tiče promjena u kodu ?

#xcommand O_PRIPR   => select(F_PRIPR); USEX (PRIVPATH + "pripr") ; set order to tag "1" 

=>

#xcommand O_PRIPR   => select(F_PRIPR); USEX (  fmk_server() + SLASH + fmk_database() + SLASH + db_user() + "_pripr") ; set order to tag "1" 

ali ovo je komplikovano

za početak pravim

bringout@bringout-developer-amd64:~/devel/fmk/fmk_lib$ cat db_fmk_vars.prg

#include "fmk.ch" 

function fmk_server()

return "127.0.0.1" 

function fmk_port()

return "2497" 

function fmk_database()

return "bringout" 

function fmk_user()

return "hernad" 

ali čekaj malo, zašto proceduralno programiram ?

zar mi nije lakše to objektno programirati ?

postoji TDB klasa

bringout@bringout-developer-amd64:~/devel/fmk/fmk_lib$ ./skeleton/skeleton_db.prg

uh jest na bezveznom mjestu

bringout@bringout-developer-amd64:~/devel/fmk/fmk_lib$ git mv ./skeleton/skeleton_db.prg class_fmk_db.prg

uh šta sam ja trao u ovu jadnu TDB klasu i menije i ko zna šta ...

• TFmkDb
• TFmkApp

TFmkDesktop

stvari se do boli zakuhavaju ....

uvodim novu klasu koja će biti nasljednik FmkDesktop klase

CLASS TFmkCuiDesktop FROM TFmkDesktop
        method menu
        method msg
        method msgO
        method MsgC
        method Box
        method BoxCls
        method Beep
END CLASS

sve funkcije koje koriste ovi metodi stavljam kao static

mirso je mnogo duplih funkcija pravio (sa copy paste) ili neke svoje verzije ... to sam za sada smjestio u cui_desktop_2.prg

klase klase ...¶

e sada ono što sam započeo može skroz drugačije da se napiše

CLASS TFmkDb
        DATA oApp
        DATA cName

        DATA cSezona
        DATA cRadimUSezona

        DATA cSezonDir
        DATA cBase
        DATA cDirPriv
        DATA cDirKum
        DATA cDirSif
        DATA cBaseDir
        DATA cUser
        DATA nPassword
        DATA lAdmin

        DATA server  INIT "127.0.0.1" 
        DATA serverPort INIT "2497" 
        DATA name INIT  "bringout" 
        DATA user INIT  "hernad" 

...        
END CLASS

zašto ova gore notacija varijabli slozenoImeVarijable¶

to je uobičajena notacija za metode i data elemente

pogledao sam u harbour source i ta se notacija imenovanja koristi pa ću je i ja slijediti

zašto sam gore uveo user kada već imam cUser¶

ostaviću sada staru varijablu ... lahko je kasnije izbrisati ...

TFmkDb ... babe i žabe¶

iz ove klase se moraju izbaciti svi dijelovi koji pripadaju interakciji sa korisnikom.

ona mora biti neovisna o TFmkDesktop-u (objektu koji će se napraviti na osnovu klase TFmkDesktop)

MVC pattern¶

pokušaću uspostaviti Model - View - controller pattern

samo mi on omogućava da da se iz ovih veza iskobeljam

harbour klase kako šta¶

dobar primjer testpers

šta ne pripada FmkDb¶

mInstall - administratorski meni - to je korisničko sučelje a ne metod vezan za pohranu podataka

pravim novu klasu

CLASS TFmkAdmin INHERITS TFmkApp
   DATA desktop
   method menuInstall()
END CLASS

method menuInstall() CLASS TFmkAdmin

menu, menu_sc ??¶

interesanto je pitanje funkcije Menu_SC - to je funkcija koja poziva funkciju menu i koja se uobičajeno koristi

zato sam je u TFmkCuiDesktop definisao kao metod menu a funkciju menu sam definisao kao static function menu_0

fmk parametri¶

uh ovo je haos ja sam ovo sve rasturio ... ovo je tako sve komplikovano postavljeno u milion nekih procedura koja jedna drugu poziva ... sad sam to sve razbuco