Juego de campos Javascript

[matheo]

Mirar lo que quiero hacer. Tengo un juego de campos tal que así :

Código HTML:

<label>
                  <input type="radio" name="Sexo_n" tabindex="12" id="Sexo_n" value="Hombre" />
                  <span class="Estilo7">Hombre</span></label>
                  <label class="Estilo12">
                  <input type="radio" name="Sexo_n"  tabindex="13" id="Sexo_n" value="Mujer" />
                  <span class="Estilo7">Mujer</span>
                  </label> 

Se trata de que se pueda elegir entre "Hombre" y "Mujer". Esto lo quiero procesar con Javascript y recoger en una variable que opción elegió el usuario. Si elegió Hombre o eligio Mujer.

¿¿¿¿Alguna ayudita????

[GatorV]

Tema trasladado a Javascript.

[matheo]

tienes razon! Pues eso...

[David]

¿En qué momento quieres procesarlo?. Porque puedes obtener el elemento, y con elemento.checked ya sabrás si está seleccionado o no.

[caricatos]

Hola:

Pues más o menos:

<input onclick="opcion_sexo = this.value" ...

Cuando pinches en el radio, la variable opcion_sexo (definida en el head) tomará el valor seleccionado.

Saludos

[buzu]

Claro, pero recuerda no poner el onclick así tal como caricatos lo pone. Mejor captura el evento con un listener desde fuera del documento mediante Javascript.

Otra cosa, estás usando mal la etiqueta label.

[caricatos]

Iniciado por buzu

Claro, pero recuerda no poner el onclick así tal como caricatos lo pone. Mejor captura el evento con un listener desde fuera del documento mediante Javascript...

Bueno, eso puede ser motivo para un debate, lo de listener no es así de sencillo, en explorer es attachEvent, en los estándares addEventListener, y en los "pasados de moda" simplemente tag.onclick = f;//...

Y no hablemos de reconocer la fuente del evento event.srcRlement... e.target... y ni hablemos de los burbujeos y otras yerbas.

Muchas veces lo que dices es una auténtica utopía.

Iniciado por buzu

Otra cosa, estás usando mal la etiqueta label.

Evidentemente el primer label falta abrirse, pero ¿cuál es el problema del segundo? y del primero si no se hubiera omitido su apertura.

Saludos

[buzu]

Quizá "usando mal" no era el mejor conjunto de palabras, pero no es la mejor forma de usar los label

http://w3schools.com/tags/tag_label.asp

Caricatos, con respecto a lo que dices sobre los listeners, no es tan difícil como parece. Mucho menos es una utopía. Es solo cuestión de saber aplicarlos. En este caso no tienes ni por que preocuparte de los burbujeos. Aun que coincido contigo, ese sí es un tema que requiere mas profundidad.

En cuanto al debate, estoy abierto. Me encantaría escuchar lo que tienes que decir, quien quita y tengas razón y al final inline hard coding es la mejor opción. Aun que lo dudo.

Saludos.

[caricatos]

Hola:

Pues mi inglés es tan malo que no me aclaro (me salió un versito), pero en español tengo esta referencia: El elemento LABEL, y no veo que haya diferencias.

Y los listeners... ¡je, je!, son muchas las posibilidades... un simple "click" en un tag, puede que no se se asocie al tag y sí a su contenido (aunque suene absurdo me ha pasado), y he tenido muchos problemas en más ocasiones, en mi caso particular, cuando tengo problemas de hacer las cosas de una manera, y hay otra más sencilla, la aplico sin más, y me da igual que sea más o menos accesible, o usable, o que guste o no siempre que funcione.

Ya que planteas usar otra forma, dinos esa alternativa... seguro que es algo (y en ocasiones mucho) más compleja.

Saludos

[buzu]

Ok, con los rótulos, al final de cuentas no hay ningún problema. Pensé que era incorrecto usarlos de la forma en que se están usando. Ya que la forma en que los aprendí es usando el for:
<label for="nombre">Nombre</label>
My bad
Por cierto, al primero no le falta su etiqueta de apertura.

