Projects
rEve API publique {activityId}/xml

Service :: Détail d'une activité

L'URL permettant d'accéder aux détails d'une activité spécifique se construit sur base de l'identifiant de l'activité; que l'on notera activityId:

{siteUrl}/{activityId}/xml

L'URL de chaque activité récupérée via le service get/activities est incluse dans la réponse de ce service.

Le retour du service de détail d'une activité est illustré ci-dessous.

⚠️ Ceci n'est qu'un exemple: plusieurs variantes des tags illustrés existent (notamment en cas de contenu bilingue) et sont décrits ci-après.

<Activity type="object" id="52897" iid="52897" className="Activity">
 <title>Tennis passion</title>
 <creator>admin</creator>
 <created type="DateTime">2025/05/06 16:17:8.693788 GMT+2</created>
 <modified type="DateTime">2025/05/06 20:42:45.268810 GMT+2</modified>
 <modifier>admin</modifier>
 <summary>Initiation au tennis, par un ancien pro</summary>
 <description>&lt;p&gt;Le tennis s'apprend dès le plus jeune âge. C'est une école de vie, de discipline, de persévérance et de dépassement de soi.&lt;/p&gt;
              &lt;p&gt;C'est un exemple de chemin difficile mais passionnant qui produit bonheur et plaisir.&lt;/p&gt;
              &lt;p&gt;Amateur de padel et autres dérivés du jokari, passe ton chemin.&lt;/p&gt;</description>
 <variety>standard</variety>
 <externalUrl/>
 <internalUrl>http://{siteUrl}/register/activity?id=52897</internalUrl>
 <publicUrl>http://{siteUrl}/52897/view?popup=True&pageLayout=w*aw*center</publicUrl>
 <picture type="file" mimeType="image/png" name="tennis.png">
  <part type="base64" number="1">iVBORw0KGg...</part>
 </picture>
 <languages type="list" count="2">
  <e>fr</e>
  <e>nl</e>
 </languages>
 <capacityDict type="dict">
  <entry type="object">
   <k>62897</k>
   <v type="object" className="Object">
    <capacity type="int">10</capacity>
   </v>
   </entry>
   <entry type="object">
    <k>62898</k>
    <v type="object" className="Object">
     <capacity type="int">10</capacity>
    </v>
   </entry>
 </capacityDict>
 <periodType>normal</periodType>
 <domain>tennis</domain>
 <ageSlice/>
 <minAge type="float">4.0</minAge>
 <maxAge type="float">6.0</maxAge>
 <agePrices type="bool">False</agePrices>
 <pricesPerAge/>
 <schoolLevels/>
 <equipment>Tout est prévu</equipment>
 <registerParents>impossible</registerParents>
 <fiscal type="bool">False</fiscal>
 <insurance type="bool">False</insurance>
 <medical type="bool">False</medical>
 <blockingMedical type="bool">False</blockingMedical>
 <targets type="list" count="1">
  <e type="object" className="Object">
   <url>{siteUrl}/49627/xml</url>
   <id>jeunesse</id>
  </e>
 </targets>
 <tags type="list" count="1">
  <e type="object" className="Object">
   <url>http://{siteUrl}/49594/xml</url>
   <id>sport</id>
  </e>
 </tags>
 <citizenPrice>100 €</citizenPrice>
 <partnerXml>&lt;a&gt; href="https://tennis.passion.sport">Tennis Passion&lt;a&gt;/a&lt;a&gt;</partnerXml>
 <periods type="list" count="2"/>
  <e>{siteUrl}/62897/xml</e>
  <e>{siteUrl}/62898/xml</e>
 </periods>
 <innerPeriods/>
 <placeTitle>Club de tennis M.A.R.S</placeTitle>
 </Activity>

Les sous-sections suivantes donnent tous les détails au sujet de ce type de réponse.

Zones de texte

Chaque activité est décrite par quatre zones de texte :

  • son titre (tag title) ;
  • un résumé (tag summary), zone de texte non formaté mais pouvant s’étendre sur plusieurs lignes ;
  • une description (tag homonyme), plus complète, sous la forme d’une zone de texte riche au format XHTML ;
  • des détails horaires (tag scheduleDetails), sous la forme d'une ligne de texte. Ces détails (non illustrés sur l'exemple ci-dessus) sont optionnels et donnent des précisions sur l’horaire et l’éventuelle récurrence de l’activité.

