Utilizzo di controlli server ASP.NET in applicazioni Web part

Articolo
10/22/2014

Aggiornamento: novembre 2007

In un'applicazione Web part, l'interfaccia utente primaria è costituita da controlli server ASP.NET che risiedono in aree (regioni) di una pagina Web con un'interfaccia utente comune e che vengono create da un tipo di controllo composito derivato dalla classe WebPartZoneBase. Le funzionalità dei controlli server che compongono l'interfaccia utente primaria di un'applicazione Web part sono definite nella classe base WebPart, ma possono essere utilizzati anche altri controlli oltre a quelli che derivano da tale classe. È possibile utilizzare qualsiasi controllo server personalizzato, controllo utente o controllo server ASP.NET standard. In questo argomento vengono trattati alcuni problemi relativi all'utilizzo dei controlli server nelle applicazioni Web part quando i controlli non ereditano dalla classe WebPart.

Creazione di controlli Web part in fase di esecuzione

Per i vari tipi di controlli server che non ereditano dalla classe WebPart, l'insieme dei controlli Web part fornisce un meccanismo che permette di inserirli nelle applicazioni Web part e di disporre delle stesse funzionalità offerte dai controlli derivati dalla classe WebPart. A tale scopo non è richiesta alcuna operazione speciale da parte degli sviluppatori, in quanto è sufficiente aggiungere un controllo server in un'area WebPartZoneBase. Quando una pagina Web viene compilata, qualsiasi controllo server presente in un'area che non eredita dalla classe WebPart viene automaticamente incapsulato in un'istanza della classe GenericWebPart e diventa un controllo figlio di tale istanza. Poiché la classe GenericWebPart eredita dalla classe WebPart, il controllo server dispone ora di tutte le funzionalità di un controllo WebPart. In pratica, i controlli server che non ereditano dalla classe WebPart aggiunti in un'area WebPartZoneBase diventano controlli WebPart in fase di esecuzione.

Nota:
I controlli WebPart possono essere utilizzati all'esterno di applicazioni Web part come i controlli server possono essere utilizzati nelle applicazioni Web part. Se si aggiunge un controllo che eredita dalla classe WebPart in una pagina all'esterno di un'area, questo funziona come un normale controllo server senza le funzionalità Web part.

Aggiunta dei controlli server ASP.NET alle aree

Quando si aggiungono controlli personalizzati, controlli utente o controlli server ASP.NET in un'area WebPartZoneBase non sono richieste speciali tecniche o dichiarazioni nella pagina. È possibile aggiungerli in un'area come se si aggiungesse un normale controllo in una pagina Web, ovvero in modo dichiarativo, nel formato di persistenza pagina, o a livello di codice. È inoltre possibile utilizzare la funzionalità di catalogo Web part che consente di aggiungere controlli server in un catalogo che l'utente può utilizzare per selezionare e aggiungere i controlli nella pagina in fase di esecuzione. Per ulteriori informazioni, vedere i controlli DeclarativeCatalogPart e ImportCatalogPart.

Per aggiungere un controllo server in un'area a livello di codice, si consiglia di utilizzare il metodo AddWebPart del controllo WebPartManager.

Quando si aggiungono controlli server che non sono controlli WebPart in modo dichiarativo in un'area, se si utilizza uno strumento di progettazione visiva come Microsoft Visual Studio 2005, i membri e le proprietà WebPart non saranno visibili nel pannello delle proprietà o in IntelliSense. Per ulteriori informazioni, vedere la sezione successiva in cui viene spiegato quando utilizzare i controlli WebPart invece di altri controlli server.

Scelta tra le diverse opzioni dei controlli server

Poiché è possibile utilizzare qualsiasi tipo di controllo server in un'applicazione Web part, è legittimo chiedersi se esista una ragione per decidere di creare un controllo che derivi dalla classe WebPart.

I fattori chiave da prendere in considerazione sono i vantaggi derivanti dall'adattamento dei controlli server preesistenti rispetto alla creazione di nuovi controlli derivandoli dalla classe WebPart. Le linee guida seguenti sono di ausilio nella decisione.

Utilizzo di controlli server

In molti casi è meglio creare controlli Web part utilizzando un controllo personalizzato, un controllo utente o un controllo server ASP.NET, specialmente se tale controllo è già disponibile. Con questo tipo di controlli server non si perde alcuna funzionalità Web part in fase di esecuzione, mentre si ottengono diversi vantaggi quali la possibilità di riutilizzare il codice esistente e di sfruttare le proprie conoscenze di sviluppo di controlli per applicarle alle applicazioni Web part.

È inoltre possibile fare in modo che il comportamento dei controlli server sia identico a quello dei controlli WebPart implementando le varie interfacce della classe WebPart, tra cui:

Se si implementa l'interfaccia IWebActionable, è possibile aggiungere verbi personalizzati al relativo menu del controllo, ossia azioni comuni che gli utenti possono eseguire su un controllo nell'interfaccia utente, come la riduzione a icona, la chiusura o la modifica.
Se si implementa l'interfaccia IWebEditable, è possibile associare i controlli EditorPart personalizzati al controllo server, permettendo agli utenti di modificare determinate proprietà personalizzate e il comportamento del controllo in fase di esecuzione.
Se si implementa l'interfaccia IWebPart, il controllo disporrà di alcune delle proprietà di un controllo WebPart che vengono ereditate dalla classe Part, fornendo lo stesso aspetto e comportamento di un controllo WebPart anche in fase di progettazione.

