© 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 IBM Corp.
I seguenti componenti sono obsoleti e se ne sconsiglia l'utilizzo:
- Dati client e strumentazione associata (ad esempio vista Dati client)
- Componenti client Faces
<odc:dataGrid>
(griglia dati)<odc:webService>
(servizio Web)<odc:clientData>
<odc:clientBinder>
La Struttura ad albero
<odc:tree>
e il Grafico<odc:graphDraw>
sono stati abilitati all'utilizzo dei dati del server.
Se viene importata un'applicazione JSF antecedente a V7 senza migrare i JAR JSF e si continua a sviluppare l'applicazione, i nuovi tag in V7 non verranno inclusi nei JAR del progetto e non saranno disponibili al runtime. Accertarsi di aver migrato i JAR antecedenti a V7.
Il tag di controllo della Struttura ad albero
<odc:treeNodeAttr>
utilizza valori differenti per l'attributo className quando associato a dati SDO e non a dati WDO. Dopo la migrazione di un progetto da un server che utilizza WDO (ad esempio WebSphere® Application Server 5.1) a un altro server che utilizza SDO (ad esempio WebSphere Application Server 6.1), la maniera più semplice per correggere tale problema è eliminare e creare nuovamente tutti i controlli della Struttura ad albero.
In v6.0, se
<hx:commandExButton>
aveva il tipo impostato su Inoltra e aveva un'etichetta e una sola immagine di sfondo (ad esempiovalue="submit" image="button.gif"
), veniva effettuato solo il rendering dell'immagine (non dell'immagine e dell'etichetta). Questo problema è stato corretto in v7.0. Con la correzione il pulsante che ha sia un'etichetta che una sola immagine di sfondo effettuerà il rendering in maniera differente utilizzando v7.0 rispetto alla v6.0.Analogamente, se
<hx:commandExButton>
aveva il tipo impostato suReset
e aveva una sola immagine di sfondo (o un'immagine di sfondo e un'etichetta), veniva effettuato solo il rendering dell'immagine e il pulsante veniva gestito come un pulsante di inoltro (il tipo di pulsante veniva ignorato). Questo problema è stato corretto in v7.0. Con la correzione i pulsanti contrassegnati con il tipo impostato suReset
attualmente reimpostano la pagina invece di inoltrarla.
Gli attributi del tag
<jspPanel>
style
estyleClass
non sono più disponibili. Gli attributi non vengono utilizzati per effettuare il rendering dei componenti del pannello JSP.Se viene importata un'applicazione JSF creata in una versione precedente del prodotto, i tag
<jspPanel>
visualizzeranno degli errori. Per risolvere gli errori, rimuovere gli attributistyle
estyleClass
da tutte i tag<jspPanel>
nel progetto, modificando l'origine JSP nella vista Origine.
Se nello spazio di lavoro vengono importati progetti creati utilizzando una versione precedente del prodotto, potrebbe essere visualizzata una finestra di dialogo a comparsa indicante che il supporto Faces è stato installato ma per il progetto non è stato selezionato alcun runtime di destinazione. In alcuni casi questo avviso non è preciso e al termine del processo di migrazione un runtime verrà definito correttamente. Per verificare se viene impostato un runtime fare clic con il pulsante destro del mouse su Progetto > Proprietà e selezionare Runtime di destinazione. Se viene visualizzata una casella di controllo accanto a un server definito, non è necessario alcun intervento, altrimenti scegliere uno dei server.
Nota: questa soluzione temporanea non è necessaria se i modelli di dati client vengono creati dallo stesso nodo di dati di pagina o dai nodi di dati di pagina con lo stesso nome.
In v7.0, quando vi sono più modelli di dati client nella pagina, creati dalle stesse classi di bean, verrà erroneamente creato un secondo file emap ed ecore per il secondo modello in fase di generazione (o rigenerazione). Conformemente alla guida alla migrazione, quando viene effettuata la migrazione di progetti di dati client, i modelli di dati client devono essere rigenerati, in modo che ciò possa aver effetto sui progetti migrati con pagine contenenti più di un modello di dati client. Uno scenario semplice è il seguente:
- Creare due dati di pagina in base al bean java.util.Date, ad esempio myDate1 e myDate2.
- Per entrambi i dati di pagina creare un modello di dati client con lo stesso nome nell'ordine: myDate1 e myDate2.
Soluzione temporanea: perché una pagina funzioni con entrambi i modelli, eliminare myDate2.ecore e myDate2.emap dal pacchetto com.ibm.dynwdo4jsmediators e le voci corrispondenti nel file OdysseyBrowserFramework.properties.
I dati client estraggono una grande quantità di JavaScript™ in una pagina. Nei precedenti rilasci JavaScript non era codificato. Ciò implicava che se venivano utilizzati dati client in più portlet, usando la stessa origine di dati di pagina, l'output JavaScript per la pagina doveva essere il medesimo per tutti i portlet.
Questo comportamento, in cui due portlet vengono associati a dati client, parrebbe eseguire un'associazione allo stesso oggetto dati client (poiché la seconda sezione di JavaScript verrà sovrapposta alla prima). Ciò consente ai due portlet di interagire a turno, ove una modifica nell'uno viene rappresentata in entrambi.
Ciò costituisce un problema se si desidera avere più portlet in una pagina che utilizzano dati client funzionanti in maniera indipendente tra loro. Quando si hanno due portlet che utilizzano dati client nella stessa pagina con origini di dati di pagina differenti, si verificano errori JavaScript. Per tale motivo potrebbe non essere effettuato il rendering di uno dei portlet.
Per correggere tali problemi e consentire l'esecuzione di portlet di dati client su WSRP, le variabili JavaScript dei dati client devono essere codificate in modo che risultino univoche per ciascun portlet. Ciò consente il funzionamento indipendente delle sezioni JavaScript dei dati client.
In V7.0, tutti i dati client saranno codificati.
Se si desidera condividere dati client tra portlet in 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, la codifica dei dati client viene rimossa.
Utilizzo del parametro Encode_Data e relativo effetto sui componenti Grafico e Struttura dati utilizzando i dati di pagina
Il Grafico e la Struttura dati utilizzano dati di pagina collocando un oggetto dati XML nella pagina. I dati di pagina per Grafico e Struttura dati sono strettamente collegati ai dati client di tali componenti. Per impostazione predefinita tali dati sono codificati. Se viene impostato <context-param> visualizzato al di sotto del file web.xml, generalmente utilizzato per rimuovere la codifica di dati client, verrà rimossa anche la codifica dei dati di pagina per il Grafico e la Struttura dati. Ciò non avrà effetto su altri componenti che utilizzano dati di pagina. Lasciare i dati di pagina senza codifica, avendo cioè due portlet in una pagina entrambi contenenti un grafico o una struttura dati, può causare problemi. Tali errori includono errori JavaScript e/o la visualizzazione di uno dei portlet in maniera non corretta.
Come con i dati client per la codifica di tali dati, che consentono l'esecuzione indipendente di due portlet in una pagina e l'abilitazione del supporto WSRL, sarà necessario rimuovere il seguente <context-param> dal file web.xml o impostare <param-value> su true:
<context-param>
<param-name>com.ibm.faces.ENCODE_DATA</param-name>
<param-value>true</param-value>
<description></description>
</context-param>
Nella parte superiore della pagina viene visualizzato quanto segue:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Ciò causa il funzionamento dei browser Web in modalità standard. In modalità standard, gli elementi
HTML
ebody
si agganciano ai loro contenuti invece di riempire la finestra come in modalità quirks (la modalità HTML predefinita).Quando un pannello a schede viene collocato nella pagina in maniera autonoma con un'altezza impostata in percentuale, si verificheranno problemi di visualizzazione con l'altezza del riquadro.
Per correggere tale errore, collocare il pannello a schede in un contenitore con un'altezza impostata o modificare il doctype nella parte superiore della pagina come di seguito indicato:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Esistono problemi di visualizzazione con le schede in modalità standard quando il doctype è impostato su:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Ciò viene rettificato modificando il doctype come segue:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Il tag
<hx:convertDateTime>
non genera un JavaScript corretto quando il tipo di calendario è impostato su Arabo. Di conseguenza, la convalida lato client, la richiesta di input, l'helper di scelta data e il mini-calendario non funzionano correttamente. Quando viene inizializzato il JavaScript generato, viene visualizzato un errore (o il componente non funziona correttamente).Soluzione temporanea non attivare la convalida lato client o la richiesta di input. Non attivare l'helper di scelta data se viene utilizzato il calendario arabo con il converter.
Impostando la destinazione del runtime di un server WebSphere®, accertarsi che sia selezionato il facet del progetto Web WebSphere (coesistenza) per il progetto Web.
Soluzione temporanea: selezionare il facet nella seconda pagina della procedura guidata Progetto Web dinamico quando viene creato il progetto, o tramite la pagina Project Facet della finestra di dialogo Proprietà del progetto se il progetto esiste già. Quando viene creato un progetto Web con destinazione impostata su un server WebSphere, se viene selezionato "Progetto Faces" o "Progetto Web dinamico con XDoclet" dall'elenco a discesa Configurazioni nella prima pagina della procedura guidata del progetto, il facet Web WebSphere (coesistenza) non verrà selezionato automaticamente. È possibile continuare con la pagina successiva della procedura guidata per selezionare tale facet. Se viene selezionato "<personalizzata>" dall'elenco Configurazioni, il facet verrà correttamente selezionato quando verrà impostata la destinazione di un runtime WebSphere.
Quando viene utilizzato
<hx:columnEx>
in<hx:dataTableEx>
ed è abilitato lo scorrimento verticale (scrollSize impostato), se la larghezza di una o più colonne nella tabella è impostata in percentuale, nel rendering della tabella le intestazioni di colonna e i contenuti della colonna potrebbero non essere allineati tra loro se il doctype della pagina viene interpretato dal browser come W3C standard (e non W3C transitional). Ciò si verificherà, ad esempio, se il doctype include una dichiarazioneloose.dtd
.
Soluzione temporanea: impostare la larghezza delle colonne su un valore fisso (non in percentuale) o accertarsi che il doctype venga risolto in un doctypetransitional
(rimuovendo, ad esempio, la dichiarazione loose.dtd).
In
<hx:panelDialog>
, se il posizionamento (orizzontale o verticale) viene impostato surelative
e il tag utilizzato come base per il posizionamento (tag rispetto a cui è posizionata la finestra di dialogo) è in una pagina in cui viene effettuato lo scorrimento in modo tale che il tag venga visualizzato e non venga effettuato lo scorrimento della pagina verso l'alto, quando la finestra di dialogo viene visualizzata potrebbe essere posizionata in maniera non corretta (in genere troppo in alto o troppo a sinistra).Soluzione temporanea: se è necessario il posizionamento relativo, accertarsi che il tag di base si trovi verso la parte superiore della pagina. In alternativa, utilizzare altri tipi di posizionamento.
Se una tabella dati (
<h:dataTable>
o<hx:dataTableEx>
) si trova in un pannello con AJAX abilitato e con la selezione della riga abilitata (<hx:inputRowSelect>
è incluso nella tabella), le caselle di controllo nella colonna di selezione non funzioneranno correttamente quando la tabella viene richiamata tramite AJAX. Solo la prima volta che verrà effettuato il rendering di questa tabella questa funzionerà.Soluzione temporanea: per questo problema non esiste ancora una soluzione temporanea. Non collocare la tabella in un pannello con AJAX abilitato.
<hx:ajaxExternalRequest>
potrebbe non funzionare correttamente in IE (Internet Explorer) se l'attributo di origine utilizzato per specificare l'ID del pannello da richiamare nella pagina di destinazione è diverso dall'ID del pannello a cui è collegato<hx:ajaxExternalRequest>
nella pagina di origine. Ad esempio,<hx:panel id="panel1"><hx:ajaxExternalRequest source="panel999" /><hx:panel>
. Il problema si verifica solo in IE e se il pannello di destinazione è una griglia, una casella o un layout (un pannello reso come una tabella HTML).Soluzione temporanea: accertarsi che gli ID siano gli stessi o suddividere il pannello di destinazione in un panelGroup.
L'attributo
inProgress
per<hx:ajaxRefreshRequest>
,<hx:ajaxRefreshSubmit>
,<hx:ajaxExternalRequest>
e<hx:inputHelperTypeahead>
non funziona. L'impostazione di un valore per questo attributo non ha effetto. Per essere certi della compatibilità con i rilasci futuri, non impostare alcun valore.
Quando
<hx:inputHelperTypeahead>
viene collegato a un campo di input, se nel campo viene immesso un carattere spazio e/o caratteri di punteggiatura quali E commerciali e percentuali, l'elenco di suggerimenti che viene costruito non includerà alcuna "corrispondenza" che comprenda tali caratteri. Ad esempio, se l'utente immette %, non verrà restituita alcuna corrispondenza, anche se nel "dizionario" utilizzato esistono parole che cominciano con %.
Una modifica nel comportamento di alcuni attributi DOM HTML iniziali in Firefox versione 1.5.0.8 possono causare il posizionamento di
panelDialog
non corretto quando viene effettuato il rendering in Firefox. Il problema si verifica più comunemente quando una finestra di dialogo viene posizionata in maniera relativa, ma può verificarsi in altri casi, se la dimensione del contenuto del corpo è "minore" dell'altezza della finestra del browser (cioè quando la pagina non scorre verticalmente).Soluzione temporanea: l'aggiunta di contenuto al corpo (anche spazio vuoto, ad esempio <div> con l'altezza impostata) in modo tale che venga visualizzata la barra di scorrimento verticale nella pagina può costituire una soluzione temporanea del problema (a seconda delle esatte dimensioni della finestra del browser e del contenuto).
<hx:pagerDeluxe>
non effettua correttamente il rendering della markup HTML se styleClass è impostato su una classe diversa da quella predefinita,pagerDeluxe
. Il rendering dei pulsanti nel pager verrà sempre effettuato con nomi di classi che utilizzano il nome classe predefinito.Soluzione temporanea:
- Non modificare il nome classe pagerDeluxe.
- Se viene utilizzato un nome classe differente, regolare il CSS utilizzato tenendo conto dei nomi di classi di cui viene effettuato il rendering sui pulsanti.