E E E E Enterprise!
- Estas parseando metadatos de imagenes en tu super enterprise entorno java
- le tiras un XPath al Nodo de los metadatos que te devuelve la API y no te devuelve nada
- pensas "debe estar mal la query XPath"
- lo probas en un debugger de XPath y anda
- le das mil vueltas y sigue sin andar
- probas con DOM a mano (que es una API horrenda) y anda
- pero te negas a hacerlo en DOM pelado
- seguis probando
- "no puede ser que la API esta mal" pensas
- ya te rendis y le preguntas a google
- "This class is not intended to be used for general XML processing. In particular, Element nodes created within the Image I/O API are not compatible with those created by Sun's standard implementation of the org.w3.dom API. In particular, the implementation is tuned for simple uses and may not perform well for intensive processing."
- Intensive processing? no responde a los queries XPath, eso no es intensive, eso es mal implementado!
- lo siguiente lo dijo mejor este vago que lo que podria escribir yo asi que lo cito
possible in a org.w3.dom.Node, but that does not mean it should
actually be wrong. Since javax.imageio.metadata.IIOMetadata.
getAsTree() returns an org.w3.dom.Node, I believe that compliance
with the contract for org.w3.dom.Node is required.
In the case of the JPEG 2000 metadata accessed using this method,
I have observed Nodes of type Element with Values set, which is
illegal.
If Element nodes are not going to have Text children in your model,
then they should have Attribute children with the Attribute name
being "value", and I don't think the JPEG 2000 metadata is doing
that (unlike the standard metadata which does use Attributes).
Also, it is all very well to say that the IIOMetadataNode is not
a "real" Node, but the point of choosing this methodology was so
as to allow the use of "ordinary" style DOM accessors, at least
that is how I remember the decision in the JSR 015 Expert Group
discussions. It is presumably the point of the existence of the
getAsTree() method.
To that end, if an ordinary Transformer cannot render the structure
returned by getAsTree() as XML without losing information, and if
XPath cannot query it, then I would argue that the implementation
of getAsTree() is broken, not just limited.
The "ability to store an Object reference within a node" is all
very well in special circumstances, but should NOT in my opinion,
be abused just to point to a scalar type, for example. This begs
the question of what the behavior is supposed to be, or defined
to be, for javax.imageio.metadata.IIOMetadata.getAsTree() in
such circumstances. Not that I have looked into the detail of
how this is implemented, just wondering theoretically how such
an Object reference would be correctly used and under what use
cases it is required."
http://forums.java.net/jive/thread.jspa?messageID=255691
y el problema es que esto ya me paso antes, en la api del widget para mostrar Rich Text en swing no hay forma en la api para obtener el offset del cursor contando el HTML que esta por detras, solo te da el offset del texto que esta en pantalla, por lo tanto hay muchas acciones que se re complican, buscando en los foros por esa epoca habia respuestas como "si, sabemos que esta mal pero no lo vamos a arreglar por X o por Y".
muy enterprise..
Edit 1:
- por que no puedo iterar sobre un NodeList en ese pseudo foreach que tienen? es un iterable despues de todo no?
- porque Vector no tiene una api para hacer slicing?
- porque Vector, LinkedList y ArrayList son implementaciones de List? no podrian esconder los detalles de implementacion al usuario y hacerles pensar que estan eligiendo mal cada vez que eligen uno por sobre el otro?
- Porque Vector es thread safe y LinkedList y ArrayList no?
- La version limitada de Node que me devuelve la metadata de la imagen no me deja hacer getElementByTagName, asi que no puedo hacer mas que iterar por todos los childs buscando el que me hace falta ya que por suerte en la implementacion se mueve de posicion.
- size() length() getLength() getSize(), no se ponen de acuerdo en eso no?