ProposteDF_XML_7

Ultimo Aggiornamento r1.24 - 22 May 2007 - 20:12 - LuigiEnricoTomaselli

Proposta di modifica dell'elemento <label/> e <select/> all'interno dei <form/>

Attributo for di label

Nelle specifice del protocollo, al paragrafo 7.2.1.3, "Particolarità dell'elemento form", viene definita la funzione dell'attributo for dell'elemento label di cui però non capisco la reale funzione ed utilità. Non sarebbe più comodo, anche in fase di passaggio da XML ad XHTML, mantenere una grammatica simile a quella XHTML in cui l'elemento input è eventualmente figlio di label? Se non capisco male, per ottenere questo:

ora si deve scrivere così:

<form action="prova.php" method="get">
  <label for="nome">Nome:</label> 
  <input type="text" name="nome">
  <input type="submit" value="invia"> 
</form>

La mia proposta è la classica sintassi XHTML

<form action="prova.php" method="get">
  <label for="nome">Nome:<input type="text" name="nome"></label> 
  <input type="submit" value="invia"> 
</form>

Oltre a una questione di comodità c'è da far presente un altro problema: quando creo dei radio e delle checkbox associo un name uguale per tutte le scelte di una certa categoria, ma in questo caso come faccio ad associare del testo descrittivo per ogni singola scelta? Faccio un esempio:

<form action="prova.php" method="get">
  <input type="radio" value="M" name="sesso">
  <input type="radio" value="F" name="sesso">
  <input type="submit" value="invia"> 
</form>

In questo caso, dato che label fa riferimento al name, non si riescono a distinguere i due radio. L'unica soluzione che mi viene in mente è quella di "portare fuori" come testo il contenuto del campo value, in fase di trasformazione XSLT, ma dato che non capisco l'utilità dell'attributo for proporrei di mantenere la sintassi XHTML.

Attributo onclick per select

Per quanto riguarda l'elemento select propongo l'inserimento dell'attributo onclick, cosi da non dover mettere un bottone di submit per ognuno dei menu a tendina, ad esempio per la scelta del layout della pagine.

COMMENTO DEL CHAIR

Ottima segnalazione, e' effettivamente un problema che non avevo per ora riscontrato. Mi sembra che il tutto non faccia una piega e che la proposta di modifica sia ragionevole. Ci rifletto ancora un po' su e per lunedi decidiamo il da farsi. Va bene anche l'attributo delle select, lunedi decidiamo. Grazie della segnalazione!

Luigi

Commento di RobertoMaggi^? La questione su label non l'ho capita perche' il sito W3Schools insegna che l'elemento label xhtml e' identico al nostro anche nell'utilizzo (eccetto il fatto che for si riferisce al nome e non all'id). Guardate le Caratteristiche dell'elemento label.
Riguardo alla cosa dell'onlick, se vuoi emulare l'xhtml forse dovresti metterci onChange che e' l'evento che intedi.
Riguardo alla questione delle label nel radiobutton piuttosto che nella check (non voglio essere rompipalle) pero' se al posto di dover dire al DF di fare un radio piuttosto che una check gli potessimo dire: fai un elemento di input che mi rappresenti una scelta (esclusiva o non) che abbia come label "xyz" e come valori di scelta questo set (a,b,c,d,e) avremmo risolto il problema, i valori (a,b,c,d,e) sono descrittivi per la loro opzione di scelta e il valore di label diventa il nome del campo da inserire.
Commento di RobertoMaggi^?

Commento di ManuelBertuzzi^? Per quanto riguarda l'utilizzo in XHTML non sapevo che fosse così, comunque buono a sapersi, quindi a questo punto la modifica che mi sembrerebbe necessaria sarebbe quella di far si che for faccia riferimento all'ID. Per quanto riguarda la motivazione per cui, indicando un tipo di scelta piuttosto che un determinato input, il problema dei radio sarebbe risolto, ma mi sembra più produttivo discuterne lunedi a questo punto. Mentre per l'attributo di select ci guardo bene, credo che ci siamo capiti comunque su quale sia il comportamento richiesto. Ciao Manuel

Fine Commento di Manuel Bertuzzi

COMMENTO DEL CHAIR

Ci ho riflettutto abbastanza e una soluzione mi sembra questa:

1. Si riaggiunge l'attributo id all'elemento input come opzionale
2. Il for della label punta ad un id della input e non piu' al suo name
3. il DF quando crea l'xhtml mantiene nell'output l'id scelto per la input, cosa per altro necessaria in javascript per gestire le form decentemente mi sa...
4. L'attributo id dell'elemento input e' opzionale, pero' il valore dell'attributo for della label deve essere associato ad un id univoco di una input, altrimenti il DF restituisce errore.
5. L'attributo name resta comunque inseribile
6. ajax continua a funzionare perche' l'id importante e' quello dell'elemento query (in modo da poter sostituire correttamente il frammento) e tale id e' scelto dal DF.

Che ne pensate?

FINE COMMENTO

Commento di RobertoMaggi^? Penso che stiam incasinando ancora di piu le cose. Avevamo deciso di non associare for all'=id= ma al nome appunto perche' l'id e' un attributo che gestisce il formatter per creare il layout (ed associargli uno stile di visualizzazione). A questo punto se torniamo con l'attributo id (sempre seguendo l'idea di emulare xhtml) l'attributo name a cosa serve??
Poi altra cosa, non e' detto che l'id della query sia solo quello importante perche' io in javascript potrei usare delle funzioni che si riferiscono direttamente agli id degli elementi. Riferirsi al nome nella nostra sintassi (che non e' xhtml!) serve per indicare al formatter che deve creare un elemento di etichetta (label xhtml o un paragrafo o un div o quello che gli pare perche' tanto e' lui che gestisce la visualizzazione, ovvio che se fai un paragrafo non te lo compro il DF) che si riferisca ad un campo di input specifico che ha come nome quello specificato.
Non vedo proprio dove sta il problema. Il DF fa una traduzione da una grammatica a un altra non un copia incolla.

piccola parentesi: il file schema degli elementi della form (form.xsd) cosi' com'e' definito da un po di problemi perche' Oxygen durante la validazione si aspetta che dentro l'elemento label ci sia una select o un fieldset(??)...quindi siccome non capivo come venirne fuori l'ho messo in forma tende alla veneziana e lo trovate qui form0.2.xsd (appena mi attivano il servizio Golem).

Fine commento di RobertoMaggi^?

COMMENTO DEL CHAIR

Non vedi proprio dove stia il problema?, intendi il problema sollevato da ManuelBertuzzi^??. In tal caso il problema ci sta eccome, il come risolverlo e' una questione da discutere. L'attributo name sarebbe comunque fondamentale perche' e' con quel valore che ti arrivano i valori della form nella POST (se tu mi metti name="pippo" poi nella post ti arrivera' qualcosa del tipo pippo=)

Il file schema della form non mi da alcun problema in oxygen;mi riferisco al file attualmente linkato nel protocollo DFV5, tu a quale ti riferisci?.

Comunque per la vostra gioia sto riscrivendo le grammatiche in stile tende alla veneziana.

Stay tuned

Ps: rob ho letto la tua mail, tutto chiaro

Luigi

Commento di RobertoMaggi^? Intendevo dire che se noi rimettiamo il fatto di riferirsi all' id anziche' al nome otteniamo che nella nosra grammaica nome e id hanno la stessa funzioni di identificare univocamente un campo di input. Boh forse non m'e' tanto chiaro il problema.
Riguardo ad oxygen intendo il file che c'e' ora sul protocollo, l'ho messo come schema di validazione in un nuovo file di esempio xml che stavo provando e quando inserivo gli elementi l'autocompletamento di oxygen mi indicava che dentro una label ci doveva stare una select, boh.
Ad ogni modo Luigi guarda il file xsd che della form che ho messo qua form0.3.xsd che e' gia a posto in tende alla venenziana. Poi invece ti do anche gli altri due file che sono uno quello degli elementi base in comune con il DS : testo.xsd(forse non sara' la versione definitiva ma praticamente si) e questo e' un estensione uile per le nostre grammatiche (ho aggiunto tabelle e link come li intendiamo noi) DFtesto.xsd. Tu usa il form.xsd che gli altri sono gia inclusi giusti da li. Nel mentre io sono qua a lavorarci sopra e fare prove.

Rob

Fine commento di RobertoMaggi^?

