UrlRewrite vs ASP.Net 3.5 DataPager
Cristian Merighi ()
I fields del nuovo controllo per ASP.Net 3.5 non sembrano andare d'accordo con la riscrittura degli URL. Ecco una possibile soluzione.
Questo articolo è da considerarsi obsoleto. Alcune funzionalità potrebbero non essere più disponibili e non è possibile aggiungere commenti.
ASP.Net 3.5 ha portato (pochi) nuovi controlli che promettono di essere di notevole aiuto
per addolcire il conflitto che da anni esiste tra la tecnologia WebControls-based e gli aspetti di correttezza formale XHTML/CSS
e di Search Engine Optimization.
Adoro il ListView ovviamente, ma apprezzo forse di più il DataPager che posso associarvi.
Infatti, valorizzando la propretà QueryStringField dello stesso, posso finalmente dimenticami degli odiosi
links javascript dei pager controls passati (illeggibili per i search-bots)!
Bene, tutto a posto allora: ho questi nuovi oggettini, scrivo il mio ultra-hackabile-leggibile-SEOttimizzato website
che è una bomb... whoops!
I Fields del mio DataPager puntano alla pagina fisica e non a quella virtuale?! Sul serio?...
Proprio così :(
Vabbè, magari utilizzo un ControlAdapter custom e risolvo agevolmente il problema.
No-no.
Vabbè, allora prendo - ad esempio - il NumericPagerField, che non è marcato sealed, lo subclasso
e sostituisco con un bell'override il metodo incriminato.
No-no... o almeno, non così facilmente...
Diamo un occhio - grazie Reflector - alla catenaria di classi e metodi che si
avvicendano per la renderizzazione dei nostri link di paginazione:
NumericPagerField espone un metodo virtual (CreateDataPagers) che dà inizio a tutto il processo.
Esso "stuzzica" due subroutines private CreateNextPrevLink e CreateNumericLink
(i nomi sono autoesplicativi direi) le quali a loro volta attingono ad un metodo GetQueryStringNavigateUrl appartenente alla classe
base abstract DataPagerField e che è marcato protected (non virtual)!
Qui non colgo il senso dell'architettura: perché un metodo protected ed, al contempo,
una chiamata esplicita e blindata da una classe derivata alla versione base del
metodo stesso?!
Per ovviare a questo inconveniente si rende necessario scrivere più codice di quanto pensassi...
Di seguito riporto quello che è il metodo centrale da riscrivere, per far funzionare questa sottoclasse di NumericPagerField
in abbinamento con la riscrittura degli URL è però necessario ulteriore, verboso, codice (disponibile nella sua interezza più sotto):
protected new string GetQueryStringNavigateUrl(int pageNumber)
{
string queryStringField = this.DataPager.QueryStringField;
StringBuilder builder = new StringBuilder();
HttpRequest request = this.DataPager.Page.Request;
string url = request.RawUrl;
int qMarkNdx = url.IndexOf("?");
if (qMarkNdx > -1) url = url.Substring(0, qMarkNdx);
builder.Append(url);
builder.Append("?");
foreach (string str2 in request.QueryString.AllKeys)
{
if (string.IsNullOrEmpty(str2) || str2.Equals(DataPager.QueryStringField, StringComparison.InvariantCultureIgnoreCase)) continue;
builder.Append(HttpUtility.UrlEncode(str2));
builder.Append("=");
builder.Append(HttpUtility.UrlEncode(request.QueryString[str2]));
builder.Append("&");
}
builder.Append(queryStringField);
builder.Append("=");
return (builder.ToString() + pageNumber.ToString(System.Globalization.CultureInfo.InvariantCulture));
}
Di seguito il codice scaricabile.
«
UrlRewriteNumericPagerField class (C#)
Take care. Bye.