Sin embargo, con lo de los listener no estoy equivocado. Tu tampoco. Es cuestión de metodologías de trabajo. Es solo que como bien lo has de saber, soy partidario de las buenas practicas y de lo que se le ha llamado las tres capas de la web. Y no, no es mas complicado, puedes construir una función genérica y después simplemente reusarla, tal como lo hacen los frameworks.

Saludos.

[buzu]

ah lo olvidaba:

Código javascript:

function addEvent(node, type, listener){
        if(!isCompatible){return false}
        
        if(!(node == $(node))){ return false;}
        
        if(node.addEventListener){
            //W3C
            node.addEventListener(type, listener, false);
            return true;
        }else if(node.attachEvent){
            //IE
            node['e'+type+listener] = listener;
            node[type+listener] = function(){
                node['e'+type+listener](window.event);
            }
            node.attachEvent('on'+type, node[type+listener] );
            return true
        }
        return false;
    };
 

Esta ya es parte de una libreria y hace uso de algunas funciones propias de la librería por ejemplo $() = document.getElementByID()

aqui tengo otra variante:

Código javascript:

addEvent: function(elem, evType, func, useCapture){
        if(elem.addEventListener){
            elem.addEventListener(evType, func, useCapture);
            return true;
        }else if(elem.attachEvent){
            var r = elem.attachEvent('on' + evType, func);
            return r;
        }else{
            elem['on' + evType] = func;
        }
    },
 

Esta es parte de un objeto.

Como ves es demasiado sencillo. Y como la función es re-usable, no estas perdiendo tiempo al desarrollarla, al contrario ganas tiempo en proyectos siguientes.

[caricatos]

Iniciado por buzu

ah lo olvidaba:
...
Como ves es demasiado sencillo. Y como la función es re-usable, no estas perdiendo tiempo al desarrollarla, al contrario ganas tiempo en proyectos siguientes.

Sencillísimo...

O sea, si se puede usar addEventListener, después de la asignación del evento, hay que devolver true, pero en explorer vale devolver el objeto o true (supongo que será igual a true...)
Y otro caso es hacer una asignación directa al objeto...
...pero eso no explica como se reconoce el objeto que provoca el evento... y lo del burbujeo... y los parámetros.

No sé si pruebas tus códigos con muchos navegadores... supongo que sí, pero con el sistema que propongo no hay que poner mucho código, y no dependemos de las librerías de terceros, que al final terminamos dependiendo de sus autores o de que algún "iluminado" re-adapte el viejo código...

La verdad es que si no dependiésemos de los fabricantes de software, posiblemente no habría motivo de debate, pero al final lo que importa es que nuestras soluciones funcionen bien en todos los navegadores posibles (y en ésto incluyo la accesibilidad)...

Saludos

[buzu]

No, la librería es mía y no de terceros. EL segundo ejemplo no es parte de ninguna librería, solo de un objeto y puede ser fácilmente adaptado para que sea una función independiente. LA función no la escribí yo. Aun que mucha ciencia no tiene. Ademas, se podría modificar la asignación en navegadores antiguos de modo que puedan asignarse mas de una función a cada evento sin que se reescriban. quedaría algo parecido a la función addLoadEvent que anda rondando por ahí.

El problema con tu código es que mezcla JS y XHTML, mala practica esa que tienes. Ademas que incrementa el costo de mantenimiento del sitio o aplicación en la que la estas usando. Tu técnica es de las viejitas. Hay que actualizarse un poco.

Por último quiero decir que coincido contigo cuando dices:

La verdad es que si no dependiésemos de los fabricantes de software, posiblemente no habría motivo de debate,

Saludos.

[buzu]

ah, otra vez lo olvidaba. Para reconocer el objeto hay que utilizar otros procedimientos igual de sencillos. Simplemente usamos condicionales para capturar uno u otro valor según el caso. Lo de los burbujeos es un problema aparte, empezando por el bug que Safari presenta (o no se si ya lo hayan arreglado) al respecto.

[David]

Yo, aunque resulte un poco anticuado , por ahora me conformo con:

Código javascript:

elem.evento = function() { /* Código */ }
 