Si le site rEve est configuré en mode bilingue, pour chacun de ces champs de texte, la structure est plus complexe et inclut les versions dans les deux langues supportées (en général, le français et le néerlandais).

En voici un exemple.

<title type="dict">
 <entry type="object">
  <k>fr</k>
  <v>Activité bilingue</v>
 </entry>
 <entry type="object">
  <k>nl</k>
  <v>Tweetalig activiteit</v>
 </entry>
</title>

Voici un exemple du tag summary en mode bilingue.

<summary type="dict">
 <entry type="object">
  <k>fr</k>
  <v>Résumé ...</v>
 </entry>
 <entry type="object">
  <k>nl</k>
  <v>Overzicht ...</v>
 </entry>
</summary>

Un exemple du tag description en mode bilingue.

<description type="dict">
 <entry type="object">
  <k>fr</k>
  <v><p>Description</p> <p>En <strong>FR</strong></p> </v>
 </entry>
 <entry type="object">
  <k>nl</k>
  <v><p>Descriptie</p> <p>In het <strong>NL</strong></p> </v>
 </entry>
</description>

Et enfin, un exemple du tag scheduleDetails en mode bilingue.

<scheduleDetails type="dict">
 <entry type="object">
  <k>fr</k>
  <v>Un mardi sur deux, de 9h à 10h15</v>
 </entry>
 <entry type="object">
  <k>nl</k>
  <v>On de andere dinsdag, van 09.00 to 10.15 uur</v>
 </entry>
</scheduleDetails>

Ces structures XML sont le résultat du marshalling d’un dictionnaire Python (une table associative).
Notez que, sur certains sites qui auraient activé le bilinguisme seulement à partir d'une certaine date, toute activité dont la date de création serait antérieure à cette date ne disposeront pas de cette structuration bilingue, mais bien de la structuration standard telle que présentée dans l'exemple de base. Dans cette structuration standard, la langue utilisée pour rédiger le contenu des tags peut être soit le français, soit le néerlandais, sans qu’aucun autre élément n’indique de quelle langue il s’agit.
Dès qu’une activité adopte le mode bilingue, outre la structuration plus complexe de certains tags, un tag additionnel nommé languages précise la ou les langues qui seront utilisées lors de l’activité. Ce tag est illustré ci-dessous.

<languages type="list" count="2">
 <e>fr</e>
 <e>nl</e>
</languages>
<language>fr</language>

La plupart du temps, il s'agira d'une liste d'un seul élément, contenant soit fr, soit nl, ou toute autre langue configurée sur le logiciel. Il y a cependant des activités qui se donnent dans plusieurs langues en même temps (en général, 2).

Les exemples ci-dessus sont tous illustrés avec le français et le néerlandais, mais sachez que rEve peut être configuré avec toutes les langues telles que listées dans la norme ISO 639-1.

Type et variété de l’activité

Le type de l’activité, dont les valeurs possibles sont déjà décrites dans le service get/activities, est repris sous le tag periodType (il ne s’appelle pas activityType pour des raisons historiques).

Sa variété est spécifiée via le tag variety. Les valeurs légales de ce dernier tag sont reprises dans le tableau ci-dessous.

Valeur Description
standard
Une activité proposée sur ce site, payante (sauf éventuelles exceptions) et requérant une inscription.
free
Une activité gratuite mais requérant néanmoins une inscription via ce site.
open
Une activité gratuite ne requérant aucune inscription, encodée sur ce site dans l'unique but d'en faire la publicité.
external
Une activité publiée via ce site mais dont l'inscription se fait via un site externe.

Selon la variété, une URL est ou non mise à disposition, permettant de démarrer le processus d’inscription à cette activité via un clic depuis un site externe.

  • Pour les activités de variété « standard » et « free », le tag internalUrl est fourni. Pour toute autre variété, le tag est vide.
  • Pour les activités de variété « external », le tag externalUrl contient l’URL fournie par le site externe via lequel l’inscription peut se réaliser. Pour toute autre variété, ce tag est vide.
  • Pour les activités de variété « open », tant le tag internalUrl qu’externalUrl sont vides.

Publics-cibles et tags

