Mecanisme automate în CA

Visual Objects 2.0

Dupa lungi asteptari, s-a nascut în sfârsit CA-Visual Objects 2.0 - mediu de dezvoltare complet obiectual, pe 32 de biti, care ofera o cale posibila pentru migrarea aplicatiilor economice xBase sub mediul Windows. Proiectat, în special, pentru dezvoltarea aplicatiilor sofisticate în medii client-server, CA-Visual Objects asigura o cale relativ usoara de migrare de la DOS la Windows, fara „socuri culturale".

István László

De ce chiar CA-Visual Objects?

Odata cu raspândirea rapida a calculatoarelor, din categoria PC-urilor performante si a sistemelor de operare Windows, se impune, din ce în ce mai pregnant, scrierea (respectiv transcrierea) aplicatiilor pentru mediul Windows. Cu toate ca, afirmatia conform careia „fiecare sistem de operare la locul lui este util" pare corecta, nu se pot contesta avantajele sistemului Windows, în ceea ce priveste interfata spectaculoasa si intuitiva pe care o ofera chiar pentru „utilizatori de ... câmpie".

Din punctul de vedere al programatorilor, nu atât frumusetea interfetei Windows este hotarâtoare în aprecierea mediului; probabil ca o pondere mult mai mare are complexitatea codului, care este capabil sa puna în functiune o aplicatie. Situatia contradictorie, adica a cerintelor „naturale" din partea utilizatorilor (aparenta deosebita, help la fiecare nivel, tabele, grafice, culori, imagini, sunete - simplitate în folosire, interfata intuitiva, robustete, mesaje prietenoase, …) si a „realitatii" cunoscute doar de programatori (arhitectura orientata eveniment, cod complex, mediu GUI sofisticat, cerinte de securitate, siguranta si robustete) este solutionata de diverse medii de programare pe diverse cai.

Una din posibilitati este calea oferita de CA-Visual Objects. Filozofia limbajului nu este straina pentru utilizatorii de CA-Clipper, fiindca CA-Visual Objects se cladeste pe principiile acestui limbaj. Arhitectura aplicatiilor reflecta inevitabil constrângerile impuse de Windows: o arhitectura orientata eveniment.

CA-Visual Objects îmbina flexibilitatea limbajelor xBase si simplitatea modelarii obiectuale cu un limbaj strict tipizat, într-un mediu de dezvoltare complet - bazat pe un depozit activ intern de date, cu un compilator optimizator nativ si link-editor incremental, cu generatoare (sau mai bine zis editoare) vizuale, si cu debugger puternic. Limbajul este complet compatibil cu CA-Clipper, doar aduce noutati în plus: se mentioneaza, în primul rând, extensia obiectuala completa, dar este semnificativa si posibilitatea tipizarii si a definirii lexicale a variabilelor. (Aceste conditii din urma reprezinta conditia ca un limbaj sa fie compilabil.) Modificarile arhitecturale permit - cladind pe clasele DataServer - exploatarea, în mod similar, a tuturor datelor care se prezinta sub forma tabelara, indiferent de forma fizica de implementare, fie vorba de vectori multidimensionali, de fisiere DBF, sau de datele obtinute în urma evaluarii unei selectii dintr-o baza de date SQL. În acest context, scalarea unei aplicatii - daca acesta a fost proiectat corespunzator, nu mai prezinta o problema chiar asa mare…

Fiind total optimizat, pentru MS Windows 95/NT 4.0, CA-Visual Objects suporta toate controalele si conventiile specifice acestor sisteme de operare (la nivel de cuvinte cheie: Common Controls, DDE, Clipboard, Drag&Drop, DLL, OLE 2.0). Mai mult, asigura acces de nivel scazut la API-urile Win32.

