Ajax Parallel Loading (APL) est actuellement disponible avec zcore. Il suffit de l’activer.
La documentation est celle de APL pour ZPIP : Zpip, blocs de page et Ajax
Attention : Les fonctionnalités de APL se répartissent dans 3 entités de code : 1) le core de spip-dist, pour quelques fonctions PHP de base, 2) le plugin zcore pour certains mécanismes de base, js notamment, 3) votre jeu de squelette, qui peut par exemple s’appuyer sur le plugin zpipr.
Pour que ça marche
- Il faut définir les blocs Z comme indiqué dans les docs pour zcore et ZPIP2 Zpip, blocs de page et Ajax
- En plus de cela, il est fortement recommandé que chaque bloc Z ait un attribut id égal à son nom de bloc. En particulier, c’est nécessaire pour le chargement des scripts inclus.
- Avec zcore, rien empêche en général que les squelettes des pages principales n’appellent pas le fichier structure.html lui même dès lors qu’ils en reproduisent le contenu, ou du moins l’inclusion des blocs principaux. Mais pour bénéficier de APL, il FAUT que tous les squelettes définissant les pages du site incluent le squelette structure.html (ou alors les autres squelettes de page ne doivent jamais inclure le bloc APLé, ou doivent explicitement désactiver APL).
Les squelettes des pages principales peuvent/doivent donc être tous (quasi-)identiques à :
<INCLURE{fond=structure, env, type-page=#ENV{page,#ENV{type-page,sommaire}}}>
- S’il y a des scripts js dans un bloc APLé :
- pour que ces scripts soient appelés, les divs englobant le blocs doivent avoir un id égal à leur nom de bloc. C’est le cas notamment dans SPIPR ainsi qu’on le voit immédiatement dans
body.html: https://git.spip.net/spip-contrib-squelettes/spipr-blog/-/blob/master/body.html (ou sinon, les scripts doivent être placés dans un<div id="nomdubloc">qui peut ne servir qu’à ça) - il peut être nécessaire de les adapter pour qu’il fonctionnent après un chargement asynchrone, et ça peut demander d’en revoir la conception.
- Les formulaire utilisés doivent être en GET, et s’il y en a en POST il faut les convertir en GET avec ajout du [(#SELF|form_hidden)] ou [(#ENV{action}|form_hidden)] qui va bien en prime.
- En cas d’usage de la fonction ajaxReload, il faut adapter les arguments pour ne pas recevoir un bloc vide :
ajaxReload('aside',
{args: {
'foo':'bar',
'var_zapl':'non'
}
});
Effets de transition à l’APL d’un bloc
Voici les CSS qui permettent d’adoucir l’apparition d’un bloc ’aside’ chargé par APL (on a donc define('_Z_AJAX_PARALLEL_LOAD', 'aside');) au moyen d’une transition d’opacité :
.aside > div:not(#zapl-aside) {
animation: asideFadeIn 2s ease-in-out;
}
#zapl-aside {
asideFadeOut 0.2s ease-in-out forwards;
}
@keyframes asideFadeIn {
from { opacity: 0; }
to { opacity: 1; }
}
@keyframes asideFadeOut {
from { opacity: 1; }
to { opacity: 0; }
}
#zapl-aside c’est en effet le bloc « Chargement en cours ». Avec ces effets CSS, il disparaît en douceur mais rapidement quand l’.aside arrive, suivi de l’apparition progressive de l’.aside, plus lente.
Exploration de l’implémentation
La fonction styliser_par_z est implémentée dans le noyau de SPIP par public_styliser_par_z_dist : https://git.spip.net/spip/ecrire/-/blob/5.x/public/styliser_par_z.php?ref_type=heads#L30
Le mécanisme APL est donc disponible dans SPIP-dist, et ZCore le complète, en cadre et en facilite l’usage.
- de même que la constante _Z_AJAX_PARALLEL_LOAD définit les blocs devant être APLé dans l’espace public, la constante _ECRIRE_AJAX_PARALLEL_LOAD définit les blocs du privé devant être APLé.
- dans la constante _Z_AJAX_PARALLEL_LOAD, il ne faut pas d’espace autours des noms de blocs
- Le bloc principal ’contenu’ doit toujours être en première position dans la liste des blocs (c’est d’ailleurs dans la doc)
- le nom du squelette ’structure’ est codé en dur.
- la constante _Z_AJAX_PARALLEL_LOAD_OK désactive APL. Elle n’est jamais positionnée par SPIP-dist, mais par zcore dans zcore_pipeline,
if (!isset($_COOKIE['no_zapl']) AND !_IS_BOT AND !_request('var_zajax') AND _request('var_mode') !== "debug" AND $_SERVER['REQUEST_METHOD'] == 'GET') {
define('_Z_AJAX_PARALLEL_LOAD_OK', true);
$GLOBALS['marqueur'] = isset($GLOBALS['marqueur']) ? $GLOBALS['marqueur'] . ":Zapl" : ":Zapl";
}
Avec ZCore, il est donc possible de désactiver APL par un cookie pour un utilisateur particulier, ou par un argument d’url (éventuellement ajouté dans le squelette de la page avant l’appel de structure.html) pour une page particulière.
Et sans ZCore, il est, au besoin, possible de le faire de manière ciblée : dans un fichier d’option par exemple.
Problèmes rencontrés
- Incroyable : un script disparaît du bloc appelé. Non seulement il n’est pas appelé, mais il ne figure pas dans le html, comme si le mécanisme APL le repérait et le retirait...
- Les formulaires de la dist sont en POST et ne sont donc pas utilisables dans un bloc APL
- Problème quand un bloc Z APL contient un sous-bloc ajax et/ou des liens de rechargement ajax.
- Cerdic, créateur de z-core, indique que « le zapl c’est un truc fancy d’il y a 10 ans, j’utilise nulle part et je pense pas que ça ait encore vraiment de l’intérêt. ».
Sentiments
- JLuc: APL ça marche bien et tout seul quand il n’y a pas de javascript ou de formulaires dans le bloc. Lorsqu’il en y a, ça devient très difficile à adapter ou il faut repartir à 0 la conception.