javascript - body - OO JQuery y clases
body class wordpress (8)
Acabo de terminar una primera versión de mi mini proyecto: https://github.com/op1ekun/plOOgins . Se trata de escribir código OOP para ser utilizado como complementos de Jquery. No es ciencia espacial solo una pequeña cosa que queríamos usar en mi lugar de trabajo. Tal vez te ayude un poco. ¡Buena suerte!
Estoy trabajando en un sitio y usando JQuery esencialmente por primera vez. En su mayoría he usado MooTools para proyectos anteriores, y tengo algunas clases de widgets que he escrito usando la estructura de clases de MooTools . Me gustaría trasladarlos a JQuery, pero me parece que no hay nada similar a la funcionalidad de MooTools cuando se trata de clases de objetos.
He buscado un poco alrededor, y no he encontrado mucho en él. Digg parece haber rodado por su cuenta , pero no estoy seguro de si esto es algo que debería estar usando. ¿Hay una mejor manera? ¿Cómo se orienta a los objetos la gente normalmente obtiene con JQuery? ¿Cuál es el método habitual para encapsular un widget de UI (o cualquier estructura de clase funcional)?
Publicaré un ejemplo falso de una posible clase de widget de MooTools:
var ZombatWidget = new Class({
Extends: BaseWidget,
widgetPropertyX = ''prop1'',
widgetPropertyY = ''prop2'',
attach = function(el) {
var f = function() {
//do something widgety
};
el.addEvent(''dblclick'',f);
el.addClass(''widgetized'');
}
});
var z = new ZombatWidget();
z.attach($(''widgetDiv''));
Lo que tengo es mucho más grande que eso, pero entiendes la idea. ¿Necesito convertir esto al método prototype de estructuración de clase / herencia? ¿Cómo escribirías este tipo de clase de objeto usando JQuery?
Escribí un artículo hace algún tiempo sobre los complementos orientados a objetos de jQuery, espero que sea útil
Existen implementaciones de clase javascript de terceros que proporcionan capacidades de introspección muy potentes. Me gustaría destacar especialmente JS.Class y Joose . Mientras que JS.Class sigue el modelo de Ruby, Joose sigue el modelo de Moose. No soy un usuario de mootools, así que no puedo comentar sobre sus ventajas / desventajas con respecto a los mootools. Pero resumiría sus características clave.
JS.Class tiene un fuerte enfoque en simular las características orientadas a objetos de Ruby y hace un buen trabajo en eso. Proporciona una biblioteca potente modelada después de la biblioteca estándar de Ruby y también viene con un marco de prueba y administración de paquetes bien integrado.
Joose, aunque no proporciona instalaciones de gestión de paquetes / marco de prueba, sobresale en términos de instalaciones avanzadas de gestión de atributos, filtros y mejores instalaciones de introspección.
Ambos tienen muy buena documentación y se pueden usar tanto en el navegador como en el servidor.
Hm ... interesante. Tenemos jQuery, que es una gran herramienta para interactuar con el DOM. Es una herramienta de selección donde puede escribir su propio código (complementos) para modificar los elementos seleccionados. Puede interactuar aquí con su propio código (orientado a objetos) en un complemento para hacer algo realmente genial.
Entonces, ¿por qué necesitaría capacidades OO adicionales en jQuery a menos que quiera poder heredar de otros complementos de jQuery?
Porque es posible que tenga un complemento que le permita hacer lo siguiente:
$(".spiffyness").yourSpiffyficationPlugin1();
Y, aunque ya estás haciendo algo realmente genial, necesitas más elegancia además de esto.
Por lo tanto, desea heredar de su primer complemento, lo que resulta en:
$(".spiffyness").yourSpiffyficationPlugin2(); //plugin inherited from 1
Pero ... ¿no llegarías también haciendo esto?
$(".spiffyness").yourSpiffyficationPlugin1().yourSpiffyficationPlugin2();
¿Donde el segundo plugin hace esta pequeña cosa (pero impresionante;) extra encima del primero?
En otras palabras: ¿vale la pena el esfuerzo por el purismo de OO? ¿O es el mecanismo de tubería jQuery lo suficientemente bueno y tal vez todo lo que necesita?
Yo diría que la separación de responsabilidades y / o su mentalidad mootools podría ser el verdadero problema aquí. Deje que jQuery haga lo que es bueno, use su potente mecanismo de tuberías, canalice sus propios complementos (que pueden contener toneladas de cosas de lujo OO) ... y puede obtener excelentes resultados mientras su código aún está limpio.
Si crees que estoy pensando demasiado simple aquí, ¡un buen ejemplo de la esencia de tu punto sería bienvenido! :-)
Y para adelantarse a eso, si está haciendo algo realmente avanzado y no se sale con la suya simplemente haciendo algo por encima de otra cosa, su complemento también podría delegar en una de sus clases de OO. Por ejemplo, como
$.fn.totalAwesomeness = function(options) {
var defaults = {
mode: 1,
title: ''Awesome''
};
var opts = $.extend(defaults, options);
return this.each(function() {
var $this = $(this);
var handler = null;
if(defaults.mode == 1)
handler = new com.myStuff.class1($this);
else if(defaults.mode == 2)
handler = new com.myStuff.class2($this); //class2 inherits from class1
handler.doMagic();
});
};
La pregunta es ... ¿Por qué te alejas de MooTools si se ajusta a tus necesidades? Me parece que MooTools estaba funcionando bien, y no hay nada que jQuery haga que MooTools no pueda hacer. (Lo contrario no es cierto).
Desafortunadamente, jQuery no está diseñado para soportar el OOP clásico, ya que MooTools es así que tendrá que escribir sus clases como complementos de jQuery.
Los complementos a veces hacen el truco.
Por supuesto, podría usar la cantidad suficiente de mootools para obtener su modelo de clase / herencia. Con la implementación del "modo de compatibilidad" document.id en 1.2.3 puede tener su pastel y comérselo también (creo que no lo he hecho yo mismo).
Puede encontrar este enfoque útil para la tarea en cuestión: crear un complemento de jQuery orientado a objetos.
Y este artículo sobre Ajaxian " un verdadero sistema de clases OO con jQuery ".
Siempre puedes usar moo4q - http://moo4q.com/ . Agrega soporte de clase MooTools a jQuery.