Pe lânga avantajele arhitecturale si cele care provin din semantica/sintaxa limbajului, CA-Visual Objects ofera niste mecanisme si functionalitati implicite. Dezvoltarea aplicatiilor se face de sus în jos, într-un mod iterativ; astfel se asigura ca aplicatia sa fie tot timpul functionala. Folosind aceasta abordare a crearii rapide de prototipuri., „detalierea" programelor urmeaza o cale naturala.

Pentru a asigura o flexibilitate ridicata si o extensibilitate usoara, sistemul are o arhitectura deschisa:

Productivitate

Una din cerintele cheie impuse pentru un limbaj, respectiv mediu de programare, este productivitatea ridicata. Succesul unui produs nou este sensibil influentat de calitatea limbajului, dar si de calitatea mediului de dezvoltare. În acest sens, problema productivitatii poate fi defalcata în doua capitole. Pe de o parte, se cauta raspunsul la întrebarea „Ce ofera limbajult", iar, pe de alta parte, trebuie conturat raspunsul dat la „Ce ofera mediul?".

Din punctul de vedere al limbajului - pornind de la CA-Clipper, evident - se asigura compatibilitate cu limbajele xBase, în mod special cu „bunicul" CA-Clipper. În acest sens, se asigura o compatibilitate de 99%. Aceasta compatibilitate este teoretica, datorita faptului ca acesta se refera la asa zisa „business logic", adica la tot ceea ce nu este interfata utilizator, ci tine de logica programului.

Pe lânga aceasta compatibilitate cu CA-Clipper si limbajele xBase, în general, limbajul ofera o serie de extensii. Cele mai importante sunt extensia obiectuala, precum si posibilitatea tipizarii stricte si a definirii lexicale a variabilelor. Implicatiile acestor extensii sunt multiple. Productivitatea este afectata, în primul rând, de faptul ca editoarele vizuale genereaza cod de înalta calitate, bazat pe clasele predefinite ale sistemului. Pe de alta parte, posibilitatea tipizarii si a determinarii lexicale a valabilitatii variabilelor permite o compilare adevarata a programului sursa. Astfel, se explica prezenta unui compilator nativ. De mentionat ca, chiar în cadrul aceleiasi entitati (functie, procedura, metoda,…) se poate amesteca codul tipizat cu cel netipizat. Acolo unde este posibil, compilatorul genereaza cod nativ, iar, acolo unde nu se poate, genereaza pseudo-cod, care la executie se interpreteaza, ca la orice limbaj xBase „cumsecade" (vezi CA-Clipper, MS FoxPro, …).

Puterea mediului de dezvoltare se manifesta la utilizarea generatoarelor de cod. Datorita prezentei depozitului de date (repository) activ multinivel, designul entitatii editate - proiectul vizual - se pastreaza pe termen lung. Pe baza acestor proiecte, editoarele genereaza, folosind clasele sistem, cod de înalta calitate. Codul generat nu numai ca este aproape optim, dar poate servi ca si model pentru programatori.

Nu este vorba chiar de un editor vizual, dar în definitia generatorului de cod intra si generatorul OLE Automation Server.

Arhitectura

Aparent fara implicatii directe, faptul ca limbajul este obiectual iar arhitectura este orientata eveniment, are efect asupra filozofiei generale, ca urmare, si asupra productivitatii.

Se pune întrebarea ce caracteristici are „lipiciul" care, din conglomeratul claselor si a obiectelor, face pâna la urma o aplicatie functionala si în ce masura influenteaza aceasta productivitatea. (Daca nu din altceva, dar macar din acest text reiese importanta.) Arhitectura, poreclita mai înainte lipici, se materializeaza în setul de principii, pe baza carora se cladeste aplicatia. Aceasta arhitectura impune uneltele si tehnicile folosite, fiind în acelasii timp determinata si de componentele (clasele) predefinite disponibile în sistem.

Analizând, din punctul de vedere al productivitatii, principiile arhitecturale de baza, se ajunge la analiza relatiilor dintre clasele si obiectele aplicatiei, precum si a mecanismelor automate asigurate de sistem.

Mecanisme automate

În concordanta cu principiile abordarii obiectuale, sistemul CA-Visual Objects ofera o aplicatie-nucleu, numita „Standard Application", care este o aplicatie minimala cu o functionalitate oarecare. Acesta este, în principiu, punctul de pornire pentru dezvoltarea unei aplicatii reale. Functionalitatea acestei aplicatii standard este data, pe de o parte, de arhitectura ei, iar, pe de alta parte, de prezenta claselor sistem cu un comportament bine cunoscut.

Unul din domeniile analizate, în acest articol, se refera la aceste comportamente, respectiv la mecanismele automate prezente în aplicatia standard. Celalalt capitol al articolului se refera la automatizarile prezente în mediul de dezvoltare prin generatoarele de cod, accentuând rolul claselor sistem. Dupa cum am mai spus, extensibilitatea sistemului - prin arhitectura sa deschisa - joaca un rol deosebit. Anumite cai de extindere a functionalitatii se bazeaza pe mecanisme automate specifice.

Automatizari - Aplicatia Standard

În cele ce urmeaza, analiza mecanismelor automate nu va urma o secventa logica. Încercam sa abordam realitatea, de la simplu la complex.

Cele mai importante implicatii, asupra mecanismelor automate, sunt cele arhitecturale, care se oglindesc si în comportamentul claselor sistem. În acest sens, cea mai importanta este „sistemul de mesagerie", adica dirijarea automata a evenimentelor (mesajelor) între obiectele aplicatiei.

Trebuie amintite - fara pretentia de a trata complet subiectul - relatiile care leaga componentele aplicatiei. De mentionat ca, toate cele trei relatii mentionate sunt de tipul „1-la-n". Asa cum am mai mentionat, arhitectura este totalitatea principiilor, legilor, si a relatiilor care determina modul de „compunere" al obiectelor dintr-o aplicatie, precum si legaturile dintre aceste obiecte.

Relatia is a (este o/un). Este o relatie care defineste arborele de mostenire între clase în timpul compilarii. Este o relatie statica. De mentionat, ca în CA-Visual Objects, se permite nu numai mostenirea de la un singur stramos. De exemplu un ComboBox este de fapt un ListBox, care nu este altceva decât un TextControl, care, la urma urmei, nu este altceva decât un Control…

Relatia has-a (are/poseda). Relatia owner se defineste în momentul executarii. Într-un fel, arborele care se naste, în urma acestei relatii dinamice, ia locul arhitecturii structurate a aplicatiilor clasice DOS. Exemplu: aplicatia are o fereastra Shell, care are sub-ferestre de date, care au atasate controale, care la rândul lor …

Relatia Client-Server uses-a (foloseste o/un). Se defineste tot în momentul executarii si în mod clasic leaga serverul de date de ferestrele de date. În CA-Visual Objects si aceasta relatie este 1-la-n, adica o fereastra de date poate fi legata (în mod oficial si recunoscut de mediu) doar de un singur server de date.

Mecanismele automate ale aplicatiei standard se bazeaza, în mare parte, pe aceste relatii. (În cele ce urmeaza, informatiile prezentate sunt usor simplificate, deci nu se vor aminti toate laturile realitatii- în scopul de a crea un model mai simplu si de a permite o întelegere mai usoara.)

1. Legarea prin nume -- eveniment-metoda. În conceptul clasic, numai ferestrele sunt contexte de evenimente, adica doar obiectele care se trag din ferestre sunt capabile sa efectueze prelucrarea evenimentelor/mesajelor. (În cele ce urmeaza, nu vom mai face distinctie între eveniment si mesaj, deoarece declansarea unui eveniment atrage dupa sine, inevitabil, si lansarea unui mesaj cu acelasi nume - vezi deci primul mecanism automat, care este atât de evident, ca aproape nici nu a fost mentionat.)