Chaque activité peut être flaggée avec plusieurs publics-cibles (tag nommé targets) et plusieurs tags (tag nommé tags).

Sur l’exemple de base, l’activité s’adresse au public « Jeunesse » et porte sur la thématique représentée par le tag « Sport ».

Deux services distincts vous permettent de récupérer les listes de publics-cibles et tags actuellement activés, donnant, pour chacun, un identifiant et une éventuelle description.

Équipement à apporter

Si l’activité requiert que les participants apportent un matériel quelconque, celui-ci peut être décrit dans le tag equipment. Ce tag, si rempli, contient une chaîne de caractères sans formatage ni passage à la ligne.

Dans le contexte d’une activité au contenu bilingue, le tag equipment l’est également et aura une structuration telle d’illustrée ci-dessous.

<equipment type="dict">
 <entry type="object">
  <k>fr</k>
  <v>Gants, bottes et fichu de travail</v>
 </entry>
 <entry type="object">
  <k>nl</k>
  <v>Handschoenen, laarzen en een werksjaal</v>
 </entry>
</equipment>

Photo ou image

Une photo ou une image illustrant l’activité peut être présente dans le tag picture, structuré comme expliqué dans la page d'introduction à l'API, section Fichiers binaires.

Pour rappel, l’image est découpée en segments, chacun contenant une de ses parties, encodée en Base64. Pour reconstituer l’image, il est plus performant de décoder chaque segment puis de concaténer le résultat dans un objet de type stream. Il se peut que l’image soit d’un autre type que celui de l’exemple ci-dessus (généralement : JPEG, PNG ou GIF).

Périodes et capacités

Une activité est programmée pour survenir lors d’une ou plusieurs périodes. Une période peut représenter :

  • une semaine complète,

  • un intervalle plus réduit, allant jusqu’au jour unique pour un événement ou un excursion ;

  • un intervalle plus vaste, pouvant par exemple représenter une tranche de plusieurs mois, dans le contexte d’activités parascolaires (par exemple, du 1er septembre au 31 décembre).

Chaque période, au sein d'un site rEve, dispose d’un identifiant.

Le tag capacityDict, présent sur chaque activité, contient une double information : la liste des périodes auxquelles l’activité est programmée, ainsi que le nombre de places maximal pour chacune de ces périodes. En voici un exemple.

<capacityDict type="dict">
 <entry type="object">
  <k>49749</k>
  <v type="object" className="Object">
   <capacity type="int">10</capacity>
  </v>
 </entry>
 <entry type="object">
  <k>49756</k>
  <v type="object" className="Object">
   <capacity type="int">15</capacity>
  </v>
 </entry>
</capacityDict>

Dans cet exemple, similaire à l'exemple de base, l’activité est programmée à 2 périodes : la 6035 et la 6037. Pour chacune d’entre elles, le nombre maximum de participants est de 16. Il est le même pour les 2 périodes mais aurait tout aussi bien pu être différent.

Périodes internes et périodes externes

Les périodes associées à une activité peuvent être externes ou internes. Une période externe correspond à une période prédéfinie, standardisée, comme une période de vacances scolaires, qu’il est opportun de définir à l’avance, indépendamment de toute activité. Lors de l’encodage d’une activité, on peut alors sélectionner la ou les périodes externes auxquelles l’activité a lieu. Lorsqu’une activité est liée à une ou plusieurs périodes externes, le tag periods est tel que représenté sur l'exemple de base, repris ci-dessous. Le tag innerPeriods quant à lui, est vide.

<periods type="list" count="2"/>
 <e>{siteUrl}/62897/xml</e>
 <e>{siteUrl}/62898/xml</e>
</periods>
<innerPeriods/>

Il est possible, via une requête HTTP GET supplémentaire, de récupérer des informations détaillées au sujet de chaque période externe. L’URL d’une période, illustrée ci-dessus, se construit sur base de son identifiant numérique (notons-le {ID}). La forme de cette URL est la suivante.

{appURL}/{ID}/xml

Une requête de ce type produit le résultat décrit ici.

