Newsgroup: it.comp.lang.javascript
Titolo: Prima Datagrid

In una pagina ho una table con tante righe, una per ogni record (lato 
server c'e' PHP+MySQL).
Ora io vorrei permettere di modificare i dati in essa.
Ho pensato:
faccio un unico form
<form> tabella </form>
poi nelle celle della tabella ci metto degli
<input type="text" name="Matricola_idrecord_25478".....
Praticamente il nome del campo mi contiene anche la chiave del record da 
cui proviene. In questo modo, con JS controllo cosa l'utente ha 
modificato (devo salvare i valori precedenti in un array sigh), e se per 
es. il campo "Matricola_idrecord_25478" e' stato modificato  allora 
dovrei richiedere a PHP di fare:
UPDATE Tabella
SET   Matricola = valore_del_campo
WHERE IdRecord = 25478
Credo che potrebbe funzionare, ma mi sembra mooooolto contorto.
Siccome questa e' la mia prima datagrid via web, devo prendere una 
decisione "politica", cioe' scegliere un modo per implementare le 
datagrid e poi usare sempre quello.
Voi come fate?
Avete qualche consiglio?
Grazie
Marco (al lavoro anche nel weekend)

 modificato (devo salvare i valori precedenti in un array sigh)
Non e' necessario, puoi controllare se il value differisce dal
defaultValue.
-- 
C'ya,
  ZER0 :: coder.gfxer.webDesigner();
"When you have eliminated the impossible, whatever remains,
however improbable, must be the truth." (S.H.)

 defaultValue.
Quella del DefaultValue non la conoscevo. Peccato non si applichi a 
tutti gli input (solo text, textarea, password, hidden) comunque e' gia' 
un bel risparmio.
grazie a te
Marco

 tutti gli input 
Si applicano a quelli che hanno un attributo value, ovviamente. A cos'altro
volevi applicarlo? A un checbox? A un radiobutton? Per un datagrid direi
che e' piu' che sufficiente.
Per casi anomali, inoltre, puoi sempre associare ad un elemento che non ha
il default value, tipo checkbox per indenderci, un campo hidden che ne
rispecchia il valore. Oppure aggiungere gli attributi mentre generi
l'elemento, ma devi anche ricordarti di estendere la DTD relativa, se vuoi
che il tuo HTML sia validabile (puoi anche fregartene della DTD,
funzionerebbe cmq, solo non e' validabile).


 funzionerebbe cmq, solo non e' validabile).
Altra perla preziosa. (La validazione e' l'ultimo dei miei probl)
Posso fare
<input type=select name="sele" mioattributo="pippo" ....
e nel DOM melo ritrovo ?
document.form['sele'].mioattributo
Micidiale!
Il JS mi piace sempre di piu'
Grazie ancora, credo di avere abbastanza elementi, di piu' non potevo 
chiedere .... a parte il listato di una tua datagrid ;.)
Mi lancio nel coding
Marco

 Mi lancio nel coding
Buon lavoro, dunque!



E infatti il meccanismo e' perfetto tranne nel caso in cui vi sia 
esattamente 1 record.
In quel caso il riferimento ai campi tramite vettori fallisce.Il che 
costringe a scrivere sempre 2 versioni di ogni istruzione.
Per esempio nel caso sopra
     var f=document.forms[0];
// se f.idRecord.length non e' def. non esiste l'array idRecord[] quindi 
c'e' un solo record
     numrec=((f.idRecord.length)? f.idRecord.length : 1);
 
     if (numrec==1)
         alert("ID:"+f.idRecord.value+"\n"+
              "Nome:"+f.fldNome.value+"\n"+
              "Cognome:"+f.fldCognome.value+"\n"+
              "Nickname:"+f.fldNickname.value);
      else
         for (var i=0;i<numrec;i++)
             alert("ID:"+f.idRecord[i].value+"\n"+
                 "Nome:"+f.fldNome[i].value+"\n"+
                 "Cognome:"+f.fldCognome[i].value+"\n"+
                 "Nickname:"+f.fldNickname[i].value);
E' un dettaglio che mina alla base la potenza di questo metodo.
Ti prego dimmi che mi sto sbagliando anche stavolta.
Ciao
Marco

 Ti prego dimmi che mi sto sbagliando anche stavolta.
Non stai sbagliando dicendo che se hai un elemento solo, non hai un array;
ma sbagli nello scrivere due versioni di ogni istruzione. Sbagli
nell'approccio alla "soluzione" di questo problema.


 questa, ci diamo un occhio assieme.
Anche subito. :-)
Ciao
Marco

 Anche subito. :-)
