Cerca nel blog

sabato 27 aprile 2013

Sintassi delle url's di Oracle Apex

Scopo di questo post è quello di illustrare com'è composta la url di invocazione di una generica web application realizzata con Oracle Apex. 
Ogni webapp sviluppata con Oracel Apex farà riferimento all'applicazione ed alle pagine che compongono l'applicazione stessa per cui in generale ci troveremo davanti ad url's così composte:
../f?p=57:1:101890654386421:::::
Analizzando il formato di tale url osserviamo la presenza di differenti parametri il cui significato posizionale è il seguente:
. f?p=APP_ID significa che stiamo invocando la webapp identificata dal numero dell'applicazione detto APP_ID
. APP_PAGE_ID costituisce il numero di pagina dell'applicazione APP_ID
. APP_SESSION rappresenta il session_id identificativo della sessione attiva per la chiamata in corso relativa allo specifico user che naviga le differenti pagina della webapp
. REQUEST costituisce il valore dell'item che ha effettuato la html request nell'ambito della sessione. 
. DEBUG permette di abilitare la visualizzazione in modalità DEBUG della pagina (valore YES) con relativi dettagli del debug.
. ClearCache consente di cancellare la cache per una oppure una serie di pagina della webapp
.ItemNames consente di settare un insieme di item nella sessione corrente
. ItemValues consente di settare i valori degli itemnames utilizzando la stessa rappresentazione posizionale.
. PrinterFriendly consente di settare per la pagina l'anteprima di stampa (valore YES)
Esempi di quanto sopra descritto sono i seguenti:

../apex/f?p=22104:1:135056808798032::NO:::
in questo caso invochiamo l'applicazione 22104, la pagina 1 dell'applicazione, sarà generata la session 135056808798032 e disabilitiamo il debug per la pagina

../apex/f?p=22104:4:135056808798032:fsp_sort_3::
in questo caso invochiamo la pagina 4 dell'applicazione 22104 ed il parametro REQUEST indica il valore fsp_sort_3 come link che ha generato la request html

Al prox post su.....Oracle Apex






lunedì 25 febbraio 2013

Oracle Apex e controlli JavaScript

Le potenzialità delle librerie Javascript sono ben consolidate nel contesto di Oracle Apex.
Risulta quindi possibile inserire frammenti di codice jscript per gestire ad esempio molteplici e sempre utili controlli client-side.
In questo articolo metteremo in evidenza  la possibilità di effettuare controlli client-side sugli item di una pagina/form della nostra generica web application sfruttando le potenziali di Javascript e non ricorrendo quindi a controlli server-side.
Creiamo quindi una generica web application nella quale definiremo la pagina controlli_jscript ed una html region con degli item su cui faremo validazione mediante controlli client-side jscript.
















La nostra semplice web application permette all'utente di inserire i dati anagrafici ed effettua il controllo di validazione sull'item P9_ETA verificando che il valore imputato  sia maggiore o superiore a 18 anni con alert di errore nel caso il valore fosse inferiore a 18.
La validazione dell'item P9_ETA sarà effettuata mediante una semplice funzione javascript che effettua in modalità client-side il controllo del valore inserito nell'item P9_ETA:


<script type="text/javascript">
function ControllaEta(object){
if(parseInt(object.value)<18)
alert('Valore non ammesso. Età inferiore a 18 anni');
}
</script>

il codice sarà inserito nella proprietà/tabs tab Html Header della pagina controlli_jscript:














mentre la chiamata della funziona ControllaEta sarà eseguita al verificarsi dell'evento javascript onblur (evento che scatta una volta che diventa passivo l'item P9_ETA):



















Ed ecco il risultato della validation sull'item P9_ETA una volta che viene inserito un valore inferiore a 18:













L'utilizzo delle librerie jscript in Oracle Apex consente di implementare molteplici controlli, quello visto in questo esempio richiede la scrittura di codice da parte dello sviluppatore mentre le dynamic action (ne parlo qui) consentono mediante wizard la realizzazione di potenti controlli che implementano nativamente codice jscrip e ajax.

Al prox post su......Oracle Apex.

Salvatore Bartucci

lunedì 18 febbraio 2013

Dynamic Action in Oracle Apex

Le Dynamic Action permettono di implementare controlli client-side sugli applicativi sviluppati in Oracle Apex mediante la combinazione di controlli Javascript ed Ajax.
La realizzazione di Dynamic Action avviene mediante l'uso di wizard guidati che facilitano notevolmente lo sviluppatore il quale non si preoccupa della stesura del codice Javascript.
Attraverso la creazione di dynamic action diventa quindi possibile attuare controlli client-side che permettono di nascondere/mostrare (meccanismo di hide/show) item o bottoni delle web form al verificarsi di particolari eventi sulla maschera (double click, valorizzazione di item, etc).
Vediamo un semplice esempio di utilizzo delle dynamic action, in particolare realizziamo una nuova pagina nella nostra web application nella quale saranno presenti due items nazione e descrizione.
Definiamo l'item nazione come select list con valori statici (Francia, Germania, Italia, Usa) mentre l'item descrizione sarà di tipo Text Area per contenere la descrizione della nazione che l'utente potrà inserire.
Realizziamo una semplice dynamic action che verifichi il valore della lista delle nazioni ed allorquando l'utente sceglie 'Italia' l'item descrizione sarà immediatamente valorizzato con un testo predefinito.
Creiamo quindi la pagina P_Dyn_Act di tipo blank page con all'interno la region html R_Dyn_Act ed associamo alla region gli item I1_DYN_ACT ed I2_DYN_ACT.
I1_DYN_ACT sarà di tipo select list e corrisponde alle nazioni mentre I1_DYN_ACT sarà di tipo text area e corrisponde alla descrizione delle nazioni.