Toute activité ne se prête pas facilement au jeu des périodes externes. Une activité représentant un événement, par exemple, définira un ou plusieurs créneaux horaires ou une ou plusieurs plages de dates qui lui sont spécifiques. Dans ce cas, rEve permet de lui définir une ou plusieurs périodes internes, propres à l’activité. Chaque période interne peut représenter un créneau horaire au sein d’une même journée ou, à l’instar des périodes externes, une plage de dates couvrant plusieurs jours. Lorsqu’une activité définit une ou plusieurs périodes internes, voici comment cela se représente.

<periods type="list" count="0"/>
<innerPeriods type="list" count="1">
 <e type="object" className="InnerPeriod">
  <startDate type="DateTime">2024/12/19 09:00:00 GMT+1</startDate>
  <endDate type="DateTime">2024/12/20 21:00:00 GMT+1</endDate>
  <publishDate type="DateTime">2024/04/04 09:00:00 GMT+2</publishDate>
  <publishDatePrivileged/>
  <unpublishDate type="DateTime">2024/12/19 08:00:00 GMT+1</unpublishDate>
  <id>49774:0</id>
  <title>19/12 09:00 → 20/12 21:00</title>
 </e>
</innerPeriods>

Les champs d’une période interne sont similaires à ceux d'une période externe, décrits ici.

Prix

Le prix de l’activité est contenu dans le tag citizentPrice. Dans sa forme la plus simple, il contient uniquement un montant, suffixé du symbole « euro », comme illustré sur l'exemple de base.

<citizenPrice>100 €</citizenPrice>

Le contenu de ce tag peut cependant prendre des formes plus complexes. Si l’activité s’étend sur plusieurs périodes et que le prix n’est pas identique d’une période à l’autre, une précision est indiquée entre parenthèses, comme montré ci-dessous.

<citizenPrice>90 € (70€ pour les semaines du 14/08 au 18/08, du 28/08 au 01/09)</citizenPrice>

Dans cet exemple, il s’agit d’une activité proposée sur diverses semaines de l’été ; parmi celles-ci, il y en a deux pour lesquelles le prix est moindre car l‘activité dure une journée de moins. En effet, le 15 août est férié et le 1er septembre est le jour de la rentrée des classes.
Si des prix dégressifs sont d’application, le contenu les explicite, incorporant également du formatage XHTML, comme illustré ci-dessous.

<citizenPrice>95 € &lt;span class="discreet" style="margin-left:7px"&gt;2e enfant: 85€ - 3e enfant: 75€ - 4e enfant (et suivants): 65€&lt;/span&gt;</citizenPrice>

Dans tous les cas de figure, les prix affichés dans le tag citizenPrice sont ceux payés par les habitants de la zone privilégiée, déterminée par le code postal de l’association ou du pouvoir public gérant le site. Cela permet à ce dernier d’appliquer, s’il le souhaite, une majoration de prix pour les parents habitant en dehors de cette zone.

Restrictions d'accès basées sur l'âge

Pour certains événements ou certaines activités, il se peut qu’une restriction d’accès, généralement basée sur l’âge, soit d’application. Pour chaque type d’activités activé, un modèle d’âge est configuré.
Les modèles d’âge existants sont décrits dans le tableau suivant.

Nom Description
Tranches d’âges fixes Il existe une série de tranches d’âges prédéfinies ; chaque activité du type doit spécifiquement viser une des tranches d’âges en question. Et si on souhaite définir une activité portant sur plusieurs tranches d’âges, le logiciel créera autant d’activités de même titre, une par tranche d’âge.
Tranches d’âges variables Pour chaque activité du type, un âge minimum et un âge maximum doit être encodé.
Niveau scolaire Au lieu de se baser sur l’âge des participants, il s’agit ici de se baser sur leur niveau scolaire. Chaque activité du type utilisant ce modèle doit choisir de s’ouvrir aux participants d’un ou plusieurs des niveaux scolaires tels que définis dans le logiciel.
Aucun Aucun modèle d’âge n’est appliqué : les activités du type configuré de la sorte seront ouvertes à tout participant.

Dans l'exemple, l'activité, via son type normal (stage), applique le modèle "Tranches d'âges variables", avec encodage d'un âge minimum et d'un âge maximum dans les tags minAge et maxAge.

<minAge type="float">4.0</minAge>
<maxAge type="float">6.0</maxAge>

Des nombres réels peuvent être utilisés : un stage peut par exemple être ouverts aux enfants de 2 ans et demi jusqu’à 4 ans.