Intendevo proprio questo, non "subito" ^_^' prima spendi un po' di tempo
dietro la reference, e sbattici un po' il capo da solo, sulla questione.
Secondo me riesci a trovare una soluzione elegante, che ti soddisfi, in
modo autonomo.


 Non riesco a capire il perche' di questo approccio.
Io non ne vedo altri.
Non posso scrivere:
	f.NomeDelCampo[iRow].value
perche' se c'e' un record solo mi da' errore.
Viceversa la notazione:
	f.NomeDelCampo.value
e' inutile nel caso di piu' record.
Ergo:
Devo usare le 2 notazioni in aree "protette" cioe' dopo avere testato se 
siamo nel caso NRecord=1, o NRecord>1;
Mah! Forse ti devo dire che ho adottato una politica forse non 
convenzionale.
Lascio l'utente operare tutte le modifiche/cancellazioni che vuole sulla 
  grid, poi, all'atto della conferma, faccio la validazione "di massa" e 
tutti gli update/delete al DB (usando l'xmlHTTPRequest che mi hai 
suggerito qualche giorno fa)
In quest'ottica io non vedo altri sbocchi se non quello orrendo da me 
adottato.
Non puoi almeno indirizzarmi sulla via da seguire?
Poi la perfeziono io a colpi di reference :-)
Ciao
Marco

 Poi la perfeziono io a colpi di reference :-)
Mhm, direi che *generalmente* dovresti fare il contrario. E ti spiego anche
perche': L'approccio che puoi utilizzare, e l'implementazione dello stesso,
dipende molto dal tipo di linguaggio che stai usando, in questo caso
Javascript.
Predisporre quindi, prima la logica senza una base consolidata delle
potenzialita' del linguaggio, e' errato. Tu stai ragionando come in
"pseudo-codice".


 "pseudo-codice".
Hai ragioe al 1000%. Ma sai com'e', a volte il tempo e' tiranno e 
bisogna scendere a compromessi anche con il proprio senso estetico. Il 
fatto che sia al lavoro anche nel weekend la dice lunga :-(
Ciao
Marco

 fatto che sia al lavoro anche nel weekend la dice lunga :-(
Capisco. Pero' e' altresi' vero che non puoi imbarcarti in un progetto in
cui non conosci a fondo i mezzi.. Come fai anche solamente a fare una stima
dei tempi (e quindi dei costi)?
Cmq sia:
Il problema e' che abbiamo degli elementi, che possono essere o non essere
array. Il nostro compito e' recuperare il valore di tali elementi, a
prescindere quindi dalla loro natura, mantenendo un codice pulito, evitando
la ridondanza laddove possibile.
Quindi i casi sono due. O gestisci l'eccezione (un elemento invece che un
array di elementi) in modo elegante, oppure *elimini* l'eccezione (fai in
modo che ti venga restituito sempre un array di elementi).
Questi sono i due approcci a cui mi riferivo prima, il primo dei quali si
snoda in varie possibilita' di implementazione.
Se scegliessi questo metodo, opterei per un approccio OOP (tutto JS e' OOP
del resto, benche' basato su prototipi invece che su classi), per questo ti
consigliavo una lettura alla reference prima.
-- 
ZER0://coder.gfxer.web-designer/
~ "Lo dice il buon senso, ma il buon senso non e' uno standard".
(Jeffrey Zeldman)

Ciao, Ux!
Il giorno 04/07/2004 alle ore 18:20 hai scritto:
 U> Dimmi in 3 righe in che modo eviti il raddoppiamento del codice e io
 U> sviluppo la soluzione funzionante.
Inserire degli hidden fields vuoti in modo che vengano restituiti come
elemento 0 ?
I miei 2 cent.
Bye
-- 
There is no passion; There is serenity.
http://www.maccasoft.com

 elemento 0 ?
Obbravo, hai azzeccato il secondo metodo.
Avrei preferito ci fosse arrivato da solo, pero'.. capire il meccanismo
delle cose (in questo caso, il DOM) e' la chiave di volta nello sviluppo in
un dato linguaggio.
-- 
ZER0://coder.gfxer.web-designer/
~ "Compiere l'impossibile e' impresa che risiede nel cuore degli uomini"
(Mariners and generals)

 un dato linguaggio.
Ma dai, questo e' un trick. Va benissimo intendiamoci, ma non lo impari 
certo sui reference. Sono quelle malizie che acquisisci dopo un po' che 
sei immerso nel JS e nella programmazione web. Io ho iniziato da qualche 
  settimana con JS+PHP+MySQL e sono autodidatta.
Tanto che a volte mi capita di fare alert($miavar)in PHP e anche 
echo(var) in JS.
Ciao
Marco
PS. Non oso chiederti i metodi senza array di elementi ;-)

 I miei 2 cent.
