Wikigrades (Archivos)

La metodología utilizada consiste en exponer la ruta completa del fichero, siempre suponiendo que nos encontramos en la carpeta de instalación de Moodle, y en función de si se han modificado funciones o métodos ja existentes, dos puntos y el nombre de la función. Del estilo de:
ruta_completa_del_archivo/archivo:función

Si la estructura de la base de datos utilizadas para las valoraciones dentro de la wiki cambia, solo tendremos que modificar las funciones afectadas por dichos cambios dentro de la librería de grades.

Archivos Creados

/mod/wiki/grades/grades.lib.php
Se han incluido, en mi opinión, las funciones principales. Entre otras las de crear las tablas de estadísticas, las listas desplegables, almacenar la valoración interna de las páginas Wiki y sus ediciones, y también otras funcionalidades intrínsecamente relacionadas el sistema de grades interno.

• get_scales_course_user($cid, $uid): devuelve las escalas creadas por un usuario, esta función se utiliza a la hora de definir la escala que utilizará la Wiki, dentro de la página web de configuración de la Wiki. Es decir, si el usuario o administrador quiere crear una Wiki con una escala determinada, anteriormente tendrá que haberla definido.


• wiki_grades_box_page(&$WS): se encarga de crear la lista desplegable con las notas disponibles en función de la escala que tenga la Wiki, para valorar páginas Wiki. También visualiza la última valoración propuesta por el usuario (si tiene la capability).


• wiki_set_grades_page(&$WS): almacena la nota valorada en una página Wiki.


• wiki_grades_box_edition(&$WS): a diferencia de "wiki_grades_box_page", crea y printa la lista desplegable para sucesivas ediciones de una página Wiki.


• wiki_set_grades_edition(&$WS): almacena la nota valorada entre un conjunto de sucesivas ediciones de una página wiki.


• wiki_grade_evaluation_exist($pagename, $wikiid, $groupid, $ownerid, $userid): Devuelve cierto si ya existe la valoración del usuario para una determinada página wiki, de lo contrario falso.


• wiki_grade_edition_exist($wiki_pageid, $userid): Devuelve cierto si existe una valoración de una edición de una página wiki para un usuario determinado, de lo contrario falso.


• wiki_grade_print_tables($group, $user, &$wiki, &$cmodule, &$scale, &$course): dibuja las tablas de estadísticas de las valoraciones de una página wiki en función del grupo, usuario o bien todos los participantes. A partir de las páginas wiki, se crean las tablas estadísticas de las ediciones de cada página wiki.

/mod/wiki/grades/grades.evaluation.php
Su principal función es la crear la página web que visualizaremos para ver los informes de las valoraciones. Siguiendo la filosofia de Moodle, comprueba que el usuario este logeado y tenga la capability "mainreview", de lo contrario no podemos acceder a la página de informes. Por último, en el pie de la página se puede valorar al usuario dentro de la actividad utilizando el Gradebook de Moodle.


Archivos Modificados

/mod/wiki/wiki/hist.php: wiki_hist_content y wiki_hist_actions
Se encarga de la gestión y tratamiento de las pestañas que hay dentro de la wiki.

/mod/wiki/version.php
Utilizado para indicar la versión del módulo.

/mod/wiki/db/acces.php
Contiene todas las capabilitys utilizadas dentro del módulo.

/mod/wiki/db/install.xml
Dentro de este archivo hay que incluir la definición de las tablas desde cero.

/mod/wiki/db/upgrade.php
Archivo destinado a actualizar el módulo si tener que instalar de nuevo todo.

/mod/wiki/localib.php: wiki_admin, wiki_view_content y wiki_info_content
Esta función es llamada para construir los enlaces de la pestaña de administración de la wiki.

/mod/wiki/mod_form.php
Formulario utilizado para configurar el módulo wiki.

/blocks/wiki_ead/block_wiki_ead.php
Este archivo contiene la definición del bloque de administración de las wikis.

/lang/en_utf8/wiki.php
Es el archivo con el que trabajé, pero las palabras o referencias deben estar definidas en todos los idiomas con su respectiva traducción. Es fácil identificar todos las palabras utilizadas para Grades, todas tienen el prefijo "eval_" (de evaluation).

Mejoras para Wikibook to PDF

Como he comentado en más de una ocasión, esta tarea es de por si es un Proyecto de Final de Carrera totalmente independiente. Las posibilidades y opciones para visualizar páginas wiki en PDF son muchas y podemos llegar a tener muchas situaciones inesperadas. A diferencia de los parser de páginas wiki a html, el parser del que dispone la clase TCPDF para pasar documentos html a PDF, no posee tanta flexibilidad y por consecuente tenemos que implementarla nosotros. Algunas mejoras podrían ser la siguientes:

- Mejorar el tratamiento para las Imagenes, cabe la posibilidad de que una imagen fuera muy larga y no cupiera dentro de la página. Es entonces cuando tendríamos que recortar la imagen. Pero tal vez no sería suficiente recortándola en dos partes y podría ocupar más de páginas. Son casos extremos pero podrían suceder.

- Mejorar el tratamiento de las tablas. Dependiendo del número de columnas o de filas, tendríamos un problema parecido al de las imágenes.

- Añadir enlaces internos a nivel de PDF. Añadir enlaces a las tablas de contenidos, para poder ir a los títulos que se muestran dentro con un solo click. Como segunda parte, resultaría más sencilla, una vez que nos encontraramos en una sección de la página wiki del PDF, al clickar el título se podría volver a la tabla de contenidos orginal.

- Añadir el soporte para nuevas etiquetas de HTML.

- Añadir la conversión de los estilos y colores del HTML a PDF.

- Permitir que en el título y subtítulo se puedan escribir caracteres accentuados.

- Ampliar las fuentes disponibles.

- Añadir una nueva funcionalidad para importar nuevas fuentes o utilizar los conversores que ya viene por defecto dentro de la carpeta de Moodle lib/tcpdf/fonts para crearlas.

- La clase TCPDF incorporá metodos para añadir codigos de barras. Estos se podrian utilizar si se tercia.

- Añadir códigos QR, tal vez con la dirección de internet de la página wiki, de las imagenes, del servidor, etc. (Una idea realmente interesante que tuve, pero a falta tiempo...)

Pigui implementará una nueva funcionalidad, que permitirá a partir de las fuentes disponibles dentro de la carpeta lib/tcpdf/fonts, cargar la página web de pasar de Wikibook a Pdf con dichas fuentes. Y si se añaden de nuevas, no tener que tocar el código de nuevo, sino que automáticamente se incluirán en las listas desplegables de selección de fuente.

Mejoras para el TimeLine

La primera de las tareas a completar y unas de las que estoy más orgulloso, podría incluir en un futuro alguna de estás mejoras.

- Cambiar la altura y el tamaño del TimeLine dinámicamente, es decir, sin tener que recargar de nuevo la página entera.

- Eliminar la ventana emergente del botón "count" e incluir dentro de la misma página web una pequeña sección que se actualice automáticamente. Una opción sería incluir un frame dentro de la página web, una solución sencilla en la que solo nos tendríamos que preocupar en recargar el frame cada vez que se cambie la pestaña. Otra opción sería añadir un programa en Ajax que mantuviera la comunicación del servidor, mostrando el número de eventos a cada cambio.

- Mejorar el sistema de filtraje. Esto implicaría (en mi opinión) un incremento considerable de código y tiempo, pero agilizaría el trabajo del servidor.

Reunión de refinamiento (14/01/2008)

Tras comentar el trabajo que había desarrollado durante la semana (grades y memoria), Marc refinó y puntualizó el diseño de las interfaces de las paginas web que servirían para valorar las página wiki y las ediciones.

Originalmente había pensado en valorar las páginas wiki en la pestaña ya existente para dicha funcionalidad. Y para las diferentes ediciones de una página wiki aprovechar la estructura que ofrece la pestaña "history" de las página wiki.

Ahora para valorar páginas wiki, se añade una lista desplegable con los valores de la scale (o nivel) en la dentro de la pestaña "view", es decir, cuando estamos visualizando el contenido de una página wiki, y si ya existe una nota por parte del usuario, mostrarla.

La valoración de ediciones se trasladará al contenido de las pestañas "differences" y "highlight differences". Semánticamente, dependiendo de las ediciones que se estén comparando, la valoración será almacenada para las n-1 páginas que comparemos. Es decir, si comparamos ediciones a y b (siendo a<=b) y posteriormente las valoramos con una valor de la scale, únicamente se almacenarán o actualizarán la valoraciones en el rango de páginas [a+1, b]. También se ha añadido un campo nuevo que he nombrado feedback en la tabla wiki_evaluation_edition para que el profesor (o el usuario que disponga de permisos) pueda dejar un comentario de su valoración.

Este refinamiento implicará cambiar levemente el diseño de las dos nuevas tablas (seguramente no será el último cambio añadido). Además hay que modificar otras funciones que se encargan de imprimir el html del contenido de las tres pestañas "view", "differences" y "highlight differences".

Pregunté a Pigui acerca de como incorporar al módulo wiki las capabilitys. Todas las nuevas capabilitys que se añadan deben estar almacenadas en el fichero mod/wiki/db/acces.php. Pero no estarán operativas hasta que cambiemos el numero de versión del módulo en el fichero mod/wiki/version.php.

Timeline (Archivos modificados o creados)

La metodología que utilizaré será exponer la ruta completa del fichero, siempre suponiendo que me encuentro dentro de la carpeta instalada de Moodle, y en función de si se han modificado funciones o métodos ya existentes, dos puntos y el nombre de la función. Del estilo de:
ruta_completa_del_archivo/archivo:función

Archivos creados

/course/report/log_timeline/index.php
Contiene la construcción de la página web principal. Es el archivo encargado de construir la página web además de verificar los datos del usuario. Punto de partida a la hora de trabajar, ya que es en este archivo donde se definen variables globales muy importantes para los Javascripts.

/course/report/log_timeline/getxml.php

Es el encargado de generar los sucesivos archivos XML con la información de los eventos que se le han solicitado. Además verifica los datos de usuario y los permisos al igual que el archivo index.php.

/course/report/log_timeline/count.php
Sirve para crear una sencilla página web con el número de eventos que se están visualizando en este momento.

/course/report/log_timeline/timeline_processing.js
Crea todas las funciones necesarias para poder enlazar las actividades de las listas desplegables con el Timeline. También es el archivo encargado de inicializar los atributos que tendrá del Tiemline. Es muy importante que este archivo sea llamado por la página web, después de que se haya definido la variable file_xml (contiene la información de la selección actual de todas las listas desplegables) y también después de la creación de las listas desplegables. Para unir definir eventos en los diferentes tags mediante el DOM, los objetos deben de estar inicializados de antemano.

/course/report/log_timeline/timeline.lib.php
Contiene dos funciones auxiliares y sencillas que se utilizan en el archivo getxml.php.

/course/report/log_timeline/api_timeline
Esta carpeta contiene la ultima versión de la Api de Timeline. Sin esta carpeta, se tendría que llamar a la página de SIMILE cada vez que se llamará a la página index.php.

Archivos Modificados

/course/report/log_timeline/mod.php
Moodle permite añadir fácilmente diferentes plugins para Informes, únicamente creando una carpeta nueva dentro de /course/report/ e incluyendo el archivo mod.php (definiéndolo a nuestro gusto) dentro de la nueva carpeta.

/course/repor/log_timeline/lib.php
Modificación del archivo /course/report/log/lib.php para adaptarlo a nuestros intereses.


... Actualidad ...

Sigo trabajando en la implementación de los grades. De momento estoy trabajando en la implementación de las interfaces que tendrán las páginas para evaluar tanto las páginas wiki como su ediciones.

Además hace unos días que he comenzado ha redactar la memoria. He añadido la mayoría de entradas de este blog a la memoria, pero hay algunos puntos que no están redactados y que tengo que añadir.

Wikibook a Pdf (Archivos modificados o creados)

Para mejorar la mantenimiento, creación y reusabilidad del código he pensado una nueva metodología que puede ahorrar tiempo y facilitar la comprensión de los usuarios que quieran trabajar sobre el código que he desarrollado.

Normalmente la metodología que utilizaré será exponer la ruta completa del fichero, siempre suponiendo que me encuentro dentro de la carpeta de Moodle instalada, y en función de si se han modificado funciones o métodos ja existentes, dos puntos y el nombre de la función. Del estilo de:

ruta_completa_del_archivo/archivo:función


Archivos Creados

/mod/wiki/wikibookpdf.class.php
Dicho archivos se encarga de hacer una extensión de la clase tcpdf de la biblioteca de Moodle (/lib/tcpdf) que sirve para crear archivos pdf al "vuelo". La extensión dispone de su propio parser, modificación del original, para gestionar y crear los archivos pdf a partir del html del wikibook.

/mod/wiki/wikibooktopdf.php
Se encarga de crear la interfaz y gestionar los wikibooks visibles dependiendo del usuario que acceda a dicha página. Además, dentro del archivo esta "la función" (wikibook_to_tcpdf) encargada en parsear las páginas nwiki del wikibook a html y posteriormente a pdf. La función wikibook_to_tcpdf también se encarga de la correcta implementación de los enlaces internos.