Pour d'autres types d'activités, notamment parascolaires, c'est le niveau scolaire qui est utilisé. Dans un tel cas, c'est le tag schoolLevels qui est utilisé. L'exemple suivant décrit une activité accessible aux enfants de la première à la sixième primaire.

<schoolLevels type="list" count="6">
 <e>p1</e>
 <e>p2</e>
 <e>p3</e>
 <e>p4</e>
 <e>p5</e>
 <e>p6</e>
</schoolLevels>

L’ensemble des valeurs possibles pour le niveau scolaire est déterminé dans le tableau ci-dessous.

Code Niveau scolaire
acc
Accueil
m1 à m3
Les 3 niveaux de maternelle
p1 à p6
Les 6 niveaux de primaire
ps
Primaire spécialisé
s1 à s6
Les 6 niveaux de secondaire
s1d
Première secondaire différenciée
s2d
Deuxième secondaire différenciée

Le tableau suivant donne les tranches d’âges existantes, dans le contexte du modèle « Tranches d’âges fixes ». Quand ce type de modèle s’applique, une seule des valeurs ci-dessous doit êre spécifiée dans le tag ageSlice. Notez que ce modèle a tendance à être abandonné.

Valeur Tranche d'âge
small
3 à 4 ans
medium
5 à 7 ans
large
8 à 12 ans
xlarge
13 à 15 ans

Enfin, en ce qui concerne les activités pour lesquelles aucun modèle d’age n’est d’application, tous les tags mentionnés seront vides. De manière générale, à chaque fois qu’un modèle d’âge donné est appliqué sur une activité, tous les tags relatifs aux autres modèles d’âge seront vides.

Lieu

Le lieu de l'activité, comme montré sur l’exemple, est repris dans le tag placeTitle. Si spécifié, il contient une chaîne de caractères sans formatage ni passages à la ligne.

<placeTitle>Club de tennis M.A.R.S</placeTitle>

Partenaire

Le nom du partenaire qui propose l’activité est défini dans le tag partnerXml. Si le lien vers le site web du partenaire est renseigné dans la base de donnée du logiciel, le tag le contiendra un lien comme illustré ci-dessous. Sinon, le tag ne contiendra que le nom du partenaire.

<partnerXml>&lt;a&gt; href="https://tennis.passion.sport">Tennis Passion&lt;a&gt;/a&lt;a&gt;</partnerXml>

Inscription des parents

Certaines activités, telles des événements, sont prévues pour des enfants, mais offrent la possibilité aux parents de s’y inscrire en tant qu’accompagnants. Cette possibilité est formalisée par le tag registerParents dont les valeurs possibles sont listées ci-dessous.

Valeur Accompagnement par le parent
impossible
Un parent ne peut pas s’inscrire avec son enfant
optional
Un parent peut s’inscrire, mais ce n’est pas obligatoire : l’enfant peut partciper seul à l’activité.
mandatory
Il est obligatoire qu’au moins un parent accompagne son enfant et soit inscrit.

Activités à inscriptions automatiques

Pour une activité à inscriptions automatiques, les champs suivants font également partie de la réponse XML.

Une activité à inscriptions automatiques est une activité gérée par un partenaire représentant une école. L'école en question réalise, en-dehors de rEve, des inscriptions groupées, pour l'une ou l'autre de ses classes, à des activités organisées par des partenaires externes: visites de musées, piscines, classes vertes... Les parents ne doivent faire aucune démarche d'inscription eux-mêmes. Les activités de ce type, dans rEve, sont appelée à inscriptions automatiques. Elles sont définies avec une ou plusieurs classes participantes. Ces inscriptions ont un tag booléen autoreg valant True.

<autoreg type="bool">True</autoreg>
<rooms type="list" count="2">
 <e>{siteUrl}/61884/xml</e>
 <e>{siteUrl}/61885/xml</e>
</rooms>
<presenceIsDefault type="bool">False</presenceIsDefault>
<incomplete type="bool">False</incomplete>

Les tags repris ci-dessus sont insérés directement sous le tag principal Activity.

La liste des classes participant à l'activité est définie dans le tag rooms. Pour chaque classe, l'URL contient, en avant-dernière position dans le chemin de l'URL, son identifiant de type iid.

