El bloque recent_activity es el que al intentar cargarse genera el problema con la dfwiki más la newwiki instalada de que solo se cargan tres bloques de la sección de la izquierda.
Investigando he descubierto la causa, y una solución provisional:
El bloque recent_activity llama a la función print_recent_activity definida en course/lib.php. Esta función ejecuta las siguientes instrucciones:
$mods = get_records('modules', 'visible', '1', 'name', 'id, name');
foreach ($mods as $mod) { // Each module gets it's own logs and prints them
include_once($CFG->dirroot.'/mod/'.$mod->name.'/lib.php');
$print_recent_activity = $mod->name.'_print_recent_activity';
if (function_exists($print_recent_activity)) {
$modcontent = $print_recent_activity($course, $isteacher, $timestart);
if ($modcontent) {
$content = true;
}
}
}
Cuando se hace el include_once de mod/dfwiki/lib.php es cuando falla.
Y este fallo se produce por que en el mod/dfwiki/lib.php se hace require_once ('dfwikilib.php') y require_once ('blocks/lib.php');
Para que funcione unasolcuión provisional sería introducir el siguiente código en mod/dfwiki/lib.php
global $COURSE;
if (!$COURSE->format='wiki'){
require_once ('dfwikilib.php');
require_once ('blocks/lib.php');
}
Lo he probado y funciona en el curso wiki, pero digo PARCIAL, ya que desconozco el funcionamiento de la dfwiki y no estoy seguro que pueda afectar en algo más.
Creo esta solución/apaño solamente falla en el caso en que en un curso_wiki se cree una actividad de tipo dfwiki, pero en teoría eso no debería ocurrir, y llegado el caso se puede modificar la dfwiki para que no se permita añadir actividades dfwiki en un curso wiki.
Dejo dos pantallitas que dan fé de que funciona:
izquierda derecha
Luego de comentar esto con pigui, el me informa que no se puede tocar el código de la dfwiki, y que la solución real, pasará por modificar los nombres de las funciones de la newwiki, para que se diferencien de los nombres de las funciones de la dfwiki. De esta manera, aunque s ehaga el include de las librerias de la dfwiki o de la new wiki, se llamará siempre a las funciones correctas desde cada módulo wiki. Pigui me informa que esta tarea la realizará él, motivo por el que mi colaboración respecto al curso wiki, de momento puede darse por finalizada.
Adicionalmente Pigui modificará algunos otros temas del curso wiki, como por ejemplo la carga de determinados javascript que no se están cargando o que funcionan de manera incorrecta.
lunes, octubre 30, 2006
Solución de los links en Curso Wiki
La idea es buscar una solución que pueda adaptarse también posteriormente al curso wiki principal.
Hay que eliminar la asignación $WS->cm->id=$WS->course->id, y que los links de la forma
mod/wiki/view.php=?'$cm->id', distingan el curso wiki de la actividad wiki y posteriormente distingan también el curso wiki principal.
Aprovechando que con la inicialización tanto del curso wiki como de la actividad wiki se realiza al llamar a la función wiki_main_setup, en dicha fucnión se define el seguiente código:
$WS->wikitype='/mod/wiki/view.php?id=';
$WS->linkid=$WS->cm->id;
if (isset($WS->dfcourse)){
$WS->wikitype='/course/view.php?id=';
$WS->linkid=$COURSE->id;
}
Luego se modifican todos los links del tipo mod/wiki/view.php=?'$cm->id', por 'WS->wikitype'.'WS->linkid'
Ahora los links ya se forman de manera correcta tanto en un curso wiki como en una actividad wiki, y en el futuro para el curso wiki principal, solo habrá que modificar el código de la siguiente forma:
$WS->wikitype='/mod/wiki/view.php?id=';
$WS->linkid=$WS->cm->id;
if (isset($WS->dfcourse)){
if ($CORSE->category!=0){ //curso wiki estandard
$WS->wikitype='/course/view.php?id=';
}
else { //Curso wiki como curso principal
$WS->wikitype='/index.php?id=';
}
$WS->linkid=$COURSE->id;
}
Nota: Habrá que modificar los links duplicados que actualmente se definen en los bloques para que sigan este mismo esquema.
Hay que eliminar la asignación $WS->cm->id=$WS->course->id, y que los links de la forma
mod/wiki/view.php=?'$cm->id', distingan el curso wiki de la actividad wiki y posteriormente distingan también el curso wiki principal.
Aprovechando que con la inicialización tanto del curso wiki como de la actividad wiki se realiza al llamar a la función wiki_main_setup, en dicha fucnión se define el seguiente código:
$WS->wikitype='/mod/wiki/view.php?id=';
$WS->linkid=$WS->cm->id;
if (isset($WS->dfcourse)){
$WS->wikitype='/course/view.php?id=';
$WS->linkid=$COURSE->id;
}
Luego se modifican todos los links del tipo mod/wiki/view.php=?'$cm->id', por 'WS->wikitype'.'WS->linkid'
Ahora los links ya se forman de manera correcta tanto en un curso wiki como en una actividad wiki, y en el futuro para el curso wiki principal, solo habrá que modificar el código de la siguiente forma:
$WS->wikitype='/mod/wiki/view.php?id=';
$WS->linkid=$WS->cm->id;
if (isset($WS->dfcourse)){
if ($CORSE->category!=0){ //curso wiki estandard
$WS->wikitype='/course/view.php?id=';
}
else { //Curso wiki como curso principal
$WS->wikitype='/index.php?id=';
}
$WS->linkid=$COURSE->id;
}
Nota: Habrá que modificar los links duplicados que actualmente se definen en los bloques para que sigan este mismo esquema.
Reunión Semana 7
La entrega a Dougiamas se pospone al miércoles. Hay que terminar de limpiar los comentarios, y solucionar el problema del curso wiki.
Pigui mirará de resolver por que falla con la dfwiki y la newwiki instaladas conjuntamente, y yo resolveré el tema de los links.
LUDO nos comenta que una vez finalizada la entrega, nos dediquemos al curso wiki como curso principal y a introducir una nueva fucnionalidad: Categorías. Por otro lado Pigui nos pide que resolvamos todos los oprional_param, de manera que se utilicen todos los parámetros y garanticemos así el nivel de seguridad que se requiere para que la wiki pueda formar parte del moodle oficial.
Pigui mirará de resolver por que falla con la dfwiki y la newwiki instaladas conjuntamente, y yo resolveré el tema de los links.
LUDO nos comenta que una vez finalizada la entrega, nos dediquemos al curso wiki como curso principal y a introducir una nueva fucnionalidad: Categorías. Por otro lado Pigui nos pide que resolvamos todos los oprional_param, de manera que se utilicen todos los parámetros y garanticemos así el nivel de seguridad que se requiere para que la wiki pueda formar parte del moodle oficial.
Puesta a punto del Curso Wiki
Continúo trabajando con el curso wiki.
La solución de las pestañas para visualizar el curso wiki no gusta a nadie, y menos la de la redirección, así que me pongo a trabajar para que en el curso wiki se vean todas las pestañas, no solo la de editar, y que el tratamiento se realice totalmente en el curso wiki.
Esto implica modificar el formato del curso wiki para acceder a todas las librerias de la actividad wiki (especialmente locallib.php) pero sin duplicar código. Para conseguirlo, hay que analizar e ir creando la instancia de curso wiki de forma paralela a como se hace en la actividad wiki, pero distinguiendo el tratamiento especial del curso wiki, como por ejemplo la integración de las actividades sociales.
Para conseguirlo se sigue el siguiente esquema:
En una actividad, el link es del tipo mod/wiki/view.php?=ID_de_la_ página_wiki, mientras que en el curso el link se ha de ser del tipo course/view-php?=ID_del_módulo_wiki.
Lo primero que se me ocurre es hacer la asignación la asignación a $WS->cm->id=$WS->course->id, que aunque es incorrecto me permite fácilmente verificar las funcionalidades. De momento dejo dicha asignación, aún sabiendo que debe cambiarse y verifico las funcionalidades.
Las pestañas de view, edit, discuss, history, navegation, evaluate, las voy verificando correctamente y voy solucionando pequeños problemas que aparecen (Como por ejemplo cargar el javascript para que aparezcan los botones en el editor dfwiki y e-wiki).
Los bloques parecen funcionar bien, gracias a que con anterioridad ya se habían programado para fucnionar tanto en actividad como en curso wiki.
El último gran tema que queda es el del bloque de administración de las ead_tools. Algunas funcionan y otras no...Para solucionar este problema, es necesario tratar correctamente el tema de los links, es decir eliminar la asignación comentada arriba, y hacer el tratamiento sugerido por Pigui con el siguiente código:
if (isset($dfcourse)){
//lo que sea referente al curso
}else{
//el codigo .
}
Con el curso wiki "funcionando", lo subo al cvs de sourceforge.Pigui la prueba y lo primero que comenta es que NO funciona.
Extrañado, aunque no mucho, ya que en mi instalación perfectamente, y en la de Paton también.
El primer indicio parece ser que es debido a un problema al cargar los bloques.
Con Marc Catala y utilizando su instalación de Moodle, verificamos que el curso wiki a él también le falla. Investigando, llegamos a la conclusión que el problema ocurre cuando se tiene instalada la dfwiki y la newwiki en un mismo sistema. No era ese mi caso, ya que en su momento no pude instalar la dfwiki, y por lo tanto solo tenía la new wiki.
En la reunión del miércoles trataremos este tema para ver como lo solucionamos.
Por este tema, entre entre otros, se decide no entregar el código a Dougiamas, pero deberemos darnos prisa para solcuionarlo lo antes posible.
En esta imágen puede observarse como falla el curso wiki con la dfwiki y la newwiki instalada:
Fallo(Solo se cargan algunos bloques de la sección de la izquirda)
La solución de las pestañas para visualizar el curso wiki no gusta a nadie, y menos la de la redirección, así que me pongo a trabajar para que en el curso wiki se vean todas las pestañas, no solo la de editar, y que el tratamiento se realice totalmente en el curso wiki.
Esto implica modificar el formato del curso wiki para acceder a todas las librerias de la actividad wiki (especialmente locallib.php) pero sin duplicar código. Para conseguirlo, hay que analizar e ir creando la instancia de curso wiki de forma paralela a como se hace en la actividad wiki, pero distinguiendo el tratamiento especial del curso wiki, como por ejemplo la integración de las actividades sociales.
Para conseguirlo se sigue el siguiente esquema:
- En un curso wiki, el archivo que se carga es course/view.php, y desde aquí se cargan los bloques del curso definidos en course/format/wiki/config.php y el formato del curso definido en course/format/wiki/format.php.
- En format.php se incluye el código de mod/wiki/lib.php que a su vez incluye el código de mod/wiki/locallib.php (Ya tenemos el 99% de las funciones de la actividad wiki para ser utilizadas en el curso wiki), y se define antes que nada la variable $WS->dfcourse = 1; que indica que estamos en un curso wiki.
- Seguimos en format.php se realizan las verificaciones de seguridad, que la página existe, etc... y se llama a wiki_main_view_setup() donde se verifica la versión de la página. A continuación se cargan los bloques de la sección de la izquierda y en la sección central se integra el bloque social activies y luego se carga el curso wiki medienta la llamada a wiki_main_view_content()
- En wiki_main_view_content(), definida en locallib, es donde se hará ahora el tratamiento más específico para que el curso wiki se comporte como una actividad wiki, es decir que funcionen todas las características de una wiki sobre el curso. Para esto y a medida que se van precisando se recogen todos los parámetros para el correcto tratamiento de las funcionalides y de los formularios, mediante la función optional_param(). y luego se hace la llamada a wiki_setup_content($WS); donde se define el contenido del curso wiki y finalmente se imprime mediante la llamada a wiki_print_content ($WS); (ambas funciones definidas en mod/wiki/lib.php.
En una actividad, el link es del tipo mod/wiki/view.php?=ID_de_la_ página_wiki, mientras que en el curso el link se ha de ser del tipo course/view-php?=ID_del_módulo_wiki.
Lo primero que se me ocurre es hacer la asignación la asignación a $WS->cm->id=$WS->course->id, que aunque es incorrecto me permite fácilmente verificar las funcionalidades. De momento dejo dicha asignación, aún sabiendo que debe cambiarse y verifico las funcionalidades.
Las pestañas de view, edit, discuss, history, navegation, evaluate, las voy verificando correctamente y voy solucionando pequeños problemas que aparecen (Como por ejemplo cargar el javascript para que aparezcan los botones en el editor dfwiki y e-wiki).
Los bloques parecen funcionar bien, gracias a que con anterioridad ya se habían programado para fucnionar tanto en actividad como en curso wiki.
El último gran tema que queda es el del bloque de administración de las ead_tools. Algunas funcionan y otras no...Para solucionar este problema, es necesario tratar correctamente el tema de los links, es decir eliminar la asignación comentada arriba, y hacer el tratamiento sugerido por Pigui con el siguiente código:
if (isset($dfcourse)){
//lo que sea referente al curso
}else{
//el codigo .
}
Con el curso wiki "funcionando", lo subo al cvs de sourceforge.Pigui la prueba y lo primero que comenta es que NO funciona.
Extrañado, aunque no mucho, ya que en mi instalación perfectamente, y en la de Paton también.
El primer indicio parece ser que es debido a un problema al cargar los bloques.
Con Marc Catala y utilizando su instalación de Moodle, verificamos que el curso wiki a él también le falla. Investigando, llegamos a la conclusión que el problema ocurre cuando se tiene instalada la dfwiki y la newwiki en un mismo sistema. No era ese mi caso, ya que en su momento no pude instalar la dfwiki, y por lo tanto solo tenía la new wiki.
En la reunión del miércoles trataremos este tema para ver como lo solucionamos.
Por este tema, entre entre otros, se decide no entregar el código a Dougiamas, pero deberemos darnos prisa para solcuionarlo lo antes posible.
En esta imágen puede observarse como falla el curso wiki con la dfwiki y la newwiki instalada:
Fallo(Solo se cargan algunos bloques de la sección de la izquirda)
Reunión Semana 6
Presentamos la primera aproximación del curso wiki como curso principal.
A LUDO le gusta el aspecto pero nos pide que dejemos de lado el curso wiki para centrarnos en la próxima entrega de código al Sr. Dougiamas. A tal efecto, debemos centrarnos en la depuración de los comentarios que hay en el código, y verificar el correcto funcionamiento de las pocas funcionalidades que hemos añadido y de los bugs que hemos corregido.
Comentamos que donde más trabajo nos queda es en el curso wiki, y que el tema fundamental a tratar es que la creación de los links para identificar el caso de curso wiki del caso actividad wiki, la hemos realizado a costa de sobreescribir una variable que NO debemos sobrescribir, pero que lo hemos hecho así para probar primero que funciona, y una vez que viéramos que funciona lo solucionaremos correctamente.
A LUDO le gusta el aspecto pero nos pide que dejemos de lado el curso wiki para centrarnos en la próxima entrega de código al Sr. Dougiamas. A tal efecto, debemos centrarnos en la depuración de los comentarios que hay en el código, y verificar el correcto funcionamiento de las pocas funcionalidades que hemos añadido y de los bugs que hemos corregido.
Comentamos que donde más trabajo nos queda es en el curso wiki, y que el tema fundamental a tratar es que la creación de los links para identificar el caso de curso wiki del caso actividad wiki, la hemos realizado a costa de sobreescribir una variable que NO debemos sobrescribir, pero que lo hemos hecho así para probar primero que funciona, y una vez que viéramos que funciona lo solucionaremos correctamente.
Curso Wiki como curso principal
Siguiendo con el curso Wiki, pero ahora buscando modificar el moodle para permitir que el curso Wiki pueda ser el Curso principal. De esta manera, al acceder a Moodle, lo primero que se debe ver es el curso wiki, con su wiki y su bloque de actividades sociales integrados, pero con los demás bloques propios del curso principal, es decir el bloque de administración de Moodle, el bloque con los cursos de Moodle, etc...
Lo primero que observo es que en la tabla mdl_course, el curso principal se distingue de los demás cursos en que el campo category tiene valor 0, mientras que el resto de curso dicho campo tiene valor 1.
Otros datos a tener en cuenta, es que por defecto el formato del curso principal es "social", y que dicho formato no se puede modificar en el formulario de administración del curso principal.
El primer intento es modificar manualmente el campo category, poniendo a category=0 a un curso wiki, pero me encuentro que aunque se carga el curso wiki como curso principal sin demasiados efectos colaterales. El mayor problema que puedo observar es que en la sección del centro, además de cargarse el curso wiki, se cargan todos los bloques que con anterioridad se habían definido a dicho curso. Esto es normal, pero indica que habrá que tener un tratamiento especial en relación a que bloques se cargan y como se cargan en el caso del curso wiki ya que se están cargando dos veces. Una en la sección central, y otra en la sección de la derecha o izquierda.
Aquí puede observarse el efecto anteriormente comentado: Curso Wiki principal primera aproximación
Continúo investigando. Una solución al tema bloques pasa por introducir un if dentro de course/wiki/formatlib.php, donde se cargan los bloques, y en caso que category=0 no cargar los bloques. Aquí puede observarse el nuevo aspecto: Curso Wiki principal segunda aproximación Se ha solucionado el problema de la visualización de los bloques, pero al intentar editar el curso, se observa que hay un problema con las secciones. La integración del bloque de social_activities se carga mal.
Conclusiones:
Lo primero que observo es que en la tabla mdl_course, el curso principal se distingue de los demás cursos en que el campo category tiene valor 0, mientras que el resto de curso dicho campo tiene valor 1.
Otros datos a tener en cuenta, es que por defecto el formato del curso principal es "social", y que dicho formato no se puede modificar en el formulario de administración del curso principal.
El primer intento es modificar manualmente el campo category, poniendo a category=0 a un curso wiki, pero me encuentro que aunque se carga el curso wiki como curso principal sin demasiados efectos colaterales. El mayor problema que puedo observar es que en la sección del centro, además de cargarse el curso wiki, se cargan todos los bloques que con anterioridad se habían definido a dicho curso. Esto es normal, pero indica que habrá que tener un tratamiento especial en relación a que bloques se cargan y como se cargan en el caso del curso wiki ya que se están cargando dos veces. Una en la sección central, y otra en la sección de la derecha o izquierda.
Aquí puede observarse el efecto anteriormente comentado: Curso Wiki principal primera aproximación
Continúo investigando. Una solución al tema bloques pasa por introducir un if dentro de course/wiki/formatlib.php, donde se cargan los bloques, y en caso que category=0 no cargar los bloques. Aquí puede observarse el nuevo aspecto: Curso Wiki principal segunda aproximación Se ha solucionado el problema de la visualización de los bloques, pero al intentar editar el curso, se observa que hay un problema con las secciones. La integración del bloque de social_activities se carga mal.
Conclusiones:
- Analizar en profundidad el tema de las secciones. Como mínimo es incorrecto el tratamiento que se hace en course/wiki/format.php, a la hora de integrar las social_activities.
- Analizar como editar el formulario de configuración->site settings del curso principal, SIN TOCAR el código de moodle. Esto será posible siempre que dicho formulario se genere dinámicamente.
- Editar (site settings) el curso principal para permitir seleccionar el formato de curso wiki y que ocurre cuando se selecciona el orden de aparición de la Lista de Novedades, de la Lista de Cursos y de la Lista de Categorias. (Se puden definir para que se visualicen Hide, First, Second..) y al guardar los cambios, se modifica la tabla de mdl_course_sections, con lo que se observa una relación al punto anterior donde se habla del tratamiento de las secciones.
- Revisar la creación de TODOS los links, para que apunten a localhost/index.php en lugar de a localhost/course/view.php. ($WS->wikitype=localhost/index.php?=).
sábado, octubre 14, 2006
To tab or not to tab
Hemos estado trabajando en el tema de la coherencia en la navegabilidad de una wiki en formato wiki.
Lo que a principio parecía algo simple se ha complicado.
Contexto
Actualemente hemos adoptado la solución de las pestañas. Pero no descartamos modificar la solución y aplicar la redirección o el tratamiento diferenciado.
Lo que a principio parecía algo simple se ha complicado.
Contexto
Curso en formato Wiki
- Al acceder a una wiki en formato curso, se carga el archivo moodle/course/view.php . Éste archivo utiliza carga los archivos moodle/course/format/wiki/format.php, formatlib.php y config.php que definien el formato de los bloques dentro del curso.
- Los únicos archivos que a priori podemos modificar al nivel de moodle/course, son format.php y formatlib.php.
- El archivo format.php hace un require de moodle/mod/wiki/lib.php que a su vez hace un require de moodle/mod/wiki/locallib.php . es en estos archivos donde se define la lógica de las funcionalidaes.
- Resumiendo, es un poco kafquiano, pero las funcionalidades se cargan a partir de los arrchivos que definen el formato de los bloques que se integran al curso...
Módulo Wiki
- La wiki se carga a partir del archivo moodle/mod/wiki/view.php y que hace un require de moodle/mod/wiki/lib.php que a su vez hace un require de moodle/mod/wiki/locallib.php
Elementos comunes
- Las funcionalidades están definidas en la ruta moodle/mod/wiki
- Concretamente en los archivos locallib.php y lib.php
- Son comunes tanto al módulo wiki como al curso wiki.
- Al acceder a una funcionalidad de una wiki integrada a un curso, como por ejemplo editar la wiki, se termina cargando el archivo moodle/mod/wiki/view.php.
- Al guardar la edición, en lugar de volver a la wiki en formato curso, volevemos a la wiki en formato módulo. Y esto no queremos que sea así.
- Crear una nueva pestaña:
- Al estar en un curso wiki, crear una pestaña que se visualice al estar en la vista tipo módulo de la wiki, que permita volver a la vista tipo curso. Ej: Pestaña
- Ventajas: Fácil de implementar, no duplica código.
- Desventajas: No soluciona totalmente el problema. La navegabilidad no es óptima.
- Redireccionar a vista curso:
- Al estar en un curso wiki, y editar una wiki o al volver de cualquier actividad, realizar el tratamiento que corresponda y que se encuentra definido a partir de moodle/mod/wiki/view.php. Una vez realizado el tratamiento, redireccionar a moodle/course/view.php
- Ventajas: Fácil de implementar, usando al finalizar el tratamiento de la funcionalidad requerida la siguiente instrucción: header('Location:$CFG->wwwroot.$dfform["pagecourse"]'); Donde $dfform["pagecourse"]' contiene la url de la página en moodle/course/view.php
- Desventajas:
- No termina de funcionar: Warning: Cannot modify header information - headers already sent by (output started at C:\moodle\moodle\mod\wiki\blocks\lib.php:13) in C:\moodle\moodle\mod\wiki\locallib.php on line 1431.
- Hay que analizar el tema de la seguridad.
- Efectuar tratamientos distintos en función de curso o módulo wiki:
- Tratar de forma difeten una wiki en un curso wiki y en un módulo wiki mediante el siguiente código: i
- if (isset($dfcourse)){
//lo que sea referente al curso
}else{
//el codigo que habia antes.
} - Ventajas: Navegabilidad óptima. No añadimos más pestañas. No hay problema de seguiridad
- Desventajas:
- Dificultad de implementación.
- Duplicación de código.
Actualemente hemos adoptado la solución de las pestañas. Pero no descartamos modificar la solución y aplicar la redirección o el tratamiento diferenciado.
Reunión semana 5
Hemos recibido la grata visita de la Fundación Equilibri.
Esta fundación realiza actividades de educación en países desfavorecidos, actualmente están trabajando en un proyecto en Bolivia donde proporcionan recursos de personas y herramientas informáticas en el ámbito educativo con el objetivo de disminuir la llamada "brecha digital". Con anterioridad otros proyectistas del equipo ya han colaborado con la fundación realizando varias tareas en Bolivia, y ahora se nos plantea además la oportunidad de colaborar mediante el uso de una plataforma de gestión de contenidos como Moodle.
En una primera instancia, se ha creado un curso en la plataforma moodle en la siguiente dirección http://morfeo.upc.es/crom/.
En este curso la gente de equilibri, nuestro tutor Marc Alier, el conjunto de proyectistas y demás personas que desen colaborar, iremos dando forma al proyecto. Por un lado consistirá en crear la infraestructura tecnológica adecuada mediante el entorno moodle, y por otro lado, ir añadiendo contenido a modo de cursos que luego puedan integrarse en un servidor de Moodle en Bolivia.
Otra tarea en la cual esperamos colaborar, es mediante un foro de desarrollo de módulos de Moodle donde junto a los proyectistas del grupo de Marc, se unirán seis personas de la universidad de la Paz que están desarrollando también su proyecto final de carrera sobre moodle. Estamos seguros que tanto a nivel técnico como humano, la experiencia será enriquecedora para todos.
En caunto al trabajo semanal propio que hemos estado realizando, hemos comentado los siguientes temas:
Esta fundación realiza actividades de educación en países desfavorecidos, actualmente están trabajando en un proyecto en Bolivia donde proporcionan recursos de personas y herramientas informáticas en el ámbito educativo con el objetivo de disminuir la llamada "brecha digital". Con anterioridad otros proyectistas del equipo ya han colaborado con la fundación realizando varias tareas en Bolivia, y ahora se nos plantea además la oportunidad de colaborar mediante el uso de una plataforma de gestión de contenidos como Moodle.
En una primera instancia, se ha creado un curso en la plataforma moodle en la siguiente dirección http://morfeo.upc.es/crom/.
En este curso la gente de equilibri, nuestro tutor Marc Alier, el conjunto de proyectistas y demás personas que desen colaborar, iremos dando forma al proyecto. Por un lado consistirá en crear la infraestructura tecnológica adecuada mediante el entorno moodle, y por otro lado, ir añadiendo contenido a modo de cursos que luego puedan integrarse en un servidor de Moodle en Bolivia.
Otra tarea en la cual esperamos colaborar, es mediante un foro de desarrollo de módulos de Moodle donde junto a los proyectistas del grupo de Marc, se unirán seis personas de la universidad de la Paz que están desarrollando también su proyecto final de carrera sobre moodle. Estamos seguros que tanto a nivel técnico como humano, la experiencia será enriquecedora para todos.
En caunto al trabajo semanal propio que hemos estado realizando, hemos comentado los siguientes temas:
- Actualmente ya funcionan los nombres de página con apostrofes y barras invertidas, pero que nos falta probar el funcionamiento de los nombres con dichos caracteres en los bloques wiki, y en cursos y actividades sobre diversos perfiles de grupos de usuario.
- A Marc le ha gustado el formato que le hemos dado a las actividades sociales sobre un cuyrso en formato wiki. Pero hemos de continuar trabajando para conseguir que la navegabilidad entre las diversas funcionalides de una wiki en un curso wiki sea coherente. Por ejemplo al editar una wiki y guardar los cambios, hemos de volver a la wiki en el formato de curso, en lugar de a la wiki en formato de módulo.
- En cuanto a las páginas hay otro aspecto que debemos depurar, y es cuando usamos en el nombre de la página los caracteres / y | . A diferencia de la barra invertida y el apostrofe, estos caracteres se usan internamente para separar funcionalidades, por lo que NO pueden formar parte del nombre de una página wiki. Esto hace que con estos caracteres, debemos desarrollar una estrategía de substitución en lugar de una estragía de integración. El problema que observamos, es que los nombres de página suelen crearse dentro de los distintos editores, por lo que el tratamiento de estos caracteres lo deberemos realizar al parsear la wiki. Por último, otro tema es que deberemos notificar al usuario que el nombre que ha puesto a la página se ha modificado substituyendo los caracteres | y / por _
- Marc nos ha solicitado que avancemos en la integración de una wiki como formato proncipal de un curso. Esto nos habre una nueva dimensión ya que implica comenzar a desarrollar sobre el "lado oscuro" de moodle, es decir fuera del dominio de la wiki y en territorio inhóspito. En resumidas cuentas, hemos de integrar la wiki en una parte central de Moodle, y en este sentido no solo tenemos el reto de que funcione sino que tanto en el estilo del código como en el testing deberemos ser muy cuidadosos ya que nuestro trabajo será analizado rigurosamente por los Lords of the Moodle.
- El último tema tratado en relación a nuestor proyecto ha sido en plan "avance de noticias" y es que debido a la integración del módulo wiki como módulo oficial de moodle en la versión 1.8, deberemos realizar la integración de la wiki con los roles de usuarios.
jueves, octubre 12, 2006
Cursos wiki
Una de las particularidades que tiene moodle, es que es posible utilizar una wiki como página principal de un curso. El desarrollo de esta funcionalidad fué realizado el año pasado por otro grupo de proyectistas, y si bien el resultado es bastante bueno, por falt de tiempo quedaron algunos aspectos a mejorar. En este sentido, una de las tareas que se nos han solicitado es la de mejorar dicha funcionalidad y que el comportamiento de un curso wiki sea coherente con las demás funcionalidades generales de moodle y con las propias de una actividad wiki.
Durante esta semana hemos solucionado algunos problemas que se presentaban con los bloques wiki´s y el curso wiki.
El primer paso fué conseguir que el comportamiento base del curso wiki en cuanto a los nombres de páginas fuera el mismo que el nombre de página en las actividades wiki´s. Luego de varias pruebas, hemos conseguido que los nombres de pñagina se comporten igual en ambis formatos, incluidas aquellas páginas que contienen caracters como el apostrofe y la barra invetida (slash).
Sin embargo aún quedan pendientes algunos temas, como verificar el funcionamiento cuando hay grupos de por medio, verificar los links que aparecen en los bloques wikis, de modo que al estar en un curso wiki, el link lleve a la wiki en formato curso en lugar de a la wiki en formato actividad. Estos temas los veremos con profunidad la próxima semana.
Para finalizar, y en relación de las actividades sociales, hemos decido eliminar el bloque de actividades sociales, e integrar las mismas a la wiki. El resultado de esta integración puede observarse en el siguiente link: http://www.flickr.com/photos/63039100@N00/267883448/
Durante esta semana hemos solucionado algunos problemas que se presentaban con los bloques wiki´s y el curso wiki.
El primer paso fué conseguir que el comportamiento base del curso wiki en cuanto a los nombres de páginas fuera el mismo que el nombre de página en las actividades wiki´s. Luego de varias pruebas, hemos conseguido que los nombres de pñagina se comporten igual en ambis formatos, incluidas aquellas páginas que contienen caracters como el apostrofe y la barra invetida (slash).
Sin embargo aún quedan pendientes algunos temas, como verificar el funcionamiento cuando hay grupos de por medio, verificar los links que aparecen en los bloques wikis, de modo que al estar en un curso wiki, el link lleve a la wiki en formato curso en lugar de a la wiki en formato actividad. Estos temas los veremos con profunidad la próxima semana.
Para finalizar, y en relación de las actividades sociales, hemos decido eliminar el bloque de actividades sociales, e integrar las mismas a la wiki. El resultado de esta integración puede observarse en el siguiente link: http://www.flickr.com/photos/63039100@N00/267883448/
Reunión semana 4
Se realiza una explicación sobre UTF-8.
Se comenta el problema con los caracteres apóstrofe y slash en los nombres de página.
Se comenta el problema del bloque social y el formato wiki en un curso, así como el comportamiento diferente de una wiki como página principal de un curso (formato wiki) y de una wiki como una actividad más de un curso.
Se nos solicita que solucionemos estos problemas.
Se informa que todas las tareas anteriores asignadas están subidas a sourceforge, incluida la nueva página de evaluaciones.
Se nos solicita que la funcionalidad de cambio del tamaño del editor wiki también funcione con postgres.
Se nos solicita que analicemos y detectemos los casos en que el nombre de página al pasarse por parámetro utilice siempre la función optionalparam(), y que en los casos que dicha función detecte caracteres prohibidos por cuestiones de seguridad se informe al usuario del cambio del nombre de la página, ya con un nombre permitido, pero que adicionalmente se cree un sinónimo con el nombre de la página que originalmente el usuario había introducido.
Se comenta el problema con los caracteres apóstrofe y slash en los nombres de página.
Se comenta el problema del bloque social y el formato wiki en un curso, así como el comportamiento diferente de una wiki como página principal de un curso (formato wiki) y de una wiki como una actividad más de un curso.
Se nos solicita que solucionemos estos problemas.
Se informa que todas las tareas anteriores asignadas están subidas a sourceforge, incluida la nueva página de evaluaciones.
Se nos solicita que la funcionalidad de cambio del tamaño del editor wiki también funcione con postgres.
Se nos solicita que analicemos y detectemos los casos en que el nombre de página al pasarse por parámetro utilice siempre la función optionalparam(), y que en los casos que dicha función detecte caracteres prohibidos por cuestiones de seguridad se informe al usuario del cambio del nombre de la página, ya con un nombre permitido, pero que adicionalmente se cree un sinónimo con el nombre de la página que originalmente el usuario había introducido.
UTF-8
Lo primero que hacemos es investigar.
Que es UTF-8? Las siglas corresponden a Unicode Transformation Format, y es un sistema de codificación variable del sistema de mapeo de caracteres de Unicode.
A continuación se detalla la información técnica extraida de wikpedia:
Los caracteres más pequeños que 128dec son codificados con un byte sencillo que contiene su valor: este corresponde exactamente a los caracteres de 7 bits de los 128 del ASCII. En los demás casos, se utilizan de 2 a 4 butes. El bit más signifiactivo de todos los bytes de esta cadena es siempre 1, para prevenir la confusión con los caracteres de 7-bits del ASCII, particularmente los caracteres menores a 32dec, tradicionalmente llamados caracteres de control.
000000 - 00007F
0xxxxxxx
rango equivalente en ASCII; byte empieza con cero
000080 - 0007FF
110xxxxx 10xxxxxx
primer byte empieza con 110 o 1110, el siguiente byte(s) empieza con 10
000800 - 00FFFF
1110xxxx 10xxxxxx 10xxxxxx
010000 - 10FFFF
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
UTF-16 require sustitutos; una compensación de 0x10000 es substraída, así el bit patrón no es idéntico con UTF-8
De este modo, los primeros 128 caracteres necesitan un byte. Los siguientes 1920 caracteres necesitan dos bytes para ser codificados. Esto incluye caracteres del Alfabeto Latino con diacríticos, griego, cirílico, cóptico, armenio, hebreo y arábigo. El resto de los caracteres usan tres bytes y caracteres adicionales son codificados con 4 bytes.
Dentro del rango de codificación con tres bytes se encuentran se encuentran el coreano, chino y japonés.
Ahora vamos a hablar de la integración de UTF-8 dentro de Moodle:
Debido a que Moodle precisa de una base de datos para persistencia, y php como intérprete para la lógica del programa, es preciso que ambos soporten UTF-8.
En el caso de MySQL se soporta UTF-8 a partir de la versión 4.1 posterior, en el caso de postgres a partir de la versión 8.1. El caso más complejo parce ser con PHP ya que internamente utiliza ISO-8859-1 para codificar los strings, si bien dispone de funciones como utf8decode() y utf8uncode() a partir de la versión 3. Por tal motivo, a la hora de trabajar con string en PHP, si dichos strings están codificacodos en UTF-8 hay que tener cuidado.
Por ejemplo:
Si contamos el número de caracteres del string Iñtërnâtiônàlizætiøn
En teoria a partir de la versión 6 de PHP se soportará nativamente la cosificación UTF-8.
Pero que hacemos mientras tanto? Pasarle el problema al navegador, y decirle al navegador que todo está codificado con UTF-8. Esto se hace informando en la cabecera http la codificación a emplear de la siguiente manera dentro de un tag meta:
http-equiv="Content-Type" content="text/html; charset=utf-8"
Esto resuelve la mayoria de los problemas, aunque no todos.
Luego de este inciso, volvemos a Moodle. Si la base de datos los soporta, al instalar una versión posterior a 1.6 ya dispondremos de codificaión UTF-8. En caso de migrar desde una versión anterior de Moodle, si la base de datos lo soporta se migrará a UTF-8. en el futuro es posible que sea un requisito disponer de una versión de base de datos con soporte UTF-8.
Con esto quiero decir que si el sistema lo soporta y se tienen instalado Moodle 1.6 o superior, el "kernel" de moodle ya funcionará con UTF-8.
Otro tema son los módulos no oficiales. Moodle ha informado el proceso para que los desarrolladores de modulos no oficiales puedan migrar las tablas que precisen para que se codifique la información en UTF-8. En el caso que nos ocupa a nosotros este trabajo ya está hecho, y puede apreciarse en el archivo migrate2utf8.xml donde se informa que campos deben convertirse y en el archivo migrate2utf8.php que define cono debe hacerse la conversión. Ambos archivos se encuentran en la carpeta /moodle/mod/wiki/db.
Conclusión:
Si el sistema lo soporta y está bien configurado se puede trabajar perfectamente con Moodle y las Wiki´s utilizando codificación UTF-8.
smile
Links de interés sobre este tema:
http://www.unicode.org/standard/principles.html
http://www.phpwact.org/php/i18n/charsets?s=utf8
http://docs.moodle.org/en/UTF-8_contrib
http://textpattern.net/wiki/index.php?title=Unicode_Support#UTF-8_Support_in_MySQL
http://www.phpwact.org/php/i18n/charsets%23common_problem_areas_with_utf-8
http://es.php.net/strings
Que es UTF-8? Las siglas corresponden a Unicode Transformation Format, y es un sistema de codificación variable del sistema de mapeo de caracteres de Unicode.
A continuación se detalla la información técnica extraida de wikpedia:
Los caracteres más pequeños que 128dec son codificados con un byte sencillo que contiene su valor: este corresponde exactamente a los caracteres de 7 bits de los 128 del ASCII. En los demás casos, se utilizan de 2 a 4 butes. El bit más signifiactivo de todos los bytes de esta cadena es siempre 1, para prevenir la confusión con los caracteres de 7-bits del ASCII, particularmente los caracteres menores a 32dec, tradicionalmente llamados caracteres de control.
000000 - 00007F
0xxxxxxx
rango equivalente en ASCII; byte empieza con cero
000080 - 0007FF
110xxxxx 10xxxxxx
primer byte empieza con 110 o 1110, el siguiente byte(s) empieza con 10
000800 - 00FFFF
1110xxxx 10xxxxxx 10xxxxxx
010000 - 10FFFF
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
UTF-16 require sustitutos; una compensación de 0x10000 es substraída, así el bit patrón no es idéntico con UTF-8
De este modo, los primeros 128 caracteres necesitan un byte. Los siguientes 1920 caracteres necesitan dos bytes para ser codificados. Esto incluye caracteres del Alfabeto Latino con diacríticos, griego, cirílico, cóptico, armenio, hebreo y arábigo. El resto de los caracteres usan tres bytes y caracteres adicionales son codificados con 4 bytes.
Dentro del rango de codificación con tres bytes se encuentran se encuentran el coreano, chino y japonés.
Ahora vamos a hablar de la integración de UTF-8 dentro de Moodle:
Debido a que Moodle precisa de una base de datos para persistencia, y php como intérprete para la lógica del programa, es preciso que ambos soporten UTF-8.
En el caso de MySQL se soporta UTF-8 a partir de la versión 4.1 posterior, en el caso de postgres a partir de la versión 8.1. El caso más complejo parce ser con PHP ya que internamente utiliza ISO-8859-1 para codificar los strings, si bien dispone de funciones como utf8decode() y utf8uncode() a partir de la versión 3. Por tal motivo, a la hora de trabajar con string en PHP, si dichos strings están codificacodos en UTF-8 hay que tener cuidado.
Por ejemplo:
Si contamos el número de caracteres del string Iñtërnâtiônàlizætiøn
echo strlen('Iñtërnâtiônàlizætiøn');
Obtendremos 27 caracteres debido a que php strlen cuenta el número de bytes sin tener encuenta que en UTF-8 se utilizan los bits de inicio de cada byte para informar la longitud de bytes correspondiente al caracter codificado.En teoria a partir de la versión 6 de PHP se soportará nativamente la cosificación UTF-8.
Pero que hacemos mientras tanto? Pasarle el problema al navegador, y decirle al navegador que todo está codificado con UTF-8. Esto se hace informando en la cabecera http la codificación a emplear de la siguiente manera dentro de un tag meta:
http-equiv="Content-Type" content="text/html; charset=utf-8"
Esto resuelve la mayoria de los problemas, aunque no todos.
Luego de este inciso, volvemos a Moodle. Si la base de datos los soporta, al instalar una versión posterior a 1.6 ya dispondremos de codificaión UTF-8. En caso de migrar desde una versión anterior de Moodle, si la base de datos lo soporta se migrará a UTF-8. en el futuro es posible que sea un requisito disponer de una versión de base de datos con soporte UTF-8.
Con esto quiero decir que si el sistema lo soporta y se tienen instalado Moodle 1.6 o superior, el "kernel" de moodle ya funcionará con UTF-8.
Otro tema son los módulos no oficiales. Moodle ha informado el proceso para que los desarrolladores de modulos no oficiales puedan migrar las tablas que precisen para que se codifique la información en UTF-8. En el caso que nos ocupa a nosotros este trabajo ya está hecho, y puede apreciarse en el archivo migrate2utf8.xml donde se informa que campos deben convertirse y en el archivo migrate2utf8.php que define cono debe hacerse la conversión. Ambos archivos se encuentran en la carpeta /moodle/mod/wiki/db.
Conclusión:
Si el sistema lo soporta y está bien configurado se puede trabajar perfectamente con Moodle y las Wiki´s utilizando codificación UTF-8.
smile
Links de interés sobre este tema:
http://www.unicode.org/standard/principles.html
http://www.phpwact.org/php/i18n/charsets?s=utf8
http://docs.moodle.org/en/UTF-8_contrib
http://textpattern.net/wiki/index.php?title=Unicode_Support#UTF-8_Support_in_MySQL
http://www.phpwact.org/php/i18n/charsets%23common_problem_areas_with_utf-8
http://es.php.net/strings
Problemas con apostrofes y barras invertidas (slash)
cuando se hace un click en un nombre de página wiki, se verifica que la página exista. Si existe, se muestra la pestaña view de dicha página. en caso contrario se muestra la pestaña del editor.
El problema ocurre cuando un nombre de página contiene caracteres con la barra invertida o apóstrofe, ya que para verificar si dicha página existe se llama a la función wiki_record_exists(). Si en la llamada no se hace un tratamiento adecuado al nombre de página enviado como parámetro, la consulta se crea incorrectamente y aún cuabdo la página existe en lugar de mostrarse la pestaña view se muestra la pestaña edit.
Este problema ocurre también con el bloque de sinonimos (aunque el procedimiento puede ser diferente, es decir, falta ver que función es la que se encarga de verificar si la página existe).
Habría que revisar las llamadas relacionadas con estos fallos y pasar adecuadamente los parámetros. Seguramente falta utilizar la función de php addslashes sobre el nombre de página antes de pasarlo como parámetro.
Se observa que sin embargo, en el caso de un curso con formato wiki, el comportamiento es correcto (aunque los nombres de lapáginas se muestran mal, es decir, con la barra invertida precediento dichos caracteres). Seguramente se debe a que la página que se carga en el caso de ver una wiki integrada a un curso es view.php del directorio moodle/course, mientras que al ver un wiki desde fuera de la página principal de un curso se hace cargando la página view.php dentro de moodle/mod/wiki
El problema ocurre cuando un nombre de página contiene caracteres con la barra invertida o apóstrofe, ya que para verificar si dicha página existe se llama a la función wiki_record_exists(). Si en la llamada no se hace un tratamiento adecuado al nombre de página enviado como parámetro, la consulta se crea incorrectamente y aún cuabdo la página existe en lugar de mostrarse la pestaña view se muestra la pestaña edit.
Este problema ocurre también con el bloque de sinonimos (aunque el procedimiento puede ser diferente, es decir, falta ver que función es la que se encarga de verificar si la página existe).
Habría que revisar las llamadas relacionadas con estos fallos y pasar adecuadamente los parámetros. Seguramente falta utilizar la función de php addslashes sobre el nombre de página antes de pasarlo como parámetro.
Se observa que sin embargo, en el caso de un curso con formato wiki, el comportamiento es correcto (aunque los nombres de lapáginas se muestran mal, es decir, con la barra invertida precediento dichos caracteres). Seguramente se debe a que la página que se carga en el caso de ver una wiki integrada a un curso es view.php del directorio moodle/course, mientras que al ver un wiki desde fuera de la página principal de un curso se hace cargando la página view.php dentro de moodle/mod/wiki
Problema con el módulo social activities en cursos en formato wiki
Se detecta un error con la integración del módulo wiki y el bloque social activities. Se envía correo a Marc para que nos indique como proceder.
A continuación se informa sobre dicho error:
Al crear un curso con formato wiki, por defecto se cargan una serie de bloques, y uno de ellos es el de "social activities".
Al borrar la instancia del bloque "social activities" (usando el icono de una cruz) ya no se pueden crear nuevas actividades sociales, dentro de las cuales se encuentran las wikis.
Hasta aquí ok, ya que si se borra el bloque por algo será, pero hay un fallo, o así lo entiendo yo. Y es que si se quiere volver a activar el bloque "social activities" no es posible, ya que en el bloque "blocks" no aparece la opción para crear una nueva instancia de "social activities". Este comportamiento solo ocurre con este bloque, no ocurre con ningún otro bloque, ni los que se cargan por defecto al crear un curso ni los que se pueden añadir posteriormente.
Por otro lado, en los demás formatos de curso si se borra dicho bloque se puede volver a crear.
En un curso con formato wiki, la única manera de volver a disponer de "social activities" es creando una entrada a mano en la tabla mdl_block_instances.
Creo que este comportamiento es incorrecto en un curso con formato wiki, ya que a partir del momento en que no es posible añadir nuevas actividades sociales se limita enormemente el potencial del curso.
Investigando he descubierto que el problema es que los bloques definen en que formatos de curso pueden visualizarse en el bloque "blocks".
En el caso del bloque "social activities" el formato de curso "course-view-wiki" no es un formato válido.
Para solucionarlo habría que hablar con el responsable del bloque social activities para que modifique el siguiente código:
function applicable_formats() {
return array('course-view-social' => true, );
}
por el siguiente:
function applicable_formats() {
return array('course-view-social' => true, 'course-view-wiki' => true);
}
Nota: Los demás bloques no tienen este problema ya que la función applicable_formats() retorna array('all' => true);
A continuación se informa sobre dicho error:
Al crear un curso con formato wiki, por defecto se cargan una serie de bloques, y uno de ellos es el de "social activities".
Al borrar la instancia del bloque "social activities" (usando el icono de una cruz) ya no se pueden crear nuevas actividades sociales, dentro de las cuales se encuentran las wikis.
Hasta aquí ok, ya que si se borra el bloque por algo será, pero hay un fallo, o así lo entiendo yo. Y es que si se quiere volver a activar el bloque "social activities" no es posible, ya que en el bloque "blocks" no aparece la opción para crear una nueva instancia de "social activities". Este comportamiento solo ocurre con este bloque, no ocurre con ningún otro bloque, ni los que se cargan por defecto al crear un curso ni los que se pueden añadir posteriormente.
Por otro lado, en los demás formatos de curso si se borra dicho bloque se puede volver a crear.
En un curso con formato wiki, la única manera de volver a disponer de "social activities" es creando una entrada a mano en la tabla mdl_block_instances.
Creo que este comportamiento es incorrecto en un curso con formato wiki, ya que a partir del momento en que no es posible añadir nuevas actividades sociales se limita enormemente el potencial del curso.
Investigando he descubierto que el problema es que los bloques definen en que formatos de curso pueden visualizarse en el bloque "blocks".
En el caso del bloque "social activities" el formato de curso "course-view-wiki" no es un formato válido.
Para solucionarlo habría que hablar con el responsable del bloque social activities para que modifique el siguiente código:
function applicable_formats() {
return array('course-view-social' => true, );
}
por el siguiente:
function applicable_formats() {
return array('course-view-social' => true, 'course-view-wiki' => true);
}
Nota: Los demás bloques no tienen este problema ya que la función applicable_formats() retorna array('all' => true);
Reunión semana 3
Se deja de lado de momento el tema de la importación de wiki´s.
Se nos solicita que demos prioridad al tema de investigar la codificación UTF-8 para permitir la creación de páginas wiki´s con nombres de página en idiomas orientales.
Se define el marco de colaboración mediante el CVS de sourceforge. Durante la próxima semana subiremos las mejoras a dicho repositorio y actualizaremos el tracker de moodle.
Se nos solicita que demos prioridad al tema de investigar la codificación UTF-8 para permitir la creación de páginas wiki´s con nombres de página en idiomas orientales.
Se define el marco de colaboración mediante el CVS de sourceforge. Durante la próxima semana subiremos las mejoras a dicho repositorio y actualizaremos el tracker de moodle.
Import de wiki´s
Durante la semana hemos comenzado a analizar el funcionamiento de los imports y backups de las wiki´s. Como efectivamente presuponiamos, nos está costando bastante comprender su funcionamiento. Tenemos que hacer varias preguntas a Pigui...
Otro apartado en el que hemos profundizado, es en el conocimiento del funcionamiento interno de moodle así como de php. Se aprovechó este nuevo conocimiento para mejorar el código de la funcionalidad de cambiar el tamaño del editor wiki y el bug del link roto.
Estamos avanzando en la modificación de la nueva pantalla de evaluación, a la que incorporaremos nuevas funcionalidades de navegación y un nuevo formato.
Otro apartado en el que hemos profundizado, es en el conocimiento del funcionamiento interno de moodle así como de php. Se aprovechó este nuevo conocimiento para mejorar el código de la funcionalidad de cambiar el tamaño del editor wiki y el bug del link roto.
Estamos avanzando en la modificación de la nueva pantalla de evaluación, a la que incorporaremos nuevas funcionalidades de navegación y un nuevo formato.
Reunión semana 2
Se informó al resto del grupo que ya habíamos resuelto las dos primeras tareas asignadas.
A partir de esta semana comenzamos a analizar el sistema de importación. Mi intuición me dice que en con este tema nos vamos a divertir.
mixed.
Adicionalmente Marc nos asignó una nueva tarea: Modificar el diseño de la página de grades. MDL-6569
A partir de esta semana comenzamos a analizar el sistema de importación. Mi intuición me dice que en con este tema nos vamos a divertir.
mixed.
Adicionalmente Marc nos asignó una nueva tarea: Modificar el diseño de la página de grades. MDL-6569
Modificar el tamaño del editor Wiki
Nuestra primera tarea !!!!!!!!!
En principio parece algo sencillo, pero con nuestros rudimentarios conocimientos de php, encontrar las páginas que era necesario modificar para el desarrollo correcto de la funcionalidad, ha sido una ardua tarea.
Como aspecto positivo cabe destacar que nos permitió profundizar en la estructura de la nwiki.
Otro aspecto a mencionar es que la definición de la tarea a realizar no era muy extensa, y considerando nuestra poca experiencia en el mundo moodle. Tuvimos que aplicar el sentido común y tomar decisiones como en que tabla guardar los campos que hagan persistente el nuevo tamaño, o si el tamaño se debía poder definir para cada página de una wiki en particular, o para todas las páginas de una wiki determinada.
Como breve resumen, el desarrollo de la funcionalidad hizo preciso modificar los siguientes archivos:
En principio parece algo sencillo, pero con nuestros rudimentarios conocimientos de php, encontrar las páginas que era necesario modificar para el desarrollo correcto de la funcionalidad, ha sido una ardua tarea.
Como aspecto positivo cabe destacar que nos permitió profundizar en la estructura de la nwiki.
Otro aspecto a mencionar es que la definición de la tarea a realizar no era muy extensa, y considerando nuestra poca experiencia en el mundo moodle. Tuvimos que aplicar el sentido común y tomar decisiones como en que tabla guardar los campos que hagan persistente el nuevo tamaño, o si el tamaño se debía poder definir para cada página de una wiki en particular, o para todas las páginas de una wiki determinada.
Como breve resumen, el desarrollo de la funcionalidad hizo preciso modificar los siguientes archivos:
- moodle/mod/wiki/mod.htm
- moodle/mod/wiki/lib.php
- moodle/mod/wiki/loacllib.php
- moodle/mod/wiki/version.php
- moodle/mod/wiki/db/mysql.php
- moodle/mod/wiki/db/mysql.sql
- moodle/mod/wiki/editor/editor.php
- moodle/lang/en_utf8/wiki.php
- editorrows integer not null default=40
- editorcols integer not null default=120
Debido a que esta tarea ha sido nuestra primera aproximación seria a la newWiki, le hemos solicitado a Pigui que verfique que como mínimo no hacemos ningún desastre antes de ofrecer la nueva funcionalidad a la comunidad Moodle.
Link roto en el sistema de evaluación de la newWiki
En el reporte completo de actividades del sistema de evaluación, los links al histórico de las páginas editadas nu funciona. Error: 'Course module is incorrect'
Detectamos el error en la siguiente línea del archivo lib.php
echo ' www.'/mod/wiki/view.php?id=1&page=info/'.$page->pagename.'&editor='.$page->editor.'&gid=0>'.$page->pagename.
Que solucionamos modificando el id=1 cambiándolo por id='.$mod->id.
Otro error que encontramos es que cuando el nombre de la página contenía un carácter en blanco, el link se formaba mal. Para solucionar este error introducimos la siguiente línea antes de crear el link:
$pageok =str_replace(" ","+",$page->pagename);
Utilizando luego la variable $pageok en lugar de $page->pagename.
Detectamos el error en la siguiente línea del archivo lib.php
echo ' www.'/mod/wiki/view.php?id=1&page=info/'.$page->pagename.'&editor='.$page->editor.'&gid=0>'.$page->pagename.
Que solucionamos modificando el id=1 cambiándolo por id='.$mod->id.
Otro error que encontramos es que cuando el nombre de la página contenía un carácter en blanco, el link se formaba mal. Para solucionar este error introducimos la siguiente línea antes de crear el link:
$pageok =str_replace(" ","+",$page->pagename);
Utilizando luego la variable $pageok en lugar de $page->pagename.
Reunión semana 1
Comienza oficialmente el proyecto.
El grupo se estructura en 4? equipos de dos personas, trabajando con el método ágil de desarrollo de software.
El tutor de todos nosotros, Marc Alier, ejerce el rol de gestor de proyectos y contamos con la inestimable ayuda de varios colaboradores que ya han finalizado su proyecto también sobre Moodle. Entre estos colaboradores se encuentra Jordi Piguillem, Pigui.
Uno de los asuntos tratados es el estado de desarrollo de moodle. Actualmente la versión estable es la 1.6. Sin embargo en paralelo hay una versión beta sobre 1.7, que será estable en uno o dos meses. Lo más importante es que una vez sea declarada estable la versión 1.7, y comience el desarrollo de la versión 1.8 beta, el módulo nwiki pasará a formar parte de los módulos oficiales de Moodle. Esta coyuntura hace que principalmente deberemos dedicarnos a la solución de errores y documentación, dedicándole menos energía al desarrollo de nuevas funcionalidades.
En cuanto a los equipo, junto con Juan Luis Paton formamos uno de los tres grupos, y se nos asignan las sguientes tareas:
El grupo se estructura en 4? equipos de dos personas, trabajando con el método ágil de desarrollo de software.
El tutor de todos nosotros, Marc Alier, ejerce el rol de gestor de proyectos y contamos con la inestimable ayuda de varios colaboradores que ya han finalizado su proyecto también sobre Moodle. Entre estos colaboradores se encuentra Jordi Piguillem, Pigui.
Uno de los asuntos tratados es el estado de desarrollo de moodle. Actualmente la versión estable es la 1.6. Sin embargo en paralelo hay una versión beta sobre 1.7, que será estable en uno o dos meses. Lo más importante es que una vez sea declarada estable la versión 1.7, y comience el desarrollo de la versión 1.8 beta, el módulo nwiki pasará a formar parte de los módulos oficiales de Moodle. Esta coyuntura hace que principalmente deberemos dedicarnos a la solución de errores y documentación, dedicándole menos energía al desarrollo de nuevas funcionalidades.
En cuanto a los equipo, junto con Juan Luis Paton formamos uno de los tres grupos, y se nos asignan las sguientes tareas:
Suscribirse a:
Entradas (Atom)