Richiedi nidificazione e incorporamento request-nesting-and-embedding

Image Server supporta la nidificazione illimitata delle richieste Image Server, l’incorporamento delle richieste Image Rendering e l’incorporamento delle immagini recuperate da server esterni. Solo le immagini e le maschere di livello supportano questi meccanismi.

NOTE
Alcuni client e-mail e server proxy possono codificare le parentesi graffe utilizzate per la sintassi di nidificazione e incorporamento. Le applicazioni per le quali si è verificato un problema devono utilizzare le parentesi anziché le parentesi graffe.

Richieste di Image Server nidificate section-6954202119e0466f8ff27c79f4f039c8

Un'intera richiesta Image Server può essere utilizzata come origine di livello specificandola nella src= (o mask=) utilizzando la sintassi seguente:

…&src=is( nestedRequest)&…

Il is il token distingue tra maiuscole e minuscole.

La richiesta nidificata non deve includere il percorso radice del server (in genere http:// *server*/is/image/').

NOTE
I caratteri delimitatori di richiesta nidificati ( '(',')') e i caratteri delimitatori del comando ( '?', '&', '=') nelle richieste nidificate non deve essere codificato HTTP. Di fatto, le richieste nidificate devono essere codificate come la richiesta esterna (nidificazione).

Le regole di pre-elaborazione vengono applicate alle richieste nidificate.

I seguenti comandi vengono ignorati se specificati nelle richieste nidificate (nell’URL della richiesta o in catalog::Modifier o catalog::PostModifier):

  • fmt=
  • qlt=
  • iccEmbed=
  • printRes=
  • quantize=
  • req=
  • bgc=

Se l'immagine risultante delle richieste nidificate include dati di maschera (alfa), questa viene passata al livello di incorporamento come maschera di livello.

Vengono ignorati anche i attribute::MaxPixe attribute::DefaultPix del catalogo immagini applicabile alla richiesta nidificata.

Il risultato dell'immagine di una richiesta IS nidificata può essere memorizzato nella cache facoltativamente includendo cache=on. Per impostazione predefinita, la memorizzazione nella cache dei dati intermedi è disabilitata. La memorizzazione in cache deve essere abilitata solo quando si prevede che l’immagine intermedia venga riutilizzata in una richiesta diversa entro un periodo di tempo ragionevole. Si applica la gestione della cache lato server standard. I dati vengono memorizzati nella cache in un formato senza perdita di dati.

Richieste di rendering immagini incorporate section-69c5548db930412b9b90d9b2951a6969

Quando Dynamic Medie Image Rendering è abilitato sul server, le richieste di rendering possono essere utilizzate come origini di livello specificandole nel comando src= (o mask=). Utilizza la seguente sintassi:

…&src=ir( *renderRequest*)&…

Il ir il token distingue tra maiuscole e minuscole.

renderRequest è la richiesta di Image Rendering abituale, escluso il percorso root HTTP http:// *server*/ir/render/.

NOTE
I caratteri delimitatori di richiesta nidificati ( '(',')') e i caratteri delimitatori del comando ( '?', '&', '=') nelle richieste nidificate non deve essere codificato HTTP. Di fatto, le richieste incorporate devono essere codificate come la richiesta esterna (incorporante).

I seguenti comandi di Image Rendering vengono ignorati se specificati nelle richieste nidificate:

  • fmt=
  • qlt=
  • icc=
  • iccEmbed=
  • printRes=
  • req=

Vengono ignorati anche i attribute::MaxPix e attribute::DefaultPix del catalogo dei materiali applicabile alla richiesta di rendering nidificata.

Il risultato dell'immagine di una richiesta a infrarossi nidificata può essere memorizzato nella cache facoltativamente includendo cache=on. Per impostazione predefinita, la memorizzazione nella cache dei dati intermedi è disabilitata. La memorizzazione in cache deve essere abilitata solo quando si prevede che l’immagine intermedia venga riutilizzata in una richiesta diversa entro un periodo di tempo ragionevole. Si applica la gestione della cache lato server standard. I dati vengono memorizzati nella cache in un formato senza perdita di dati.

Richieste di rendering FXG incorporate section-c817e4b4f7da414ea5a51252ca7e120a

Quando il renderer grafico FXG (alias AGMServer) è installato e abilitato con Image Server; le richieste FXG possono essere utilizzate come origini di livello specificandole in src= (o mask=). Utilizza la seguente sintassi:

…&src=fxg( renderRequest)&…

Il fxg il token distingue tra maiuscole e minuscole.

NOTE
Il rendering della grafica FXG è disponibile solo nell’ambiente in hosting Dynamic Medie e potrebbe richiedere licenze aggiuntive. Per ulteriori informazioni, contattare il supporto tecnico Dynamic Medie.

renderRequest è la richiesta di rendering FXG usuale, escluso il percorso root HTTP http:// *server*/agm/render/.

NOTE
I caratteri delimitatori ( '(',')') e i caratteri delimitatori del comando ( '?', '&', '=') nelle richieste nidificate non deve essere codificato HTTP. Di fatto, le richieste incorporate devono essere codificate come la richiesta esterna (incorporante).

I seguenti comandi FXG vengono ignorati se specificati nelle richieste nidificate:

  • fmt=
  • qlt=
  • icc=
  • iccEmbed=
  • cache=

Origini immagine esterne section-84e83ecfcd1a43748cdfc7a6f8c04cb8

Image Server supporta l’accesso alle immagini sorgente su server HTTP esterni.

NOTE
Per gli URL remoti è supportato solo il protocollo HTTP.

Per specificare un URL esterno per un src= o un mask= , delimitare l'URL esterno o il frammento di URL tra parentesi:

…&src=( foreignUrl)&…

Importante I caratteri delimitatori ( '(',')') e i caratteri delimitatori del comando ( '?', '&', '=') nelle richieste nidificate non deve essere codificato HTTP. Di fatto, le richieste incorporate devono essere codificate come la richiesta esterna (incorporante).

URL assoluti completi (se attribute::AllowDirectUrls è impostato) e gli URL relativi a attribute::RootUrl sono consentite. Si verifica un errore se è incorporato un URL assoluto e si verifica un attributo: AllowDirectUrls è 0, o se è specificato un URL relativo e attribute::RootUrl è vuoto.

Anche se gli URL esterni non possono essere specificati direttamente nel componente percorso dell’URL della richiesta, è possibile impostare una regola di preelaborazione per consentire la conversione di percorsi relativi in URL assoluti (vedi l’esempio di seguito).

Le immagini esterne vengono memorizzate nella cache dal server in base alle intestazioni di memorizzazione in cache incluse nella risposta HTTP. Se nessuna delle due ETag La risposta non viene memorizzata in cache, poiché non è presente alcuna intestazione di risposta HTTP Last-Modified. Questo può causare prestazioni scadenti per gli accessi ripetuti per la stessa immagine esterna, in quanto Image Server deve recuperare e riconvalidare l’immagine a ogni accesso.

Questo meccanismo supporta gli stessi formati di file immagine supportati dall'utilità di conversione delle immagini (IC), ad eccezione delle immagini sorgente con 16 bit per componente.

NOTE
Image Server esegue automaticamente l'utilità di convalida quando viene utilizzata per la prima volta un'immagine esterna, per garantire che sia valida e non sia danneggiata durante la trasmissione. Questo può causare un leggero ritardo al primo accesso. Per ottenere prestazioni ottimali, si consiglia di limitare le dimensioni di tali immagini e/o utilizzare un formato di file di immagine che comprima bene.

Restrizioni section-fb68e3f0d40947feb94d7bf183b64929

Le dimensioni dell’immagine generata da richieste nidificate/incorporate vengono in genere ottimizzate automaticamente. Se è abilitata la memorizzazione nella cache delle immagini di richiesta nidificate, è possibile ottenere miglioramenti incrementali delle prestazioni specificando la dimensione esatta dell’immagine nidificata, in modo che non sia necessario alcun ulteriore ridimensionamento quando la voce della cache viene riutilizzata.

Il server immagini importanti non supporta la doppia codifica delle richieste nidificate o incorporate. Le richieste nidificate e incorporate devono avere la codifica HTTP proprio come per le richieste semplici.

Esempi section-d800cfc31abe46d2a964f8e7929231f1

Modello di livelli con memorizzazione in cache:

Utilizzare la nidificazione per aggiungere il caching a un modello di layout. Un numero limitato di immagini di sfondo viene sovrapposto a testo altamente variabile. La stringa del modello iniziale potrebbe essere simile alla seguente:

layer=0&src=$img$&size=300,300&layer=1&text=$txt$

Con lievi modifiche, possiamo prescalare l'immagine di livello 0 e memorizzarla nella cache in modo persistente, riducendo così il carico del server:

layer=0&src=is(?src=$img$&size=300,300&cache=on)&layer=1&text=$txt$

Incorporazione di richieste per Dynamic Medie Image Rendering

Utilizzo di un modello memorizzato in myCatalog/myTemplate; genera l’immagine per il livello2 del modello utilizzando Dynamic Medie Image Rendering:

http://server/is/image/myCatalog/myTemplate?layer=2&src=ir(myRenderCatalog/myRenderObject?id=myIdValue&sel=group&src=is(myCatalog/myTexture1?res=30)&res=30)&wid=300

Osserva le parentesi graffe nidificate. La richiesta Image Rendering incorpora una chiamata a Image Server per recuperare una texture ripetibile.

Consultate anche section-109a0a9a3b144158958351139c8b8e69

src= , mask= maschera, PreElaborazione richieste, Riferimento per il rendering delle immagini, Modelli, Utilità Image Server

recommendation-more-help
a26166cd-f2f4-45ce-996d-96a0f0d6cf49