Newsgroup: it.comp.lang.javascript
Titolo: Meglio JQuery o Prototype

Ciao all, senza voler innescare un qualche tipo di flame, secondo la
vostra esperienza per costruire siti/applicazioni web2.0 è
consigliabile utilizzare JQuery oppure Prototype ?
Mi chiedo questo perche' sia Drupal che Wordpress hanno scelto
JQuery.
M.

 consigliabile utilizzare JQuery oppure Prototype ?
secondo la mia è meglio (molto meglio) (consigliato) (consigliatissimo se
si vuole avere un buon controllo sul proprio codice) farsi le proprie
librerie, magari studiandosi entrambe queste librerie (che non so cosa
siano, immagino librerie ajax, ho sentito nominare jquery perché usa eval
client-side ed è soggetto ad hacking, come del resto 
ajax.net
, ma non ne so
nulla di più).
-- 
"Affacciati affacciati benedici, guardaci
 guardaci...guardaci!
 Tanto sono quasi duemila anni che stai a guardare!"
									    E.B.

 JQuery.
Se non è cambiato nulla nel frattempo, Prototype estendeva l'Object.
Solo per questo andrebbe evitata.
-- 
~ "Quando ti rifiuti di imparare una lezione in un modo,
ti verrà ripresentata sotto un altro aspetto." (E.Caddy)

 Solo per questo andrebbe evitata.
Da un'occhiata rapidissima sembrerebbe che nell'ultima versione
abbiano deciso di fare marcia indietro (fortunatamente).
-- 
~ "Io ho fatto questo, dice la mia memoria
Io non posso aver fatto questo, dice il mio orgoglio.
Alla fine, è la memoria ad arrendersi." (Nietzsche)

 nulla di più).
