Newsgroup: it.comp.lang.delphi
Titolo: IW : sara' vera gloria?

Salve a tutti.
Lurkando lurkando ho notato che pochi post fa qualcuno denigro' IW per D7
dicendo che e' una cagata ed invitando ad usare PHP.
Io sto usando la versione 7.0 di IW con dei controlli TMS aggiuntivi e mi
ci trovo bene. Creo i file HTML con Dreamweaver e li uso in IW come
template. 
Vengo da una terrificante esperienza con JSP in cui dovevo scrivermi
l'HTML a manina manco fossimo ancora ai tempi del Clipper e qualsiasi cosa
e' meglio di quello. 
Ho provato ad usare anche PHP, ma quando ho visto che dovevo usare delle
funzioni ad hoc per accedere a Firebird ho smesso.
Non intendo scatenare una "guerra di religione". Sono interessato ad una
discussione tecnica con tanto di dati oggettivi (se possibile) e non
soggettivi.
Le mie domande sono: 
- IW puo' sopportare carichi di lavoro pesanti (migliaia di richieste)?
- in cosa PHP e' meglio (se lo e') di IW?
- in cosa IW e' meglio (se lo e') di PHP?
TIA a chiunque avra' la cortesia di rispondermi.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Le mie domande sono [...]
Non ho una ferrata esperienza con IW, ma dal poco che ho potuto vedere è 
gravato da diversi problemi.
Ci tengo a specificare la mia limitata esperienza (qualche semplice demo 
per testare i meccanismi) poichè alcuni dei difetti che ho riscontrato 
potrebbero avere, in qualche modo, una risoluzione che però io non sono 
stato in grado di trovare.
Tra i difetti più gravi riscontrati, c'è un'eccessiva pesantezza degli 
script JavaScript restituiti all'interno delle pagine IntraWeb.
Rispetto ad altri tool comparabili, come può essere 
ASP.NET
, c'è un 
distacco maggiore dal "mondo HTML" poichè si tratta di un pacchetto 
destinato all'uso da parte di chi vuole realizzare applicazioni fruibili 
con il web ma, tuttavia, senza conoscenze specifiche del web ma 
esperienza sulla VCL.
Alcune applicazioni complesse che ho potuto vedere, realizzate con 
IntraWeb, riuscivano a restituire pagine nell'ordine dei 200KB, anche 
con un numero di informazioni basse: questo non è consultare una pagina, 
ma un vero e proprio...download! :-|
Senza considerare che la quantità di codice JavaScript presente rende 
davvero lenta l'interazione con il browser che deve interpretare gli 
script, spesso duplicati per ciascun oggetto invece che "accumulati" e 
parametrizzati...
Insomma, IW rappresenta senz'altro un'idea interessante e può essere 
valutata per quelle esigenze specifiche in cui si abbia a disposizione 
un server Apache su Windows o su Linux; tuttavia, nel caso si possa o si 
debba usufruire di IIS, credo che 
ASP.NET
 fornisca migliori risultati 
con lo stesso principio: familiarità nel nome e nella tipologia di 
controlli applicati al web, ma con la possibilità di intervenire 
maggiormente su stile, script e altro ancora.
P.S.: non ho capito come mai ti hanno spaventato le procedure di PHP... 
:-) è senz'altro uno dei linguaggi più immediati con cui realizzare 
pagine web ed è molto utilizzato.
-- 
Marco «Alka» Breveglieri	
http://www.marco.breveglieri.name
  «bvmcnxsjlkhròhyeq, potrei scrivere a questo punto,
   se mi addormentassi sui tasti» (Daniele Luttazzi)

 - in cosa IW e' meglio (se lo e') di PHP?
IW non è "meglio", dal mio punto di vista, in nulla rispetto a 
nessun altro sistema di scripting server-side.

 nessun altro sistema di scripting server-side.
-- 


 pagine web ed č molto utilizzato.
