Newsgroup: it.comp.java
Titolo: [OT]Frames, Popup, JavaScript e... Applet... e il Web come VisualBasic!

Ciao,
Domandina... che spero sfoci in una discussione animata (e perché no...
anche polemica)...
Cosa pensate di sviluppare applicativi che fanno massivo uso di
+ Frames
+ Popup (ovvero finestrelle che si aprono su click)
+ Uso massivo di JavaScript
Come gestireste l'utente che vi chiede applicazioni web che si comportino
come applicazioni VisualBasic... esempio una combo in un form html che viene
popolata in funzione di altri controlli nello stesso frame... checkbox
intelligenti... controlli che si abilitano e disabilitano (compaiono e
scompaiono) a seconda di come sono valorizzati campi sul form o di altre
condizioni... E un sacco di roba simile... ?
Ciò implementabile spesso con il "ricarico" del form in combinazione di
Javascript su "onBlur", "onChange", "onLoad" e cose del genere. Conseguenza:
"applicazioni chiodo"... ciò è inevitabile?
Altro discorso per le Applet... io ho sempre cercato, ove possibile di
evitarle, per evitare problemi di plugin vari sul browser, e di distribuire
logica business sul client, ad ogni modo questa comincia a sembrarmi l'unica
soluzione (per quanto implichi problemi di sicurezza) per implementare
questo genere di logica (che trovo) assurda per applicazioni web. Ovvia
conseguenza (secondo me) di richieste fatte da gente che vuole "web" solo
perché fa figo, senza sapere cosa si può e non si può fare col web.
Web è un requisito, in queste applicazioni, per cui soluzioni come
Applicazioni Standalone sono già state bocciate... non so cosa si pensi
delle applet (ma tenderei a bocciarle già io, se non fossero rese necessarie
da certe strane richieste).
Mi piacerebbe leggere un po' di commenti per poi farne una sintesi da
sottoporre all'attenzione di chi si occupa dei requisiti delle applicazioni
web... come dire: "raccogliere i punti di vista" di altri programmatori (non
io... "ambasciator non porta pene")
Prometto di comportarmi bene :)
Help...
Jigi

 "applicazioni chiodo"... ciò è inevitabile?
