What's new di SitePainter Infinity

Transcript

1 What's new di SitePainter Infinity

2 COPYRIGHT by ZUCCHETTI S.p.A. Tutti i diritti riservati. Questa pubblicazione contiene informazioni protette da copyright. Nessuna parte di questa pubblicazione può essere riprodotta, trascritta o copiata senza il permesso dell'autore. TRADEMARKS Tutti i marchi di fabbrica sono di proprietà dei rispettivi detentori e vengono riconosciuti in questa pubblicazione. Ultima revisione Giugno 2009 ZUCCHETTI S.p.A. infotools@zucchetti.it Indirizzi sito WEB:

3 Sommario What's New Librerie aggiuntive (JAR) Componente SlideToolbar in SPI Portalstudio Componente Timer in SPI Portalstudio Routine asincrone Grafici nel report SPI Portalstudio: Data object e Data Grid server-side 'Suggest' sui campi linkati Portlet inclusi nelle gestioni La robustezza delle credenziali Foundling child SOMMARIO I

4

5 Capitolo 1 What's New Ecco l'elenco delle nuove implementazioni della build Librerie aggiuntive (JAR) Le librerie aggiuntive che venivano usate sia per la compilazione che per l'esecuzione delle applicazioni realizzate con SITEPAINTER INFINITY, sono state inserite direttamente nella cartella 'libraries' del tool al fine di facilitare le operazioni di setup e di avere tutto sempre a disposizione. Nota bene Nel caso si utilizzi una versione pre-esistente del jdk si consiglia chiaramente di eliminare i vecchi jar delle release precedenti del tool dalla cartella jdk/jre/lib/ext. I jar rilasciati con questa versione sono compatibili a partire dal jdk 15 e dal Tomcat 5.x. Nome file Versione Dim.ne in byte Necessario in compilazione servlet.jar si no jcaptcha.jar si si commonscollections.jar commons-loggingapi.jar no si no si Necessario esecuzione in Per chi utilizza un runtime Java 1.4.x Nome file Versione Dim.ne in byte Necessario in compilazione rowset.jar no si Necessario esecuzione in WHAT'S NEW 1