Evenimentul, preluat de aplicatia standard, ajunge la un dispecer de evenimente, implicit al aplicatiei, care distribuie evenimentul ferestrei de care apartine controlul care a generat evenimentul (de exemplu, apasarea unui buton, sau selectarea unui element dintr-un ListBox, sau modificarea continutului unui SingleLineEdit). Metodele de tratare a evenimentelor apartin (sunt posedate) de ferestre.

Identificarea metodei care trebuie invocata se face prin nume. Adica, numele mesajului este identic cu numele evenimentului, care este identic cu numele simbolic al controlului. (Legatura dintre declansarea evenimentului si generarea mesajului este total transparenta, si în continuare, se face abstractie de aceasta. Mai mult, cititorul este chiar rugat sa uite de aceasta dualitate.) Ca urmare a evenimentului, se invoca metoda cu acelasi nume a ferestrei curente.

2. Derutarea evenimentelor. Totul decurge asa cum a fost descris mai înainte, daca metoda cu acelasi nume, ca si evenimentul/mesajul, exista! Daca nu exista, evenimentul este trimis, în mod automat, în sus pe arborele owner (has-a), la posesorul ferestrei (contextului de evenimente) curente. Aceasta, fiind la rândul ei tot un context de evenimente, încearca, din nou, identificarea metodei cu acelasi nume ca si evenimentul. Daca acesta nu este definit, se repeta totul pentru detinatorul ferestrei curente, si asa mai departe. În momentul în care evenimentul a ajuns deja la obiectul-aplicatie, care de fapt sta pe vârful arborelui owner si nu s-a identificat la nici un nivel metoda corespunzatoare, dispecerul de evenimente procedeaza în felul urmator:

Luând în considerare cele de mai sus, devine clar de ce si cum sistemul sustine o abordare top-down, respectiv de ce este posibila o proiectare iterativa a aplicatiei.

3. Obiecte inteligente. Cu putina exagerare, putem afirma ca obiectele pot fi inteligente: definind metodele NoMethod(), NoIVarGet() si NoIVarPut(), controlul se transfera acestor metode ori de câte ori se emite un mesaj, caruia nu îi corespunde nici o metoda, ori se încearca citirea sau atribuirea de la o variabila de instanta nedefinita. Astfel, se poate modifica sau extinde functionalitatea unui obiect dinamic, în momentul executarii.

Cu toate ca sarcina crearii si distrugerii obiectelor este preluata de sistem, în unele cazuri este nevoie de anumite initializari la creare, respectiv de unele actiuni de de-alocare la distrugerea obiectului în cauza. În acest scop, se pot defini metodele Init() si Axit(), care se invoca automat, imediat dupa crearea, respectiv, imediat înainte de distrugerea obiectului. Utilitatea acestor metode devine evidenta în cazul în care obiectul contine la rândul sau, alte obiecte, care, înainte de folosire, trebuie sa fie initializate, respectiv, resursele alocate trebuie sa fie eliberate, înainte de distrugerea obiectului gazda.

4. DataServer - configurat în momentul executarii. Pentru accesarea datelor, sub forma tabelara, se foloseste clasa DataServer. Aceasta este o coaja care înveleste sursa reala de date si are un rol dublu: pe de o parte, ascunde implementarea concreta, forma de manifestare fizica a datelor - fie tabel în memorie, fie DBF local - CDX, NTX, sau MDX compatibile, fie un motor SQL undeva în retea; pe de alta parte ofera o interfata unica (vezi rolul si avantajele izomorfismului din modelul obiectual) surselor de date. Prin aceasta interfata comuna, programele devin independente de structura concreta a datelor. Câmpurile DataServer-ului pot fi accesate si prin nume.

Ramânând la ipoteza unui fisier DBF, daca structura acestuia nu este cunoscuta în timpul compilarii, nu exista alta solutie: serverul de date trebuie sa se configureze - în functie de structura fisierului - în timpul rularii aplicatiei. Într-adevar, serverul de date îsi poate modifica proprietatile în timpul executiei.

