Inicio › Forums › Desarrolladores / Desenvolupadors / Garatzaileak / Desenvolvedores / Developers › nuevos idevices
This topic contains 23 respuestas, has 7 voices, and was last updated by Ignacio Gros Hace 8 años.
-
AuthorEntradas
-
7 junio, 2012 at 22:06 #474
Hola,
Estuve construyendo un idevice , la intención era que me sirviera para conocer la estructura de exelearning, y exploré tres posibilidades:
1.- Añadí una opción al idevice de huecos para que el autor pudiera elegir entre escribir ( como ahora ) o una lista desplegable con las palabras ocultas. No es un idevice nuevo, sino una nueva opción.
2.- Construí un idevice de lista desplegable a partir de clozeidevice ( huecos ) , con las nuevas clases en element y field
3.- Construí el mismo idevice pero independiente, sin modificar element ni field . Creo que es una buena opción para añadir idevices sin modificar otros archivos, pero desvirtúa la estructura actual de exelearning.
Que opinais sobre el punto 3? ( las clases que normalmente irían en element y field , colocarlas en el propio idevice)
Sólo es una prueba, no está 100% depurada.
Archivos adjuntos:
You must be logged in to view attached files. -
8 junio, 2012 at 8:03 #480
AnónimoHola Fran,
En principio en desarrollo, en pruebas, tenemos ya que eXe incluye la opción de agregar y eliminar idevices por menús, no sólo los que son variantes de los cuatro básicos (que ya se pueden importar/exportar como idp) sino cualquier idevice.
En las pruebas realizadas esos idp deben venir con los dos dos módulos python (no son necesarios los compilados) y los tres content (data, sxd y xml). Te adjunto uno de ejemplo, creado desde eXe exportando uno de los de FP.
Ciertamente esto aún se puede cambiar, si lo vemos conveniente.
Acerca de si es mejor sustituir un idevice existente por una versión mejorada o si incorporarlo como uno nuevo… opino que si es obviamente una versión mejorada de uno preexistente simplemente sustituiría el viejo por el nuevo, sin complejos, es igual y mejor?, pues a actualizar. Podemos aprender de la cierta confusión en los usuarios “no FP” cuando ven idevices muy similares… Otro tema sería si ciertamente no es mejor, sino diferente. Recuerda que, por lo dicho más arriba, se dispondrá de un repositorio de idevices.
No soy hacedor experimentado de actividades, así que acerca de si lo vería como una mejora o como “otra cosa diferente” lo dejo a otra gente.
A mí en principio me suena genial lo que has hecho.
Un saludo -
8 junio, 2012 at 8:20 #481
Anónimopues que graciosa la seguridad…. a ver este adjunto, he renombrado el .idp como .zip; si sube lo tendrás que renombrar de nuevo.
Archivos adjuntos:
You must be logged in to view attached files. -
8 junio, 2012 at 8:49 #483
Hola,
Y si son necesarias nuevas clases en element y field? En el ejemplo que me envías no se necesitan nuevas clases, porque hace uso de las que ya existen.
-
11 junio, 2012 at 7:17 #484
AnónimoEs obvio que de entrada lo deseable es que un nuevo idevice haya podido hacerse autosuficiente (todas sus necesidades cubiertas en sus dos múdulos **idevice.py y *block.py), pero como sabemos puede ser mucho más operativo modificar módulos como los que comentas (field, element etc.).
Desde eXe se tiene hoy (junio 2012) en pruebas el código que permite agregar o eliminar idevices “de verdad”, no sólo los que son combinaciones de los 4 básicos. Para no ser necesario ser el administrador del ordenador donde se pretenda la instalación de un nuevo idevice, ésta se realiza en el directorio personal en el usuario. Ahora eXe buscará idevices en su propio código Y en ese directorio personal. Esto saldrá próximamente.
Esta nueva funcionalidad impone el compromiso de mantener un repositorio de idevices instalables.
En principio consideramos los 18 idevices originales como un buen surtido de herramientas, debiera ser la dotación de serie. Son el tiempo y las demandas de los usuarios quienes irán provocando cambios, de los 18 válidos cuando se inició el desarrollo de eXe es natural que alguno vaya cayendo en desuso y otros vayan apareciendo.
Desde eXeLearning.net sólo hay una manera de trabajar: cuando se decide adoptar una posible mejora o funcionalidad se hace con todas las consecuencias. Sean idevices o no. Si un nuevo device es considerado valioso por la comunidad y sus creadores lo hacen disponible:
– se subirá al repositorio de idevices soportados y su código pasa a integrarse a todos los efectos: si hacen falta nuevas clases en element y en field se modifican también, por supuesto, ¿cómo si no?, otros posibles futuros desarrollos de idevices pueden requirir otros cambios en esos o en otros módulos… y como imaginas es más operativo mantener la vigencia de un sólo field.py que de tantos como nuevos idevices puedan surgir.
– se incorporarán en el código de eXe las traducciones de sus cadenas de texto
En definitiva un idevice que se incorpore al repositorio debe tener asegurada su carga exitosa. ¿Que no se llega a importar nunca?, no pasa nada, ni al módulo modificado ni a los ficheros de traducciones les va a pasar nada.
En concreto, acerca de las tres opciones que planteas, no entiendo cuando dices que la opción del idevice “autosuficiente” (todo su código en listaidevice.py y listablock.py) desvirtúa la estructura actual. ¿Es clara la conveniencia de modificaciones en módulos transversales como field y element?, pues adelante, asegúrate de que eso no pueda originar problemas en otras funcionalidades, pero si puedes conseguir las mismas funcionalidades sin tocarlos más fácil será de mantener.
Vamos a ir ayudando a probar lo que tienes hecho.
Un saludo -
11 junio, 2012 at 12:27 #486
Hola Fran:
Lo primero darte las gracias por el esfuerzo y el trabajo que has realizado. Ton ha conseguido reproducir el código que has elaborado del idevice y me parece un avance notable ya que era un tipo de actividad que le faltaba a exe. Enhorabuena por ello.
Como dices que es una prueba y que no está al 100% depurada solo te comento dos cosillas que he visto, a ver si a ti también te pasan:
1. El botón de envío no me funciona, no hace nada, no da las respuestas correctas
2. Sería deseable que en los desplegables que genera, las posibles soluciones tengan un orden aleatorio… ¿has pensado en ello?
Pues nada mas, darte la enhorabuena y en exelearning.net estamos todos encantados en poder ayudarte y en darte la bienvenida al proyecto.
Un abrazo
- This reply was modified Hace 12 años, 6 meses by Antonio Monje Fernández.
-
13 junio, 2012 at 12:54 #493
Hola,
Sí , todavía está en desarrollo
Intento que no sea necesario modificar common.js para el tratamiento de las respuestas
Las posibles soluciones están por orden alfabético, no hay problema en desordenarlas. Falta eliminar duplicados y añadir a mayores otros items.
……
-
15 junio, 2012 at 0:30 #524
Hola,
Añadido el control de aciertos y el orden aleatorioArchivos adjuntos:
You must be logged in to view attached files. -
21 junio, 2012 at 10:21 #553
Para no modificar common.js, ¿has probado a definir los archivos necesarios en el *.py del iDevice y a incluir la llamada al JS en el propio HTML generado por el mismo?
self.systemResources += [“mi_js.js”, “mi_imagen.gig”, etc.]oself.systemResources.append(‘mi_js.js’)
Por favor, si lo haces, dinos si funciona.
¡Gracias por la aportación! -
25 junio, 2012 at 16:05 #577
Hola,
Incluir la llamada al javascript es sencillo, pero no conseguí que al exportar se adjuntara el archivo ( no lo copia al temporal ). Ni systemresources ni userresources, tendría que hacer shutil.copyfile.
Al final utilizo las funciones de common.js y no necesito otro archivo.
Hay otra cosa curiosa que desconozco si tiene explicación: algunos html cargan varias veces el archivo common.js, por ejemplo si creas una actividad de huecos, verás que el html carga common.js en la cabecera, pero también dentro del div que corresponde a cada actividad. Es innecesario a menos que exista alguna configuración concreta donde sea conveniente esa redundancia ( ¿existe?)
Archivos adjuntos:
You must be logged in to view attached files. -
26 junio, 2012 at 9:46 #583
Anónimoobserva cómo crean el recurso en appletidevice.py y en attachmentidevice.py:
Resource(self, resourceFile)
(siendo por ejemplo resourceFile = Path(filePath))
Aunque tampoco veo problemas en usar el módulo shutil, no sería la primera vez en eXe. -
12 julio, 2012 at 10:49 #785
Hola Fran:
Hemos probado el idevice que has creado y está genial. Muchas gracias por la aportación. ¿podemos incluirlo en la siguiente versión, citando por supuesto al autor claro ;-)?
Sigues trabajando en alguna otra cosilla. Mantennos informados
Un abrazo
Archivos adjuntos:
You must be logged in to view attached files. -
12 julio, 2012 at 14:37 #789
No hay problema.
Mi intención es crear un iDevice que permita la carga de carpetas y seleccionar un archivo “lanzador”, pero eso supone muchos cambios en la organización de archivos que hace eXeLearning.
Saludos
-
12 julio, 2012 at 15:43 #790
Así es. No tiene sentido que se cargue common.js más de una vez, no. De hecho, sería mejor no hacerlo. Se resolverá lo antes posible; en cuanto empiece la revisión de los iDevices.
-
12 julio, 2012 at 15:57 #791
No parece necesario, pero tendrías que explorar todos los entornos y situaciones para saber si fue un error de los programadores o es necesario en una determinada situación.
En las pruebas que hice no encontré ningún motivo para duplicar ( o triplicar ,…) la carga de common.js .
-
13 julio, 2012 at 7:03 #794
AnónimoConsulta appletidevice.py, gestiona ficheros de muy diversas maneras y puede darte ideas. Cualquier duda ya sabes.
-
13 julio, 2012 at 7:16 #795
AnónimoHola Fran:
Si no eniendo mal tu propuesta, se podría cargar de esa manera elementos estructurados como animaciones que carguen los textos desde archivos .xml en subcarpetas. Sería realmente interesante, porque ahora mismo, para incorporar este tipo de recursos estamos haciendo esto:
- Regenerar el .swf para que llame a un .xml que esté en la misma carpeta y no en una subcarpeta.
- Cargar en exe el swf
- Cargar el .xml mediante un enlace para garantizar su incorporación al paquete
Tu idevice sería muy util pero creo que debería ser sólo un primer paso y que este tema se debería abordar en profundidad, para que sea posible hacerlo desde un botón del editor y así incorporar contenidos estructurados en cualquier idevice. Eso supone replantear a fondo la gestión de archivos.
Mucho ánimo con el idevice y muchas gracias por colaborar. 🙂
-
23 julio, 2012 at 7:18 #845
Hola Fran:
¿Necestas una rama en la forja? ¿Te facilitaría el trabajo?
Un saludo
-
23 julio, 2012 at 8:14 #846
AnónimoHola
Subido el idevice (versión 25 junio) y su carga a la rama jsui en la rev 432.
Un saludo
-
21 abril, 2014 at 12:51 #18395
Buenos dias alguien tendra algun tutorial de como programar IDevices en Phyton? Soy novato disculpen la molestia se los agradeceria mucho 🙂
-
21 abril, 2014 at 12:55 #18396
Hola Edson:
Desarrollos… mira en la forja la guía para unirse al proyecto y cómo crear un idevice: https://forja.cenatic.es/plugins/mediawiki/wiki/iteexe/index.php/P%C3%A1gina_principal
- This reply was modified Hace 10 años, 8 meses by Antonio Monje Fernández.
-
21 abril, 2014 at 13:48 #18398
Antonio Muchas Gracias
-
7 diciembre, 2016 at 17:40 #26614
Buenas, estoy interesado en saber como se crean los idevice desde “0” pero la guía de forja ya no funciona y la de GitHub no la llego a entender ¿Hay alguna guía nueva?
-
14 diciembre, 2016 at 8:04 #26653
Hola jsanchez.
Documentación (en inglés): https://github.com/exelearning/iteexe/wiki/Creating-An-Idevice
Lee también esta respuesta.
De todas formas, estamos trabajando en un sistema para que desarrollar nuevos iDevices sea más sencillo. Se hará con JavaScript. Hay una rama en la que ya está funcionando (javascript-idevices). En esta petición (FR) de GitHub encontrarás una explicación de su funcionamiento.
Avísanos si desarrollas un iDevice nuevo, por favor. Tal vez pueda ser interesante para otros usuarios. La ayuda y las ideas siempre son bienvenidas.
Espero que la información te sirva.
Saludos.
-
AuthorEntradas
You must be logged in to reply to this topic.