Noi facciamo sempre presente all'utente che un'interfaccia web *non è*
una GUI e quindi
non si può pretendere che abbia tutte le funzionalità di una GUI.
Detto questo, valutiamo di volta in volta se una cosa conviene farla con
Javascript oppure no. Teoricamente si potrebbe fare tutto con HTML puro,
in pratica per certe cose Javascript rende l'applicazione più
funzionale.
L'esempio classico è quello delle due combo dipendenti l'una dall'altra:
tenendo conto che per fare funzionare il meccanismo devi precaricare
tutti i dati della seconda combo in un array, si valuta banalmente la
dimensione dell'array. Se ad esempio le due combo sono regioni e
province si usa
Javascript, se sono province è comuni non si usa per non appesantire
troppo la pagina e si sceglie un'interfaccia di tipo wizard in cui
l'utente sceglie prima la provincia, poi preme un pulsante "Avanti" e il
server gli genera la combo coi comuni di quella provincia.
Bisogna inoltre tenere conto del fatto che un uso pesante di Javascript
richiede più tempo per il testing perchè purtoppo ci sono differenze
nelle modalità di esecuzione da browser a browser.
In sintesi: Javascript sì, ma con prudenza.
Solo le mie 20 lire (nostalgia, nostalgia canaglia... :))
Ciao, Cris
-- 
Cristian Veronesi ><((((º> 
http://www.crpa.it
There are no good wars, with the following exceptions: The American 
Revolution, World War II, and the Star Wars Trilogy. (Bart Simpson)

Un'altro problema è la compatibilità dei browsers verso questi "cosi
strani"...
Non vorrei ridurmi a dover scrivere versioni differenti dell'applicazione
per ogni caso di browser (IE4,IE5,Netscape,Opera, Konquerror, Mozzilla...),
alcuni *con* Java e altri senza..., alcuni che supportano i frames e altri
che no... oppure che fanno cose strane coi frames (ho visto casi in cui le
richieste http venivano "doppiate" dal browser a causa di una cattiva
gestione del frames).
Il risultato è una babele ... l'azione sono spesso JavaScript che si
autocondizionano a seconda del browser, oppure generare risposte diverse
secondo l' "agent" del client... il che diventa spesso una complessità che
supera di molto la complessità dell'applicazione in se stessa. Risultato...
applicazioni lente, o non funzionanti...
Altro problema... mi devo imparare JavaScript? Essendo che è solo una
rottura, il mio rifiuto va oltre l'esigenza...
Il mio approccio "estremista" è spesso di implementare tutto in Java e mi
rendo conto degli svantaggi. Ma se il cliente non capisce che certe cose
'non si fanno' (come i bimbi...) allora si becca "l'applicazione chiodo"...
e i ritardi nelle consegne...
Per dirla tutta... secondo me queste cose sono la morte del web... La gente
si chiede perché tutto funzionava bene con i mainframes e le interfacce a
caratteri e perché oggi ci sono casini a sviluppare applicazioni web che
fanno ciò che prima facevano i mainframes... la ragione è, secondo me, che
il terminale faceva il suo mestiere (generare richieste e visualizzare
risultati) e il server anche (generare risultati)... tutto questo sarebbe
applicabilissimo al web (che funziona per definizione su "request" e
"response") se non fosse che poi ci sono queste "idee delle balle" come
JavaScript, Popup e Frames... tutta roba che non serve a un tubo in
applicazioni serie... solo a far fallire il progetto.
Io rimango dell'opinione di usare il subset di HTML compatibile tra tutti i
browser... personalmente, quando nessuno me lo vieta uso XHTML e ho
applicazioni che funzionano bene anche con lynx ed Explorer 3... anche a
costo di qualche rinuncia di logica sul client...
Ho fatto un plugin per JBuilder 4 (e superiori) che trasforma html in xhtml
e aggiusta gli errori e indenta i tag (ho trasformato il jtidy del w3c in un
opentool per Jbuilder). Mi piacerebbe che la gente pensasse che fare le
interfacce con dreamweaver non sia sempre l'approccio corretto all'html...
ma perché mai un'applicazione deve essere diversa per ogni browser che la
apre... e perché mai poi non deve funzionare... e perché la colpa ricade sui
programmatori quando chi fa i layout "fighi" è la causa di queste cose?
rgds...

 rgds...
devono proprio averti rotto i c***ioni, vecchio...
Dai, tieni botta un altro po', ormai č Natale!


Vedi considerazioni precedenti.
Ciao,
    Bruno.
|
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://bbruno.fasturl.it
|
| 
http://members.xoom.it/bbruno
| 
http://digilander.iol.it/bbossola
|

 io... "ambasciator non porta pene")
I requisiti delle applicazioni web non sono gli stessi delle applicazioni
wndows "standard". Il principio resta quello di una logica molto ristretta
nel lato client. Io dico che esistono già innumerevoli problemi sulla logica
"essenziale" (controlli sui campi, verifiche di congruità dei dati, etc...),
ma il problema di fondo è che nonostante tutti gli sforzi possibili è una
forzatura che non funziona. Alcune cose che nello standard windows sono
naturali e implicite, in html/javascript non funzionano o vanno
"rabberciate" alla meno peggio.
 Ci sono effettivamente anche gli applet. Ma torno a dire, è un modo per
portare la logica sul client e questo va contro i requisiti delle
applicazioni web. Non ho mai visto nessun sito decente e funzionale che sia
realizzato con applet, evidentemente non è l'uovo di colombo.

 ma se alla fine lui vuole qualcosa io glielo faccio.
Mah... quando in rete vedo roba con popup e frames, e logica troppo
complessa per compilare dei forms, comincio a chiedermi se i programmatori
erano ubriachi o se i loro manager hanno tirato troppa coca...
Se fossi io a fare il prezzo, certe rogne, le farei pagare così tanto... che
le ragioni o ce le ha davvero o cambia idea...
ad ogni modo apprezzo molto i siti che non si fanno paranoie su quanto
idiota possa essere l'utente... (esempio: se mi chiedono di inserire una
data, e non mi mettono 3 combobox, li ringrazio per la fiducia)
La semplicità è una cosa che ho sempre amato in ogni programma... ci sono
siti web dove i javascript o altri controlli sul client realmente rendono
impossibile una compilazione di un form... bella logica...
Insomma, su questi siti, una buona analisi e una conoscenza delle tecnologie
ha limitato le pretese di logica pesante sul client... HTML e basta, che
sogno! e tutto funzia a meraviglia solo con HTML (i javascript sono quelli
richiesti da banner pubblicitari idioti)

Però non ti sei espresso sui popup, frames e javascript :)
A proposito di Microsoft... vedi hotmail...
sui JavaScript passiamoci su... li hanno traviati loro quindi... ma niente
popup e niente frames... e hanno il client di posta più bello che c'è in
giro.
avete visto per caso 
http://my.sun.com
 ? (oggi non mi funziona molto bene
sarà che stanno facendo manutenzione) Se tutto questo si può fare evitando
certe tecnologie scomode... perchémmai andare a ravanare in mezzo alle
schifezze?

 web. 
Mah, un cliente di solito vuole un'applicazione web non perche' fa figo,
ma perche' cosi' puo' usarla da qualunque workstation abbia un browser -
cioe' oggidi' qualunque workstation. :) 
Per quanto riguarda l'user interface, popup&c sono forse "dettagli" dal
punto di vista puramente funzionale, ma sono spesso essenziali per
l'usabilita' del programma. Del punto di vista puramente funzionale da
solo, un utente non se ne fa nulla. 
Chiaro poi che l'approccio assistant-like e' non solo inutile, ma pure
fastidioso. Pero', per dire, poter usare il right-click per far venire
fuori un menu' contestuale invece di dover navigare un menu' o
selezionare una listbox *sono* dettagli che fanno la differenza, eccome. 
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun


Concordo! (ma i soldi non mi fanno schifo :-D)



Non l'ho ancora visto, asap lo visito!


 selezionare una listbox *sono* dettagli che fanno la differenza, eccome.
Nel web un menů contestuale? L'ho visto su qualche sito... ma in
Javascript... quindi evito...

 Javascript... quindi evito...
Oh cribbio... se mai qualcuno del dominio dovesse sentire parole come "menu
contestuale" siamo fritti... (fortuna che non sanno nemmeno cos'č...)

 Purtroppo si. 
ma un browser non java-enabled difficilmente è javascript-enabled.... no?
Kali

 Non sempre ti assicuro :)
sottoscrivo.
E aggiungo che anche Java, purtroppo (o per fortuna per noi), è 
richiesto in certe aziende solo perchè è di tendenza.... bah! finche' 
dura ;)
Kali


Ciao, 
programmo prevalentemente in php (lato server) e uso
l'essenziale di javascript, come popup (per me utilissime,
in realtà si tratta di un paio di linee di codice) e
controllo form.
Di java ne so poco o nulla, lo sto studiando ultimamente per
sviluppare servlet e jsp, ma conosco bene la logica OO.
Io credo che, visto che i client sono al giorno d'oggi molto
potenti, effettuare ad esempio un controllo di un form sul
client serve per evitare il fastidio all'utente di inviare i
dati, vedere dove ha sbagliato, tornare indietro e
ricompilare il form. Si nota naturalmente uno spreco di
banda.
Ciò è deleterio proprio perchè i pc sono molto potenti
(hanno più che decuplicato i loro clock), ma la connessione
non si è nemmeno raddoppiata. Il 90% degli utenti ha un
modem 56k. Quindi credo sia molto agevole far apparire un
messaggio alert con javascript piuttosto che processare i
dati in remoto.
Le finestrelle popup sono utilissime in vari casi. 
Naturalmente, è inutile esagerare con javascript (ho provato
un menu stile windows ma è davvero di una lentezza immane,
quindi credo che fra poco lo toglierò).
Per quanto riguarda il discorso della compatibilità etc.,
credo che bisogna ragionare per target, nel senso che , se
si sta sviluppando un'interfaccia per un sito di commercio
elettronico, chi vorrà acquistare online, significa che lo
fa abitualmente o è particolarmente predisposto per le
novità, quindi probabilmente ha un browser che supporta
javascript, ha i cookies abilitati ed altro ancora.
E questo è quanto IMHO:)
Saluti.
-- 
WEbdOM webmaster di
Metronic.It mobile phone philosophy
www.gadgetpoint.it
 serigrafia on line

 Dai, tieni botta un altro po', ormai è Natale!
Si sa che molti programmatori sono skizzati e hanno una fragilità lombare
piuttosto marcata... :)
E' già stato citato Dilbert sul newsgroup... consiglio a tutti una lettura
per Natale "Il manuale di management (top secret) di Dogbert"

> ma un browser non java-enabled difficilmente è javascript-enabled.... no?
Non vedo relazioni tra i due... tranne per una inverosimile assonanza nei
nomi...
Konquerror è javascript enabled ma non java-enabled se non erro. Stesso
dicasi per opera se non installi la versione java-enabled. Stesso dicasi per
IE6 che pare venga distribuito senza Java ma con i javascript...
in altre parole, secondo me non c'entra...

 ha scritto nel messaggio
news:3d176ecf...@news.cis.dfn.de...



Si vai a darci un occhiata... è fantastico. Una specie di desktop dentro il
browser.
In verità le finestre popup sono utilizzate (ma non ditelo a nessuno)...
comunque in modo furbo.