6 Modulo WebReport Nome file Versione Dim.ne in byte Necessario in compilazione dsn.jar si si imap.jar si si mailapi.jar si si pop3.jar si si smtp.jar si si activation.jar si si JimiProClasses.jar si si pja.jar no si itext.jar si si jcommon.jar si si jfreechart.jar si si Necessario esecuzione in LEGENDA Le librerie necessarie in compilazione vengono usate per il la compilazione dei sorgenti java generati dal tool. In particolare la versione correntemente distribuita della servlet.jar risulta valida per versioni delle API a partire dalla 2.4 (ad esempio il jar risulta valido a partire da Tomcat 5.x. Se risultasse necessario utilizzare versioni precedenti alla 5.x è necessario utilizzare la versione 2.3 recuperabile direttamente sul sito del produttore dell'application server). Le librerie necessarie in esecuzione sono usate quando l'applicazione viene testata/pubblicata. Queste vengono deployate nell'application (per Tomcat ad esempio nella WEB-INF\lib). Per ogni container bisogna studiare le istruzioni relative alla struttura delle directory. I raggruppamenti delle librerie sono effettuati secondo i seguenti criteri Le prime righe sono necessarie per qualsiasi tipo di applicazione realizzata con SITEPAINTER INFINITY. La versione delle API minima richiesta per poter utilizzare un'applicazione Sitepainter è la 2.3. Se il JDK usato per compilare l'applicazione è lo stesso usato per eseguire il container delle servlet bisogna aver cura di porre nella directory <JDK DIR>/jre/lib/ext una versione compatibile con il container utilizzato: ad es. la versione 2.3 per Tomcat 4.x. Le librerie necessarie al runtime Java 1.4.x sono diventate parte integrante dell'edizione standard della piattaforma Java 5 a partire dalla versione 1.5 e sono anch'esse necessarie per tutte le applicazioni. Vanno quindi usate solo se l'applicazione viene testata/pubblicata in un ambiente di versione precedente la 1.5.x. Le librerie del WebReport sono necessarie unicamente se si utilizza il modulo WebReport. 2 WHAT'S NEW

7 1.2 Componente SlideToolbar in SPI Portalstudio Figura 1 - L'effetto della toolbar a scorrimento A fronte della creazione di nuovi skin per le applicazioni realizzate con SITEPAINTER INFINITY abbiamo pensato di rendere disponibile questo nuovo componente che consente di creare toolbar in cui i bottoni 'scorrono', da qui il nome di SlideToolbar, per far apparire un testo quando ci si posiziona sopra. Figura 2 - Il decoratore dei titoli delle gestioni per lo Skin Infinity L'utilizzo principale lo possiamo ritrovare nei portlet che fanno da 'Decoratori' per i titoli delle gestioni. La toolbar di stato che consente l'interazione con la servlet è stata creata proprio sfruttando questo oggetto. Rimandiamo alla documentazione di SITEPAINTER PortalStudio per le proprietà, i metodi e gli eventi supportati dal componente. WHAT'S NEW 3

8 1.3 Componente Timer in SPI Portalstudio Figura 3 - L'oggetto Timer In SITEPAINTER PortalStudio è stata aggiunta una nuova componente, utilizzabile nei portlet: Timer. Questa componente permette di eseguire una procedura ad una cadenza temporale predefinita, in modo da poter creare oggetti attivi che anche senza l'intervento dell'utente eseguono dei compiti come controllare se sono arrivati messaggi di posta, se ci sono aggiornamenti delle pagine che stiamo osservando o se altri utenti si sono loggati al sistema. Inserendo un oggetto di questo tipo nel portlet avremo una componente senza interfaccia, nascosta all'utente, il cui unico compito è attivare un evento a cadenza temporale predefinita che potrà essere gestito da una procedure nell'action Code del portlet. 4 WHAT'S NEW

9 Figura 4 - Un esempio di Timer utilizzato con routine asincrona La componente permette una controllo molto fine su quando l'evento viene attivato. La forma più semplice è un intervallo fisso espresso in millisecondi: in questo caso l'evento verrà scatenato ripetutamente al passare del tempo. Questa che è la forma più semplice non risponde completamente alle esigenze applicative. Quindi è possibile modularne il funzionamento attraverso proprietà e procedure. La prima è la possibilità di definire se la componente è attiva immediatamente o se inizierà a scatenare l'evento dopo essere stata attivata attraverso una apposita funzione. Specularmente a volte un compito, una volta portato a termine, potrebbe non richiedere più questa esecuzione cadenzata, quindi è a disposizione del programmatore una funzione che permette di disattivare la componente che smetterà di scatenare l'evento. La frequenza in cui viene attivato l'evento potrebbe variare a seconda dello stato dell'applicazione. Per esempio, in una chat, finché si è in attesa potrebbe bastare un controllo ogni secondo, mentre iniziata la conversazione per poter avere un comportamento fluido occorre verificare lo stato dei messaggi con una frequenza più elevata. La componente offre una funzione che permette di modulare l'intervallo di chiamata, risolvendo questi casi. Un'altra possibilità è quella di scatenare l'evento un numero prefissato di volte. Per esempio si potrebbe voler controllare solo 5 volte se una risorsa è disponibile per poi proseguire con un'opzione alternativa. Questo componente è stato principalmente realizzato per poter essere utilizzato con la nuova feature delle routine asincrone. Ulteriori dettagli possono essere reperiti nel manuale User's Guide (spr_usg) presente nella directory help del tool. WHAT'S NEW 5

10 1.4 Routine asincrone Figura 5 - Un esempio di Routine asincrona Le routine di SITEPAINTER INFINITY sono programmi procedurali che svolgono il loro compito senza presentare un'interfaccia all'utente. Spesso i compiti svolti non possono essere eseguiti in tempi bervi, per cui la tradizionale struttura a botta e risposta prevista dalle applicazioni web non può essere utilizzata: una routine che viene eseguita in termini di minuti (o addirittura di più) lascia l'utente di fronte ad una pagina bianca senza far capire se il programma è in esecuzione o ha incontrato problemi e si è piantato. Se poi viene superato il tempo di timeout previsto dal browser, l'utente si trova di fronte ad uno sconcertante messaggio di errore quando in realtà tutto procede regolarmente. Il trucco a cui molti sono ricorsi è quello di utilizzare lo schedulatore, lanciando un compito a distanza di pochi secondi e quindi monitorandone il procedere. Naturalmente questa soluzione, pur essendo soddisfacente, introduce una inutile complessità richiedendo a presenza dello schedulatore sfruttandone in realtà la sola capacità di creare thread di esecuzione indipendenti dal thread principale dell'utente. In questa versione è stata quindi introdotta una nuova opzione che permette di risolvere elegantemente questo problema, senza dove ricorrere alla sovrastruttura dello schedulatore: l'esecuzione di una routine in modo asincrono. L'operazione di esecuzione di una routine da parte di una routine principale ora presenta la possibilità di eseguire la routine chiamata in modo asincrono. Scegliendo questa opzione il tool crea un nuovo thread ed esegue la routine da chiamare in questo contesto. Il programma quindi prosegue mentre la routine lanciata viene eseguita in parallelo al programma principale. Sono chiaramente stati creati dei metodi per recuperare l'identificativo del l'ultimo thread lanciato (LastStartedAsyncRoutineId( ) e una volta ottenuto l' identificativo del thread è possibile chiedere al sistema sia lo stato che l' ultimo messaggio fornito al sistema dal thread stesso. Per questo si utilizzano due funzioni di sistema: IsAliveAsync(id) e LastMessageAsync(id). La funzione IsAliveAsync(id), che vuole come parametro l'id del thread, è una funzione booleana che indica se il thread è terminato o è ancora in esecuzione. La funzione LastMessageAsync(id), che ha sempre come parametro l'id del thread, ritorna l'ultimo messaggio emesso dal thread con l'istruzione "Mgs" del tool delle routine. Attraverso queste due funzioni è possibile controllare lo stato di avanzamento delle routine eseguite in modo asincrono. Anche in SITEPAINTER Portalstudio nel disegnatore di portlet, l'oggetto SPLinker è stato esteso per supportare l' esecuzione asincrona di qualunque routine. Scegliendo l'opzione "Async routine" la routine viene chiamata server side lanciandola in un nuovo 6 WHAT'S NEW

11 Figura 6 - Un esempio di Timer utilizzato con routine asincrona thread, quindi l'id del thread viene tornato al portlet che la ha invocata. In questo modo il portlet, dopo aver lanciato la routine, riesce a ottenere le informazioni sul come la stessa sta procedendo nell'esecuzione dei propri compiti. Ulteriori dettagli possono essere reperiti nel manuale User's Guide (spr_usg) presente nella directory help del tool. 1.5 Grafici nel report Da questa versione di SITEPAINTER INFINITY sarà possibile aggiungere i grafici all'interno dei report. Utilizzando un file di definizione di un grafico creato tramite il Chart Editor presente nella suite di programmi di SITEPAINTER INFINITY PortalStudio, sarà possibile stampare i grafici, sfruttando una logica simile a quella delle query alternative. Aggiungendo la query utilizzata dal grafico all'elenco delle query presenti nel report, questa sarà disponibile per l'oggetto 'Chart'. A questo punto non si dovrà far altro che specificare la condizione di join con la query principale e quali campi vengono utilizzati dal grafico per averlo a disposizione. WHAT'S NEW 7

12 Figura 7 - L'oggetto 'Chart' all'interno del report 8 WHAT'S NEW

13 Figura 8 - Esempio di stampa in formato pdf 1.6 SPI Portalstudio: Data object e Data Grid server-side Per facilitare l'indicizzazione dei contenuti da parte dei vari motori di ricerca, a partire da questa Build è stata introdotta una nuova modalità per l'estrazione dati dai dataobj (SQLDataobj e XMLDataobj) di SITEPAINTER INFINITY PortalStudio: la modalità "Server-only". Normalmente quando eseguiamo una portlet che contiene un data provider, ccome un Sql Data Object, ed un data consumer, ad esempio una griglia, la portlet viene renderizzata sul client e poi viene utilizzato l'sql Data Object per fornire i dati alla griglia. Questo fa sì che risulti praticamente impossibile indicizzare i contenuti del nostro applicativo. Settando la modalità "Server" sull'sql Data Object, la query viene eseguita server side solo la prima volta che lanciamo la portlet e viene passato un recordset al client in modo che i data consumer presenti nella portlet, tra cui la grid, possano utilizzare i dati. WHAT'S NEW 9

14 Figura 9 - Un esempio della nuova modalità La modalità "Server-only" settata sull'sql Data Object unito al flag 'Server side' sulla griglia, fa invece in modo che la query venga eseguita lato server e la griglia, o meglio tutto l'html necessario, venga prodotto sul server (in modo da poter essere indicizzato) e venga presentato solo dopo averne completato la produzione. 1.7 'Suggest' sui campi linkati Da questa release, a disposizione dell'utente ci sarà un nuovo modo di visualizzazione dei dati all'interno delle gestioni: il "suggest". Sarà sufficiente digitare i primi tre caratteri del testo nella campo linkato per visualizzare automaticamente i primi dieci record che corrispondono a quei valori. 10 WHAT'S NEW

15 Figura 10 - Un esempio di suggest Figura 11 - L'impostazione del suggest assieme alla linked using Per selezionare i valori visualizzati ci si potrà muovere con le frecce e poi confermare premendo "Invio" oppure cliccando con il mouse. L'impostazione del 'suggest' si ottiene semplicemente settando il flag relativo nella maschera di "Edit Field/Variable" ed è principalmente utilizzato in combinazione con il 'Linked using' che ricordiamo, estende le proprietà di ricerca/link anche alle variabili/campi decodificati. I colori e il font del suggest possono essere modificati tramite il SITEPAINTER Skin Editor alla voce 'Field tools' nel paragrafo 'Form'. WHAT'S NEW 11

16 1.8 Portlet inclusi nelle gestioni Figura 12 - Un esempio di page con incluso un portlet con una griglia Una interessante novità della nuova release è la possibilità di includere un portlet creato con SITEPAINTER PortalStudio nelle maschere delle entità prodotte da SITEPAINTER INFINITY. Questa possibilità continua lo sforzo di unione e fusione tra i due strumenti, iniziato con SITEPAINTER INFINITY, e porta anche nello strumento web il modello degli oggettini di CodePainter Client/Server, dove delle classi di MS Visual Foxpro potevano creare piccole componenti da inserire nelle procedure gestionali per specifici compiti che andavano al di la di quello previsto dallo strumento prettamente orientato alle transazioni. Inserire un portlet in una gestione permette di creare oggetti che visualizzano i dati in modo completamente diverso da quello freddo e schematico delle maschere transazionali. E' molto facile creare dei sistemi di visualizzazione che presentano cruscotti, barre, termometri o addirittura grafici, intere griglie o tabelle pivot ricevendo come parametri i dati della parte gestionale. La gestione ed i portlet comunicano attraverso la funzione di calcolo. In tutte le maschere create da SITEPAINTER Infinity ad ogni input da parte dell' utente, dopo aver validato i dati, viene chiamata la funzione (Calculate) che ricalcola tutti gli oggetti calcolati. I portlet inclusi nelle gestioni non sfuggono a questa regola: sono oggetti calcolati, il cui calcolo si basa sulla funzione Calculate scritta nell' Action Code del portlet. 12 WHAT'S NEW

17 Figura 13 - Un esempio della Calculate nel portlet che riceve il parametro dalla page e lancia la query Quindi ad ogni input utente viene chiamata questa funzione, che, ricevendo uno o più parametri dalla maschera, potrà riadattare la visualizzazione per comunicare all'utente i dati ricevuti. WHAT'S NEW 13

18 Figura 14 - La page in sviluppo con incluso in portlet Per poter creare portlet che si prestano ad essere utilizzati in più maschere è possibile passare dei valori di inizializzazione alle variabili del portlet stesso da parte della maschera che lo include. In questo modo il portlet è parametrico e i parametri vengono impostati dalla maschera che lo contiene al momento dell' inclusione. Ulteriori dettagli possono essere reperiti nel manuale User's Guide (spr_usg) presente nella directory help del tool. 1.9 La robustezza delle credenziali Nella nuova release di SITEPAINTER INFINITY sono state fatte parecchie implementazioni volte ad irrobustire il sistema di accesso alle applicazioni. Il sistema, fino alle release precedenti, gestiva le credenziali ponendo l'attenzione soprattutto sugli aspetti prettamente tecnici, attraverso sistemi come il "doppio sale" e gli algoritmi MD5 nella memorizzazione delle password, ora le nuove realizzazioni puntano invece ad evitare gli aspetti "umani" inevitabilmente correlati a questo argomento. Con un esempio chiarificante: se un amministratore di sistema lascia la password vuota anche se viene memorizzata in un modo inattaccabile è comunque molto semplice accedere anche se non si è autorizzati. Il sistema di gestione delle password e degli accessi ora implementa una serie di accorgimenti volti a limitare i problemi che possono derivare da una non corretta gestione al di fuori dell'applicazione stessa di password e profili di accesso e permette di forzare le "buone pratiche". 14 WHAT'S NEW

19 In particolare sono stati implementate le seguenti funzionalità: Complessità della password Età della password Ciclicità della password Livello minimo di robustezza legato al profilo utente Forzatura del cambio password Informazioni di login Captcha Ulteriori dettagli possono essere reperiti nel manuale User's Guide (spr_usg) presente nella directory help del tool Foundling child Figura 15 - La definizione di un Foundling Child Chiamati in gergo 'trovatelli' o 'foundling', sono entità di tipo 'child' di cui l'entità padre non conosce l'esistenza. Questo perché il 'figlio' è presente in un modulo che aggiunge determinate funzionalità al progetto base. Creare questo tipo di entità è molto semplice: si importa nel plan del modulo l'entità padre come 'External entities'. Si aggiunge il trovatello nel plan, operando come nel caso in cui si trattasse di una normale entità 'child', e si imposta il template 'Child Foundling Master entity (MasterFoundlingChild)' o 'Child Foundling Detail entity (DetailFoundlingChild)', a seconda del tipo del trovatello e infine si aggiunge la relazione di tipo 'Parent/Child relationship' tra le due entità, operando nel modo consueto. WHAT'S NEW 15

20 Figura 16 - La definizione di codifica del link sul Foundling Child Si tenga presente che è possibile accedere a quasi tutte le opzioni messe a disposizione dal control 'Link Parent/Child definition' cliccando sul tab 'Foundling Child Option' presente nella dialog 'Global definitions' del menu 'Global' del disegnatore dell'entità. Lì sarà possibile specificare quali campi del padre copiare in quali variabili o campi del trovatello, le condizioni per l'eventuale modifica di tali valori, e la possibilità di specificare il nome del tab in cui sarà presentato il trovatello Dopo il Compile/Deploy, il figlio sarà visualizzato come un tab aggiuntivo nella maschera di inserimento dati del padre. 16 WHAT'S NEW