Problemas con el evento .scroll() de jQuery sobre IE?

Programación > CSS

Como siempre! nuestro “amigo” Internet Explorer (IE) dándonos problemas.

Algo tan simple como tener un DIV con un evento “scroll” de jQuery no funciona para IE.

Pongamos un conjunto basico de elementos
<div id="pages"></div>

en CSS algo como:
#pages { overflow: auto; position: absolute; height: 290px; width: 100%;}

y en un script algo como:
$("#content #pages").scroll(function () { //code});

nos dará como resultado que funciona en todos los Navegadores menos IE. La conclusión que hemos sacado luego de algunas pruebas es que IE hace que el evento solo responda sobre las áreas donde exista algún elemento visual (traduzcase como alguna propiedad que realmente lo obligue a renderizar algo porque un DIV vacío no renderiza nada visual).

Si dentro del DIV ponemos algún elemento visual o sencillamente le asignamos un color pues el evento comienza responder. Pero si no puedo poner un color de fondo porque no va con el diseño de la página pues que hago?

Una solución simple que se me ocurrió es ponerle como background una imagen transparente de 1 pixel de ancho por alto y que se repita. De esta forma consigo todo lo que quiero:
- Que el DIV continúe sin “contenido visual” como lo necesito.
- Que IE lo asuma como que posee “contenido visual” y responda al evento en toda el área que abarca el DIV.

El CSS quedaría en algo como:
#pages {
overflow: auto; position: absolute; height: 290px; width: 100%;
background: url(../images/desktop/common/scroll-pages-bg-fix-to-ie.png) repeat;
}

Lo mismo pudiera aplicarse para los demás eventos de scroll como “mousewheel” aunque no le he probado.

Problemas con el tamaño de los fonts cuando cambia la orientación de su Navegador móvil?

Programación > Móviles

Después de pasar varias horas en busca de un supuesto error en el HTML o el CSS de un proyecto, de frustrarme hasta que te dan ganas de tirar la laptop contra el piso y de que apareció un amigo que encontró la solución mágica del problema buscando en Internet pues creo que merece la pena dejarlo por escrito a ver si otros pobres del mundo no sufren lo que me ha tocado hoy.

El proyecto es bastante complejo y quizás eso hacía ver el problema como consecuencia de algún error interno. Pero el problema era tan simple como que un DIV mostrando simplemente texto no era capaz de mostrarlo de forma correcta en ambas vista u orientaciones, Portrait y Landscape, cuando íbamos de la primera a la segunda y regresabamos de nuevo a Portrait.

Era para volverse loco. Revise varias veces los estilos para ambas vistas, cambie todas y cada una de las unidades de medida del FONT-SIZE de “pt” a “px” y todo en vano. Lo más frustrante es que por momentos algún cambio hacía que se visualizara correctamente y después todo se desvanecía. Por otro lado en la PC todo funcionaba a las mil maravilla y evidentemente en el móvil todo se hace más difícil de depurar.

Para no darle más vueltas al asunto pues ya he perdido suficiente tiempo por hoy, jeje, la solución radica en poner en el CSS la siguiente línea de código:

-webkit-text-size-adjust: none;

Asi de sencillo??, pues si. Es una de las tantas magias oscuras que posee WebKIT. Este problema puede tenerlo cualquier WEB que se visualice en un dispositivo móvil con algún Navegador basado en webkit, como Safari y Chrome. En mi caso estaba probando sobre un iPhone5 y un tablet Nexus7 de Google.

Creo que a partir de hoy vendre a este Blog a copiarla y pegarla en cada proyecto nuevo que comience.

LINQ to SQL. Tratamiento de Transacciones con TransactionScope (parte 3 final))

Aunque no fue mencionado, la variante primera de lograr transacciones también tenía un problema: No se admitían transacciones anidadas.

La clase TransactionScope viene a solucionar todos los problemas con transacciones, diseñada incluso para el caso que queramos, en medio de una transacción, ejecutar un bloque de código fuera de ella.  Genial!.

Su uso seria en un bloque similar al siguiente:

using (TransactionScope trans = new TransactionScope())

{

    //Operaciones

    trans.Complete();

}

Aquí se extrañaran de no ver algo parecido a un Rollback y un bloque de try..catch en el cual se llame: NO ES NECESARIO. Al utilizar el TransactionScope en un bloque using, el mismo sistema se encarga de deshacer todas las operaciones si al concluirlo no se ha llamado al método Complete().

Claro que un bloque try..catch será necesario para capturar excepciones pero no para llamar a un Rollback específicamente.

Este mecanismo está preparado para hacer transacciones sobre múltiples servidores a la vez, caso en el cual usa el servicio MSDTC de Windows como soporte.