COMMENTO DEL CHAIR Ottimo Rob, solo che stiamo facendo lo stesso lavoro (ed i risultati sono pure simili) . Arrivati a questo punto mi sembra che testo.xsd vada a sostituire l'attuare StrutturaHTML^?.xsd giusto?. Facciamo che io modifico lo schema principale formatta.xsd per fargli usare form0.3.xsd e DFtesto.xsd (ed il relativo testo.xsd) ok? Se fai delle modifiche a questi file fammi sapere, io nel frattempo faccio il merge, onde evitare di fare lavoro doppio sulle stesse cose, ok?

Buon lavoro

Luigi

FINE COMMENTO

Commento di RobertoMaggi^?

Si dunque allora, il file form0.3.xsd e' equivalente al tuo form.xsd che c'e' ora nel protocollo con l'aggiunta dell'elemento button (equivalente a quello xhmtl).
Il file testo.xsd contiene gli elementi di grammatica pseudo xhtml che usano anche quelli del DS.
Il file DFtesto.xsd include il file testo.xsd e estende le definizioni introducendo il tipo table_t e il tipo link_t (quest'ultimo si differenzia da un semplice a poiche' ha l'attributo selected="selected", che permette l'indicazione che si sta navigando quella sezione del sito, e l'attributo extra che sono info extra sul link). Ah, il tipo testo_t e' un content model misto con anche tutti i possibili tag base pseudo xhtml, il tipo testoSemplice_t invece e' un content model misto con solo elementi decorativi di testo (questi due sono utili per definire i content model degli elementi).
Altre estensioni alla grammatica base al momento non ne trovo. Se ne troviamo le dobbiamo aggiungere li.

Ad ogni modo ok tu fai quello (che cmq gia la grammatica di quella parte l'avevi fatta pulita ;-)), io faccio 1po di prove e faccio la grammatica di elementi semantici per la form che ho nominato piu volte, cosi' se lunedi a qualcuno interessa e' gia pronta.
Alla fine una volta fatto tutto questo dobbiam solo risolvere la questione dell'elemento contenitore e dei tipi e decidere la grammatica di elenco e scheda che derivera' da quella del DS (per questo direi di parlarne con quelli del DS al nostro WG lunedi visto che vengono).

PS Ho capito qual'e' il problema di name/id con le checkbox e le radiobutton, la cosa e' alquanto incasinata perche' in xhtml, la cosa che identifica un gruppo di opzioni di tipo radio o check e' l'attributo name e' non c'e' modo di far si che l'attributo name possa essere univoco per ogni opzione (e quindi non c'e' modo di associare un testo ad una sola opzione). La mia soluzione resta quella che ho in testa dall'inizio, un elemento inputChoice che superi questi limiti e non li incasini. Ora faccio la grammatica poi ve la posto (magari in un topic proposta a se stante)

Rob Fine commento di RobertoMaggi^?

COMMENTO DEL CHAIR

Ti link l'archivio zip delle nuove grammatiche. Ho modificato formatta.xsd in modo che usi i file che mi hai passato. Ho modificato DFtesto.xsd per aggiungere un group che mi serviva. Dacci un'occhiata e dimmi che ne pensi!, le trovi qui

Buon lavoro

Luigi

Commento di RobertoMaggi^? A meno di qualche dimenticanza (ad esempio dei tipi di alcuni attributi), e dello schema del contenuto statico (che tando dobbiamo ancora definire cosa sara') direi che per il resto va piu che bene.
Guardati/atevi lo schema del form in modalita' "semantica" che ho postato come proposta.

Rob Fine commento di RobertoMaggi^?

Commento di ManuelBertuzzi^?

Alla riunione del 21/05/07, per quel che riguarda la richiesta dell'attributo OnClick dell'elemento select, si è deciso di lasciar stare l'aggiunta di quest'attributo perchè è stato detto che usando delle form con una sola select, al cambio di valore della stessa si attiva automaticamente l' action della form. Ho fatto alcune prove, ma non riesco ad avere questo tipo di comportamento, qualcuno mi può delucidare?
Grazie
Manuel

Fine del commento di ManuelBertuzzi^?

COMMENTO DEL CHAIR

Effettivamente nemmeno io sono riuscito ad ottenere quanto detto, qualcuno (Giacomo) puo' postare qualche esempio (che non usi javascript magari)?

Grazie

Luigi

FINE COMMENTO
to top