Newsgroup: it.comp.macintosh
Titolo: Re: import [javascript]

 o simile?
no(*)
(*) se ti riferisci a Javascript eseguito dentro un browser web
-- 
La parte migliore dell'innamoramento e' quando ancora non
immagini che l'oggetto del tuo amore ha tutt'altri piani.

 (*) se ti riferisci a Javascript eseguito dentro un browser web
Si. A questo mi riferivo. Mannaggia ma che storia pacco! :)
Quindi via di inclusione lato pagina web?
Che tristezza. O magari un  mega makefile che mi costruisce il
pappardellone.
-- 
non vincono, non vinceranno, non hanno domani
la forza č nel puntello impugnato da oneste fortissime mani

 pappardellone.
se spieghi cosa vuoi fare, forse posso essere piu' preciso
-- 
Le aquile non volano a stormi

 se spieghi cosa vuoi fare, forse posso essere piu' preciso
Nulla. Semplicemente sono abituato a strutturare i miei progetti, a
creare librerie et similia, e trovo seccante il fatto che il supporto
non esista (da quanto dici, d'altra parte ho chiesto perchè non ho
trovato nulla).
Pertanto le strade rimaste sono due. O includo i javascript nella pagina
in modo che le "librerie" siano caricate prima (ma questa soluzione
*non* mi piace, troppo error prone) oppure faccio una soluzione di
"metaprogrammazione".
Ovvero utilizzo un qualche tool (make o magari ant o qualcosa di più
avanzato scritto ad hoc in Python) per trascrivere le funzioni di
libreria usate nel file che verrà chiamato dal browser. Mi scogliona un
po' l'idea di farmi un maledetto mini-interprete (di questo si tratta)
per andare a sgamare quali funzioni sarebbero richieste).
Più probabile che faccia un giocattolino più grezzo che semplicemente
legge le dipendenze e crea.
myscript.js: xmllib.js other.js base_source.js
        cat base_source.js > myscript.js
        cat xmllib.js >> myscript.js
        cat other.js >> myscript.js
Tuttavia mi pare assurdo che nessun programmatore javascript abbia prima
di me sentito la necessità di separare il codice su più files...
-- 
non vincono, non vinceranno, non hanno domani
la forza è nel puntello impugnato da oneste fortissime mani

 di me sentito la necessità di separare il codice su più files...
questo viene gia' fatto includendo nell'HTML diversi sorgenti
<script type="text/javascript" src="path/to/first/script.js"></script>
<script type="text/javascript" src="path/to/second/script.js"></script>
<!-- ... -->
<script type="text/javascript" src="path/to/nth/script.js"></script>
quanto al fatto che non sia possibile risolvere automaticamente le
dipendenze... beh la mole non immensa dei progetti web rende sufficiente
aggiungere una o due righe negli header HTML


 prima generazione del tag script con document.write, una vera palla.
Per quello che pensavo di farlo "staticamente". Ovvero di generare a
partire dai miei sorgenti il "sorgentone" da includere.
-- 
non vincono, non vinceranno, non hanno domani
la forza č nel puntello impugnato da oneste fortissime mani

 aggiungere una o due righe negli header HTML
Il discorso "tanto l'oggetto č piccolo" č una delle ragioni per cui PHP
si č diffuso. Finchč uno si barcamena su progetti piccolini (quasi)
nessun problema [ a parte un linguaggio veramente brutto ], poi quando
deve affrontare qualcosa di serio (e ha esperienza con linguaggi seri)
si accorge che č un giocattolino e che ha piů difetti che altro.
Solo che la maggior parte degli sviluppatori tendono a non accorgersene.
Sigh... spesso non sanno nemmeno come dovrebbe essere una piattorma di
sviluppo e vanno avanti a pezze.
Purtroppo adesso come adesso sembrerebbe  che mi troverň a mettere le
mani in un progetto dove la parte javascript č parecchio consistente
(Ajax pesante), e mi farebbe parecchio comodo un po' di riutilizzo del
codice.
Mi č anche venuta la soluzione... generare dinamicamente il javascript
che mi serve. Sigh. Che tristezza perň.
-- 
non vincono, non vinceranno, non hanno domani
la forza č nel puntello impugnato da oneste fortissime mani

 partire dai miei sorgenti il "sorgentone" da includere.
ad esempio io genero lato server (in PHP) un file javascript in base ai
privilegi dell'utente


 beh... serverside puoi avere un output javascript :-)
Esattamente a quello pensavo. 


 *senza* passare per HTML?
No. 
Script.aculo.us
 lo fa automaticamente trovando il proprio percorso
(leggendo l'attributo src dei tag <script> della pagina) e appendendo
nuovi tag <script> al DOM.
 - ∞

 nuovi tag <script> al DOM.
Mo ci guardo un poco. Ma esattamente cosa è aculo? Sono andato sul sito
del produttore e non ho visto *esattamente* cosa fa.
-- 
non vincono, non vinceranno, non hanno domani
la forza è nel puntello impugnato da oneste fortissime mani


 - ∞

 perche'? Sapessi quante volte genero javascript con Perl o XSLT :-)
Perchè è una cosa (nel mio caso) "non necessaria", utile solo per
"sopperire" ad una mancanza del runtime.
Se avessi effettivamente necessità di generare dinamicamente javascript
sarebbe invece la soluzione logica.
Insomma ogni qual volta devo sparare con il cannone alle zanzare perchè
mi hanno nascosto le ciabatte, la cosa mi secca :)
-- 
non vincono, non vinceranno, non hanno domani
la forza è nel puntello impugnato da oneste fortissime mani


Yes... ma cheffanno sti scripts?
(e immagino che nel progetto non ci siano italiani)


.
 - ∞


*minchia*. :)
-- 
non vincono, non vinceranno, non hanno domani
la forza č nel puntello impugnato da oneste fortissime mani