Pero bueno, aunque concuerdo contigo buzu en cuanto a no mezclar Javascript y HTML, si a caricatos no le molesta el mayor costo de mantenimiento, que así continúe haciéndolo .

E infelizmente tener que explicar lo del addEventListener a un usuario que no sabe nada (y que muchas veces no quiere investigar ) se vuelve engorroso, difícil, aunque en el fondo es culpa del usuario (sin referencia al que hizo la pregunta, sino en términos generales) algunos de los que respondemos (me incluyo) a veces nos resignamos (aunque no debiéramos) a mostrar del modo "incorrecto".

Saludos .

[Panino5001]

En mi opinión los 3 tienen razón. La primera manera que muestra buzu soluciona varios de los problemas de referenciación, ya que tienen sentido event y this. La segunda no sirve para mucho en ese sentido, ya que para algunos navegadores this tiene otro significado. Lo cierto es que siempre es más complejo trabajar de esa forma y a veces podemos ceder a la tentación de colocar código inline para evitar complicaciones, sobre todo cuando un cliente nos contrató hoy para resolverle un problema para ayer, y al costo de anteayer. Por ejemplo, la simple validación onsubmit de un formulario se complica porque tenemos que limpiar las acciones por defecto y por 2 caminos distintos, como ya sabemos. O aplicar un simple onchange a un campo file para validarlo por ese camino puede ser otra pesadilla. Y los onmouseout y onmouseover pueden también traer algún trastorno. Y, como bien dice David, cuando un usuario te viene con un "me falla el window.open con el body onload" cómo explicarle todo esto sin meterlo en un laberinto del que no va a saber salir? Es cuando uno opta (yo muchas veces y lo confieso aunque sé que está mal) por no contestar o por (yo también muchas veces) por contestarle con código inline, que en definitiva es así como aprendí, y lo que me permitió luego seguir aprendiendo alentado por cada pequeña solución que iba encontrando a los problemas.
En definitiva, una web es tan efímera y todo cambia tan rápido que lo que creo es que, mientras no te aparezca el color rojo en el firebug o el triangulito en explorer y todo funcione siempre igual de rápido siempre, todo está bien, aún a sabiendas de que podría estar mejor.
En tu ejemplo, Buzu, acaso no podría venir a decirte alguien también que ninguna de tus soluciones contempla el problema de pérdida de memoria en Explorer 6ó-?
Lo cierto es que no hay una manera buena y otra mala de trabajar, hay mejores o peores, pero el único parámetro válido es si las cosas funcionan o no funcionan.

[caricatos]

Iniciado por buzu

...empezando por el bug que Safari presenta (o no se si ya lo hayan arreglado) al respecto.

¡Je, je! con ese comentario me estás dando la razón...

Cuando hacemos nuestras páginas, si no funcionan de la forma estándar, tenemos que hacerlas funcionar de otras maneras... evidentemente cuando aparecen nuevas versiones de los navegadores tienen muchos bugs que se tardan en corregir, y no todos nuestros visitantes actualizan su versión con fallos... en mis trabajos, siempre perduran las versiones que funcionan (no importa que las pruebas se hagan en navegadores con bugs)... y un webmaster mínimamente exigente al menos prueba sus páginas en los navegadores más importantes (en mi caso explorer, firefox, chrome, opera y safari... estoy intentando conectarme con linux para ampliar esa lista... todo se andará...)

Bueno, también hay que considerar con elementos creados dinámicamente...(dá más dolores de cabeza de los que cualquiera pueda imaginarse.)

Por cierto, creo que Panino5001 ha pasado por estas circunstancias (Hola Andrés)

Saludos

[buzu]

jajaja.... concuerdo con Panino en cuanto a que todos tenemos razón, aun que cada quien desde su punto de vista. Yo ya lo habia mencionado tambien:

Sin embargo, con lo de los listener no estoy equivocado. Tu tampoco. Es cuestión de metodologías de trabajo.

Hay soluciones para el tema de las lagunas mentales, digo de la perdida de memoria de explorer. El bug de safari es en cuento al burbujeo, lo cual hasta ahora ni tu caricatos, ni yo ni nadie ha explicado como trabajarlo.

Saludos.