Modificar atributo de elp mediante utilidad eXe_do

Hola,

Creo que la utilidad no está preparada para acceder al tipo de datos complejo que es el objeto LOM-ES. Aunque cuelga de package y se puede acceder a estructuras complejas usando . (por ejemplo root.title=”prueba” que cambiaría el título de un nodo) el objeto LOM-ES contiene diccionarios según veo en el contentv3.xml.

A bote pronto creo que habría que implementar el operador [] además del operador . en el parseador de exe_do.

Un  saludo.

Hola

Hace tiempo le hice a tu compañero Rafa una utilidad en python que servía para lanzar cambios masivos en proyectos, aunque ahora mismo no recuerdo exactamente lo que hacía :-). Coméntale si lo que pretendéis es algo similar y/o pídele aquel script para echarle un ojo.

Si no das con Rafa pásanos un ejemplo de elp sin modificar y el modificado.

un saludo

Otra posible vía sería (requiere desarrollo):

1) Exportar los metadatos LOM-ES

2) Modificar el archivo .xml

3) Importar los metadatos

No me acabo de aclarar de si serviría lo siguiente:

un script desde consola que lanzado sobre una carpeta con ficheros elp los abra uno a uno, edite sus contentv3.xml y, dentro de la sección dictionary,  sustituya la línea:

<string value=”mda”></string>

por:

<string value=”texto_a_escribir_por_el:usuario “></string>

o sobre elps por separado…

(estoy hablando de la opción  2 de Josemi)

un saludo

Hola Antonio:

El procedimiento que describes debería funcionar, pero es importante saber que, modificar el archivo contentv3.xml desde un script de sustitución de textos tiene sus riesgos y sus limitaciones. Por ejemplo, puede que ese texto se encuentre en otras partes del archivo, por lo que modificaríamos más cosas de las deseadas, o puede que ya hubiera otras palabras clave, por lo que el script no encontraría la cadena <string value=”mda”></string>. Además, el formato del archivo contentv3.xml es muy flexible para poder albergar los datos de los diferentes apartados de eXe pero a la vez, bastante complejo para ser interpretado a simple vista.

La solución ideal viene por la vía propuesta por Pedro. Lo que yo he propuesto, sólo sería posible si existe una exportación/importación de metadatos LOM accesible desde exe_do. Tendríamos los mismos posibles problemas descritos antes, pero el formato LOM-ES es más legible y el riesgo de modificar algo indebido estaría acotado a los metadatos.

Hola:

¿Se ha valorado la posibilidad de tener los metadatos LOM-ES en un fichero aparte?

Saludos.

Hola Rafa,

ya lo están: SCORM permite incluirlos textualmente en el manifiesto o referenciar a un fichero que los incluya: esto es lo que hacemos: actualmente lo denominamos imslrm.xml (adjunto uno de ejemplo), ese es el fichero que se rastrearía.

• This reply was modified Hace 10 años, 6 meses by  .

Vaya, me explico mal, mejor empiezo por el final 🙂 y perdón si digo cosas obvias:

Haz esto: exporta un elp cualquiera como paquete SCORM1.2 ó 2004 -o IMSCP y observa el fichero ZIP que se genera, ahí aparecerán, entre otras cosas, un fichero imsmanifest.xml  y un imslrm.xml. El primero, el llamado manifiesto, incluye información necesaria del proyecto para su correcto tratamiento desde gestores de contenidos tipo moodle etc. Si editas el manifiesto verás que entre etiquetas <metadata>….</metadata> tiene la referencia al fichero imslrm.xml, generado también en la exportación. Quiero decir que el fichero que incluye los metadatos YA se está generando en el momento en que generas el empaquetado del proyecto.

Por eso reeditar ese fichero no es complejo, implementar un modo de generarlo ajeno al proceso de exportación tampoco lo es; el tema es que realmente entiendo que imslrm.xml no nos sirve para nada más que para que los gestores de contenidos se entiendan con el paquete, pero modificar ese fichero NO modifica los metadatos en el el elp EN SÍ. Por tanto nuestro gozo en un pozo salvo que el objetivo último de vuestros proyectos modificados fuera siempre un gestor de contenidos…

Poco a poco…

Hola Antonio:

Muy interesante la vía que propones con el archivo imslrm.xml. Tal y como cuentas, ese archivo es referenciado desde el imsmanifest.xml para que los repositorios clasifiquen el paquete. Si se modifica el archivo, luego se puede importar desde el menú de exe (nueva opción de eXe20). He hecho esta prueba:

1) En un paquete existía la palabra clave AAAA

2) Exportar a SCORM

3) Descomprimir

4) Abrir con un editor de texto el archivo imslrm.xml

5) Buscar lo siguiente: <keyword><string language=”es”>AAAA</string></keyword>

6) Si queremos añadir la palabra clave BBBB, hay que sustituirlo por <keyword><string language=”es”>AAAA</string></keyword><keyword><string language=”es”>BBBB</string></keyword>

7) Importar el archivo de metadatos desde el menú de eXe (nueva opción de eXe20)

Este último paso es el que no creo que está disponible desde exe_do

¡Un saludo!

Hola Belén:

Tal y como has comprobado, la opción de exportación/importación a xml existente en exe_do exporta/importa el achivo contentv3.xml, es decir, el archivo que contiene TODA la información del paquete. Sobre ese archivo puedes hacer las modificaciones que consideres oportunas, pero debes tener especial cuidado con lo que haces, ya que el tamaño y formato del mismo hace que sea posible cometer errores.

A modo de resumen del hilo, tenemos 3 opciones:

1) Exportar a xml, modificar el archivo contentv3.xml e importar: esta vía es viable desde eXe o desde exe_do. Hay que tener especial cuidado con el script de manipulación del archivo contentv3.xml

2) Exportar a SCORM, modificar el archivo imslrm.xml e importar metadatos: esta vía es viable desde exe pero no desde exe_do (a día de hoy no tiene la importación de metadatos). El desarrollo del script de sustitución de cadenas en imslrm.xml es más sencillo y los posibles errores son menos peligrosos.

3) La vía propuesta por Pedro: mejorar las rutinas de gestión de propiedades para poder hacer los cambios desde exe_do y no con un editor de texto. Es la vía ideal ya que manipulamos las propiedades con garantías, pero requiere más desarrollo.

¡Un saludo!