Web

Buscar por tag, clase e id en jquery

Hace tiempo escribí un artículo hablando de rendimiento de jQuery y el uso de selectores dobles con jQuery, pero lo que no he hecho es explicar como funciona un selector de jQuery. La idea es que esto no sea «la guía definitiva de jQuery», ni nada por el estilo, sino un breve apunte para los lectores, la visión mas básica del uso de jQuery.

En este artículo voy a exponer como seleccionar de forma mas que simple utilizando un tag (etiqueta de html), una clase de css y un id. jQuery es un ente muy inteligente y por tanto, sabrá si lo que le estamos pidiendo es que convierta una etiqueta a jQuery o que la busque.

  • Buscar por tag con jQuery: este junto con el de clase, son métodos de búsqueda de poco rendimiento y que pueden dar como resultado varios objetos (ya que un tag se puede repetir), se indicaría a jQuery el nombre del tag.
  • Buscar por clase con jQuery: al igual que el anterior, es de bajo rendimiento y dará como resultado un array de objetos, ya que una clase se puede repetir.
  • Buscar por id con jQuery: es el mas optimo y el que se ha de usar siempre que sea posible. Devolverá un único objeto ya que los id’s en teoría no se repiten.

Ahora vista un poco la teoría viene la practica. Lo primero es entender como se hace la llamada a jQuery, que tiene 2 formas, la original que es usando la función jQuery o la corta que es usando su alias a la función $. Veamos un ejemplo genérico de esto y luego uno por cada selector.

var selectorjQuery = jQuery("#mi_id_a_seleccionar");
var selectorAlias = $("#mi_id_a_seleccionar");

En el ejemplo anterior, el resultado sería el mismo, ya que es similar utilizar la función jQuery que la función $. Ahora veamos un ejemplo con los selectores, con un código en html y otro de código javascript.

<p>
   <a href="#">Mi link 1</a>
   <a href="#" class="enlace">Mi link 2</a>
   <a href="#" class="enlace" id="myLink">Mi link 3</a>
</p>

Ahora vamos a hacer lo siguiente, con estos enlaces, vamos a poner el color del enlace en negro para todos los enlaces, rojo para los enlaces que tienen una clase enlace y azul para el id myLink

//ponemos todos los enlaces a negro
$("a").css("color", "#000");
//los enlaces con la clase .enlace los dejamos en rojo
$(".enlace").css("color", "#ff0000");
//el enlace con el id myLink lo ponemos azulado
$("#myLink").css("color", "#336699");

Como podemos observar, las etiquetas se indican con su nombre, las clases como si de css se tratase, con un punto delante, al igual que los ids, que al igual que css utilizan una almohadilla.

Por que no usar django. Breve comparativa entre django, ruby y Mono ASP.Net con MVC

Hace un tiempo empecé a oír hablar de django y empecé a interesarme por el. La verdad que al principio me llamaba mucho la atención porque la gente no hacia mas que alabar las virtudes de django. Investigando encontraba mas y mas alabanzas, incluso expertos que comparaban django con otros entornos como Mono ASP.Net con MVC o ruby.

A veces las comparaciones son odiosas y esto es que lo les pasa a los demás entornos cuando los comparamos con django. Al comparar django con Mono ASP.Net con MVC, comentaban como un mismo proyecto realizado por programadores expertos en django, realizaban muchas mas tareas que los expertos en ASP.Net en el mismo tiempo y que el resultado final del proyecto es que era mas rápido y consistente el desarrollo en django que en ASP.Net. Yo no digo que django sea un mal entorno, ni que los programadores de ASP.Net sean malos, pero la calidad de un programador de .Net realizando una web deja un poco que desear en la mayoría de los casos, no asi un programador friki de python que ha decidido hacer webs y que seguramente sea mucho mas versátil que uno de asp.net aunque hiciera la web en php y para mi esto no es comparable. Por otro lado comparaban django con ruby y no me gusto nada la comparación, ya que al comparar, decían que ruby on rails era para “nenas” y django para “hombre de pelo en pecho”. La verdad que esta comparación, es un poco ridícula, hasta llego a hacerme gracia a pesar de no gustarme.

Ahora vayamos a mi experiencia personal. Decidí instalarme django, ruby y Mono ASP.Net con MVC. Al buscar información, tutoriales o algo de guía para instalar e iniciar django, me encuentro con poca información y además centrada para linux, seguía las guías para mac y me costo sudor y lágrimas hacerlo correr (mi amigo @saikus no fue capaz). Cuando ya conseguí, intente hacer una prueba pero fui incapaz, bastante complicado para empezar sin un libro o sin que alguien te enseñe. Aun así, vi que utiliza una especie de servidor propio, por lo que para por ejemplo hacerlo correr en apache, hay que arrancarlo desde ssh y enlazarlo por un fastcgi o similar con apache, pero la cuestión es, cuanta comunidad puede generar algo que es muy muy muy dificil que sin ser pro y sin gastar un dineral en hosting, puedan hacer pruebas (yo en mi hosting no puedo instalarlo de momento).

Por ejemplo, mi experiencia con ruby o asp.net es muy mas satisfactoria, puesto que ruby es tan fácil como instalarlo desde algún apt-get, ports, descargable, etc y luego instalar las mil y una gemas necesarias. De una forma rápida y fácil puedes hacer funcionar un ejemplo o programar algo no solo en linux, sino en MacOSX, que es importante, ya que cada vez hay mas gente que usa este sistema. Por otro lado Mono ASP.Net con MVC es también muy fácil, quizás algo mas complejo que ruby, pero tan fácil como bajarse el instalable o en el peor de los casos las fuentes de la web de mono y compilar. Mono ya tiene XSP que es su propio server como ocurre con django y rails, y con mod_mono lo compilamos e instalamos en un periquete en apache.

Por que me gusta mas usar Mono ASP.Net con MVC que usar ruby o django. Django lo descarto por el costo de su instalación, porque no tengo un buen IDE donde poder programarlo y si quisiera pagar aunque fuera poco por los IDES, ¿Por qué no volverme a Windows y usar Visual Studio? Ruby es un poco parecido, es mas fácil de instalar y trabajar, pero falta un buen IDE, Netbeans tiene soporte, al igual que Eclipse para django, pero son plugins para mi gusto no estan muy muy depurados. Por el lado de Mono ASP.Net con MVC tenemos la opción de monodevelop, que si bien es cierto que sus primeras versiones eran como los plugins antes mencionados, las ultimas han mejorado sustancialmente y no hay que olvidar que en lugar de ser un IDE de java con plugins para python o ruby, es un IDE de .Net (dotnet), por lo que mvc esta soportado nativamente.

En conclusión, a django le veo demasiadas pegas que ensombrecen las virtudes que tiene. Ruby es quizás el mas equilibrado en cuanto a potencia y tiempo de desarrollo y Mono ASP.Net con MVC es mas lento en cuanto a desarrollo pero muy potente, además de no ser un framework añadido a un lenguaje (mvc si, pero no asp) sino todo un entorno preparado para la web, donde con un par de clicks es muy fácil generar clientes de servicios web, o crear un servicio web xml, una pagina web o mil cosas mas. Es por esto que yo personalmente me quedo con Mono ASP.Net con MVC.

Scroll al inicio