Cuaderno De Bitácora

Wikigrades (Archivos)

2008-02-22T16:03:00.011+01:00

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

2008-01-16T00:11:00.000+01:00

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

2008-01-15T23:34:00.000+01:00

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)

2008-01-15T20:00:00.000+01:00

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)

2008-01-13T15:04:00.000+01:00

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)

2008-01-08T18:23:00.000+01:00

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

2008-01-08T17:40:00.000+01:00

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)

2008-01-07T13:59:00.000+01:00

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

2008-01-02T23:59:00.001+01:00

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.

Reunión (27/12/2007)

2007-12-29T20:57:00.000+01:00

El pasado jueves, estuve comentando con Pigui, algunas tablas auxiliares que podría necesitar para la tarea de los Grades, y también las ideas que había tenido.

Una de las partes de la tarea de los Grades consiste en valorar ediciones de una misma página wiki, para poder notar al progreso del autor o del grupo, y es a esta a la que dedicamos más tiempo. Para evaluar las páginas wiki utilizaremos una nueva clase asociativa compuesta por la asociación de las clases usuario, nota (grades) y página wiki. Dicha propuesta implica que la idea inicial de valorar entre ediciones, no precisamente consecutivas, no pueda llevarse acabó (de momento...) y por lo tanto solo se valorarán únicamente páginas wiki. Este cambio en el funcionamiento, beneficiará el cálculo de las estadísticas y los informes. Si se valoraba entre diferentes ediciones de la misma página wiki, a la hora de calcular las evaluaciones tendríamos que tener en cuenta diferentes criterios como por ejemplo, si la valoración entre dos ediciones pasaría únicamente a una de las dos (preferiblemente la más tardía) o si la nota se contaba en cada sección, es decir, una valoración contaría en las dos ediciones de la misma página wiki.

Otra parte a considerar, es que a la hora de valorar las páginas wiki, podremos utilizar las Scales que nos proporciona Moodle o bien crear nuestras propias Scales.

También se tendrán que añadir tres nuevas capabilitys para diferenciar que se puede visualizar y que no. Estas tres nuevas capabilitys son gradepeer, gradeauthor y grademain. Gradepeer establece que el usuario podrá ver las valoraciones de su página wiki y el nombre de los usuarios que las han realizado. Gradeauthor, a diferencia del anterior, no permitirá ver el nombre de los usuarios que han realizado las valoraciones. Y por último, grademain, que permitirá ver todas las valoraciones de todas la páginas wiki.

Las valoraciones se añadirán a través de la pestaña evaluate y las ediciones serán en la pestaña history.

(Para más información sobre Grades, Scales, ... vea la entrada anterior :) )

... Wikibook to Pdf ...

De la tarea anterior, pasar de Wikibook a Pdf, falta acabar el tratamiento que tendrán los Wikibooks en función de los campos studentmode y groupmode de la tabla Wiki, que variarán las consultas a la base de datos en función de estas.

Gracias a las explicaciones de Pigui, esta parte estará acabada próximamente.

Documentación para desarollar con grades en Moodle 1.9

2007-12-25T18:55:00.001+01:00

He recopilado algunas páginas web, dentro de Moodle.org, que creó que me pueden servir para realizar la tarea y también pueden ser de utilidad para cualquier persona que quiera contribuir y trabajar con los grades de Moodle 1.9.

Son los siguientes:

Más información:

"See you"

Reunión y Nueva Tarea (Grades)

2007-12-20T12:37:00.000+01:00

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):

Documentación: Escribir un informe de los objetivos a cumplir, explicando la semántica del funcionamiento.
Interfaz: Bocetos iniciales de el aspecto que tendrá las páginas html.
Tablas: Diseño de las tablas a añadir en la base de datos. Con la ayuda del incombustible Pigui.
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.

Trabajo de la semana (III)

2007-12-16T11:21:00.000+01:00

Trabajando en la conversión de wikibook a pdf...

He añadido al parser de la librería TCPDF de Moodle, la funcionalidad de printar correctamente las listas de listas. Y es totalmente indiferente que sean ordenadas (<ol>), desordenas (<ul>) o combinaciones estas.

El tratamiento de links internos está acabado y ahora solo hace falta testearlo. A diferencia de los links externos, los links internos son de color verde. Para añadir esta funcionalidad, que es dependiente de las páginas nwiki, he creado estructuras internas dentro de la clase para gestionar los enlaces.