Derivazione dalla classe WebPart

La creazione di un controllo derivandolo dalla classe WebPart offre come vantaggio principale la possibilità di esercitare pieno controllo sul comportamento specifico delle Web part.

Ciò risulta utile ad esempio se uno sviluppatore di controlli desidera modificare il comportamento di un controllo in fase di esecuzione e quindi ridistribuirlo agli utenti. In questo caso lo sviluppatore può eseguire l'override di una delle proprietà virtuali della classe WebPart, ad esempio AllowClose, e renderla una proprietà di sola lettura che restituisce sempre false per impedire agli utenti di chiudere il controllo ed essere quindi limitati da tale comportamento.

Un secondo vantaggio che si ottiene ereditando dalla classe WebPart è relativo al comportamento in fase di progettazione. In un controllo WebPart tutti i membri WebPart esposti sono visibili agli sviluppatori delle pagine in fase di progettazione tramite IntelliSense (se viene utilizzato uno strumento di progettazione visiva come Microsoft Visual Studio 2005), consentendo loro di utilizzare le proprietà in modo dichiarativo nel pannello Proprietà. Se invece in fase di progettazione in un'area si dichiarano controlli server che non sono controlli WebPart, non sarà possibile vedere alcun membro specifico della classe WebPart in IntelliSense o nel pannello Proprietà, anche se sarà comunque possibile dichiararlo. Questo comportamento è dovuto al fatto che in fase di progettazione un controllo server ordinario non è stato ancora incapsulato in un oggetto GenericWebPart e quindi non dispone delle funzionalità WebPart che avrà in fase di esecuzione. Sebbene sia possibile attivare i controlli server per ottenere un aspetto e un comportamento simili ai controlli WebPart tramite l'implementazione delle interfacce elencate in precedenza, spesso è più semplice creare un controllo WebPart. Gli sviluppatori e i fornitori di controlli che creano package di controlli possono sfruttare l'utilizzo della classe WebPart per dotare i controlli di funzionalità più avanzate in fase di progettazione.

Conclusioni

In conclusione, se non è necessario eseguire l'override delle proprietà standard dei controlli, è più pratico utilizzare i controlli server preesistenti e inserirli nel controllo WebPart.

Se si decide di creare un controllo WebPart personalizzato, è potenzialmente possibile eseguire l'override delle proprietà seguenti:

Controlli utente come controlli WebPart

I controlli utente costituiscono un'ottima scelta per gli sviluppatori ASP.NET in quanto consentono di generare rapidamente un'interfaccia utente complessa per un controllo utilizzando la stessa sintassi dichiarativa delle pagine Web e forniscono un modo conveniente per dividere e riutilizzare il codice in più pagine. Come i controlli server ASP.NET, anche i controlli utente possono essere utilizzati in applicazioni Web part. I controlli utente possono essere aggiunti direttamente in un'area WebPartZoneBase e funzioneranno come controlli WebPart in fase di esecuzione, come descritto in precedenza. Possono inoltre essere utilizzati con la funzionalità di catalogo Web part, sia come controlli da importare, sia per creare package di altri controlli server che gli utenti possono selezionare e aggiungere in una pagina. Per ulteriori informazioni, vedere la proprietà WebPartsListUserControlPath.

Nota importante:
È necessario tenere presente che la memorizzazione nella cache di output ASP.NET è disattivata per i controlli utente utilizzati come controlli WebPart in fase di esecuzione. L'insieme di controlli Web part richiede che un controllo sia presente nella struttura dei controlli per ciascuna richiesta inviata a una pagina. Ciò è necessario per utilizzare determinate funzionalità Web part, ad esempio la personalizzazione. Per ulteriori informazioni, vedere Cenni preliminari sulla personalizzazione di Web part. Poiché per le richieste in cui un controllo utente viene memorizzato nella cache (per ulteriori informazioni, vedere la direttiva @ OutputCache) il controllo non viene aggiunto alla struttura dei controlli, la memorizzazione nella cache di output non è compatibile con le funzionalità Web part e non può essere utilizzata con controlli utente che operano come WebPart in un'applicazione Web part.

È necessario tenere presente che la memorizzazione nella cache di output ASP.NET è disattivata per i controlli utente utilizzati come controlli WebPart in fase di esecuzione. L'insieme di controlli Web part richiede che un controllo sia presente nella struttura dei controlli per ciascuna richiesta inviata a una pagina. Ciò è necessario per utilizzare determinate funzionalità Web part, ad esempio la personalizzazione. Per ulteriori informazioni, vedere Cenni preliminari sulla personalizzazione di Web part. Poiché per le richieste in cui un controllo utente viene memorizzato nella cache (per ulteriori informazioni, vedere la direttiva @ OutputCache) il controllo non viene aggiunto alla struttura dei controlli, la memorizzazione nella cache di output non è compatibile con le funzionalità Web part e non può essere utilizzata con controlli utente che operano come WebPart in un'applicazione Web part.