Mi sono spiegato male.
Venivo da un'esperienza JSP in cui non si sapeva ancora, o meglio il
sempre santificato cliente non sapeva ancora, quale engine di database si
sarebbe usato alla fine (una delle scelte era DB2 su OS/390 :( ). Da JSP
mi veniva molto semplice cambiare la stringa di connessione del JDBC e
adattarmi, senza dover riscrivere altro. 
Quando ho visto che in PHP avrei dovuto riscrivere tutte le procedure per
cambiare i vari ibase_connect ecc. ho lasciato perdere e ho continuato ad
usare JSP. Scripting per scripting, tanto valeva continuare ad usare
qualcosa col quale, bene o male, avevo fatto esperienza. Avevo letto che
anche in PHP c'e' una cosa simile al JDBC ma avevo paura comportasse un
calo nelle prestazioni.
In ultima analisi avevo sempre associato PHP a MySql e non avevo alcuna
intenzione di usare MySql che, all'epoca, mancava di alcune
caratteristiche che invece IB/FB ha sempre avuto. Ma questo discorso
rientra nella "guerra di religione" che non voglio scatenare. Fai finta
che non abbia detto nulla.


 Beh, ma col 5 non piu'. 
Quota bene quello che scrivo (non mettere punti dove non ce ne 
sono).  Io parlo di MySQL _e_ PostgreSQL, preferendo quest'ultimo.
Che vi sia o meno un supporto nativo è un'altra storia, PHP e 
MySQL sono sempre stati un'accoppiata molto comune e lo sono 
tuttora.  MySQL possiede, ormai tutto ciò che serve per essere un 
DBMS relazionale (per quanto il concetto di "relazionale", per i 
teorici dei DB, è ancora lungi dall'essere rispettata dai DB 
commerciali).

 perdere, ormai).
???????????????Commerciali?????????????? 
Ma i vari IBQuery, IBDatabase... cos'hanno che non ti vanno bene?
A me pare siano piu' che adeguati.


 Ma i vari IBQuery, IBDatabase... cos'hanno che non ti vanno bene?
TIBQuery e TIBDatabase sono i componenti della suite IBX (che 
avevo detto di scartare), che hanno moltissimi difetti (non ultimo 
un consumo eccessivo di memoria).  Oltretutto Jeff Overcash, lo 
sviluppatore di questo set di componenti, non è intenzionato a 
renderli portabili per Firebird.  I componenti migliori che 
conosca sono i FIBplus.

 Cosa vuoi dire? E' lento nel rispondere o non risponde proprio?
Avevo saltato questo punto: IW costruisce, in fin dei conti, dei 
moduli per il Web server, quindi in teoria, se c'č un limite, č 
legato al server.  Il problema č che IW non scala facilmente verso 
l'alto, per esempio per il load balancing bisogna usare dei tool 
esterni e commerciali anch'essi (vedi un certo software 
dell'Octagate che venne comprato dal nostro cliente).  Il problema 
  grande di IW č il prezzo (a PHP si accede gratuitamente) e la 
mancanza dei sorgenti che ha fatto sě, ad esempio, che non 
potessimo capire dove si annidasse un errore legato alla visual 
form inheritance.

..mah! io ho fatto 2 applicazioni una su linux/mysql e l'altra su
win/firebird entrambe su apache 2 e mi sono trovato
benissimo..certamente la parte web non era molto sofisticata mentre lo
era molto di piu la parte applicativa...personalmente l'ho trovato
molto veloce nei tempi di risposta, sicuramente piu di JSP e ASP

 monotask wrote:


Io sto usando questi componenti con D7 e Firebird 1.5 e non mi danno
nessun tipo di problema tanto a casa quanto in ufficio. 
Devo aspettarmene?


 monotask wrote:


Io non ho mai potuto usare il refresh parziale malgrado la documentazione
ne parlasse come della panacea per tutti i mali.
Problemi di gioventu' di IW? 


 Devo aspettarmene?
La compatibilità con FB non è assicurata (essenzialmente perché 
non voluta).

 ...mah! io ho fatto 2 applicazioni una su linux/mysql e l'altra su

Su JSP ci posso mettere la mano sul fuoco! La mia applicazione JSP aveva
tempi di risposta elefantiaci ma questo dipendeva dal fatto che era basata
su IB e quindi c'erano due strati (JDBC e IntraClient) tra la pagina ed il
database vero e proprio. A volte non si connetteva nemmeno dando errore.


 maniera discutibile.
Puoi spiegarti meglio? Cosa significa "...in maniera discutibile"?


 dicendo che e' una cagata ed invitando ad usare PHP.
Perchè PHP.....
1) PHP è nato per il web ed ha una marea di funzioni specifiche per 
quell'ambiente.
2) PHP è supportato da una tantissimi provider (a prescindere dal SO)
3) PHP è semplice da usare (ma questa tutto sommato è soggettivo)
4) PHP ha un supporto ai database notevole, si va dai driver specifici 
per i maggior database (Oracle, Postgresql, Mysql, sybase, Interbase 
ecc.. ecc..), in più puoi usare i driver ODBC
5) E' notevolmente diffuso e questo ti facilita nel trovare aiuto 
(
http://www.php.net/usage.php
)
6) E' facile reperire esempi e stralci di codice da studiare.
7) Molte delle applicazioni web le trovi già fatte da cms a quello che 
tu vuoi.
Detto tutto ciò, con php puoi anche sviluppare applicazioni desktop 
tramite bindings per le GTK+, ma indubbiamente in questo campo non 
brilla, come delphi 7 non brilla in campo web.
P.S.
Qualche mese fa, se non erro su linux&c, c'èra un articolo in 3 puntate 
sullo sviluppo di applicazioni web con free pascal (il linguaggio che 
usa lazarus, giusto per capirci). Bell'articolo, molto interessante, ma 
quanti lo usano per sviluppare sul web?
Ogni linguaggio ha un suo punto di utilizzo specifico o in cui eccelle.
Ciao
Gianni

 Gianni