He jugado bastante con los métodos de la clase para saber que posibilidades extras ofrece.

Sigo trabajando en la interfaz, que había dejado de lado para centrarme exclusivamente en las listas y los links.

Todos esto aparte de la corrección del bug.

Un bug ...

2007-12-15T21:21:00.000+01:00

El plugin de Timelines para ver la actividad de Moodle tenía un pequeño bug.

Al crear el objeto Timeline dentro de la página web, hay que definir la información y la estructuración que tendrá, por ejemplo, dentro de cada banda (o tira) hay que especificar la unidad temporal (minutos, días, meses, años, ...), también existe un atributo dentro de cada banda que permite definir la posición inicial por defecto y es aquí donde residía el fallo.

Para establecer este parámetro creo un objecto en JavaScript de la clase Date que por defecto contiene la fecha y hora actual, posteriormente realizó la conversión a tipo string y construyo correctamente el valor del atributo requerido. Esto implica que en Firefox se compone correctamente, pero en cambio en Internet Explorer no, debido a que la conversión a String en Internet Explorer es diferente, la posición del año se encuentra cambiada de lugar. Este hecho se puede comprobar directamente con el siguiente código:


<html>
<head></head>
<body>
<script type="text/javascript">
var today = new Date();
alert(today);
</script>
</body>
<html>

Mozilla Firefox

Internet Explorer

Aparte de esta pequeña peculiaridad, trabajar con DOM los objetos de la página html, puede tener también algunas complicaciones. Como por ejemplo, para modificar el texto de una etiqueta h2, en Internet Explorer tenemos que utilizar el atributo innerHTML y en Firefox es suficiente con utilizar el atributo textContent.

La Reunión

2007-12-11T23:59:00.000+01:00

En la reunión del lunes le comenté a Marc y a Pigui, las complicaciones que había tenido en la tarea de pasar de Wikibook a PDF. Estas fueron las que expuse:

He tenido problemas con las fuentes de la clase TCPDF. Intentaba utilizar las fuentes que venían por defecto con FPDF (arial, times, courier, ...), pero parece que solo se pueden utilizar fuentes Unicode en formato TruType. Solución: Utilizar las fuentes que vienen por defecto.
La función (o parser) encargado de pasar de html a pdf de la clase TCPDF, que se llama writeHTML, solo imprime listas sencillas (<ul> y <ol>), es decir, permite listas de listas pero las imprime como si fueran listas sencillas o simples. Actualmente estoy trabajando en solventar esta disfunción.
Los enlaces no están completados correctamente, el parser de la clase TCPDF, recoge el atributo "href" del enlace(<a>) y lo escribe directamente e incompleto.
Existe un restricción de etiquetas no soportadas, que simplemente son eliminadas, dejando únicamente el texto que contenían entre ellas.

Estos días estoy analizando el código para poder corregir estas pequeñas deficiencias y tenerlas solucionadas lo antes posible. He tenido un par de buenas ideas que creo que me darán buenos resultados.

Seguiré informando...

Resumen de la Semana Pasada

2007-12-10T12:48:00.000+01:00

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"

My first plugin :)

2007-12-07T23:56:00.000+01:00

El viernes 30 de noviembre de 2007, acabé mi primer plugin, para Moodle. Estoy muy satisfecho con el resultado y espero que con el tiempo se pueda ir mejorando y ampliando.

Junto con el TimeLine, redacté tres breves manuales (en inglés, catalán y castellano) explicando el sencillo proceso de instalación y el manejo de la interfaz. Accediendo a esta web como usuario registrado o bien como invitado, podemos ver los tres manuales y además contribuir a mejorar el texto con toda clase de críticas constructivas (...espero).

En esta otra página se encuentra el enlace de descarga del plugin. También en esta misma página se recoge otros recursos para Moodle desarollados por Dfwikiteam.

Trabajo de la Semana (II)

2007-11-25T23:53:00.000+01:00

Mejoras de la última versión del plugin:

He tenido problemas con la fechas a la hora de tratar los milisegundos transcurridos desde las 00:00 del 1 enero de 1970 (timestamp) que están almacenados en la etiqueta select con id="menudate". Al convertir el valor de timestamp en un determinado formato dentro de Javascript, constantemente daba un valor erróneo. Para solucionarlo he añadido dentro de cada opción (<option>) del select con id="menudate", el atributo id con la traducción de la fecha con el formato necesario para, si es necesario, filtrar los eventos por fecha. El formato del string es "mes día año", donde el mes tiene un representación textual y corta (las tres primeras letras, en inglés), el día con dos dígitos (añadiendo el 0 de 1-9) y el año con los cuatro dígitos. La primera solución que había implementado, no contemplaba todos los casos posibles, es decir se construía el filtro a partir del la representación de texto ya existente de la fecha.

He integrado los Highlights ya implementados de Timeline. Estos consisten en cuatro campos de distintos colores, en los que se pueden escribir para subrayar los eventos que contengan las mismas cadenas dentro de la descripción o el título.

He añadido algo que creo que se tenía que conservar, el número de registros que se mostraban en el timeline. Primero opté por buscar la forma de hacerlo a partir del objeto que creaba, pero no sabía si al filtrar se incluirían estos o no, y al no encontrar una solución solvente, me decante por crear mediante JavaScript otra pequeña ventana del navegador que llama a la página count.php con la query necesaria mostrar el número de eventos dibujados en el timeline. Si no se cierra la nueva ventana y se pulsa de nuevo el botón count, la ventana se actualiza en vez de crear otra nueva.

Ya no hace falta modificar ninguna dirección dentro del script timeline_processing.js para utilizar el plugin.

Trabajo de la semana (I)

2007-11-24T13:16:00.000+01:00

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.

Imprevistos (Desde cero...)

2007-11-13T23:24:00.000+01:00

Esta mañana he tenido que volver a instalar todo el sistema operativo, con los drivers, programas de edición de texto y otros, por culpa de un Troyano que había afectado el archivo windows/system32/user32.dll, el cual el antivirus que tenía instalado (AVG) no ha conseguido subsanar. Dudo de si la infección ha ocurrido hoy o tal vez con anterioridad.

Por suerte, suelo mantener al día los backups del trabajo realizado.

TortoiseSVN

2007-11-13T00:33:00.000+01:00

Para descargar la API del Timeline he utilizado el programa TortoiseSVN, exactamente el archivo:
“TortoiseSVN-1.4.5.10425-win32-svn-1.4.5.msi”
que se puede encontrar la página oficial. TortoiseSVN es un programa cliente SVN que se integra en la interfaz de Windows (windows explorer).

Cambiando de tema, dentro de la carpeta de la API de Timeline, existe un directorio llamado “images”, que es donde se almacena las imágenes que utiliza la API para construir las burbujas, los puntos referentes a los eventos, etc. Cambiando las imágenes por otras que conserven el mismo nombre, podemos personalizar, si cabe aún más, la visualización del Timeline. Aunque existen también otras alternativas como personalizar los eventos en el archivo XML, con los campos icon, image, ... (Para más información remítase a la entrada anterior).

Formato de los Eventos y Accesibilidad

2007-11-09T16:17:00.000+01:00

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>

Filtros & Eventos

2007-11-04T23:22:00.001+01:00

Para filtrar los eventos podemos utilizar nuestras propias funciones. Dichas funciones pueden utilizan el potencial que nos brindan las expresiones regulares de Javascript. Un ejemplo de definición de una función de filtraje sería:

var regex = new RegExp(chain /* Patrón o cadena a filtrar */, "i");

filterMatcher = function(evt) {

return regex.test(evt.getDescription());

};

Se define una expresión regular con la cadena o patrón a buscar. En este caso, se buscará el string dentro de la descripción de cada evento (el texto que hay entre las etiquetas de <event></event>), los que valúen a cierto serán visibles y los que valúen a falso no se mostrarán. Después se asigna está función a las bandas del Timeline que queremos filtrar, y por último repintamos el Timeline:

for (var i = 0; bandIndices.length; i++)
{
var bandIndex = bandIndices[i];
timeline.getBand(bandIndex).getEventPainter().
setFilterMatcher(filterMatcher);
}

timeline.paint();

Para poder trabajar con filtros es necesario saber algunos métodos de la clase Event, estos métodos nos sirven para acceder a la información (los eventos) ya cargada con el método loadXML del objeto Timeline:

