2010-05-21 18 views
16

Siempre he visto una gran cantidad de campos ocultos utilizados en aplicaciones web. He trabajado con código que está escrito para usar muchos campos ocultos y los valores de los datos de los campos visibles que se envían hacia adelante y hacia atrás. Aunque no entiendo por qué se usan los campos ocultos. Casi siempre puedo pensar en formas de resolver el mismo problema sin el uso de campos ocultos. ¿Cómo ayudan los campos ocultos en el diseño?¿Por qué se usan campos ocultos?

¿Alguien me puede decir cuál es exactamente la ventaja que ofrecen los campos ocultos? ¿Por qué se usan campos ocultos?

+0

En realidad, no puedo encontrar un ejemplo en el que no necesite un campo oculto. ¿Puedes proporcionar uno? :) – ZeissS

+4

¿Por qué está etiquetado 'C#'? ¿Quiso preguntar específicamente sobre el uso de campos ocultos en ASP.NET? –

+0

Sí, quise preguntar sobre el uso de campos ocultos en ASP.NET. Marqué la pregunta en consecuencia. gracias @ Jørn Schou-Rode – pavanred

Respuesta

16

Los campos ocultos es la manera más fácil, es por eso que se usan bastante.

Alternativas:

  • almacenamiento de datos en un servidor del lado de la sesión (con la galleta del sessionid)
  • almacenamiento de datos en un servidor del lado de la transacción (con identificación de la transacción como el campo oculto individual)
  • utilizando ruta URL en lugar de los parámetros ocultos de campo de consulta en su caso

principales preocupaciones:

  • no se puede confiar en que el valor del campo oculto no se altere de página a página (en lugar de almacenamiento en el servidor)
  • big data debe publicarse siempre, podría ser un problema, y no es posible que algunos datos (por ejemplo, cargado imágenes)

ventajas principales:

  • no hay sesiones pegajosa que se derraman entre las páginas y múltiples ventanas del navegador
  • ninguna limpieza del lado del servidor es necesario (por datos caducados)
  • accesibles para el lado del cliente guiones
+1

+1 por excelentes explicaciones de los beneficios y las dificultades. – IAbstract

+2

Falta la buena alternativa ViewState para almacenar dichos valores. –

+1

@Tim: ViewState * de ASP.NET * se implementa * utilizando campos de entrada ocultos. –

4

El uso más típico que veo/uso es para los ID y otras cosas que realmente no necesitan estar en la página por algún otro motivo que no sea necesario en algún momento para ser enviado de vuelta al servidor.

-edit, debería haber incluido más detalle-

dicen por ejemplo que haya algún objeto que desee actualizar - la interfaz de usuario devuelve una colección de valores y el servidor en ese punto puede o no puede saber "Oye, este es un objeto del cliente", por lo que envías una solicitud al servidor y dices "hey, dame la ID 7" y ahora tienes tu objeto de cliente, ya que el sistema lo sabe. Las actualizaciones se aplican, validan, lo que sea y ahora su UI obtiene el resultado completo.

Supongo que una buena excusa/argumento es el uso de linq. Intenta actualizar un objeto en linq sin obtenerlo primero de la base de datos. No tiene una idea real de que es algo que puede hacer un seguimiento hasta que obtenga el objeto completo.

1

Se usan generalmente para almacenar estados a medida que progresa la interacción. Las cookies se pueden usar en su lugar, pero algunas personas las desactivan. También podría usar un solo campo oculto para apuntar al estado del lado del servidor, pero luego hay problemas de adherencia de sesión.

3

Hay muchos escenarios útiles.

Una es para "almacenar" algunos datos en una página que no debe ser ingresada por un usuario. Por ejemplo, almacene el ID de usuario al generar una página, luego este valor será enviado automáticamente con el formulario de regreso al servidor.

Otro escenario es la seguridad. Agregue un token oculto a la página y verifique su existencia en el servidor. Esto ayudará a identificar si un formulario fue enviado a través del navegador o por algún bot que acaba de publicar en alguna URL de su sitio.

12

Supongamos que desea editar un objeto. Ahora es útil poner la ID en un campo oculto. Por supuesto, debe no confiar nunca en ese valor (es decir, asegúrese de que el usuario tenga los derechos apropiados al insert/update).

Aún así, esta es una solución muy conveniente. Mostrar el ID en un campo visible (por ejemplo, cuadro de texto de solo lectura) es posible, pero irritante para el usuario.

Almacenar el ID en una sesión/cookie es prohibitivo, porque no permite múltiples ventanas de edición abiertas al mismo tiempo e impone restricciones de por vida (el tiempo de espera de la sesión resulta en una operación de edición rota, muy molesto).

El uso de la URL es posible, pero rompe las reglas de diseño, es decir, utiliza POST al modificar los datos. Además, dado que es visible para el usuario, crea URL más desagradables.

3

Mantiene las cosas fuera de la dirección URL (como en la cadena de consulta) por lo que mantiene tan limpia. También mantiene las cosas fuera de la sesión que pueden no necesariamente tener que estar allí.

Aparte de eso, no puedo pensar en muchos otros beneficios.

3

he aquí una razón, forma conveniente de pasar datos entre el código del cliente (javascript) y el lado del servidor.

1

Si está utilizando un campo oculto en el formulario, está aumentando la carga de forma al incluir un nuevo control.

Si no hay necesidad de tomar el campo oculto, no debe tomarlo porque no es adecuado sobre la base del punto de seguridad. usar el campo oculto no está bajo la buena programación. Porque también afecta el rendimiento de la aplicación.

Cuestiones relacionadas