Archivos Modificados

/lang/en_utf8/wiki.php
"Almacén" de palabra en inglés que utiliza el módulo Wiki para traducir las palabras utilizadas. En este caso para traducir las palabras en inglés. He añadido bastantes palabras como por ejemplo, "Header & Footer Section", "Wikibook to Pdf", etc.

/mod/wiki/locallib.php:wiki_admin
Esta función es la encargada de crear parte de la interfaz de la pestaña de administración que tiene la wiki. He incorporado el enlace correctamente construido para pasar de wikibook a pdf, en el caso de que se tengan los permisos correspondientes.

/blocks/wiki_ead/block_wiki_ead.php
Define el bloque de administración wiki. Igual que en el anterior, he incorporado un enlace a la página que se encarga de pasar de wikibook a pdf.

Mini Reunión

Aprovechando que Ludo ha vuelto de vacaciones en Marrakech, he visitado la FIB para exponer el desarrollo del proyecto durante estas fiestas navideñas.

He explicado los inconvenientes y ventajas que tiene la funcionalidad de pasar de Wikibook a Pdf, y como se desarrollaba la última funcionalidad, con la inestimable ayudad de Pigui, valorar páginas wiki y ediciones de una misma página wiki.

La primera reunión de 2008 (04/01/2008)

El pasado viernes visité a Pigui para comentarle los problemas que había tenido, como se desarrollaba la nueva tarea y otros quehaceres.

...Wikibook to Pdf...

Comenté a Pigui el tratamiento que hacía dependiendo de los atributos groupmode y studentmode. Pigui me explicó que había cambiado el campo groupmode de la tabla de Wiki a la tabla course_modules, en Moodle 1.9, para mejorar la eficiencia y la semántica. También me explico que función podía utilizar para saber el valor de dicho campo dentro del módulo wiki, exactamente, get_coursemodule_from_instance("wiki", wikiid, courseid) que se encuentra dentro de /lib/datalib.php.

Para poder utilizar la nueva funcionalidad, pasar de wikibook a pdf, decidimos incorporarla dentro del bloque de administración wiki y además de la pestaña de administración de la wiki.

También le comenté a Pigui, un pequeño bug que no he podido solucionar. El problema es que en los títulos y subtítulos de la cabecera no se pueden incluir letras acentuadas. Desconozco el motivo, ya que dichas fuentes son las mismas que se utilizan para el cuerpo del pdf, y en el cuerpo se dibujan perfectamente.


...Grades...

Ultimamos los detalles para la creación de las tablas. Además Pigui me explico que pasos tenia que seguir a la hora de crearlas. A parte de explicarme la herramienta para la creación de los XML con el XMLDBeditor que dispone Moodle en Site (dentro del bloque de administración), me explicó también los archivos que tenía que modificar, para poder instalar o actualizar las tablas y consecuentemente el tratamiento de los backups.

En resumen:

1. /mod/wiki/db/install.xml -> Dentro de este archivo hay que incluir la definición de las tablas desde cero.

2. /mod/wiki/db/upgrade.php -> Archivo destinado a actualizar el módulo si tener que instalar de nuevo todo.

3. /mod/wiki/version.php -> El archivo se encuentra en el root de la wiki.

4. /mod/wiki/backuplib.php -> El archivo al que llama Moodle para hacer los backups de las tablas.

5. /mod/wiki/restorelib.php -> Se encarga de recuperar la información.

6. /mod/wiki/xml/exportxmllib.php -> Export e Import del contenido de las páginas wiki en xml.

El punto 1, haría referencia a la instalación. El punto 2 y 3 a la actualización (upgrade). Y los demás puntos al sistema de backup excepto el 6 que es un sistema de backup interno y propio, desarollado por el dfwikiteam.

Dos nuevas Tablas: wiki_evaluation y wiki_evaluation_edition

Aún tengo que solucionar algunos problemas técnicos que tengo con Moodle 1.9 y Nwiki, mientras, sigo trabajando en Moodle 1.8.

Mi primer idea es crear dos nuevas tablas auxiliares que sirvan para valorar páginas wiki y versiones de una misma página wiki.

Para la primera parte, evaluar páginas wiki, la llamaré wiki_evaluation, y será una tabla nueva que relacionará la tabla usuario, páginas wiki y notas (grades). Aparte de relacionar dichas tablas también servirá para almacenar un comentario y la nota (gradesid). En caso de que se modifiqué repetidas veces una nota, siempre podremos recuperar la nota inicial o las sucesivas a partir de los historiales de las tablas de grades (history tables, que básicamente tienen los mismos campos más tres extra). Todas las tablas de se utilizan para gestionar los grades posen su respectiva tabla historial y con ella se pude reconstruir las notas en cualquier punto en el tiempo.

