En este video describo cómo es posible estar verificando si el usuario sigue teniendo la sesión en un sistema web.
Muchas veces nuestra sesión ha terminado por inactividad, y esta logística te servirá para tomar una decisión, si mandar al usuario a la pantalla de autentificación o simplemente mostrarle un mensaje de que su sesión expiro.
Ahora ya podrás ser capaz de detectar si la sesión ha terminado sin necesidad de que el usuario se entere hasta que de clic en algún elemento de tu pagina.
Para que el contenido que tiene un elemento sea copiado automáticamente al portapapeles del usuario, anexo la siguiente función en javascript ayudándome de los selectores de jquery.
Cada paso esta comentado, para en caso de utilizarla con un distinto elemento puedas modificarla sin dificultad.
En el ejemplo realizo la copia del contenido html que existe dentro de un elemento td de una tabla.
HTML
<table>
<tr>
<td onclick="Copiar(this)">Hola soy un texto que se copia al darle clic</td>
<td onclick="Copiar(this)">Hola yo soy otro texto que se copia al darle clic</td>
</tr>
</table>
JAVASCRIPT
function Copiar(element) {
//creamos un input que nos ayudara a guardar el texto temporalmente
var $temp = $("<input>");
//lo agregamos a nuestro body
$("body").append($temp);
//agregamos en el atributo value del input el contenido html encontrado
//en el td que se dio click
//y seleccionamos el input temporal
$temp.val($(element).html()).select();
//ejecutamos la funcion de copiado
document.execCommand("copy");
//eliminamos el input temporal
$temp.remove();
}
Para regresar un arreglo anónimo u objeto anónimo con formato JSON a través de un controller en MVC .Net, por ejemplo la lista de algún catalogo que no se necesite llenar con alguna tabla de base de datos, o una lista de años, meses o días, tenemos que hacerlo de la siguiente manera:
public JsonResult Metodo()
{
return Json(new[] { new { Id = 1, Nombre = "Dato 1"},new { Id=2, Nombre="Dato 2"}
}, JsonRequestBehavior.AllowGet);
//JsonRequestBehavior.AllowGet es opcional si nuestro método permitirá ser llamado por Get
}
Para lograrlo vamos a utilizar el disparador keyup y jquery y haremos un selector por clase, en este caso la llamaremos positive, así podemos reutilizarlo en las cajas de texto que deseemos, código a continuación:
$(".positive").keyup(function () {
var valor = $(this).prop("value");
//evaluamos si es negativo, y ponemos 1 por defecto
if (valor < 0)
$(this).prop("value", "1");
})
Cuando comenzamos a utilizar Entity Framework vemos la maravilla de LINQ al obtener los datos de manera relacional, organizarlos como si de Sql se tratara, pero nunca nos preguntamos que de distinto tiene cuando utilizamos IQueryable o IEnumerable, para explicarlo rápidamente nos basaremos en la siguiente tabla (suponiendo que su nombre es tabla, literal):
Cuando obtenemos los datos con IEnumerable de la siguiente forma:
IEnumerable<tabla> lst= from d in db.tabla
select d;
Si quisiéramos hacer un filtrado con una clausula where posterior a nuestra obtención de datos haríamos lo siguiente:
lst= lst.Where(d=>d.name=='Pedro');
Cuando utilizamos IEnumerable al llenar nuestro objeto con LINQlo que obtenemos son los datos de la tabla en nuestra colección es decir, que al aplicar el filtrado trabajamos directamente con un conjunto de datos en memoria al cual se le hace el where directamente. Esto ocasiona un mal performance cuando nuestra tabla tiene millones de datos ya que los tendríamos en memoria y posterior aplicaríamos el filtrado, esto es una mala practica que jamas se debe hacer.
Ahora veamos la diferencia con IQueryable:
IQueryable<tabla> lst= from d in db.tabla
select d;
//lo que obtiene IQueryable despues de la consulta es:
// select * from tabla
Ahora haremos el mismo filtro posterior a la consulta:
lst= lst.Where(d=>d.name=='Pedro');
//y aquí lo que hacemos es concatenarle:
select * from tabla where name='Pedro'
A diferencia de IEnumerable lo que tenemos en nuestro objeto IQueryablees la consulta SQL en sí, es decir tenemos algo como lo siguiente:
select * from tabla
where name='Pedro'
En conclusión si vamos a realizar filtrados dinámicos en un conjunto de datos se debe utilizar la interface IQueryable, es la forma correcta de aplicar manipulación a nuestra consulta antes de enviarla al servidor de base de datos. ¿Cuando se realizar el envió de la consulta al servidor por parte de IQueryable? Cuando hacemos uso de los datos es decir, cuando aplicamos un foreach o hacemos un ToList().
Para poder cachar excepciones dentro de una consulta LINQ y poder manipular el error para que no truene la consulta en si misma debemos hacer uso de Lambda, esto es útil cuando nuestra base de datos puede presentar inconsistencias las cuales pueden ocasionar una excepción en ciertos casos, y podemos evitarlo de la siguiente forma:
EntityDB db= new EntityDB();
var lst = from d in db.tabla.ToList() //es importante hacerlo lista
select new TablaViewModel
{
id = d.id,
//campo es string por lo cual
//nuestra función delegada regresara igual string
campo = (new Func<string>(() => {
try {
// suponiendo que exista una referencia
// a una tabla secundaria la cual no siempre exista
// lo cual puede ocasionar una excepción
// de esta manera lo podemos manipular
return d.tablaSecundaria.campo2;
}
catch { return "No existe"; }
}
)
)()
};
De esta manera nuestra consulta no tronara y podemos darle un resultado a la vista donde mostraremos nuestros datos.
No es bueno para el rendimiento hacer este tipo de consultas ya que las tablas están en bases de datos distintas, pero muchas veces es necesario para el hecho de crear un reporte, o cuando se expande un sistema con nueva tecnología y al final el cliente desea un reporte combinado entre sus sistemas viejos y los nuevos, yo les mostrare una manera de poder lograr un join entre dos bases de datos distintas. El problema es el siguiente(es hipotético no necesariamente es real solo sirve para el ejemplo), tenemos una base de datos (BD1) con las ventas diarias guardadas en una tabla llamada ventas, se nos pide que sea mostrada la venta y a su lado los datos del domicilio de la tienda, pero nos damos cuenta que no contamos con esos datos, esos datos están en una tabla llamada tienda en una base de datos distinta (BD2), entonces necesitamos hacer un join entre las 2 bases de datos, y para hacerlo debemos tomar a consideración lo siguiente: Debemos evaluar cual tabla tiene menos registros ya que haremos primero la consulta sobre esa tabla primero y esos datos los tendremos en memoria. En este caso la tabla tienda es la que tiene menos datos (una tienda tiene muchas ventas así que el universo es menor por sentido común). Así que primero vamos por las tiendas de la siguiente forma:
//creamos nuestro contexto de la bd2 ya que ahi esta la tabla tienda
var db2= new entitiesTiendaDB();
//obtenemos las tiendas con una consulta simple de linq
var lstTiendas = from d in db2.tiendas.ToList()
select d;
Ahora que a tenemos las tiendas, de la siguiente manera hacemos el join con los datos que ya tenemos en la variable lstTienda:
//creamos el contexto de db1 el cual contiene la tabla ventas
var db = new entitiesVentasDB();
//teniendo un viewmodel llamado VentasViewModel el cual tenga solo los campos que necesitamos creamos la consulta
List<VentasViewModel> lst= from d in db.ventas.ToList()
//nuestra tienda se une por el campo codigTienda de lstTiendas y por el mismo campo en
//la tabla ventas
join t in lstTiendas on d.codigoTienda equals t.codidoTienda into un
//esto hace que sea un left join,
// si no ponen esto solo les regresara todo como inner join
from x in un.DefaultIfEmpty()
orderby t.nombreTienda
select new VentasViewModel
{
idTienda = (x!=null) ? x.id : 0, //como hicimos left join podría haber datos nullos y debemos evaluar
nombreTienda =(x!=null) ? x.nombre : "",
domicilioTienda =(x!=null) ? x.domicilio : "", //asi obtenemos el domicilio
codigo = (x!=null )? x.codigoTienda : "",
total= d.total //este viene en ventas así que accedo con d
subtotal=d.subtotal //igual que arriba
};
Para llenar un SelectList manualmente y poder ser utilizado en nuestro DropDownList (o lo que sea) lo podemos hacer de la siguiente manera:
//creamos una lista tipo SelectListItem
List<SelectListItem> lst = new List<SelectListItem>();
//De la siguiente manera llenamos manualmente,
//Siendo el campo Text lo que ve el usuario y
//el campo Value lo que en realidad vale nuestro valor
lst.Add(new SelectListItem() { Text = "Pato", Value = "1" });
lst.Add(new SelectListItem() { Text = "Perro", Value = "2" });
lst.Add(new SelectListItem() { Text = "Pollo", Value = "3" });
lst.Add(new SelectListItem() { Text = "Gato", Value = "4" });
//Agregamos la lista a nuestro SelectList
SelectList miSL = new SelectList(lst, "Value", "Text");
Para enviar un archivo por medio de Ajax en realidad es muy fácil, sobre todo con la función Ajax de jquery, para ello lo demuestro a continuación: Primero tenemos el código html siguiente, el cual tiene un formulario con un campo de texto y un input file, es importante que el atributo del formenctype sea multipart/form-data, si no es asi no se enviara el archivo.
$(document).ready(function () {
//sobreescribimos el metodo submit para que envie la solicitud por ajax
$("#frmFormulario").submit(function (e) {
//esto evita que se haga la petición común, es decir evita que se refresque la pagina
e.preventDefault();
//ruta la cual recibira nuestro archivo
url="@Url.Content("~/Archivo/Recibe")"
//FormData es necesario para el envio de archivo,
//y de la siguiente manera capturamos todos los elementos del formulario
var parametros=new FormData($(this)[0])
//realizamos la petición ajax con la función de jquery
$.ajax({
type: "POST",
url: url,
data: parametros,
contentType: false, //importante enviar este parametro en false
processData: false, //importante enviar este parametro en false
success: function (data) {
alert("Se capturo el archivo con éxito")
},
error: function (r) {
alert("Error del servidor");
}
});
})
})
Y este es el trabajo que se hace en el front-end, ahora solo queda hacer el método en el back-end el cual capture el archivo y lo guarde o realice la acción deseada con el fichero; por ejemplo en Mvc.Net seria de la siguiente manera:
//controlador de mvc.net
public class Archivo : Controller{
public ActionResult Recibe(string uncampo, HttpPostedFileBase archivo)
{
//aqui va el codigo que deseemos para manipular el archivo
}
}
Y así de fácil se envía un archivo por medio de Ajax. Dudas o comentarios pueden hacérmelos llegar y yo les respondo en breve.
Este artículo lo hago para romper muchos dogmas que existen en el área de desarrollo de software. Primero hablare de conceptos básicos y al final daré la conclusión y mi punto de vista. También hablare de lenguaje de programación encasillando: lenguaje de programación, framework, librería, Software-Stack etc.
Siempre los desarrolladores de software creen que los lenguajes que utilizan son los mejores ya que son los que utilizan. También existe el dogma de creer que el lenguaje de programación de moda (véase Ruby en el 2012, véase Mean últimamente) es el lenguaje más potente de todos.
Siempre defenderemos el lenguaje que sabemos utilizar ya que es el que nos da de comer, pero no por ello quiere decir que es el mejor. Los lenguajes de programación son como los colores, un gusto por el verde no lo hace mejor que el azul. O algo más acercado es, los idiomas con los que nos comunicamos, no por estar escrito el Quijote en inglés es mejor que el japonés. Para entender un poco el fin de este artículo, centrémonos en esto último.
Un libro nos cuenta una historia la cual pasa de generación en generación. Esta historia puede ser traducida y no por eso pierde su simbolismo. En los lenguajes de programación se cuentan al igual historias las cuales pueden ser traducidas de un lenguaje a otro (de programación); algo hecho en java del lado del servidor puede ser traducido a node.js o a php, y el lector de la historia (front-end por ejemplo) recibirá el mismo resultado. Aquí vemos un punto clave: la solución del problema es lo que le importa al cliente. Pero también le importa el tiempo en que es escrita la historia. El tiempo en que se escribe una historia (programa) es parte de por qué nuestra elección sobre un lenguaje de programación nos hace pensar que es el mejor, pues es el que conocemos. Obviamente lo defenderemos a capa y espada. Aquí ya tenemos dos puntos clave: la historia y el tiempo en que esta es escrita, o a su vez, la solución del problema (historia plasmada en libro) y el tiempo de desarrollo (escritura de la historia).
Ahora ya que hablamos de la similitud de libros y programas, hablemos de otros puntos clave. Existen libros que son malos pero cuentan una historia que es entretenida más o menos, y existen libros que son buenos y cuentan una historia que entretiene, divierte, motiva, bueno es una obra de arte. Esto relacionado a los lenguajes de programación es lo siguiente: existen programas que son lentos, mal hechos pero resuelven el problema más o menos, y existen programas que resuelven el problema pero a su vez hace verlo como una obra de arte por su rapidez, y sobre todo la manera que parece que hace magia con el modelo de negocio del cliente. Es aquí el punto más importante: no importa en qué lenguaje de programación hagas las cosas, lo que importa es que hagas bien las cosas.
Otro punto clave es la antigüedad, la mayoría de las veces un lenguaje viejo es un lenguaje obsoleto (yo no veo a nadie escribiendo libros en griego o en hebreo). Pero no siempre es el caso, es mejor decir que un lenguaje es obsoleto cuando no evoluciona (nunca se implementó lambda, no tiene orms, no tiene plugins que hacen el desarrollo más rápido, etc).
Para concluir yo aconsejo que se debe conocer un lenguaje de programación con el cual estés cómodo, y después te hagas experto, más tarde en 1 o 2 años, ve conociendo más lenguajes, esto te ayuda a comparar la forma en que otros lenguajes resuelven lo que tú ya has resuelto, esto lograra que tu abstracción crezca y te ayudara a pensar de manera más ágil. Lo que más importa no es el lenguaje de programación sino la abstracción y creatividad que tengas para resolver las cosas.
Ningún lenguaje de programación es el mejor, sino el cómo tú piensas y resuelves el problema, eso es lo que en realidad importa.