Les méthodes _saxOtherData() des contenus ODF plombent souvent les performances alors que la plupart des éléments appelés par cette méthodes pourraient être mis dans la vue et donc saxés ou non selon les cas.

Par exemple, un grosse formation peut mettre une dizaine de secondes juste pour le SAX.

Dans le CourseContentGenerator, refProgram peut être remplacé par l'appel à parentPrograms dans la vue (et les appels XSL en contentAttribute devraient être directement saxés dans la vue). Idem pour les contacts, les composantes, les heures d'enseignement, et les listes d'ELP avec la même problématique sur les XSL derrière pour certains.

Dans le OrgUnitContentGenerator, les contacts et les composantes devraient être dans la vue aussi.

Dans le ProgramContentGenerator, idem, avec en plus les childProgramParts. En plus, comme on peut faire appel à une vue lorsqu'on référence un attribut de type content dans une vue, la vue s'adapte selon le type d'enfant : conteneur ou parcours (je pense notamment au champ description ou presentation qui est sélectionné dans un cas ou l'autre).