Newsgroup: it.comp.www.asp
Titolo: #include "parametrico"

Ciao a tutti.
C'e' un modo per implementare un #include ma il cui puntamento dipenda dal
contenuto di una variabile?
Mi spiego meglio, diciamo di avere una variabile Categ che contiene una
stringa (es. "CatA" o "CatB", ma i valori potrebbero teoricamente essere
tanti), vorrei poter fare una cosa di questo tipo (so che non si puo', e'
per far capire l'esigenza;-)):
<!-- #include virtual="/miosito/<%=Categ%>/include.txt" -->
Questo potrebbe essere utile ad esempio per rendere parametrica la dir a cui
puntare, ad es. per rendere "portabile" il codice che usa #include, in
quanto se uso "file=" devo dare un percorso relativo (ed a priori vorrei
essere svincolato dal dover adattare tutti gli #include a seconda della dir
in cui si trova l'ASP origine), mentre con "virtual=" sono vincolato al
percorso (costringendomi ad es. a tenere lo stesso identico percorso
virtuale sia sul server di sviluppo sia su quello di "produzione", cosa a
volte molto scomoda da mantenere).
Tanto per fare un altro esempio, potrebbe anche servire per rendere il
codice "multilingua" caricando solamente le costanti relative ai messaggi
della lingua correntemente selezionata, con una cosa del tipo:
<!-- #include virtual="/miosito/lang/<%=Lingua%>.txt" -->
Ovviamente potrei anche caricare sempre tutti gli include, ma vorrei
evitarlo per cercare di rendere piu' "leggero" il lavoro del server (e'
inutile caricare in ogni pagina centinaia di variabili e costanti che non
verranno mai utilizzate), ed in fondo anche piu' leggibile il codice...
Consigli?
--
   Alex Palmese
---
Sei anche tu stanco dei messaggi spam? Usa Terminator, il programma
anti-spam italiano FREEWARE! 
http://www.sertel.net/terminator/

 
Che io sappia, no. Nell'include NON puoi aggiuneger ASP.
Puoi perņ stamparlo o meno, con un IF o Select Case.
<%
Select Case variabile
	Case 1 %>
	<!-- #include...
<%	Case 2 %>
	<!-- #include...


Con ASP 3.0 (windows 2000 e successivi):
server.execute "/miosito/"& Categ &"/include.txt"
--
Ciao,
Andrea Z.
--

 <!-- #include...
Anche questo lo avevo pensato, pero' cosi' anche se alla fine ne utilizzo
solo uno, dal punto di vista del server vengono comunque inclusi TUTTI gli
include, portando ad una pagina di fatto abbastanza "pesante"... E poi puo'
valere per un numero comunque limitato di #include, oltre a non risolvere il
problema della "parametrizzazione" dei "virtual" (vedi mio msg).
Comunque grazie per la risposta...;-)
Altre possibilita' secondo voi esistono?


 Altre possibilita' secondo voi esistono?
Server.Execute?
--
Claudio Valerio
Analista Programmatore
XXI.it S.r.l.
www.xxi.it

Dimenticavo...
Ovviamente potrei passare dal modulo chiamante ("prova.asp" nel mio esempio)
a quello chiamato ("prova1.asp") tutte le variabili Application e Session,
ma ovviamente non e' sufficiente sia perche' non mi piace "abusare" di
variabili Application e Sessio, sia perche' mi sarebbe utile poter
condividere anche costanti, Sub e Function definiti nel modulo chiamato...


 server.execute "/miosito/"& Categ &"/include.txt"
Ti ringrazio, sicuramente questo consiglio mi sara' utile per aggirare
alcuni ostacoli, e lo usero' (perche' non mi e' venuto in mente prima di
cercare nell'ASP 3.0?;-)), pero' non mi sembra sia esattamente quello che
cercavo. Con la Server.Execute e' pur vero che viene eseguito il file
indicato (quindi con la parametrizzazione completa di nome e percorso) ma
non mi risolve l'altra questione, ossia poter includere porzioni di codice
ed utilizzarli come se fossero interni al modulo ASP "ospitante".
In sostanza con Server.Execute l'esecuzione di quel modulo resta
completamente isolata (almeno stando ai primi test che ho fatto su un IIS
5.0)! Mi spiego meglio... Se io avessi:
' File PROVA.ASP
<%
Server.Execute "prova1.asp"
Response.Write "Il valore e' " & Valore & "<br>"
%>
' File PROVA1.ASP
<%
Dim Valore
Valore = 10
%>
In "PROVA.ASP" non vedrei la variabile "Valore" (ossia avrei sempre stringa
nulla, o, piu' esattamente, con Option Explicit avrei correttamente un
messaggio di errore)! Invece con l'#include funzionerebbe tutto (ma senza
"parametrizzazione" del nome file):
' File PROVA.ASP
<!-- #include file="prova1.asp" -->
<%
Response.Write "Il valore e' " & Valore & "<br>"
%>
In sostanza variabili, sub e function presenti nel modulo richiamato con
Execute non sarebbero accessibili dal modulo chiamante, mentre a me
piacerebbe poter utilizzare questi include ad esempio per rendere
parametrici in base alla lingua selezionata i messaggi del mio programma
(quindi avrei una serie di file da includere nei quali metterei tutte le
costanti che rappresentano i messaggi in ognuna delle lingue).
Ti viene in mente qualche altro trucco che potrei sfruttare?
Ti ringrazio.
Ciao!


 Server.Execute?
Si, questo si avvicina molto a quello che mi servirebbe, ma come ho scritto
nell'altro messaggio e' piu' simile al comando SSI #exec che all'#include
perche' esegue un ASP in un ambiente completamente separato. Sarebbe stato
perfetto se avessero aggiunto un'opzione per eseguirlo nello spazio
corrente, per consentire la condivisione di tutte le variabili, costanti,
Sub e Function! Qualcosa del tipo:
Server.Execute "altroscript.asp", vbInclude


 un'applicazione ASP...
si struttura tutto in modo differente....
ad esempio per un multilingua, strutturi tutti i campi testo con variabili
che valorizzi in base alla lingua scelta.
Zero include...
dipende sempre quello che tu devi fare....


se non hai moltissime variabili, la pagina chiamata da Server.Execute può
creare le var. che devono essere visibili dalla pagina chiamante come
variabili di sessione.


Credo che nel tuo caso devi seguire un'altra strada.
Se ho ben capito vuoi creare un sito multilingua. In tal caso memorizza in
un database tante tabella quante sono le versioni del sito che vuoi avere o
usa un  file XML. Quindi, a seconda della lingua che vuoi utilizzare, esegui
una query e visualizzi menu, titoli e testo nella lingua scelta dall'utente
(naturalmente puoi velocizzare il tutto *bufferizzando* il tutto). Quindi
crei le sub e function che ti servono in altri file asp che includerai al
momento dell'utilizzo.
In ASP non ci sono altre alternative...


Non ne esci
ho messo mano ad un sito che aveva N include con la logica if...then; se è
vero che non manda al client tutti gli include, è però vero che se li passa
uno per uno lato server; man mano che si aggiungevano include il tutto era
sempre più lento.
Server.Execute va bene per passare parametri ma ahimé non legge le variabili
della pagina contenitrice.
Io non ho trovato soluzioni (nel caso del mio sito ho spezzettato la home
page in N home page parallele, con un redirect a seconda degli include che
servivano)