3 messaggi dal 28 febbraio 2013
www.gammaweb.net
Salve a tutti, sto tentando di scrivere un provider personalizzato di localizzazione che prelevi le risorse da SQL server. Fin qui nessun problema.

Volevo inoltre corredarlo di uno userControl da inserire in una pagina dell'amministrazione del sito con il quale gestire l'inserimento delle varie risorse. Tramite questo controllo dovrei passare le variabili da inserire nel DB al provider.

Qui sorge il problema: per le risorse relative alla singola pagina, non so come passare al provider l'url corretta. Mi spiego meglio: il sito utilizza l'url routing, l'implementazione della quale non è di mia competenza, quindi la domanda è: c'è un modo per ricavare questa url da una pagina che non è quella interessata ma solo avendo i parametri che le vengono passati tramite querystring, o c'è qualche altro modo per riuscire a fare quello che mi interessa?

Qualunque idea è graditissima :)
Grazie in anticipo per l'aiuto.

Immagination is more important than knowledge - Albert Einstein - http://www.gammaweb.net
11.884 messaggi dal 09 febbraio 2002
Contributi
ciao, benvenuto nel forum!
Il routing in questo caso potrebbe non essere un problema. Infatti, quando l'esecuzione arriva alla factory del tuo resource provider, la route è già stata risolta con il percorso virtuale al file aspx.

Mi spiego meglio: avrai sicuramente realizzato una classe che deriva da ResourceProviderFactory. Come parametro del suo metodo CreateLocalResourceProvider gli verrà passato un percorso tipo "/Cartella/Pagina.aspx", indipendentemente dalla route usata per arrivarci.

Quindi non devi ricavarti alcun percorso, ti viene già fornito come serve a te.

Lo user control che hai in amministrazione dovrà usare anch'esso un percorso come quello lì. A questo punto dovreti aver risolto perché si tratta del percorso di una pagina.aspx fisicamente esistente su disco.

Può funzionare?

Enjoy learning and just keep making
3 messaggi dal 28 febbraio 2013
www.gammaweb.net
BrightSoul ha scritto:
.
Lo user control che hai in amministrazione dovrà usare anch'esso un percorso come quello lì. A questo punto dovreti aver risolto perché si tratta del percorso di una pagina.aspx fisicamente esistente su disco.

Può funzionare?


Tutto corretto, quello che non va è che la pagina nell'amministrazione non ha lo stesso indirizzo di quella dove effettivamente verranno utilizzate le risorse; inoltre la pagina prodotto.aspx non avrà le stesse risorse sempre, queste dovranno essere diverse da prodotto a prodotto, non posso mettere una descrizione del prodotto x nel prodotto y. Questa è la difficoltà che trovo, dovrei passare i parametri idProdotto e idCategoria per avere qualcosa di univoco, ma il routing mi passa solo la pagina.

Immagination is more important than knowledge - Albert Einstein - http://www.gammaweb.net
11.884 messaggi dal 09 febbraio 2002
Contributi
ciao SlowFox,
ok, ora penso di aver capito.
Comprendo che tu voglia "unificare" la gestione dei testi tradotti ma probabilmente dovresti tenere separate le risorse locali, cioè quei testi come "Aggiungi al carrello" propri della pagina aspx, dalle descrizioni prodotti.

Può capitare infatti di dover presentare un prodotto anche in altri punti dell'applicazione, come in una pagina di ricerca oppure nella vetrina in homepage. In questo caso legheresti le descrizioni anche a quelle altre pagine?

No, è preferibile che i contenuti restino agnostici sul come poi verranno presentati nel sito.
Per i prodotti, potresti predisporre nel database una tabella secondaria che conterrà i testi tradotti ed avrà una chiave primaria composta da due campi: l'id del prodotto e l'id della lingua. Qui trovi una possibile implementazione, vedi il paragrafo "The good design".
http://www.codeproject.com/Articles/8084/Creating-multilingual-websites-Part-2#databasedesign

Il tuo strato di accesso ai dati dovrà dunque mettere in JOIN la tabella principale dei Prodotti e quella secondaria che contiene le traduzioni. Nella clausola ON della join, andrà indicato anche il criterio della lingua, in modo che tra le tante traduzioni sia scelto solo il record relativo alla lingua dell'utente.
Trovi l'esatta query SQL nello stesso articolo che ho linkato qui sopra.

SlowFox ha scritto:

dovrei passare i parametri idProdotto e idCategoria per avere qualcosa di univoco

Da questo punto di vista, conoscere l'idProdotto e l'idCategoria non ti serve più perché l'inserimento delle traduzioni avverrebbe dalle pagine di amministrazione dello specifico prodotto o categoria.

Nella pagina di modifica prodotto potresti predisporre un editor del genere, avente tante tabs quante sono le lingue disponibili nel sito.
http://help.convio.net/images/content/pagebuilder/TabsEditorEnglish.png
Al salvataggio, ogni contenuto tradotto verrebbe poi inserito nella tabella secondaria di cui parlavo.

ciao
Modificato da BrightSoul il 09 maggio 2013 23.26 -

Enjoy learning and just keep making
3 messaggi dal 28 febbraio 2013
www.gammaweb.net
Ho capito, effettivamente non avevo pensato che un prodotto è inserito anche in altre pagine e mi sarei ritrovato a duplicare risorse. Grazie mille per il consiglio, una sola altra domanda: richiederebbe troppe risorse lato server localizzare gli oggetti prodotto e categoria con risorse globali?

Immagination is more important than knowledge - Albert Einstein - http://www.gammaweb.net
11.884 messaggi dal 09 febbraio 2002
Contributi
ciao, prego :)

SlowFox ha scritto:

richiederebbe troppe risorse lato server localizzare gli oggetti prodotto e categoria con risorse globali?

Immagino che tu possa farlo, e con pochi utenti contemporanei potrebbe funzionare egregiamente. Tuttavia, non è una soluzione che mi sento di consigliarti, in primo luogo perché penso che snaturi lo scopo delle risorse globali che è quello di contenere piccole porzioni di dati da condividere attaverso molteplici pagine.
L'altro motivo è che, se in una scheda prodotto impieghi 4 o 5 risorse globali (es. titolo, sottotitolo, descrizione e scheda tecnica), il tuo provider custom dovrà effettuare altrettante query SELECT al database. Invece, potresti ridurre il numero ad 1 se con una sola query recuperassi contemporaneamente tutti i campi da mostrare nella pagina.

Certo, nel provider custom potresti impiegare un meccanismo di caching per mitigare il problema di accesso al database, ma a quel punto dovrai fare attenzione alla RAM occupata dalle risorse. Con migliaia di prodotti e descrizioni abbastanza corpose, questo potrebbe diventare un problema.

Nel dubbio, personalmente cercherei di seguire la soluzione che riesce a darmi il miglior risultato con il minor dispendio di risorse. In questo caso si tratterebbe di recuperare i dati di un prodotto con un'unica SELECT ... JOIN tra la tabella principale e quella correlata che contiene i testi tradotti.
Se ci pensi, il lavoro di progettazione da fare a livello di database è lo stesso sia che usi l'uno o l'altro sistema. Si tratta comunque di creare una tabella con una chiave primaria composta da lingua e identificativo del prodotto.

ciao

Enjoy learning and just keep making

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.