Making Optlists
[Note: Ce billet en suite au premier billet d'installation de gRSShopper. Nous attendions de le traduire avant de le publier. Pour le moment, le voici en format original anglais.]
Preparing for the MOOC-REL course I filled in a full set of optlists.
An 'optlist' is the information required to create a dropdown list. These lists create predefine options in the forms people use to create new posts, events, pages, etc.
So, for example, a 'post' might have a field called 'status'. Normally it would just be a plain text field, and you'd type in the name of the type. But it's easier just to select a value from a predefined list. The 'optlist' defines this list.
Administrators can crate optlists by clicking on [New] Optlist in the admin screen(the direct link is http://yoururl/cgi-bin/admin.cgi?db=optlist&action=edit ) and providing the following information:
Table: the name of the table
Field: the name of the field
Data: this is the list of options. It's a structured list: optiontitle,optionvalue;optiontitle2,optionvalue2
Just type out the just. (You can experiment with this to get it right).
For example: Approved,A;On Hold,O;Retired,R
Adding Fields to Tables
Setting up the optlists, I noticed some fields were not updating properly - I would enter the value and it would just disappear when I updated the form. This happens when the field is not defined in the table.
I can add a field to any table using the Database functions. Click on the 'Database' tab in the admin screen and look for 'Manage Database'. Select the table to look at, then select 'Show Columns' from the drop down. This will tell me the names of all the fields in the database.
To add the new field, type the name of the field in the space and select 'Add Column' from the dropdown.
Note all table column field names begin with the name of the table. So, for example, to add a 'title' field to the 'event' table, the name of the field must be 'event_field'. This way, every single field in the database has a unique name.
Note to change the list of fields that will be displayed for any given table in admin.cgi, go to the edit_record() function (it's the content beginning my $showcols = ...). This is hard-coded for now but will one day be part of the general admin screen. You will need to do this if you add a field that wasn't previously defined.
grsshopper.js
I noticed things like the delete buttons were not working. Many of the basic functions (including delete alerts and login status updates are handled by the grsshopper.js Javascript library. The templates were still pointing to the older downes.js I was using previously. So I changed the script include to read src="http://123.45.67.89/assets/js/grsshopper.js"></script>
While I was looking at this I checked the grsshopper.js script. It is supposed to be configured by the installer but that does not always work properly. That was the case here. First, it was an older script. Second, the site information wasn't correctly added.
You can always get a correct up-to-date grsshopper sscript from my website:
http://www.downes.ca/assets/js/grsshopper.js
I downloaded this (you would replace 123.45.67.89 with your own base URL).
Then I reset the values at the top of the script (these are needed to make the 'login' script at the top of the page work properly):
var base_url = "http://123.45.67.89/";
var cgi_url = "http://123.45.67.89/cgi-bin/";
var title_cookie = "123_45_67_89_person_title";
Aucun message portant le libellé gRSShopper. Afficher tous les messages
Aucun message portant le libellé gRSShopper. Afficher tous les messages
mardi 3 décembre 2013
lundi 25 novembre 2013
Tribulations de développement
Dès l’annonce du projet MOOC – REL, certains paramètres de
fonctionnement appartenaient naturellement au projet. Par exemple, il allait de
soi que l’allégeance au modèle connectiviste de l’apprentissage n’était pas
remise en question. L’utilisation de la plateforme libre gRSShopper tombait
sous la même clause. Dans les deux cas, ces orientations viennent de la
direction de projet qui appartient à notre collègue chercheur de renommée
mondiale Stephen Downes.
Mais si Stephen a maintenant plus de cinq ans d’expérience
avec les cMOOC, il n’en va pas de même pour l’équipe de développement du Groupe
des technologies de l’apprentissage (à l’Université de Moncton). Même les
chercheurs du Conseil national de recherches du Canada, collègues de groupe de
Stephen, n’ont pas la même expérience.
Croyant que la flexibilité de gRSShopper nous permettrait de
concevoir une ergonomie d’environnement évoluée et propre au MOOC – REL,
l’équipe du GTA a attaqué le travail de la manière habituelle : analyse de
besoins, étude comparative de produits similaires, carte conceptuelle de site,
maquette fonctionnelle et… Stop! au développement.
Car soudain, on se rend compte que, pour très flexible que soit
gRSShopper, le modèle envisagé demanderait beaucoup de développement, autant
dans l’encodage des fonctions que dans la mise à niveau de la base de données
et de l’interface administrative. Or, dû à la nature du projet (signature de
l’entente au mois de juin, début du travail en juillet 2013 et livraison prévue
en janvier 2014), nous n’avons soudain que très peu de temps de développement
avec une équipe de travail somme toute limitée.
C’est ainsi que de durs choix ont dû être faits la semaine dernière, lors d’une réunion technique mardi. En fin de compte et après mûre
considération, nous avons décidé de déployer gRSShopper comme elle l’est en ce
moment (pour des exemples, voir Compte-rendu du 15 novembre, les quatre liens dans la section "maquette graphique de page principale"), en l’habillant d’occasion et en développant quelques fonctions de base
minimales (comme la connexion par médias sociaux et l’attribution de badges),
en plus bien sûr de traduire la plateforme qui est en anglais.
Pour ceux qui connaissent gRSShopper, il n’y aura pas de dépaysement!
jeudi 7 novembre 2013
Mise-à-jour sur l'implémentation technique
Cela fait maintenant plusieurs semaines que Benoît Lanteigne et moi-même avons commencé à explorer les fonctionnalités de gRSShopper.
gRSShopper est la solution technique qui portera notre MOOC
connectiviste. La principale force de cette plateforme réside dans sa
capacité à agréger de l'information en provenance des différents
participants du cours. Nous pouvons ainsi définir dans un premier temps
une structure pédagogique avec un certain nombre de ressources qui
seront agrémentées dans un second temps par les contributions (billets
de blogs, messages Twitter, commentaires, ressources, etc...) des
participants tout au long du cours.
Dans les semaines qui viennent nous allons devoir clarifier le fonctionnement de l’agrégateur de contenus et finaliser le développement d'une fonctionnalité de badges. Il sera alors temps d'implémenter la charte graphique qui est en cours de conception.
Dans les semaines qui viennent nous allons devoir clarifier le fonctionnement de l’agrégateur de contenus et finaliser le développement d'une fonctionnalité de badges. Il sera alors temps d'implémenter la charte graphique qui est en cours de conception.
mercredi 4 septembre 2013
gRSShopper Set-up Log
Journal d'installation - Application gRSShopper
J'utiliserai ce forum pour décrire, étape par étape, la procédure d'installation de gRSShopper sur le site Web MOOC - RÉL, ceci à la fois pour mon usage personel, mais aussi pour les personnes intéressées.
J'utiliserai ce forum pour décrire, étape par étape, la procédure d'installation de gRSShopper sur le site Web MOOC - RÉL, ceci à la fois pour mon usage personel, mais aussi pour les personnes intéressées.
- Vérifier l'accès SFTP au serveur Web: j'ai ouvert le client Filezilla et testé la connexion SFTP au site Web en utilisant les coordonnées d'accès qui m'ont été transmises. Le test est concluant. J'ai localisé les dossiers Web à /var/www/html and /var/www/cgi-bin
- Vérifier l'accès SSH au serveur Web: j'ai ouvert PuTTY et testé la connexion SSH au serveur Web en utilisant les coordonnées d'accès qui m'ont été transmises (les mêmes que pour SFTP). Le test est concluant. J'ai testé SU avec les mêmes coordonnées d'accès. Cela fonctionne.
- J'ai testé l'accès MySQL avec le mot de passe principal fourni (>mySQL -p). Test concluant.
- Testé le serveur Apache en entrant l'URL ou IP dans une fenêtre de fureteur. Test concluant. J'ai utilisé vi(un éditeur de texte) pour tester la location des pages Web en créant une page Index-test (dans /var/www/html/index.htm pour le cas présent). Ça marche. Modifié le propriétaire et le groupe pour 'apache' et testé de nouveau. Encore bon.
- J'ai créé la base de données gRSShopper sur MySQL. >CREATE DATABASE database; Pour conférer les privilèges d'administrateur à un utilsateur: mysql> GRANT ALL PRIVILEGES ON database.* TO user@localhost IDENTIFIED BY 'password';
- J'ai assigné mon compte utilisateur au groupe apache: >usermod -G wheel,apache myusername et j'ai ensuite changé le propriétaire et le groupe de /var/www/html et /var/www/cgi-bin de 'root' à 'apache'. Ensuite, j'ai donné au groupe 'apache' le droit d'écriture sur cgi-bin: >chmod 775 cgi-bin.
- Créé la base de données pour le cours UMCourse dans gRSShopper à partir de l'archive de cours Change 2011. J'ai exécuté la commande 'archive_cgi.sh' sur downes.ca; ceci crée une archive de la version courante de gRSShopper qui inclut le dossier de données tout juste créé (data pack). [À noter que toute autre personne que moi accéderait la plus récente archive de code - qui contient le paquet de données - à partir de http://sourceforge.net/projects/grsshopper/ ou http://grsshopper.downes.ca/grsshopper_0.52.tar.gz
- J'ai sauvegardé grsshopper_0.51.tar.gz sur downes.ca et je l'ai copié sur le site UdeM dans /var/www/cgi-bin.
- J'ai utilisé PuTTY pour extraire les fichiers: tar -zxvf grsshopper_0.51.tar.gz
- J'ai exécuté le script pour tester le serveur: http://url/cgi-bin/server_test.cgi. Ceci génère une erreur. Pour vérifier le journal d'erreurs: > tail /var/log/httpd/error_log. Le résultat indique: Exec format error. J'ai téléchargé server_test.cgi sur ma machine locale, je l'ai ouvert pour l'éditer et j'ai déplacé la ligne #!/usr/bin/perl tout en haut du fichier (avant même les commentaires). J'ai essayé à nouveau et ça a fonctionné cette fois. J'ai été aussi corriger cette erreur sur downes.ca afin qu'elle ne se reproduise plus à l'avenir.
Ce script teste que les modules nécessaires sont présents. Malheureusement, le script est un peu vieux et il m'indique qu'il manque XML::Feed, XML::Feed OPML, XML::LibXML et Net::OpenID::Consumer. J'ai donc écrit un nouveau script de test de l'environnement serveur pour vérifier la présence des modules Perl pré-requis - pour les intéressés, tous les modules sont chargés par grsshopper.ph load_modules(). J'ai versé ce nouveau script sur downes.ca et aussi sur le site UdeM, donc à l'avenir le script server_test.pl devrait fonctionner beaucoup mieux.
J'ai ensuite exécuté le nouveau script server_test.cgi avec un résultat tout à fait satisfaisant:
gRSShopper web server environment test. Checking PERL version... OK
Checking for CGI. This module handles form input functions. OK
Checking for CGI::Carp. This module displays error messages. OK
Checking for DBI. This module handles database functions. OK
Checking for LWP. This module connects to other web servers. OK
Checking for LWP::UserAgent. This module emulates a web browser. OK
Checking for LWP::Simple. This module emulates a web browser. OK
Checking for File::Basename. This analyzes file names and is used for file uploads. OK
Checking for File::stat. This examines files and is used for file uploads. OK
Checking for HTML::Entities. This encodes and decodes strings with HTML entities. OK
Checking for Scalar::Util 'blessed'. This is a set of useful utilities. OK
Checking for Text::ParseWords. This is used to extract lists of words from strings (ignoring delimiters insider quotes) OK
Checking for Net::Twitter::Lite::WithAPIv1_1. This connects to Twitter and executes the new Twitter API) OK
Checking for Image::Magick. This connects to Twitter and executes the new Twitter API) OK
Checking for DateTime. This converts dates and times) OK
Checking for DateTime::TimeZone. This manages time zone conversions) OK
Checking for Time::Local. This manages local time) OK
Checking for Digest::SHA1 qw/sha1 sha1_hex sha1_base64/. This excrypts passwords and access tokens) OK - J'ai créé un répertoire secret de données dans lequel j'ai placé un fichier nommé 'multisite.txt'. Il s'agit d'un fichier délimité par les espaces Tab contenant les valeurs suivantes: url database_name localhost database_user user_password. Inutile de dire que ce fichier n'est pas inclus avec la distribution gRSShopper. On peut éditer le début de grsshopper.pl pour donner des valeurs spécifiques de base données, définir la location du script multisite.txt au début de grsshopper.pl (sinon il est assigné par défaut à /cgi-bin/data/multisite.txt). À noter, pour utilisation future, que la table capcha est aussi située dans le répertoire de données.
- J'ai exécuté le script d'initialisation avec la commande http://website/cgi-bin/admin.cgi. À noter que ceci redirige à initialize.cgi, mais j'aime l'exécuter ainsi afin de tester admin.cgi et la redirection.
Résultat: 'server error' (*Misère*). Je vérifie de nouveau le journal d'erreurs: 'Error: Can't locate MIME/Types.pm'. Je modifie donc server_test.cgi pour inclure MIME::Types (heh heh). J'ai utilisé CPAN pour installer MIME::Types
J'exécute donc de nouveau le script d'initialisation: http://website/cgi-bin/admin.cgi. Le résultat est celui attendu, c'est-à-dire qu'on obtient le message suivant, en très gros caractères: gRSShopper Initialization - Unable to Access Database. - J'initialise la base de données en cliquant à l'endroit indiqué, et j'obtiens une erreur: "The requested URL /cgi-bin/initialize.cgi was not found on this server." Je modifie le nom de fichier, de /cgi-bin/initialize.cgix à /cgi-bin/initialize.cgi; ceci afin d'éviter que j'exécute par accident le fichier d'initialisation sur mon propre site. Vous voudrez supprimer ce fichier lorsque vous aurez terminé l'installation.
- Étape 1 - Initialisation de la base de données. Vérifier les valeurs dans le formulaire. Je modifie les valeurs du Data Directory (répertoire des données) pour celles de l'emplacement de mon fichier secret de données. Les détails comme les noms et les balises peuvent être modifiés plus tard. Je clique Soumettre.
- Étape 2 - Sélection du dossier de données (data pack). Je sélectionne le dossier de données créé plus tôt. (Note: On peut passer d'un dossier de données à un autre aussi longtemps que la routine initialize.cgi demeure sur sa machine. On peut aussi créer de nouveaux dossiers de données et passer de l'un à l'autre en autant qu'on est très prudent: basculer d'un dossier de données à un autre effacera les données existantes; il faut donc s'assurer de sauvegardrer les données existantes en tant que dossier de données avant de basculer.)
Le dossier de données crée un répertoire et des tables de données pour vous. Il charge aussi Javascript, Image et les fichiers CSS associés à l'installation courante. Ceux-ci deviennent parfois mélangés et il faudra que je répare quelques petits trucs, plus bas. L'installeur n'est pas encore parfait. - Étape 3 - Tester le témoin (cookie) de login. Il me fait grand plaisir de constater que le témoin peut être trouvé avec succès.
L'Installeur crée alors un ID d'usager Admin ainsi qu'un ID d'usager Anonyme. À noter que le mot de passe par défaut n'est pas 'L60iAoNSIza8k' ou quelque chose du genre, mais plutôt 'admin'. Je dois corriger le message de l'installeur ici. - Cliquer le lien pour être ramené à cgi-bin/admin.cgi où vous attendra un message d' erreur et une invitation à vous loguer.
Le lien vers la page de login était mauvais; c'était le lien par défaut (http://www.yoururl.ca/cgi-bin/login.cgi) qui apparaît au début de grsshopper.pl. J'ai corrigé grsshopper.cgi. Maintenant, s'il détecte la location cgi-bin 'yoururl' par défaut (qui est toujours mauvaise), il remplacera cet emplacement par défaut à la location (généralement correcte) url/cgi-bin. Si cette correction ne fonctionne pas pour vous, vous devrez entrer manuellement l'URL du script de login. À noter que vous pouver modifier l'emplacement de vos scripts cgi dans admin.cgi, mais vous ne devriez pas le faire, à moins qu'ils soient bousillés, car vous allez tout foutre en l'air.
Le login ne fonctionne pas comme il faut. Cela est dû au fait qu'on utilsee une URL numérique (e.g. 123.45.67.89). Normalement, le système établit le domaine des témoins (cookies) en laissant tomber la première partie de l'url (p. ex. www.downes.ca donne downes.ca comme domaine), mais ceci ne fonctionne pas pour les domaines en deux sections (e.g. myspace.ca), ni pour les domaines numériques. Il faut vraiment que je corrige cela.
Mais pour l'instant, j'ai édité login.cgi afin qu'il établisse explicitement un domaine pour les témoins. L'entrée est à la ligne 65 - our ($Site,$dbh) = &get_site("page");
# Get Site Information
$Site->{co_host} = "123.45.67.89";
et elle fonctionne bien pour l'instant. - J'ai oublié d'inclure les "boîtes" dans le dossier de données UMCourse, donc il n'y en a aucunes. De plus, toutes les URL des scripts et des CSS sont erronées dans la template, et les données de la page n'ont pas -été sauvegardées. Je ne sais pas pourquoi . Je devrairs peut-être revoir cette section du script d'installation du dossier de données. Je peux cependant manuellement créer les données que je n'ai pas pu importer: je peux créer des boîtes, des pages ainsi que les autres contenus à l'aide de l'interface admin. Dans le cas présent, j'ai simplement copié les boîtes et le contenu des pages du cours change.mooc.ca pour les besoins de la cause!
S'abonner à :
Messages (Atom)