asp.net - una - pagina maestra visual studio 2017
Elementos de formulario en ASP.NET Páginas maestras y páginas de contenido (12)
Solo puede tener un formulario en una página ASP.NET. Una forma de manejar esto es colocar un controlador de eventos en el botón de inicio de sesión en la página maestra. El manejador validará al usuario y lo redirigirá a la misma página en caso de éxito (para ejecutar correctamente el controlador Page_Load, que se ejecuta antes de los manejadores de eventos).
OK, otro bache en mi proyecto actual.
Nunca he tenido elementos de formulario en mis páginas maestra y de contenido, tiendo a tener todos los formularios en el contenido donde sea relevante.
Sin embargo, en el proyecto actual, tenemos una página donde quieren ambos. Un formulario de inicio de sesión en la parte superior derecha y un formulario de preguntas en el contenido.
Después de haber tratado de entender esto, me he encontrado con el problema de que ASP.NET lamenta la necesidad de un único elemento de formulario en una página maestra. TBH, realmente no entiendo por qué esto es un requisito en la parte de ASP.NET, pero hola ho.
¿Alguien sabe si / cómo puedo obtener las páginas maestra y de contenido para que contengan elementos de formulario que funcionen independientemente?
De lo contrario, ¿puede ofrecer consejos sobre cómo proceder para obtener la apariencia / funcionalidad deseada?
Todos los demás ya han mencionado que solo puede tener un único elemento de formulario en una página ASP.NET dada y que estaría contenido en la página maestra. Hasta aquí todo bien. Pero no creo que eso te ayude a llegar a donde quieres estar ...
En sus páginas maestras, usted (supongo) definió los controles asp:ContentPlaceHolder . Sus páginas que usan el maestro tienen asp:Content Correspondiente asp:Content Etiquetas de asp:Content . Todo el contenido de su página debe ir en estas asp:Content correspondientes asp:Content Etiquetas de asp:Content .
Una vez en esa etiqueta, son parte del formulario de la página maestra. La página maestra puede responder a eventos desde sus propios controles, y las páginas responden a los eventos desde sus propios controles, y usted está configurado.
Si necesita que la página interactúe con la página maestra, puede acceder a ella a través de la propiedad Page.Master . Para interactuar con cualquier código visible públicamente (métodos, propiedades, etc.) de la página maestra, debe convertir esta propiedad al tipo correcto y acceder al código público visible desde allí.
Eso debería llevarte a donde necesitas estar en este escenario. (¡Me funcionó en múltiples sitios!)
la etiqueta del formulario está en la página maestra, como tal, puede codificar cualquier control del servidor asp.net en la página maestra que desee. Y puede escribir la lógica de procesamiento para esos controles de servidor en el código de la página maestra detrás del archivo.
Entonces, en su ejemplo, puede tener los controles de inicio de sesión en la esquina superior derecha de la página maestra y luego tener la lógica de autenticación en la página de códigos para la PÁGINA PRINCIPAL, no en su página de contenido.
Esto le permite tener los controles de inicio de sesión en cada página, y mantener ese procesamiento, así como mantener los controles de contenido y su procesamiento en sus páginas individuales.
no, solo puedes tener un formulario asp.net por página. Esa ha sido la regla desde 1.0
Ambos deberían compartir la misma forma
Pensé que podría revisar algunas de mis preguntas pendientes y ver si puedo cerrar algunas de ellas.
Esta fue una interesante. Me negué rotundamente a creer que solo puedes tener un formulario en una página ASP.NET. Esto para mí no tiene sentido. He visto muchas páginas web que tienen más de un formulario en una página web, ¿por qué una página ASP.NET debería ser diferente?
Entonces, me hizo pensar.
¿Por qué una página ASP.NET necesita un elemento de formulario?
Las páginas ASP.NET intentan emular el entorno WinForms, mediante la persistencia de estado proporcionada a través del modelo PostBack. Esto proporciona un elemento de estado a un entorno sin estado. Para hacer esto, el tiempo de ejecución debe poder mantener este estado dentro de cada "forma". Lo hace mediante la publicación de datos de regreso a sí mismo. Es importante tener en cuenta que:
- No hay nada realmente lujoso sobre un PostBack.
- Utiliza un formulario HTTP y POST, al igual que cualquier otra forma, desde cualquier otra pila.
- Solo porque parece que podría estar haciendo algo especial, no es así, todo lo que sucede es que POST está de regreso con algo de información sobre qué lo causó, por lo que puede hacer cosas como manejar eventos del lado del cliente, en código del lado del servidor.
Entonces, ¿por qué solo uno?
Esto para mí fue la pregunta del millón de libras (soy británico). Entiendo que ASP.NET necesita esto, especialmente si está utilizando controles de servidor ASP.NET, pero ¿por qué demonios no puedo crear mis propios formularios adicionales?
Entonces, pensé en arruinarlo, ¡solo crea tu propia forma!
Y lo hice. Agregué un formulario simple estándar de pantano con una acción de envío de "#". Esto luego realiza una POST a la página actual, con los datos de formulario para el formulario dado en la solicitud.
¿Adivina qué? Todo funcionó bien. Así que terminé con:
- Una página maestra, con un formulario HTML en
- Este formulario publica de nuevo en la página actual (básicamente la página que usa el maestro).
- En el código subyacente Page_Load para el maestro, agregué código para verificar la solicitud y ver qué datos se pasaron en la solicitud. Si contiene datos (por ejemplo, un campo oculto), entonces sé que la publicación se obtuvo del Formulario en la página maestra, de lo contrario, es muy probable que se haya producido un Retorno desde el contenido y se puede ignorar.
- Luego rodeé las etiquetas de Contenido con las etiquetas
<form runat="server" id="aspNetForm"...> </form>. Esto significaba que todas las páginas de contenido tenían automáticamente un formulario para trabajar.
Esto me proporcionó una solución relativamente simple y limpia para mi problema. Mi formulario de inicio de sesión funciona bien en conjunto con todos los formularios de contenido creados, algunos de los cuales son formularios complejos, otros usan muchos controles de servidor y muchos PostBacks, y así sucesivamente.
Espero que esto ayude a otros.
Robar,
Solución interesante No veo ningún problema con lo que estás haciendo. El problema que algunos pueden encontrar sin embargo, es si intentan hacer esto con 2 formularios de servidor. No hay regla en ASP.NET de que no puedas tener más de 1 formulario HTML en una página, solo que no puedes tener más de un formulario "runat = ''server''" en la página. Obviamente, has encontrado una manera bastante fácil de satisfacer tus necesidades.
Descubrí que, en su mayor parte, lidiar con un único formulario no es un problema porque el marco ASP.NET básicamente separa todo para nosotros al nombrar contenedores. Sin embargo, en su comentario inicial de publicación, señala el importante factor ausente pero crítico para la esencia de la pregunta original: ingrese el comportamiento clave. Eso siempre lanza una llave inglesa a las obras.
Si tuviera que usar un formulario de servidor estándar "completo", ¿no podría capturar la acción correcta utilizando un evento de texto modificado de texto? Por supuesto, si el usuario cambia ambos valores antes de presionar Enter, o bien obtendría un comportamiento extraño. Y creo que el problema central con la tecla Intro es que una vez que tienes más de una entrada de envío en un formulario HTML, presionar ENTER en un cuadro de texto no hace nada. Solo cuando hay un elemento INPUT único, la tecla Intro causa que se "haga clic" en uno.
Resolví el problema "hacer clic en la clave de retorno en la subformulación de inicio de sesión hace que el formulario principal envíe" en mi proyecto actual al insertar un iframe en la página maestra. El iframe apuntaba a la página login.aspx que autenticaba al usuario.
<iframe id="login" src="login.aspx" frameborder="0" enableviewstate="false" scrolling="no" runat="server"></iframe>
(por alguna razón, necesitaba la etiqueta de cierre / iframe, de lo contrario, la vista de diseño se confundió)
Puede tener más de 1 formulario. (solo 1 visiable a la vez) línea de código 1 = formulario 1 visible / formulario 2 oculto. Código 2 Form 2 visible / formulario 1 oculto. = resuelto (esto también es ideal para formularios de contacto estáticos)
Puede acceder a los controles de MasterPage desde el formulario aspx: agregue la etiqueta de detractivo a la forma aspx <% @ MasterType VirtualPath = "~ / Site.Master%> y en el código detrás use Master.FindControl (); para obtener el control por CARNÉ DE IDENTIDAD
por ejemplo, si desea obtener el formulario Control = Master.FindControl ("formulario")
ahora puede usar el formulario de la página maestra en su código.
Espero esta ayuda.
Ninguna de las respuestas anteriores dio un ejemplo de código. Aquí hay una versión simplificada de Visual Studio 2012 Site.Master que ilustra cómo hacer esto:
<%@ Master Language="C#" AutoEventWireup="true" CodeBehind="Site - Copy.Master.cs" Inherits="WebApplication1.Site1Master" %>
<!DOCTYPE html>
<html>
<head runat="server">
<title>This is a title</title>
<asp:ContentPlaceHolder runat="server" ID="HeadContent" />
</head>
<body>
<form runat="server">
<header>
<div class="content-wrapper">
<div class="float-right">
<section id="login">
<asp:LoginView runat="server" ViewStateMode="Disabled">
<AnonymousTemplate>
<asp:ContentPlaceHolder runat="server" ID="AnonContent" />
</AnonymousTemplate>
<LoggedInTemplate>
<asp:ContentPlaceHolder runat="server" ID="LoggedInContent" />
</LoggedInTemplate>
</asp:LoginView>
</section>
</div>
</div>
</header>
<div id="body">
<asp:ContentPlaceHolder runat="server" ID="FeaturedContent" />
<section class="content-wrapper main-content clear-fix">
<asp:ContentPlaceHolder runat="server" ID="MainContent" />
</section>
</div>
</form>
</body>
</html>
Así que tiene todo envuelto por un solo elemento de formulario, por lo que puede colocar controles en la página maestra, sin embargo, sus páginas de contenido también pueden usar controles.
Esta es una limitación de ASP.NET
ASP.NET está diseñado para tener un formulario por página y solo un formulario. Cuando fue diseñado originalmente eso no fue un problema.
Sin embargo, desde entonces esto se ha identificado como un gran problema con la accesibilidad.
Microsoft Fix para esto fue ASP.NET MVC, si es posible, sugeriría cambiar a ASP.NET MVC ya que resuelve una gran cantidad de problemas con ASP.NET
¡Ungüento! En un hilo similar, publiqué una respuesta que podría ayudarte. Puede usar jquery para agregar contenido a un div vacío. Ese contenido puede incluir etiquetas de formulario e incluso una función de envío independiente de cualquier cosa que esté haciendo el código del lado del servidor. ¡El único inconveniente de esto es si el usuario no tiene javascript habilitado!
En lugar de volver a publicar la misma respuesta (y el código también), aquí está el enlace: