Newsgroup: it.comp.lang.javascript
Titolo: Curiosita'...

Intanto che finisco il lavoro, m'e' venuta in mente una curiosita' riguardo 
al javascript (maledetta M$!)...
Come mai si mette il blocco di commento ( <!-- e //--> ) a racchiudere il 
codice tra i due tag <script... e </script>
??



per questi browser vetusti che non sanno cosa sia javascript?
-- 
"Emancipate yourselves from mental slavery;
None but ourselves can free our minds"
									    B.M.

 ??
Per i dispositivi che non supportano javascript. Altrimenti manderebbero in
output il codice ivi compreso. Ma è una pratica che non utilizzo, preferisco
di gran lunga avere un file js esterno ed il problema non si pone. :)
-- 
Chuck Norris non manda lettere minatorie. Le lettere minatorie mandano Chuck
Norris.

 per questi browser vetusti che non sanno cosa sia javascript?
Originariamente sì, come ti hanno correttamente risposto Zer0 e Cristiano.
Ora però è corretto continuare ad usarli (anche) per evitare che vada a
male la validazione di una pagina (X)HTML, ad esempio:
<script type="text/Javascript" [language="Javascript"]>
var a=5;
var b=6;
if (a<b)
{
	alert("a è minore di b");
}
</script>
Non potrebbe essere validata, perché nell'if è presente il segno < che
rappresenta l'apertura scorretta di un tag (X)HTML (<b).
Per evitare ciò, si usano i classici commenti HTML, che vanno bene fintatno
che in XHTML non utilizzi un doppio meno, per esempio:
<script type="text/Javascript">
<!--
var a=5;
var b=6;
b--;
if (a==b)
{
	alert("a è uguale a b");
}
//-->
</script>
In questo caso non passeresti la validazione, perché all'interno dei
commenti HTML <!-- --> non puoi usare il -- e devi quindi usare le sezioni
CDATA, opportunamente nascoste all'interprete JS con:
/* <!CDATA[ */
/* ]]> */
Oppure come ti ha suggerito Zer0, metti tutto in un file esterno ed eviti
tutti i problemi.
Spero di aver spiegato tutto ;)
-- 
Ro!

 di gran lunga avere un file js esterno ed il problema non si pone. :)
Ok, per cui posso proseguire con la mia filosofia, e non metterlo e tenere 
il codice js nelle pagine.
Grazie!
(anche a Cristiano DNMNDF)

 js lo posso usare o mi bacchettate anche su quello? :-)
JS lo uso pure io :)
-- 
Ro!

 e non metterlo e tenere il codice js nelle pagine.
Se vuoi tenerlo nelle pagine, che ti costa aggiungere due caratteri. Tra
l'altro, quando passerai a validare le tue pagine, se proprio vuoi tenere il
codice js all'interno dell'HTML dovrai forzatamente cambiare filosofia. :)
(Per non parlare se userai XSLT, allora lě la dovrai cambiare due volte :D )
-- 
Chuck Norris riesce a prendere al volo una freccia lanciata da un arco. Dopo
averla tirata lui stesso.

 codice js all'interno dell'HTML dovrai forzatamente cambiare filosofia. :)
Sto gia' procedendo in quel senso.
Il problema e' che io non sono un programmatore WEB, e' una logica di 
programmazione che mi piace poco e mi riesce poco, io sono un programmatore 
di software client side.
Pero' ogni tanto mi pagano per fare siti...

 Pero' ogni tanto mi pagano per fare siti...
E al Dio Denaro non si può dire di no. :P
-- 
Un giorno, mentre partecipava al Grande Fratello VIP, Chuck Norris è stato
nominato. In un batter di ciglia, aveva sterminato tutti i suoi coinquilini.
Nessuno nomina Chuck Norris invano. Nessuno.

 Quando arrivi alla perversione di generare con XSLT dell'XML 
