Dado que el orden no tiene mayor importancia, seguiremos orden alfabético para analizar los otros wikis.
Bitweaver
A pesar de haber buscado con ahínco, no he conseguido encontrar un solo diagrama que me permita acercarme al diseño de este wiki. Lo más aproximado es la documentación realizada con
Doxygen, en la que se pueden ver pequeños fragmentos de diagrama indicando las relaciones de herencia de cada clase (es decir, para cada clase puede verse su padre, como se ve en la siguiente figura).
También se puede obtener un diagrama completo de herencia haciendo click en la clase
BitBase que es a Bitweaver lo que
Object es a Java, pero, además de no ser muy práctico ni manejable por su formato, no aporta toda la información relevante, sino sólo las relaciones de herencia.
Por otro lado, como indiqué en otra entrada, parte del wiki está escrito siguiendo el paradigma estructurado, por lo que esta ausencia de diagramas de clases resulta bastante lógica (sobre todo teniendo en cuenta que algunas de las partes que están así desarrolladas son de gran importancia, como lo relacionado con los ficheros de la carpeta
users).
En resumen, para poder averiguar algo acerca del diseño de este wiki haría falta estudiar el código fuente, bien "a mano", bien con una herramienta que lo realice de manera automática, y saber algo de dicho diseño es imprescindible para poder estudiar y entender cómo resolvieron los autores los problemas más frecuentes de desarrollo de wikis para su caso particular.
Daisy Wiki
Como ya se comentó en entradas anteriores, el aspecto más original de este wiki es el modo en que accede a la información del repositorio, a través de servicios web. Por eso, si quisiéramos emular algo similar en el caso de
JSPWiki, sería necesario cambiar por completo el modelo, así como sus comunicaciones con la vista y el controlador.
Otro aspecto interesante de este wiki es que puede albergar diferentes versiones de un mismo documento. De este modo, sin necesidad de crear un nuevo documento, podría haber diferentes puntos de vista sobre el mismo, o el propio artículo podría estar editado en varios idiomas,... Todo este tema está actualmente en boga debido al próximo lanzamiento de Google: Knol, una especie de wiki para competir con Wikipedia y una de cuyas ventajas más valoradas es ésta. Todo esto, probablemente haga que muchos de los wikis que son objeto de este estudio modifiquen su funcionamiento para incorporar esta característica. Volviendo a lo que nos ocupa, integrar este aspecto con
JSPWiki puede ser algo muy trabajoso, ya que los cambios a realizar afectarían a partes de todas las capas.
Para finalizar, pese a haber buscado durante varias horas en distintos servidores, el diagrama más interesante que encontré fue el siguiente que, realmente, no es que aporte mucho, puesto que representa sólo una pequeña parte de la arquitectura.
Por último, añadir que sería posible obtener un sucedáneo de diseño mediante herramientas, pero que no creo que sea la mejor opción para tener que trabajar sobre el diseño.
XWiki
Como se vio en entradas anteriores, se trata de un wiki muy interesante. Además, el servidor de documentación ya ha sido actualizado y contiene abundante documentación para desarrolladores, aunque, en la mayor parte de los casos, resulta bastante mejorable, como veremos más tarde.
Empecemos con un vistazo general a la arquitectura:
En este diagrama de la arquitectura a nivel global se pueden observar las distintas partes que componen el wiki: el motor del wiki (XWikiEngine), el almacén de información (Store), los documentos que se componen a partir de dicha información (XWikiDocument), el API que accede a los documentos (XWikiAPI, en el grupo Rendering), los aspectos visuales (Rendering) y todo lo relacionado con usuarios y su autenticación (Authentication & User Rights). También se pueden ver las relaciones entre estas partes, como por ejemplo los documentos que acceden al almacén para obtener la información y a su vez son accedidos por el motor y la API, pudiendo ser modificados sólo por el primero,... Para más detalles, obsérvese el diagrama.
Vayamos ahora más al detalle. Los desarrolladores de
XWiki nos ofrecen diagramas de clases de varios de los módulos. Veamos algunos.
Empecemos por la API. A continuación podemos ver el diagrama de clases:
Lo primero que llama la atención de este diagrama es la clase API, situada en el centro y de la cual heredan directamente las clases más importantes como XWiki, Document, User, Context y Element. Por otro lado se observa también la importancia de la clase Collection, de la cual heredan varias como Class, PropertyClass y object.
Continuemos ahora con el módulo XML-RPC, que se ocupa de las llamadas a procedimientos remotos:
En este caso, existen relaciones con clases de paquetes externos, que vienen en color azul y el diagrama no está tan centralizado como el anterior sino que es más complejo, por lo que remito al diagrama para más detalles.
El diagrama del módulo de documentos no resulta especialmente interesante (a alto nivel) pues apenas se indica relación alguna sirviendo principalmente para ver los métodos y propiedades de las clases XWikiDocument, XWikiAttachment, ... Por resultar poco útil en este momento lo omito.
Seguiremos con el módulo Store, que sirve para el almacenamiento de información como su propio nombre indica:
En este caso, se trata de unas interfaces situadas en el centro del diagrama, una de almacenamiento y otra de caché, que son implementadas por el almacén por defecto (XWikiDefaultStore) y por XWikiCache respectivamente. A su vez, las clases XWikiRCSFileStore y XWikiHibernateStore heredan de la citada XWikiDefaultStore.
También nos proveen los desarrolladores de XWiki de un diagrama de clases del módulo Rendering y User and Rights que, según indican no están actualizados por lo que, por ahora, serán obviados, aunque pueden ser consultados en cualquier momento.
Pasemos al diagrama del módulo objetos:
Este diagrama me parece bastante claro: de la interfaz ElementInterface derivan PropertyInterface y ObjectInterface, que son implementadas por BaseProperty y BaseObject respectivamente. Por otro lado, del resto del diagrama parece desprenderse que se serializarán objetos de clases propiedad y objeto (es un tanto extraño, pero viendo el diagrama se entiende bien).
Sigamos con el módulo de clases:
Lo primero que destaca de este diagrama es el hecho de incluir 2 interfaces y una clase del anterior módulo: ObjectInterface, PropertyInterface y BaseCollection respectivamente. A partir de ellas y de otras del propio paquete, surgen las distintas clases que se podrán almacenar luego en la base de datos.
Y para terminar, el módulo de MetaClasses:
De nuevo podemos hablar de una interfaz y una clase externas al paquete a partir de las cuales y otras más propias del paquete, se derivan/implementan los distintos tipos de metaclases que contempla XWiki.
Conclusiones
Teniendo en cuenta lo anterior, podemos concluir que los únicos wikis que están documentados suficientemente como para poder extraer algo de información sin necesidad de recurrir al código fuente son XWiki y JSPWiki.
Por otro lado, cabe destacar también las ideas extraídas de DaisyWiki de separar el repositorio y hacer accesible a través de servicios web de tal manera que incluso el propio wiki acceda a la información de esta manera y, además, que puedan existir diversas versiones de cada artículo y no un sólo punto de vista o un solo lenguaje.
Para finalizar, decir que a partir de ahora es necesario replantearse el diseño del wiki elegido (utilizando patrones de diseño) para poder continuar.
¡Hasta la próxima entrada!