Straight from the code:
Timeline.DefaultEventSource.Event.prototype
Event Methods:
getID: function() { return this._id; },
isInstant: function() { return this._instant; },
isImprecise: function() { return this._start != this._latestStart
|| this._end != this._earliestEnd; },
getStart: function() { return this._start; },
getEnd: function() { return this._end; },
getLatestStart: function() { return this._latestStart; },
getEarliestEnd: function() { return this._earliestEnd; },
getText: function() { return this._text; },
getDescription: function() { return this._description; },
getImage: function() { return this._image; },
getLink: function() { return this._link; },
getIcon: function() { return this._icon; },
getColor: function() { return this._color; },
getTextColor: function() { return this._textColor; },
getProperty: ...
getWikiURL: function() { return this._wikiURL; },
getWikiSection: function() { return this._wikiSection; },
setWikiInfo: function(wikiURL, wikiSection) { ... }

Por último decir, que tengo la pestaña de Participante casi acabada. Tengo que ir implementando los demás filtros de forma más personalizada. Aparentemente la pestaña de Fechas y Acciones dentro de la página de registros, supondrán un poco más de dedicación.

“No cambié de canal, mañana más”

getxml.php v2.0

2007-11-01T17:44:00.000+01:00

He corregido un pequeño fallo dentro de dicho archivo.

En resumen, el archivo getxml.php crea a partir de la base de datos de Moodle el archivo xml con la información de los eventos solicitados a través de la página /moodle/course/report/log/index.php. En dicho archivo se va concatenando la información de los eventos en una variable de tipo string (llamada, $file_xml) y al final se imprime todo (echo($file_xml);). Pero esta forma de almacenar la información implicaba que cuando el numero de eventos excedía una cantidad limitada (unos XX KBytes) se producía este error:

Como no sabía si existían limitaciones de variables con Moodle o en PHP, opté por ir imprimiendo en cada iteración un evento para solucionar el problema, y funcionó. El Guru Pigui, me dijo que seguramente existe una limitación de tamaño a nivel de programación en PHP o en el servidor.

Change the course

2007-10-28T20:16:00.000+01:00

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

Reading

2007-10-25T23:59:00.001+02:00

He estado ojeando la Wiki de Timelines de SIMILE y especialmente la sección dedicada a How-Tos, donde he dedicado una especial atención al apartado de "How to Load Events Dynamically".

La sección How-Tos recoge algunos de los problemas y consultas de los usuarios, recopilándolos por temática. Además, hay enlaces directos al Mailing List(foros con información de todos los proyectos de SIMILE) con las preguntas relacionadas.

Si necesitas documentación sobre Timelines, te recomiendo estimado lector que entres primeramente en la sección Wiki , es más completa que la sección de documentación estática. Incluso en la misma página principal de SIMILE Timeline se dice que se ha transferido la información a la wiki para facilitar el mantenimiento.

¡¡¡ Escoge la forma de hacerlo wiki !!!

La notación JSON

2007-10-22T23:08:00.000+02:00

Leyendo Introducción a AJAX, he encontrado que la notación utilizada en la mayoría de scripts de Timeline y en su definición, es la JSON, que es básicamente una forma estructurada de componer los objetos y arrays.

Según el libro: “La notación de objetos mediante JSON es una de las características principales de JavaScript y un mecanismo definido en los fundamentos básicos del lenguaje. JSON permite definir arrays y objetos de una manera concisa, lo que supone una gran ventaja respecto de la notación tradicional de los objetos y los arrays”.

Un ejemplo de la notación JSON para crear objetos sería:

var objeto = {
"propiedad1": valor_simple_1,
"propiedad2": valor_simple_2,
"propiedad3": [array1_valor1, array1_valor2],
"propiedad4": { "propiedad anidada": valor },
"metodo1": nombre_funcion_externa,
"metodo2": function() { ... },
"metodo3": function() { ... },
"metodo4": function() { ... }
};

Siguiendo con la lectura, he encontrado una sutil diferencia a la hora de crear objetos o como dice el libro, pseudoclases. La diferencia está en la propiedad prototype. Me explico, los métodos que se definen con protoype se crean una sola vez para todos los objetos, en cambio, si no utilizamos prototype, se crea el mismo método para cada objeto y en consecuencia ocupando más espacio. Utilizando protoype, podemos redefinir metodos de clases ya existentes o bien añadir nuevos.

Para ilustrarlo mejor adjunto un ejemplo de la propiedad prototype.

