© Copyright International Business Machines Corporation 2006. Tutti i diritti riservati. Limitazioni previste per gli Utenti del Governo degli Stati Uniti - L'uso, la duplicazione o la divulgazione sono limitati dal GSA ADP Schedule Contract con la IBM® Corp.
I seguenti componenti sono obsoleti e se ne sconsiglia l'utilizzo:
- Dati client e la strumentazione associata (quale la vista Dati client)
- Componenti client Faces
<odc:dataGrid>
(Griglia di dati)<odc:webService>
(Servizio Web)<odc:clientData>
<odc:clientBinder>
La struttura ad albero
<odc:tree>
e i grafico<odc:graphDraw>
sono stati abilitati all'utilizzo dei dati server.
Se si importa un'applicazione JSF pre-V7 senza migrare i JAR di JSF e si continua a sviluppare l'applicazione, le nuove tag della V7 non verranno incluse nei JAR del progetto e non saranno disponibili al runtime. Assicurarsi di aver migrato i JAR pre-V7.
La tag
<odc:treeNodeAttr>
di controllo della struttura utilizza diversi valori per il proprio attributo className quando assegnato ai dati SDO contro i dati WDO. Una volta migrato un progetto da un server che utilizza WDO (come WebSphere® Application Server 5.1) ad un server che utilizza SDO (quale WebSphere Application Server 6.1), il modo più semplice per risolvere tale problema è eliminare e ricreare qualsiasi controllo della struttura.
Nella v6.0, se una
<hx:commandExButton>
aveva il tipo impostato su Submit ed aveva un'etichetta e solo un'immagine di sfondo singola (ad esempiovalue="submit" image="button.gif"
), viene effettuato solo il rendering dell'immagine (non dell'immagine e dell'etichetta). Tale problema viene risolto nella v7.0. La correzione consiste nel fatto che viene effettuato il rendering dell'etichetta e dell'immagine singola di sfondo dei pulsanti in maniera diversa durante l'utilizzo della v7.0 rispetto alla v6.0.In maniera simile, se una
<hx:commandExButton>
ha il tipo impostato suReset
ed ha un'immagine di sfondo singola (o un'immagine di sfondo e un'etichetta), verrebbe eseguito il rendering solo dell'immagine ed il pulsante verrebbe trattato come un pulsante di inoltro (il tipo di pulsante è stato ignorato). Tale problema viene risolto nella v7.0. La correzione consiste nel fatto che i pulsanti contrassegnati con il tipo impostato suReset
reimposterà la pagina invece di inoltrarla.
Gli attributi della tag
<jspPanel>
style
estyleClass
non sono più disponibili. Gli attributi non vengono utilizzati per la resa dei componenti del pannello JSP.Se si importa un'applicazione JSF creata in una versione precedente di questo prodotto, le tag di
<jspPanel>
visualizzeranno degli errori. Per risolvere gli errori, rimuovere gli attributistyle
estyleClass
da tutte le tag<jspPanel>
nel progetto, modificando l'origine JSP nella vista Origine.
Se si importano dei progetti nel proprio spazio di lavoro, creati utilizzando una versione precedente del prodotto, potrebbe essere visualizzata una finestra di dialogo nella quale si avvisa che il supporto Faces è stato installato ma non è stato selezionato alcun runtime di destinazione per il progetto. In alcuni casi tale avvertenza non è precisa ed un runtime verrà definito una volta terminato il processo di migrazione. Per verificare se un runtime è stato configurato fare clic con il tasto destro del mouse Progetto > Proprietà e selezionare Runtime di destinazione. Se appare una casella di spunta affianco a tutti i server definiti, allora non sono richieste azioni aggiuntive, altrimenti selezionare uno dei server.
Nota: tale soluzione temporanea non è richiesta dove i modelli dei dati del client vengono creati dallo stesso nodo dei dati della pagina o dai nodi dei dati della pagina dello stesso nome.
Nella v7.0, dove vi sono più modelli dati client sulla pagina, creata dalle stesse classi bean, un secondo file ecore e emap verranno creati erroneamente per il secondo modello dopo la generazione (o rigenerazione). In conformità alla guida alla migrazione, durante la migrazione dei progetti dati client, i modelli dati client devono essere rigenerati in maniera tale che vadano ad impattare i progetti migrati con le pagine contenenti più di un modello dati client. Quello che segue è un semplice scenario:
- Creare due dati pagine in base al bean java.util.Date, ad esempio myDate1 e myDate2.
- Per ciascuno dei dati pagine, creare un modello dati client dello stesso nome nel seguente ordine: myDate1 poi myDate2.
Soluzione temporanea: perché una pagina funzioni con entrambi i modelli, eliminare myDate2.ecore e myDate2.emap dal pacchetto com.ibm.dynwdo4jsmediators e la voce corrispondente nel file OdysseyBrowserFramework.properties file.
I dati client emettono una grande quantità di JavaScript™ su una pagina. Nei precedenti rilasci il JavaScript non era codificato. Ciò significava che se si utilizzavano i dati client in più portlet, che utilizzavano la stessa origine dati pagina, l'output del JavaScript sulla pagina sarebbe stato lo stesso per tutti i portlet.
Tale funzionamento, dove due portlet sono associati ai dati client, potrebbero dare l'impressione di essere associati allo stesso oggetto dati client (mentre la seconda sezione di JavaScript sovrascriverà la prima). A sua volta consente ai due portlet di interagire, dove una modifica in uno dei due, verrebbe rappresentata in entrambi.
Ciò potrebbe risultare problematico se si desidera avere più portlet su una pagina che utilizza i dati client che funzionano in maniera indipendente gli uni dagli altri. Gli errori di JavaScript si verificano quando due portlet utilizzano i dati client sulla stessa pagina con origini dati della pagina diversi. Inoltre può far si che uno dei portlet non esegua il rendering.
Per risolvere tali problemi e consentire ai portlet dati client di essere eseguiti su WSRP, le variabili di JavaScript dei dati client devono essere codificate, così che siano univoche per ciascun portlet. Questo consente alle sezione di JavaScript dei dati client di funzionare indipendentemente gli uni dagli altri.
Nella V7.0, tutti i dati client verranno codificati.
Se si desidera condividere i dati client tra i portlet su una pagina, sarà necessario aggiornare il file web.xml con i seguenti parametri di contesto:
<context-param>
<param-name>com.ibm.faces.ENCODE_DATA</param-name>
<param-value>false</param-value>
<description></description>
</context-param>Impostando <param-value> su false, si rimuoverà la codifica dei dati client.
Utilizzando il parametro Encode_Data ed il suo effetto sui componenti Grafico e Struttura dati che utilizzano i dati pagina
Il Grafico e la Struttura dati utilizzano i dati della pagina immettendo un oggetto dati XML sulla pagina. I dati della pagina per il Grafico e la Struttura dati è fortemente collegata ai dati client per tali componenti. Per impostazione predefinita, tali dati vengono codificati. Se si imposta il parametro <context-param> visualizzato in basso nel file web.xml, solitamente utilizzato per rimuovere la codifica dei dati client, rimuoverà anche la codifica dei dati della pagina per il Grafico e la Struttura dati. Non verrà coinvolto nessun altro componente che utilizza i dati della pagina . Lasciando i dati pagina senza la codifica, si avranno due portlet su una pagina, dove entrambi contengono un Grafico e una Struttura dati, si potrebbero verificare dei problemi. Tali errori includono gli errori di JavaScript e/o uno dei portlet che non viene visualizzato correttamente.
Come per i dati client per codificare tali dati, consentendo ai due portlet su una pagina di essere eseguiti in maniera indipendente l'uno dall'altro e per abilitare il supporto WSRP, sarà necessario rimuovere il seguente parametro <context-param> dal file web.xml oppure impostare il parametro <param-value> su true:
<context-param>
<param-name>com.ibm.faces.ENCODE_DATA</param-name>
<param-value>true</param-value>
<description></description>
</context-param>
Si trova in cima alla pagina:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Questo fa si che i browser Web passino in modalità standard. In modalità standard, gli elementi
HTML
ebody
vengono agganciati ai loro contenuti piuttosto che riempire la finestra come accade in modalità quirks (la modalità HTML è quella predefinita).Quando un pannello a schede viene immesso nella pagina da solo, con la propria altezza impostata su una percentuale, provocherà dei problemi di visualizzazione con l'altezza del pannello.
Per risolvere tale problema, immettere il pannello a schede in un contenitore che abbia un'altezza impostata o modificare il doctype in cima alla pagina su:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Vi sono dei problemi di visualizzazione con le schede in modalità standard quando il doctype viene impostato su:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Questa procedura viene rettificata modificando il doctype su:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
La tag
<hx:convertDateTime>
non genera un JavaScript corretto quando il tipo di calendario viene impostato su arabo. Come risultato, la convalida dal lato client, la richiesta di input, l'helper per la scelta della data e il mini calendario non funzionano correttamente. Quando viene inizializzato lo JavaScript, viene visualizzato un errore (oppure il componente non funziona correttamente).Soluzione temporanea: non attivare la convalida o la richiesta lato client. Non attivare l'helper per la scelta della data se il calendario arabo viene utilizzato con il convertitore.
Quando viene indirizzato un runtime del server WebSphere®, verificare che il face del progetto Web WebSphere (Co-esistenza) sia stato selezionato per il proprio progetto Web.
Soluzione temporanea: selezionare il facet sulla seconda pagina della procedura guidata Progetto Web dinamico durante la creazione del progetto, oppure tramite la pagina Facet del progetto della finestra di dialogo Proprietà del progetto se questi già esiste. Durante la creazione di un progetto Web indirizzato su un server WebSphere, se si seleziona "Progetto Faces" o "Progetto Web dinamico con XDoclet" dall'elenco a discesa Configurazioni sulla prima pagina della procedura guidata, il facet Web WebSphere (Co-esistenza) non verrà selezionato automaticamente. È possibile continuare alla seconda pagina della procedura guidata per selezionare tale facet. Se si seleziona "<personalizzata>" dall'elenco a discesa Configurazioni, il facet verrà selezionato correttamente durante l'indirizzamento ad un runtime di WebSphere.
Quando si utilizza un
<hx:columnEx>
all'interno di un<hx:dataTableEx>
e lo scorrimento verticale è stato abilitato (scrollSize è stato impostato), se una o più colonne nella tabella hanno la loro ampiezza impostata perché sia un'ampiezza basata sulla percentuale, nella tabella resa, le intestazioni delle colonne e i contenuti delle colonne potrebbero non essere allineati tra di loro se il doctype della pagina viene interpretato dal browser come se fosse un W3C standard (contro un W3C tradizionale). Ad esempio, ciò accadrebbe se il doctype include una dichiarazione diloose.dtd
.
Soluzione temporanea: rendere fisse le ampiezze delle colonne (non basate sulla percentuale) oppure verificare che il doctype venga risolto in un doctypedi transizione
(ad esempio rimuovere la dichiarazione di loose.dtd).
In un
<hx:panelDialog>
, se il posizionamento (orizzontale o verticale) è stato impostato surelative
e la tag utilizzata come base per il posizionamento (ovvero la tag a cui fa riferimento la relativa finestra di dialogo) si trova in una pagina che è possibile far scorrere in maniera tale che la tag venga visualizzata e la pagina non viene fatta scorrere verso l'alto, quando la finestra di dialogo viene visualizzata, potrebbe non essere stata posizionata correttamente (solitamente troppo lontano dalla parte alta o troppo lontano dalla sinistra).Soluzione temporanea: se viene richiesto il posizionamento relativo viene richiesto, verificare che la tag di base sia vicino alla parte alta della pagina. In alternativa, utilizzare uno degli altri tipi di posizionamento.
Se una tabella dati (
<h:dataTable>
o<hx:dataTableEx>
) si trova in un pannello attivato da AJAX e la selezione è stata abilitata (<hx:inputRowSelect>
viene inclusa nella tabella), le caselle di spunta nella colonna di selezione non funzioneranno correttamente quando la tabella viene recuperata tramite AJAX. Funzioneranno (solo) la prima volta che verrà effettuato il rendering.Soluzione temporanea: attualmente, non esiste alcuna soluzione per questo problema. Non immettere la tabella nel pannello attivato da AJAX.
<hx:ajaxExternalRequest>
potrebbe non funzionare correttamente in Internet Explorer se l'attributo di origine utilizzato per specificare l'ID del pannello, perché venga richiamato nella pagina di destinazione, non corrisponde all'ID del pannello a cui<hx:ajaxExternalRequest>
è collegato nella pagina di origine. Ad esempio,<hx:panel id="panel1"><hx:ajaxExternalRequest source="panel999" /><hx:panel>
. Il problema si verifica solo in IE e solo se il pannello di destinazione è una griglia, una casella o un layout (un pannello che viene reso come una tabella HTML).Soluzione temporanea: verificare che gli ID siano gli stessi oppure includere il pannello in un gruppo di pannelli.
L'attributo
inProgresss
per<hx:ajaxRefreshRequest>
,<hx:ajaxRefreshSubmit>
,<hx:ajaxExternalRequest>
e<hx:inputHelperTypeahead>
non funziona. L'impostazione di un valore su tale attributo non ha alcun effetto. Per assicurare una compatibilità con rilasci futuri, non impostare il valore.
Quando
<hx:inputHelperTypeahead>
viene collegato al campo di immissione, se viene immesso uno spazio e/o dei caratteri di punteggiatura come la "e" commerciale (&), il simbolo percentuale (%) nel campo, l'elenco di suggerimenti costruiti non comprenderà alcuna "corrispondenza" che includa tali caratteri. Ad esempio, se un utente immette %, non verrà restituita alcuna corrispondenza anche se vi sono parole nel "dizionario" in uso che inizi con %.
Una modifica nel funzionamento di alcuni attributi DOM di HTML, a partire da Firefox Versione 1.5.0.8, può consistere in una
finestra di dialogo
non posizionata correttamente quando ne viene effettuato il rendering. Il problema più comune si verifica quando una finestra di dialogo viene posizionata relativamente, ma si può verificare in altri casi dove le dimensioni del contenuto del corpo sono "inferiori" all'altezza della finestra del browser (vale a dire, quando la pagina non scorre verticalmente).Soluzione temporanea: aggiungendo del contenuto al corpo (persino lo spazio vuotoquale <div> con l'altezza impostata) come la barra di scorrimento verticale sempre attiva sulla pagina, potrebbe risolvere il problema (questo dipende dalle dimensioni esatte della finestra di browser e dal contenuto).
<hx:pagerDeluxe>
non effettua il rendering della markup HTML corretta se la styleClass è stata impostata su qualche valore diverso dalla classe predefinitapagerDeluxe
. Verrà sempre eseguito il redering dei pulsanti nel pager con i nomi delle classi che comprendono il nome classe predefinito.Soluzione temporanea:
- Non modificare il nome classe in un valore diverso da pagerDeluxe.
- Rettificare il CSS utilizzato per per prendere in considerazione i nomi delle classi per i quali è stato effettuato il rendering sui pulsanti se viene utilizzato un nome classe diverso.