Originariamente inviato da jartiello
Ho capito, grazie.
Sono riuscito a generare qualcosina con questo metodo.
Naturalmente per qualsiasi operazione sulla tabella (tipo add/edit/delete) devo estrarre necessariamente la primary key quindi presumo di tirarla fuori a parte utilizzando "SHOW KEYS FROM mia_table" giusto?
No. Per l'operazione "add" SHOW FULL COLUMNS è più che sufficiente. Per "edit" e "delete" invece devi fare un normale SELECT * FROM mia_table WHERE id=... per leggere la riga che vuoi modificare/cancellare. In questo modo puoi riproporre i vecchi dati per la modifica o visualizzarli prima della cancellazione.
Chiamando "widget" gli elementi html della form da generare, SHOW FULL COLUMNS... ti ritorna i seguenti dati utili:
Field
Da usare per identificare il widget (<input name="$Field" ... >)
Type
Fornisce una prima classificazione del tipo di widget e della lunghezza massima. Per esempio potresti utilizzare una textarea per i campi tipo "text". La lunghezza massima inoltre è comoda per impostare l'attributo maxlength. Per i campi flag ed enum specifica anche le alternative: analizzando il Type di un enum, per esempio, posso acquisire le alternative e decidere se presentare con una serie di <input type="radio"> se sono pochi o una <select> se sono tanti.
Extra
Comodo soprattutto per sapere se un campo è tipo "auto_increment" (ergo sicuramente chiave primaria).
Comment
Usando le informazioni sopraccitate puoi già generare una form base. Alcune informazioni però sono da impostare a mano, un esempio sopra tutti l'obbligo di compilazione di un campo. Per esempio, puoi decidere che i campi che contengono la stringa "required" in Comment siano obbligatori. Altro esempio: ho trovato il campo Comment estremamente utile per impostare dei limiti ai campi immagine o le opzioni di testi WIKI.
Ora alcuni esempi pratici che utilizzano questo approccio. Questa pagina di registrazione
http://www.entidi.it/neskens/user/add/
è interamente generata in dinamico da questa tabella:
codice:
CREATE TABLE `utente` (
`id` int(10) unsigned auto_increment,
`user` char(20) COMMENT 'category=required|rules=unique(user)',
`password` char(20) COMMENT 'widget=password|category=required|rules=minlength(4)',
`publicname` char(20) COMMENT 'category=required|rules=unique(publicname)',
`sex` enum('male','female') COMMENT 'category=suggested',
`email` varchar(40) COMMENT 'category=suggested|rules=email',
`url` varchar(100),
`uri` varchar(100),
PRIMARY KEY (`id`)
);
mentre questa dalla tabella sottostante:
http://www.entidi.it/test.php?action...e=test_content
codice:
CREATE TABLE `articolo` (
`id` int(10) unsigned auto_increment,
`group` int(11) COMMENT 'widget=hierarchy|category=required',
`date` date COMMENT 'category=required',
`subject` varchar(50) COMMENT 'category=required',
`image` varchar(32) COMMENT 'widget=picture|rules=maxfilesize(80000),minpicturesize(10 10),maxpicturesize(200 200)',
`remark` varchar(100),
`content` text COMMENT 'category=required|wiki_rules=Heading,Toc,Horiz,Blockquote,List,Deflist,Table,Url,Strong,Emphasis',
`contact` set('mail','email','mobile','phone'),
`notify` enum('yes','no','later'),
`_creation` datetime,
`_comments` int(11),
PRIMARY KEY (`id`)
);
Originariamente inviato da jartiello
Forse ti chiedo troppo ma cmq ci provo, non potresti inviarmi anche in pvt una parte del codice da te utilizzato per generare una pagina di edit sul recordset utilizzando questo metodo?
Almeno cosi riesco a capire più in fretta.
Non c'è problema: ho comunque intenzione di rilasciarlo come software libero una volta che le API sono stabili. L'inghippo è che fa parte di un framework più ampio: ti posso spedire la parte riguardante le form ma dopo dovrai adattarlo (parecchio). Lasciami il tuo indirizzo email in privato che te lo spedisco.
Rispondi quotando