Problema con scroll en ventana modal bootstrap

En bootstrap al abrir una ventana modal automáticamente se desactiva el scroll de la parte que se encuentra en el background.

Si al cerrar la ventana modal no consigue restablecerse el scroll se puede utilizar el siguiente cambio en el css:

Esto es el css que hace desaparecer el scroll

.modal-open {
    overflow: hidden;
}

Se puede modificar por lo siguiente

.modal-open {
    overflow: scroll;
}

De esta manera el scroll siempre estará activo.

 

Utilizar AsyncPostBackTrigger o Update

Cuando utilizamos un UpdatePanel en Asp.Net WebForms a veces no tenemos en cuenta el uso final al que va destinado. Es decir, en ocasiones se hacen llamadas al servidor que no requieren un refresco del UpdatePanel con lo que no tiene sentido actualizarlo.

Entendiendo el UpdatePanel

Existe una propiedad fundamental para configurar el UdpatePanel y este es el UpdateMode. Puede tener 2 valores: Allways y Conditional.

Si establecemos este valor en Allways, todas las llamadas al servidor de los controles que produzcan un postback harán refrescar el panel. Esta es una opción muy rápida, que además viene por defecto, pero en mi opinión no nos ayuda nada a la hora de aprovechar al máximo los beneficios de AJAX y el UpdatePanel.

Estableciendo el valor UpdateMode en Conditional, deberemos preocuparnos nosotros de indicar qué controles realizarán el update en el panel o bien indicarle en nuestro código cuándo debe actualizarse.

Establecer los controles en la sección Triggers para indicar cuales de ellos producirán un update del panel puede parecer una buena opción, desde luego no está mal, pero ¿por qué deberíamos hacerlo si podemos indicarlo en el código mediante el método Update() del UpdatePanel?

La ventaja de utilizar el método Update() frente por ejemplo AsyncPostBackTriggers es que tenemos controlado en todo momento cuando se debe actualizar el UpdatePanel. Si, por ejemplo, tenemos un método en el servidor que responde a un click de un botón y dentro de este método tenemos condicionales que harán que el resultado sea o no visible para el usuario podremos indicar nosotros mismos cuando una acción alterará los datos visibles en pantalla mediante el método Update().

 

Realizar tareas programadas en una aplicación ASP.Net

Desarrollo y programación .net

Por circunstancias de la vida me he encontrado últimamente con varios proyectos realizados en ASP.Net que requieren realizar tareas programadas que se ejecuten en un momento concreto del día independientemente si existe o no usuarios conectados.

Como suele ocurrir existen muchas maneras de abordar esta funcionalidad:

  • Mediante Servicios Windows, siempre que tengamos total control de nuestro servidor y el entorno para realizar la tarea en cuestión (Base de Datos, acceso al sistema de ficheros, etc.)
  • Mediante WCF. También sería necesario acceso total a IIS y a su configuración.
  • Mediante programación dentro de la misma aplicación ASP.Net.

Seguro que existe alguna otra pero mi objetivo primordial en todos estos proyectos que debía realizar era optimizar los tiempos mantenimiento, para ello creo que la última solución resultaba la mejor en este caso ya que solo tendría que dedicarme a modificar un único proyecto: la aplicación ASP.Net. De otro modo tendría que instalar el servicio windows o configurar el proyecto WCF dentro del IIS.

Así que me puse a investigar por la web cuales eran las mejores prácticas de cómo realizar una tarea programada en background dentro de ASP.Net. Encontré una solución que me parecía muy clara y que muchos reportaban como buena. Su funcionamiento requería del uso de la caché de la aplicación web y el método application_start dentro del global.asax.

Su uso consistía en añadir un objeto a la cache en el contexto de ejecución para que cuando dicha cache expirara utilizara el evento para ejecutar de nuevo la tarea. La palabra clave para este método es CacheItemRemovedCallback… pero os anticipo que yo NO LO UTILIZARÉ MÁS.

No voy a adentrar en los motivos de rehusar finalmente este método pero os puedo asegurar que da problemas, incluso cuando establecemos el tiempo de inactividad a 0 dentro del pool de aplicaciones del IIS, que en principio parecía que podía ser una de las soluciones.

