Conclusiones

El trabajo presente ha tenido presente la idea de trabajo multiplataforma, de hecho se ha utilizado tanto la plataforma Windows como la GNU/Linux en su gestación y periodo de pruebas sin mayores problemas.

El ejemplo sigue siendo de interes si su DTD no es la misma que la nuestra, el manejo de las diferentes situaciones que se pueden dar en un fichero XML es bastante completo pues cumple todas las enunciadas al principio de este captítulo. Hemos dejado fuera las referentes a la validación del documento, si a alguien le apetece ....

Hemos dejado caer un error para que el lector tenga que echar un vistazo al código y replantearse lo visto si no ha desarrollado su propia solución. En el caso del nodo "Datos", que es vacío, la información (si la hay) debería aparecer en uno de sus nodos. La salida mostrada en la segunda captura de la Figura 17-2 no es posible con el código aquí presentado. ¿Se le ocurre una solución, amigo lector?

De cara a cerrar la aplicación para ponerla a disposición de un usuario, proponemos una serie de ampliaciones:

• Extender el uso del evento returnInField utilizado en la opción de modificar el título puesto que aligera el interfaz y mantiene la coherencia en disco con lo que hay en pantalla. A menos que el tamaño del fichero lo haga difícil, que no es el caso presente.

• El uso de un menú facilitaría el modo de trabajo del usuario que no está muy entrenado en el tema: cargar el fichero, salir de la aplicación, una buena ayuda y la opción de deshacer serían elementos imprescindibles. En este caso, la utilización del teclado para acceder a esas opciones debería tenerse en cuenta, para que el usuario experto se maneje con soltura y rapidez en una aplicación, mayormente, dirigida a la entrada de datos por teclado.

• El uso de copias de seguridad de los ficheros manipulados suele agradecerse. A la hora de escribir el fichero en disco, al menos, debería preguntarse al usuario si quiere sobreescribir el fichero y, en cualquier caso, crear copias del contenido previo antes de modificar. Junto al uso de una nomenclatura apropiada esto facilitaría una función de recuperación o marcha atrás.

• El usuario es, generalmente, bastante cómodo. Este hecho es innegable y está en su derecho, así que la asignación de la ruta a la imagen y el taño de esta se podrían flexibilizar para que no se descuiden estas informaciones.

• No se ha hecho uso de los códigos de error que se generan al ejecutar las órdenes y funciones presentadas para no extender demasiado el código. Pero piense que no todos los elementos son de obligatoria aparición, así que alguno podría llegar a fallar ...

Hay zonas de código que se pueden hacer más óptimas, pero nuestra intención es didáctic, aprovechando para mostrar el uso del mayor número posible de funciones. Así también hemos sacrificado la flexibilidad de adaptarse a la existencia o no de determinados elementos como se comentaba en la última ampliación sugerida.