Merita facuta observatia ca aceasta auto-configurare nu impune o modificare reala a structurii obiectului, ci se modifica numai structura virtuala. Evident, s-a folosit un mecanism asemanator celor prezentate în paragraful precedent.

5. Legarea prin nume - DataWindow. Ferestrele servesc la vizualizarea diverselor date. Fereastra cea mai complexa ca si functionalitate este DataWindow, adica fereastra de date. Ca si orice alta fereastra, pe suprafata DataWindiow pot fi asezate diverse controale. Controalele specializate pentru vizualizarea datelor (deci, de exemplu SingleLineEdit, MultiLineEdit, CheckBox, ListBox, ComboBox, RadioButton, …) pot fi direct legate de câmpurile serverului de date atasat ferestrei.

Specificarea relatiei uses-a, adica a relatiei client-server, dintre fereastra de date si serverul de date, se face printr-un simplu apel al metodei Use(). Ca urmare a acestui apel, controalele de date cu nume identice cu câmpurile de date ale serverului se leaga, adica, valoarea din controale reflecta valoarea din sursa de date, si vice-versa.

6. FieldSpec. Toate informatiile, care determina un câmp de date, sunt colectate într-un singur obiect numit FieldSpec. Pe lânga descrierea tipului (N, C, L, D, M, OLE) si a lungimii câmpului, aici se gasesc si informatiile de delimitare a domeniului (lungime, domeniu, reguli de validare).

Avantajul folosirii acestor obiecte consta, pe de o parte, într-o întretinere mai simpla, mai usoara a aplicatiei (descrierile se propaga automat în toate locurile unde se foloseste FieldSpec-ul respectiv), iar, pe de alta parte, pe baza acestora functioneaza metodele automate de validare a câmpurilor, atât la nivelul serverelor de date cât si la nivelul ferestrelor de date atasate.

7. Vizualizarea datelor - AutoLayout . Jobul cel mai important, dintr-o aplicatie economica, este de obicei vizualizarea datelor. Pentru acesta, fereastra de date ofera, pe lânga legarea controalelor de câmpuri prin nume, posibilitatea vizualizarii automate a datelor (auto-layout în momentul executarii). Optional, la legarea ferestrei de un server (vezi metoda Use(), din paragraful precedent) aceasta interogheaza structura sursei de date si îsi construieste, conform structurii serverului, doua vederi: un FormView si un BrowseView. Comutarea, între cele doua moduri la vizualizare, se face prin trimiterea unui mesaj catre fereastra respectiva de date.

Mai mult, regulile de validare a câmpurilor sunt preluate, în mod automat, din obiectele FieldSpec asociate câmpurilor.

8. Metode de navigare - DataWindow. Structura ferestrei de date, fie în FormView, fie în BrowseView repeta structura serverului de date, cu observatia ca, fiecarui câmp de date îi corespunde ori un control (de obicei Single/MultiLineEdit sau CheckBox), ori un obiect DataColumn. Ca similitudinea sa fie perfecta, însasi fereastra de date asculta de aceleasi comenzi de navigare (GoTo, GoTop, GoBottom, Skip, SkipPrevious, Append, …) ca si serverul de date.

9. Sub-ferestre de date. Ferestrele de date sunt capabile sa lucreze cu sub-ferestre de date, care au forma de manifestare asemanatoare cu un control complex, dar, la rândul lor, sunt ferestre de date al caror server se leaga de serverul de date al ferestrei-mama, prin relatia SetSelectiveRelation. De altfel, comportamentul sub-ferestrei este identic cu comportamentul ferestrelor de date. Încuibarea sub-ferestrelor nu este limitata sub nici o forma (doar de genialitatea utilizatorului final si de dimensiunea ecranului).

Amenajarea legaturilor dintre servere, respectiv datele vizualizate, se face în mod automat de fereastra mama.