Grazie, mi avete quasi convinto. Forse molto piu' di quasi... :)


 Su JSP ci posso mettere la mano sul fuoco! [...]
Non sono convinto che si possa generalizzare a livello assoluto le 
prestazioni di JSP da te riscontrate in un caso particolare. :-/


 prestazioni di JSP da te riscontrate in un caso particolare. :-/
Che versione di Tomcat hai usato? Se hai usato Tomcat, ovviamente.
A me e' capitata tra capo e collo la 3.2 ed era un vero disastro. Pensa
che rispondeva ad una richiesta di Mozilla/IE5 ma non ad una di IE6.
Aggiornato a Tomcat3.3 tutto funzionava regolarmente.
D'accordo, ho generalizzato ed ho fatto male. Forse le nuove versioni di
Tomcat hanno reso JSP velocissimo e scattante. Per me non lo e' mai stato.


 quanti lo usano per sviluppare sul web?
Concordo.  Il problema è che molti (Jilani Khaldi per primo) 
tendono ad usare il proprio linguaggio preferito comunque e sempre 
e pensare che sia ottimo per tutto.

 cambiare i vari ibase_connect ecc. ho lasciato perdere e ho continuato ad
Vero ma ci sono alcune librerie di astrazione che ti consentono di 
superare questo ostacolo, una per tutte adoDB 
(
http://adodb.sourceforge.net/
) che e' ormai piuttosto stabile e matura.
Si porta dietro qualcosa di troppo, ma si puo' rimuovere.
Con IB e Firebird magari potresti trovare qualche problema, perche' da 
sempre db engine di nicchia e quindi essendo meno usati di altri la 
libreria e' certamente meno testata.
Comunque io sinora con Firebird 1x non ho incontrato particolari 
problemi e se pure fosse mi tranquillizza molto che i sorgenti siano li' 
a portata di editor.
Per il resto mi sento di condividere in toto quanto detto da Marco e 
Andrea, rimarcando che e' meglio scrivere html a manina, magari 
scrivendosi qualche funzione per le cose piu' noiose, che avere come 
risultato le pagine prodotte da certi framework.
-- 
L'ignoranza e' l'inizio del sapere, il sapere e' l'inizio della 
saggezza, la saggezza e' la consapevolezza dell'ignoranza.  {W. Rotsler}

 Tomcat hanno reso JSP velocissimo e scattante. Per me non lo e' mai stato.
Mi riferivo al fatto che visitando siti basati su questa tecnologia, 
anche molto complessi, non ho notato problemi di sorta; inoltre, ho 
sempre letto buone recensioni riguardo le prestazioni di JSP che, tra 
l'altro, è stato usato più volte come riferimento da Microsoft per 
vantare le performance di 
ASP.NET
 leggermente superiori al confronto.
Le "prove tecniche di laboratorio" che ho fatto io con Tomcat non sono 
degne di poter essere utilizzate per esprimere giudizi. :-)
Ciao,
   Marco.


 risultato le pagine prodotte da certi framework.
E io, povero illuso, che pensavo che i tempi del Clipper fossero
definitivamente passati.
Mi mettero' di buona volonta' a reimparare quel poco di PHP che avevo
studiato e dimenticato. D'altronde se lo usano in tanti un motivo ci
sara'...


 degne di poter essere utilizzate per esprimere giudizi. :-)
L'esperienza malvagia che ho avuto con JSP era anche dovuta al fatto che
non potevo materialmente mettere mano sul server per ottimizzarlo. Sapevo
che si poteva usare IIS (il cliente usava Windows) per la parte non JSP e
lanciare Tomcat solo quando serviva, ma non potevo fare questa
ottimizzazione. Ero costretto ad usare Tomcat anche come server Web e
questo ha notevolmente influito sulle prestazioni. Non dubito che una
versione recente di Tomcat ed un corretto settaggio IIS->Tomcat o
Apache->Tomcat porti a prestazioni maggiori.