Le tag presenceIsDefault, si setté à True, dispense les gestionnaires de cette activité d'encoder les présences: s'ils ne l'ont pas fait, alors tous les enfants de la classe, au moment de l'activité, seront considérés comme ayant participé à l'activité.

Le tag incomplete, si True, signifie qu'il manque actuellement des données concernant l'activité, bloquant temporairement la facturation mensuelle qui en découle. Le cas le plus fréquent est que la facture du partenaire externe n'a pas encore été envoyée à l'école. Dans pareil cas, il reste une incertitude sur le prix précis à payer pour chaque enfant; on attend donc que ces informations soient connues afin de remettre une valeur False au tag.

Tags additionnels

Des tags additionnels, non documentés et actuellement inutiles dans le contexte précis de l’API publique d'un site rEve, peuvent être présents au sein des fichiers XML d’activités. Ils doivent être simplement ignorés.

Présences

Cette section nous amène hors de l'API publique, car elle révèle, à l'utilisateur qui en a le droit, une partie privée des données d'une activité, à savoir ses listes de présences.

Un unique tag presences reprend ces présences, sous la forme d'un dictionnaire Python marshallé, incluant les présences de toutes les périodes liées à l'activité, qu'il s'agisse de périodes internes ou externes.

Les données du tag presences sont disponibles pour toutes les activités, à l'exception de celles:

  • dont les inscriptions ne sont pas nominatives (inscriptions à tickets);
  • qui gèrent des garderies et repas chauds: les structures de données, dans ce cas, sont spécifiques et ne sont pas rendues dans le tag presences.

La structure de données reprend une entrée par participation. Une participation se définit comme la présence d'une personne à un jour.

Les implications sont les suivantes.

  • Si une période représente un unique jour, ou moins d'un jour (une plage horaire au sein d'un jour), alors, dans le tag presences, on trouvera, pour cette période, une entrée par participant.
  • Si une période s'étend sur plus d'un jour, alors, on trouvera, dans le tag presences, par participant et pour cette période, autant d'entrées qu'il n'y a de jours qui chevauchent la période.

Une participation est formalisée par une chaîne de caractères pouvant prendre une forme différente, selon le type de période.

Pour une période interne, une participation est de la forme

<periodId>_<participantId>_<index>
  • <periodId> se réfère à l'identifiant de la période, tel qu'il est présent dans le sous-tag id du tag innerPeriods retourné par le service {activityId}/xml (voir ci-dessus).
  • <participantId> se réfère à l'identifiant iid de l'enfant ou du citoyen qui participe à l'activité. ⚠️ S'il s'agit d'un citoyen, on parle bien du participant et non du profil: les 2 peuvent être différents dans le cas où un citoyen secondaire est le participant.
  • <index> dans le cas où la période s'étend sur un jour ou moins, cet index est 0. Dans le cas où la période s'étend sur plus d'un jour, l'index correspond au numéro du jour parmi tous les jours que la période chevauche, le premier jour ayant l'index 0. Par exemple, si une classe verte a lieu du 13 juillet 9h au 15 juillet 16h, l'index 0 correspondra au jour 13, l'index 1 au jour 14 et l'index 2 au jour 15.

Pour une période externe, le format est plus simple. En effet, au contraire des périodes internes, il ne peut y avoir de chevauchement entre périodes externes; chacune représente un nombre de jours consécutif. Par conséquent, il est suffisant, dans le format, d'insérer l'identiant iid du participant (comme pour les périodes internes, voir ci-dessus) et le numéro du jour au sein du mois.

<participantId>_<dayNumber>

Voici un exemple de contenu du tag presences.

<presences type="dict">
 <entry type="object">
  <k>64247:0_61938_0</k>
  <v type="object" className="Object">
   <pc type="int">100</pc>
  </v>
 </entry>
 <entry type="object">
  <k>64247:0_50190_0</k>
  <v type="object" className="Object">
   <pc type="int">100</pc>
  </v>
 </entry>
 ...
 <entry type="object">
  <k>64247:1_61938_0</k>
  <v type="object" className="Object">
   <pc type="int">0</pc>
   <comment>Absent ce jour.</comment>
  </v>
 </entry>
</presences>

