Una cuesti\u00f3n que normalmente\u00a0 surge en las nuevas instalaciones (o migraciones ) de DSpace es \u00bfqu\u00e9 interface usar?.<\/p>\n
Anteriormente a Dspace 1.5, la interface \u00fanica\u00a0 de JSPUI simplificaba la elecci\u00f3n :), y este es el motivo de la amplia difusi\u00f3n de los interfaces JSPUI, pero con la aparici\u00f3n de XMLUI es una pregunta recurrente. Intentaremos proporcionar alguna luz, o\u00a0quiz\u00e1 simplemente alimentar el debate al respecto…\u00a0 Empecemos:<\/p>\n
XMLUI permite de forma extremadamente simple, mucho m\u00e1s que JSPUI, aplicar apariencias radicalmente diferentes a distintas colecciones, lo que resulta de especial relevancia en determinados \u00e1mbitos, pensemos en distintas tipolog\u00edas de objetos por colecci\u00f3n, o en diferenciaci\u00f3n de la imagen institucional o… motivos diversos los hay, y en ocasiones son causas suficientes para decantarse por XMLUI…<\/p>\n
Por otra parte, existe una sensaci\u00f3n general de que los nuevos desarrollos de Dspace se alejan de JSPUI, pero nos gustar\u00eda confirmarlo con hechos. Algunas de las nuevas funcionalidades presentes en Dspace 1.8 est\u00e1n soportadas \u00fanicamente en XMLUI, como el Configurable Reviewer Workflow. De hecho, seg\u00fan se encarga de recordarnos la documentaci\u00f3n del 1.8, la activaci\u00f3n de esta funci\u00f3n \u00abdeshabilita\u00bb el JSPUI. (realmente no lo deshabilita, simplemente deja de funcionar, pues se altera el esquema de la base de datos…). Y en versiones anteriores, recordamos el Authority Control en Dspace 1.6, la versi\u00f3n JSPUI nos produjo m\u00e1s quebraderos de cabeza que satisfacciones, hablando en plata. Y algunas de las caracter\u00edsticas de un \u00abtema\u00bb como Mirage, incluso considerando sus bugs pre-1.8, son inalcanzables, pensamos, para JSPUI.<\/p>\n
Pero esto tambi\u00e9n pudiese ser cierto a la inversa. Al menos hasta la aparici\u00f3n de la versi\u00f3n 1.7, la interfaz de administraci\u00f3n de XMLUI iba por detr\u00e1s de la disponible en JSPUI. Y recordemos que la funcionalidad base para usuarios generales de JSPUI sigue siendo objetivo, a mi entender, a\u00fan no alcanzado, de los temas XMLUI como el \u00abClassic\u00bb, sin efectuar desarrollos espec\u00edficos. Lo cual nos lleva al siguiente punto, modificar y desarrollar la interfaz de usuario en una u otra interfaz.<\/p>\n
Desarrollar en XMLUI es sustancialmente m\u00e1s complejo que en JSPUI, para funcionalidades \u00abest\u00e1ndar\u00bb si es que eso existe. La curva de aprendizaje de XMLUI es mucho m\u00e1s costosa y esforzada, sinceramente. La mezcla de funciones java, seguido de una cadena de transformaciones XSL, todo embutido en un framework Apache Cocoon, resulta compleja de entender. XMLUI no funciona bajo una l\u00f3gica \u00abuna plantilla-una p\u00e1gina\u00bb, sino bajo una l\u00f3gica \u00abdiversas plantillas- una p\u00e1gina\u00bb y, simult\u00e1neamente \u00abuna plantilla- diversas p\u00e1ginas\u00bb. Lo cual complica la concepci\u00f3n del sistema as\u00ed creado…<\/p>\n
Bien, existen m\u00e1s diferencias, y sobre todo m\u00e1s opiniones sobre las mismas, que las planteadas en la breves l\u00edneas anteriores<\/p>\n
\u00bfy Vds, que opinan?.<\/p>\n","protected":false},"excerpt":{"rendered":"
Una cuesti\u00f3n que normalmente\u00a0 surge en las nuevas instalaciones (o migraciones ) de DSpace es \u00bfqu\u00e9 interface usar?. Anteriormente a Dspace 1.5, la interface \u00fanica\u00a0 de JSPUI simplificaba la elecci\u00f3n :), y este es el motivo de la amplia difusi\u00f3n …<\/p>\n