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.

Reunión y Nueva Tarea (Grades)

El pasado lunes, en la reunión con Marc(Ludo) y Pigui, me explicaron cual sería la última tarea a implementar, grades para páginas wiki en Moodle 1.9. Hoy, empezaré a documentarme y buscar información del funcionamiento de los grades.

La tarea de los grades constará de cuatro etapas (by Ludo):

1. Documentación: Escribir un informe de los objetivos a cumplir, explicando la semántica del funcionamiento.
2. Interfaz: Bocetos iniciales de el aspecto que tendrá las páginas html.
3. Tablas: Diseño de las tablas a añadir en la base de datos. Con la ayuda del incombustible Pigui.
4. Programar: Implementar
   

Más sobre la tarea de Wikibooks...

Se han añadido los emoticones para substituir el conjunto de los caracteres que los definen.

Siguiendo con las imágenes, he acabado la tarea de añadir imágenes en el PDF. Una de las muchas limitaciones que tiene la clase TCPDF, es que el método implementado(Image) utiliza como parámetro la dirección completa de disco del archivo que se tiene que añadir, es decir, la imagen tiene que estar almacenada en el disco duro.

El método Image, abre el archivo especificado para lectura (que tiempos aquellos los de S.O.), después calcula la altura y anchura, y finalmente lo guarda en un atributo interno de la clase TCPDF (images, que es un vector de imágenes). Como cada imagen que hay en la página nwiki hay que descargarla al disco y calcular la altura y anchura, el tiempo a la hora de crear el PDF se incrementa, y más si el PDF se tiene que crear dos veces para poder calcular los enlaces internos (de lo contrario, nos sabríamos cuantas páginas ocupa cada nwiki), como este comportamiento es ineficiente, implementé dos métodos nuevos a la clase que sirven para hacer un copy & paste del vector de imágenes. Antes de descargar la imagen se comprueba si ya existe en el vector o no.

Al trabajar con archivos y ficheros hay que tener siempre en cuenta algunas particularidades dependientes del sistema de ficheros del S.O., como por ejemplo los permisos, el espacio disponible en el disco, que no existan conflictos con los ficheros existentes, etc. Los criterios que he escogido son los siguientes:

• Para cada imagen, se descarga el disco duro una sola vez, si existe cualquier error a la hora de leer la url de la imagen, crear el archivo en el disco o escribir los datos en el disco, se interrumpe la creación del pdf y se elimina del disco duro el archivo.
• Tras pasar la información de la imagen al vector de imágenes de la clase TCPDF, se elimina la imagen.
  
• Cada usuario tendrá una fichero dentro del fichero de /tmp de tcpdf. De está forma se evita que una misma imagen pueda ser sobrescrita o evitar comportamientos inesperados.
• Habilitar correctamente un fichero en el que poder escribir para poder almacenar imágenes temporalmente.

He añadido como tags soportados: <dl> (definition list), <dt>, <dd> y <div> (tabla de contenidos).

Las páginas nwiki que tengan la cadena " %%% " será sustituida por el tag <br>.

Después de trabajar con la clase TCPDF comentaré algunas impresiones. Dentro de las librerías (o bibliotecas) de Moodle para crear PDFs (que conozca), la librería de TCPDF es la más completa. La clase es bastante modular, pero no es una clase con la que se pueda trabajar únicamente sabiendo las funciones públicas disponibles, hay que tener en cuenta aspecto internos de la clase, como por ejemplo las unidades utilizadas (pixels, mm, cm, puntos, ...). La función que se utiliza como parser, para los documentos html es bastante limitada en algunos aspectos, como por ejemplo, hacer listas de listas (algo que ya comente), introducir imágenes de tamaño considerable (al menos que no definamos para cada imagen la escala que queremos), etc.

Nota: Algunas de las funciones PHP que he utilizado, solo están disponibles a partir de la versión PHP 4. Una consideración importante a tener en cuenta.

Resumen de la Semana Pasada

El martes día 4 de diciembre de 2007 se me encomendó una nueva tarea, la de pasar un wikibook a pdf.

Un wikibook, es un conjunto de paginas wiki, presentadas en formato libro (esta explicación tal vez sobraba...).

El primer día estuve analizando la estructura de las tablas de la base de datos con las que tenía que trabajar. Específicamente se trata de las siguientes tres tablas: wiki, wiki_pages y course_modules. Es importante entenderlas bien, de cara escoger las últimas versiones de las páginas wiki del wikibook que pertenece al módulo del curso o al módulo wiki.

Cuando acabé de completar las consultas en sql a la base de datos, me centré (como me dijo Pigui) en mirar las dos clases que ja dispone la librería de Moodle para crear pdfs. Estás son FPDF y TCPDF. TCPDF es una extensión de la clase FPDF, con más métodos que nos pueden facilitar en gran medida la creación de pdfs. El único problema que tenía era que las fuentes disponibles en FPDF, no son fácilmente accesibles para la clase TCPDF (yo de momento uso otras...).

Ahora mismo estoy trabajando en TCPDF y he conseguido avanzar bastante, pero existen algunas incompatibilidades de tags html con la función writeHTML de la clase. Por ejemplo, no se escriben bien las listas de listas o hay etiquetas no soportadas como "div".

Coming soon -> "La Reunión"

Trabajo de la semana (I)

Durante el transcurso de esta semana he añadido estas funcionalidades principales:

• Para instalar el plugin solo hay que descomprimir el fichero en la carpeta de /moodle/course/report/ (y modificar, de momento, una dirección url en el archivo timeline_processing.js, el archivo que inicializa el timeline)
  

• Se ha añadido la API a la cabecera de la página en HTML. Existe el parametro $return de la función print_header, que si evalúa cierto devuelve el string de la cabecera en vez de imprimirla con el comando "echo" (la función que tiene por defecto).
  

• Ahora dentro del propio fichero del plugin del timeline, se incluye la última versión de la API de Timeline.

• He añadido los saltos de linea a las burbujas del timeline (<br/>).

• Se mantiene el mismo formato de la página web para todos los usuarios. Cuando el usuario era el administrador, se añadían bloques de administración.

Ahora explicaré algunos detalles relevantes a la hora de modificar o mejorar el código, que cabe destacar:

• La inicialización del Timeline (timeline_preocessing.js) tiene que ir dentro del body, porque lo modifica. Se añade por JavaScript los eventos onLoad y onResize al body.

• En el caso de ser administrador, dependiendo de la página a la que accedamos para ver los registros, no es visible el plugin, ja que el plugin o los plugins dentro de la carpeta de /moodle/course/report/ solo son visibles si la url solicitada es parecida a /moodle/course/report.php?id=(numero de identificación del curso)

• Cada vez que se accede al index.php se registra en el log una nuevo report log. Este funcionamiento se ha cambiado para que en vez de añadir como si se tratará de un report log normal, se añada un timeline log. Es de agradecer la modularidad y libertad de añadir entradas al log de moodle con la función add_to_log(...).

Sigo trabajando en tener una versión estable (en la medida de lo posible...) para el lunes.

Formato de los Eventos y Accesibilidad

Sigo programando la ardua tarea de filtrar la información del Timeline, y llegados a este punto he pensado que estaría bien comentar el formato que he utilizado en las burbujas del Timeline, que básicamente es el reflejo de la información almacenada en el archivo XML. He intentado mantener las misma filosofía para mostrar la información como cuando se presenta los registros en formato HTML.

Para formar el título de la burbuja, utilizo el nombre del curso, si es que la acción se asocia alguno, de lo contrario nada acerca del curso (site), el nombre completo del usuario a cargo de la acción, la acción especifica y por último, la imagen para mostrar del usuario.

Dentro de la descripción está la información de la I.P. que tenía el usuario en ese instante además del nombre completo del usuario, la acción que ha realizado y por último la información del evento (nombre del curso completo, Id, etc.). Se repite el nombre completo del usuario como la acción tanto en el título como en la descripción, para poder proporcionar los mismos enlaces que se proporcionan en la versión HTML.

Para completar la disertación dejaré un pequeño ejemplo de como debe de ser el archivo XML (extraído de la página oficial):

The XML format used for Timeline goes somewhat like this:

• Everything is contained by a <data /> element
  
  • The <data /> element can have the following attributes:
    
    • wiki-url -- Base url used to gin up url's for each event; by appending the wiki-section and the event's title; often a MediaWiki wiki URL
      
    • wiki-section -- MediaWiki wiki section
      
    
    
  • Inside <data>events</data> go a number of <event>content</event> elements, the order of these is unimportant.
    
  
  
  • Each <event /> element can have the following attributes:
    
    • start -- in full date format (e.g. "May 20 1961 00:00:00 GMT-0600"")
      
    • latestStart -- for imprecise beginnings...
      
    • earliestEnd -- for imprecise ends...
      
    • end -- same date format as start
      
    • isDuration -- either "true" or "false", if false the item will be drawn as a dot with a pale bar drawn behind it
      
    • title -- text title that goes next to the bar in the timeline
      
    • description -- more text for the bubble
      
    • image -- url to an image that will be displayed in the bubble
      
    • link -- the bubble's title text will become a hyper-link to this address.
      
    • icon -- this image will appear next to the title text in the bubble.
      
    • color -- color of the bar to display in the timeline
      
    • textColor -- color of the text to display next to the bars
      
    
    
  
  
• The "content" part is what will be displayed inside the bubble that pops up when the event is clicked
  
  • Should be escaped/formated HTML.
    

A example:

<data 
  wiki-url="http://simile.mit.edu/shelf/" 
  wiki-section="Simile JFK Timeline">
    <event 
       start="Sat May 20 1961 00:00:00 GMT-0600" 
       title="'Bay of Pigs' Invasion">

    </event>
    <event 
       start="Wed May 01 1963 00:00:00 GMT-0600" 
       end="Sat Jun 01 1963 00:00:00 GMT-0600" 
       isDuration="true" 
       title="Oswald moves to New Orleans">
         Oswald moves to New Orleans, and finds employment at the William
 <!-- This is "content" -->

         B. Riley Coffee Company. <i>ref. Treachery in Dallas, p 320</i>
 <!-- This is "content" -->
    </event>
    <event>

      ...
    </event>
</data>

Change the course

Jordi, me comentó que para evitar la carga completa de la página de Informes->Registros, la página de Moodle en la que estoy trabajando, exactamente el fichero moodle/course/report/log/index.php, modificara únicamente el Timeline para agilizar el servidor y mejorar la eficiencia.

Actualmente, estoy trabajando en esta tarea, que consiste en que al cambiar los selectores no se tenga que volver a pedir el documento HTML entero al servidor, sino que solo se actualice el Timeline. Para hacerlo utilizaré filtros, es decir, modificar el Timeline desde el cliente y sin necesida de establecer conexión con el servidor. Pero el problema es que existen algunos casos donde filtrando la información mostrada no es suficiente y hay que recargar los eventos. Para ilustrar este ejemplo supondré que tengo que cambiar una fecha determinada para ver la actividad de todos los días (opción disponible). A la hora de hacer esto hay que controlar los eventos que ya existen y los que tengo que añadir, este punto requiere trabajo en el cliente (administración de eventos) y en el servidor (la petición de los eventos a añadir en el Timeline). Por eso he pensado que sería mejor volver a cargar el archivo XML entero (donde está la información necesaria para dibujar los eventos), una solución sencilla y en la que estoy trabajando actualmente.

De esta forma dependiendo del estado estableceré dos posibles acciones:

• Si falta información
  • Recargo los eventos del XML(getxml.php)
  • Filtrar dependiendo del estado anterior
  
  
• Filtro los eventos liberando el servidor más trabajo

La tarea propuesta por Jordi, empieza ha dar sus frutos después de un tiempo. He conseguido que al cambiar el curso se cambie el Timeline sin tener que recargar la página pero si pidiendo de nuevo la información de los eventos. El visitar la Wiki de Timelines fue decisivo.

... to be continued