Sta zitto va', che mi capita anche a me. :)
Sto riscrivendo la gestione degli errori e debug per gli applicativi intranet
attuali, e l'oggetto che ho creato per gestire tutte le variabili di ambiente
e applicativi si basa su una struttura XML. Ha un metodo poi, chiamato
"applyStylesheet" che restituisce in output (o direttamente in un output
stream passato come secondo parametro) il risultato della trasformazione
dell'XML così popolato, con un XSLT (passato come primo parametro).
In questo modo posso visualizzare a video all'end-user delle informazioni
limitate (friendly), all'utente definito come "developer" altre, e
contemporaneamente mandare via posta elettronica a quest'ultimo una mail con
in attachment un report (chi ha scatenato cosa, dove come e quando). Le tre
cose anche con un layout e "funzioni" completamente differenti; dato che la
funzione è parametrica.
In verità, anche se questo copre gli errori che capitano tramite
XmlHttpRequest, mi è venuto in mente di dare la possibilità di restituire -
nel caso di richieste di questo tipo - anche un XML, da poter gestire tramite
responseXML.
Non posso fargli restituire l'XML "originale", perché contiene informazioni
che l'end user non deve possedere né avere. L'utonto, non riuscirebbe mai a
recuperarle, ma un utente un po' più smart si. E anche se di utenti "smart"
qua non ne abbiamo, preferisco evitare (insomma, sempre il solito discorso: o
le cose si fanno bene, o non si fanno :) ).
Perché non sfruttare quindi il meccanismo che già ho imbastito tramite
applyStylesheet? Basta passare un XSLT che compone un XML, filtrando i dati
sensibili.
Mi sembra un doppio salto carpiato, ma credo anche che sia la soluzione più
pulita, elegante e riusabile. Tu che ne pensi?
-- 
Ogni volta che Chuck Norris sente nominare la frase "La 'vergine' Maria" ride
a squarciagola.

 (qui sono a quota 16!)
Mi pare un "tantinello" esagerato. :)
-- 
Chuck Norris fuma toscani. Vivi.

 metodi javascript sono troppe. Non ha senso :-)
Ha senso eccome: secondo te 16 chiamate a cascata di metodi JS non sono
troppe? :D
BTW, dipende sempre per cosa lo fai. Inoltre c'è una differenza tra il
paragone che tu citi. Per quanto mi riguarda, sarebbe come se io chiamassi 16
volte un intero file javascript, non 16 chiamate a metodi :)
Personalmente cmq, tenterei di evitare una cosa del genere anche in altri
linguaggi.
-- 
Un giorno, dopo aver sentito "I will survive", Chuck Norris decapitò Gloria
Gaynor con un calcio rotante: l'aveva interpretata come una sfida.

 un applicativo (con bei guadagni in termini prestazionali) allora no.
Non fraintendermi: non ti sto dicendo che preferisco manipolare un XML tramite
DOM API lato server, piuttosto che utilizzando una trasformazione XSLT se ciò
che voglio ottenere me lo permette. Ti sto dicendo che raramente un numero
elevato di trasformazioni XSLT a cascata è necessario.
Ricordati, che del resto in informatica ci sono molti modi per ottenere il
medesimo risultato. Non è anche il motto del tuo amato perl? :)
-- 
Chuck Norris è l'unico al mondo in grado di far fare il sorriso ai Sofficini
con la forchetta come nella pubblicità.

 /* ]]> */
Attenzione, hai dimenticato una parentesi <![CDATA[
Cmq forse non sono fufficientemente informato io, cmq io faccio:
<script type="text/javascript">
<!--//<![CDATA[
....
//]]>-->
</script>
ed e' validato XHTML1.1 
Nel mio caso, essendo JS un requisito fondamentale potrei anche
risparmiarmi i 7 byte di commento per i browser che non supportano JS,
cmq...

 eh si...
:)
-- 
Il governo degli Stati Uniti spende 40 miliardi di dollari all'anno in
prevenzione di calamità naturali. Di questi, 35 miliardi sono spesi per
garantire che la birra di Chuck Norris sia sempre fredda.

 cmq...
Ti ripeto che la commentazione del codice JS va fatta non solo per i
browser non compatibili (anche perché ormai non lo farebbe quasi nessuno)
ma per validarne il codice. Poi uno può saltare a pie' pari entrambe le
cose e proseguire, ma il fatto che ti sia posto il problema vuol dire che
almeno lo vuoi affrontare e in generale ciò è buono ;)
-- 
Ro!