No obstante, no todo es felicidad. Esta clase utiliza un mecanismo propio (por llamarlo de una forma más amigable) en caso que dentro de su bloque se utilice solo una conexión de datos o DataContext. Si se llegan a utilizar dos entonces hace uso del servicio MSDTC para gestionarlo lo que nos obligaría a instalarlo en las PC donde se use el sistema.

En Windows7 de 64 bit existen varios reportes de personas en Internet que no les corre por la ausencia del servicio y en mi caso lo viví en carne propia. Aunque la solución sería la instalación del servicio y listo a mí no me resultaba factible agregar un pre-requisito más a mi sistema así que ajuste el código fuente a que usara siempre una sola instancia del DataContext al menos mientras se estuviera dentro del contexto de la transacción (bloque using).

Hasta aquí lo relacionado a los problemas más relevantes que hemos tenido. Los beneficios han sido muchos más con el uso de LINQ to SQL. Solamente tendría algo importante que criticarle y es que el modelo creado no incluye un par de métodos WriteToXml y ReadFromXml como los tiene la tecnología de Ado.Net con el uso de los DataSet. No es que Linq to SQL no tenga mecanismo de exportar a Xml sino que es, por mucho, más complejo, aunque también ofrece buena flexibilidad.

Todo problema con LINQ to Sql que puedan reportar en este blog será bienvenido.

Problemas con Jdbc para conectar a una BD en SqlServer 2005 Express (PROGRAMACION)

Crear aplicaciones de bases de datos en Java a través de Jdbc puede no ser siempre una experiencia alegre, sobre todo cuando se trata de conectarlas con SqlServer.

En nuestro caso trabajamos con el IDE Eclipse, usamos un driver de Microsoft y usamos SqlServer 2005 Express Edition.

Los primeros problemas vienen con el Driver que a decir de varias personas en Internet no es la mejor opción seleccionar el de Microsoft sino otros de terceros que incluso se pueden encontrar en CodeProjetc con licencia GNU.

En Microsoft encontramos varias versiones: “Microsoft SQL Server JDBC Driver 2.0” y “Microsoft SQL Server 2005 JDBC Driver” y aunque la lógica indica hacer uso de este ultimo pues en mi caso solo funcionó el primero.

Entonces, ya sabe, si tiene problemas con la supuesta versión 2005 del Driver pues utilice en su lugar la versión “Microsoft SQL Server JDBC Driver 2.0”.

Estructura de la Cadena de Conexión.

Lo primero es un curso de adivino, hasta que te convences y buscas la documentación. Normalmente en todas las cadenas de conexión el nombre del servidor es “NombreServidor\NombreInstancia” (recordemos que podemos tener varias instancias de SqlServer en la misma PC, incluso de la misma versión) pero no se por cual motivo nuestros amigos de Microsoft decidieron separar aquí estas dos propiedades: Supongo que de fondo sea por culpa de alguna limitación de Java, jajaja.

El formato es como sigue:

"jdbc:sqlserver://MOMBRE_SERVIDOR;instanceName=NOMBRE_INSTANCIA;user=USUARIO;password=PSW;databaseName=NOMBRE_BD";

Un ejemplo concreto sería:

"jdbc:sqlserver://miServidor;instanceName=SQLEXPRESS; user=sa;password=miPassword;databaseName=miDB";

Una vez que esto es correcto estaremos en condiciones de crear Conexiones en Java a través del java.sql.DriverManager: DriverManager.getConnection(connectionUrl);

A partir de este momento pueden generarse una serie de mensajes de error entre cuyas causas están las siguientes:

- No Suitable Driver.

Este es un error bastante común y que lo he visto bastante documentado salvo por el segundo punto que expondré.

Lo primero es verificar que incluimos la biblioteca del driver en el ClassPath del proyecto. En el caso de Eclipse basta con acceder a la propiedades del proyecto, opción “Java Build Path” en la lista de la izquierda, ficha Libraries, botón “Add External JARs…” y localizar el jar del driver correcto como explique anteriormente.

Pero esto me funciono en varias PC y de pronto en una no me funcionaba, error va y error viene y ni atrás ni adelante, hasta que verificando observe que estaba usando la versión 5 y necesite configurar el uso de la versión 6 del “JRE System Library (jre6)” .

En mi caso, usando Windows7, mas de un problema me vino por esta causa. Por ejemplo el programa iReport no se me abría, entre otros, por lo que le recomiendo descargar la ultima versión del JRE.

- El servicio SQLBrowser está detenido.

Hasta ahora jamás he tenido que iniciar este servicio (parte del SqlServer) para conectarme con SqlServer pero al parecer este Driver hace uso del mismo para detectar la instancia que solicitamos.