Marco «Alka» Breveglieri	
http://www.marco.breveglieri.name
	Ciao
	MassimoB
 
---------------------------------
http://www.massimobeschi.it/
---------------------------------
Se tu pagare come dici tu ...
Io lavorare come dico io ...
Se tu pagare come dico io ...
Io lavorare come dici tu ...
---------------------------------

 io avrei spinto un pň di piů ;)
Poteva spingere fino a farsi uscire i muscoli dalle braccia. 
NET l'ho provato sia con D8 sia con D2005. 
Se sono tornato indietro addirittura a IW un motivo ci sara' pure, no? 
Lo vedo bene come linguaggio multi-piattaforma se Mono si sveglia un po'.


 io avrei spinto un pò di più ;)
Non era mia intenzione convincerlo di nulla. :-)
-- 
Marco «Alka» Breveglieri	
http://www.marco.breveglieri.name
  «bvmcnxsjlkhròhyeq, potrei scrivere a questo punto,


Marco «Alka» Breveglieri	
http://www.marco.breveglieri.name
	Ciao


Lo vedo bene come linguaggio multi-piattaforma se Mono si sveglia un po'.
mono sta andando avanti ... piano ma prosegue lo
sviluppo ... meglio che vadano piano e facciano le cose
per bene che tirino fuori una cosa che in TEORIA fa
tutto quello che dicono ma in pratica no.
Comunque dovrebbero essere alla release 1.0


 Comunque dovrebbero essere alla release 1.0
Release 1.1.8
A me e' capitato con la Mandrake 10.1 che non partisse nemmeno sotto Gnome
e funzionasse perfettamente sotto KDE. 
Considerato che il capoprogetto Mono e' anche colui che ha progettato
Gnome...


 Lo vedo bene come linguaggio multi-piattaforma se Mono si sveglia un po'.
Mono è sveglio, ma è indubbio che i vantaggi di sviluppare 
ASP.NET
 siano 
maggiori se ci si basa su soluzioni Microsoft.
Se sei interessato al multipiattaforma, per il momento escluderei 
ASP.NET
. In caso contrario, non vedo perchè preferire IW, secondo me non 
sono nemmeno due tecnologie paragonabili (a livello architetturale).
Ciao,
   Marco.
-- 
Marco «Alka» Breveglieri	
http://www.marco.breveglieri.name
  «bvmcnxsjlkhròhyeq, potrei scrivere a questo punto,


    Marco.
Ciao.


 Ah, i bei tempi del Clipper...
?

 ?
NO! Non mi dire che non ha mai sentito parlare del Clipper, il compilatore
per applicazioni dBIII/dBIV?
Nelle ultime versioni si stava addirittura C++izzando.
Scrivevi applicazioni tramite Norton Editor o l'Edit del DOS, linkavi e 
compilavi.
Quelli si' che erano bei tempi!


 per applicazioni dBIII/dBIV?
Certo che lo conosco (e mi ricordo della mitica Summer '87), ma 
non capisco proprio in che senso fossero bei tempi.

 Quelli si' che erano bei tempi!
Mah... io preferisco quelli di adesso. :-D
-- 
Marco «Alka» Breveglieri	
http://www.marco.breveglieri.name
  «bvmcnxsjlkhrňhyeq, potrei scrivere a questo punto,


 monotask wrote:


Io avevo circa una quindicina d'anni meno, tu non so.
Mi basta per pensare a quell'epoca come a "bei tempi".


 poi mai! :-)
E comunque anche la "C++zzazione" del Clipper era abbastanza 
discutibile.  E' vero che si trattava dei primi anni di OOP 
applicata alla grande massa dei linguaggi, ma è anche vero che i 
tentativi fatti con il Clipper erano abbastanza ridicoli.
Con Clipper sono state fatte sicuramente un mare di applicazioni 
ben funzionanti, ma anch'io preferisco i tempi di oggi ;-)

 Mah... io preferisco quelli di adesso. :-D
Programmatorialmente... programmaticativamente... Beh, dal punto di vista
della programmazione puo' darsi. Ma quando riguardo le foto dell'epoca e
scopro che avevo ancora dei capelli... :'(


 Mi basta per pensare a quell'epoca come a "bei tempi".
Io no, perché allora dovevo sopperire alle mancanze del Clipper 
scrivendo librerie esterne in C e la cosa non è che mi 
entusiasmasse più di tanto.

 entusiasmasse piů di tanto.
Beh, era una sfida, o no?


 Beh, era una sfida, o no?
No, e comunque smettiamola, siamo off-topic.

 monotask wrote:


Hai ragione, siamo OT di qualche decennio. Chiudo.
