Lavorando con la funzionalità di esportazione di webpart, e collegandomi al mio precedente post #9, potrebbe capitare il caso in cui un utente provi ad esportare una webpart che contiene una parte dei suoi dati contrassegnati come sensibili; quindi, per riassumere, significa che la webpart ha l'attributo [Personalizable(PersonalizationScope.User, true)] nella situazione suddetta possiamo mostrare all'utente un avviso che lo informa di annullare l'operazione perchè non consentita. L'oggetto che gestisce ciò è il WebPartManager e la property è ExportSensitiveDataWarning.

Può essere necessario, a volte, inibire ad un utente la possibilità di effettuare il drag'n'drop di una webpart da una zona ad un'altra. Possiamo farlo mediante la classe WebPartZoneBase e, in particolare, utilizzando la property DragDropEnabled(True|False) che passa il valore alla omonima property della classe WebPartChrome.

Uno dei metodi canonici che il WebPart Framework mette a disposizione per disabilitare verbi è quello di utilizzare l'override sul metodo FilterWebPartVerbs e passargli la collection di verbi che si vuole abilitare/disabilitare unitamente alla webpart: protected override WebPartVerbCollection FilterWebPartVerbs(WebPartVerbCollection verbs, WebPart webPart) { WebPartVerbCollection wpvc = base.FilterWebPartVerbs(verbs, webPart); foreach (WebPartVerb verb in wpvc) { if (verb == this.Zone.EditVerb) verb.Enabled = webPart.AllowEdit; } return wpvc; } ciò che probabilmente non riusciremo a fare, però, è nascondere il verbo...

Quando creiamo verbi custom potremmo avere la necessità di associare azioni particolari, come ad esempio la funzione di narrazione del testo per utenti disabili, che non prevede form di dialogo o da compilare ma soltanto una attivazione o disattivazione della suddetta funzionalità. Ebbene, ciò significa che accanto al verbo, nel menù a tendina, dovrebbe comparire anche un simbolo di spunta o un checkbox da selezionare/deselezionare; come fare? Utilizzando la property WebPartVerb.Checked (true|false) possiamo giungere al nostro obiettivo. Quando il suo valore è true accanto al nome del verbo apparirà una checkbox. Da ricordare, però, che tale proprietà funziona solo con...

Quando lavoriamo con i Verbs, per default nel menù a tendina, accanto ai verbi, non appaiono immagini che rendono più user friendly la nostra webpart. Per ovviare a ciò, mediante l'uso della property ImageUrl contenuta nella classe WebPartVerb, possiamo ad esempio creare una zona custom e, ogni webpart che verrà inserita in essa, acquisirà i verbi di default e quelli aggiunti, nonchè le immagini (nei formati soliti) che appariranno accanto ad ogni verbo Ecco un esempio del codice internal class CustomWebPartVerb : WebPartVerb { private const String _copyImageUrl = "~/Copy.ico"; internal CustomWebPartVerb(WebPartEventHandler serverClickHandler) : ...

Il nostro utente ha aggiunto una webpart in una zona della pagina dal catalogo di webparts che gli abbiamo messo a disposizione. Ha aggiunto dei contenuti all'interno della webpart e, dietro le quinte, glieli abbiamo salvati nello storage di persistenza di AspNet e, avendo l'esigenza di dover lavorare su determinati molteplici contenuti di una webpart, in un nostro db custom. Il nostro amato utente si rende conto di aver sbagliato pagina e quella webpart non doveva metterla là bensì in un'altra pagina, quindi clicca sull'apposito menù a tendina della webpart e seleziona "Delete". Sappiamo che aspnet elimina dal suo storage...

Quando vogliamo dare all'utente del nostro sito la possibilità di esportare una web part in formato xml sappiamo che occorre innanzitutto abilitare l'export dal web.config mediante    In questo modo, tuttavia, se non impostiamo la property ExportMode della web part, l'utente non otterrà l'esportazione a causa del valore di default che è None. Se però vogliamo che l'esportazione avvenga in maniera parziale, cioè che non tutte le properties vengano esportate, dobbiamo impostare a NonSensitiveData la suddetta property, importante è che nella dichiarazione dell'attributo [Personalizable] ci ricordiamo di passare true come secondo argomento: [Personalizable(PersonalizationScope.User, true)] in questo modo le properties della nostra web part che...

Capita, lavorando con WebParts in connessione, che vi siano una o più di esse con il ruolo sia di Provider che di Consumer. L'effetto negativo che si può riscontrare è quello, ovviamente, dei riferimenti circolari; serve quindi un modo per determinare ciò e prendere eventuali contromisure: WebPartTracker.IsCircularConnection. La classe WebPartTracker è sealed e ha una property, IsCircularConnection appunto. La suddetta property non fa altro che testare se la WebPart che, unitamente al punto di connessione, abbiamo passato al WebPartTracker ha più punti di connessione e, nel caso, restituisce un valore true; a noi resta da verificare che non vi siano riferimenti circolari.

Mi rifaccio al mio post precedente in cui parlo di IWebPartTable. Se invece di una tabella dovete passare tra webparts provider e consumer una singola riga di dati, utilizzate l'interfaccia IWebPartRow; il meccanismo è il medesimo, GetRowData per passare una riga e Schema per recuperarne i dati. Non ripeto l'esempio perchè è similissimo al precedente.