Investigando un poco más pude dar con un componente muy interesante: Quartz.

Su uso es muy sencillo y parece ser que existe un componente homónimo en Java.

Quartz tiene una Interfaz denominada IJob que únicamente expone un método llamado Execute(). Si deseas hacer una tarea a nivel de aplicación únicamente debes llamar JobScheduler.Start() dentro de Application_Start() del Global.asax.

using Quartz;
using Quartz.Impl;
using System;
 
namespace ScheduledTaskExample.ScheduledTasks
{
    public class JobScheduler
    {
        public static void Start()
        {
            IScheduler scheduler = StdSchedulerFactory.GetDefaultScheduler();
            scheduler.Start();
 
            IJobDetail job = JobBuilder.Create<MyJob>().Build();
 
            ITrigger trigger = TriggerBuilder.Create()
                .WithDailyTimeIntervalSchedule
                  (s =>
                     s.WithIntervalInHours(24)
                    .OnEveryDay()
                    .StartingDailyAt(TimeOfDay.HourAndMinuteOfDay(0, 0))
                  )
                .Build();
 
            scheduler.ScheduleJob(job, trigger);
        }
    }
}

Comparativa de rendimiento de plantillas WordPress

Como sabemos desde hace algún tiempo en muchos casos se ha ido dejando de lado el rendimiento de los sitios web dando prioridad a otros aspectos como eran la «espectacularidad» del sitio y la inserción numerosos scripts por parte del programador que ralentizaban de manera increíble la carga de una página.

Esta tendencia está cambiando en gran parte a las preferencias de buscadores como google en la red .net a situar mejor a aquellos sitios que tienen una carga de página más liviana, y así de paso para promocionar sus servicios como por ejemplo page speed service.

La razón de realizar esta comparativa de rendimiento de plantillas WordPress es simplemente analizar la evolución en este aspecto de estas themes con respecto al rendimiento. Sabemos que existen numerosas plantillas en el mercado pero nos centraremos únicamente en las que proporciona WordPress al inicio de la instalación:

  • Twenty Fifteen
  • Twenty Fourteen
  • Twenty Thirteen

Para realizar la métrica utilizaremos PageSpeed Insights de Google.

Nota: existen factores externos de terceros que pueden afectar a la carga de una página como puede ser el servidor que aloja el sitio o la velocidad de transferencia, en nuestro caso y para que la comparativa sea más justa se ha procurado realizar esta comparativa en las mismas condiciones para todas las plantillas.

Twenty Fifteen

Resultado Móvil: 64 / Resultado Ordenador: 74

Rendimiento de Plantilla Twenty Fifteen

Twenty Fourteen

Resultado Móvil: 67 / Resultado Ordenador: 78

 

Rendimiento de plantilla Twenty Fourteen

Twenty Thirteen

Resultado Móvil: 68 / Resultado Ordenador: 83

Rendimiento de plantilla Twenty Thirteen

 

 

Resultado

Como vemos no hay grandes diferencias entre ellos pero estamos viendo que la evolución de las plantillas tampoco muestra una mejora en el rendimiento.

Timeout en MySQL con Entity Framework

Si se produce un timeout en MySQL con Entity Framework la primera opción que se nos podría ocurrir es agregar el parámetro default command timeout en la cadena de conexión:

<add name="Entities" connectionString="metadata=res://*/DAL.MyModel.csdl|res://*/DAL.MyModel.ssdl|res://*/DAL.MyModel.msl;provider=MySql.Data.MySqlClient;provider connection string='server=localhost;persistsecurityinfo=False;user id=root;password=;database=myddatabase;default command timeout=300'" providerName="System.Data.EntityClient" />

Por desgracia esta solución no funciona debido a un bug en el connector / NET de MySQL. Ver ref. bug.

Por suerte existe una opción para cambiar este valor para el object context en Entity Framework, dependiendo de la versión de Entity Framework:

Entity Framework 6:

this.context.Database.CommandTimeout = 180;

Entity Framework 5:

((IObjectContextAdapter)this.context).ObjectContext.CommandTimeout = 180;

Entity Framework 4 e inferiores:

this.context.CommandTimeout = 180;