10. Acces concurent. În medii de tip Windows, programatorul (facând abstractie de câteva cazuri fericite) este nevoit sa-si proiecteze aplicatia special pentru exploatare multiuser/multitasking, chiar daca este vorba de un calculator singuratic. Ca urmare, se pune accent pe serviciile privind modul de lucru concurent. Pentru preîntâmpinarea greutatilor, fereastra de date din CA-Visual Objects ofera niste mecanisme predefinite de control al concurentei. De mentionat, ca, daca programatorul nu este multumit cu nici una din functionarile predefinite, este liber sa-si implementeze - folosind de mecanismul Notify prezentat în urmatoarele - propria metoda de control.

CCNone. Serverul de date nu asigura de la sine nici un serviciu de lock-ink.

CCOptimistic. Blocarile nu sunt permanente. Înainte de a aplica o modificare, articolul este recitit si, daca este identic cu imaginea pastrata în memorie, se blocheaza si se aplica modificarile. Daca sunt diferente, se raporteaza eroare si noile valori se propaga catre fereastra de date.

CCStable. Articolul curent vizualizat (în mod BrowseView rândul curent) este blocat în mod continuu.

CCRepeatable. Toate articolele care au fost odata vizualizate se mentin în stare blocata. Astfel, se asigura ca la o noua vizualizare datele sunt nemodificate.

CCFile. Toate aticolele serverului, din selectia curenta, sunt blocate. Acesta nu este util în general pentru fisiere întregi, pentru ca este echivalent cu un FileLock, dar se recomanda folosirea ei pentru servere legate prin relatia SetSelectiveRelation (vezi sub-ferestre de date).

11. Mecanismul Notify. Cum am mai discutat, relatia client-server este o relatie 1 la n, adica unui server de date i se pot atassa mai multe ferestre de date, sau clienti. În fiecare fereastra se vizualizeaza un subset de câmpuri al acelorasi articole. O modificare a starii serverului trebuie sa se reflecte la nivelul fiecarui client în parte. În acest scop, clientii serverului trebuie cumva anuntati asupra modificarii (sau tentativei de modificare).

Clientii unui server de date pot fi înregistrati si de-înregistrati, fara nici o restrictie. Singura conditie, ca un obiect sa fie recunoscut ca si client, este ca acesta sa aiba definita metoda Notify().

Declansarea unui eveniment atrage dupa sine trimiterea unui mesaj catre fiecare client în parte. Metoda Notify() al obiectelor client este invocata cu un parametru care specifica natura evenimentului. (De exemplu, FieldChange, IntentToMove, RecordChange, GoTop, FileChange, RelationChange, …). Folosind faptul ca obiectul client nu trebuie sa fie o specie anumita de fereastra, dar trebuie sa dispuna de o metoda Notify(), se pot formula solutii extrem de elegante la cele mai diverse probleme. (Vezi, de exemplu, tema unui alt articol, despre ComboBox-uri conectate on-line la acelasi server de date…)

12. HyperLabel. În filozofia CA-Visual Objects, majoritatea claselor, chiar daca nu se impune, se permite folosirea unui sistem evoluat de etichetare. Obiectul HyperLabel, atasat unui alt obiect, contine informatii despre obiectul gazda. Astfel, se pastreaza numele, numele ca simbol (NameSym), eticheta (Caption), descrierea (Description) si contextul pentru WinHelp (HelpContext) ale obiectului.

Aceasta etichetare are rol multiplu. Pe de o parte joaca rol la vizualizarea unui control de date (eticheta se afiseaza în fata controlului, descrierea pe linia de stare, iar contextul serveste la identificarea paginii de Help), sau la controale de comanda numele/numele simbolic din HyperLabel determina numele evenimentului. Schimbând, de exemplu, în mod dinamic numele unui PushButon, se genereaza automat alt eveniment la apasarea acestui buton.

13. Send(). Este posibila trimiterea unui mesaj într-un mod indirect, folosind functia Send(). Sintaxa la apel a functiei este urmatoarea:

Send([<oObject>], <symMethod>, [<MethodArgList>]) ---> uValue.

Treaba devine interesanta în momentul în care programatorul constientizeaza ca numele metodei de invocat nu trebuie cunoscut în momentul compilarii. Mai mult, numele simbolic al metodei de invocat se poate „compune din mers". De mentionat ca, folosind functia IsMethod() se poate interoga obiectul în cauza, indiferent daca are sau nu definita metoda cu numele specificat. Ca sa fie si mai elegant, folosind doua functii similare se pot interoga/adresa chiar si metodele unei super-clase.

14. Obiecte si controale OLE. Dupa cum am mai spus, sistemul este compatibil OLE 2.0 si suporta, pe lânga încuibarea obiectelor, si înserarea în ferestre a controalelor OLE - numite controale OCX. Comportamentul lor, în contextul celor ce urmeaza, este acelasi, deci nu vor fi tratate separat.

Încuibarea controalelor OCX se poate face on-the-fly; ca sistemul sa poata sa gestioneze asemenea obiecte, este necesar ca acesta sa fie capabil sa interogheze interfata lor: metodele, modul de apel al metodelor, variabilele de instanta. Din momentul în care aplicatia dispune de aceasta interfata, ea poate lucra cu obiectele respective ca si cu obiecte proprii.

Aplicatia standard este capabila sa insereze, în câmpurile de tip OLE ale fisierelor, date obiecte OLE, fie folosind direct metodele specifice containerelor OLE, fie folosind dialogurile standard de Insert-, respectiv Paste OLE Object.

15. OLE Automation Server. Unul din mecanismele OLE 2.0 se materializeaza în definirea unui protocol de interogare a macro-limbajului, prin care o aplicatie poate fi programata din exterior. (OLE Automation standardizeaza doar protocolul de interogarea macro-limbajului, si nu macro-limbajul în sine!)

Urmatoarea secventa de cod foloseste programul Word pentru a demonstra lansarea unui Automation Server. Deoarece serverul se ruleaza în spate, invizibil, doar fereastra HelpAbout modificata se va vizualiza.