Seules quelques entrées sont illustrées, pour être concis.

Sur cet exemple, l'activité se décline en 2 périodes, dont les identifiants, repris sous chaque clé (sous-tag k) sont 64247:0 (2 ehtrées) et 64247:1 (1 entrée). Il s'agit d'activités internes, car une activité interne a un identifiant de la forme <activityId>:<i>, i étant le numéro d'ordre, commençant à 0, de la période au sein de toutes les périodes internes définies dans l'activité.

La deuxième partie de chaque clé reprend l'identifiant d'un enfant. Dans l'exemple, on a les enfants 61938 et 50190, deux entrées étant illustrées pour le premier —une par période.

Les 2 périodes sont des périodes de moins d'un jour: toutes les clés se terminent donc par 0.

Penchons-nous maintenant sur les valeurs, emballées dans les sous-tags v.

Pour une période interne, comme c'est le cas de l'exemple, chaque valeur est un objet disposant potentiellement des 2 attributs suivants.

  • l'attribut pc (pour percentage) indique un pourcentage de présence: 0 si l'enfant a été absent ce jour, 100 s'il a été présent. Pour une flexibilité maximale, on peut indiquer toute valeur comprise entre 0 et 100 (un enfant venu le matin mais pas l'après-midi, par exemple, pourrait être encodé à 50), mais dans la grande majorité des cas, seules les valeurs 0 et 100 sont utilisées. Cet attribut est obligatoirement repris dans chaque valeur.
  • l'attribut comment accueille un commentaire. Il s'agit d'un attribut optionnel, qui peut ne pas faire partie du tout du résultat s'il n'a pas été rempli, comme c'est le cas des 2 premières entrées de l'exemple.

Pour une période externe, la structure varie légèrement.

  • L'attribut pc est remplacé par les attributs booléens am et pm, comme illustré ci-dessous, qui indiquent a présence ou non de l'enfant le matin (AM) et/ou l'après-midi (PM) sur la journée en question (un 27)
  • L'attribut comment est le même que pour la valeur de même nom dans le contexte d'une période interne (voir ci-dessus).
...
 <entry type="object">
  <k>6168_27</k>
  <v type="object" className="Object">
   <am type="bool">True</am>
   <pm type="bool">False</pm>
   <comment>Absent ce jour.</comment>
  </v>
...

Le tag « presences » de mon activité est vide ou absent, qu'est-ce que cela signifie ?

N'oubliez pas que, pour certains types d'activités, ce tag n'est jamais utilisé. C'est le cas pour les garderies et repas chauds.

Ensuite, assurez-vous que vous consultez la bonne activité et que vous avez le droit d'y consulter les présences.

Enfin, en ce qui concerne les autres types d'activités, en règle générale, pour toute activité qui n'est pas à inscriptions automatiques, l'absence du tag presences, ou le fait qu'il soit vide, signifie que les présences n'ont pas (encore) été encodées. Dans ce cas, il suffit d'attendre, à moins que l'activité ne soit déjà terminée depuis des lustres et que vous soyez en mesure de sonner les cloches des gestionnaires de l'activité. En ce qui concerne les activités à inscriptions automatiques, si le tag presenceIsDefault est False, on se retrouve dans le même cas de figure que le cas précédemment décrit: les présences n'ont pas (encore) été encodées. Si le tag presenceIsDefault est True, l'absence de présences signifie que tous les élèves de la ou des classes inscrites à l'activité sont considérés comme présents. Utilisez le service get/rooms pour vous enquérir de la liste des élèves qui correspondent. Pour ce service, l'usage du paramètre attendances avec les valeurs paramétrées period ou interval sera un outil précieux pour récupérer la liste précise des élèves au·x moment·s (=aux périodes) où l'activité a lieu.

D'accord, mais comment détecter l'« absence de présences » ?

Dans le cas où une activité n'est organisée qu'à une unique période, la réponse à cette question est simple: l'absence de présences se détecte par l'absence du tag presences, ou le fait qu'il soit vide.

Dans le cas où une activité est organisée à plusieurs périodes, le tag presences contient les présences des participants à, potentiellement, toutes les périodes définies. Dans ce cas, l'absence de présences pour une période donnée est avérée s'il n'existe, dans le tag presences, aucune clé correspondant à cette période.