Non ho approfondito Prototype, ma in jQuery "AJAX" e` solo una piccola
parte. Il grosso della libreria serve a fare query (appunto :) sul DOM,
dal banale getElementById alla ricerca in base a classi css (anche con
roba tipo "p + p", "div > span", ecc.)
Un po' come XQuery per XML (che conosco pochissimo, tra l'altro).
Bye.

 Un po' come XQuery per XML (che conosco pochissimo, tra l'altro).
ah. allora potrebbe essere interessante, quando avrò tempo ci darò un
occhio (resto comunque sul mio concetto-base: gli dò un occhio per vedere
se fa qualcosa di interessante da cui poter imparare, ma poi le librerie me
le faccio io)
-- 
"Run rabbit run
 dig that hole, forget the sun
 and when at last the work is done
 don't sit down, it's time to dig another one"
									    P.F.

 ah. allora potrebbe essere interessante, 
Aspetta. E' lenta quanto il cucco, anche se dopo i dibattiti con
"DomQuery" ha velocizzato qualcosa. E' che quel tipo di librerie
viene solitamente testato su computer abbastanza potenti, mentre
se provi su un PC un poco più vecchiotto rischi grosso.
Mentre stavo facendo un po' di benchmark tra il mio DOM Selector
e quelli in circolazione, jQuery mi ha PIANTATO IE con una query
un minimo complessa ("div div div" più altra roba che ora non mi
ricordo)...
-- 
~ "E' bello essere vivi.
Ci sono tante cose che non si possono fare da morti."


Meglio Jquery perchè non ha il peccato originale di prototype, quello di
estendere object. JQuery non crea nessun problema con altre librerie,
script etc. Per prototype bisogna stare un attimo attenti.
JQuery mi sembra la più compatta quindi per effetti sui siti può andare
bene.
Da un punto di vista tecnico a me piace YUI
http://developer.yahoo.com/
ed il capolavoro di extjs
http://extjs.com/
sono probabilmente più indicate per applicazioni che per effetti sui
siti. Non sono facilissime da usare e non sono velocissime, però sono
quelle con la miglior documentazione, fatte da ingegneri, controllo di
non spaccare nulla con le nuove versione etc etc.
Recente comparazione tra varie librerie ajax:
http://www.ddj.com/dept/webservices/199203087
-- 
FABIO SERRA
*Questo testo deve essere valutato secondo il senso della RFC-3*
Per rispondere in e-mail sostituire "invalid" con "faser"

 
Se non hai roba già fatta da te in anni, se non hai un'ottima conoscenza
di javascript le tue librerie non potranno mai competere con quelle che
ci sono in giro, è impensabile.
E' buono avere propri set di funzioni, classi specializzate che ti
permettono di fare una determinata cosa senza tirarsi dietro tutta una
libreria, ma voler fare tutto da soli penso non abbia senso. Solo farsi
una classe per xhr non è proprio immediato
Es:
http://developer.yahoo.com/yui/docs/connection.js.html
Io ai tempi me la ero dovuta fare, ma se iniziassi oggi non ci penserei
proprio.



A meno che non abbia preso un abbaglio, a occhio mi pare che non lo
faccia più.
-- 
~ Se i sintomi persistono, insultare il medico.

 
http://developer.yahoo.com/yui/docs/connection.js.html
Le facessero bene, almeno. :)


 oh yeah! Pesa sempre come una sassata su un tavolo di cristallo?
Non lo so, l'occhiata è stata appunto rapidissima. :) Ma onor del vero
il peso non mi è mai sembrato un difetto che le appartenesse.


 parte. Il grosso della libreria serve a fare query (appunto :) sul DOM,
Già, e la parte fondamentale è la possibilità di fare le query con i
selettori CSS. La qual cosa, si spera, diventerà presto uno standard
implementato nativamente dai browser (magari i miei nipotini faranno
in tempo ad assistere all'evento):
http://www.w3.org/TR/selectors-api/


 erano una 60ina di KB, AFAIR...
Beh, non compressi presumo. Anche jQuery si assesta sui 55 e
spiccioli, se ricordo bene, ma "compressa" va sui 20. E poi,
laddove sussistono librerie come YUI, dojo e via dicendo, 60
kappa non sarebbero neppure 'sta tragedia. :)


 performanti.
Verissimo. Una ottima non c'è. Hanno tutti vari difetti ed anche a me
non convincono completamente. Alle volte mi stupisce come ci siano dei
difetti macroscopici e non vengono sistemati. Però se devi fare
un'applicazione, tipo questa:
http://extjs.com/deploy/ext/examples/layout/feed-viewer.html
fare tutto da zero è molto molto lungo.
Per "competere" intendo che quelle librerie in genere sono molto più
testate di quanto tu possa fare da solo. Ad esempio, io su Safari, non
testo mai nulla, quelle librerie in "teoria" :-) ti garantiscono anche
il supporto per browser di nicchia.
Io ho provato yahoo, dojo e spry. La prima è sovra ingegnerizzata e
lenta, la seconda è documentata molto male ma per i widget utilizza
l'approccio dichiarativo (i tag) piuttosto che imperativo. Mi sembra
un'ottima cosa, implementata anche da spry che però è un pò lenta in
quanto usa xpath cross-browser e non nativo ed aveva alcuni limiti su
certo xml.
Nonostante questo appoggiarsi ad una e piegarla un pò alle proprie
esigenze può far risparmiare molto tempo.

 faccia più.
E' vero, hai ragione. Però a differenza delle altre non usa i
"namespace".

 esigenze può far risparmiare molto tempo.
Aspetta, dipende cosa intendi. Se con "piegarla", intendi modificarne
il sorgente, non mi trovo d'accordo. Se decidi di utilizzare qualcosa
di terze parti, e mi riferisco alle librerie di cui sopra, sarebbe il
caso che non facessi modifiche. Questo perché avresti problemi con le
successive versioni delle stesse.
Diversamente, è se decidi di iniziare a usare librerie del genere, ma
con lo scopo di arrivare a qualcosa di tuo (come sempre dipende dallo
scopo personale che uno si prefigge). Allora le modifiche che apporti
le fai nell'ottica di non seguire le successive versioni, perché alla
fine otterrai qualcosa di tuo. Usi, insomma, quella libreria come una
sorta di "banco da lavoro".
-- 
~ "Non sono solitamente un uomo che prega,
ma se sei lassù, per favore salvami,Superman."
(Homer Simpsons)

 esigenze può far risparmiare molto tempo.
Aspetta, dipende cosa intendi. Se con "piegarla", intendi modificarne


 "namespace".
Beh, parlavamo dell'estensione dell'Object. Se vogliamo metterci a
elencare tutti i difetti che ha Prototype, o jQuery, o YUI... e si
fa notte. :)
-- 
~ "Non hai veramente capito qualcosa fino a quando non sei in grado di
spiegarlo a tua nonna."
(Einstein)

Ciao.
Che ne pensate di 
http://mootools.net/
leggero modulare veloce ben documentato
ed ad una prima occhiata ben implementato
ah l'autore è pure italiano altra cosa marginale
il sito mi fa impazzire ;)

 il sorgente, non mi trovo d'accordo.
No, assolutamente. Intendo di prendere quello che c'č di buono e magari
usare un'altra cosa per quello che manca. In quest'ottica bisogna usarne
di piccole e "namespaced". JQuery č un ottimo candidato.



60 kappa ormai fanno ridere :-)
Rimane però il fatto che se devi fare una "Rich Application", Ajax
rimane comunque la scelta che occupa meno banda. L'alternativa
Flex/Flash sono sempre più KB.
E poi oggi non è più una questione di banda, ma di intensità di calcolo.
Il problema non sono i 200 kb, ma la cpu al 90% :-)


 JQuery è un ottimo candidato.
"jQuery". Ce l'hai con "JQuery", eh. :)
-- 
~ Tenete la morte lontano dalle strade. Guidate sul marciapiede.

 E poi oggi non è più una questione di banda, ma di intensità di calcolo.
Con me stai sfondando una porta aperta, lo sai, è quello di cui mi son
lamentato nelle librerie attuali. :)
-- 
~ "Lo  dice il  buon senso, ma il buon senso non è uno  standard".
(Jeffrey Zeldman)

 Che ne pensate di 
http://mootools.net/
Interessante, non lo conoscevo.
Una curiosità: come mai tutti questi framework usano il '$' per wrappare 
la getElementById? E' uno standard, un'abitudine, una moda... ?
Ciao,
Paolo

 trasferire porzioni di html e non dati.
Quoto.
Però c'è da dire (so che è brutto) che è anche comodo...
Ciao,
Paolo

 trasferire porzioni di html e non dati.
Beh, l'importante è che non inviino *solo* porzioni di HTML. :)


 "jQuery". Ce l'hai con "JQuery", eh. :)
No, per carità. E' che ho dato un'occhiata al libro dell'autore delle
librerie
http://www.amazon.com/Pro-JavaScript-Techniques-John-Resig/dp/1590597273/
e mi sembrava ben fatto, poi ho visto un suo video
http://video.yahoo.com/video/play?vid=410472
ed infine ho scoperto che lavora alla Mozilla Foundation. Quindi mi è
simpatico :-)
La perplessità sulle librerie è che snaturano un pò javascript e poi la
loro ossessione per il chaining.
Ciao.


 la getElementById? E' uno standard, un'abitudine, una moda... ?
Se leggi all'inverso quello che hai scritto, ti rispondi da solo. :)
E' una moda, che poi è diventata per i più un'abitudine. E, dato che
lo stanno appunto usando "tutti questi framework", si può anche dire
che ormai è uno standard "de facto".
Standard per quel genere di librerie, eh, in quel contesto, ci tengo
a precisare :)



Il primo è stato prototype. Inizialmente lo trovavo osceno, ormai mi
sembra che sia diventato quasi uno "standard" anche le librerie 
ajax.net
della MS hanno $
Poi ho visto anche $$ che non mi ricordo più cosa facesse :-)
Ciao.


 Però c'è da dire (so che è brutto) che è anche comodo...
Beh, io non lo trovo sbagliato di per sé. E' sbagliato se si va ad
usare XHR *solo* per inviare porzioni di codice HTML e viene fatto
pure male; così che si finisce per generare spaghetti-code.
Personalmente preferisco usare XHR per inviare altre cose (oggetti
JS, XML), ma ho implementato comunque la gestione del codice HTML,
in modo che se mi capita almeno me lo son gestito ammodino. :)
Ma è raro. Al più uso un'iframe.


 verticalmente sul client.
Sinceramente non lo so, mai provato a lavorare con prototype. :)


 dei laptop, ed il 7.7% dei desktop. Se questa è nicchia...
La cosa mi interessa moltissimo, che fonti usi per le statistiche
sull'uso dei browser? In genere tutte quelle che ho visto mostrano
Safari oscillare attorno tra 1.5 e 2.3 %. A me sembra nicchia.
C'è poi da dire che fino a quando la Apple non mi farà una macchina
virtuale free per testare Safari (come fa la MS per IE 6) sarà molto
dura supportare adeguatamente quel browser.

 dura supportare adeguatamente quel browser.
Concordo con quanto ti ha risposto il Balestra su questo punto;
aggiungendo che le alternative, comunque, ci sono. Negli ultimi
mesi ho visto moltissimi dei miei amici e collaboratori passare
a MacBook Pro, come macchina di sviluppo, sia per usare Windows
che OSX. Io lo scorso anno mi sono preso un iBook, ed è un vero
gioiellino. Alternativamente, esiste sempre il Mac mini.
E' ovvio che non sono "free", ma se fai un certo mestiere, devi
possedere anche gli strumenti adeguati per farlo. A meno che tu
non programmi su web per diletto, ed il pane te lo guadagni con
tutt'altro ovviamente; ma allora non è il tuo mestiere.
-- 
~ "L'amore è la risposta.
Ma mentre aspetti la risposta,
il sesso fa nascere alcune buone domande."
(Woody Allen)

 dei laptop, ed il 7.7% dei desktop. Se questa è nicchia...
Si, d'accordo, ma siamo realisti. A tutt'oggi, se qualcuno mi dovesse
offrire una percentuale sulla vendita di un software che realizzo, ma
dovessi svilupparlo monoplatform, non ci penserei due volte: lo farei
per Windows. Ha ancora una base d'installazioni mostruosa, nonostante
gli utenti Apple siano aumentati nell'ultimo periodo (foss'anche solo
nel mio "piccolo mondo" di amicizie informatiche).
-- 
~ "La realtà è ciò che, quando smetti di crederle, non va via."
(Philip K. Dick)

 No, per carità. 
Mi sono spiegato male forse, intendevo dire che il suo nome è "jQuery"
con la "j" minuscola, mentre continuavi a scriverlo con la "J". ;)
-- 
~ "Ho sciupato il tempo, e ora il tempo sciupa me."
(W.Shakespeare, "Riccardo II")

 Come lo è per me dover pagare la licenza di Windows solo per IE.
Per IE 6 non devi pagare nessuna licenza di windows, la macchina
virtuale è free e va anche su MAC.
Ed è quello che dovrebbe fare la Apple. Altrimenti che si lamentino
pure.
Ciao.

Scusate, ho letto tutto il thread (molto interessante), ma alla fine
la mia domanda resta senza risposta.
M.

 la mia domanda resta senza risposta.
Se hai letto tutto il thread, tutti i partecipanti hanno più o meno
espresso la medesima opinione: tra le due, è consigliabile jQuery.
-- 
~ "When you have eliminated the impossible, whatever remains, however
improbable, must be the truth." (S.H.)

 espresso la medesima opinione: tra le due, è consigliabile jQuery.
Mi sono perso tra le risposte.
Grazie.

 Mi sono perso tra le risposte.
Me lo immagino, anzi: Complimenti per aver comunque seguito l'intero
thread; io al tuo posto non so mica se l'avrei fatto. :)
-- 
~ "L'arte non riproduce cio' che e' visibile,ma rende visibile cio'
che
non  sempre lo e'" (Paul Klee)

 certo... *se* devi svilupparlo monopiattaforma.
Ovviamente, ma il punto è che fintanto che il dubbio non sussisterà,
fintanto che - commercialmente parlando - farlo monoplatform per Win
assicura comunque tutto il guadagno necessario per via delle basi di
quest'ultimo installate.. il resto è tranquillamente da considerarsi
di "nicchia". Perché commercialmente parlando, non ha rilevanza. Non
così sensibile, almeno, da giustificarci un investimento.
Questo per essere obiettivi. Soggettivamente parlando io la penso in
altri termini e lo sai. :) Ma non sono termini commerciali, sono più
che altro "morali". ;)
-- 
~ "Ciò che il cuore conosce oggi, la testa comprenderà domani"
(Seneca)

 la getElementById? E' uno standard, un'abitudine, una moda... ?
Una ventina abbondante di caratteri in meno.
Jquery lo usa come shortcut per l'oggetto/namespace jquery, quindi per un  
decina circa di cose. E' un default rimappabile a piacimento ( $j, pippo,  
quello che vuoi tu ).
La scelta del $ è probabilmente derivata non solo dal fatto che è un  
carattere tradizionalmente usato in vari linguaggi ( perl, php, bash ) per  
indicare le variabili, ma anche dal fatto che è valido in js per i nomi di  
oggetto/variabile/funzione e che era (fino all'avvento di questi  
framework) scarsamente utilizzato (meno probabilità di rompere librerie  
già esistenti).
Tac
-- 
Using Opera's revolutionary e-mail client: 
http://www.opera.com/mail/

 JQuery.
Ho usato un poco tutti e due e con jquery vivo particolarmente contento.
Prototype ha una serie di utilities che jquery di default non ha (sempre  
che non me le sia perse, una su tutti il function.bind() di prototype), ma  
in giro trovi plugin interessanti e benfatti.
Esiste anche una specie di equivalente di scriptacolous chiamato  
Interface, che sembra decisamente carino. (spero solo sia programmato con  
un minimo di cristo in piu')


 nulla di più).
Quello non dovrebbe essere un problema. La sicurezza và gestita client  
side.


 Safari sarebbe "di nicchia"?
Decisamente di nicchia, per ora.


 Come lo è per me dover pagare la licenza di Windows solo per IE.
Un'attimo. Windows gira su qualsiasi computer, così come linux (con  
qualche grana, ma ci provano).
Osx gira solo su apple per scelta loro, altrimenti lo installerebbero in  
molti sul pc.
La "nicchia" è una scelta precisa della apple, pochi ma fighi (I'm a pc,  
I'm a mac). A me stà bene, ognuno fà quel che vuole, ma laddove non ho gli  
strumenti per testare non li ho, e non pago di mia tasca per farlo, a meno  
che non abbia interesse a farlo.
L'azienda per cui lavoro non è propriamente piccola (per carità, non è  
fiat o ibm..), ma un Mac per il testing non ce lo dà. Ed alcuni di loro  
sono Mac user. Se non hanno interesse commerciale a spendere 500/600 (i  
mac mini se non erro stanno su quella cifra)  euro per testare i siti sui  
mac, perchè dovrei tirar fuori la grana dal conto in banca (non dirmi che  
avere un mac è un'esperienza fantastica - non discuto ma ognuno fà le sue  
scelte).
Se uno è freelance o è a capo di un srl ci può pensare. Ma a livello  
commerciale, in Italia, da quel che ho visto io: la compatibilità Mac è  
scarsamente considerata quando addirittura non viene marchiata come non  
rilevante in senso assoluto.
Detto questo: utilizzo le famose librerie js (prototype, jquery) già  
pronte anche per scansare quel tipo di problemi lì. Ma non ci fossero  
continuerei sulla stessa medesima strada fino a che: a) la apple non si  
decide a rendere accessibile il suo so a tutti (a pagamento per carità, ma  
non lo farà mai lo stesso visto che è un incentivo non da poco per  
l'acquisto del suo hardware), il Safari non raggiunge il 38% almeno dello  
share (e se continuano su questa strada non lo faranno mai).
Da ultimo: tutti si lamentano che Vista costringe gli utenti a comprare un  
pc apposta............


 utilizzando Spry s'invalidano le pagine?
Incredibile ma vero è possibile estendere il doctype, addirittura inline  
(ad esempio aggiungere target _blank ad un doc type strict).
Per alcuni versi è un controsenso farlo, perchè cmq si modifica quello che  
è stato creato per rappresentare uno standard e rendere tutti i documenti  
uguali nella struttura. C'è anche da dire che quantomeno la modifica al  
doctype è documentata (per chi la sa leggere - e non sognatevi di  
includermi nella categoria).


 Decisamente di nicchia, per ora.
Per esperienza, su una ventina di siti "commerciali" (quelli che ci hanno 
chiesto di attivare le statistiche) Safari e` mediamente sotto il 2%.
Alcuni utenti Mac usano Firefox (lo vedo perche` i Mac sono intorno al 3%, 
quindi per forza qualcuno deve usare Firefox o Camino con motore Gecko, e 
Camino rientra negli "other" nelle statistiche, quindi non so la quota 
precisa, meno dello 0,5%).
Firefox fluttua tra il 5-6% di alcuni siti e il 15-18% di altri.
In Italia sembra che IE6 la faccia ancora da padrone assoluto. Pochissimi 
usano IE7.
Bye.

 L'importante è crederci.
Gia`.
Le statistiche non sono il parametro assoluto, ma danno un'idea. Se anche 
sono sbagliate del doppio, Safari non raggiunge comunque il 4%.
Se vuoi un'altra statistica, tra quelli che conosco, gli utenti Linux 
desktop sono circa dieci volte tanto gli utenti Apple. :P
Bye.

 ogettive di vendita di Bloomberg.
Che sono tutto tranne che corrette e oggettive.
Intanto tengono conto del fatturato, e non del numero di unita` vendute.
Il notebook piu` economico della Apple costa oltre 1000 euro, il piu` 
economico di Dell (che non e` in classifica, e mi pare strano) viene meno 
della meta`. Quindi potenzialmente si potrebbe quasi dimezzare quella 
percentuale, parlando di unita` vendute.
Sui desktop ancora peggio, visto che se ne trovano da 200 euro, ma 
soprattutto molti comprano ancora componenti e non PC completi. E anche 
qui la percentuale puo` essere ridotta a meta` se non a 1/3.
Bada che non sto dando contro a Apple, non prenderla come una guerra di 
religione.
Si stava parlando di javascript, e se valga la pena sbattersi per coprire 
una certa percentuale di utenti. E se gli utenti si mascherano da IE ma 
non ne supportano il JS, peggio per loro, non appaiono nelle statistiche e 
quindi nessuno fara` mai codice per loro finche` stanno sotto il 2%.
Firefox ha un plugin per mascherarsi da altri browser, da installare a 
parte. Opera ha smesso di mascherarsi di default da IE, bisogna attivarlo 
manualmente. Non so Safari cosa faccia, onestamente.
Ma finche` gli utenti continueranno a mascherarsi, la maggior parte dei 
web-developer li ignoreranno e continueranno a sviluppare per IE e 
Firefox, e al limite per Opera (che ha quote apparenti maggiori di Safari, 
ora come ora).
Bye.

 (ad esempio aggiungere target _blank ad un doc type strict).
Stavamo parlando di Spry: questo aggiunge unicamente un namespace, e
sebbene in XML sia un approccio corretto in XHTML non ne permette la
validazione.
Come ho scritto nei post precedenti, l'aggiunta di attributi era una
pratica che si faceva da anni, compresa quindi la modifica della DTD
inline o meno.
Se spulci negli archivi di questo NG troverai post a riguardo, con i
vari pro e contro.
Il tutto, sempre per causa dell'XHTML che non viene considerato come
un linguaggio XML, né dal validator né dai browser (quest'ultimi per
lo più lo rimappano internamente come "HTML").
-- 
~ Se i sintomi persistono, insultare il medico.

 Leggi meglio.
Giusto.
Note: figures are for "brick and mortar" retail sales only and do not
      include direct sales, sales from Wal-Mart or warehouse clubs.
Per quello Dell (credo il maggior venditore di notebook al mondo) non c'e`.
Inoltre tratta solo il mercato americano.
Nemmeno Acer e Asus compaiono, che in Italia hanno una fetta enorme.
Rimangono valide le mie considerazioni finali.

 su questi dati trovo sempre atteggiamenti tanto religiosi.
Sono felice che tu abbia letto tutto il mio messaggio, dove finivo con:
Si stava parlando di javascript, e se valga la pena sbattersi per coprire 
una certa percentuale di utenti. E se gli utenti si mascherano da IE ma 
non ne supportano il JS, peggio per loro, non appaiono nelle statistiche e 
quindi nessuno fara` mai codice per loro finche` stanno sotto il 2%.
...


 Ossimoro o semplice errore?
Errore, orrore. Server side.


 Miopia, interesse o sempice stupidità?
Software di statistiche e una semplice calcolatrice.


 per indicare le variabili  [...]
E' questa la cosa che mi lascia perplesso: usando un motore di 
templating che usi il $ come identificatore di variabile, mi trovo di 
fronte a un conflitto con i framework javascript che lo usano con lo 
stesso scopo.
Nulla di grave, ma forse usare qualcosa di meno "sfruttato" non sarebbe 
stata una cattiva idea... :)
Ciao,
Paolo

 potrebbe. Non ne avrebbe il tempo, non glielo lascerebbero fare.
Wow, hai appena descritto gli ultimi miei 2 posti di lavoro :(
E aggiungerei che le suddette librerie devono essere note ed essere
padroneggiate ancora prima di pensarlo...