FUNCTION Start()
LOCAL oAuto AS OLEAutoObject
oAuto:=OLEAutoObject{"word.basic"}
oAuto:HelpAbout(;
"CA Word Version 2000 for VO",; // AppName
"Copyright 1700-2001",; // AppCopyright
"CA-Visual Objects 2.0",; // AppUserName
"OLE Sample",; // AppOrganization
"ABCDEFG"; // AppSerialNumber)

Dezavantajul metodei configurarii la runtime este ca programatorul trebuie sa cunoasca, în momentul scrierii codului interfata serverului (în acest caz existenta metodei HelpAbout si sintaxa apelului), care se va conecta doar în timpul rularii aplicatiei. Avantajul este, evident, flexibilitatea obtinuta.

Automatizari - Mediul de Dezvoltare Vizual

Din punctul de vedere al productivitatii, joaca un rol deosebit de important prezenta uneltelor de dezvoltare vizuale (evident din categoria WYSIWYG evoluate…) si a generatoarelor de cod automate. De importanta similara sunt si uneltele care servesc la extinderea mediului de dezvoltare. Bineînteles, nu putem gasi perfectiunea în nici un generator de cod (cu exceptia celor umane…), dar se poate pretinde un nivel oarecare, calitativ, de la medii de dezvoltare putin mai serioase.

16. Functia Import - Servere de Date. Atât editorul DBServer, cât si editorul SQL Server construiesc clasa specifica sursei de date. Clasa noua mosteneste toate proprietatile clasei server, dar, în plus, dispune de variabilele de instanta, de metodele acces si assign pentru fiecare câmp de date în parte.

Rezultatul functional obtinut este echivalent cu ceea ce se obtine la auto-configurare în momentul executarii, dar intern este total diferit. În timp ce la auto-configurare structura sursei se reflecta într-o structura virtuala, clasa generata de editor prin specializare reflecta fizic structura sursei.

Avantajul generarii claselor, în timpul compilarii, se simte nu numai la viteza de executie, dar si la posibilitatea verificarii corectitudinii codului - din punctul de vedere al existentei si proprietatilor câmpurilor de date.

Evident, cele descrise pentru un DBServer sunt total valabile si pentru familia de clase specifice surselor de date SQL.

17. AutoLayout - Editorul de Ferestre. Nu se pot închipui aplicatii economice care sa prelucreze date sub o forma sau alta, dar sa nu afiseze rezultate pe ecran. Afisarea datelor fara ferestre de date se face doar în situatii mai rare. Ca urmare, se poate afirma ca nu exista aplicatie la dezvoltarea careia sa nu se foloseasca editorul de ferestre.

Folosind functia AutoLayout a editorului, este posibil sa se specifice serverul de date la care se va conecta fereastra. Ca urmare a comenzii, se vor genera, în mod automat, pe lânga un design vizual, si entitatile de resurse, controalele de date, precum si codul pentru gestionarea controalelor de pe fereastra corespunzatoare câmpurilor serverului.

Editorul permite modificarea manuala, în mod independent, a celor doua moduri de vizualizare - FormView si BrowseView; deci, design-urile generate automat servesc drept punct de pornire pentru programator. Bineînteles, pentru a pastra independenta totala a codului generat, în mod automat si a codului scris manual, trebuie sa se respecte anumite reguli de joc - dar acestea nu sunt importante în acest moment.

18. Generatorul de Meniuri. Majoritatea aplicatiilor ofera un set comun de comenzi meniu. Acestea se ofera sub forma unor meniuri standard predefinite, care, optional, pot fi adaugate la meniul editat. (Aceste elemente optionale sunt File, Edit, View, Window si Help).

Dat fiind faptul ca meniurile standard genereaza evenimente standard, multe comenzi din meniu au metodele corespondente deja definite la nivelul ferestrei shell sau a ferestrelor de date. (De exemplu, FileOpen, FileClose, FileExit, GoTop, SkipPrevious, SkipNext, GoBottom, FormView, BrowseView, Help).

Cum s-a mai spus în paragrafele anterioare, structura ferestrei de date, în esenta, dubleaza structura serverului de date atasat. Astfel se explica prezenta de exemplu a metodelor de navigare în baza de date (Skip~, Go~).

19. Generator de Clase - Controale OCX. Pentru a insera Controale OCX în ferestrele aplicatiei se pot folosi de mecanismele run-time descrise mai înainte, sau se poate folosi generatorul de clase specializat la clasele OCX, care dau nastere la clasele specifice si metodele de interfatare a controlului OCX. Astfel, se obtine o interfata conform standardelor CA-Visual Objects.

20. Generatoare de Clase - OLE Automatin Server Generator. Cum s-a mai discutat, OLE Automation nu reprezinta un standard de comunicare inter-aplicatii, doar (sau poate mai mult prin aceastat) un standard de interogare a interfetei unei aplicatii zise compatibil OLE Automation. Prin interogare, folosind macro-limbajul de programare al aplicatiei, sistemul obtine informatiile necesare, pentru a genera proprietatile si metodele claselor specifice care asigura o interfatare în stil VO a aplicatiei.

Rezultatul generarii va fi o clasa - sau mai multe clase - prin care aplicatia straina poate fi controlata, conform sintaxei si semanticii limbajului CA-Visual Objects. Eleganta consta în generarea acestei interfete

Într-un viitor articol, se vor analiza aceste mecanisme automate, pe rând, exemplificând eleganta limbajului, si utilitatea automatizarilor - prin exemple de cod concrete.

István László este general manager la Networks ltd. Oradea si poate fi contactat la istvan@lego.soroscj.ro

(C) Copyright Computer Press Agora