Ma bella Macca!!!
Ti devo 2 cent ;-)
Ciao
Marco

 PS. Non oso chiederti i metodi senza array di elementi ;-)
Quello e' puro javascript, e non e' niente di che. Si rifa' semplicemente
alla logica di incapsulamento dell'OOP.
Il tuo problema e' ottenere il giusto riferimento ad un elemento. In
sostanza, nel codice sottostante, e' "f.idRecord[i]" a essere un'incognita:
for (var i=0;i<numrec;i++)
	alert(f.idRecord[i].value);
E quindi, devi delegare a qualcos'altro la responsabilita' di restituirti
cio' che desideri:
for (var=0;i<numrec;i++)
	alert(getField(f.idRecord,i).value);
In questo modo, il codice principale non viene duplicato come facevi prima,
non hai piu' tale ridondanza.
Questo per spiegarti la logica che sta dietro. Ovviamente non e' ancora il
massimo dell'eleganza, ma e' l'esempio piu' semplice. Non mi piace passare
l'indice della riga corrente, e dovresti cmq fare una funzione per
recuperare il numero dei record.
E qui entra in gioco l'OOP. Incapsulando il tutto in un oggetto, riesci a
gestire poi, a livello di codice effettivo, la griglia in modo veramente
snello. Ad esempio, prendendo come spunto la struttura dell'oggetto
Recordset di ADO, potresti sviluppare un oggetto che ne ricalca
l'interfaccia, per poi avere quindi, il seguente codice:
/* 
	crei un oggetto recordset per iterare la form datagrid,
	passando come parametro la form come datasource.
*/
var rs=new Recordset(document.forms[0]);
/* si sposta al record successivo finche' non raggiunge la fine (eof) */
for (;!rs.eof;rs.moveNext() ){
	alert("ID: "+rs.getField("idRecord").value+"\n" +
		"Nickname: "+rs.getField("fldNickname").value)
}
Ovviamente le responsabilita' da dare ad un oggetto del genere sono a tua
discrezione. MoveNext, MovePrevious, MoveFirst, MoveLast.. senza contare
altri eventuali metodi di checking:
/* 
	riporta il recordset aperto alla prima riga,
	e lo cicla nuovamente.
*/
for (rs.moveFirst();!rs.eof;rs.moveNext() )
	if ( rs.isChanged() ){
		/* 
			la riga corrente e' stata modificata,
			salva i valori da qualche parte per
			poi inviare tutto tramite XmlHttpRequest
		*/
		doSomething();
	}
/* invia i dati al server */
	doRequest();
-- 
ZER0://coder.gfxer.web-designer/
~ "Problemi" e' il nome che gli informatici danno a quelli che
comunemente verrebbero definiti "disastri"; altrimenti si chiamano
"features".

ZER0 wrote:

Si,
ne intravedo le potenzialita'
ma non ho ancora la capacita'
che fa anche rima pappappero pappapa'
:-)
Daccordo che il tuo e' solo un esempio, ma io dovendo creare dal nulla 
un oggetto per accedere al mio form non sceglierei l'approccio 
"sequenziale" di ADO, cioe' MoveFirst+MoveNext. Sara' anche meno 
elegante ma a me l'accesso random (alla array) sembra molto piu' potente.
Tipo:
FormName(NomeCampo,NRecord).value
accoppiata alla forma (utile per le iterazioni sui campi):
FormName(indiceCampo, NRecord).value
Vabbe', questione di gusti.
Ciao
Marco
...e via per un'altra fantastica pagina web!!!!!!

 FormName(indiceCampo, NRecord).value
Accoppiata alla forma?
-- 
ZER0://coder.gfxer.web-designer/
~ "L'arte non riproduce cio' che e' visibile,ma rende visibile cio' che
non sempre lo e'" (Paul Klee)
on air ~ "the calling - for you"

 Accoppiata alla forma?
Intendevo dire 2 sintassi di utilizzo, una con NomeCampo l'altra con 
indiceCampo.
Ma questo e' il futuro, per l'incapsulamento e' ancora presto.
Adesso ho il problema di decidere la modalita' di inserimento di un 
nuovo record nella dbgrid. Ma per questo forse e' meglio che apra un 
nuovo thread.
Ciao
Marco

 so nemmeno se sia fattibile e cosa comporti)
Ad esempio, la sintassi che hai scritto tu e' errata:
FormName.length
FormName(*,i)
-- 
ZER0://coder.gfxer.web-designer/
~ Le donne si dividono in 4 categorie: le suore (non la danno a nessuno);
le puttane (la danno a tutti); le stronze (la danno a tutti tranne che
a te); le rompiballe (la danno a te e solo a te).