2011-03-08 7 views
5

Queremos actualizar de una versión de jQuery a otra. Utilizamos varios complementos en línea y hemos escrito muchos de los nuestros. El desafío ahora viene en la forma de tratar de MIGRAR LENTAMENTE todos sus objetos con guión LENTAMENTE sin una reescritura completa. Tengo una idea sobre cómo manejar esto:¿Existe alguna manera elegante de actualizar jQuery lentamente?

PERO TENGO PREGUNTAS:

  1. es la idea más adelante, incluso una buena idea?
  2. ¿Puedo decirle (directamente) a cada objeto jQuery dónde viven las dependencias?
  3. Si esta es una mala idea ... ¿cómo lo manejas?
  4. ¿Simplemente reescribo CADA objeto que se rompe al actualizar? (Sux!)

explique el problema:
Si todo el plug-in de vivir sólo en el ámbito de una sola página, a continuación, diferentes versiones se tratan fácilmente: basta con hacer su archivo-incluye en la página nivel en lugar del nivel de la página maestra (¡duh!). Sin embargo, los objetos que viven en la página maestra o en los controles de usuario son un poco más difíciles ... ya que necesitan versiones específicas para ejecutarse correctamente.

está aquí mi idea:
La definición de un plug-in comienza con una función anónima.

(function ($){<!- code goes here -->})(jQuery); 

Todas las dependencias que he visto utilizan esto como punto de partida.

EJEMPLOS: dependencias jQuery incluyen plug-ins como: ui.widget, ui.position, ui.core, etc.

qué si lo referencia a cada versión de jQuery (y sus dependencias) usando un JavaScript objetar y pasar ESE OBJETO a los diversos plug-ins internos y en línea?

LAS REFERENCIAS objeto podría ir así:

var jQueryVersion1_3_2 = function(){<!- paste the files contents here-->}; 
var jQueryVersion1_4_4 = function(){<!- paste the files contents here-->}; 

los plug-ins:
Mis internamente y en línea plug-ins todavía podrían ser incluidos como (normal) Archivo- enlaces, pero con los siguientes cambios

Vaya desde aquí:

// Plug-in X 
(function ($){<!- its untouched code -->})(jQuery); 
// Plug-in Y 
(function ($){<!- its untouched code -->})(jQuery); 
// Plug-in Z 
(function ($){<!- its untouched code -->})(jQuery); 

... ¡el control de versiones apesta aquí!

A ESTA ...

// Plug-in X 
(function ($){<!- its untouched code -->})(jQueryVersion1_3_2); 
// Plug-in Y 
(function ($){<!- its untouched code -->})(jQueryVersion1_3_2); 
// Plug-in Z 
(function ($){<!- its untouched code -->})(jQueryVersion1_4_4); 

... ahora podemos actualizar nuestros objetos lentamente.

El único problema que veo:
El reto se convierte en las dependencias de plug-in (entre las versiones).En una prueba de actualizar los siguientes comenzó a romperse a través de diversos plug-ins, cosas como:

  • ui.widget, ui.position, ui.core, etc. (todo rompieron después de la actualización).

la única respuesta que vemos es:
Envolver jQuery y todas las diversas referencias en una sola función y ahorro que en la variable anterior. A continuación, pase ESE objeto intermediario a cada complemento AS jQuery.

Ayúdame Obi-Wan Kenobi ... ¡eres mi única esperanza!

+3

¿Cuál es la razón para eso? ¿Crees que algunos de tus complementos dejarán de funcionar después de la actualización? (Es curioso ... En mi experiencia, mudarme a una versión más nueva de jQuery siempre ha sido indolora) – Andrey

+2

¿Está utilizando tantas funciones obsoletas? Siempre puedes verificar 'http: //docs.jquery.com/Release: jQuery_1.3.2' (cambiando 1.3.2 con la versión en cuestión) y ver qué puede ser necesario cambiar. de lo contrario, cargar cada biblioteca y 'var jQuery_1_3_2 = $ .noConflict()' puede ser su mejor opción (aunque posiblemente una gran cantidad de gastos generales). –

+0

Recuerde, no queremos tener que volver a escribir cada complemento. Queremos tocar solo algunos a la vez. Tenemos muchos complementos: algunos desarrollados internamente y otros de fuentes en línea. Y sí ... los objetos están fallando una vez que se actualizaron debido a su obsolescencia, etc. Pero esa no es la pregunta. Ya sé cómo adivinar y probar dolorosamente ... Estoy buscando algo más elegante. –

Respuesta

1

Usando $ .noConflict globalmente crear todas sus versiones

<script src="jquery 1.x" /> 
<script> 
    var jQuery_1_x = $.noConflict(true); 
</script> 
... 

luego envolver todos los plugins jQuery, parte interna o tercero en los cierres como:

(function(jQuery, $) { 

    ... // code 

}(jQuery_1_x, jQuery_1_x)); 

La única cosa que puede romper con este método es un código de terceros que usa var foo fuera de cualquier función para crear objetos globales. Es necesario buscar cualquier funciones/objetos/métodos globales e izar manualmente utilizando

window.foo = ...

Afortunadamente la creación de funciones/objetos/métodos globales se considera mala forma por ese método de todos modos por lo que no debería haber demasiados de aquellos.

+0

PREGUNTA: El uso de noConflict (true) elimina todas las variables de jQuery del ámbito global ... entonces, ¿cómo te ayuda cuando quieres usar 2 variables para mantener diferentes versiones de jQuery? - Gracias –

+0

Esto es lo que noConflicto hace: ventana. $ = _ $; if (deep) window.jQuery = _jQuery; devolver jQuery; Todo lo que veo es que escribe el objeto jQuery en una variable global en la ventana (en lugar de $) ... así que me falta algo.-Gracias –

+0

@Robalot cuando una versión de jQuery lo carga almacena en caché las variables en '$' y 'jQuery' actualmente en' _S' y '_jQuery'. La primera carga de jQuery almacenará en caché 'undefined'. Lo que hace esto es configurar los valores 'indefinidos' y devolver una referencia a '$'. Por lo tanto, elimina jQuery del alcance global y devuelve jQuery. – Raynos

Cuestiones relacionadas