Destacar, que para asociar una página wiki (wiki_pages) con la tabla wiki_evaluation, utilizaré en vez del identificador de la página wiki (id), los cuatro campos principales para diferenciar páginas wiki, estos son pagename (nombre de la página wiki), dfwiki (a que wiki pertenece), ownerid (el propietario de la página wiki) y groupid (grupo al que pertenece). Creo que para evitar constantemente que la relación entre las páginas wiki y las evaluaciones tengan que actualizarse siempre que se modifica una página wiki, es decir, se añade una nueva versión, es coger estos cuatro campos. Si solo utilizaremos el campo id de la tabla wiki_pages, estaríamos valorando versiones en vez de la página wiki y si buscáramos que la nota fuera a parar a la última versión disponible, tendríamos que actualizar al nuevo valor del campo id de wiki_pages.

La estructura en UML sería la siguiente (no confundir con el condensador de flujo...XD):

En sql:

CREATE TABLE mdl_wiki_evaluation
(
id BIGINT(10) unsigned NOT NULL auto_increment,
pagename VARCHAR(160) NOT NULL DEFAULT '',
wikiid* BIGINT(10) unsigned NOT NULL DEFAULT 0,
groupid BIGINT(10) unsigned NOT NULL DEFAULT 0,
ownerid BIGINT(10) unsigned NOT NULL DEFAULT 0,
userid BIGINT(10) unsigned NOT NULL DEFAULT 0,
gradeid BIGINT(10) unsigned NOT NULL,
comment MEDIUMTEXT,

PRIMARY KEY (id),
UNIQUE (pagename, wikiid, groupid, ownerid,
userid, gradeid),
FOREIGN KEY (wikiid) REFERENCES wiki(id),
FOREIGN KEY (userid) REFERENCES user(id),
FOREIGN KEY (gradeid) REFERENCES grade_grades(id)
);

* Más conocido como Dfwiki, pero para ahorrar cambios y mantenimiento en el código, he preferido nombrarlo así.


Para evaluar las versiones de las páginas wiki, habrá una nueva tabla con el nombre de wiki_evaluation_edition. A diferencia de la anterior, hay que destacar que será una clase asociativa propiamente dicha. Esto implica que el identificador esta vez si será el identificador de la página wiki, que representa la edición que vamos a evaluar. Por lo tanto la nueva tabla que añadiremos a la base de datos estará compuesta por el identificador del usuarios, de la página wiki y el del la respectiva nota. Además almacenará los caracteres +, - o = dependiendo de la valoración del usuario respecto a la versión.

La estructura en UML sería la siguiente:

En sql:

CREATE TABLE wiki_evaluation_edition
(
id BIGINT(10) unsigned NOT NULL auto_increment,
wiki_pageid BIGINT(10) unsigned NOT NULL,
userid BIGINT(10) unsigned NOT NULL DEFAULT 0,
gradeid BIGINT(10) unsigned NOT NULL,
valoration VARCHAR(10) NOT NULL DEFAULT '',

PRIMARY KEY(id),
UNIQUE (wiki_pageid, userid, gradeid) **
FOREIGN KEY (wiki_pageid) REFERENCES wiki_page(id),
FOREIGN KEY (userid) REFERENCES user(id),
FOREIGN KEY (gradeid) REFERENCES grade_grades(id)
);

** Deviation from SQL standards: A FOREIGN KEY constraint that references a non-UNIQUE key is not standard SQL. It is an InnoDB extension to standard SQL. (http://dev.mysql.com/doc/refman/5.0/en/innodb-foreign-key-constraints.html)

Aunque, nuestra idea inicial es crear una clase asociativa en Moodle, en realidad, a efectos prácticos no podremos realizar dicho concepto. Esto se debe a que las nuevas tablas de Moodle que incorporemos, deben de reunir unos requisitos mínimos. Algunos de estos requisitos son, que todas las tabla nuevas deberán de tener como clave primaria un identificador numérico autoincremental, este hecho rompe el concepto de clase asociativa, ya que una clases asociativa, su clave primaria se compone de las claves primarias de la relación de las demás clases. La solución es crear la tabla con el identificador y posteriormente crear nuestra clave única para evitar repeticiones no deseadas.