2010-09-29 13 views
8

¿Hay razones generales para no tratar con el prototipo de Document's y Element?Motivos generales para no tratar el prototipo de Document y Element

Me gusta crear mi propio marco pequeño, porque mi proyecto actual no necesita la gran cantidad de características de los marcos existentes.

No necesito admitir navegadores que no sean compatibles con Element/Document-constructor y tampoco ejecute scripts que no estén bajo mi control.

¿Recomendaría extender el prototipo o debería hacerlo de la manera habitual y crear mis propios objetos a partir de Elemento/Documento?

+1

Realmente no está claro lo que está preguntando aquí. – Robusto

+0

Hablo de Element.prototype y Document.prototype (HTMLDocument.prototype). ¿Cuál es la razón para no usarlos, si hay alguno? –

Respuesta

8

¿Planeas extender los elementos DOM por defecto? Si es así, por favor no. Juriy Zaytsev (también conocido como Kangax) claramente describe por qué no en What’s wrong with extending the DOM.

+1

Exactamente, eso es lo que he planeado. –

+0

Puedo pensar en algunos casos muy especiales, cuando no quieres hacer esto. por ejemplo, depurando algunos escenarios de prueba de concepto, lo que nunca entrará en producción. Entonces encuentro que esta respuesta no es útil. – kisp

6

Sí, lamentablemente. Sería agradable poder agregar funcionalidad manipulando los prototipos DOM, pero en la práctica no es confiable dada la tecnología actual.

Document, Element y otros etc. pueden ser 'objetos de host' implementados por el navegador sin capacidad de juguetear con sus prototipos. Los objetos host pueden tener potencialmente muchos otros comportamientos extraños que un objeto JavaScript nativo no tendría. Los nodos DOM son objetos host en IE6-7 y muchos navegadores antiguos, de nicho y móviles.

Incluso si se implementan como objetos JavaScript nativos, no existe un estándar (todavía) que describa dónde se encuentra la función constructora para ellos, para que pueda ir a buscar en el .prototype. Document, Element y así sucesivamente son solo nombres de interfaz W3 DOM, no dicen nada sobre los objetos de implementación que se encuentran.

Ocurre que los navegadores modernos (modo nativo IE8 y versiones recientes de Firefox, Opera y WebKit) hacen que las funciones de constructor estén disponibles para que pueda comenzar a agregar métodos a Document o HTMLElement. Pero incluso entonces, existen diferencias entre los objetos que están expuestos, ya que no todos los navegadores proporcionan las interfaces DOM con implementaciones bajo los mismos nombres. (Las subinterfaces/implementaciones de NodeList son particularmente problemáticas.)

Puede ver cómo el prototipado DOM ha funcionado en la práctica al observar el marco Prototype.js. Cuando funciona, es súper suave. Pero debido a que no puedes prototipar en todas partes, terminas con cosas extremadamente feas donde el framework tiene que lidiar con lugares donde el prototipado no funcionará copiando métodos en cada instancia de un nodo. Y luego tienes la situación en la que tu código podría olvidar que necesita forzar este 'aumento' y así podría funcionar o no, dependiendo de si alguna otra función sucedió para aumentar el mismo nodo antes. Esto lleva a un dolor de depuración realmente horrible específico del navegador, específico de orden de interacción, propenso a condiciones de carrera.

Si puede limitar su trabajo de creación de prototipos a unas pocas interfaces bien respaldadas y renunciar a todos los navegadores menos a los más recientes, probablemente pueda salirse con la suya.

+0

DOM Los nodos siguen siendo objetos host incluso cuando los navegadores proporcionan una cadena de constructores y prototipos. –

Cuestiones relacionadas