obtener el texto de un combo

[Trulala de cordoba]

Hola gente, como estan.
Tengo en combobox que tiene como valor el id de una tabla, pero también como saben se muestra el texto de esa tabla, por ejemplo el nombre del pais.
Cuando request.form("pais") me devuelve como es logico el value del combo país, por ejemplo 12. Lo que me preguntaba si es posible en asp obtener aparte del valor del value, también el valor del texto.
Desde ya gracias.

[gorka_22]

En el value del form pon el id y el texto separados con una coma por ejemplo. Luego en el request.form("pais") te devolveria, por ejemplo, "12,francia". A esto le haces un split con asp y ya tienes los dos datos para trabajar con ellos.
Espero que te sirva.

[tammander]

Lo mejor para esas cosas es una combinación de JavaScript y campos ocultos en el tag del formulario. Te cuento como hago yo esas cosas.

Supongamos un formulario:

Código:

<form name="form1" method="post" action="recogedatos.asp">

<select name="select">
  <option value="1">Valor 1</option>
  <option value="2">Valor 2</option>
  <option value="3">Valor 3</option>
</select>

<input name=" insert" type="submit" value="Aceptar" class="enviar"/>

</form>

Al pulsar el boton de enviar, el archivo recogedatos.asp recibirá solo dos parejas de datos (name/value): select=1&insert=Aceptar. Como ves, solo se admiten parejas de datos (data set pairs en inglish :P ) en el envio del formulario. Entonces, ¿como envio el otro valor? Usando un campo más :D

Código:

<form name="form1" method="post" action="recogedatos.asp">

<input name="texto" type="hidden" value="" /> 

<select name="select">
  <option value="1">Valor 1</option>
  <option value="2">Valor 2</option>
  <option value="3">Valor 3</option>
</select>

<input name=" insert" type="submit" value="Aceptar" class="enviar"/>

</form>

Ahora tenemos tres parejas de datos. Solo nos falta añadir el valor a ese campo oculto. Para ello usaremos JavaScript y una pequeña funcioncilla que hará de intermediaria entre el formulario y el envio de este.

Código:

<script type="text/javascript">
<!--
  function funcioncilla() {
     var doc = document.form1

     doc.texto.value = doc.select.options[doc.select.selectedIndex].text;

     return true;

  }
-->
</script>

<form name="form1" method="post" action="recogedatos.asp" onSubmit="return funcioncilla()">
 
<input name="texto" type="hidden" value="" /> 

 <select name="select">
   <option value="1">Valor 1</option>
   <option value="2">Valor 2</option>
   <option value="3">Valor 3</option>
 </select>
 
 <input name=" insert" type="submit" value="Aceptar" class="enviar"/>
 
 </form>

Si te fijas, el formulario comprobará la función funcioncilla antes de enviar los datos ya que esa es la misión del evento onSubmit: disparar una acción antes de enviarse.

Esta función JavaScript realmente es una sola linea:

doc.texto.value = doc.select.options[doc.select.selectedIndex].text;

como ves, asignamos a ese campo oculto que estaba vacio el texto (no su valor) de la opción seleccionada y luego devuelve true para que se envie sin demora Cuando llegue a la página recogedatos.asp, la información estará en parejas pero esta vez asi:

select=1&texto=Valor 1&insert=Aceptar

Con lo que ya tienes el texto del combo

NOTA: te recuerdo que para que funcione correctamente, javascript debe estar habilitado en el cliente (80% de los casos).



Un saludo

[AlZuwaga]

Iniciado por tammander

NOTA: te recuerdo que para que funcione correctamente, javascript debe estar habilitado en el cliente (80% de los casos).

Yo creo que debe ser más del 80%, pero así y todo prefiero la opción propuesta por gorka_22 ;)

[tammander]

Hola Al Zuwaga :)

Sigo pensando que los programadores web estamos muy, pero que muy influenciados por la programación de aplicaciones de cónsola. El no querer aprovechar las diferentes tecnologias que disponemos para desarrollar aplicaciones 100% web nos limita y hace que las aplicaciones contengan innumerables cuellos de botella (sobre todo en el lado del servidor).

Las tecnologías desarrolladas para correr en el lado del cliente disponen de muchas posibilidades y javascript es muchisimo más potente que muchas de las llamadas tecnologias de servidor (ASP por ejemplo). No querer usarlas o preveer que dicha tecnología no estará habilitada en el cliente nos hace hacer cosas como esta de la que estamos hablando: más código para el servidor.

Posiblemente para páginas web tales como portales, etc abiertas al público en general sea una buena forma de programar (aun a costa de sobrecargar el servidor) pero en entornos restringidos a determinados usuarios hay que evitar esa sobrecarga por todos los medios pues el uso del ancho de banda hay que compartirlo con los usuarios "generales" y la carga es mucho mayor. Obligar a los usuarios de acceso restringido (registrados) a habilitar javascript, cookies o lo que haga falta se hace vital.

Por supuesto, es mi modo ver las cosas y lo que, tras más de 10 años haciendo aplicaciones web, he aprendido de este submundo dentro de la programación de aplicaciones.


Un saludo

[AlZuwaga]

Hola tamm, estoy de acuerdo con vos en que dentro de entornos restringidos a determinados usuarios (un panel de control, intra y extranets, homebankings, etc) se haga uso y abuso de determinadas tecnologías. Total, los requisitos los pone la aplicación y si no estás de acuerdo pues... no lo podrás usar. Es simple: es el usuario quien debe adecuarse a los requisitos.

Pero no pienso de la misma manera cuando de un simple sitio web se trata. Esto ya no es una aplicación y debería poder funcionar en el 100% de los casos (digo que debería por hacer una especie de meaculpa, ya que suelo muchísimas veces caer en dichos errores de usabilidad)

Quisiera citar lo siguiente:

...pero en entornos restringidos a determinados usuarios hay que evitar esa sobrecarga por todos los medios pues el uso del ancho de banda hay que compartirlo con los usuarios "generales"...

Por un lado, usando la técnica que proponés estás escribiendo al menos 6 líneas más de código en el HTML (1 del hidden + 5 de la función).

Por el otro, no creo que las siguientes líneas de código server-side ocupen un gran tiempo de procesamiento:

Código:

arr_tmp = split(request.form("select"), ",")
id_pais = arr_tmp(0)
nombre_pais = arr_tmp(1)

Que dicho sea de paso, ocupa sólo una línea más que cómo lo recibirías según tu método:

Código:

id_pais = request.form("select")
nombre_pais = request.form("texto")

Saludos

[tammander]

Hola Al Zuwaga. Tienes toda la razon del mundo :) Mi código es más extenso que el de groka_22 y posiblemente menos efectivo.

Lo cierto es que suelo tirar mucho de código reutilizable (mi propia libreria) y procuro que las variables vayan y vengan lo más puras posibles (ya sabes, parejas de datos nombre/valor) y no tener que manipular los datos dependiendo de como programo para cada cliente. Esto agiliza mucho la lectura del código en posteriores modificaciones y no tardo demasiado en identificar el error o el sitio donde hay que "operar" para su modificación.

Este hecho me obliga a estandarizar mi metodología. Tiene sus inconvenientes pero muchas ventajas. Por eso, cuando veo valores que comparten datos me llevo las manos a la cabeza (si yo tuviera que recordar que aplicaciones web no llevan mis directivas, me volveria loco).




Un saludo