Ringrazio coloro che hanno risposto gentilmente al mio Poll(icino), quindi, augurandovi un ottimo 2007 (in fondo siamo ancora all'8 gennaio), proseguo con la miniserie in oggetto.   Vi occorre mettere in comunicazione una webpart che contiene una tabella e passare il contenuto ad altre webparts che consumano la prima? Bene, tutto quello che dovete fare è utilizzare l'interfaccia IWebPartTable; essa, sfruttando il meccanismo di connessione del Web Part Framework, consente con un metodo - GetTableData(TableCallback tbc) - e con una property - Schema - di spedire un DataTable verso una o più webparts public sealed class WebPartProvider : WebPart, IWebPartTable{    DataTable _table;    public WebPartProvider()    {        // codice che crea un DataTable (table), alcune DataColumn        // e un pò di DataRow    }    public PropertyDescriptorCollection tableSchema    {        get        {            return TypeDescriptor.GetProperties(table.DefaultView[0]);        }    }    public void GetTableData(TableCallback tableCallback)    {            tableCallback(table.Rows);    }    public bool ConnPointON    {        get        {            object o = ViewState["ConnPointON"];            return (o != null) ? (bool)o : true;        }        set        {            ViewState["ConnPointON"] = value;        }    }    [ConnectionProvider("Table", typeof(TableProviderConnectionPoint), AllowsMultipleConnections = true)]    public IWebPartTable GetConnectionInterface()    {        return new TableProviderWebPart();    }        public class TableProviderConnPoint : ProviderConnectionPoint    {        public TableProviderConnPoint(....) : base(....)        {        }        public override bool GetEnabled(Control control)        {            return ((TableProviderWebPart)control).ConnectionPointEnabled;        }    }} Notate la firma di questo metodo public void GetTableData(TableCallback tableCallback); TableCallBack è delegato a contenere l'indirizzo...

Mi piacerebbe sapere, e lo chiedo in particolare a chi legge il mio blog, se i post finora pubblicati (5) della miniserie in oggetto sono di qualche utilità per qualcuno e se qualcuno ha interesse che compaiano, tempo permettendo, post relativi a subtopic particolari riguardanti la stesse serie. Mi farebbe piacere ricevere feedback in proposito, anche in privato (soprattutto se negativi ). Vi ringrazio. powered by IMHO 1.3

Con l'attributo [Personalizable] dichiariamo ad ASP.NET di voler persistere nello storage di default il valore di una property da noi creata all'interno della web part. E fin qui nulla da dire. Peccato però che la property, se non contiene un semplice valore bensì un dato più complesso (collections o riferimenti a oggetti business) e questo viene modificato durante il ciclo di vita dell'applicazione - e quindi anche della web part - l'attributo [Personalizable] non è più sufficiente per persistere tale valore. Occorre quindi utilizzare il metodo SetPersonalizationDirty() quindi, una cosa di questo tipo: public class EditorWebPart : WebPart{    private BaseEditor _editor;        [Personalizable]    public BaseEditor Editor    {        get { return _editor; }        set { _editor = value; }    }    } essendo Editor una property complessa, perchè ha come tipo BaseEditor, non si potrà persistere il suo...

Scenario: avete sviluppato un portale web utilizzando il WebPart Framework, avete eseguito la fase di test e avete rilasciato il sistema al cliente, che lo sta collaudando inserendo dati a iosa nel db mediante le vostre webpart. Il cliente vi chiede delle modifiche e siete costretti a sostituire alcune properties dichiarate [Personalizable] con delle altre che gestiscono dati in maniera differente. ...e i dati già inseriti dal cliente e da noi persistiti nelle tabelle di ASP.NET ??!?? Sappiamo benissimo che sostituendo proprietà di personalizzazione rendiamo "orfani" i dati scritti nelle tabelle di personalizzazione. Come fare per agganciarli nuovamente e "travasarli" nelle nuove properties?   Soluzione: Lavoriamo...

Mi collego al mio precedente post #2 Piccolo scenario...avete un sito e i contenuti li inserite grazie a webparts, ognuna con il suo specifico compito di farvi editare contenuti e visualizzarli, opportunamente formattati, nel punto in cui le avete sistemate nelle vostre pagine, in apposite Zones. Sapete perfettamente che se non create verbi custom nelle webparts, il WebPartZone farà apparire il menù a tendina con i verbi di default o perlomeno customizzati, secondo quanto spiegato nel post suddetto. Se avete bisogno di far modificare i contenuti del vostro sito ad un utente tipo "PowerUser", quindi può accedere alla webpart in modalità Edit...

Secondo post sull'argomento WebParts Framework. Vediamo come "rivisitare" un altro componente che serve per ospitare le Web Parts in zone diverse della pagina web: il WebPartZone. Prima di tutto, cosa offre? Il WebPartZone deriva dalla classe WebPartZoneBase, che a sua volta deriva da WebZone, che deriva da CompositeControl; in effetti una WebPartZone non è altro che un controllo Web composto in grado di ospitare al suo interno altri controlli compositi, le Web Parts.   In questo post vorrei porre l'attenzione su una caratteristica in particolare: i Verbi. Si da per assunta la conoscenza di base del Web Part Framework quindi non spiego cosa sono...

"ASP.NET 2.0 fornisce classi che permettono di costruire applicazioni web integrando la tecnologia delle web parts..." si ok questo già lo conosco. Come spesso accade, però, non sempre basta quello che mamma Microsoft rilascia per le nostre innumerevoli esigenze, così capita che ci si ritrova a dover "estendere" qualcosina. Iniziamo a estendere, o meglio "rivedere", il Web Part Framework di ASP.NET 2.0 con un bel WebPartManager di casa nostra che si adopera per autorizzare o meno le webparts che gli si pareranno dinanzi nella pagina web. Nel codice che segue da notare AuthorizationFilter, è una proprietà che assume il nostro Custom User Control...