Aplicatii Profesionale BDOO

Universitatea din Bucureti
Facultatea de Matematic i Informatic

A Ap pl li ic ca a i ii i p pr ro of fe es si io on na al le e n n b ba az ze e d de e d da at te e
o or ri ie en nt ta at te e o ob bi ie ec ct t

Master Baze de date i tehnologii web
Anul I, Semestrul I

Oracle9i Developer Suite - Crearea aplicaiilor profesionale cu Forms i Reports 2
Cuprins
1. INTRODUCERE ...................................................................................................... 4
2. ORACLE9I FORMS DEVELOPER......................................................................... 6
2.1. INTRODUCERE .................................................................................................... 6
2.2. ARHITECTURA SERVICIILOR FORMS................................................................... 7
2.3. PUBLICAREA FORMELOR.................................................................................... 8
2.4. PROIECTAREA FORMELOR................................................................................ 10
2.4.1. Diagrama conceptuala exemplu.............................................................. 10
2.4.2. Componentele Forms Builder.................................................................. 11
Object Navigator .................................................................................................. 11
Paleta de proprieti (Property Palette)................................................................. 13
Editorul vizual (Layout Editor) ............................................................................ 15
Editorul PL/SQL................................................................................................... 16
2.4.3. Instrumente de tip wizard........................................................................ 17
2.4.4. Testarea formelor .................................................................................... 27
Modul insert ......................................................................................................... 31
Modul query ......................................................................................................... 35
2.4.5. Rafinarea formelor .................................................................................. 40
2.4.6. Palete de proprieti................................................................................ 43
2.4.7. Atribute vizuale........................................................................................ 47
2.4.8. Proprietile ferestrelor .......................................................................... 48
2.4.9. Proprietile unui bloc de date................................................................ 49
2.5. BLOCURI MASTER-DETAIL................................................................................ 58
2.6. GESTIONAREA ELEMENTELOR TEXT ................................................................. 71
2.7. BUTOANE (PUSH BUTTONS)............................................................................... 83
2.8. CANVAS-URI DE TIP SUPRAPUS (STACKED CANVAS)............................................ 87
2.9. LISTE DE VALORI (LOVS) ................................................................................ 92
2.10. ALTE TIPURI DE ELEMENTE INTR-UN FORMULAR............................................. 99
2.10.1. Casete de validare................................................................................... 99
2.10.2. Elemente lista ........................................................................................ 100
2.10.3. Grupuri de butoane radio...................................................................... 101
2.11. DECLANATORI (TRIGGER-I)........................................................................... 103
2.11.1. Trigger-i de interogare (query triggers) ............................................... 109
2.11.2. Trigger-i de validare ............................................................................. 111
2.11.3. Trigger-ii navigationali ......................................................................... 114
2.11.4. Trigger-ii tranzactionali........................................................................ 115
3. ORACLE9I REPORTS DEVELOPER................................................................. 120
3.1. INTRODUCERE ................................................................................................ 120

3
3.2. PROIECTAREA RAPOARTELOR........................................................................ 123
3.2.1. Componentele Reports Builder.............................................................. 123
Object Navigator ................................................................................................ 124
Report Editor ...................................................................................................... 125
Property Inspector .............................................................................................. 127
Editorul PL/SQL................................................................................................. 127
3.2.2. Instrumente de tip wizard...................................................................... 127
3.3. REPORT EDITOR 5 MODURI DE VIZUALIZARE A RAPORTULUI ..................... 136
3.4. RAPOARTE CU GRUPURI MASTER-DETAIL ...................................................... 145
3.5. MODIFICAREA RAPOARTELOR FOLOSIND DATA MODEL ............................... 152
3.5.1. Crearea manuala a grupurilor.............................................................. 153
3.5.2. Adaugarea manuala a coloanelor......................................................... 156
3.6. MODIFICAREA RAPORTULUI FOLOSIND PAPER LAYOUT ................................ 159
3.6.1. Cele 3 sectiuni ale raportului: header, main, trailer ............................ 159
3.6.2. Margini.................................................................................................. 162


1. 1. Introducere Introducere
Corporaia Oracle ofer un set complet de instrumente pentru gestionarea datelor
i dezvoltarea de aplicaii performante. Produsele incluse n versiunea 9i sunt: Oracle9i
Developer Suite (Oracle9iDS), care permite crearea de aplicaii ce vor fi stocate i rulate
pe Oracle9i Application Server (Oracle9iAS) i care acceseaz datele din Oracle9i
Database.
Versiunea 9i a sistemului Oracle prezint o arhitectur pe 3 niveluri (3-tier):
clientul este pe primul nivel, Oracle9i Application Server pe nivelul din mijloc i server-
ul de baze de date este pe cel de-al treilea nivel.
Oracle9iDS (Developer Suite) este un set complet de instrumente pentru crearea
de aplicaii i servicii web, asigurnd ntregul ciclu de via al unei aplicaii, de la
modelare, scriere de cod de orice tip (incluznd Java Server Pages, servlet-uri, forme),
pn la testare i depanare.
Produsele Oracle9i folosesc un set comun de tehnologii, care permit utilizarea
aceleiai aplicaii n medii cu configuraii arhitecturale variate. Java, XML i PL/SQL sunt
limbaje complementare utilizate pentru dezvoltarea de aplicaii, iar Oracle9iDS permite
folosirea n paralel a celor trei.
Oracle9i Developer Suite ofer instrumente vizuale, wizard-uri, utilitare pentru
verificarea automat a sintaxei, pentru editarea elementelor grafice i de interfa, toate
acestea permind dezvoltarea rapid de aplicaii i uurarea muncii programatorului.
Aplicaii de tipuri diferite cer instrumente de dezvoltare diferite. Aceast idee este
implementat cu succes n Oracle9i Developer Suite unde gsim, n principal,
urmtoarele componente:
1. Oracle Designer conine instrumente ce permit specificarea cerinelor i
proiectarea schemei aplicaiei ntr-un mediu vizual, oferind utilitare de reverse
enginnering i generare automat de cod;
2. Oracle Forms Developer se ocup de prezentarea logic a aplicaiei,
genernd formulare sofisticate ce permit operaii DML pe tabelele bazei de date;
formularele pot conine cmpuri calculate, sume totale sau pariale, liste diverse,
alerte toate create cu un efort de programare minim;
3. JDeveloper este un mediu integrat pentru crearea, depanarea i gestionarea
aplicaiilor XML pe mai multe niveluri i a componentelor bazate pe J2EE;

5
4. Oracle Portal organizeaz toat informaia (coninut web, aplicaii) sub
forma unui portal. Poate fi permis accesul de la distan al dispozitivelor wireless,
opiune util pentru persoanele care cltoresc des;
5. Oracle Reports Developer, Oracle Discoverer, Oracle Express permit
analizarea informaiei din surse diverse, crearea de rapoarte complexe i
distribuirea lor n formate diverse i n medii diverse (email, imprimant, fiier,
portlet). Un raport poate fi mprit logic n mai multe seciuni i, printr-o singur
rulare, seciuni diferite vor fi trimise ctre destinatari diferii.
Oracle9iDS face saltul de la arhitectura client-server la cea web-enabled. n
versiunile 6i i anterioare acesteia era necesar instalarea de componente Oracle pe
fiecare client. Pentru rularea formularelor i a rapoartelor trebuia instalate pe client
componentele Forms RunTime i Reports RunTime. n versiunea 9i aceste runtime-uri se
instaleaz pe Oracle9iAS. Deci, pe client nu este necesar instalarea de aplicaii Oracle,
fiind ncarcata, la rulare, doar interfaa grafic a aplicaiei.
Algoritmul parcurs la rularea unui formular este urmtorul: clientul (reprezentat
de un browser web) trimite o cerere ctre server-ul de aplicaii (Application Server - AS).
Aceast cerere este preluat de server-ul HTTP Oracle (Apache), care recunoate tipul ei
i o redirecioneaz prin server-ul web ctre instrumentele corespunztoare (de exemplu,
dac este un formular, l trimite ctre Oracle Forms). n urma prelucrrii cererii naintate
de ctre browser, Oracle9iAS i rspunde acestuia printr-un document HTML care poate
fi construit n unul din mai multe moduri: PL/SQL, Java, printr-un program CGI etc.
Oracle9iAS prezint o arhitectur pe niveluri, cu urmtoarele tipuri de servicii:
de comunicare pentru recunoaterea unui numr mare de protocoale;
un container J2EE creeaz un mediu runtime pentru aplicaii;
servicii sistem;
servicii de conectivitate pentru sisteme diverse.
Dintre componentele Oracle9i Developer Suite ne vom opri, n capitolele
urmtoare, asupra urmtoarelor dou: Forms Developer i Reports Developer.

2. 2. Oracle9i Forms Developer Oracle9i Forms Developer
2.1. 2.1. Introducere Introducere
Oracle Forms are dou componente: Oracle Forms Developer, un mediu de
dezvoltare de aplicaii, care este inclus n Oracle9i Developer Suite i Oracle9i Forms
Services, un mediu pentru publicarea aplicaiilor, aflat pe Oracle9i Application Server.
Oracle Forms Developer ofer un mediu pentru dezvoltarea de formulare
complexe ce permit accesul la datele din baza de date. Integrarea sa cu Oracle Designer
permite folosirea unui model creat n acest mediu de programare i generarea automat de
formulare conform cerinelor proiectate n Oracle Designer. Mecanismul de inginerie
invers (reverse engineering) permite ca modificrile fcute apoi n Oracle Forms
Developer s fie implementate automat n model, pstrndu-se, astfel, integritatea dintre
model i aplicaie.
Limbajul de programare folosit n Forms este PL/SQL, codul aplicaiilor fiind
interpretat n timpul rulrii. Interfaa web a unei aplicaii Forms este un applet Java,
obinut fr ca utilizatorul s scrie un singur rnd de cod Java.
Oracle9i Forms folosete un interpretor runtime, dar nlocuiete motorul
client/server din versiunile anterioare cu unul web, care ncarc pe staia client interfaa
aplicaiei folosind un set generic de clase Java. Principalul avantaj este c se pot publica
formele pe web fr a modifica nici o linie de cod. Formele web sunt accesibile printr-un
URL scris n bara de adrese a browser-ului.
Iat, n continuare, cteva din caracteristicile reprezentative ale produsului:
Oracle Forms Developer conine wizard-uri pentru crearea rapid de aplicaii
n care nu este nevoie de nici o linie de cod. Funcionalitatea formularelor este
asigurat de proceduri i funcii predefinite (numite built-ins).
Unitile de program PL/SQL pot fi plasate pe server-ul bazei de date sau n
interiorul aplicaiei, n funcie de cerine. Se poate face drag-and-drop asupra
obiectelor, deplasndu-le ntre module i server-ul bazei de date.
Aplicaiile Oracle9iDS pot fi folosite de un singur utilizator sau de mai muli
utilizatori simultan, fr nici o modificare n cadrul sursei.
Oracle Forms Developer folosete modelul de motenire obiectual, care
permite motenirea atributelor i a codului ntre obiecte i module.

7
2.2. 2.2. Arhitectura serviciilor Forms Forms Arhitectura serviciilor
Componenta Forms Services reprezint un cadru de lucru pe trei niveluri folosit
pentru a publica formularele dumneavoastr pe Internet, folosind interfee Java deosebite.
Cele trei niveluri sunt: clientul, server-ul de aplicaii i baza de date Oracle9i. Modul de
lucru cu o aplicaie Oracle9i Forms respect urmtorul algoritm:
1) utilizatorul (reprezentat printr-un browser web) nainteaz o cerere sub forma
unei aplicaii, ce va fi accesat printr-o adres URL. Acest URL este trimis
server-ului HTTP (Apache), care sesizeaz c este vorba despre o aplicaie
Developer Forms i trimite cererea ctre Forms Servlet.
2) Forms Servlet-ul detecteaz ce browser are utilizatorul, apoi creeaz dinamic
o pagin HTML coninnd toat informaia necesar pentru iniierea unei
sesiuni Forms (numit i motor runtime). Dup ce pagina este ncarcat n
browser, acesta iniiaz descrcarea unui applet Java client, constnd ntr-un
set de clase Java (doar dac acest applet nu a fost deja descrcat n cadrul
unei alte sesiuni, caz n care este pstrat n memoria cache). Clientul Forms
Java ruleaz pe o main virtual Java (care, implicit, este JInitiator) i
acceseaz servlet-ul Forms Listener (aflat pe nivelul din mijloc unde este
server-ul de aplicaii). Forms Listener deschide un motor runtime web,
crend pentru aceast sesiune un cookie, depozitat n memorie sau ataat
URL-ului la fiecare cerere i rspuns. Acest cookie nu este niciodat stocat pe
calculatorul utilizatorului.
3) Pentru fiecare client Forms listener demareaz cte un proces runtime web
nou (ifweb90.exe). Acest proces este cel care se conecteaz la baza de date i
comunic cu clientul Forms, gestionnd logica aplicaiei i procesarea.
Astfel, datele nu sunt ncrcate n browser-ul client, ci interschimbate ntre
server-ul de aplicaii (Application Server) i server-ul de baz de date
(Database Server), reducndu-se traficul n reea i mbuntindu-se
performanele. Procesul runtime comunic cu clientul Java folosind
protocoalele HTTP sau HTTPS.
4) Servlet-ul Forms Listener stabilete o conexiune cu motorul runtime, care se
conecteaz la baza de date. El este cel care, prin intermediul server-ului
HTTP sau al container-ului OC4J gestioneaz comunicarea dintre applet-ul
Forms i motorul runtime. Motorul runtime web comunic inteligent cu
clientul Java, comparnd mesajul actual cu cel transmis anterior i
transmind doar informaia ce a fost actualizat. Astfel, traficul n reea este
redus substanial.
5) Interfaa utilizator Forms este un applet Java care folosete un set de clase
Java prestabilit. Acesta afieaz interfaa utilizator a aplicaiei n fereastra

browser a utilizatorului. Odat descrcat acest applet n browser-ul
clientului, pot fi rulate orict de multe i de complexe aplicaii Forms, fr
descrcri ulterioare. Setul de clase Java este pstrat n memoria cache pn
la detectarea unei versiuni noi a Forms-ului, caz n care va fi actualizat.
Interfeele Java utilizate n Oracle9i Developer Forms ofer acelai design i
calitate ca cele utilizate n aplicaiile client/server, fr a cere din partea
utilizatorului final cunotinte superioare. n plus, logica aplicaiei este mutat
pe nivelul din mijloc, al server-ului pe aplicaii, asigurnd performane
sporite aplicaiei.

2.3. 2.3. Publicarea formelor Publicarea formelor
Procesul de publicare pe web a formelor este implementat, deci, conform ideii c
logica aplicaiei i motorul runtime al serviciilor Forms se afl pe server-ul de aplicaii.
Toate procesele ce acioneaz asupra datelor se execut la nivelul bazei de date i al
server-ului de aplicaii, n timp ce interfaa aplicaiei se afl pe clientul Forms.
Utilizatorul final ruleaz o aplicaie Forms Developer ntr-un browser web, invocnd-o
printr-o adres URL care pointeaz ctre aplicaie. Componenta Forms Services
genereaz apoi un fiier HTML care descarc un applet Java pe maina client. Acest mic
applet este cel care permite afiarea interfeei formei, n timp ce logica aplicaiei se
execut pe server-ul de aplicaii.
La rularea formei sunt vizibile urmtoarele:
1. fereastra browser-ului;
2. applet-ul Java (coninut n fereastra browser-ului);
3. meniul implicit (coninut n applet);
4. meniul smartbar (coninut n applet);
5. bara de stare (coninut n applet).
O cerere naintat de utilizator va avea urmtorul rezultat:

9

3
4
1
2
5
Meniul implicit este parte a tuturor aplicaiilor Forms i conine intrri pentru
operaiile de baz ce se pot efectua asupra datelor din form (salvare n baza de date,
ncrcarea n formular a unei nregistrri noi, tergerea din baza de date a nregistrrii
curente, operaii de commit i rollback etc.) Acest meniu poate fi eliminat sau
personalizat, aa cum vom vedea ntr-un capitol ulterior.
Meniul smartbar conine butoane a cror apsare are aceeai aciune cu unele
dintre opiunile meniului implicit i este utilizat pentru accesarea direct a acestora. n
runtime, acest meniu este afiat deasupra oricrui eventual meniu definit de utilizator. Ca
i cel precedent, i meniul smartbar poate fi eliminat sau personalizat.
Bara de stare este afiat n partea inferioar a ferestrei i conine informaii
dependente de context, cum ar fi:
Record:n/m - sunt afiate nregistrri ncepnd de la a n-a din grupul de m
nregistrri ncrcate de pe server;
Enter-Query blocul curent este n modul Enter-Query;

LOV elementul curent (cel pe care este concentrat focus-ul) are asociat
o list de valori;
n bara de adrese a browser-ului se poate observa URL-ul prin care este invocat
aplicaia. n cazul nostru, acesta este:
http://smart.com:8888/forms90/f90servlet?form=D:\carte\rulare.fmx&userid=C
ARTE/C@o9i&buffer_records=NO&debug_messages=NO&array=YES&query_only=N
O&quiet=NO&RENDER=YES
Componentele URL-ului sunt:
Protocolul http
Domeniul smart.com
Portul pentru server-ul HTTP sau pentru
OC4J
Xxxx implicit pentru server-ul http
8888 implicit pentru OC4J
Alias-ul servlet-ului Forms /forms90/f90servlet
Parametri: seciunea ncepe cu caracterul
?; parametrii sunt separati prin & i
pot fi specificai n URL sau n fiierul
de configurare Forms
form=D:\carte\rulare.fmx
userid=CARTE/C@o9i
buffer_records=NO
debug_messages=NO
array=YES
query_only=NO
quiet=NO
RENDER=YES

URL-ul pointeaz, deci, ctre servlet-ul Forms (/forms90/f90servlet). Acesta este
un servlet Java care creeaz o pagin HTML dinamic n conformitate cu informaia luat
din urmtoarele surse: fiierul de configurare web (formsweb.cfg), fiierul HTML de baz
al Forms-ului (basejini.html) i parametrii din adresa URL a aplicaiei.

2.4. 2.4. Proiectarea formelor Proiectarea formelor
2.4.1. 2.4.1. Diagrama conceptual exemplu Diagrama conceptual exemplu
Exemplele din lucrare se refer la un model de gestiune a componentelor de
calculatoare dintr-un depozit. Modelul ales este simplu, astfel nct nelegerea sa s
necesite efort minim, scopul nostru constnd n focalizarea ateniei cititorului ctre
nsuirea modului de lucru cu produsul Oracle Forms. Schemele relaionale din
exemplele folosite n lucrare sunt:

11
stoc (cod_prod#, tip_prod, den_prod, pret_unit, cantit);
clienti (cod_firma#, nume_firma, sold);
facturi (cod_fact#, cod_firma, data, io);
produse (cod_fact#, cod_prod#, cantit).
S facem urmtoarele precizri: clienii emit facturi pe baza crora pot cumpra
sau vinde componente de calculatoare. Datele fiecrei facturi sunt reinute n tabela
facturi; fiecare factur are un cod_fact care o individualizeaz. Cmpul io va reine tipul
facturii (1 dac factura este de intrare, 0 dac este de ieire). Pe o factur pot fi cumprate
(sau vndute) mai multe produse. Acestea sunt gestionate de tabela produse. Tabela
stocuri conine informaii despre componentele aflate n depozit.
Dorim s crem o aplicaie care s permit operarea facturilor emise de clieni.
La inserarea unei facturi noi, stocul i soldul firmei vor fi automat reactualizate.

2.4.2. 2.4.2. Componentele Forms Builder Forms Builder Componentele
Object Navigator
Object Navigator (figura 2.3.1) reprezint o interfa ce ofer o prezentare
ierarhic a obiectelor (aflate att pe client, ct i pe server) din modulele deschise.
Obiectele sunt grupate dup nodurile corespunztoare. De exemplu, toate ferestrele create
pentru modulul curent sunt grupate n nodul windows.

Bara de instrumente
folosite pentru
crearea, tergerea,
expandarea sau
contractarea
nodurilor.

Figura 3.2.1. Interfaa Object Navigator.
Nodurile de nivel cel mai nalt n ierarhia Object Navigator sunt: forme, meniuri,
biblioteci PL/SQL, biblioteci de obiecte, pachete predefinite i obiecte ale bazei de date.
Toate celelalte noduri sunt indentate pentru a arta faptul c ele aparin acestor noduri de
nivel superior.
Obiectele i nodurile sunt afiate cu un + sau n fa, semnificnd faptul c
sunt sau nu expandate. Obiectele care nu pot conine obiecte de nivel inferior sunt afiate
cu un disc n fa. Fiecare obiect din Object Navigator are ataat un icon care i sugereaz
tipul. n general, dublu click pe icon-ul ataat invoc un editor corespunztor obiectului
(pentru stil sau coninut).
Prin intermediul interfeei Object Navigator se pot efectua operaii complexe i
diverse asupra obiectelor din form:
expandarea i restrngerea nodurilor pentru vizualizarea optim a
obiectelor;
selectarea, crearea i tergerea de obiecte;
copierea i mutarea obiectelor ntre noduri;

13
accesarea altor moduri de vizualizare a obiectelor i proprietilor lor;
localizarea rapid a obiectelor prin folosirea opiunii FastSearch.
Paleta de proprieti (Property Palette)
Fiecare obiect dintr-un modul (inclusiv modulul nsui) are proprieti specifice
tipului su. Ele sunt accesibile prin intermediul paletei de proprieti, care se acceseaz
din meniul de context al obiectului selectat (click dreapta pe obiect) opiunea Property
Palette sau apsnd tasta F4 cnd obiectul (sau grupul de obiecte) pentru care se vrea
afiat paleta de proprieti este selectat. Paletele de proprieti ale obiectelor de acelai
tip au ntotdeauna aceleai capitole i aceleai detalii; putem numai seta aceste proprieti,
nu le putem terge sau aduga unele noi. Fiind pozitionai pe o proprietate, apsarea tastei
F1 are ca efect afiarea unei ferestre-help cu descrierea proprietii respective.

Figura 3.2.2. Paleta de proprieti a unui obiect modul

n figura 3.2.2 este afiat paleta de proprieti a unui modul. Observai faptul c
proprietile sunt grupate logic ntr-o ierarhie, n raport cu funcionalitatea lor. Intrrile
care au fost lsate la valoarea implicit sunt prefixate de un disc gri, pe cnd celor ce au
fost modificate le este ataat un dreptunghi verde. Exist proprieti motenite, care sunt
marcate printr-o sageat, precum i proprieti care iniial au fost motenite, apoi au fost
suprascrise, caz n care sunt prefixate de o sageat urmat de un x rou.
Lista proprietilor unui obiect conine dou coloane: prima indic numele
proprietii, iar a doua valoarea proprietii (atributului). Se pot modifica atributele
selectnd proprietatea corespunztoare; n cea de-a doua coloan, dedicat atributelor,
poate aprea, n funcie de proprietatea selectat, un cmp text (pentru editarea
atributului), o list de tip pop-up (pentru atributele care au un set specificat de valori
valide) sau un buton More (cnd proprietatea curent cere valori mai complexe).
Paleta de proprieti este dependent de context. Totui, exist cteva intrri
comune majoritii obiectelor utilizate n formulare:
zona General d obiectului un nume i-i definete tipul;
zona Functional - stabilete modul de funcionare a cursorului, atunci cnd se
afl n cmpul asociat obiectului;
zona Navigation definete ordinea i stilul de navigare ntre obiecte;
zona Data controleaz tipul obiectului i eventuala legtur dintre acesta i
baza de date.
Implicit, paleta de proprieti se actualizeaz automat la selectarea unui alt obiect.
Cnd este necesar compararea proprietilor a dou obiecte, se poate deschide o palet
adiional acionnd n prealabil butonul Pin/Unpin . Selectarea mai multor obiecte
(realizat prin inerea apsat a tastei Shift i click pe fiecare dintre obiecte) afieaz o
palet de proprieti comun obiectelor selectate, ca n figura 3.2.3:

15

1
2
Figura 3.2.3. Paleta de proprieti comun unui set de obiecte
Implicit, este afiat intersecia proprietilor obiectelor. Acest mod se poate
schimba prin apsarea butonului marcat cu 2 n figura 3.2.3 (butonul Intersection/Union).
Atributele (valori ale proprietilor) diferite ale aceleiai proprieti sunt marcate prin
***** (vezi marcajul 1 din figura 3.2.3).
Editorul vizual (Layout Editor)
Editorul vizual este un instrument folosit pentru crearea i modificarea interfeei
grafice a formei. De aici se pot seta culori, setul de caractere, mrimea i poziia
elementelor incluse n form. Acestea se aeaz ntr-un canvas, care este afiat n runtime
ntr-o fereastr (window). Un canvas este o suprafa aflat ntr-o fereastr-container, pe
care se poziioneaz obiectele cu care interacioneaz utilizatorul la rularea formularului.
Setnd proprietatea window a canvas-ului, specificm n ce fereastr va fi afiat acesta.
Utilitarul Layout Editor permite lucrul, la un moment dat, cu un singur canvas. Canvas-ul
conine doar elemente cu care utilizatorul nu poate interaciona: texte statice (care pot fi
formatate ntr-o diversitate de moduri de ctre programator), elemente grafice etc. Fcnd
analogie cu munca unui pictor, fereastra este cadrul pe care acesta i fixeaz pnza,
reprezentat de canvas.


n bara de titlu a ferestrei editorului vizual avem informaii despre contextul de
lucru, inclusiv canvas-ul i blocul n care lucrm. Putem schimba canvas-ul curent
selectnd un altul din lista indicat de sgeata din figura anterioar. Folosind bara
vertical de instrumente din stnga ferestrei editorului vizual putem crea obiecte noi, care
vor fi automat asignate canvas-ului i blocului curent.
Editorul PL/SQL
Editorul PL/SQL permite inserarea i compilarea de cod PL/SQL, precum i
asocierea acestuia obiectelor din formular. Invocarea editorului PL/SQL se face prin click
dreapta pe obiectul care permite ataarea de cod PL/SQL. Obiectele care suport cod n
Forms Developer sunt trigger-ii, subprogramele (funcii i proceduri), pachetele.

17

Opiunea Type din partea superioar a ferestrei editorului PL/SQL definete tipul
obiectului ce va fi creat (n cazul nostru trigger), iar opiunea Object ataeaz codul
unui obiect specificat. n colul stnga-sus al ferestrei se afl butonul Compile PL/SQL
Code, la apsarea cruia compilatorul detecteaz erorile de sintax, semantic i
referinele ctre obiecte inexistente.
2.4.3. 2.4.3. Instrumente de tip wizard wizar Instrumente de tip d
Orice form este creat pentru a interaciona cu un set de date, care se pot gsi n
tabele sau pot fi generate de o procedur stocat. Paii care trebuie parcuri pentru crearea
unei forme noi sunt, n general, urmtorii:

crearea unui modul nou s-a efectuat prin click pe semnul verde (marcat
n figura de mai jos cu sgeat) din bara de instrumente a ferestrei Object
Navigator (sau, echivalent, File New Form) i are rezultatul urmtor:

crearea blocurilor de date i a elementelor sale (n general, se face cu ajutorul
instrumentului Data Block Wizard);
definirea proprietilor vizuale ale formei (cu ajutorul lui Layout Wizard sau
Layout Editor);
setarea proprietilor obiectelor (din paleta de proprieti a fiecrui obiect);
adugarea de cod PL/SQL, acolo unde este cazul (folosim editorul PL/SQL);
testarea formei (dnd click pe butonul Run Form , reprezentat n bara de
instrumente sub forma unui semafor verde).

19
S parcurgem mpreun aceti pai i s crem un formular simplu, care s
permit gestionarea clienilor firmei. Primul pas const, dup cum am precizat, n
stabilirea blocului de date pe care se bazeaz formularul.
Exist dou tipuri de blocuri: de date i de control. Blocurile de ultimul tip
conin, n general, butoane care permit efectuarea unor aciuni (definite prin trigger-i
asociai unor evenimete cum ar fi click pe buton), cmpuri totalizatoare, cmpuri ascunse
(folosite pentru a memora variabile) i orice obiect ce nu trebuie asociat cu un bloc de
date. Blocurile de date sunt cele prin intermediul crora manevrm datele din baza de
date. ntr-un bloc de date se stocheaz liniile ce provin dintr-o tabel sau cele ce vor fi
introduse n tabel; un bloc de date este, de fapt, un container pentru duplicarea
informaiei din baza de date. Fiecare bloc de date gestioneaz o singur tabel (folosirea
n form a datelor dintr-o alt tabel implic definirea unui nou bloc de date) i are o
funcionalitate implicit pentru modurile insert i query (cele dou moduri de lucru cu o
form vor fi prezentate n mod detaliat n continuare). Modul n care funcioneaz un bloc
de control trebuie definit explicit, programatic.
ncepem, deci, cu definirea blocului de date pe care se bazeaz forma. Dublu
click pe intrarea Data Block din Object Navigator determin apariia unei casete de dialog
prin care definim modul n care vom crea blocul de date: folosind Data Block Wizard sau
manual. Pentru nceput, s dm click pe OK, lsnd bifat opiunea implicit - Use the
Data Block Wizard. Acesta este un utilitar care permite crearea sau modificarea rapid a
blocurilor de date folosite n aplicaie, precum i generarea automat de cod pentru
respectarea constrngerilor de integritate definite n baza de date.
Primul pas al wizard-ului const n afiarea unei ferestre de ntmpinare, a crei
apariie poate fi inhibat prin deselectarea casetei Display this page next time. Click pe
butonul Next determin apariia unei ferestre n care suntem invitai s precizm sursa
blocului de date: dintr-o tabel sau generate de o procedur. (vezi figura de mai jos)


Pentru nceput, vom crea o form ce va permite gestionarea clienilor firmei care
lucreaz cu depozitul de componente pentru calculatoare, deci vom lsa bifat opiunea
Table or View i vom da click pe butonul Next, fapt ce va determina trecerea la
urmtorul pas al wizard-ului:

21

n cmpul Table or View va trebui sa selectm tabela sau vizualizarea pe baza
creia construim forma. Click pe butonul Browse ataat acestui cmp determin apariia
unei casete de dialog Connect, prin care facem conectarea la baza de date, apoi afiarea
tuturor tabelelor i vizualizrilor din schema utilizatorului curent. Am ales, din lista ce a
aprut, tabela clienti i zona Available Columns a fost ncrcat cu coloanele din aceast
tabel. Folosind butoanele etichetate > , >> , < , << populm zona DataBase Items cu
coloanele ce vor fi utilizate n formular. La acest pas va fi creat, pentru fiecare dintre
coloanele selectate de noi, cte un obiect de tip text item. Selectarea butonului Enforce
Data Integrity determin impunerea automat a constrngerilor de integritate definite la
nivelul bazei de date. Un click pe butonul Next ne va conduce la pasul urmtor al wizard-
ului, unde denumim blocul de date pe care l crem. Implicit, numele blocului de date este
acelai cu cel al tabelei sau vizualizrii pe baza creia a fost creat. Din motive didactice,
schimbm numele blocului de date n BL_CLIENTI. Click pe butonul Next determin
afiarea unei noi ferestre:


n care suntem anunai c am parcurs cu succes toi paii wizard-ului i suntem
ntrebai dac vrem doar s crem blocul de date sau s invocm urmtorul utilitar,
Layout Wizard. Crearea blocului de date nu a implicat i crearea reprezentrii vizuale a
obiectelor incluse n el, aa c n continuare ne vom ocupa de modul cum vom afia
coninutul blocului de date n scopul interaciunii cu utilizatorul. Putem face acest lucru
manual sau dnd click pe butonul Finish i continund, deci, cu instrumentul Layout
Wizard.
Dup o fereastr de ntmpinare a crei apariie poate fi inhibat ca i n wizard-
ul precedent, urmeaz pasul al doilea al wizard-ului, n care stabilim tipul canvas-ului n
care vor fi plasate obiectele din blocul de date, precum i alte obiecte noi, pe care le vom
defini pe parcurs.

23

n mod implicit, o form se bazeaz pe un canvas de tip content (coninut), ns o
fereastr poate conine mai multe tipuri de canvas:
stacked (stiv), folosit n special pentru afiarea de informaii la declanarea
unui eveniment (de exemplu, atunci cnd focus-ul intr pe cmpul clieni vrem
s apar n fereastr un canvas - din punct de vedere vizual va fi un dreptunghi
care are definite elemente vizuale - care s ofere informaii despre clieni; la
click pe suprafaa canvas-ului, acesta va disparea);
vertical toolbar (bar vertical de instrumente), folosit, n general, pentru
definirea unei bare verticale de instrumente. Poate conine butoane la apsarea
crora se vor declana aciuni specificate, de exemplu, prin secvene de cod
PL/SQL ataate butoanelor;
horizontal toolbar (bar orizontal de instrumente) identic, ca funcionalitate,
cu bara vertical. Va fi poziionat automat n partea superioar a ferestrei, pe
toat limea ei;

tab creeaz aplicaii tab-type n care datele nrudite sunt grupate pe aceeai
pagin de tab. Sunt folosite, n general, cnd avem tabele cu un numr mare de
coloane i aezarea tuturor n acelai canvas ar produce confuzie.
Alegem ca datele s fie afiate ntr-un canvas de tip content i trecem la
urmtorul pas al wizard-ului, n care va trebui s specificm ce cmpuri din blocul de date
vor fi afiate n form:

Dintre cmpurile disponibile (Available Items) va trebui s selectm, folosind
grupul de butoane etichetate <, <<, >, >> pe cele care dorim s fie afiate. Cmpurile care
nu vrem s fie afiate ca atare i care vor fi folosite (de exemplu, n formule de calcul) sau
vor fi completate automat cu ajutorul unor formule trebuie lsate n zona din partea
stng. S selectm toate cmpurile, dnd click pe butonul >>. n colul din stnga-jos al
ferestrei observm o list etichetat Item Type. Implicit, tipul obiectelor create astfel este
de tip text item i la acest moment le lsm i noi de acest tip. Dnd click pe butonul Next
ajungem la urmtorul pas al wizard-ului:

25

Wizard-ul deduce tipul, lungimea i alte informaii referitoare la cmp din tabela
pe baza creia este construit blocul. Putem schimba aici eticheta (Prompt), lungimea i
limea pe care va fi afiat coninutul obiectului din coloana Name, aceste modificri
influennd layout-ul formei, nicidecum structura bazei de date. Dnd click pe Next
ajungem la urmtorul pas al wizard-ului, unde suntem ntrebai ce stil de prezentare
alegem pentru formular: Form sau Tabular. La selectarea uneia sau alteia dintre cele dou
opiuni, n stnga ferestrei va fi afiat o imagine sugestiv a modului n care va arta
formularul. Menionnd c stilul Tabular este folosit tradiional pentru forme de tip
master-detail, lsm bifat opiunea Form i trecem mai departe dnd click pe familiarul
de acum buton Next.
Urmtorul pas al utilitarului Layout Wizard ne cere s dm un nume cadrului n
care va fi afiat blocul de date (s-l completm: Clientii firmei mele), numrul de
nregistrri ce vor fi afiate la un moment dat (lsm valoarea implicit, 1), distana dintre
nregistrri, n cazul n care sunt afiate mai multe) precum i apariia sau nu a unei bare

verticale de derulare. Toate aceste lucruri pot fi modificate ulterior, cu ajutorul paletei de
proprieti a obiectelor, aa c la acest moment le lsm neschimbate i trecem la
urmtorul pas, apsnd butonul Next.
La ultimul pas al wizard-ului dm click pe butonul Finish i este afiat rezultatul:

n partea stng a ferestrei Forms Builder avem Object Navigator, n care au
aprut toate obiectele coninute n forma noastr: nodul Data Blocks are ca subnod pe
BL_CLIENTI, care conine cele trei elemente de tip text, folosite pentru afiarea unei
nregistrri din tabela CLIENTI. Aceste elemente sunt aezate n canvas-ul cu numele
implicit Canvas4. Putem schimba numele canvas-ului dnd dou click-uri (dar nu dublu
click) pe nume, apoi tastnd numele dorit. Automat, numele canvas-ului va fi actualizat
pentru obiectele aflate n orice fel de relaie cu el.
Dup cum putei observa n captura anterioar de ecran, odat cu crearea unui
bloc de date cu ajutorul instrumentului Data Block Wizard, Forms Builder-ul creeaz
automat urmtoarele:

27
un modul care are o funcionalitate motenit (sunt implementate automat
operaiile de insert, delete, update i query pentru coloanele din tabela pe
care este bazat blocul de date);
un obiect frame (suportul vizual pe care sunt aezate item-urile);
cte un item pentru fiecare coloan din tabela inclus n blocul de date (un
item este reprezentarea grafic a unui obiect; cele mai multe dintre item-uri
sunt asociate coloanelor din tabel);
o etichet pentru fiecare item (implicit, eticheta este numele coloanei);
declanatori (sau trigger-i) pentru impunerea constrngerilor de la nivelul
bazei de date, n cazul n care caseta de validare Enforce data integrity a
fost bifat.
n partea din dreapta a ferestrei Builder-ului s-a deschis automat utilitarul Layout
Editor, care permite rafinarea aspectului formei. S observm c cele dou ferestre se
sincronizeaz, n sensul c selectarea unui obiect n una din ele duce la selectarea
automat a aceluiai obiect n cealalt fereastr.
Dac nu avem pretenii prea mari de la aplicaia noastr, putem considera c am
ncheiat faza de proiectare a formularului. Probabil c scopul muncii noastre nu este
crearea unei forme de unic folosin, aa c este indicat s salvm rezultatul
impresionantului nostru efort intelectual. Facem acest lucru dnd click pe File Save
sau direct, pe butonul Save din meniul Forms Builder. O ferestr de dialog
cunoscut deja din mediul windows ne invit s alegem un nume i o locaie pentru
fiierul pe care suntem pe cale s l crem. Dnd click pe butonul OK obinem un fiier cu
extensia .fmb. Acesta nu este un executabil i poate fi deschis numai cu Forms Builder-ul.
Dac lucrm simultan cu mai multe module, acestea vor fi stocate n fiiere
separate, deci operaia de salvare trebuie fcut pentru fiecare n parte.
2.4.4. 2.4.4. Testarea formelor o Testarea formel r
nainte de rularea formei trebuie compilat fiierul .fmb creat. Automat, va fi creat
un fiier executabil cu acelai nume i extensia .fmx. Operaia de compilare poate fi
efectuat:
explicit, n unul din modurile:
n meniul Forms Builder dm click pe Program Compile Module
lansnd Form Compiler din meniul Start al Windows-ului:


lansnd executabilul Form Compiler (ifcmp90.exe) din linie de comand
implicit, setnd opiunea Build Before Running aflat n meniul Forms
Builder: Edit Preferences

29

n concluzie, modulele Forms pe care le crem sunt stocate n fiiere binare .fmb
care sunt portabile ntre platforme. Fiierele executabile .fmx sunt stocate, de asemenea,
n format binar, dar nu sunt portabile ntre platforme. Pentru fiecare modul poate fi
generat un fiier text (portabil) cu extensia .fmt: n meniul Form Builder alegem File
Convert, iar n caseta de dialog ce apare selectm tipul modulului, fiierul pe care trebuie
s l convertim i direcia (Binary-to-Text sau invers).
Putem genera automat documentaie pentru modulul nostru, selectndu-l n
Object Navigator i dnd click pe File Administration Object List Report. Aceast
operaie va produce un fiier ASCII cu numele identic cu cel al modulului i extensia .txt.
Cu toate c modulele create pot fi testate pe maina client, pentru dezvoltarea
unor aplicaii profesionale aceste module trebuie transferate pe server-ul de aplicaii. n
cazul n care acesta ruleaz pe o platform diferit, se transfer (cu ajutorul utilitarului
ftp, de exemplu) fiierul .fmb pe maina pe care se afl server-ul de aplicaii, iar acolo se
invoc Form Compiler, pentru recompilare. n cazul n care server-ul de aplicaii ruleaz
pe aceeai platform ca cea pe care a fost dezvoltat aplicaia, poate fi transferat direct
fiierul .fmx.
Dup ce fiierele executabile au fost transferate pe Oracle9iAS, aplicaia poate fi
ncrcat n fereastra unui browser prin intermediul URL-ului su, care pointeaz ctre
servlet-ul Forms.

Deocamdat ne aflm, ns, n faza de testare i depanare a aplicaiei, iar acestea
se pot face i pe maina pe care rulm Form Builder. n acest scop, n Oracle9i Developer
Suite a fost inclus Oracle9iAS Containers for J2EE (OC4J), astfel nefiind necesar
instalarea produsului Oracle9i Application Server pentru testarea aplicaiilor Developer
Forms.
Instana OC4J se pornete dnd dublu click pe fiierul startinst.bat i ofer un
mediu complet pentru rularea aplicaiilor Java 2 Enterprise Edition (J2EE) coninnd,
printre altele, i servlet-ul Forms Listener. OC4J ruleaz ntr-o fereastr DOS, care poate
fi minimizat, dar nu nchis atta timp ct vrem s rulm modulele create. Pentru oprirea
instanei OC4J se ruleaz fiierul de comenzi stopinst.bat.
Ne ntoarcem acum la formularul creat pentru gestionarea clienilor firmei. S
startm, deci, instana OC4J i s apsm butonul Run Form, pe care l cutam n bara de
instrumente a Form Builder-ului i l recunoatem dup semaforul verde cu care este
etichetat. Rezultatul obinut este afiat n fereastra unui browser:

31

Comportamentul implicit al lui Oracle Forms const n dou moduri de
funcionare:
modul insert (inserare);
modul query (interogare).
Modul insert
La deschiderea unei forme, aceasta se gsete n modul de lucru insert, care
permite operaii DML pe tabel. n bara de stare a applet-ului Java este semnalat modul
n care lucrm. n cazul modului insert, mesajul Record: 1/1 semnific faptul c suntem
poziionai pe prima nregistrare, din grupul de 1 care sunt ncrcate n applet.
Pentru exemplificare, verificm ce clieni are, deocamdat, firma. S lucrm ntr-
un mediu presupus cunoscut: deschidem o sesiune SQL*Plus i afim toate nregistrrile
tabelei clienti:

S presupunem c dorim adugarea unui nou client al firmei, al crui cod este
510, iar nume - RDC Computers. Soldul iniial este 0. Completm aceste date n
cmpurile corespunztoare din form.
Simpla completare a cmpurilor nu va duce la salvarea datelor n tabel (i ne
putem convinge de acest lucru interognd, n SQL*Plus, tabela clienti). n cazul n care
dorim editarea la acest moment a datelor mai multor clieni, apsm tasta sgeat n jos i
observm, n bara de stare, c s-a trecut la o nou nregistrare, vid, care se ateapt a fi
completat. Practic, a fost creat o nregistrare nou, vid. O completm i salvm
rezultatul muncii noastre (prin click pe Action Save din meniul implicit al produsului
Developer Forms), aciune care este echivalent cu binecunoscutul commit. Exist i un
echivalent al instruciunii rollback , invocat prin Action Clear All (sunt anulate toate
modificrile facute de la ultima instruciune commit).

Observai bara de stare, n care avem confirmarea salvrii celor dou nregistrri.
Dac nu avem, deocamdat, destula ncredere n abilitile noastre, putem verifica printr-
o comand SQL faptul c cei doi clieni se afl n tabela clienti:

33

Dup cum ai sesizat deja, n form putem lucra cu mouse-ul sau cu tastatura.
Fiecare buton are asociat cte o cheie funcional. La crearea unei aplicaii profesionale,
trebuie gsit modul optim n care toate aceste faciliti s fie comunicate end-user-ului.
Corespondenele dintre butoane i taste se gasesc la Help Keys (sau Ctrl+K):


Navigarea ntre obiectele din form se poate face n mai multe moduri:
utiliznd tasta Tab;
folosind opiunile Field Previous sau Next din meniul implicit Forms;
dnd click pe cmpul pe care dorim s l editm;
ncercarea de a prsi cmpul cod_firma fr ca acesta s aib un coninut va
eua, fapt care intr n comportamentul implicit al formei; acest cmp mapeaz coloana
cod_firma a tabelei, care este cheie primar i, implicit, se presupune c nu trebuie lsat
vid. Cum se poate modifica acest mod de lucru vom vedea ceva mai trziu.
Ordinea cmpurilor n Object Navigator este foarte important; n aceast ordine
vor fi accesate n form la navigarea cu tasta Tab (sau cu Field Next).

35
Modul query
Trecerea din modul insert n modul query se face prin opiunea din meniul
implicit Query Enter:

Utilizatorul aduce n formular o copie a nregistrrilor asupra crora vrea s
lucreze. Modul Query permite definirea unui criteriu (filtru) pe baza cruia sistemul va
crea fraza select executat n momentul populrii blocului de date. Eventualele modificari
ale nregistrrilor nu vor fi operate n baza de date dect la comanda Action Save.
Exist dou feluri de cereri:
nerestricionate (sau globale), prin care utilizatorul aduce n form copii ale
tuturor rndurilor tabelei pe care se bazeaz blocul de date asupra cruia se
efectueaz cererea;

restricionate, acestea fiind echivalentul selectrii unei submulimi a mulimii
rndurilor tabelei, conform unui filtru indicat de utilizator.
Pentru realizarea unei cereri nerestricionate, vom efectua una din aciunile:
selectm Query Execute;
click pe butonul Execute Query din meniul smartbar;
apsm combinaia de taste Ctrl+F11.
Oricare din aceste actiuni are ca efect popularea blocului de date cu toate
nregistrrile din tabela de baz.
S ncercm acum efectuarea unei cereri restricionate: comutm n modul query
(Query Enter) i introducem, n cmpul cod_firma, criteriul: >505. Dup cum v-ai dat
seama, click pe Query Execute va avea ca rezultat generarea unei cereri SQL cu o
clauz where creat conform filtrului introdus de utilizator, n cazul nostru ncrcarea n
formular a copiilor nregistrrilor pentru care cod_firma este mai mare dect 505.
Observai cum, n bara de stare, este semnalat faptul c formularul se afl n
modul Enter-Query. n acest moment, blocul pe care am fost surprini nu poate fi prsit,
singurele aciuni posibile fiind:
introducerea unui filtru i executarea cererii (cu Ctrl+F11 sau Query
Execute);
abandonarea modului query prin apsarea tastei F4 sau Query Cancel.
Se pot introduce filtre complexe, pe mai multe cmpuri simultan. Urmtorul
filtru:

37

va afia toate firmele al cror cod este mai mare dect 505 i care au litera a n
numele firmei.
S subliniem, deci, c introducerea de filtre pe mai multe item-uri se transpune
ntr-o fraz select cu o clauz where n care ntre aceste condiii este pus operatorul AND.
Dac vrem o clauz where cu disjuncie ntre condiii, procedm n felul urmtor: s
presupunem c vrem s aducem n form copii ale nregistrrilor n care cod_firma este
mai mare dect 505 SAU ale celor care conin irul Comp n denumire. Pentru aceasta
invocm modul Enter Query i completm n cmpul cod_firma valoarea :a, iar n
cmpul nume_firma valoarea :b. ntrebarea imediat este: cine sunt a i b, prefixati de :?
Acestea reprezint variabile de legtur (bind variable), semnul : semnificnd faptul c
acestea nu sunt interne mediului curent.
Selectarea opiunii Query Execute va determina afiarea unei ferestre numite
Query/Where, unde se ateapt introducerea clauzei where, dup toate regulile din SQL:


Dup stabilirea clauzei where ca n figura anterioar, click pe OK va determina
aducerea n form a tuturor firmelor al cror cod este mai mare dect 505 SAU al cror
nume conine irul Comp. Comutm ntre nregistrri cu ajutorul tastelor-sgei sus i
jos sau din meniul implicit Forms, Record Next sau Previous. n meniul smartbar
exist, de asemenea, butoane corespunztoare acestor funcii. Le putei descoperi uor,
deoarece au ataate imagini sugestive i, mai mult dect att, trecerea cu mouse-ul peste
fiecare determin apariia unui text informativ relativ la butonul curent.
Dup introducerea filtrelor exist posibilitatea aflrii (naintea aducerii de copii n
form) numrului de nregistrri ce verific criteriul, folosind opiunea din meniul
implicit Query Count Hints:

39

Observai mesajul din bara de stare: cererea va gsi 6 nregistrri (ce ndeplinesc
criteriul cod_firma>505).
Sintetiznd, obinem urmtoarele asemnri i diferene ntre cele dou moduri
implicite de lucru n form:

Aciuni Modul Insert Modul Query
cereri restricionate (cu clauza where)

cereri nerestricionate (fr clauza where)

caseta de dialog Query/Where

insert/update/delete

navigarea n afara blocului curent

shutdown-ul procesului runtime

Criteriile dup care vor fi formulate cererile restricionate sunt urmtoarele:
completarea (n modul Query) a unui item cu o valoare i executarea cererii
va implica aducerea n form a nregistrrilor pentru care cmpul
corespunztor item-ului are valoarea specificat;
completarea unui item cu un ir coninnd % sau _ va duce la formularea unei
cereri cu o clauz where coninnd operatorul like;
folosii semnul # n faa operatorilor SQL; exemplu: #between 501 and 505;
utilizai formatul implicit al datei: DD-MON-YY;
n caseta de dialog Query/Where irurile de caractere i datele calendaristice
vor fi incluse ntre apostrofuri.
2.4.5. 2.4.5. Rafinarea formelor ea formelo Rafinar r
Dup crearea modulului (folosind cele dou wizard-uri prezentate anterior),
utilizatorul va dori sa l personalizeze sau s l modifice, lucru ce poate fi fcut n unul
sau mai multe moduri:
1) rafinarea blocului de date se poate face:
invocnd Data Block Wizard n modul reentrant;
efectund modificri manual, de exemplu adugarea sau tergerea de item-
uri;
modificnd proprietile obiectelor, folosind paleta de proprieti;
2) rafinarea machetei modulului se poate face:
invocnd Layout Wizard n modul reentrant;
invocnd Layout Editor (prin selectarea Tools Layout Editor sau click
drepta pe un obiect n Object Navigator Layout Editor) i efectund
manual modificri;
modificnd proprietile cadrului n paleta sa de proprieti.
O caracteristic foarte util a celor dou wizard-uri prezentate anterior este
capacitatea de a putea fi apelate n modul reentrant (chiar i pentru blocurile sau frame-
urile care nu au fost create cu Data Block Wizard, respectiv Layout Wizard), mod n care
toi paii parcuri sunt prezentai ntr-o singur fereastr de tip tab.
Pentru invocarea utilitarului Data Block Wizard n modul reentrant:

41
selectm un obiect din blocul de date sau frame-ul n Object Navigator sau n
Layout Editor (observai c cele dou ferestre sunt sincronizate la selectarea
unui obiect n oricare dintre ele, acelai obiect va fi automat selectat n
cealalt fereastr);
apelm instrumentul Data Block Wizard n oricare dintre modurile nvate
pn acum:
o selectnd Tools Data Block Wizard din meniul Form Builder;
o click dreapta i selectnd Data Block Wizard din meniul de context ce
apare;
o click pe butonul Data Block Wizard din meniul numit main toolbar al
Builder-ului;
Rezultatul oricreia dintre aceste aciuni va fi:


Observai n fereastra care a aprut cele trei pagini Tab corespunztoare celor trei
pai parcuri de utilitarul Data Block Wizard.
Invocarea instrumentului Layout Wizard n modul reentrant se face:
selectnd cadrul (frame) n Object Navigator sau Layout Editor;
lansnd Layout Wizard, n oricare dintre modurile:
o click pe Tools Layout Wizard;
o click dreapta pe cadru i selectnd Layout Wizard;
o click pe butonul Layout Wizard din meniul Builder-ului.
Rezultatul va fi, ca i n cazul precedent, o fereastr tab-type avnd pe fiecare
pagin tab cte unul din paii parcuri de wizard:

43

Modificm, pe pagina a doua, eticheta item-urilor, apoi acionm butonul Finish
(care determin o aciune prealabil implicit Apply). Rulai aplicaia i observai
modificrile fcute.
2.4.6. 2.4.6. Palete de proprieti Palete de proprieti
O alt modalitate de a rafina modulele create este modificarea comportamentului
sau a modului de afiare a obiectelor folosind paletele lor de proprieti.
Primul pas n dezvoltarea unei aplicaii Forms const n crearea unui modul.
Acesta are proprieti predefinite, care pot fi, ns, modificate folosind paleta de
proprieti a modulului. Selectm modulul n Object Navigator i din meniul de context
ce apare la click drepta selectm Property Palette (acelai lucru se putea obine apsnd
tasta F4 atunci cnd modulul este selectat n Object Navigator):


Se pot obine informaii despre fiecare din proprietile ce se pot seta la acest
nivel selectnd proprietatea i apsnd tasta F1. Proprietile care au nc valoarea
implicit sunt prefixate, n paleta de proprieti, de un disc, n timp ce acelea care au fost
modificate sunt marcate cu un ptrat verde. O proprietate ce a fost modificat poate fi
adus la valoarea implicit prin apsarea butonului Inherit din bara de meniu a paletei de
proprieti. Toate modulele vor avea aceleai intrri n paleta de proprieti. Capitolul
General ofer informaii generale legate de modul. Intrarea Name permite modificarea
numelui modulului (lucru ce poate fi realizat i n Object Navigator, dnd de dou ori
click pe numele modulului i editnd noul nume), iar Comments este folosit pentru
adugarea de comentarii utile pentru dezvoltatorii de aplicaii, uurnd astfel munca de
ntreinere i depanare.
La capitolul Funcional se poate seta fereastra n care va aprea modulul
(Console Window), precum i meniul care va fi asociat acestuia. Implicit, modulul va fi
afiat cu cele dou meniuri precizate anterior, aa c la intrarea Menu Module vom gasi

45
DEFAULT&SMARTBAR. tergerea oricruia dintre cele dou nume va determina
dispariia meniului respectiv la rularea aplicaiei. Putem defini, de asemenea, meniuri-
utilizator, iar aici este locul n care le asociem modulului curent. Capitolul Menu Security
conine intrarea Menu Role. Aici se specific rolul care i este acordat utilizatorului la
rularea meniului.
Capitolul Navigation conine dou proprieti:
Mouse Navigation Limit n care se precizeaz ct de departe poate naviga
end-user-ul cu mouse-ul; implicit, proprietatea este setat la Form,
nsemnnd c este permis navigarea n orice item din form; alte valori
posibile sunt:
o block permite navigarea cu mouse-ul doar n interiorul item-urilor ce
aparin blocului curent;
o record utilizatorul se poate deplasa cu mouse-ul numai n item-urile din
nregistrarea curent;
o item previne navigarea cu mouse-ul n afara item-ului curent (valoarea
este aplicat n cazul n care se vrea interzicerea folosirii mouse-ului n
forma curent).
First Navigation Data Block specific numele blocului cu care Forms
Developer-ul ncepe navigarea la ncrcarea formularului sau dup o operaie
CLEAR_FORM (de aducere la valoarea implicit a tuturor obiectelor din
form).
Capitolul Database definete modul de interaciune a modulului cu baza de date,
prin definirea proprietilor:
Validation Unit determin domeniul de validare al formularului n runtime;
pentru cele mai multe din aplicaii, valoarea default este setat la item,
semnificnd faptul c validarea datelor introduse de utilizator se face la nivel
de item, adic odat cu ncercarea de prsire a respectivului obiect;
Interaction Mode determin modul de interaciune a utilizatorului cu
formularul, n cazul modului Enter-Query; implicit, aceast proprietate este
setat la Blocking, ceea ce previne orice posibilitate de interaciune a
utilizatorului cu formularul atta timp ct nu au fost ncrcate toate
nregistrrile din baza de date. Dac valoarea este setat la Non-blocking,
end-user-ul poate interaciona cu forma n timpul n care nregistrrile sunt
ncrcate. Aceast valoare este folosit n special cnd se emit cereri
consumatoare de timp i se vrea ca utilizatorul s poat ntrerupe executarea
cererii.

Maximum Query Time permite specificarea timpului dup care orice cerere
va fi ntrerupt, dac execuia ei nu a fost terminat. Valoarea implicit este 0
care semnific, de fapt, faptul c cererea nu va fi ntrerupt automat (vom
vedea c n Oracle Forms Developer valoarea 0 are, n multe din cazuri, alt
semnificaie fa de cea atribuit ei de matematicieni cu mai bine de dou
milenii n urm). Orice valoare nenul este luat n considerare doar dac
proprietile Query Allowed i Query All Records sunt setate la Yes (avei
rbdare, despre ele vei afla ceva mai tarziu!).
Maximum Records Fetched specific numrul de nregistrri ce vor fi
ncrcate n formular nainte de abandonarea execuiei cererii. Comentariile
referitoare la valoarea implicit 0 sunt valabile i n acest caz.
Isolation Mode permite definirea modului de rezolvare a concurenei
tranzaciilor; proprietatea se seteaz pe Serializable n cazul n care civa
utilizatori lanseaz un numr mic de tranzacii pe o baz de date de
dimensiuni mari, deci atunci cnd ansa ca dou tranzacii concurente s
ncerce modificarea aceleiai nregistrri este mic. Dac acest lucru se
ntmpl, unul din user-i va primi eroarea cu mesajul Cannot serialize
access. n cazul n care se lanseaz tranzacii intensive, este recomandat
lsarea acestei proprieti la valoarea implicit, Read Commited.
Capitolul Physical conine informaii referitoare la atributele fizice ale obiectelor
modulului:
Coordinate System permite definirea unitii de msur folosite pentru
stabilirea dimensiunii de afiare i a poziiei obiectelor. Aceast unitate de
msur se poate exprima n:
o caractere, mrimea unui caracter fiind dat de setul implicit de caractere
sau putnd fi specificat de programator;
o uniti de msur reale, avnd posibilitatea de a alege ntre: pixeli,
centimetri, puncte etc..
Use 3D Controls proprietate valabil doar pe sistemele ce ruleaz Microsoft
Windows i a crei setare la valoarea Yes permite afiarea item-urilor cu
efecte tri-dimensionale;
Form Horizontal Toolbar Canvas permite specificarea (prin numele su),
pentru Microsoft Windows, a unui canvas de tip horizontal toolbar care s fie
afiat ca bar orizontal de meniu;
Form Vertical Toolbar Canvas proprietate echivalent cu cea precedent,
folosit pentru cazul meniurilor verticale.

47
Capitolul International conine proprietatea Direction, a crei valoare ar trebui
lsat neschimbat deoarece end-user-ul nu va fi ncntat, probabil, de posibilitatea
scrierii de la dreapta la stnga.
Am trecut, n descrierea capitolelor de proprieti ale unui modul, peste capitolul
Records, care conine o singur intrare, Current Record Visual Attribute Group. Aceast
proprietate este specific att modulelor, ct i blocurilor de date i item-urilor i permite
specificarea unui atribut vizual pentru obiectul cruia i este aplicat.
2.4.7. 2.4.7. Atribute vizuale Atribute vizuale
Un atribut vizual este un obiect pe care l crem n Object Navigator (selectnd
nodul Visual Attributes i dnd click pe butonul New) i care are proprieti ce definesc:
setul de caractere, culoarea i modul de haurare. Un atribut vizual aplicat unui obiect va
determin motenirea de ctre obiect doar a acelor proprieti care sunt setate n atributul
vizual, restul rmnnd neschimbate.

Observai n fereastra Object Navigator crearea, la nodul Visual Attributes, a
obiectului numit ATR_MEU_VIZ. Invocarea paletei de proprieti a acestui obiect are
efectul prezentat n fereastra din dreapta. Numele proprietilor legate de font i culoare
sunt sugestive i pot fi setate cu usurin. Proprietatea Visual Attribute Type stabilete
domeniul de aplicare al atributului: common, prompt sau title.
2.4.8. 2.4.8. Proprietile ferestrelor Proprietile ferestrelor
Scopul crerii unui obiect este folosirea (i refolosirea) lui, aa c vom utiliza
atributul vizual creat anterior pentru setarea proprietilor ferestrei n care este ncrcat
modulul. Apare urmtoarea ntrebare: pentru ce ne trebuie un atribut vizual, prin care se
definesc proprieti cum ar fi culoarea fundalului i a setului de caractere, cnd pot face
acest lucru direct, la nivelul capitolului Color al paletei de proprieti a ferestrei? Unul
din avantajele (re)utilizarii unui obiect este acela c orice modificare a unei proprieti a
obiectului se va moteni automat de toate instanele respectivului obiect.
n paleta de proprieti a ferestrei:

49
modificm proprietatea Visual Attribute Group, selectnd atributul vizual creat anterior
din lista pop-up corespunztoare. Remarcm modificarea imediat a valorilor
proprietilor legate de culoare i font ale ferestrei conform celor motenite de la atributul
vizual i faptul c proprietile motenite sunt marcate cu o sageat. S presupunem c
dorim ca fontul cu care apare textul n item-uri s fie altul dect cel definit n atributul
vizual i motenit, implicit, de ctre fereastr. Modificnd valoarea fontului observm c
sgeii care prefixeaz proprietatea respectiv i este adugat un x rou,
semnificnd faptul c, iniial, proprietatea a fost motenit, dar am renunat la motenire
i am suprascris-o. Acionarea n aceast situaie a butonului Inherit va
determina aducerea valorii la cea motenit de la obiectul atribut vizual ATR_MEU_VIZ.
Dou capitole importante n paleta de proprieti a ferestrei merit detaliate:
Funcional i Physical. Capitolul Physical permite specificarea locului n care va aprea
obiectul (n cazul nostru, fereastra) pe ecran, prin stabilirea coordonatelor colului din
stnga-sus (proprietile X Position i Y Position) i a dimensiunilor sale (proprietile
Width i Height). Proprietatea Bevel seteaz tipul chenarului obiectului, iar ultimele dou
proprieti comut ntre afisrea/inhibarea barelor de scroll verticale i orizontale pentru
obiectul respectiv.
Capitolul Funcional permite definirea modului de funcionare a ferestrei, setnd
proprieti cum ar fi: Close Allowed (este sau nu permis comanda Close window), Move
Allowed, Resize Allowed etc. Stilul ferestrei este definit de proprietatea Window Style,
care poate fi setat la una din valorile Document sau Dialog. Proprietatea Modal
stabilete tipul ferestrei. O fereastr de tip modal nu poate fi prsit liber (dnd click n
afara ei), ci numai programatic. Implicit, o fereastr Modalless, adic nerestricionat,
este o fereastr pe care utilizatorul o poate prsi liber. Ferestrele de acest tip nu sunt n
mod necesar active atunci cnd sunt afiate.
2.4.9. 2.4.9. Proprietile unui bloc de date Proprietile unui bloc de date
ntorcndu-ne la aplicaia pe care vrem s o crem (nu am avansat extraordinar de
mult, aa e?), haidei s ne reamintim c ne aflm la etapa n care creasem, folosind dou
utilitare (DataBlock Wizard i Layout Wizard), un modul prin care vrem s gestionm
clienii firmei. Am creat un atribut vizual pe care l-am aplicat ferestrei n care va aprea
modulul, iar rezultatul este urmtorul:


Modulul conine un singur bloc de date, numit BL_CLIENTI. Acesta are 3 item-
uri (elemente), corespunztoare celor 3 cmpuri din tabela clienti. Utilizatorul poate
modifica interfaa i comportamentul unui bloc setndu-i proprietile.
S analizm paleta de proprieti a blocului de date (pentru accesarea acesteia
folosim una din metodele prezentate ntr-un capitol anterior, de exemplu: ne poziionm
pe blocul de date n Object Navigator i apsm tasta F4). Primul grup de proprieti este
General, cu intrrile deja cunoscute. Urmeaz grupul Navigation, care gestioneaz modul
de navigare cu tastatura n interiorul blocului. Implicit, pentru efectuarea unui salt circular
ntre item-urile din modul se folosete tasta Tab pentru navigarea nainte i combinaia
Shift+Tab pentru navigare inapoi. Proprietile ce se pot seta din grupul Navigation sunt:

51

Navigation Style implicit, la navigarea din ultimul item al blocului,
Forms returneaz focusul pe primul item din bloc. Acest mod de lucru
corespunde valorii Same Record al acestei proprieti; alte valori posibile
(ce se pot selecta din meniul pop-up ce apare la click pe aceast
proprietate) sunt:
Change Record caz n care cursorul se mut pe primul item al
urmtoarei nregistrri la prsirea ultimului item din
nregistrarea curent
Change Data Block aceast valoare determin saltul la blocul
urmtor odat cu prsirea ultimului item din nregistrarea
curent
Previous (Next) Navigation Data Block valoare setat implicit la Null,
semnificnd faptul c blocul anterior (respectiv urmtor) blocului curent
este cel ce se afl n Object Navigator naintea blocului curent, respectiv
dup acesta. Aici este permis definirea unui alt bloc la care se va face

saltul cursorului n cazul unei navigri cu tastatura spre blocul anterior
(urmtor).
Urmtorul grup de proprieti al unui bloc de date poart numele Records i arat
cam aa:

Grupul Records controleaz modul n care nregistrrile din tabel sunt ncrcate
de Forms n modul i conine urmtoarele proprieti:
Current Records Visual Attribute Group permite specificarea unui atribut
vizual care va fi folosit ca masc pentru afiarea nregistrrilor
Query Array Size specific numrul maxim de nregistrri pe care Forms-ul
le ncarc la o accesare a bazei de date. O valoare mic a acestei proprieti
va implica un timp de rspuns per accesare a bazei de date mic; o valoare
mare implic un numr mai mic de accesri a bazei date i, prin urmare, un
trafic n reea redus i un timp total de procesare mai mic. Valoarea implicit

53
a acestei proprieti este 0, semnificnd faptul c la o accesare a bazei de date
numrul de nregistrri ncrcate n form este egal cu valoarea proprietii
Number of Records Displayed
Number of Records Buffered este o proprietate ce se folosete pentru a mri
viteza de lucru. Buffer-ul este o zon de memorie n care Forms Builder-ul i
aduce nregistrrile care sunt n ateptare. Valorea implicit 0 nseamn, de
fapt, numrul de nregistrri afiate (setat prin proprietatea Number of
Records Displayed) plus 3. nregistrrile adiionale sunt salvate de Forms pe
hard-disk, ntr-un fiier temporar. O valoare mare a acestei proprieti
mbuntete viteza de lucru, dar folosete mai mult spaiu de stocare.
Number of Records Displayed aceast proprietate seteaz numrul de
nregistrri pe care un bloc le afieaz n canvas la un moment dat. Setai
aceast proprietate la o valoare mai mare, apoi rulai forma i observai
rezultatul! (Asigurai-v de faptul c n canvas este loc suficient pentru
afiarea simultan a mai multor nregistrri. n caz contrar, poziionai-v pe
un obiect din Object Navigator i apsai tasta F2 pentru accesarea
instrumentului Layout Editor (aceasta este doar una din multiplele posibiliti
n care acesta poate fi invocat); redimensionai frame-ul, eventual i canvas-
ul, astfel nct s poat fi vizualizate toate nregistrrile.
Query All Records dac aceast proprietate este setat la valoarea Yes vor fi
aduse n form toate nregistrrile odat. Implicit, aceasta valoare este setat
la No pentru mbuntirea performanelor de lucru, dar este esenial
modificarea ei la valoarea Yes n cazul cnd n form se fac calcule statistice
(de exemplu: sume, medii etc.) Este logic faptul c, pentru un calcul corect,
trebuie luate n considerare toate valorile din baza de date, deci acestea
trebuie aduse n form de la prima accesare a ei.
Record Orientation determin orientarea nregistrrilor n bloc (vertical sau
orizontal)
Single Record se seteaz la Yes n cazul unui bloc de control care conine
un cmp de tip item calculat conform unei formule statistice i specific
faptul c acest bloc trebuie sa conin, la un moment dat, numai o
nregistrare.
Urmtorul grup din paleta de proprieti al unui bloc determin modul de
interaciune dintre elementele blocului i tabelul pe baza cruia este construit acesta. Sub
denumirea Database gsim urmtoarele proprieti:


Database Data Block valoarea Yes nseamn c blocul va fi populat cu
informaie din baza de date (exist i blocuri populate prin proceduri
PL/SQL)
Enforce Primary Key precizeaz dac Forms-ul va verifica sau nu
constrngerea de cheie primar de la nivelul tabelei nainte de inserarea
sau modificarea nregistrrilor n baza de date
Query Allowed sunt sau nu permise interogri pe acest bloc
urmtoarele proprieti permit specificarea tabelei i a cmpurilor pe baza
crora este construit blocul curent. Exist, de asemenea, proprieti care
controleaz aciunile care se pot efectua de ctre utilizator asupra
nregistrrilor din blocul de date: Query/Insert/Update/Delete Allowed.
Where Clause dac vrem s impunem un filtru la nivelul blocului de
date, aici este locul lui; orice cerere restricionat efectuat asupra
blocului de date va fi automat conjuncionat cu condiia impus la

55
clauza where. De exemplu, condiia cod_firma>505 va avea ca efect
ncrcarea tuturor nregistrrilor care verific att condiia impus de
utilizator, ct i condiia: codul firmei mai mare dect 505.
Order by Clause determin un mod implicit de afiare a nregistrrilor,
sortate dup item-ul precizat aici. Aceast ordine poate fi stabilit i n
runtime, folosind caseta Query Where, procedur care a fost discutat
anterior n acest capitol.
Locking Mode precizeaz modul de blocaj al unei nregistrri. Implicit,
valoarea este setat la Automatic, care n cazul bazelor de date Oracle
este echivalent cu Immediate, iar n cazul altor baze de date ncearc un
comportament ct mai apropiat: atunci cnd utilizatorul iniiaz editarea
unui item, nregistrarea corespunztoare din tabel este blocat i nimeni
nu o poate modifica (din Forms sau din alt orice alt mediu, de exemplu
SQL), ci o poate doar accesa. La salvarea datelor din formular (i
efectuarea unui commit asupra bazei de date), nregistrarea este
deblocat. Modul de lucru Delayed realizeaz blocarea nregistrarii doar
n timpul operaiei de salvare.
Update Changed Columns Only cnd proprietatea este setat la Yes
doar acele item-uri modificate de utilizator vor fi salvate n coloanele din
baza de date corespunztoare lor.
Enforce Column Security cnd aceast proprietate are valoarea Yes,
elementele blocului de date pot fi modificate doar dac utilizatorul curent
are acest drept asupra coloanelor din tabela crora le corespund
elementele respective
Maximum Query Time ofer posibilitatea precizrii unui interval de
timp la expirarea cruia o cerere nesoluionat de ctre sistem este
abandonat; este util atunci cnd proprietatea Query All Records este
setat la valoarea Yes
Maximum Records Fetched permite precizarea unui numr maxim de
nregistrri ce vor fi aduse n form; dup aducerea acestui numr de
nregistrri, execuia cererii este abandonata.
Capitolul Scrollbar conine proprieti legate de apariia i funcionalitatea unei
bare de derulare la nivelul blocului de date. n cazul cnd este afiat o singur
nregistrare din blocul de date nu i are sensul crearea unei bare de derulare, aa c vom
studia ulterior, n detaliu, modul de definire al unui asemenea obiect. Totui, s
menionm proprietile unei bare de derulare:


Prima dintre acestea, Show Scroll Bar, determin/inhib apariia barei de
derulare. n cazul setrii acestei proprieti la valoarea Yes, elementele ce urmeaz n
paleta de proprieti permit definirea canvas-ului n care bara va aprea, a orientrii sale
(Vertical/Horizontal), precum i a poziiei (colul din stnga-sus al barei vezi sgeata 1
din figura urmatoare) i a dimensiunilor ei (limea barei de derulare, indicat de sageata
2 i lungimea sgeata 3 din figura de mai jos):

57

1
3
2
Renunm deocamdat la afiarea unei bare de derulare (setnd proprietatea Show
Scroll Bar a blocului de date la valoarea No) i analizm urmtoarele elemente din paleta
sa de proprieti. Acestea sunt legate de eventualele atribute vizuale folosite pentru
afiarea sa (ce se seteaz n capitolul Visual Attributes), precum i de precizarea irului
de caractere, a culorii i a modului de haurare a spaiului pe care se afieaz elementele
blocului de date (capitolul Color). De fapt, stabilirea unor valori pentru proprietile
legate de culoare/haurare la nivel de bloc nu are nici un efect, ele aplicndu-se doar n
cazul: item-urilor, paginilor tab, canvas-urilor, ferestrelor i butoanelor radio.
Sintetiznd ceea ce facem de cteva pagini bune ncoace (atributul bune se refer,
evident, la numr i nu la calitatea paginilor, ultima caracteristic fiind lsat la
latitudinea cititorului), concluzionm c am nvat s crem un formular simplu, pe care
apoi l putem rafina folosind paletele de proprieti ale obiectelor pe care le conine.
Transferul de informaie dintre formular i baza de date se efectueaz prin intermediul
meniului implicit.


2.5. 2.5. Blocuri master-detail master-detail Blocuri
Formularul creat de noi gestioneaz datele referitoare la clienii firmei (inserare
de noi clieni, modificarea informaiei legate de cei existeni, tergerea celor care ne-au
suprat, precum i interogarea tabelei clienilor). Ar fi mult mai plcut dac afiarea
datelor clientului x ar fi nsoit de afiarea, n acelai formular, a facturilor clientului
respectiv. Acest lucru este posibil datorit existenei, la nivelul bazei de date, a unei relaii
one-to-many (unu-la-mai-multe) ntre cele dou tabele pe care se bazeaz blocurile de
date, fapt ce se implementeaz n Forms Developer prin crearea unui formular de tip
master-detail. ntr-un astfel de formular va exista o sincronizare ntre nregistrrile din
blocul detail i cele din blocul master.
Un formular poate, deci, conine unul sau mai multe blocuri de date. Fiecare bloc
de date poate gestiona o singur tabel. Blocurile de date pot fi independente sau corelate
printr-o relaie de tip master-detail; efectul unei astfel de relaii const n sincronizarea
datelor ntre blocul de date master, care este bazat pe tabela care conine cheia primar i
cel detail, ce se bazeaz pe tabela care conine cheia extern. Pot fi create relaii
complexe, n care blocul detail al uneia este master pentru o alta, sau n care un bloc
master are mai multe blocuri detail. De asemenea, se pot defini formulare de tip master-
detail fr ca ntre tabelele pe care se bazeaz blocurile de date s fie explicit definit o
relaie unu-la-mai-muli, caz mai rar ntlnit ns.
S revenim la exemplul nostru, n care, pn acum, am construit un formular
pentru gestionarea clienilor firmei noastre. Unicul bloc de date definit, BL_CLIENTI,
este bazat pe tabela clienti. Vom construi nc un bloc de date, care va gestiona
nregistrrile din tabela facturi. Procedeul de construire, cu ajutorul instrumentului Data
Block Wizard, este deja cunoscut. La un moment dat, ns, s observm c apar elemente
specifice unei aplicaii master-detail; ne poziionm, deci, pe blocul BL_CLIENTI,
apsm butonul New, reprezentat, n partea din stnga a ferestrei Object Navigator, prin
icon-ul : . Primii pai ai wizard-ului sunt cei prezentai la crearea blocului anterior.
Definim blocul ca fiind bazat pe tabela facturi, selectm toate coloanele pentru a fi aduse
din tabel n aplicaia Forms, iar la pasul urmtor este sesizat existena unui alt bloc n
formular i suntem chestionai n legtur cu crearea unei relaii ntre cele dou blocuri. n
pagina Master-detail care apare se selecteaz butonul Create Relationship, iar din lista
de valori care apare se alege blocul BL_CLIENTI. Astfel, dac la nivelul celor dou tabele
este definit o cheie extern, atunci instrumentul Data Block Wizard va genera automat o
condiie de join ntre cele dou blocuri; n caz contrar, va trebui s o definim explicit,
alegnd din cele dou liste de valori Detail Item i Master Item elementele dup care se
va face corelarea ntre blocurile de date:

59

Urmtoarele pagini sunt cele cunoscute. S continum, apelnd Layout Wizard.
Vom proceda la afiarea tuturor elementelor blocului asupra cruia lucrm (numit de noi
FACT_CLIENTI), cu excepia item-ului cod_firma. Acesta va fi afiat n blocul
BL_CLIENTI i, datorit faptului c cele doua blocuri vor fi corelate, afiarea acestui item
va produce informaie redundanta. S alegem, de data aceasta, modul tabular de afiare
(n care nregistrrile vor fi prezentate sub form de tabel), precum i afiarea simultan a
4 instane din blocul detail la un moment dat:


Rezultatul procesului de creare a acestui al doilea bloc este prezentat n figura
urmtoare:

61

Corelarea ntre blocul master i cel detail este realizat de un obiect nou, de tip
Relations, aparinnd nodului blocului de date master. Implicit, numele relaiei se
formeaz dup urmtoarea regul: NumeBlocMaster_NumeBlocDetail. Sunt generate
automat uniti de program (trigger-i) care menin coordonarea ntre cele dou blocuri.
Privii figura de mai sus i vei remarca imediat acesti trigger-i, la creare sunt automat
selectai n Object Navigator.
Exist cazuri (de exemplu cel amintit anterior) n care ntre cele dou tabele nu
este definit o relaie one-to-many. Dac vrem, totui, o coordonare ntre blocurile de
date, trebuie s crem obiectul Relations manual. Dnd dublu click pe capitolul Relations
al blocului de date master, obinem urmtoarea fereastr:


n care specificm blocul de date detail, conditia de join, precum i modul n care va lucra
corelarea dintre cele dou blocuri. Atenie: definii condiia de join folosind sintaxa SQL
de definire a unei astfel de condiii, dar utilizai numele blocurilor n locul numelor
tabelelor, precum i numele item-urilor n locul coloanelor tabelelor.
Acum sincronizarea dintre cele dou blocuri se efectueaz automat la schimbarea
focus-ului n cadrul blocului master, n dou etape: se golete blocul detail, apoi se
repopuleaz conform frazei select-SQL definit de condiia de join. Mecanismul de
repopulare are la baz folosirea proprietii Copy Value from Item din paleta de
proprieti a elementului cod_firma din blocului detail. Astfel, cnd se actualizeaz blocul
detail (n urma apariiei unui eveniment care necesit sincronizare), item-ul care are rol de
cheie extern din blocul detail ia valoarea item-ului cheie primar din blocul master i
sunt afiate numai nregistrrile care verific aceast condiie:

63

Modul n care se efectueaz tergerile i coordonarea dintre cele dou blocuri se
poate seta din fereastra n care am definit relaia de join sau poate fi modificat ulterior,
folosind paleta de proprieti a relaiei:


Una din cele mai importante proprieti este Delete Record Behaviour, care
determin modul n care se fac tergerile n blocul master. Implicit, valoarea acestei
proprieti este setat la Non Isolated, nepermind tergerea unei nregistrri din blocul
master atta timp ct exist detalii care se refer la ea. Dac nu renunai la ideea tergerii
nregistrrii master, ar trebui terse, nti, nregistrrile corespondente ei din blocul de
detalii, sau putei seta proprietatea despre care tot discutm la valoarea cascading, fapt
ce va determina tergerea automat a nregistrrilor detail corespunztoare nregistrrii
master pe care ncercm s o tergem. O alt variant este selectarea valorii Isolated
pentru proprietatea Delete Record Behaviour, fapt ce permite tergerea nregistrrii
master, chiar dac exist nregistrri detail care se refera la ea.
Cu siguran ai observat deja faptul c modificarea modului de tergere a
nregistrrilor din formular a produs schimbri ale trigger-ilor generai de relaia dintre
cele dou blocuri: s ne reamintim c, n cazul modului de tergere implicit, Non Isolated,
trigger-ii (sau, pe romanete, declanatorii) care au aprut automat au fost:

65

on-clear-details (definit la nivel de modul),
on-populate-details,
on-check-delete-master (definit la nivelul blocului master).
Un declanator este un fragment de cod care se execut la declanarea unui
eveniment. S ncercm mpreun s ntelegem ce este cu aceti trigger-i: primul dintre
ei, on-clear-details, se declaneaz cnd are loc un eveniment de coordonare ntre dou
blocuri. Dac vei da dublu-click n Object Navigator pe icon-ul ataat acestui
declanator, vei vedea codul surs, n PL/SQL. Poate deocamdat pare mai complicat,
dar sperm ca, treptat, s lmurim lucrurile. La declanarea lui, acest trigger va goli
blocul detail, urmnd ca repopularea s fie efectuat de ali trigger-i, definii la nivel de
bloc master. Acolo vedem declanatorul on-populate-details, generat implicit de Forms la
crearea relaiei ntre cele dou blocuri. Acest trigger se ocup de popularea blocului
detail cu nregistrri corelate cu nregistrarea curent din blocul master, conform
strategiei definite de Forms. Putem schimba, ns, modul de populare a blocului detail,
modificnd codul PL/SQL al acestui trigger. Atenie, acest trigger nu se va declana n

absena unui trigger de tip on-clear-details. Ultimul dintre trigger-i, on-check-delete-
master, se declaneaz la ncercarea de tergere a unei nregistrri dintr-un bloc master
aparinnd unei relaii master-detail. S privim mpreun codul acestui trigger:

--
-- Begin default relation declare section
--
DECLARE
Dummy_Def i ne CHAR( 1) ;
- -
- - Begi n FACT_CLI ENTI det ai l decl ar e sect i on
- -
CURSOR FACT_CLI ENTI _cur s I S
SELECT 1 FROM FACTURI F
WHERE F. COD_FI RMA = : BL_CLI ENTI . COD_FI RMA;
- -
- - End FACT_CLI ENTI det ai l decl ar e sect i on
- -
- -
- - End def aul t r el at i on decl ar e sect i on
- -
- -
- - Begi n def aul t r el at i on pr ogr amsect i on
- -
BEGI N
- -
- - Begi n FACT_CLI ENTI det ai l pr ogr amsect i on
- -
OPEN FACT_CLI ENTI _cur s;
FETCH FACT_CLI ENTI _cur s I NTO Dummy_Def i ne;
I F ( FACT_CLI ENTI _cur s%f ound ) THEN
Message( ' Cannot del et e mast er r ecor d when mat chi ng
det ai l r ecor ds exi st . ' ) ;
CLOSE FACT_CLI ENTI _cur s;
RAI SE For m_Trigger_Fai l ur e;
END I F;
CLOSE FACT_CLI ENTI _cur s;
- -
- - End FACT_CLI ENTI det ai l pr ogr amsect i on
- -
END;
- -
- - End def aul t r el at i on pr ogr amsect i on
- -

67
Dup cte v amintii, un program PL/SQL are 3 seciuni: cea declarativ
(opional), corpul programului i o seciune de tratare a excepiilor (tot opional). n
cazul nostru, n prima parte este declarat un cursor. Acesta reprezint o zon de memorie
n care Oracle stocheaz nregistrrile returnate de o comand SQL. Orice instruciune
select genereaz un cursor, care este gestionat automat de sistem, ns utilizatorul poate
crea cursoare proprii, apoi poate prelucra, nregistrare cu nregistrare, coninutul
cursorului. Lucrul cu un cursor explicit implic urmtorii pai:
crearea cursorului, n seciunea de declaraii (adic specificarea comenzii SQL
care va popula cursorul); la acest moment cursorul este doar declarat, nu i
populat;
deschiderea cursorului (cu comanda open nume_cursor), fapt ce induce
popularea sa;
extragerea, nregistrare cu nregistrare, a coninutului cursorului n scopul
prelucrrii (cu comanda fetch nume_cursor into nume-variabla);
nchiderea cursorului (cu close nume_cursor).
Observai, n trigger-ul on-check-delete-master, definirea i deschiderea unui
cursor care conine toate codurile de facturi ale clientului al crui cod este valoarea item-
ului cod_client din blocul master BL_CLIENTI:
CURSOR FACT_CLI ENTI _cur s I S
SELECT 1 FROM FACTURI F
Deci, n cazul n care nregistrarea master are detalii corelate cu ea, instruciunea
FACT_CLIENTI_curs%found va ntoarce valoarea true, n bara de stare va fi afiat
mesajul
Message('Cannot delete master record when matching detail records exist.');
cursorul va fi nchis, iar instruciunea RAISE Form_Trigger_Failure va produce euarea
trigger-ului i ntreruperea aciunii curente (de tergere a nregistrrii master cnd are
nregistrri detail corelate). n cazul n care cursorul nu conine nregistrri, acesta este
nchis, trigger-ul se termin cu succes i tergerea este permis.
Acetia au fost, deci, trigger-ii creai automat n cazul unei relaii master-detail
cu condiie de tergere Non Isolated. S schimbm, n paleta de proprieti a relaiei,
aceast valoare cu Isolated. Observai dispariia trigger-ului on-clear-details, lucru care
era de ateptat deoarece acum tim c acest mod de lucru permite tergerea nregistrrilor
master chiar n cazul existenei unor nregistrri detail corelate cu aceasta.
Ultimul mod de tergere este Cascading. Reamintim c n acest caz, la tergerea
unei nregistrri master, vor fi terse automat nregistrrile detail corespunztoare
acesteia. Ce nseamn de fapt automat? Cine efectueaz aceast tergere? Binenteles

c trigger-ul pre-delete care a fost generat la nivel de bloc. Trigger-ii pre- se declaneaz
nainte de eveniment, n cazul nostru acesta se va declana nainte de ncercarea de a
terge o nregistrare master i va terge toate nregistrrile detail corelate cu aceasta.
Secvena de cod PL/SQL este, de aceasta dat, mult mai simpl (terge din tabela facturi
toate nregistrrile corespunztoare clientului al crui cod este n blocul BL_CLIENTI,
item-ul cod_firma):
- -
- - Begi n def aul t r el at i on pr ogr amsect i on
- -
BEGI N
- -
- - Begi n FACT_CLI ENTI det ai l pr ogr amsect i on
- -
DELETE FROM FACTURI F
- -
- - End FACT_CLI ENTI det ai l pr ogr amsect i on
- -
END;
- -
- - End def aul t r el at i on pr ogr amsect i on
- -
n urma execuiei acestui trigger nu vor mai exista n tabela nregistrri copil ale
nregistrrii ce se vrea tears din tabela printe i operaia se termin cu succes.
Cred c este timpul s v luai o clip de rgaz i s rulai aplicaia, ncercnd s
vedei cum funcioneaz n fiecare din cele trei cazuri.
Nu v bucurai, nu am terminat cu paleta de proprieti a relaiei! Mai sunt cteva
lucruri interesante, cum ar fi Prevent Masterless Operaion. Valoarea implicit este No,
nsemnnd c se poate face query pe blocul detail, indiferent dac blocul master este sau
nu populat cu vreo nregistrare. n cazul contrar, cnd valoarea acestei proprieti este
Yes, ncercarea de a efectua o cerere pe blocul detail eueaz, eroarea obinut fiind:
FRM-41105: You cannot query records without a saved parent record
Ultimul nod n paleta de proprieti a relaiei, Coordination, se refer la modul n
care se face coordonarea ntre blocuri. Proprietatea Deferred este setat implicit la No,
valoarea Yes determinnd popularea blocului detaliu doar atunci cnd focus-ul intr pe el.
Acest mod de lucru poart numele de populare cu ntrziere, iar ea poate fi de dou feluri:
n cazul cnd proprietatea Automatic Query are valoarea No, popularea se
numete a fi cu ntrziere, dar cu subcerere, pentru popularea blocului detail
fiind necesar nc o dat comanda Execute Query;

69
n cazul cnd proprietatea Automatic Query are valoarea Yes, popularea se
numete a fi cu ntrziere i cu cerere implicit, pentru popularea blocului
detail fiind necesar doar mutarea focus-ului pe acesta.
Primul mod de coordonare (populare cu ntrziere i cu subcerere) este folosit
atunci cnd se dorete obinerea nregistrrilor ce ndeplinesc un filtru cu o condiie
dubl, att din primul ct i din al doilea bloc. n acest caz se scrie condiia n primul
bloc, se acioneaz butonul Execute Query, se d click pe al doilea (nu va fi nc populat),
se introduce i a doua condiie, apoi se acioneaz din nou butonul Execute Query.
Am creat, deci, un formular de tip master-detail, i-am asigurat funcionalitatea
necesar, iar acum ar trebui s fim mulumii de rezultatele efortului nostru:

S reamintim c ntre cele dou blocuri corelarea se face automat (n cazul
interogrilor blocului master, blocul detail va fi populat automat; insernd o nregistrare
detail, ea va fi automat asociat cu nregistrarea afiat n blocul master), iar regula
implicit de tergere este urmtoarea: nu se poate terge o nregistrare master atta timp
ct ea are nregistrri detail corespondente (aceste moduri de lucru pot fi modificate, aa
cum am aratat anterior).
Remarcai afiarea simultan, n blocul detail, a 4 nregistrri. Acest fapt a fost
setat la crearea interfeei blocului de date (fcut, va amintii?, cu Layout Wizard) i se
regsete, bineneles, n paleta de proprieti a blocului de date, de unde poate fi i
modificat:

71
2.6. 2.6. Gestionarea elementelor text text Gestionarea elementelor
Un element de tip text este o interfa prin care putei interoga i actualiza datele.
n general, un obiect text corespunde unei coloane dintr-o tabel. La crearea unui element
nou, tipul su implicit este text. Proprietile elementului sunt, apoi, definite n paleta sa
de proprieti. Crearea unui element text nou se poate face n unul din mai multe moduri:
folosind utilitarele de tip wizard;
convertind un element deja existent ntr-unul de tip text (n paleta sa de
proprieti, la Item Type, alegem din lista de valori ataata intrarea text);
acionnd instrumentul Text Item din Layout Editor;
apsnd butonul Create icon din Object Navigator;
Pentru exemplificarea celei de a treia metode de creare a unui element text, s
invocm Layout Editor, s lrgim cadrul ce conine blocul de date FAC_CLIENTI, s
mutm bara de scroll spre dreapta, pentru a face loc unui element de tip text, apoi,
selectnd butonul pentru crearea unui astfel de obiect, s l poziionm pe locul n care
vrem s apar. Atenie, n partea superioar a acestui editor avem dou liste pop-up de
valori din care trebuie s selectm blocul de date i canvas-ul crora vrem s le aparin
elementul nou creat.


Ar fi foarte bine dac am reui s asociem elementului creat o etichet. Pentru
aceasta acionm butonul etichetat cu litera A din bara de instrumente aflat n partea
stng i crem un element nou, deasupra celui de tip text creat anterior.Dup ce adugm
textul dorit, selectarea simultan (innd tasta Ctrl apsat) a celor dou obiecte i
acionarea butonului Associate prompt (vezi figura anterioar) va determina asocierea
etichetei cu elementul text i tratarea lor unitar (orice ncercare de deplasare a unuia
dintre elemente va determina deplasarea celuilalt, tergerea se face n grup etc).
Remarcai faptul c, deoarece noul element text aparine blocului
FACT_CLIENTI, care afieaz simultan cte 4 nregistrri, acesta va avea afiate tot cte
4 instane ale sale. Noul item nu ne va fi, ns, de prea mare folos dac nu i setm
proprietile. Trebuie s specificm ce vrem s afieze noul element; este sau nu bazat pe
o coloan dintr-o tabel, se calculeaz dup vreo formula etc.
Haidei s facem un pas important (sperm c acesta va fi nainte) i s ncercm
s convingem acest element s ne arate, pentru fiecare factur, valoarea total a
Butonul
Associate
prompt

73
produselor pe care aceasta le conine. Pentru nceput s acionm tasta F4 invocnd,
astfel, paleta de proprieti a acestui item:

Dup ce, la intrarea Name, am numit acest element ntr-un mod mai uman
(total, de exemplu), i setm tipul ca fiind Number, lucru foarte important. Implicit,
acest element ar fi fost tratat ca fiind de tip ir de caractere. Capitolul Calculation este
locul n care vom defini modul de calcul pentru noul element. Nu vom folosi funciile
oferite la intrarea Summary Funcion (sunt cele disponibile i n SQL), ci vom seta
Calculation Mode la valoarea Formula, iar la intrarea Formula va trebui sa specificam o
expresie PL/SQL mai complex. Putem s trecem ca formul o expresie aritmetic ce are
ca operanzi item-urile din formularul curent (folosind sintaxa NumeBloc.NumeItem) sau,
dac avem nevoie de informaie care nu a fost nc ncrcat n formular (cazul nostru
trebuie s interogm tabela stoc), vom crea o funcie ce va ntoarce valoarea ce se dorete
a fi atribuit noului element. Funcia va fi creat cu ajutorul cunotintelor pe care le avem
(sau pe care ar trebui s le avem) relativ la limbajul PL/SQL. Putem crea aceast funcie
la nivelul bazei de date, caz n care poate fi reutilizat n orice mediu de programare

Oracle sau la nivel de modul, caz n care poate fi utilizat doar n modulul n care a fost
creat. Optm pentru a doua varianta i, n Object Navigator, selectam nodul Program
Units, apoi acionm butonul New. n caseta de dialog care apare selectm tipul
obiectului ce va fi creat la valoarea Function, iar numele: tot_fact. Click pe OK
determin invocarea editorului PL/SQL:

S ne reamintim c vrem ca aceast funcie s calculeze, pentru o factur dat,
suma produselor existente pe acea factur. Ca s funcioneze n caz mai general, codul
facturii ar trebui dat ca parametru al funciei. Ne reamintim c n specificaia unei funcii
PL/SQL trebuie s precizm tipul de dat returnat de funcie (n cazul nostru number). n
variabila rez calculm suma produselor dintre valoarea unitar a produselor de pe factur
i cantitate. Preul fiecrui produs se afl n tabela stoc, n timp ce cantitatea se afl n
tabela facturi, aa ca am facut un join ntre aceste tabele. Este returnat valoarea
variabilei rez:

75

Acionarea butonului din stnga-sus al editorului PL/SQL (etichetat Compile) va
determina compilarea funciei i, n cazul fericit, afiarea n dreapta jos a mesajului
Successfully Compiled. Dac exist erori, acestea vor fi afiate n partea de jos a ferestrei
editorului PL/SQL i vor trebui corectate.
Odat creat, funcia poate fi invocat oriunde n aplicaia curent. n paleta de
proprieti a item-ului total setm modul de calculare la valoarea Formula, iar valoarea pe
care o ia acest element va fi cea returnat de funcia tot_fact, calculat pentru parametrul
:cod_prod. S precizm doar faptul c un item poate s nu fie prefixat de numele blocului
din care face parte doar n cazul n care el este invocat n acelai bloc. Rezultatul este:


Dup ce vei rula aplicaia i v vei convinge c totalul de pe fiecare factur este
afiat corect, v propun s revenim la elementele de tip text, acestea fiind cele mai
frecvente n aplicaiile Forms, i s analizm, n continuare, proprietile lor.
Am creat un item de tip text folosind instrumentul Layout Editor. Precizam, cu
cteva pagini n urm, c acesta putea fi creat i din Object Navigator, dnd click pe
butonul New n timp ce este selectat un alt element text din acelai bloc cu cel ce se
dorete a fi creat. Un element text obinut n acest mod, nu va fi regsit n Layout Editor
i aceasta deoarece nu i se asociaz implicit nici un canvas n care s fie afiat. S
analizm paleta de proprieti a unui element text: capitolul General permite modificarea
numelui elementului i selectarea, din lista pop-up a proprietii Item Type, a tipului su.
Capitolul Functional permite modificarea funcionalitii implicite a elementului i
conine urmtoarele proprieti:
Enabled este corelata cu proprietatea Keyboard Navigable a capitolului
Navigation, astfel:
Enabled Keyboard
navigable
Comportament

77
Yes Yes Item-ul este inclus n navigare; poate fi
accesat i cu ajutorul mouse-ului
Yes No Item-ul nu poate fi accesat prin navigarea
implicit, cu tastatura; poate fi accesat doar
cu mouse-ul
No No Item-ul este practic exclus din procedeul de
navigare; nu poate fi manipulat nici cu
mouse-ul, nici cu tastatura
No Yes Item-ul nu este activ, el nu poate fi manipulat.
Valoarea celei de a doua proprieti este,
practic, tot No.
Justification permite specificarea modului de aliniere a valorii item-ului;
Multi-line este sau nu permis spaierea textului pe mai multe linii;
Wrap Style - modul n care se efectueaz trecerea la linie nou n cazul n care
textul depete suprafaa de editare;
Case Restriction textul este convertit la majuscule, litere mici sau este afiat
aa cum este introdus de utilizator;
Conceal Data este o proprietate specific doar item-urilor text pe un singur
rnd i este folosit pentru introducerea parolelor: la fiecare tast apsat de
utilizator, n cmpul respectiv este afiat caracterul *.
Keep Cursor Position cursorul nu se mic n timp ce utilizatorul tasteaz
valoarea cmpului;
Automatic Skip salt la item-ul urmtor cnd cel curent este completat pe
toat lungimea sa.
Capitolul Navigation stabilete modul de navigare spre i de la item la apsarea
tastei Tab, permind specificarea item-urilor anterior i urmtor celui curent, n cazul n
care acesta este Keyboard Navigable. Valoarea implicit No a acestor dou proprieti
determin navigarea n ordinea n care item-urile apar n Object Navigator.
Capitolul Data este utilizat pentru controlul modului n care datele sunt introduse
i afiate. Cel mai des folosite proprieti sunt:
Data Type specificarea tipului de valori pe care Forms Developer le permite
a fi introduse;
Maximum Length lungimea maxim a valorii introduse de utilizator;

Initial Value valoarea implicit pe care Forms Developer o asociaz
respectivului item de fiecare dat cnd e creat o nregistrare nou; poate fi, de
exemplu, o valoare fix, sau poate fi selectat dintr-o secven, folosindu-se
sintaxa :sequence.NumeSecventa.nextval; pentru o variabil de tip date pot fi
folosite data i ora sistemului de operare, n forma $$DATE$$,
$$DATETIME$$, $$TIME$$.
Required dac aceast proprietate este setat la valoarea Yes, nregistrarea
curent este considerat invalid n cazul cnd acest item are valoarea Null;
Format Mask pemite definirea unui prototip (conform standardelor SQL)
pentru introducerea datelor. Se pot defini prototipuri-utilizator, prin inserarea
caracterelor adiionale ntre ghilimele (de ex., pentru elementul total, care
afieaz valoarea total a unei facturi, un prototip ar putea arata aa:
999.999euro);
Lowest/Higher Value specific domeniul maxim de valori acceptate;
Copy Value from Item indic sursa valorii pe care Forms-ul o folosete
pentru a popula item-ul. Este util n cazul unei relaii master-detail, fapt
discutat ntr-un capitol anterior;
Synchronize with Item specific numele unui item (care poate fi ales dintr-o
list de valori coninnd item-urile din blocul curent) cu care item-ul curent se
va sincroniza. Orice modificare a valorii acelui item va produce actualizarea
celui curent.
ncercati s convingei aplicaia noastr s fac urmtoarele lucruri:
Lng numele cadrului al doilea s fie un item care s arate numele firmei ale
crei facturi sunt afiate;
Valoarea total a facturii s fie afiat conform capturii de ecran urmtoare;
La crearea unei nregistrri pentru o factur nou, cmpul data s fie
completat automat cu data sistemului:

79

Indicaii: observai c lng numele celui de al doilea cadru apare i denumirea
firmei care trebuie s se sincronizeze cu item-ul nume-firma din blocul BL_CLIENTI.
Creai, deci, n blocul master un element nou, de tip text. Poziionai-l ca n captura
anterioar de ecran i setai-i proprietatea Synchronize with Item la valoarea nume_firma.
Setai, pentru item-ul total, proprietatea Format Mask la 999.999euro, iar proprietatea
Initial Value a cmpului data la data sistemului, n forma $$DATE$$.
Capitolul Calculation a fost prezentat odat cu crearea item-ului numit total, aa
c trecem la capitolul Records. Una din cele mai importante proprieti se afl aici:
Number of Items Displayed. Valoarea implicit 0 nseamn, de fapt, c numrul de
instane afiate este acelai cu numrul de nregistrri afiate simultan, proprietate setat
la nivelul blocului de date (v mai amintiti? Se numea Number of Records Displayed.)
Modificarea acestei valori determin afiarea unui numr de instane corespunztor noii
valori.
Capitolul Database conine proprieti ce controleaz sursa informaiei din item-
ul curent (este bazat pe o tabel sau este item de control), precum i modul de comunicare
ntre acesta i tabel. La nodul Database gsim:

Database Item setai aceast proprietate la valoarea Yes dac elementul
curent ia informaia dintr-o tabel;
Column Name numele coloanei (din tabela pe care este construit blocul
curent) din care item-ul ia informaia;
Primary Key coloana pe care se bazeaz item-ul conine sau nu cheie
primar; n caz afirmativ, Forms Developer verific unicitatea valorii acordate
acestui item;
Query Only implicit are valoarea No; schimbarea ei la valoarea Yes permite
includerea item-ului numai n executarea de cereri, nu i n operaii insert sau
update;
Query/Insert/Update Allowed - controleaz ce operaii DML sunt permise;
Query Length specific lungimea maxim a unui ir ce poate fi stocat n
acest item n cazul efecturii unei cereri. Valoarea implicit 0 nseamn, de
fapt, lungimea maxim a cmpului, setat prin proprietatea Maximum Length,
de la capitolul Data;
Case Insensitive Query permite sau nu utilizatorului s efectueze pentru
item-ul respectiv cereri case-insensitive;
Update Only if Null setat la valoarea Yes, aceast proprietate nu permite
utilizatorului modificarea item-ului curent dect dac acesta are valoarea Null;
Lock Record blocheaz (sau nu) rndul din tabel corespunztor nregistrrii
curente n cazul cnd aceasta este modificat.
Urmtoarele dou capitole din paleta de proprieti a unui element text, List of
Values i Editor vor fi studiate n detaliu ulterior; acum ne oprim asupra proprietilor
grupate sub numele Physical, care se refer la poziia i dimensiunile item-ului. Gsim
aici:
Visible care setat la valoarea Yes produce afiarea elementului; n caz
contrar, elementul exist, poate fi folosit, de exemplu, pentru calculul unor
valori, dar nu va fi vizibil;
Canvas n ce canvas va fi afiat elementul;
Tab Page n cazul canvas-urilor de tip Tab permite specificarea paginii
canvas-ului pe care va fi afiat elementul;
X/Y Position permite specificarea coordonatelor colului din stnga-sus al
elementului relativ la acelai col al canvas-ului;
Width i Height - seteaz limea i nlimea item-ului curent;

81
Bevel permite setarea chenarului item-ului curent;
Rendered la ieirea focus-ului de pe element, acesta i va modifica sau nu
aspectul;
Show Vertical Scrollbar este evident la ce se refer, nu?
Urmatoarele grupe de proprieti, Visual Attributes, Color i Font contin
proprieti deja familiare noua, aa ca trecem la capitolul Prompt, care personalizeaza
apariia etichetei elementului text curent:
Prompt textul afiat ca etichet;
Prompt Display Style cum s fie afiat eticheta: doar o dat, lng prima
instan a elementului, cte o dat pentru fiecare instan sau s fie ascuns;
Prompt Justification modul de aliniere al textului;
Prompt Attachment Edge lng ce latur a elementului va fi afiat eticheta;
Prompt Alignment seteaz modul n care este aliniata eticheta de-a lungul
laturii stabilit prin proprietatea anterioar;
Prompt Attachment Offset distana dintre item i eticheta sa;
Capitolele Prompt Color i Prompt Font stabilesc culoarea fundalului pe care va
fi afiata eticheta, precum i caracteristicile font-ului folosit la afiarea acestuia.
Capitolul Help permite programatorului afiarea de mesaje ajuttoare, case-
sensitive, pentru utilizatorul final al aplicaiei. Textul care este atribuit proprietii Help
va fi afiat n bara de stare a aplicaiei, la rulare, n modul urmtor: dac proprietatea
Display Hint Automatically este lsat la valoarea implicita, No, mesajul ajuttor va fi
afiat doar cnd focus-ul se afl pe element i utilizatorul apas tasta F1. n cazul n care
aceast proprietate are valoarea Yes, mesajul va fi afiat la intrarea focus-ului pe
elementul curent. Proprietatea Tooltip permite definirea unui text care va fi afiat ntr-o
caset alturat elementului, cnd utilizatorul mic mouse-ul deasupra acestuia. Atributul
vizual folosit pentru afiarea tooltip-ului se seteaz la proprietatea Tooltip Visual
Attribute Group.
ncercai s setai grupul de proprieti Help pentru elementul cod_prod la
valorile urmtoare:


Vei obine, n runtime, urmtorul efect:

83
2.7. . Butoane (push buttons) push buttons 2.7 Butoane ( )
Un buton este o interfa grafic pe care utilizatorul d click pentru iniierea unei
aciuni. Acesta este, n general, reprezentat sub forma unui dreptunghi ce include o
etichet coninnd text i/sau imagine; nu poate reine sau afia valori (cu toate c eticheta
sa poate fi modificat programatic n timpul rulrii). n general, butoanele sunt adugate
formularelor pentru obinerea unei funcionaliti sporite i a unui mod rapid de acces la
cel mai des utilizate operaii.
Este recomandat poziionarea butoanelor n blocuri speciale, numite blocuri de
control. S crem, n aplicaia noastr, un bloc nou, pe care sa l denumim CONTROL.
Exist mai multe modaliti prin care se poate crea un buton:
1. convertind un element deja existent la unul de tip buton (n paleta de
proprieti setm Item Type la valoarea Push Button);
2. crend, n Object Navigator, un element nou, de tipul buton;
3. n Layout Editor acionm butonul din bara de instrumente, apoi prin
drag&drop, poziionm obiectul pe locul dorit, avnd grij s fie selectat
blocul de control:


Obiectului nou creat i modificm proprietile n modul deja cunoscut:

85

Setnd proprietatea Name, numim butonul but_ies (acesta va fi un buton la a
crui apsare se va nchide formularul), iar eticheta (Label) va fi setat la valoarea Iesire.
Proprietatea Iconic permite specificarea modului de afiare a butonului imagine sau
text? n primul caz, la intrarea Icon Filename precizm numele fiierului (fr extensie!)
care va fi folosit ca etichet pentru butonul curent. Putem s stabilim, cu ajutorul
proprietii Access Key o combinaie de taste (de exemplu Alt-J) la a crei apsare s fie
acionat butonul. Celelalte proprieti sunt cunoscute, ele fiind aceleai cu cele ale
elementelor text create ntr-un capitol precedent.
Dup crearea prii grafice a butonului, ar trebui sa i acordm funcionalitate.
Pentru aceasta avem la dispozitie triger-ii, secvene de cod care se declaneaz la anumite
evenimente. Efectund click dreapta pe buton, din meniul de context care apare alegem
intrarea smart triggers, reprezentnd cel mai des utilizai trigger-i pentru obiectul
respectiv. La click pe buton se va declana, dup cum ai bnuit deja, trigger-ul when-
button-pressed. l selectm:


i va fi invocat editorul PL/SQL, unde suntem invitai s scriem codul trigger-ului:

Am folosit procedura predefinit exit_form, care nchide formularul curent.
Rulm forma i testm butonul creat. S-ar putea s deranjeze faptul c, atunci cnd focus-
ul se afl pe un cmp care are proprietatea Data Required setat la valoarea Yes, nu putem
aciona butonul pn cnd nu completm cmpul curent. Acest context va fi neplcut

87
pentru utilizatorul care nu va nelege de ce trebuie s scrie n cmpul respectiv o valoare
arbitrar ca s poat nchide forma. Putem salva situaia printr-un truc: setm proprietatea
Mouse Navigate a butonului la valoarea No, acest lucru nensemnand c butonul nu poate
fi accesat cu mouse-ul, ci c focus-ul rmne pe cmpul anterior.

2.8. . Canvas-uri de tip suprapus (stacked canvas) Canvas 2.8 -uri de tip suprapus (stacked canvas)
Clarificasem, ntr-un capitol anterior, faptul c o fereastr este un container
pentru obiecte, iar canvas-ul este pnza pe care le aezm. Pentru a fi afiat n runtime, un
canvas trebuie s fie asociat unei ferestre. Exist 4 tipuri de canvas-uri. Pn acum am
folosit doar canvas-uri de tipul implicit, numit coninut (content canvas). Trebuie
respectate cteva reguli n lucrul cu canvas-uri de tip coninut:
acestea ocup toat suprafaa ferestrei;
este obligatoriu ca fiecare fereastr s conin cel puin un canvas, iar acesta
s fie de tip content;
nu pot fi afiate simultan mai multe canvas-uri coninut, comutarea ntre
acestea fcndu-se programatic (putem s aducem simultan dou canvas-uri
pe ecran doar dac le asignm la ferestre diferite).
Partea vizibil n runtime este determinat de proprietile Viewport X/Y Position
on Canvas (care determin coordonatele, relativ la canvas, ale colului stnga-sus al
suprafeei vizibile). La nodul Functional al paletei de proprieti a unui canvas gsim
proprietile Heigh i Width, care se refer, ns, la dimensiunile canvas-ului, nu la cele
ale viewport-ului.


Adiional canvas-urilor coninut, Forms Buider ofer alte 3 tipuri de asemenea
elemente, care au un comportament diferit, n sensul c pot fi afiate peste canvas-urile
content, n acelai timp cu acestea.
Stacked canvas (suprapus) se afieaz n aceeai fereastr cu un canvas de
tip coninut, peste acesta; dimensiunile lui sunt, n general, mai mici; ntr-o
fereastr pot fi definite mai multe canvas-uri suprapuse; este utilizat, n
general, pentru afiarea mesajelor de help, a informaiei aditionale, a antetelor
cu informaie static;
Toolbar canvas reprezint o alternativ pentru meniuri; pe un asemenea
canvas putem aeza mai multe butoane, fiecare cu o funcionalitate specific;
Tab canvas permite organizarea i afiarea informaiei pe pagini separate,
care se pot accesa prin click pe eticheta acestora; sunt afiate peste un canvas
de tip coninut.

89
Fiind narmai cu noiunile de baz referitoare la canvas-uri, s purcedem la
crearea unuia de tip stacked. Dorim ca, la acionarea unui buton, s fie afiat ntr-un mod
atractiv numele firmei (eventual o sigl, n cazul n care aceasta este disponibil):

Paii care trebuie urmai pentru crearea noului canvas sunt:
1. n Object Navigator efectum dublu-click pe icon-ul canvas-ului content n
care vrem sa crem canvas-ul suprapus;
2. Click pe butonul Stacked Canvas din bara de instrumente, pe care l
recunoatei dup eticheta sa:
3. Efectum click i drag cu mouse-ul n canvas-ul de tip content, acolo unde
vrem s poziionm canvas-ul suprapus. Atenie: la afiarea unui canvas nu
trebuie s opturm cu el cmpul curent (pe care se afl focus-ul). n caz
contrar, afiarea nu se face.

4. Invocm paleta de proprieti a noului element, pentru a-i seta
funcionalitatea:

n primul rnd, schimbm numele acordat implicit canvas-ului la valoarea
suprapus. Proprietile Viewport X/Y Position stabilesc coordonatele colului din stnga-
sus al canvas-ului relativ la acelai col al ferestrei n care acesta este afiat, n timp ce
proprietile Viewport Width/Heigh permit setarea dimensiunilor parii vizibile la rulare a
canvas-ului. Proprietatea Visible aflat la nodul Physical indic dac acest canvas este
afiat sau nu la rulare. Setm aceast proprietate la valoarea No, urmnd s afim acest
canvas programatic: crem, n blocul de control, dou butoane, unul pentru afiarea siglei
clientului, cellalt pentru ascunderea siglei. Funcionalitatea lor este dat de trigger-ii
when-button-pressed, n care vom folosi dou proceduri built-in (predefinite):
show_view(NumeCanvas) determin afiarea canvas-ului
hide_view(NumeCanvas) produce inhibarea afirii canvas-ului.
Ce afim n canvas? Hotrsem s afim, ntr-un mod mai spectaculos, numele
firmei. Avem n formular aceast informaie n blocul BL_CLIENTI, ns un item nu
poate fi folosit dect ntr-un singur canvas, aa c definim un nou bloc de date, pe care l
numim STACKED_CLIENTI i l asociem tabelei CLIENTI. Coninutul acestui canvas va
fi afiat n canvas-ul numit suprapus. Crem o relaie master-detail ntre blocul
BL_CLIENTI i noul bloc, astfel nct s existe sincronizare ntre item-urile nume_firma.
O mic problem apare: n cazul n care nici o nregistrare nu este adus n
formular, acionarea butonului etichetat sigla client va produce un canvas vid, a crui
afiare poate fi neplacut. Putem, atunci, rezolva aceasta problem n unul din dou
moduri: afim, n acest caz, un mesaj predefinit sau, pur i simplu, nvm butonul s

91
nu afieze canvas-ul, dac nu conine informaie. n primul din cele dou cazuri,
procedura PL/SQL arat aa:

Bineneles, butoanele (push buttons) nu reprezint singura modalitate de a
afia/ascunde un canvas de tip suprapus. Codul PL/SQL anterior poate fi convins s se
declaneze i n alte situaii, de exemplu, cnd focus-ul este transferat pe elementul
cod_firma. Dar pentru a obine un asemenea comportament va trebui sa nvm mai
multe despre tipologia trigger-ilor.
Putem, totui, s nlocuim cele dou butoane folosite pentru afiarea, respectiv
inhibarea siglei firmei cu unul singur, care s i schimbe eticheta n funcie de context.
Generaliznd afirmaia din capitolul anterior (conform creia un buton i poate schimba
programatic, n runtime, eticheta), precizm c orice element i poate schimba
programatic, n timpul rulrii, proprietile. Motorul PL/SQL din Forms are cteva
extensii legate de particularitile elementelor specifice formularelor. Astfel, pentru a
accesa proprietile acestora nu se folosete sintaxa clasic obiect.proprietate=valoare, ci
au fost create
funcia predefinit GET_TipObiect_PROPERTY (avnd doi parametri, numele
obiectului i proprietatea) i
procedura predefinit SET_TipObiect_PROPERTY (cu trei parametri: numele
obiectului, proprietatea, noua valoare).
Folosind aceste built-ins-uri, s crem n blocul CONTROL un nou buton (n
locul celor dou) pentru afiarea canvas-ului, avnd numele af i eticheta iniial afiare.
Trigger-ul when-button-pressed asociat lui va arta aa:


2.9. 2.9. Liste de valori (LOVs) Liste de valori (LOVs)
Listele de valori sunt obiecte ale modulului care i deschid propria fereastr la
apelarea n timpul rulrii aplicaiei. Ele ofer utilizatorului posibilitatea de a alege un item
dintr-o list cu mai multe coloane, list care poate fi definit static (are aceleai valori
indiferent de context) sau dinamic, creat pe baza unei instruciuni select. Obiectele LOV
sunt definite la nivel de modul, astfel nct pot fi utilizate oriunde n modulul curent.
Tipologia unei liste de valori implic existena a trei elemente:
1. un grup de nregistrri (record group) - un obiect Forms Buider folosit pentru
stocarea unei mulimi de valori; acesta poate fi static sau dinamic; poate fi
creat independent sau odat cu crearea LOV-ului; poate fi utilizat pentru
definirea uneia sau mai multor liste de valori, fiecare dintre acestea afind o
mulime specificat de coloane ale grupului;
2. LOV lista nsi, format din una sau mai multe coloane ale grupului de
valori pe care se bazeaz; permite utilizatorului selectarea unei valori din list,
care va fi automat asignat unui item;
3. Un element text beneficiarul listei de valori, cel cruia LOV-ul i returneaz
o valoare; un singur LOV poate returna valori mai multor item-uri simultan; un
LOV poate fi afiat automat, la intrarea focus-ului pe respectivul element sau
manual, la apsarea de ctre utilizator a combinaiei de taste Ctrl-L sau a
opiunii Edit Display List din meniul implicit Forms.

93
S exemplificm crearea i afiarea unei liste de valori statice asociate
elementului FACT_CLIENTI.IO. Valoarea pe care o poate lua cmpul IO din tabela
FACTURI este 1 sau 0, aa nct dorim ca la completarea item-ului corespunztor acestui
cmp, utilizatorul s aib posibilitatea de a alege, dintr-o list, una din cele dou valori.
Procedm nti la crearea unui grup de valori pe care se va baza LOV-ul. n Object
Navigator selectm nodul Record Groups i acionm butonul Create. Din caseta de
dialog care apare alegem opiunea Based on Static Values, dup care suntem invitai s
completm valorile ce vor aprea n grup. S crem dou coloane, una ce va conine
valorile 1 i 0, iar alta cu explicaii referitoare la cele dou valori:

S numim acest grup GRUP_IO i s trecem la crearea listei de valori dorite.
Procedm n acelai mod, selectnd n Object Navigator nodul LOVs i acionnd butonul
Create. Din caseta de dialog afiat s alegem crearea listei cu ajutorul unui instrument de
tip wizard , iar n prima fereastr ce apare s specificm faptul c noua list va fi creat pe
baza unui grup deja existent (cel creat anterior). Dorim ca, la invocarea LOV-ului, s fie
afiate utilizatorului ambele coloane ale grupului de nregistrri, deci n caseta urmtoare
selectm ambele elemente:


Pasul urmtor este foarte important; precizm cror elemente le vor fi asignate
coloanele LOV-ului:

95

Am acionat butonul Look up return item i din lista de valori ce a aprut
(cuprinznd toate elementele din modul) am selectat FACT_CLIENTI.IO, element cruia
vrem s i fie atribuit valoarea coloanei VAL_ADMISE selectate de utilizator. Cea de a
doua coloan a listei este doar informativ, aa c nu i asociem nici un element. n caseta
urmtoare dm un nume ferestrei n care este afiat lista de valori (de exemplu Tipul
facturii) i putem stabili poziia pe care aceasta va aprea pe ecran. Dnd click pe butonul
Next ajungem la pagina Advanced, unde putem s i permitem sau nu utilizatorului s
filtreze la afiare lista de valori creat. Pagina final selecteaz dintre item-urile care
primesc valori din list pe cele care, avnd focus-ul pe ele, pot afia (n modul specificat
anterior) LOV-ul. Observm n Object Navigator crearea unui obiect LOV nou, pe care s
l denumim LOV_IO. Analiznd paleta sa de proprieti, remarcm faptul c toate
elementele setate cu ajutorul instrumentului LOV Wizard se regsesc i pot fi modificate
aici.
Analiznd paleta de proprieti a elementului FACT_CLIENTI.IO observm c
sub nodul LOV a fost modificat automat proprietatea List of Values, fiindu-i atribuit
valoarea LOV_IO. Proprietatea Validate from List a fost lasat la valoarea implicit No,

permind astfel utilizatorului i inserarea de alte valori, n afara celor din LOV. Noi nu
dorim acest lucru, aa c l obligm pe utilizator s aleag una dintre cele dou valori
oferite de noi setnd aceast proprietate la valoarea Yes.
Rulnd aplicaia, observam c atunci cnd focus-ul se afl pe cmpul IO n bara
de stare este semnalat prezena unei LOV pentru acest element, iar la apsarea
combinaiei de taste Ctrl-L este afiat lista:

Dublu click pe nregistrarea dorit (sau click simplu urmat de acionarea
butonului OK) va atribui item-ului Io valoarea selectat din list. Curiozitatea v va face
s ncercai completarea elementului cu o alt valoare, diferit de 1 sau 0, caz n care
Forms Developer va afia lista de valori i nu va permite trecerea la alt item nainte de
completarea corect a celui curent.
Lista de valori poate fi determinat s apar automat, la intrarea focus-ului pe
cmpul Io, prin setarea proprietii Automatic Display aflate la nodul Functional al listei.
Am construit astfel un grup de nregistrri statice, pe baza cruia am creat un
LOV pe care l-am asignat unui element text. S exemplificm obinerea unui LOV
dinamic, creat pe baza unei comenzi select. Vom selecta, n Object Navigator, nodul
LOVs, apoi vom aciona butonul Create. Alegem i de aceast dat crearea listei cu

97
ajutorul utilitarului LOV Wizard, iar la pasul urmtor precizm c lista i va lua
nregistrrile dintr-un grup nou, bazat pe o cerere (selectm opiunea New Record Group
Based on a Query). Pasul urmtor al wizard-ului cere definirea instruciunii select care va
popula grupul. Putem invoca utilitarul Built SQL Query (acionnd butonul
corespunztor), iar n caseta ce apare selectm tabelele ce vor participa la instruciunea
select, precum i cmpurile ce vor fi utilizate. S presupunem c vrem mai mult dect
poate acest utilitar: dorim ca grupul de nregistrri s conin 3 coloane: pe prima s avem
codul firmei, pe a doua numele firmei, iar pe a treia suma valorilor tuturor facturilor
operate de firma respectiv (indiferent dac sunt de intrare sau iesire) astfel vom avea o
imagine a intensitii activitii firmei respective. Ceea ce permite utilitarul amintit
anterior este selectarea celor 4 tabele pentru includerea lor n cerere, depistarea corect a
relaiilor dintre ele i alegerea cmpurilor ce vor participa la rezultat:

Acionarea butonului OK va produce o cerere pe care o modificm manual,
conform cerinelor prezentate anterior (modificrile operate de noi sunt scrise cu litere
mici):


La paii urmtori includem toate cele trei coloane ale grupului n LOV i
returnm valorile primelor dou elemente BL_CLIENTI.COD_FIRMA, respectiv
BL_CLIENTI.NUME_FIRMA (folosind opiunea Look up Return Item). Pentru o afiare
elegant, este recomandat redimensionarea spaiului pe care sunt afiate coloanele
grupului. La pasul urmtor putem da un titlu ferestrei n care va fi afiat LOV-ul;
urmtoarea caset permite specificarea numrului maxim de nregistrri care va fi afiat
n fereastra LOV-ului i dac instruciunea select ce populeaz lista va fi executat la
fiecare afiare sau o singur dat, la prima sa afiare (proprietatea Refresh Record Group
Data Before Displaying LOV). Bifarea ultimei casete (Let the user filter records before
displaying them) permite utilizatorului introducerea unui filtru la afiarea listei de valori.
Click pe butonul Next ne conduce la pasul urmtor, unde specificm cror elemente le
asignm lista de valori (de pe ce item-uri poate fi aceasta invocat). S selectm aici doar
BL_CLIENTI.COD_FIRMA. Butonul Finish ncheie procesul de creare a listei de valori,
al crei nume l vom modifica din Object Navigator (s l numim, de exemplu,
LOV_CLIENTI). ncheind i aceast etap, rmne doar s rulm aplicaia i s admirm
rezultatele obinute.

99
2.10. 2.10. Alte tipuri de elemente ntr-un formular Alte tipuri de elemente ntr-un formular
n afara elementelor text, un formular poate conine i alte tipuri de elemente
utilizate pentru introducerea datelor de ctre utilizator. Cel mai des folosite sunt casetele
de validare (check boxes), grupurile de butoane radio (radio groups) i elementele list.
2.10.1. 2.10.1. Casete de validare Casete de validare
O caset de validare este un obiect-interfa ce poate avea una din dou stri:
bifat sau nebifat. Un astfel de obiect poate fi obinut prin convertirea unui obiect deja
existent sau prin crearea unuia nou, n Layout Editor, selectnd butonul corespunztor:
. S exemplificm crearea unui obiect caset de validare folosind prima metod.
Elementul FACT_CLIENTI.IO poate lua una din dou valori (1 sau 0) i se preteaz, deci
a fi transformat ntr-o caset de validare. Acionnd paleta sa de proprieti, o modificm
pe cea care definete tipul elementului, alegnd check box:

Unele dintre proprietile acestui nou obiect sunt comune cu cele ale unuia de tip
text. La nodul Functional se afl, totui, cteva proprieti specifice:
Value when Checked permite specificarea unei valori corespunztoare strii
bifat. Atunci cnd o valoare egal cu cea specificat aici este ncrcat din
tabel i atribuit casetei, aceasta va aprea bifat. Reciproc, atunci cnd
utilizatorul va bifa caseta, valoarea asignat acestei proprieti va fi transferat
coloanei pe care o mapeaz caseta.
Value when Unchecked este echivalentul proprietii anterioare pentru cazul
cnd caseta rmne nebifat.
Check Box Mapping of Other Values se folosete n cazul n care pot fi
ncrcate sau asignate casetei alte valori, n afara celor specificate prin cele
dou proprieti anterioare i permite definirea modului n care orice alt
valoare va fi procesat (Not Allowed, Checked sau Unchecked)
2.10.2. 2.10.2. Elemente list Elemente list
Un element list este un obiect care afieaz o mulime predefinit de elemente,
fiecare corespunznd unei valori specificate de programator. Exist trei tipuri de liste i n
nici unul dintre cele trei nu se pot face selectri multiple:
Poplist apare ca un cmp de tip text avnd ataat un buton reprezentat printr-
o sgeat. Acionarea butonului va determina expandarea listei, sub forma:

Plist apare ca un dreptunghi care afieaz elementele listei. Cnd suprafaa
de afiare nu este suficient, i va fi ataat automat o bar de derulare:

Combo Box apare ca un element text cu o sgeat n jos ataat, a crei
apsare determin afiarea elementelor listei. Spre deosebire de listele de tip
poplist, elementele combo box permit introducerea de ctre utilizator i a altor
valori, n afara celor din lista de valori predefinite: .

101
O proprietate important, comun tuturor tipurilor de liste, este Elements in List,
locul unde se definesc elementele listei i valorile corespunztoare acestor elemente.
Click pe aceast proprietate va afia o caset de editare a acestor valori:

n partea superioar a casetei
vor fi editate elementele listei (valorile
afiate n runtime), iar n partea
inferioar va fi definit, pentru fiecare
element al listei, o valoare asociat lui.
Celelalte proprieti ale listelor sunt
cunoscute din capitolele anterioare.

2.10.3. 2.10.3. Grupuri de butoane radio Grupuri de butoane radio
Un grup radio este un obiect format (din punct de vedere vizual) dintr-o mulime
de butoane radio, reprezentnd toate valorile posibile pe care le poate lua acest element.
Dintre acestea, unul i numai unul poate fi bifat (utilizatorului i se ofer posibilitatea unei
selectri unice din mulimea de valori permise). Acest tip de element reprezint o
alternativ la casetele de validare (n cazul cnd mulimea de valori permise are dou
elemente) sau la liste (n cazul cnd aceast mulime are mai puin de 4 elemente). Pentru
mulimi de valori cuprinznd mai mult de patru elemente, este recomandat folosirea
listelor, afiarea unor grupuri de butoane radio att de numeroase aglomernd inutil
suprafaa de afiare. Valoarea grupului de butoane radio poate fi sprecificat de utilizator
(n timpul rulrii aplicaiei), prin proprietatea Initial value sau programatic. Se pot
executa, de asemenea, interogri folosind acest tip de element.
Un grup de butoane radio poate fi creat n oricare din modurile deja cunoscute de
creare a elementelor Forms :
Convertind un element deja existent la tipul radio group;

Crend un element nou n Layout Editor, caz n care acionm, n bara de
instrumente, butonul corespunztor:
Utiliznd, n Object Navigator, icon-ul Create ; aceast
aciune va avea ca efect crearea unui element nou, de tipul (implicit) text, care
va fi transformat n grup radio prin setarea corespunztoare a proprietii Item
Type. Crend astfel grupul de butoane radio, acesta nu va fi afiat n Layout
Editor pn n momentul cnd vom seta proprietatea Canvas, specificnd
astfel canvas-ul n care elementul va aprea. Butoanele vor fi poziionate n
colul din stnga sus al formularului, pasul urmtor fiind repoziionarea lor .

103
2.11. 2.11. Declanatori (trigger-i) trigger Declanatori ( -i)
Declanatorii reprezint cea mai important modalitate de a aduga
funcionalitate unui formular sau de a-i redefini funcionalitatea implicit. Un declanator
are trei elemente definitorii:
Tipul definete evenimentul care va declana trigger-ul;
Codul definete aciunea efectuat de trigger (este scris n PL/SQL);
Domeniul definete nivelul la care sunt ascultate evenimentele de ctre
respectivul trigger.
Numele trigger-ilor este format din dou componente, separate prin cratim:
prefixul, care determina cnd (n raport cu evenimentul generator) se declaneaz trigger-
ul i evenimentul, care determin tipul de aciune ce va declana trigger-ul.
n funcie de prefix, trigger-ii se mpart n urmtoarele categorii:
When-eveniment procesrii asociate implicit evenimentului i sunt adugate
aciunile definite de trigger (de exemplu, When-validate-item se declaneaz
imediat ce Forms valideaz datele dintr-un cmp; when-new-item-instance
se declaneaz cnd focus-ul prsete cmpul curent)
On-eveniment funcionalitatea definit implicit n cazul declanrii acestui
eveniment este nlocuit cu aciunile definite n corpul trigger-ului (de
exemplu, On-logon se declaneaz n locul conectrii la baza de date Oracle i
este folosit, de exemplu, cnd se dorete conectarea programatic la alt baz
de date);
Pre-eveniment se declaneaz chiar nainte de eveniment; acetia preced
trigger-ii when-eveniment sau on-eveniment i sunt folosii n scopul pregtirii
obiectelor i a datelor pentru evenimentul ce se va declana;
Post-eveniment se declaneaz imediat dup trigger-ii when-eveniment sau
on-eveniment i este folosit, de obicei, pentru a valida datele sau pentru a
efectua anumite aciuni bazate pe evenimentul ce doar a avut loc;
Key se declaneaz la apsarea de ctre utilizator a tastei sau a combinaiei
de taste creia i sunt asignai (amintii-v c cele mai multe interfee grafice
ofer utilizatorului mai multe moduri pentru accesul la acelai obiect).
Exist, n Forms Developer, peste 100 de declanatori predefinii, fiecare
identificat unic prin numele su, format ntotdeauna conform sintaxei: prefix-eveniment.
Evenimentele ce au loc la nivelul bazei de date pot declana, de asemenea,
anumii trigger-i, dar acetia sunt diferii de cei din Forms. Exist, deci, trigger-i la

nivelul bazei de date i trigger-i la nivel de formular, acetia tratnd evenimente specifice
formularului.
Forms Builder-ul suport declanatoare definite de programator, dar acestea se
vor executa doar atunci cnd sunt apelate dintr-un alt trigger sau dintr-o unitate de
program, folosind sintaxa execute NumeTrigger.
Codul unui trigger definete aciunile care vor fi efectuate atunci cnd acesta se
declaneaz. Sintaxa este aceeai cu a unui bloc PL/SQL; dac lipsesc partea de declaraii
i cea de tratare a erorilor, nu este necesar includerea corpului trigger-ului ntre begin i
end. Secvenele de cod PL/SQL scrise pentru aplicaiile Forms cuprind adesea apeluri de
subprograme.
Subprogramele PL/SQL folosite n aplicaiile Forms sunt: funciile i
procedurile predefinite (Built-in) sau cele definite de utilizator. Primele se gsesc n
Object Navigator la nodul Built-in Packages, iar urmtoarele la nodul Program Units.
Observai n figura de mai jos existena funciei tot_fact, creat anterior de noi. Funciile
i procedurile built-in sunt grupate n pachete, conform funcionalitii lor i se apeleaz
folosind sintaxa: NumePachet.NumeProcedura. Pentru cele aflate n pachetul standard
numele acestuia poate fi omis.

Teoretic, aceste built-ins-uri pot fi folosite n orice subprogram PL/SQL sau
trigger. Practic, unele dintre acestea ofer funcionaliti care nu sunt permise n anumii
trigger-i. Acesta este motivul pentru care Built-ins-urile au fost mprite n dou
categorii:

105
nerestricionate nu afecteaz navigaia logic sau fizic i pot fi apelate n
orice trigger sau subprogram;
restricionate afecteaz navigaia n formular i pot fi apelate doar n
trigger-ii care nu genereaz navigaie intern. De exemplu, apelul unui built-in
restricionat (cum ar fi go_block(numeBloc);) ntr-un trigger navigaional (ca
when-new-item-instance, explicat mai jos) se compileaz cu succes, dar
genereaz eroare la rulare.
S ne amintim c am folosit pn acum cteva dintre built-ins-urile definite n
pachetul standard: show_view, hide_view, exit_form, get_item_property,
set_item_property. Forms Builder permite un mod rapid de inserare a prototipului unui
built-in n secvena de cod curent, astfel:
1. poziionm cursorul n editorul PL/SQL exact n locul n care dorim s fie
inserat apelul de subprogram;
2. expandm nodul Built-in Packages din Object Navigator i selectm
procedura sau funcia pe care vrem s o utilizm;
3. selectm Edit Paste Name sau Edit Paste Arguments din meniul Forms
Builder (prima opiune va genera inserarea doar a numelui, pe cnd cea de a
doua va include att numele, ct i argumentele subprogramului);
4. prototipul built-in-ului va fi copiat la poziia curent a cursorului, iar
utilizatorul va continua, dac este cazul, cu completarea numelor
argumentelor.
Variabilele folosite pentru stocarea valorilor n aplicaiile Forms sunt de dou
tipuri:
Variabile PL/SQL se definesc n seciunea declarativ i sunt disponibile
pn la ncheierea execuiei blocului curent; nu sunt prefixate de : ; pot fi
definite n pachete, caz n care se apeleaz prin NumePachet.NumeVariabila i
sunt accesibile din toi trigger-ii care utilizeaz respectivul pachet;
Variabile Forms Builder - sunt gestionate de Forms Builder i sunt vzute de
PL/SQL ca variabile externe; pentru deosebirea lor de obiectele PL/SQL se
impune prefixarea cu semnul : (exceptnd cazul n care numele lor este
transmis ca parametru unui subprogram). Exist patru tipuri de variabile
Forms Builder:

Tipul
variabilei
Domeniul Scopul utilizrii Sintaxa
Item (text, list,
radio group
etc.)
Modulul curent
i meniul ataat
Interaciunea cu
utilizatorul
:NumeBloc.NumeItem
Variabil
global
Toate modulele
din sesiunea
curent
Stocarea valorilor
pe parcursul unei
sesiuni de lucru
:GLOBAL.NumeVariabila
Variabil
sistem
Formularul
curent i meniul
ataat
Controlul
mediului de lucru
:SYSTEM.NUME_VARIABILA (numele
acestor variabile se scriu cu majuscule)
Parametri Modulul curent Transferul
valorilor spre i
de la modulul
curent
:PARAMETER.Nume
Domeniul de aciune al unui trigger (numit n engleza trigger scope) este
determinat de poziia sa n ierarhia obiectelor din Object Navigator:

Dup cum vedei n figura anterioar, exist trigger-i la nivel de: modul, bloc i
element. Unii trigger-i nu pot fi definii sub un anumit nivel. Un trigger rspunde unui

107
eveniment asociat obiectului care deine acel trigger sau oricrui alt obiect care este
deinut de primul. Putem avea, n formular, mai muli trigger-i cu acelai nume pe
niveluri diferite; n mod implicit, pe un obiect se declaneaz un singur trigger de acelai
tip: cel deinut de obiectul respectiv sau, n cazul n care nu exist, cel aflat pe nivelul
ierarhic superior cel mai apropiat. Acest comportament este definit de proprietatea
Execution Hierarchy, setat la valoarea Override. Alte valori posibile ale acestei
proprieti sunt: Before (caz n care trigger-ul aparinnd obiectului curent se va declana
naintea oricruia de acelai tip aflat pe nivelul superior cel mai apropiat) i After (caz n
care trigger-ul curent se va declana dup oricare altul de acelai tip aflat pe nivelul
superior cel mai apropiat).
Cu ct un trigger este mai sus, cu att el ascult mai multe evenimente. S lum
ca exemplu trigger-ul when-new-item-instance, care se declaneaz la prsirea de ctre
focus a item-ului curent i navigarea ctre un alt item. Putem crea acest trigger (i oricare
altul) n unul din mai multe moduri:
Selectnd din meniul de context al obiectului cruia vrem s i asociem
trigger-ul intrarea Smart triggers, care va afia un LOV cu trigger-ii cel mai
des declanati de obiectul curent:

Selectnd, n Object Navigator, nodul Trigger al obiectului cruia vrem sa i
atam trigger-ul i acionnd butonul Create.
Rezultatul oricreia dintre aceste aciuni va fi afiarea instrumentului PL/SQL
Editor, unde vom scrie secvena de cod ce va fi rulat la declanarea trigger-ului:


Built-in-ul message(text) are ca efect afiarea mesajului n bara de stare a
ferestrei Forms-ului. Apelarea de dou ori consecutiv a acestei proceduri are ca efect
aglomerarea mesageriei i apariia pe ecran a unei casete de alert, rezultat mult mai
vizibil utilizatorului. Dup ce ai scris codul asociat trigger-ului, nu uitai s acionai
butonul care l compileaz i corectai eventualele erori. Putem crea trigger-ul when-new-
item-instance la nivel de element, bloc sau modul. Dac vom scrie un singur trigger de
acest tip pentru item-ul cod_firma, de exemplu, el se va declana doar atunci cnd focus-
ul prsete acest item. Dac, ns, trigger-ul va fi asociat blocului bl_clienti, el va fi
declanat de evenimentul de prsire a oricrui element aflat n acest bloc, iar dac acest
trigger va fi asociat modulului, va fi declanat de mutarea focus-ului de pe oricare dintre
elementele formularului. Putem, de asemenea, defini trei trigger-i when-new-item-
instance, la toate cele trei niveluri (vezi figura anterioar), caz n care ordinea de
declanare este stabilit de proprietatea Execution Hierarchy detaliat anterior. ncercai
toate modalitile de definire a acestor trigger-i, apoi rulai, n fiecare caz, aplicaia i
observai rezultatele!
Am clasificat trigger-ii dup mai multe criterii, dar cel mai important este cel
referitor la contextul n care se declaneaz. Astfel, exist:

109
trigger-i de validare se declaneaz cnd Forms Developer valideaz date
dintr-un cmp sau nregistrare. Exist conceptul de unitate de validare,
reprezentnd volumul maxim de date pe care operatorul le poate introduce
nainte de a se efectua validarea lor (verificarea corectitudinii). Implicit,
unitatea de validare este item-ul, ceea ce nseamn c Forms Developer
iniiaz procesul de validare imediat ce se ncearc navigarea (programatic sau
de ctre operator) ctre alt item;
trigger-i tranzacionali apar ca rspuns a unor evenimente generate de
interaciunea dintre formular i baza de date;
trigger-i de interogare se declaneaz nainte (pre-query) sau dup (post-
query) ce operatorul sau aplicaia execut o cerere;
trigger-i navigaionali permit controlul asupra poziiei mouse-ului, definind,
de asemenea, aciuni ce se vor declana atunci cnd focus-ul intr sau
prsete un obiect;
trigger-i de procesare a blocului de date se declaneaz la operaii de
interaciune a formularului cu baza de date, creare de nregistrri noi, eliberare
a celor existente n bloc;
trigger-i master-detail au fost prezentai detaliat la crearea unui modul
master-detail; acetia sunt: on-check-delete-master, on-clear-detail, on-
populate-detail;
trigger-i interface-event se declaneaz la evenimente specifice interfeei
utilizator: when-mouse-click; when-mouse-down, when-button-pressed, when-
list-changed, etc.
trigger-i pentru interceptarea erorilor definesc aciunea ce trebuie ntreprins
la apariia unui mesaj sau a unei erori (exemplu: On-Error, On-Message).
2.11.1. 2.11.1. Trigger-i de interogare (query triggers) Trigger-i de interogare (query triggers)
Evenimentele asociate interogrilor asupra tabelelor de baz ale blocurilor de
date pot fi controlate prin intermediul trigger-ilor de interogare, care permit
personalizarea modului de lucru query. Pentru a ntelege tipologia acestor trigger-i, ar
trebui s cunoastem modul n care are loc procesul de interogare a bazei de date de ctre
formular. Cnd, ntr-un bloc de date, este iniiat o cerere (de ctre operator sau
programatic) formularul parcurge urmtoarele etape:
1. aflat n modul enter-query, Forms Developer declaneaz trigger-ul pre-
query, dac acesta exist; n cazul eurii, interogarea este abandonat; dac
trigger-ul se termin cu succes, se trece la pasul urmtor;

2. Forms-ul construiete, apoi execut fraza select utilizat pentru interogarea
tabelelor bazei de date; aceasta este creat folosind filtrele definite n blocul de
date, filtre care sunt introduse de utilizator sau/i de trigger-ul pre-query;
3. o linie ntoars de cerere este ncrcat ntr-o nregistrare nou, care va fi
marcat ca valid;
4. este declanat trigger-ul post-query; atenie: acest trigger se declaneaz
pentru fiecare nregistrare n parte i este folosit, n general, pentru popularea
elementelor non based-table, pentru efectuarea de calcule statistice. Dac
acest trigger eueaz, nregistrarea curent este abandonat i eliminat din
blocul de date. Se revine la pasul 3.
5. dac trigger-ul se termin cu succes, vor fi validate modificrile efectuate n
nregistrarea curent.
n afara celor doi trigger-i prezentai anterior, specifici modului de funcionare
query al formularului, se pot declana i ali trigger-i, dac proprietatea Fire in Query
Mode asociat lor este setat la valoarea Yes. n cazul cnd un trigger poate fi declanat n
ambele moduri (normal i query), este util de detectat starea n care se afl formularul; n
funcie de aceasta, vor fi efectuate aciuni diferite. Variabila sistem mode permite
detectarea modului de lucru n care se gsete formularul, avnd una din urmtoarele trei
valori:
Valoarea variabilei :SYSTEM.MODE Semnificaie
NORMAL Formularul se gsete n modul de
procesare normal
ENTER-QUERY Formularul este n modul enter-query, se
ateapt introducerea criteriului pentru
interogare
QUERY Formularul se afl n etapa de procesare a
nregistrrilor aduse de pe server
S presupunem c dorim s crem propriul buton pentru lansarea de cereri asupra
blocului bl_clienti. Vom crea un buton, numit cerere, care poate fi poziionat n orice
canvas, dar va trebui s aparin blocului asupra cruia se va executa interogarea. Motivul
este acela c, ntr-un trigger care se declaneaz n modul query nu avem voie s folosim
anumite build-ins-uri, printre care i cele care execut navigarea (go_block, go_record,
next_block, next_record etc.). n trigger vom folosi procedurile predefinite enter_query,

111
pentru comutarea n modul query i execute_query. Abandonarea modului query i
comutarea la modul normal se face cu ajutorul build-in-ului abort_query. Dac butonul
creat va fi n alt bloc dect cel care se dorete a fi interogat, acionarea lui nseamn
schimbarea focus-ului pe blocul cruia i aparine butonul i interogarea acelui bloc.
Crem, deci, butonul cerere n blocul bl_clienti, iar secvena de cod PL/SQL a trigger-
ului when-button-pressed va fi urmtoarea:

2.11.2. 2.11.2. Trigger-i de validare Trigger-i de validare
Forms Developer execut un proces de validare implicit, la diferite niveluri,
pentru a se asigura c nregistrrile i elementele individuale respect anumite reguli
(definite n paletele de proprieti ale elementelor, n trigger-i etc). Forms-ul declaneaz
fenomenul de validare la nivel de:
element (item) fiecare element are un status care indic validitatea acestuia.
Dac un item a fost modificat i nu este nc marcat ca valid (validat), Forms
efectueaz o validare a sa, verificnd dac valoarea este conform cu
condiiile impuse prin paleta de proprieti a elementului (format mask;
required; data type; range; validate from list). Aceste verificri preced
declanarea trigger-ului when-validate-item.
nregistrare (record) la ncercarea (iniiat programatic sau de ctre
utilizator) de a prsi o nregistrare, este verificat status-ul acesteia. n cazul
cnd nu a fost validat, este verificat status-ul fiecrui item, apoi este
declanat un eventual trigger when-validate-record. Dup ce toate aceste
etape sunt parcurse, nregistrarea este marcat ca valid;

bloc sau modul toate nregistrrile aflate sub acest nivel vor fi validate (de
exemplu, la efectuarea unui commit).
Unitatea de validare definete maximul de date ce pot fi introduse nainte de
declanarea automat a procesului de validare. Implicit, aceasta este setat la nivel de
item, dar poate fi definit, de asemenea, la nivel de record, block sau form.
Procesul de validare se declaneaz la navigarea din unitatea de validare
(programatic, printr-un trigger, sau de ctre utilizator) sau la rularea built-in-ului enter.
Acesta este un subprogram creat pentru forarea imediat a validrii la nivelul la care se
afl definit. De exemplu, crearea unui buton pentru care trigger-ul when-button-pressed
invoca built-in-ul enter va efectua validarea imediat a elementului pe care se afla focus-
ul.
Odat cu aducerea de pe server a nregistrrilor ce sunt folosite n formular,
Forms-ul ncarc adiional cteva pseudo-coloane (numite flag-uri interne), cum ar fi
row_id (un numr ce definete unic nregistrarea n baza de date) i valid (reprezentnd
status-ul obiectului curent). Astfel, Forms-ul urmrete cu uurin aciunile efectuate de
utilizator. Pentru a determina dac validarea datelor trebuie sau nu efectuat, Forms-ul
utilizeaz statutul nregistrrii sau al item-ului curent. Astfel, statutul unui item poate avea
una din valorile:
Status Explicaie
NEW La crearea unei nregistrri noi, fiecrui item i este acordat acest
status.
CHANGED Un item este marcat cu acest status dac valoarea sa este modificat
(programatic, de ctre un trigger, sau de ctre utilizator); de
asemenea, n cazul n care un item este modificat, toate item-urile
aparinnd aceleiai nregistrri vor fi marcate ca changed.
VALID Forms-ul marcheaz un item ca valid dac:
toate item-urile din nregistrarea ncrcat din baza de date sunt
marcate ca fiind valide;
procesul de validare al item-ului curent s-a terminat cu succes;
dup o instruciune post sau commit terminat cu succes;
fiecare item dintr-o nregistrare duplicat motenete status-ul de
la surs

113
Validarea are loc, dup cum precizam anterior, i la nivel de nregistrare. Orice
nregistrare primete un statut, dup regulile:

Status Explicaie
NEW La crearea unei nregistrri noi, acesteia i este acordat statutul new.
CHANGED Ori de cte ori un element dintr-o nregistrare este marcat ca
changed, acest statut i este acordat ntregii nregistrri.
VALID Forms-ul marcheaz o nregistrare ca valid dac:
toate item-urile din nregistrare au fost validate cu succes;
dup o instruciune post sau commit terminat cu succes;
o nregistrare duplicat motenete status-ul de la sursa sa.
Statutul unui element poate fi modificat programatic de ctre trigger-i care conin
built-ins-uri ce influeneaz procesul de validare:
clear_block, clear_form, exit_form primul parametru al acestor proceduri
indic modul n care vor fi operate modificrile fcute atunci cnd un bloc sau
un modul sunt reiniializate, respectiv cnd formularul se nchide (n cazul
procedurii exit_form). Atunci cnd este folosit valoarea NO_VALIDATE,
eventualele modificri nu vor fi operate. Absena unui parametru va produce
afiarea unei casete de dialog care ofer posibilitatea alegerii unei opiuni de
salvare.
Item_is_valid se pot folosi procedurile get_item_property i
set_item_property pentru a afla sau modifica proprietatea item_is_valid a unui
element. Acest mod de setare a status-ului unui element nu poate fi aplicat i
nregistrrilor. Totui, setnd status-ul fiecrui item al respectivei nregistrri,
avem controlul asupra status-ului nregistrrii nsei.
Enter este un built-in care foreaz validarea imediat a unitii curente de
validare;
Validate (domeniu) produce validarea imediat la nivel de domeniu, care
poate lua una din valorile: default_scope, block_scope, record_scope,
item_scope.

2.11.3. 2.11.3. Trigger-ii navigaionali Trigger-ii navigaionali
Forms Builder ofer o varietate de modaliti pentru deplasarea focus-ului.
Aceast aciune, iniiat de utilizator sau generat programatic, poart numele de
navigare.
Pentru a defini statutul navigaional al unui modul a fost definit noiunea de
unitate navigaional: aceasta este un obiect intern, invizibil, folosit pentru a reine poziia
curent a focus-ului i poate fi setat la una din valorile (se respect ierarhia urmtoare):
outside the form (n afara formularului), form, block, record, item. Cnd se navigheaz n
afara unui obiect, se schimb unitatea navigaional; Forms-ul parcurge ierarhia
precedent pn cnd elementul pe care se afl cursorul este atins.
Spre deosebire de unitatea navigaional, cursorul este un obiect vizibil, extern,
care indic poziia curent a focus-ului. n timpul procesului navigaional, Forms-ul
prsete un obiect i intr ntr-un altul. Ptrunderea ntr-un obiect nseamn modificarea
unitii navigaionale de la obiectul anterior ctre cel curent. Forms-ul nu va deplasa
cursorul pn cnd unitatea navigaional nu ia noua valoare. Dac navigarea eueaz,
Forms-ul modific unitatea navigaional la vechea valoare. Dac aceast tentativ
eueaz, Forms-ul nchide formularul. Cursorul rmne pe poziia iniial pn cnd
unitatea navigaional devine stabil.
Cnd utilizatorul iniiaz rularea unui formular, acesta observ cursorul
poziionat pe primul item din primul bloc navigaional (n ordinea din Object Navigator).
Accesarea primului item al formularului a implicat, ns, desfurarea unor procese
navigaionale complexe; adiional navigaiei externe (care poate fi observat de utilizator)
are loc i o navigare intern, care const n:
intrarea focus-ului n formular;
intrarea focus-ului n bloc;
intrarea pe prima nregistrare;
intrarea n item.
Prsirea item-ului curent i accesarea unui alt item, aparinnd altei nregistrri,
implic urmtoarele aciuni:
prsirea item-ului curent;
prsirea nregistrrii curente;
intrarea focus-ului pe noua nregistrare;
intrarea focus-ului pe item-ul dorit.
Modul n care se realizeaz navigarea se poate defini cu ajutorul proprietilor
obiectelor. Au fost detaliate anterior intrri din paletele de proprieti cum ar fi:

115
la nivel de modul: Mouse Navigation Limit (determin ct de departe relativ la
item-ul curent poate naviga utilizatorul cu mouse-ul), First Navigation Block
(neprecizarea unei valori pentru aceast proprietate va determina navigarea, la
iniierea formularului, n primul bloc, n ordinea n care sunt aezate n Object
Navigator);
la nivel de bloc de date: Navigation Style, Previous Navigation Data Block,
Next Navigation Data Block;
la nivel de item: Enabled, Keyboard Navigable, Mouse Navigate, Previous
Navigation Item, Next Navigation Item.
Navigarea dintr-un formular este influenat, n afara proprietilor specifice ale
obiectelor, i de trigger-ii navigaionali, care se mpart n dou categorii:
Post- i Pre- cnd ne deplasm din obiectul x n obiectul y, pentru primul se
declaneaz trigger-ul post-, iar pentru cel de al doilea trigger-ul pre-. Acetia
nu se declaneaz dac sunt definii pentru un nivel ierarhic inferior unitii
curente de validare. La euarea oricruia din aceti trigger-i focus-ul se
ntoarce pe obiectul prsit anterior.
When-new-<obiect>-instance se declaneaz imediat ce focus-ul este pe
obiectul <obiect> i unitatea de navigare este stabil.
Adesea poate avea loc, n timpul procesului navigaional, un fenomen interesant:
s presupunem c, la navigarea din obiectul x spre obiectul y, trigger-ul predefinit
pentru al doilea obiect eueaz. Atunci unitatea navigaional tinde s se ntoarc la
obiectul x. Dac acesta are un trigger predefinit i care eueaz, cursorul logic nu are
unde s se ntoarc i este generat o eroare. Euarea n lan a dou trigger-e se numete
capcana navigrii.
Procesul de navigare poate fi iniiat i programatic, folosind built-ins-uri
restricionate (acelea care afecteaz navigarea), cum ar fi: go_form, go_block, next_block,
up (navigheaz ctre instana item-ului curent aflat n nregistrarea anterioar), down,
next_set etc. Acestea nu pot fi, ns, utilizate n trigger-ii pre- i post-.
2.11.4. 2.11.4. Trigger-ii tranzacionali Trigger-ii tranzacionali
Procesul tranzacional este iniiat la apsarea de ctre utilizator a butonului Save
(sau, echivalent, selectarea opiunii Action Save din meniu) sau la apelarea, ntr-un
trigger, a procedurii commit_form.
La ncercarea de a salva modificrile fcute de utilizator ntr-un formular, se
declaneaz o secven de aciuni care poate fi algoritmizat dup urmtoarea schem:
1. validarea formularului;

2. declanarea trigger-ului pre-commit;
3. validarea blocurilor de date (n ordinea apariiei acestora n Object Navigator);
4. executarea operaiilor DML:
a. n cazul unui delete:
i. declanarea trigger-ului pre-delete;
ii. tergerea rndului din tabela de baz sau declanarea trigger-ului
On-Delete;
iii. declanarea trigger-ului Post-delete;
b. n cazul unui insert:
i. verific proprietatea Copy Value from Item;
ii. declaneaz trigger-ul pre-insert;
iii. verific unicitatea nregistrrii;
iv. insereaz rndul n tabela de baz sau declaneaz trigger-ul on-
insert;
v. se declaneaz trigger-ul post-insert
c. n cazul unui update:
i. se declaneaz trigger-ul pre-update;
ii. se verific unicitatea nregistrrii;
iii. se modific rndul corespunztor din tabela de baz sau se
declaneaz trigger-ul on-update;
iv. se declaneaz trigger-ul post-update;
5. se declaneaz trigger-ul post-form-commit; dac operaia urmtoare este
commit, atunci:
6. se execut o comanda SQL commit;
7. se declaneaz trigger-ul post-database-commit.
Enumerm n tabela urmtoare cteva din caracteristicile celor mai uzitai
trigger-i tranzacionali:

Trigger-i Caracteristici
Pre-commit Se declaneaz o singur
dat, nainte ca blocurile de
date s fie procesate.
Verificarea privilegiilor utilizatorului.

117
Pre-delete S presupunem c utilizatorul vrea s
tearg o nregistrare care are fii;
server-ul va returna o eroare, dar
putem preveni aceast situaie
cutand eventualii fii i tergndu-i
prin acest trigger.
Pre-insert Dac vrem s populm un item dintr-
o secven, putem seta proprietatea
Initial Value cu numele secvenei, caz
n care de fiecare dat cnd rulm
formularul valoarea curent a
secvenei se incrementeaz; putem
preveni aceast situaie folosind acest
trigger. Doar la declanarea lui va fi
incrementat secvena.
Pre-update Permite implementarea regulii cheii
externe. Putem simula un update n
cascad, n trigger actualiznd fiii,
apoi, n formular, tatl.
Post-DML
(update, delete,
insert)
Se declaneaz o singur dat
pentru fiecare nregistrare
marcat pentru o operaie
DML; trigger-ii pre-DML
sunt folosii i pentru
jurnalizare (memorarea, ntr-
o alt tabel, a operaiilor
DML efectuate asupra tabelei
de baz).

On-DML Se declaneaz pentru fiecare nregistrare marcat pentru insert,
update sau delete, nlocuind instruciunile DML standard cu cele
precizate n codul trigger-ului. De obicei, includ un apel la built-ins-
urile insert_record, update_record, delete_record.
Post-forms-
commit
Se declaneaz o singur dat, dup ce blocurile de date sunt
procesate, dar nainte de execuia instruciunii SQL commit.
Post-database-
commit
Se declaneaz o singur dat, dup executarea unui SQL-commit.

Desigur, utilitatea acestor trigger-i se definete programatic, n funcie de
cerinele utilizatorului, care pot fi cu totul altele dect cele prezentate n tabelul anterior.
S premiem acum cititorii care au avut rbdarea necesar atingerii acestei ultime
pagini a acestei pri a lucrrii de fa cu cateva task-uri:
1.. Ce efect credei c are definirea, la nivel de bloc de date, a trigger-ului on-
delete coninnd doar instructiunea null;?
2.. Ce efect va avea definirea, la nivel de bloc bl_clienti, a trigger-ului:

3.. Creai un canvas de tip toolbar vertical, unde aezai butoanele necesare n
formular. Creai un buton la a crui apsare formularul va intra n modul
enter-query. Utilizatorul va introduce criteriul de cutare, butonul i va
schimba eticheta, iar acionarea din nou a sa va avea efectul execute_query.
Dublu click pe codul unei facturi va determina apariia unui canvas de tip
stacked care va conine informaii referitoare la datele respectivei facturi:

119


3. 3. Oracle9i Reports Developer Oracle9i Reports Developer
3.1. 3.1. Introducere Introducere
Raportarea este procesul de oferire a informaiei ctre clieni ntr-o form
accesibil, bine structurat. Oracle9i Reports Developer reprezint soluia pentru
publicarea att pe web, ct i pe hrtie a oricrui tip de date, din orice surs, n orice
format. Cu Oracle9i Reports nu efectum modificri n tabele, ci doar extragem datele n
scopul prelucrrii lor i a afirii ntr-o form atrgtoare.
ntr-un mediu bazat pe Internet, clienii ateapt un rspuns prompt la cererile lor.
Una dintre modalitile de reducere a timpului de ateptare este dezvoltarea rapid a
rapoartelor, fr necesitatea scrierii a sute de linii de cod sau a formatrii manuale a
structurilor. n Oracle9i Reports ntregul mediu de dezvoltare este bazat pe instrumente
de tip wizard, urmate de generarea automat de cod i posibilitatea transmiterii ctre
browser a rapoartelor n formate diverse: Hypertext Markup Language (HTML) cu
Cascade Style Sheets (CSS), Extensible Markup Language (XML), Rich Text Format
(RTF), PostScript, Portable Document Format (PDF). Productivitatea muncii
programatorului este mbuntit i prin posibilitatea construirii, n afara modulelor de
tip raport, a nc dou tipuri de module: template-uri (un schelet coninnd reguli generale
de afiare a datelor ntr-un raport) i biblioteci de programe PL/SQL (conin uniti de
program ce pot fi apoi apelate din raport).
Tot mai muli utilizatori caut informaia n primul rnd pe Internet. Totui,
printarea informaiei are importana sa de necontestat. Aceste dou modaliti de
publicare sunt complementare una alteia, neexcluzndu-se reciproc. n majoritatea
cazurilor, nu putem afirma despre un fiier HTML care arat excelent ntr-o pagin web c
va avea acelai aspect i la printare, dup cum macheta unui raport creat pentru a fi printat
nu este satisfctoare pentru afiarea ntr-un browser. Instrumentul Reports Builder, care
permite proiectarea rapoartelor, construiete, n acelai timp, dou machete: una specific
web-ului, cealalt n scopul printrii. Macheta web este optimizat pentru HTML, pe cnd
macheta paper este proiectat pentru formatele PDF i PostScript. Avantajul major
const n faptul c modelul de date este unic, productivitatea fiind astfel mbuntit.
Ca i n cazul formularelor, raportul poate fi construit (cu ajutorul instrumentului
Reports Builder) i testat pe maina client (amintii-v, trebuie startat instana OC4J),
apoi transferat pe server-ul de aplicaii, care, fizic, se poate afla pe alt calculator. Orice
browser acceseaz raportul, aflat pe Oracle Application Server, printr-o adres web.
Raportul va accesa datele, aflate pe server-ul de baze de date. Algoritmul folosit pentru

121
crearea, testarea i rularea aplicaiilor Oracle9i Reports Developer este similar cu cel
utilizat de Oracle9i Forms Developer.
Oracle9i Reports Developer este, deci, o colecie de programe folosite pentru a
uura munca de raportare. Componenta Report Builder permite definirea modelului de
date pentru raport, crearea i testarea machetelor web i paper, posibilitatea atarii de
coninut dinamic unui raport HTML prin ataarea de marcaje Java Server Page (JSP) etc.
Componenta Oracle9iAS Reports Services ofer mediul pentru rularea, distribuirea i
publicarea aplicaiilor Oracle9i Reports Developer.
Executabilele incluse n Reports Developer au fost denumite n Windows
conform regulii rw<?>.exe i sunt prezentate pe scurt n tabelul urmtor:

Numele
fisierului
executabil
Numele aplicaiei Descriere
rwbuilder Reports Builder Creeaz i rafineaz raportul.
rwrun Reports runtime Mediu runtime pentru testare.
D
e
v
e
l
o
p
e
r

rwconverter Reports Converter Convertete raportul n diferite formate de
stocare.
rwserver Reports Server Instaleaz/apeleaz componente de pe
Internet Application Server (IAS) care
gestioneaz rapoartele ce se vor executa.
rwclient Reports Client Acceseaz server-ul de rapoarte i trimite
acolo linia de comand pentru executarea
raportului curent.
rwrqm Reports Queue
Manager
Vizualizeaz i programeaz la ore stabilite
execuia rapoartelor.
rwservlet Reports Servlet Ruleaz raportul pentru web, asigurnd
procesarea server-side ce const, de obicei,
n accesarea bazei de date.
R
e
p
o
r
t
s

S
e
r
v
i
c
e
s

rwcgi Reports CGI Este meninut doar pentru compatibilitatea
cu versiunile anterioare; ofer o conexiune
ntre server-ul web i Reports Services.

Crearea unui raport include definirea a dou elemente (distincte n faza de proiectare) ce
vor determina, la rulare, coninutul i aspectul raportului. Cele dou pri logice ale unui
raport sunt:
Modelul de date, constnd n datele ce vor fi afiate la ieire i structura lor;

123
Macheta (layout), ce definete modul de afiare a datelor la ieire. Macheta
poate fi de tip paper (utilizat pentru rapoartele destinate printrii) sau de tip
web (utilizat pentru rapoartele ce se vor publica pe web). Macheta de tip web
are n spate cod surs (HTML i JSP).
Un raport poate conine:
Un model de date i o macheta paper;
Un model de date i o macheta web;
Un model de date, o macheta web i una paper.

3.2. 3.2. Proiectarea rapoartelor Proiectarea rapoartelor
3.2.1. 3.2.1. Componentele Reports Builder Reports Builde Componentele r
Aplicaia Report Builder include patru componente:
1. Object Navigator;
2. Report Editor;
3. Property Inspector;
4. Editorul PL/SQL.
ncercai s le identificai n captura de ecran urmtoare:


Object Navigator
Acesta const, ca i n cazul produsului Forms
Builder, ntr-o prezentare ierarhic a tuturor obiectelor
aplicaiei, permind accesarea i manipularea lor
rapid. Toate nodurile din Object Navigator, mai puin
Database Objects, conin obiecte aflate pe parte de
client. La crearea unui raport nou (prin click pe
butonul marcat cu o cruce verde i aflat n partea
superioar a barei de instrumente), acestuia i va fi
automat asignat numele ModuleN, N fiind numrul
su. Numele raportului nu poate fi modificat la fel ca
n cazul formularelor. Salvarea raportului va produce
modificarea automat a numelui su n Object
Navigator acordndu-i-se aceeai valoare cu numele
fiierului. Obiectele coninute n raport se mpart n
mai multe categorii (reflectate i n ierarhia din Object
Navigator):

125
Raport se afl proprieti generale, legate de setrile pentru previzualizare,
dimensiuni ale paginilor etc.;
Data Model obiectele aflate la acest nivel definesc datele publicate n raport
i structura lor. Exist 11 parametri-sistem care ateapt s fie setai, se pot
defini parametri-utilizator, sunt coninute frazele select, mpreun cu
eventualele grupuri returnate de acestea. Ierarhia de la nodul Groups indic
tipul raportului: master-detail sau simplu. Putem avea mai multe fraze select,
dar acestea trebuie conectate logic; n acest scop exist nodul Data Links.
Web Layout bazndu-se pe frazele select, Reports Builder construiete dou
machete: Paper Layout i Web Layout, n spatele creia este cod HTML
mpnat cu marcaje JSP;
Paper Layout obiectele aflate sub acest nod definesc formatul raportului:
poziionarea i frecvena de apariie a datelor, text i elemente grafice;
Paper Parameter Form definete apariia n runtime a unui formular pentru
parametri; crem, de exemplu, un raport care s afieze toate comenzile unui
client. La rularea raportului va aprea o form de parametri, n care utilizatorul
va introduce codul clientului, iar raportul va afia doar comenzile acestuia.
Astfel, este creat un singur raport i rulat pentru mai multe seturi de date;
Report Triggers conine proceduri PL/SQL care se vor declana n timpul
populrii cu date i al formatrii lor. Reports Builder conine cinci trigger-i,
care sunt:
o Before Report trigger;
o After Report trigger;
o Between Pages trigger;
o Before Parameter Form trigger;
o After Parameter Form trigger.
Program Units
Attached Libraries .
Report Editor
Acesta este un utilitar care conine cinci moduri de vizualizare utilizate pentru
gestionarea modelului de date i a machetelor raportului. Fiecare din acestea poate fi
accesat printr-un buton aflat n colul din stnga sus al ferestrei editorului de rapoarte sau
din meniul Reports Builder, selectnd View Change View, apoi modul de vizualizare
dorit. S le prezentam pe scurt, urmnd s revenim asupra lor, n
ordinea apariiei n fereastra editorului de rapoarte:

Data Model (nu confundai modul de vizualizare Data
Model cu nodul Data Model din Object Navigator!)
const n reprezentarea simbolic a structurilor de date
afiate n raport. Sunt marcate special tipul obiectelor i
relaiile dintre acestea. Obiectele aflate aici nu vor aprea
ca atare n raport, la rularea acestuia, dar vor influena
macheta.
Web Source acest mod permite vizualizarea codului
surs care produce publicarea pe
web a raportului. Dup cum
precizam, la definirea cu ajutorul
instrumentului Report Wizard a
raportului se poate alege crearea
ambelor machete (web i paper),
ns modificarea ulterioar a
oricreia dintre acestea nu se va
reflecta i n cealalt machet, care
va trebui modificat manual.
Paper Layout reprezint o zon
de lucru n care putem defini
modul de afiare a
datelor. Se lucreaz
cu obiecte specifice
machetelor, cum ar
fi: cadre, cadre
repetitive, cmpuri,
ancore i obiecte
grafice. La rulare, Reports Builder folosete aceast machet ca pe un schelet
de baz, pe care l expandeaz astfel nct datele s poat fi poziionate n el.
Paper Design este un mod de vizualizare care ofer un preview al raportului
i permite manipularea coninutului efectiv
al acestuia (acest mod de vizualizare este
ideal pentru a modifica, de exemplu,
limea unei coloane).
Paper Parameter Form permite crearea,
cu ajutorul instrumentului Paper
Parameter Builder, a unui formular unde
utilizatorul va introduce proprii parametri
sau va fi invitat s aleag valorile dintr-un
LOV.

127
Reamintim c Data Model este responsabil cu partea logic a raportului, livrnd
informaia, n timp ce paper layout i web layout se ocup de modul de afiare a acesteia.
Legtura dintre modelul de date i machet se face la rularea raportului n modul urmtor:
pentru fiecare grupare din Data Model, Report Builder construiete n machet cte un
cadru repetitiv (repeating frame) i reciproc, orice cadru repetitiv are la baz o grupare. n
cadrul unui repeating frame avem cmpuri (fields). Ele sunt populate conform
instruciunii select definite la acest pas.
Property Inspector
Toate obiectele din Object Navigator au cte o palet de proprieti specifice,
care descriu comportamentul obiectului. Paleta de proprieti a oricrui obiect se obine
apsnd tasta F4, atunci cnd obiectul este selectat sau alegnd opiunea Property
Inspector din meniul de context al obiectului.
Editorul PL/SQL
Acest instrument este identic cu cel folosit n Forms Builder i permite scrierea i
compilarea de cod PL/SQL asignat unei proceduri definite de utilizator sau unui trigger.
3.2.2. 3.2.2. Instrumente de tip wizard wizar Instrumente de tip d
Indiferent de modul de stocare a raportului, definiia acestuia trebuie s conin
un model de date, o surs web i/sau o machet pentru printare, uniti de program i
formulare pentru parametri. Modelul de date i unitile de program sunt comune ambelor
machete (web i paper).
n Oracle9i Reports avem mai multe posibiliti pentru a crea un raport:
folosind Reports Builder;
definind modelul de date i/sau macheta ntr-un fiier XML.
Ne vom opri asupra primei posibiliti i ne vom uura munca folosind
instrumentele de tip wizard incluse n Report Builder, apoi vom rafina manual raportul
obinut. Reamintim faptul c orice modificare manual ntr-una din machetele paper sau
web nu se va reflecta i n cealalt.
Sa purcedem, deci, la construirea unui raport. Din aceleai considerente cu cele
prezentate n capitolul Oracle9i Forms Developer trebuie startat instana OC4J (care
creeaz un mediu virtual ce permite rularea rapoartelor, n vederea testrii), apoi aplicaia
Report Builder, al crei shortcut poate fi gsit la meniul Start al Windows-ului:


Invocarea Reports Builder-ului va produce afiarea unei casete de dialog cu
opiuni privind modul de creare a raportului:

129
Una dintre cele mai uzitate modaliti este folosirea instrumentului Report
Wizard, urmat de rafinarea manual a raportului. S lsm, deci, opiunea Use the
Report Wizard bifat i s continum. Report Wizard ofer o interfa de tip step-by-step
pentru crearea unui raport. Prima sa caset de dialog cuprinde un mesaj introductiv i
poate fi inhibat prin deselectarea casetei de validare Display at Startup. Pagina
urmtoare culege informaie referitoare la modul de publicare a raportului, n funcie de
care creeaz machetele paper, web sau pe amndou.
Acionarea butonului Next determin afiarea casetei Report Style, n care
specificm titlul i tipul raportului ce va fi creat:

n campul Title completm textul titlului raportului, aa cum vrem s apar la
afiare (partea de formatare a sa se definete ulterior), apoi selectm un buton din grupul
radio ce permite specificarea tipului raportului ce va fi creat. Observai faptul c, la acest
moment, ultimele trei opiuni (legate de etichete i scrisori) sunt inhibate, deoarece am
ales i generarea machetei web, unde nu are sens publicarea a astfel de documente. n
cazul cnd, n caseta de dialog anterioar (Layout Type) am fi ales Paper Layout Only am
fi avut, la acest pas, i ultimele trei posibilitati disponibile.
Pentru o nelegere mai bun a acestor tipuri de rapoarte, s reamintin c se
lucreaz cu un model de date, bazat pe o fraz select executat n runtime i care are ca
efect ncrcarea de pe server a setului de date necesar raportului. Aceste date sunt afiate
conform unei machete. Report Builder organizeaz datele, crend grupuri. La scrierea
unei instruciuni select pe o tabel este creat automat un grup, care conine coloanele
selectate n cerere. Se pot defini grupuri adiionale (pentru a crea niveluri de diviziune ale
raportului) manual sau folosind Report Wizard, opiunile group-above i group-left.

Revenim la caseta de dialog ce permite determinarea tipului raportului. Exist,
dup cum observai, mai multe tipuri de rapoarte:
tabulare cel mai des ntlnite; fiecare coloan a raportului corespunde unei
coloane dintr-o tabel;
group-left mparte rndurile din tabel n submulimi, n fiecare submulime
fiind coninute rndurile pentru care valoarea uneia dintre coloane este
aceeai; se folosete pentru evitarea repetrii afirii informaiei;
group-above conine dou sau mai multe grupuri de date; pentru fiecare
valoare din grupul master, sunt afiate valorile corespunztoare din grupurile
detail;
matrix un raport de tip matricial conine un rnd de etichete, o coloan de
etichete, iar informaia aflat la intersecia acestora este corelat cu
semnificaia etichetelor. O caracteristic important a acestui tip de rapoarte
este acela c numrul de coloane nu este cunoscut pn la ncrcarea datelor
din baza de date;
matrix with groups este un raport de tip group-above cu o matrice pentru
fiecare valoare a grupului master.
S construim un raport tabular lsnd, deci, bifat primul buton al grupului radio,
tabelar. Urmtoarea caset de dialog, Data Source Type, permite specificarea sursei de
date a raportului. Vom construi un raport pe baza unei instruciuni select, deci selectm
opiunea SQL Query i apsm butonul Next, care permite definirea sursei de date:

131

Pentru a accesa datele din baza de date trebuie s ne conectm la aceasta
(observai butonul Connect), apoi putem tasta fraza select ce va popula raportul. Pentru
utilizatorii nu prea familiarizai cu limbajul SQL avem la dispoziie un utilitar pentru
automatizarea crerii cererilor, numit Query Builder. Invocarea sa (prin acionarea
butonului corespunztor) va determina apariia unei casete ce conine toate tabelele din
schema utilizatorului curent, n vederea selectrii acelora care vor participa la fraza select:

S crem un raport simplu, care va afia toate produsele aflate n stoc. Selectm
tabela stoc, apoi acionm butonul Include. Procedm la fel cu toate tabelele ce vor oferi
date n vederea publicrii, apoi dm click pe butonul Close. Urmtoarea fereastr conine
toate tabelele selectate la pasul anterior i permite specificarea coloanelor care vor intra n
cerere i a relaiilor dintre tabele (n cazul rapoartelor master-detail) . Putem da dublu
click pe numele tabelei, rezultatul fiind selectarea tuturor coloanelor:

Dm click pe OK i automat Query Builder va copia sintaxa cererii n Report
Wizard:

133

Caseta urmtoare de dialog, numit Fields, permite selectarea cmpurilor care
vor participa la output. Cmpurile selectate n zona Available Fields pot fi mutate n zona
cmpurilor ce vor fi afiate (Displayed Fields) prin acionarea butonului >. Pentru
selectarea rapid a tuturor coloanelor se apas butonul >>. Ordinea apariiei cmpurilor n
zona Displayed Fields va determina ordinea apariiei coloanelor raportului n runtime.
ntr-un raport tabelar, acestea vor fi aezate n ordinea specificat, de la stnga la dreapta.
Folosind tehnica drag putem modifica ordinea de apariie a coloanelor n raport.
Cmpurile rmase n zona Available Fields pot fi referite n raport (ele se numesc
ascunse) i folosite n calcule statistice sau n codul trigger-ilor.
Acionnd butonul Next ajungem la urmtoarea caset de dialog, Totals, unde
putem crea totaluri bazate pe funciile statistice SQL standard afiate de Report Wizard:


Toate funciile, mai puin count, folosesc valori numerice. Acionnd butonul
corespunztor funciei dorite, aceasta va fi aplicat cmpului selectat n zona Available
Fields. Wizard-ul va crea cte un total la fiecare nivel al raportului, adic: pentru ntregul
raport i pentru fiecare grup n parte, n cazul existenei acestora.
Urmtoarea caset de dialog permite ataarea unor etichete cmpurilor, precum i
setarea dimensiunii acestora, iar ultimul pas al wizard-ului ofer posibilitatea alegerii unei
machete pentru publicarea raportului, dintr-o serie de template-uri disponibile.
Utilizatorul i poate defini propriile machete, pe care le va salva ca template-uri n
vederea aplicrii lor ulterioare asupra altor rapoarte. Acionarea butonului Finish va
determina invocarea utilitarului Report Editor, n modul Paper Design, care permite o
vizualizare a raportului:

135

Este momentul s salvm rezultatul muncii noastre de pn acum. Ceea ce vom
salva de fapt nu este raportul, aa cum apare el n runtime, ci definiia sa. La fiecare rulare
va fi executat fraza select ce va popula raportul, iar informaia returnat de aceasta va fi
afiat conform specificaiilor machetei. S selectam, deci, din meniul Report Builder
opiunea File Save. Aceast aciune va invoca o bine-cunoscut caset de dialog
specific mediului Windows, ce permite alegerea locului unde va fi stocat raportul, a
numelui su i a formatului n care este salvat:


Formatul implicit este .jsp. Remarcai n LOV-ul afiat anterior existena
formatului .rdf, specific versiunii 6 a produsului Oracle Reports i introdus n aceast
versiune doar pentru compatibilitatea cu cele anterioare.

3.3. . Report Editor 5 moduri de vizualizare a raportului Report Editor ortului 3.3 5 moduri de vizualizare a rap
Macheta raportului fiind salvat, ne ntoarcem la utilitarul Report Editor, unde
vom analiza modurile de vizualizare a raportului i modificrile ce se pot efectua n
fiecare din acestea.
Primul, n ordinea apariiei butoanelor care le apeleaz, este modul ce permite
vizualizarea modelului de date:

137

A fost creat o cerere, numit implicit Q_1, iar ea a generat un grup, numit G_1.
(Fiecare cerere genereaz un grup propriu!) Toate coloanele returnate de fraza select se
afl n grupul G_1. Coloanele singulare (create de utilizator pentru calcule statistice) se
afl n afara grupului. Observai sgeata orientat n sus i aflat n stnga fiecrui
element al grupului G_1. Aceasta este adaugat implicit i determin o clauza order by.
Pentru creterea vitezei de rulare a raportului este recomandat anularea acestei clauze
pentru coloanele unde ea nu este necesar (setnd proprietatea Break Order a coloanei la
valoarea dorit: Null, Ascending sau Descending).
Proprietile obiectului Q_1 i ale grupului generat de acesta pot fi modificate
prin intermediul inspectorului de proprieti. Proprietile specifice unei cereri pot fi
observate n figura urmtoare:

Acesta este locul de unde putem
modifica numele cererii, tipul i numrul
maxim de rnduri returnate de aceasta
(opiune extrem de util n cazul n care
suntem n faza de testare a raportului, iar
baza de date conine mii de nregistrri),
precum i fraza select. Este recomandabil
ca ntr-un model de date complex numele
atribuite automat cererilor s fie
modificate de ctre utilizator, pentru o mai
bun nelegere a acestora. Comentariile
pot fi inserate la proprietatea Comments
sau direct n fraza SQL, folosind
delimitatorii:
utilitarului Query Builder, coninutul
-- pentru comentariu la sfarsitul liniei curenta;
/* comentariu */ pentru comentarii multi-linie.
Coloanele returnate de fraza select nu pot fi terse cu tasta Del n Data Model.
Doar coloanele create de utilizator pot fi terse n acest mod; pentru primul caz, trebuie
modificat chiar fraza select: la efectuarea unui click pe proprietatea SQL Query
Statement vom obine aceeai caset de dialog cu cea ntlnit n Report Wizard, n care
utilizatorul poate modifica manual sau cu ajutorul
cererii:

Aceeai caset de dialog poate fi invocat i dnd dublu click pe numele cererii,
Q_1.

139
Urmrii, n figura de mai jos, legtura dintre elementele modelului de date i
cmpurile afiate la rularea raportului: obiectul Q_1 genereaz o fraz select ce populeaz
grupul de nregistrri G_1. Fiecare nregistrare ncrcat din baza de date va deveni o
instan a grupului. Fiecare element al unei nregistrri este ncrcat n coloana
corespunztoare a grupului de date. Fiecare coloan ntoarce valori care sunt afiate n
cmpurile corespunztoare. Un cmp trebuie s afieze toate instanele coloanei asociate;
consecin, fiecare nregistrare instan a grupului este reprezentat de un cadru
etitiv (repeating frame).

SELECT..
n
rep

\

Modificrile fcute n Data Model, nu se vor reflecta automat n Layout. Toate
aceste eventuale modificri din Data Model trebuie fcute manual i n Layout: o coloan
care a fost tears din modelul de date va trebui tears i n layout; dac adugm
manual n fraza select o coloan, aceasta va aprea n modelul de date la nivelul cel mai
de jos. Utilizatorul va trebui s o trag cu mouse-ul la nivelul dorit, apoi s fac
modificarea corespunztoare i n layout. Din pcate, la acest nivel nu ne putem permite
sa invo
iionarea elementelor n
ciat; cadrele repetitive sunt
odul
z o singur dat;
Acionnd, n fereastra Report Editor, butonul corespunztor modului de
vizualizare Paper Layout va fi afiat urmtoarea fereastr:
cm Layout Wizard-ul, care mi recreeaz macheta, distrugnd-o pe cea veche
(asupra creia se presupune c s-au efectuat rafinri complexe ce vor fi pierdute).
Urmtorul mod de vizualizare a raportului este accesat cu ajutorul butonului Web
Source. Vom reveni ulterior asupra acestuia, trecnd acum la macheta pe care i-o
construiete Report Builder-ul pentru a printa raportul i definit n modul Paper Layout.
Obiectele specifice acestui mod de vizualizare definesc poz
pagin, precum i modul n care vor fi afiate datele, elementele text i graficele. Cele
mai des ntlnite obiecte, specifice modului Paper Layout sunt:
Cadru repetitiv (repeating frame) conine obiecte care sunt afiate o singur
dat pentru fiecare nregistrare a grupului aso
figurate ca dreptunghiuri pe ale cror laturi se afl sgei, n funcie de m
de expandare (gsii explicaii detaliate mai jos);
cadru (frame) - grupeaz mai multe obiecte i se afiea
cmp (field) conine date i modul lor de formatare;
boilerplate conine text sau imagini ce pot aprea oriunde n raport.

141

Remarcai, n Object Navigator, existena a trei sub-noduri ale nodului Paper
Layout: Header Section (coninnd informaia ce va fi afiat la nceputul raportului),
Main Section (coninutul efectiv al raportului) i Trailer Section (coninnd informaia ce
va fi afiat la sfritul raportului). n fereastra Report Editor este apsat butonul
corespunztor seciunii Main (vezi sgeata). Pentru afiarea celorlalte seciuni se vor
aciona butoanele corespunztoare (alturate celui prezentat anterior).
S rearanjm obiectele n machet, mrind spaiul dintre ele. Aceast aciune are
ca scop nelegerea tipurilor de obiecte ce pot fi manipulate n modul de vizualizare
curent. Mutarea obiectelor trebuie fcut ns cu mult atenie. Cele mai grave i dese
erori provin din poziionarea unui cmp care trebuie s afieze o ntreag coloan de date
n afara cadrului repetitiv ce l conine. Selectm n Object Navigator ntregul cadru
M_G_1_GRPFR (dnd click pe el). n fereastra Report Editor mutm ntregul grup,
folosind sgeile (jos i dreapta). Acelai rezultat poate fi obinut i cu ajutorul mouse-
ului. Selectm n continuare cadrul M_G_1_FTR, care genereaz n raport ultima linie, n
care este afiat totalul. n fereastra Report Editor mutm i acest cadru mai jos. n sfrit,
selectm cadrul repetitiv R_G_1 i procedm n acelai mod. Observai, n Object
Navigator, dreptunghiul marcat cu sgeat asociat cadrului R_G_1, care indic faptul c
acesta este de tip repetitiv. Cadrele anterioare pot fi selectate, de asemenea, prin

selectarea unui obiect coninut n ele i acionarea butonului Select Parent Frame: .
Rezultatul deplasrilor anterioare de cadre este urmtorul:

S urmrim nc o dat cadrele generate pentru acest raport: cadrul printe este
numit implicit M_G_1_GPRFR i este ncadrat n Report Editor ntr-un dreptunghi
marcat pe laturile verticale cu cte un romb. Acest romb indic tipul de elasticitate a
cadrului (n cazul nostru, se expandeaz pe vertical, astfel nct s poat cuprinde
ntregul volum de date). Exist mai multe tipuri de elasticitate, iar acestea pot fi setate cu
ajutorul inspectorului de proprieti al cadrului, capitolul General Layout:
cadru cu elasticitate fix (fixed elasticity)- mrimea cadrului nu variaz n
funcie de dimensiunea sau numrul obiectelor pe care le include; este
reprezentat printr-un dreptunghi fr marcaje adiionale;
cadru ce se poate contracta (contracting elasticity) dimensiunea
cadrului se poate micora n funcie de mrimea obiectelor pe care le
include, dar nu poate crete; este reprezentat printr-un dreptunghi avnd
cte un cerc pe dou laturi opuse;

143
cadru ce se poate expanda (expanding elasticity)- dimensiunea cadrului
se poate mri n funcie de mrimea obiectelor pe care le include, dar nu
se poate micora; este reprezentat printr-un dreptunghi avnd cte dou
liniue paralele pe dou laturi opuse;
cadru cu elasticitate variabil (variable elasiticty) dimensiunea cadrului
se ajusteaz (mrindu-se sau micorndu-se) n funcie de obiectele
coninute n cadru; este reprezentat printr-un dreptunghi avnd cte un
romb pe dou laturi paralele.
n funcie de laturile dreptunghiului pe care se afl marcajele, elasticitatea poate
aciona pe vertical sau pe orizontal. Adugnd doar faptul c sgeata n jos ataat
dreptunghiului cadrului G_R_1 semnific faptul c acesta este repetitiv, suntem n msur
s nelegem toate elementele ce apar n fereastra Report Editor, modul Paper Layout.
Acionnd urmtorul buton, Paper Design, obinem un preview al raportului
proiectat pentru tiprire. Acesta este un editor de tipul WYSIWYG, n care putem face
modificri direct asupra setului de date reale.

Selectai coloana Pret Unit i ncercai s formatai modul de afiare a sa
acionnd grupul de butoane din bara de instrumente formatting (asemntoare cu cea din
aplicaiile Microsoft): Ultimul grup de butoane permite
adugarea automat a unuia din semnele dolar, procent sau virgul. S adugm semnul
monedei americane i s presupunem c dorim formatri mai complexe, cum ar fi: toate
cantitile mai mici dect 150 s fie marcate (avertizndu-ne, astfel, c respectivul produs
tinde s fie epuizat). Ne poziionm pe coloana Cantit i din meniul de context (obinut
dnd click dreapta pe respectiva coloan) alegem opiunea Conditional Formatting. Din
caseta de dialog afiat alegem opiunea new (crem o nou condiie de formatare) i
trecem la urmtorul pas, specificarea condiiilor:

Specificm, aa ca n figura anterioar, condiia (valoarea cmpului cantit mai
mic dect 150), iar n partea de jos a ferestrei precizm modul n care va fi formatat
cmpul dac ndeplinete condiia anterioar. Am ales culoarea textului - albastr, iar
pentru haurare i chenar dou nuane de galben. Rezultatul va fi urmtorul:

145

Putem aduga, de asemenea, numrul paginii curente, precum i data, eventual
ora la care a fost generat raportul. Acest lucru se face ntr-un mod asemntor aplicaiilor
Microsoft Office, prin selectarea din meniul Insert a opiunilor Page Number, respectiv
Date and Time. Opiunea AutoText permite stocarea i inserarea automat a unor poriuni
de text, grafice, cmpuri i a altor elemente care sunt folosite frecvent.

3.4. 3.4. Rapoarte cu grupuri master-detail master detail Rapoarte cu grupuri -
Am creat i analizat n capitolele precedente un raport simplu, bazat pe un singur
grup de date. O s continum cu rapoarte mai complexe, analiznd structura datelor care
sunt afiate i modul n care poate fi modificat raportul prin manipularea modelului de
date. S generm un nou raport, n care s afim pentru fiecare firm toate facturile
existente (de intrare sau ieire). Pentru fiecare factur vom afia produsele
corespunztoare, precum i cantitatea. Raportul final va arta astfel:


S invocm bine-cunoscutul Report Wizard. n pagina Style dm un titlu
raportului (de exemplu, Facturi i produse) i alegem tipul de raport Group Left. Sursa de
date va fi, ca i pn acum, rezultatul unei cereri SQL. La pasul urmtor invocm Query
Builder-ul i selectm trei tabele: produse, facturi i stoc. Relaia de join dintre cele trei
tabele este generat automat, iar noi precizm ce coloane dorim s apar n raport, bifnd
casetele de validare din stnga fiecreia:

147

Acionnd butonul OK, va fi generat automat fraza SQL:

Urmtorul pas al wizard-ului permite definirea unor grupuri de date; dorim ca
produsele s fie grupate pe firme, iar n cadrul fiecrei firme dup factur. Pentru a
realiza acest lucru, procedm n felul urmtor: n caseta Groups a wizard-ului mutm din
zona Available Fields n zona Group Fields cmpul cod_firma. Astfel, va fi creat un grup
dup acest cmp. Dorim ca, n cadrul acestui grup, produsele s fie grupate dup codul
facturii. Putem proceda n unul din dou moduri: avnd selectat grupul cod_firma din
caseta din dreapta, mutm cmpul cod_factura din zona cmpurilor disponibile n cea a
gruprilor. Rezultatul va fi urmtorul:

Al doilea mod n care putem proceda este s mutm cmpul cod_fact n zona
Groups avnd selectat n caseta din dreapta Level 1. Rezultatul va fi altul:

149

Diferena dintre cele dou metode este c n primul caz vor fi create n Data
Model doar dou grupuri de date, pe cnd n cazul al doilea vor fi create trei grupuri. Care
din cele dou metode este cea corect? Analizndu-le pe amndou, vor hotr mpreun
acest lucru, pe parcursul prezentului capitol. Deci, s procedm conform primului caz; n
caseta urmtoare, Fields, precizm care din cmpuri vor fi folosite la afiare. Le selectm
pe toate i le mutm n zona Displayed Fields. Ordinea n care sunt cmpurile afiate la
printarea raportului este aceeai cu ordinea n care se gsesc n zona Displayed Fields i
poate fi schimbat n mai multe moduri; unul dintre ele este rearanjarea cmpurilor chiar
n aceast caset, prin drag&drop. Urmtorii pai ai wizard-ului sunt cei deja cunoscui,
iar rezultatul final ar trebui s fie raportul din figura de la nceputul prezentului
subcapitol. S analizm modelul de date pe care se bazeaz acest raport:


A fost generat o cerere SQL (prezentat anterior) i dou grupri, unul master,
cellalt detail. Aceast structur poate fi observat att n Data Model, ct i n Object
Navigator. S ne reamintim c un raport tabular se bazeaz pe o cerere care genereaz un
singur grup, pe cnd rapoartele de tip Group Above i Group Left conin o cerere i dou
sau mai multe grupuri.
Pentru fiecare nregistrare din grupul master vor fi listate toate nregistrrile din
grupul detail. Sgeile afiate n Data Model n stnga fiecrei coloane indic faptul c
nregistrrile sunt sortate. Proprietatea corespunztoare (accesibil prin Property
Inspector) se numete Break Order. Sgeile sunt, ns, valabile doar pentru grupul
master. n grupul detail ele nu au nici un efect, sortarea realizndu-se prin modificarea de
ctre utilizator a cererii SQL, introducnd manual o clauz order by. Este recomandat
eliminarea sgeilor care nu sunt necesare, pentru mbuntirea performanelor
raportului.
Observai, n raportul generat, un lucru mai putin plcut: pentru o firm care are
mai multe facturi, codul firmei va fi afiat de mai multe ori, odat cu fiecare factur.
nelegnd corect modelul de date, realizm i de ce se ntmpl acest lucru. Folosind
acest model de date, nu putem determina afiarea codului firmei o singur dat. Putem
realiza ns acest lucru modificnd Data Model: pentru fiecare firm, trebuie s am o

151
grupare detail care s afieze toate facturile. Acest scenariu corespunde celui de al doilea
mod de creare a gruprilor, folosind dou niveluri (n acest subcapitol spuneam c putem
crea n Report Wizard grupul cod_factura avnd selectat Level 1 n pagina Groups, caseta
Group Fields. Rulai Report Wizard n modul reentrant, facei modificarea
corespunztoare i vei observa c raportul arat n felul urmtor:

Modelul de date este, ns, altul fa de cel prezentat anterior:


Dup cum observai, n Oracle9i Reports grupurile sunt organizate conform unei
ierarhii. Aceasta poate fi modificat invocnd Report Wizard-ul n modul reentrant;
exist ns situaii cnd nu vrem s folosim acest mod de a modifica Data Model (de
exemplu, n cazul cnd vrem s evitm pierderea unor rafinri efectuate dup ncheierea
procesului de generare a raportului cu ajutorul wizard-ului). n acest caz, putem crea
grupuri noi chiar n Report Editor.

3.5. 3.5. Modificarea rapoartelor folosind Data Model Data Model Modificarea rapoartelor folosind
Modelul de date definete datele care apar n raport i ierarhia acestora, deci
structura raportului, ns nu permite definirea nici unui atribut de formatare a raportului.
Modelul de date este creat odat cu raportul, la rularea instrumentului Report Wizard.
Artam ntr-un capitol anterior c pasul urmtor rulrii acestui wizard este rafinarea
manual a raportului. Dup ce toate aceste etape au fost parcurse, poate aprea necesitatea
modificrii structurii datelor, prin crearea unui grup nou, introducerea unor coloane
suplimentare etc. Toate aceste modificri vor fi fcute manual, n Data Model.

153
S revenim la modelul de date anterior:

Pentru evitarea afirii de mai multe ori a codului clientului vom crea, de aceasta
dat manual, un nou grup de date. Astfel, primul grup master va conine cmpul
cod_firma, iar pentru fiecare firm va fi generat grupul detail al facturilor asociate
respectivei firme. La rndul su, acest grup va avea ca grup copil pe G_COD_PROD.
3.5.1. 3.5.1. Crearea manual a grupurilor Crearea manual a grupurilor
Putem crea un grup master al grupului G_1 trgnd cmpul cod_fact n partea
stng, apoi elibernd mouse-ul sau putem crea un grup detail pentru G_1 trgnd cmpul
cod_firma n partea dreapt i elibernd mouse-ul; n cel de al doilea caz, Data Model va
arta astfel:


Odat creat noul grup, n el pot fi mutate i alte coloane, trgndu-le cu mouse-ul
n ierarhie de sus n jos, dintr-un grup superior n cel nou sau ntr-unul inferior lui.
Ordinea n care grupurile apar n Data Model are efect asupra modului n care vor fi
afiate. Trebuie s ne asigurm c ntotdeauna grupurile printe (master) sunt afiate
naintea grupurilor copil (detail).

155

Ne ntoarcem la primul model de date, cu doar dou grupuri. Proprietile
grupurilor pot fi vizualizate i modificate folosind Inspector Property: observai
posibilitatea introducerii unui filtru la nivel de grup, prin selectarea proprietii Filter
Type. Exist trei tipuri de filtru: First, urmat de specificarea unui Number of Rows
determin afiarea, pentru fiecare nregistrare master, a numrului de nregistrri detail
specificate de utilizator. Urmtoarea proprietate, Last, acioneaz asemntor, ns
produce afiarea ultimelor rnduri din gruparea detail. Aceste proprieti sunt foarte utile
n faza de testare a raportului. Cea de a treia valoare a proprietii Filter Type, PL/SQL,
permite inserarea de cod PL/SQL pentru stabilirea filtrului. Filtrul PL/SQL este o funcie
boolean, care ntoarce, deci, una din valorile true sau false. Funcia se declaneaz
pentru fiecare instan: dac este ntoars valoarea true, nregistrarea este afiat; n caz
contrar, ea este eliminat din raport. S presupunem c dorim s afim doar acele
produse pentru care cantitatea este mai mare de 50. Funcia boolean care realizeaz acest
lucru este:


3.5.2. 3.5.2. Adugarea manual a coloanelor Adugarea manual a coloanelor
Coloanele existente n Data Model provin, aa cum am artat anterior, din cererea
select care populeaz raportul folosind coloanele existente n tabelele bazei de date.
Reports Builder-ul impune cteva restricii n manipularea acestor tipuri de coloane:
O parte din proprietile lor sunt read-only: Name, Column Type, Data Type i
Width. Aceste informaii provin din tabelele bazei de date i nu pot fi
modificate n Report Builder;
Nu pot fi terse direct n grup (cu tasta Del, de exemplu), ci trebuie eliminate
din cererea select.
n afara coloanelor bazate pe cmpurile tabelelor, utilizatorul poate crea propriile
coloane, care pot fi de mai multe feluri:
Summary aplic funciile statistice standard unei alte coloane sau unui grup
de coloane; poate fi definit la momentul crerii raportului, folosind
instrumentul Report Wizard; numele acordat implicit de ctre Reports Builder
unei astfel de coloane este CS_1;

157
Formula se calculeaz ca rezultat al unei funcii scrise de utilizator n
PL/SQL; numele acordat implicit de ctre Reports Builder unei astfel de
coloane este CF_1;
Placeholder primete valoare n runtime, de la un alt obiect; numele acordat
implicit de ctre Reports Builder unei astfel de coloane este CP_1. O coloan
de tip placeholder este, de fapt, un container populat cu elemente aduse, n
general, dintr-o coloan sau dintr-un trigger.
Fiecare din cele trei tipuri de coloane poate fi creat folosind toolbar-ul vertical
din Report Editor:

S ne amintim c raportul asupra cruia lucrm de vreo dou subcapitole ncoace
afieaz situaia comenzilor corespunztoare fiecrei facturi, pentru fiecare produs fiind
afiate numele acestuia, cantitatea i preul unitar. S presupunem c, dup formatri
complexe asupra machetei, a aprut necesitatea inserrii unei coloane noi, care s afieze
pentru fiecare produs preul total, adic valoarea produsului (cantitatea * pretul unitar).
Nu dorim s alterm rafinrile efectuate asupra layout-ului, aa c vom introduce manual
o nou coloan de tip formula.
S crem, n Data Model, o nou coloan care s calculeze produsul dintre preul
i cantitatea corespunztoare fiecrui produs. Pentru aceasta selectm butonul Formula
Column, apoi dm click n grupul G_COD_PROD, unde este locul noii coloane. Astfel,
modelul de date a fost modificat:


Acionnd paleta de proprieti a coloanei nou create, putem modifica numele
acesteia i i acordm funcionalitate. O coloan de tip formula va avea valorile calculate
conform unei funcii PL/SQL definite de utilizator. Funcia trebuie s ntoarc o singur
valoare, de tipul specificat conform proprietii
Datatype i de lungimea definit prin
proprietatea Length.

Acionnd butonul corespunztor
proprietii PL/SQL Formula va aprea caseta
bine-cunoscut, care permite inserarea codului
PL/SQL ce se va executa la fiecare instan a
grupului cruia i aparine cmpul curent.
Funcia care va calcula valoarea dorit este:
159

Nu uitai s compilai funcia, acionnd butonul corespunztor, Compile.
Vizualizarea raportului n modul Paper Design (care reprezint, dup cum precizam
anterior, un instrument WYSIWYG) nu prezint nici o modificare, coloana nou creat
neaprnd. Ne ateptam, ns, la acest lucru, deoarece am precizat c modificrile
efectuate manual n Data Model nu se regsesc automat n layout. Modificarea manual a
machetei raportului este o operaie deosebit de dificil, care trebuie efectuat cu mult
atenie. Deplasarea elementului grafic ce desemneaz un cmp n afara grupului cruia i
aparine respectivul cmp (n Object Navigator) duce la o eroare fatal i la
imposibilitatea rulrii raportului. Pentru a modifica cu succes macheta raportului trebuie
s aprofundm elementele ce o definesc i comportamentul acestora.

3.6. 3.6. Modificarea raportului folosind Paper layout Paper layout Modificarea raportului folosind
3.6.1. 3.6.1. Cele 3 seciuni ale raportului: header, main, trailer le header main trai Cele 3 seciuni ale raportului: , , r
Un raport este implementat, din punctul de vedere al aplicaiei Oracle Reports,
asemntor cu o carte: informaia pe care cererea select o aduce din baza de date este
depozitat ntr-o seciune numit main. Putem crea, ns, pagini-antet i pagini ce vor fi
ataate la sfritul raportului. Acestea pot conine simplu text sau informaii din modelul
de date. Seciunea antet (header section) conine una sau mai multe pagini care vor fi
afiate o singur dat, la nceputul raportului. Seciunea trailer se comport ntr-un mod
similar, dar informaia corespunztoare acesteia va fi afiat la sfritul raportului. Cele
trei seciuni ale raportului sunt afiate n Object Navigator la nodul Paper Layout.
La fel ca n cazul seciunii main, n seciunile header i trailer machetele pot fi
construite cu ajutorul instrumentelor de tip wizard sau manual. Comutarea ntre cele trei
seciuni ale raportului se face prin acionarea butoanelor corespunztoare aflate n partea
superioar a ferestrei Paper Layout:


Acionai primul din cele trei butoane; va aprea o zon fr informaii, n care
putei insera informaiile ce dorii a aprea pe prima pagin a raportului. Acionnd
butonul text, putei insera text static, iar cu ajutorul butonului Field putei
insera informaia corespunztoare unuia din cmpurile existente la nivel de raport.
Acionai paleta de proprieti a cmpului nou creat i alegei, la proprietatea Source,
afiarea datei la care a fost rulat raportul:

161

Prima pagin a raportului poate fi vizualizat cu ajutorul instrumentului Report
Editor, n modul Paper Design :


Aa cum precizam anterior, seciunile header i trailer pot conine de asemenea
informaie dinamic, generat n runtime. Un exemplu a fost prezentat anterior i a
constat n inserarea datei la care a fost generat raportul. Macheta seciunilor sus-amintite
poate fi creat manual sau automat, cu ajutorul instrumentelor de tip wizard. Simpla
invocare a utilitarului Report Wizard va produce rularea lui n modul reentrant i
afectarea machetei seciunii main. Se dorete, ns, crearea unei machete adiionale,
pentru seciunea header, iar acest lucru se obine prin acionarea prealabil a butonului
Report Block, ultimul din bara vertical de instrumente aflat n fereastra Paper Layout i
marcat prin semnul . Apsarea acestui buton, urmat de rularea instrumentului
Report Wizard, va determina crearea unei machete adiionale, pentru seciunea header.
Paii specifici acestui wizard sunt deja cunoscui. ncercai s afiai, pe aceast prim
pagin a raportului, numele firmelor cu care firma curent are schimburi de marf,
precum i codurile tuturor facturilor operate (grupate pe firme).
3.6.2. 3.6.2. Margini Margini

163
Editorul Paper Layout permite att modificarea corpului celor trei seciuni ale
raportului, ct i setarea marginilor lor. Fiecare pagin fizic (indiferent de seciunea care
o genereaz) conine dou zone: corpul paginii i marginea sa. Comutarea ntre cele dou
zone se poate face, la orice moment, acionnd butonul Body/Margin aflat n zona
superioar a ferestrei Paper Layout i marcat prin icon-ul . Marginile pot conine
text static, grafice, imagini, numerotarea paginilor, totaluri etc. Cnd utilizatorul
selecteaz butonul Body/Margin pentru a vizualiza i modifica marginile, zona body
rmne, de asemenea, vizibil, dar nu poate fi modificat (este read-only). Ea este
ncadrat ntr-un dreptunghi cu laturile negre, care stabilete grania dintre margini i
corpul paginii. Modificarea dimensiunilor marginii poate fi fcut selectnd dreptunghiul
negru care o ncadreaz i redimensionndu-l, cu ajutorul mouse-ului.
S ncercm inserarea unei imagini dintr-un fiier n zona margins. Apsm n
bara vertical de instrumente a ferestrei Paper Layout butonul File Link, reprezentat prin
imaginea , apoi dm click n zona unde vrem s fie afiat figura. Va fi creat un
obiect nou, a crui funcionalitate o vom stabili folosind paleta sa de proprieti:


Proprietatea File Source Format va trebui setat la valoarea Image, iar actionarea
butonului atasat proprietii Source filename conduce la afiarea ferestrei Open, n care
putem selecta fisierul al carui continut va fi afiat.
Efectul ultimelor modificari poate fi vizualizat folosind modul Paper Design:

Aplicatii Profesionale BDOO

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Aplicatii Profesionale BDOO

Încărcat de

Drepturi de autor:

Formate disponibile

Universitatea din Bucureti

Facultatea de Matematic i Informatic

S-ar putea să vă placă și