Definiamo adesso la Dynamic action attraverso la quale l'utente una volta selezionata la nazione Italia dal select item avrà immediatamente valorizzato il campo descrizione con il testo seguente 'La penisola italiana si trova nel cuore del mediterraneo.'
Attraverso il wizard a livello di item I1_DYN_ACT creiamo la Dynamic action Dyn_Nazione, l'evento che scatenerà la Dynamic Action sarà il 'change' nel select item delle nazioni, in particolare nella sezione When viene indicato l'item I1_DYN_ACT con condition equal to al valore Italia:



Definiamo le condizioni true e false della dynamic action in base alle quali l'item della descrizione I2_DYN_ACT assumerà il valore predefinito (caso true = Italia) oppure apparirà vuoto e quindi pronto all'inserimento di testo nel caso condizione false.
















La condizione true con il relativo valore ('La penisola italiana...') che assumerà l'item I2_DYN_ACT:










La condizione false con l'azione di clear dell'item I2_DYN_ACT:















Infine eseguendo la web application avremo il risultato seguente nel caso di nazione diversa da Italia:










Mentre la selezione del valore Italia comporterà il caricamento in automatico nel campo descrizione:










Attraverso le dynamic action si possono implementare sofisticati meccanismi client side che rendono le web application molto funzionali ed estremamente dinamiche agli eventi che scaturiscono nel flusso di selezione dei dati.

Al prox post su...Oracle Apex

Salvatore Bartucci


venerdì 11 gennaio 2013

Oracle Apex - Una web application per la raccolta differenziata

In questo nuovo post sulle funzionalità ed uso di Oracle Apex ho implementato una semplice web application    per la gestione della raccolta Differenziata. Ci ritroviamo quotidianamente a chiederci come debbano esssere differenziati i vari tipi di rifiuti che quotidianamente vengono prodotti e spesso siamo assaliti da dubbi amletici per capire quel tipo di rifiuto come dev'essere differenziato e quindi in quale 'contenitore' dev'essere riposto allora grazie all'uso del web effettuiamo ricerche di pagine web per avere una risposta. Questa semplice web application censisce un numero (censimento work-in-progress) di 'rifiuti' e indica quale sia la modalità di 'differenziare' più idonea.
Creiamo quindi la nostra semplice web appllication GestDifferenziata e definiamo due nuove pagine al suo interno.
Avremo la pagina 1 che chiameremo P_RicercaRifiuto, sarà di tipo page blank con all'interno una region html R_RicercaRifiuto nella quale definiamo il text item P1_RIFIUTO che sarà di tipo autocomplete Fig.1:

Fig.1

Questo text_field sarà valorizzato con le tipologie di rifiuti censiti nella relativa tabella del DB. Ad esempio si potrebbe creare una semplice tabella come la seguente(chiaramente si possono creare più tabelle e relazionarle,etc):



CREATE TABLE "RIFIUTI" 
("ID_RIFIUTO" NUMBER NOT NULL ENABLE, 
"DESCRIZIONE" VARCHAR2(100) NOT NULL ENABLE, 
"TIPOLOGIA_RIFIUTO" VARCHAR2(50) NOT NULL ENABLE, 
"CONTENITORE" VARCHAR2(50) NOT NULL ENABLE)


In tal caso avremmo una sola tabella nella quale censiremo la tipologia di rifiuto con relativo Id e descrizione, le categorie dei rifiuti (Organico, carta, indifferenziata, etx) ed il contenitore in cui dev'essere differenziato (Bianco - Carta; Marrone - Organico; Blu - Multi-materiale; Verde - Vetro).
Sempre all'interno della region R_RicercaRifiuto definiamo anche un button region P1_CERCA, che una volta valorizzato il text field P1_RIFIUTO, avrà come action Fig.2 quella del submit della pagina P_RicercaRifiuto che punterà al link definito attraverso il branches p_6 (Fig. 3) della sezione Page Processing.


Fig. 2












Fig. 3

   










Fig. 4




















Il branches P_6 non avrà altro che la funzione di invocare la pagina 6 (vedremo in seguito che sarà una pagina di tipo report) passando il parametro p1_rifiuto della page 1 che valorizzerà il data field IT_6 nella page 6 (Fig. 4).
Creiamo infine la pagina 6 P_GestDiff dove sarà mostrato il risultato di come differenziare il rifiuto cercato nella pagina 1. 


Fig. 5





P_GestDiff sarà quindi di tipo report, all'interno avremo il data filed di tipo hidden IT_6 che riceve il valore di parametro P1_RIFIUTO passato nel branches P_6. _Il data field IT_6 sarà quindi usato nella query del report R_GesDiff presente nella page 6 (Fig. 5).
Infine nella Fig.6 è evidenziata la semplice query di ricerca che utilizziamo nel report R_GesDiff con l'uso del parametro hidden IT_6(che avrà il valore di P1_RIFIUTO per via del passaggio di parametro effettuato attraverso il branches P_6) nella where condition della Sql Query.
Infine nelle figure 7 e 8 l'esecuzione della web application con la ricerca del rifiuto e il risultato di come differenziarlo


Fig. 6



Fig. 7
















Fig. 8



























Qui è visualizzabile la semplice web application GestDifferenziata, spero nel corso del tempo di renderla più appetibile come veste grafica e censire più rifiuti possibili.
Al prox post su Oracle Apex.

Salvatore Bartucci