Clase original
function Factura(idFactura, idCliente) {
this.idFactura = idFactura;
this.idCliente = idCliente;
this.muestraCliente = function() {
alert(this.idCliente);
}
this.muestraId = function() {
alert(this.idFactura);
}
}

Clase que utiliza su prototype
function Factura(idFactura, idCliente) {
this.idFactura = idFactura;
this.idCliente = idCliente;
}
Factura.prototype.muestraCliente = function() {
alert(this.idCliente);
}
Factura.prototype.muestraId = function() {
alert(this.idFactura);
}

AJAX

2007-10-22T13:11:00.001+02:00

Tras leer algunos apartados de Introducción a Javascript, que me han servido para solucionar algunos problemas que tenía con los Timelines, he comenzado a leer otro libro que también me puede ser de gran ayuda, se llama Introducción a AJAX, del mismo autor que Introducción al Javascript (Javier Eguíluz Pérez) y de la misma página web.

Este libro trata con más profundidad el tema DOM y Javascript, y por eso creo que me puede servir de cara a trabajar con Timelines.

DOM Inspector

2007-10-18T22:54:00.000+02:00

Utilizando el DOM Inspector de la pestaña de herramientas de Mozilla, he encontrado que aunque el código del html tenga dos bodys (uno con identidad y el otro no) los eventos de onload y onresize, que están en el segundo, pasan a estar en el primer body.

Igualmente he quitado el body que servía para cargar el Timeline y reescalarlo, y he añadido estos dos eventos a través de un javascript con las siguientes instrucciones:

window.onload=onLoad;
window.onresize=onResize;

Al objeto window podemos definirle cuales serán las funciones o sentencias a llamar cuando se generen los eventos onload y onresize de la ventana.

El menú del día

2007-10-16T23:46:00.000+02:00

Esta tarde he estado practicando en un menú opcional para la visualización del Timeline. Esta idea consiste en añadir una menú para poder redefinir algunos aspectos de la visualización del Timeline (el tamaño básicamente, pero también otras personalizaciones), y también de paso, empezar ha trabajar más en JavaScript. Hasta ahora, la mayor parte de código que he programado ha sido en php y quería comenzar ha trabajar un poco más JavaScript.

El primer libro que leí de JavaScript durante el verano, Guía Practica de JavaScript , ha sido de ayuda en algunos aspectos, pero no abarcaba otros que son importantes. El libro se centraba en la manipulación de objetos ya existentes en html pero no se hacía referencia al Document Object Model, DOM.

En la búsqueda de otro manual más reciente, he encontrado un libro con licencia Creative Commons llamado “Introducción al JavaScript” de Javier Eguíluz Pérez. En este libro he encontrado funciones del navegador(?) que desconocía, como por ejemplo createElement, appendChild o removeChild. Solo decir que me ha ayudado bastante para empezar ha trabajar más en JavaScript.

See you.

getxml.php, O.K.

2007-10-15T00:08:00.000+02:00

He acabado de solucionar los problemas que había descrito anteriormente.

El primer problema es que habían caracteres inválidos en la variable $getaxml, dicha variable tenía comillas dobles repetidas e innecesarias. Que afectaban directamente a la función loadXML.

El segundo problema era que se realizaba una llamada a la función build_logs_array en de la librería /moodle/course/lib.php con un parámetro incorrecto.

También he creado el archivo /moodle/course/report/log/timeline.lib.php con dos sencillas funciones que se utilizan en /moodle/course/report/log/getxml.php, comentadas en formato javadoc.

Con más técnica!!!

2007-10-14T19:34:00.000+02:00

Entre ayer y hoy, he acabado de leer el documento del Dfwikiteam de “Tècniques de programació especifiques per PHP” de Ferran Recio Calderó. Ha sido un lectura muy amena de un manual de programación, su tono informal y los ejemplos facilitan considerablemente la compresión a lector.

Reordenando

2007-10-11T23:42:00.000+02:00

Hoy, he estado trabajando en cambiar la función que generaba el archivo xml, que estaba almacenada en /moodle/course/report/log/lib.php al nuevo archivo /moodle/course/report/log/get_xml.php.

Me he encontrado con dos problemas que espero solucionar lo antes posible. El primero es que el timeline no se muestra bien y el segundo que es independiente del primero, la información de los eventos que genera el archivo get_xml.php, no inserta ningún evento, seguramente se trata de una llamada errónea en la obtención de los logs de la base de datos de Moodle.