Esto lo podemos hacer desde varios lugares: el administrador de Servicios del PC, el “Sql Server Configuration Manager” localizado en el grupo de programas del menú Start de Windows con nombre “Microsoft Sql Server 2005/Configuration Tools”.

- El protocolo TPC/IP de Servidor para SQLEXPRESS está desabilitado.

Casi de seguro deberemos activar el uso de este protocolo pues por defecto no se activa con la instalación.

Desde el “Sql Server Configuration Manager” vaya al árbol de la izquierda a la opción
“SQL Server 2005 Network Configuration/Protocols for SQLEXPRESS” y en la derecha active el protocolo TCP/IP.

- No está activada la Autenticación mixta para Sql Server que nos permita autenticarnos con usuarios propios del mismo y no con los usuarios de Windows.

Desde el “Micorsoft SQL Server Management Studio” acceda al nombre de su Instancia en el árbol de la izquierda (una vez registrado y conectado claro), acceda a sus Propiedades (clic derecho encima y seleccione Properties), vaya a la ficha Security y active la opción “SQL Server and Windows Authentication mode” del grupo de opciones “Server authentication”.

- El usuario “sa”está desabilitado o posee una contraseña diferente a la que está utilizando.

Aunque no es correcto, en ambientes de producción solemos utilizar al mismísimo usuario “sa” (System Administrator) para trabajar pero por defecto la instalación deja la posibilidad de autenticarse a través de este usuario deshabilitada.

Para corregir este problema, desde el “Micorsoft SQL Server Management Studio” acceda al nombre de su Instancia en el árbol de la izquierda (una vez registrado y conectado claro), acceda a la opción Security/Login/sa, y una vez allí, a sus Propiedades (clic derecho encima y seleccione Properties). Vaya a la ficha Status y active la opción “Enabled” del grupo de opciones “Login”.

De paso vaya a la ficha General y verifique o modifique la contraseña para este usuario.

Bueno, son bastantes las causas de errores media mágicas a las que nos enfrentamos como pueden ver. Espero tengan suerte y no se enfrenten a ellas.

Dos problemas con la autenticación en ASP.Net y la seguridad con roles (PROGRAMACION).

Primer problema: El ticket de autenticación pierde el valor  previamente guardado en su propiedad UserData y el formulario de Login se muestra una y otra vez.

He desarrollado varios sitios web utilizando la misma filosofía de autenticación y seguridad de ASP.Net. No obstante me han reportado varias veces que de pronto “Internet Explorer” se comporta de forma inesperada en el proceso de Autenticación y aclaro que casi nunca había sucedido con “Mozilla Firefox”: hasta hoy.

De pronto el formulario de autenticación parecía trabajar bien pero nunca me dejaba salir hacia otras páginas de la administración de mi sitio web. Una y otra vez se mostraba cuando las credenciales de acceso eran correctas. Depuraba el código fuente de la aplicación y todo parecía funcionar correctamente, salvo
que los Roles se perdían de pronto en una u otra esquina.

Para aclarar mejor aun el contexto, tengo una carpeta de nombre ADMIN que guarda todas las páginas de administración del sitio. Esa carpeta tenía las políticas de acceso siguientes:

<?xml version="1.0" encoding="utf-8"?>
<configuration> 
 <system.web>
  <authorization>
   <allow roles="admin" /> 
   <deny users="*" /> 
  </authorization> 
 </system.web> 
</configuration>
    

Pues bien una solución momentánea fue cambiar la política

<deny users="*" /> a <deny users="?"/>
    

Aunque luego más tarde no me solucionó aún el problema sino que me llevó al segundo.

Segundo problema: El tratamiento de roles

Cuando queremos habilitar opciones en dependencia del rol(es) del usuario utilizamos el siguiente método para saber si pertenece o no a “rol_name”

HttpContext.Current.User.IsInRole(“rol_name”)

Pues bien, algo tan sencillo y que llevo años usandolo de pronto no funcionaba tampoco. Despues de tanto y tanto depurar descubri que se debia a la simple sentencia de configuración siguiente que accidentalmente se me habia agregado al archivo de configuración de la raiz del sitio.

<?xml version="1.0"?> 
 <configuration> 
  <system.web> 
   <roleManager enabled="true" />

Bastó con eliminar esta linea de la configuración y todo volvió a la normalidad: tanto mi primer problema como el segundo.

Es necesario aclarar que las causas pudieran ser varias más, así que solo pretendo ofrecerles un par de posibles soluciones para cuando se les presentes estos “mágicos” e indeseables comportamientos en la autenticación con ASP.Net.

Enlace recomendado:
¿Será el contenido la mejor herramienta de posicionamiento web en buscadores? (seo)