Valery Fremaux

Well, i was trying to have look to it while I fall on a database inconsistency in my development copy maybe dued to XMLDB misinterpretation of the SEQUENCE attribute. I will keep you informed and will send you a full reviewed code, once my own developement module is back to an healthy situation.

Thanks for appreciating the techproject module

Drag and drop should effectively be implemented likely using YUI. It should (?) ensure full compatibility across browsers.

For making objects draggable, following the instructions on YUI docs will result in very few encoding. Obviously using the require_js() function for calling YUI units (injects properly the .js calls within the page head) and just designate the mobile element using something like

<script type="text/javascript">
var dd1 = new YAHOO.util.DDProxy("mobile"); 
</script>

through a proxy or the simpler YUI drag class.

Then should be considered drag-drop feature, which for drop targets must be defined. Drop targets will be kept aware of an element being moved and dropped over them. (I didn't have time from now on to test the scenario practically)

The third thing to consider is "what happens to the information" when dropped over (also should be considered what happens when dragged from). In most cases, this move will "move something", that may match an "action" use case already encoded (or not...) in a more standard way. The result of such a move MUST be reflected on server and in the remote data model. This assumes a drop should send an asynchronous request to the server in order to synchronize client information status change.

This assumes an additional "asynchronous port" is added to the module, as a special php file that can receive such an action request, producing no or little output (just for printing back a status on the move in a DIV prepared for that purpose), a kind of nude controller.

As initiator of the techproject module, I'm obvioulsy interested in your approach and work.

Best regards from Paris (France)
 

Is there any documentation about changing coding strategy for knowing all students or teachers in a course. In other words, what should be the alternative to old (deprecated) get_course_students(), get_course_teachers().

In extention, if some roles are cloned from legacy student and/or teachers, should that alternative be able to keep such users in the student (resp. teacher) list ?

N'aurais tu pas installé le schéduleur sur le cours "portail" ?

C'est effectivement un cas particulier sur lequel je suis resté. Le schéduleur est "pour l'instant" travaillé pour un emploi "dans" un cours moodle explicite. Nous avons un problème de développeur depuis la 1.7, où les procédures pour obtenir les étudiants ou les enseignants d'un cours reposent encore dans les pratiques à ces anciennes fonctions get_course_students() et get_course_teachers(). Elles sont obsolètes mais la procédure légitime est encore floue (pour moi du moins).  J'essaie d'y travailler mais les réponses des H.Q. ne m'ont pas encore pleinement satisfaites.

Je vais m'en enquérir.

Jene sais pas encore par contre si cette erreur est à l'origine des "trous" que tu vois. Je regarde... 

C'est très étonnant. Chez moi, FireFox et IE ont exactement le même comportement.

Hier, j'ai fait qqchose de très bête : j'ai écrit le message pour la création de répertoire et je ne l'ai pas enregistré  

Voilà le message d'hier qui règle le problème de la création de répertoire :

En ligne §20 de mod/flashcard/lib.php :

    filesystem_create_dir($COURSE->id.'/moddata/flashcard/'.$newid, FS_RECURSIVE);

cet ajout permettra en effet de créer le répertoire même si c'est le premier module flashcard du cours (situation banale, je me foutrais des baffes, parfois ).

Nous arrivons au bout. Courage, patience et opiniâtreté (loi imprescriptible du développement logiciel).