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.