2008-08-27 7 views
6

Me enredé en una discusión acerca de las peculiaridades de implementación de DOM ayer, lo que dio lugar a una pregunta interesante sobre los comportamientos Text.splitText y Element.normal y cómo deberían comportarse.¿Debe DOM splitText y normalizar componer para dar la identidad?

En DOM Level 1 Core, Text.splitText se define como ...

rompe este nodo Text en dos nodos de texto en el desplazamiento especificado, manteniendo tanto en el árbol como hermanos. Este nodo solo contiene todo el contenido hasta el punto de compensación. Y un nuevo nodo de Texto, que se inserta como el próximo hermano de este nodo, contiene todo el contenido en y después del punto de desplazamiento.

Normalizar es ...

pone todos los nodos de texto en toda la profundidad de la sub-árbol debajo de este elemento en una forma "normal" en el que sólo marcado (por ejemplo, etiquetas, comentarios, procesamiento instrucciones, secciones CDATA y referencias de entidad) separa los nodos de texto, es decir, no hay nodos de texto adyacentes. Esto se puede utilizar para garantizar que la vista DOM de un documento sea la misma que si se hubiera guardado y vuelto a cargar, y es útil cuando se van a utilizar operaciones (como búsquedas XPointer) que dependen de una estructura de árbol de documentos en particular.

Por lo tanto, si tomo un nodo de texto que contiene "Hola Mundo", se hace referencia en textNode, y hago

textNode.splitText(3) 

textNode ahora tiene el contenido "Hola", y un nuevo hermano que contiene "Mundial"

si yo

textNode.parent.normalize() 

lo que es textNode? La especificación no deja en claro que textNode tiene que seguir siendo hijo de su anterior padre, recién actualizado para contener todos los nodos de texto adyacentes (que luego se eliminan). Parece ser un comportamiento de conformidad eliminar todos los nodos de texto adyacentes y luego volver a crear un nuevo nodo con la concatenación de los valores, dejando que TextNode señale algo que ya no forma parte del árbol. O bien, podemos actualizar textNode de la misma manera que en splitText, por lo que conserva su posición de árbol y obtiene un nuevo valor.

La elección del comportamiento es realmente bastante diferente, y no puedo encontrar una aclaración sobre cuál es la correcta, o si esto es simplemente un descuido en la especificación (no parece ser aclarado en los niveles 2 o 3) ¿Puede algún gurú DOM/XML por ahí arrojar algo de luz?

Respuesta

3

Estaba en el Grupo de trabajo DOM en los primeros días; Estoy seguro de que destinados para textNode que contiene el nuevo valor sumado, pero si no lo hicimos decir que en la especificación, es posible que algunos aplicación podría crear un nuevo nodo en lugar de reutilizar textNode, aunque eso requeriría más trabajo para los implementadores.

En caso de duda, programe a la defensiva.

1

Si bien parece una suposición razonable, estoy de acuerdo en que no está explicitamente aclarada en la especificación. Todo lo que puedo agregar es que la forma en que lo leo, uno de textNode o su nuevo hermano (es decir, el valor de retorno desde splitText) contendría el nuevo valor unido - la instrucción especifica que todos los nodos en el subárbol se colocan forma normal, no es que el subárbol esté normalizado para una nueva estructura. Supongo que lo único seguro es mantener una referencia al padre antes de normalizar.

1

Creo que todas las apuestas están apagadas aquí; Ciertamente no dependería de ningún comportamiento dado. Lo único seguro es recuperar el nodo de su padre.

Cuestiones relacionadas