Newsgroup: it.comp.www.php
Titolo: ajax ....ovvero lavorare di più

Salve
ma perchè implementare due volte gli stessi contenuti solo perchè un 
utente potrebbe disattivare javascript?
A questo punto uno fa i classici doppi controlli client / server, e al 
massimo se javascript viene disattivato, operano quelli lato server.
Con ajax invece o tutto o niente....
die("fine dello sfogo...");
ciao


Vabbé, ma chi è che ha i js disabilitati ormai?
M

 Vabbé, ma chi è che ha i js disabilitati ormai?
I rompicoglioni. :)
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
Going to church does not make a person religious, nor does going to
school make a person educated, any more than going to a garage makes
a person a car.

 Con ajax invece o tutto o niente....
Eh?

 utente potrebbe disattivare javascript?
Perche` implementarli due volte?
Modularizza la tua applicazione server side, e li implementi una volta 
sola.
Lato server usi "include" in PHP per montarli, lato client usi javascript 
per fare lo stesso.
Bye.


cioè
fai un test sul client e in base al fatto che js sia attivo passi un 
contenuto piuttosto che un altro?...
Ma allora siamo a punto di partenza....sempre doppio lavoro :(
ciao


Non capisco il problema, la differenza tra servire contenuti in ajax o
normalmente è solo un fatto di templating e content type.
Una volta che hai qualcosa la cui logica assomigli anche solo
vagamente all'MVC, ti basta che il controller riconosca che si tratta
di richiesta ajax (o xml, csv, quellochetipare) e configuri le Viste
di conseguenza..
Io creo il sito SENZA ajax, dopodichè tramite jquery vado a modificare
il comportamento dei link/bottoni che dovrebbero far uso di ajax; Non
hai js? chissene, jquery non parte e il link funziona normalmente -
hai js attivato? quando clicchi invece del reload pagina parte la
funzione js che fà la chiamata ajax.
E' solo un fatto di impostazione, se segui l'mvc (anche solo le basi)
ci sono mille modi, uno più semplice/veloce dell'altro

 funzione js che fà la chiamata ajax.
dimenticavo la parte più importante: cambiando solo il comportamento
della vista, i vari controller e models rimangono invariati, il tuo
codice rimane identico, non devi fare script appositi solo per le
chiamate ajax.
Però la prima regola nello sviluppo di un sito/applicazione web è che
DEVE funzionare anche senza ajax e i contenuti devono essere leggibili
anche senza i css.


E però si torna al punto di partenza dell'OP ossia che tocca fare il 
lavoro doppio
Se da una parte ho un webservice che mi butta fuori dati in json che 
vengono poi formattati da js e dall'altra invece devo buttare fuori 
tutta la pagina in un colpo unico devi comunque fare tutto doppio
Che il controller stia più vicino alla view o al modello cambia poco
Io ho la fortuna che  i miei committenti ormai non si pongono più il 
problema che non ci siano i js attivati (e io sicuramente non lo vado a 
sottolineare), ma è una rottura di balle che ricordo bene ...
M

 I rompicoglioni. :)
e tutti i bot che ti indicizzano il sito
e tutti gli screen reader per persone non vedenti


Giusto, devo precisare una cosa.
La parte sulla quale me ne sbatto della possibilità di js disattivati è 
quella delle applicazioni, non quella del sito o cmq dei contenuti "statici"
Concordo che per l'accessibilità si sia ancora troppo indietro rispetto 
a quanto permette la tecnologia e in questo siamo colpevoli un po' tutti 
come categoria (con ovviamente l'eccezione di qualche singolo)
M

 Che il controller stia più vicino alla view o al modello cambia poco
No è che in tal caso devi estendere le viste non solo al php ma anche
al js.
Tu hai nel controller la funzione Piglia_dati(), che fà tutte le sue
belle richieste ai model e costrutti logici.
Se è pagina html, invoca la vista Stampa_html() e gli passa i dati,
lei penserà a creare l'html.
Se è ajax, invochi la vista Sputa_json() e la vista stampa un semplice
array json, buttando prima fuori gli headers corretti.
Dopodichè avrai la tua funzione javascript che elabora il json e fà
quel che deve fare.

 quella delle applicazioni, non quella del sito o cmq dei contenuti "statici"
Scusa, e un non vedente o uno che ha js disabilitato (c'è un addon di
firefox ad esempio) non può usare la tua applicazione?
Certo, dipende un sacco dal target che hai, tuttavia io non sarei
molto tranquillo a consegnare al cliente qualcosa che senza js non
funziona.... o in tal caso, credo che il cliente debba esserne
informato (oltre che per il discorso trasparenza, per un discorso di
"dormire tranquilli")

 controller stia più vicino alla view o al modello cambia poco
Se hai gia` il codice sul server che interroga quel webservice e genera 
l'HTML corrispondente, ti basta che il tuo codice diventi un proxy per il 
webservice, quindi da ajax interroghi il tuo server e ti fai tornare 
l'html, invece di andare direttamente sul webservice.
Bye.

 "dormire tranquilli")
Tu la compreresti oggi una macchina (che non sia un barattolo da 15
km/h) senza airbag e/o senza ABS ?
Dormiresti tranquillo dopo aver venduto una macchina da 110 cavalli
avendo informato il cliente che se si schianta l'airbag non c'è?
Il cliente non sa mai quello che vuole e non sa mai di che cavolo si sta
parlando. E' per definizione un deficiente. Magari per spendere meno
sceglie la strada più idiota e poi dopo (quando è troppo tardi) si lamenta.
Il cliente dovrebbe essere informato / educato / sensibilizzato che
molte delle funzionalità che ha chiesto (magari per lui sono delle
cazzate) sono state implementate grazie a js...
Per carità, io cerco sempre di utilizzarne il meno possibile e quando
possibile si va di css. Ma il js "non è il Male" ...
I controlli lato server vanno *sempre* fatti, e vanno messi in conto. Il
giorno che vuoi cambiare / togliere / aggiornare / qualsiasi cosa sul
front-end, hai comunque le chiappe coperte lato back-end server.

 front-end, hai comunque le chiappe coperte lato back-end server.
Non capisco perchè hai quotato me che dico le stesse cose che dici
te ;)
Per quel che riguarda il cliente a mio avviso è fondamentale essere
chiari sulle funzionalità del sito: io da un annetto ad esempio metto
la compatibilità completa* con IE6 a parte, spiego al cliente cosa
significa, e in pochi l'hanno richiesta espressamente, e nessuno si è
lamentato finora.
Io rimango dell'idea che javascript (anche se prende sempre più piede)
deve essere considerato come un optional, se c'è tanto meglio, ma il
sito deve funzionare/essere fruibile anche senza.
* per completa intendo che il funzionamento/aspetto del sito è
identico su firefox 3 e IE6, "non completa" che alcune minime
differenze grafiche ci possono essere (che non compromettano la
navigabilità/fruibilità dei contenuti)