Dar prioridad a un PostBack Asíncrono específico (1ª parte)

20. October 2010 22:00 by Oscar.SS in Desarrollo Web  //  Tags:   //   Comments (0)
Le recomiendo al lector que antes de empezar a leer este artículo dedique unos minutos a este otro artículo. En él se explican algunos conceptos que serán necesarios para comprender lo que ahora veremos.
 
Cuando estamos trabajando bajo el esquema del UpdatePanel podemos tener la necesidad de diferenciar que control u objeto provocó la solicitud asíncrona. Para entenderlo con facilidad veamos un ejemplo.
 
Supongamos que tenemos la siguiente interfaz de usuario.
 
 
 
 
La funcionalidad que queremos implementar es que tanto al guardar la dirección del usuario, como al borrar la dirección del campo de texto, se produzca con AJAX. Además, antes de borrar queremos pedir una confirmación al usuario.
 
Introducimos el campo de texto dentro del UpdatePanel y obtenemos el siguiente código.
 
        <asp:UpdatePanel ID="UpdatePanel1" runat="server">
            
<ContentTemplate>
                
<asp:Label ID="lbDireccion" runat="server" Text="Dirección:   "></asp:Label>
                
<asp:TextBox ID="tbDireccion" runat="server" Width="260px"></asp:TextBox>
            
</ContentTemplate>
            
<Triggers>
                
<asp:AsyncPostBackTrigger ControlID="btBorrar" EventName="Click" />
                <
asp:AsyncPostBackTrigger ControlID="btGuardar" EventName="Click" />
            </
Triggers>
        
</asp:UpdatePanel>
 
Ahora viene lo bueno. ¿Como diferenciamos que control provocó la llamada asíncrona?. ¿Como decimos que un botón deba tener una confirmación antes de llamar asincronamente al servidor y el otro botón no?.
 
    <script type="text/javascript" language="javascript">
        
        
//Intercetamos la llamada automatica de AJAX ASP.NET al servidor para pedir una confirmacion antes de eliminar.
        
Sys.WebForms.PageRequestManager.getInstance().add_initializeRequest(confirmarEliminar);

        function 
confirmarEliminar(sender, args) {

            
//Capturamos el boton que inicializa la llamada AJAX.
            
var idPostBack args.get_postBackElement().id;

            if 
(idPostBack == "btBorrar") {
                
var valorConfirm = confirm("¿Está seguro que desea borrar esta dirección.?");

                
//Si el usuario ha cancelado detenemos la llamada al servidor.
                
if (!valorConfirm) {
                    args.set_cancel(
true);
                
}
            }
        }
    </script>
 
En primer lugar debemos interceptar la llamada asíncrona justo antes de que comience. Para ello utilizamos el evento initializeRequest del ciclo de vida cliente. A continuación obtenemos el id del control que provoco la llamada con el método y propiedad get_postBackElement().id. Y en función de la elección del usuario cancelamos la llamada al servidor con el método set_cancel().
 
 

Transformación del Modelo E/R al Modelo Relacional

12. October 2010 20:57 by Oscar.SS in Desarrollo Empresarial  //  Tags:   //   Comments (3)

En el diseño de base de datos lo más difícil y sujeto a la interpretación del desarrollador es construir un buen modelo entidad-relación que represente fielmente el problema. Sin embargo, la transformación de este al modelo relacional es casi mecánico y se basa en unas pocas reglas que ahora veremos.

 

Transformación de entidades débiles

Todas la entidades del modelo E/R  se convierten en tablas en el modelo relacional. Las entidades débiles también se transforman en tablas pero su clave primaria se compone de la unión de esta con la clave de la entidad fuerte a la que pertenece.

 

 

Transformación de las relaciones (1:1)

 

- Mismo Identificador  

Si las dos identidades tienen el mismo identificador se transforman en única tabla que contendrá este identificador como clave primaria y los atributos de ambas entidades.

 

  

- Diferente Identificador  

Cuando tienen diferente identificador cada entidad se convierte en una tabla con su identificador como clave primaria y como clave ajena el identificador de la otra entidad.

 

 

- Cardinalidad Mínima Cero 

Si alguna de las entidades participa con cardinalidad mínima igual a cero se añade una tabla intermedia cuyo identificador se forma por las claves primarias de las otras dos tablas y se le añaden los atributos de la relación cuando los haya.

 

 

 

Transformación de relaciones (1:N)

 

- Cardinalidad Mínima Uno

Si en la relación la entidad que participa con cardinalidad máxima igual a uno, lo hace también con cardinalidad mínima igual a uno, cada entidad se transforma en una tabla con su respectiva clave primaria. La tabla, que participa con caridnalidad N,  tendrá como clave ajena la clave primaria de la otra tabla, así como los atributos de la relación.

 

 

 

Cardinalidad Mínima Cero

En este caso cada entidad se transforma en una tabla con su respectiva clave primaria. Se añade otra tabla que representa la relación, cuya clave primaria será la clave primaria de la tabla con cardinalidad N. Y tendrá como clave ajena la clave primaria de la tabla con cardinalidad uno.

 

 

  

 

Transformación de las relaciones (N:N)

Cada entidad se transforma en una tabla con su respectiva clave primaria. Se añade una tabla para la relación con los atributos de esta y como clave primaria la composición de las claves de las otras entidades.

 

 

 

 

Transformación de las relaciones N-arias

En este tipo de relaciones intervienen 3 o N entidades.

 

 

Al transformarlo al modelo relacional podemos separar cada una de las relaciones y tratarlas por separado.

 

 

De este modo, podemos aplicar las relaciones (1:1), (1:N) o (N:N) según los casos como hemos visto anteriormente. En el ejemplo que nos ocupa tendríamos las siguientes tres tablas. 

 

 

 

 

Transformación de relaciones reflexivas

 

 

En este tipo de relaciones hay que suponer que se trata de una relación binaria normal en la que las dos entidades son iguales. A partir de aquí, aplicar las reglas de las relaciones (1:1) o (N:N).

 

 

 

Recent Comments

Comment RSS

Month List