"Revisando código"

2007-10-09T23:30:00.001+02:00

Tras la reunión del pasado lunes, estoy revisando el código ya hecho de timelines por los compañeros del DFWikiteam.

De momento tengo que cambiar el funcionamiento de generar un archivo para cada usuario, donde se encuentran los eventos solicitados, por el de llamar a una nueva página php para generar el xml de forma más dinámica, con el fin de evitar que cualquier persona pueda ver los logs (xml’s guardados en el disco) solicitados por los demás. La idea propuesta por Jordi Piguillem, es de los más acertada. Primero me centraré en conseguir esto y después comprobaré la seguridad, al igual que lo hace Moodle.

He conseguido solucionar el problema que tenía con la API de Timelines. Resulta que no había descargado todos los archivos necesarios para el correcto funcionamiento del Timeline. Y por este motivo tenía que acceder constantemente a la página oficial.

Identifícate

2007-10-04T11:40:00.000+02:00

Había detectado un fallo cuando se cambiaban los participante.

Cuando se seleccionaba de “Todos los usuarios” a “Invitado”, siempre se pintaban en el timeline los mismos eventos. Esto era debido a que tras haber conseguido los registros de todos los usuarios, se creaba el archivo 0_info_timeline.xml (“id. del participante solicitado”_info_timeline.xml, en este caso todos) y al pedir el registro del invitado creaba otro archivo con un número distinto, pero en la inicialización de variables del timeline solo se utilizaba el archivo 0_info_timeline.xml.

Este error conceptual lo he solucionado cambiando la “id. del participante” por la “id. de la persona que esta accediendo a los registros” que era en principio lo que tenia en mente, de esta forma solo hay un archivo por usuario en el servidor. Otra razón era la de evitar conflictos con los archivos.

Más detalladamente, he insertado un input hidden con el número de identificación del usuario y desde el JavaScript tomo el valor guardado, esto implica que la inicialización de las variables del timeline debe ser posterior a la definición del input.

Sigo anotando...

2007-09-24T00:17:00.000+02:00

Quedan por acabar algún par de detalles para tener bien encaminada la integración del Timeline. Después de pelearme con el formato requerido por el Timeline y los strings, he conseguido tener los documentos estructurados para una interpretación correcta de los eventos. Hay tres tipos de eventos, los que tiene una duración predeterminada, eventos instantáneos y los eventos instantáneos en los que no se sabe con exactitud cuando han comenzado. Los que he utilizado han sido los eventos instantáneos, creo que son los más generales, aunque se puede utilizar también los que tienen una duración determinada para algunos casos más específicos.

De la parte del Moodle, destacar que en la página de Moodle Docs hay suficente información para empezar a trabajar en Moodle. Pero en mi opinión, creo que requiere mucho más tiempo estudiar el código detenidamente, si se es programador. También hay disponibles bastantes herramientas para desarrolladores (por ejemplo, Cross reference, muy útil) que facilitan en gran medida el trabajo.

“I’ll come back”

Moodle, bases de datos y otras cosas...

2007-09-17T00:39:00.000+02:00

Después de trabajar con Moodle, PHP, JavaScript, HTML y Bases de Datos, he conseguido hacer (de esa forma...) una de las tareas que me había encomendado Marc, visualizar un timeline con un log de Moodle.

Y mis primeras conclusiones son: que tengo que seguir aprendiendo más de JavaScript, PHP y volver a revisar en profundidad los apuntes de BD (algo muy importante a saber para brillar en una entrevista de trabajo, pero eso es algo que ya explicaré).

Por último he tenido un problemilla con la librería GD, requerida por Moodle para generar gráficos, que no he llegado a poder instalar, algo que espero solventar.

Primeros pasos

2007-09-16T00:08:00.000+02:00

Es hora de poner a prueba lo aprendido en los deberes de verano (programar en PHP y JavaScript).

Mi primera tarea, y en mi opinión muy estimulante, es la de crear Timelines (“widget” en AJAX) a partir de un registro de Moodle, es decir, de la base de datos que utiliza Moodle para crear estos logs de participación.

Un Timeline es un espectacular cronograma con el que podemos interactuar directamente con solo unos clicks de ratón. Para generarlo solo necesitamos incrustarlo en la página web que queramos y llamar a la API con la información de los eventos.