Hello,
tout est dans le titre :
on passerait pas la 3.3 en beta pour signifier que quand même là tout à l’air de marcher et on est quasi dans un état de release ?
(et je cross-post parce que on a toujours 2 listes pour le prix d’une)
Bises
Coucou
Oui oui !
Je suis dispo pour aider à une release SPIP 3.3 beta 
Super, merci!
Cette année Noël tombe au mois de novembre 
Quels sont les retours d'expérience les plus souhaités?
C'est où la "changelist"?
:-)k++
Hello,
J’ai quand même deux petits sujets que j’aimerais qu’on traite ou du moins qu’on décide ou pas de les ajouter :
- la fonction objet_lire() que j’ai proposé il y a quelques semaines
- l’évolution ou pas du critère id_? ou un autre critère ?
Merci d’avance
Eric
Autre chose aussi.
Cédric tu avais proposé de modifier paquet.xml pour prendre en compte dans la balise pipeline la possibilité de forcer le passage en fin.
Pas à mettre dans la 3.3 ?
J’ai toujours pas pris le temps de regarder toutes les implications techniques de htmlpurifier, et il n’a pas été testé dans suffisamment d’usage en l’état pour avoir assez de recul, ça me parait hasardeux.
Mais c’est vrai aussi qu’on repousse sans cesse ce tas de sable, faute d’avoir assez de temps et d’énergie à lui consacrer…
(g0uz et le seul à avoir pris le temps de bosser dessus, et je n’ai suivi que de très loin)
ah oui totalement ! si on le fait pas là on va devoir attendre encore 5 ans 
Salut,
le modele logo n’était pas totalement heureux, je viens de le corriger, mais quoi qu’il en soit ça ne devrait pas provoquer de bug (les filtres image_xx du core fonctionnant très bien), il faut donc regarder du cote du plugin responsive
Salut,
Hello,
Je remets une couche juste pour décider si on intègre ces deux sujets dans la 3.3 :
la fonction objet_lire (que j’ai proposé il y a quelques semaines) :
oui ou non, et pas de problème si c’est non.
Amélioration ou pas du critère id_? :
à mon avis il faut restreindre ce critère uniquement aux id_xxx et donc laisser faire le critère sans rajouter de possibilité d’y injecter autre chose.
Modifier le pipeline lister_champs_selection_conditionnelle en exclure_id_conditionnel qui cette fois ne ferait que donner une liste d’id à exclure.
A priori pas de souci pour ce changement puisque ce pipeline n’est utilisé que par SVP pour justement supprimer id_plugin et id_paquet je crois que la liste.
Hello,
pour la fonction objet_lire() j’avais soumis mon interrogation sur le fait qu’elle contiennent un appel à pipeline qui permet d’enrichir l’objet, chose qui n’est pas équivalente à un sql_fetsel() en base
C’est peut-être une direction dans laquelle on voudra aller, mais ça me semble pas certain, et lourd de conséquence.
Donc amha on peut l’intégrer mais sans ce pipeline : la fonction est juste un shorthand facilitateur, avec quelques automatismes/sécurités par rapport à un sql_fetsel() mais renvoie le même résultat.
Ça permet de l’introduire, de voir si on en s’en sert, et éventuellement de réflechir à l’étendre, mais c’est un sujet plus gros et plus vaste.
Je n'ai pas le même regard.
Pour moi c'est juste une fonction de plus haut niveau que sql_fetsel.
En fait, c'est simplement le complément des objet_ecrire et objet_modifier qui elles aussi peuvent générer des traitements lourds à travers des pipelines.
objet_lire() serait donc à utiliser en connaissance de cause, comme les autres objet_*
Un peu comme les ORM, qui sont super pratiques en cachant toute la magie (behaviors, relations, cascade...), mais qui peuvent être contre productifs si mal utilisés.
Hello,
Hello,
pour la fonction objet_lire() j’avais soumis mon interrogation sur le fait qu’elle contiennent un appel à pipeline qui permet d’enrichir l’objet, chose qui n’est pas équivalente à un sql_fetsel() en base
C’est peut-être une direction dans laquelle on voudra aller, mais ça me semble pas certain, et lourd de conséquence.
Donc amha on peut l’intégrer mais sans ce pipeline : la fonction est juste un shorthand facilitateur, avec quelques automatismes/sécurités par rapport à un sql_fetsel() mais renvoie le même résultat.Ça permet de l’introduire, de voir si on en s’en sert, et éventuellement de réflechir à l’étendre, mais c’est un sujet plus gros et plus vaste.
Oui, j’avais déjà pris en compte ta remarque et enlevé le pipeline.
Ce que j’avais par contre c’est un appel à une fonction spécifique pour lire les champs de l’objet si elle existe et qui se substitue au traitement standard si besoin (comme par exemple pour les plugins qui nécessite une jointure sur la table des dépots).
Si ça convient pas on peut le supprimer aussi.
Rasta avait fait aussi la remarque sur l’intérêt de l’argument forçant le recalcul en base : effectivement ça sert peut être à rien et on pourrait l’enlever.
Le code actuel est donc le suivant, dites moi si on fait des modifications et je le commite :
/**
* Lit un objet donné connu par son id ou par un identifiant textuel unique et renvoie tout ou partie de sa
* description.
* Il est possible pour un objet donné de fournir la fonction <objet>_lire_champs qui renvoie simplement tous les
* champs de l'objet concerné sans aucun autre traitement. Sinon, l'appel SQL est réalisé par l'API.Hello,
Si je comprends bien, l’intérêt de cette fonction c’est que c’est plus optimisé que de faire plusieurs sql_fetsel, j’ai bon ?
Juste une remarque sur la signature de la fonction : ça me semble un peu pénible d’avoir à récupérer le nom du champ qui sert d’identifiant avant d’appeler cette fonction. N’est-il pas possible de rendre le paramètre $champ_id optionnel, et le mettre en dernier ?
Il me semble que dans la majorité des cas, il s’agira du champ qui porte la clé primaire, qui peut être déduit automatiquement non ?
Ainsi l’utilisation “de base” serait plus simple et identique à objet_modifier et objet_inserer.
C’est à dire faire ça :
objet_lire(‘patate’, 10, array(‘titre’, ‘texte’));
Au lieu de faire ça :
objet_lire(‘patate’, ‘id_patate’, 10, array(‘titre’, ‘texte’));
Re,
Hello,
Si je comprends bien, l’intérêt de cette fonction c’est que c’est plus optimisé que de faire plusieurs sql_fetsel, j’ai bon ?
Oui et c’est aussi un complément naturel à l’API objet.
Juste une remarque sur la signature de la fonction : ça me semble un peu pénible d’avoir à récupérer le nom du champ qui sert d’identifiant avant d’appeler cette fonction. N’est-il pas possible de rendre le paramètre $champ_id optionnel, et le mettre en dernier ?
Il me semble que dans la majorité des cas, il s’agira du champ qui porte la clé primaire, qui peut être déduit automatiquement non ?Ainsi l’utilisation « de base » serait plus simple et identique à objet_modifier et objet_inserer.
C’est à dire faire ça :
objet_lire(‹ patate ›, 10, array(‹ titre ›, ‹ texte ›));
Au lieu de faire ça :
objet_lire(‹ patate ›, ‹ id_patate ›, 10, array(‹ titre ›, ‹ texte ›));
Oui on peut.
Si ça convient à tous, j’ai pas de souci.
et moi je remet une couche également sur la fusion des deux listes pour la sortie 3.3.0
d’ailleurs les réponses sont sur une seul liste, alors qu’uau départ sur les 2 listes
Sauf que ça a rien à voir avec le fil de discussion
sauf que lorsque le fil est lancé sur les deux listes et que une seul réagit
on c'est plus quoi suivre et sur quel liste répondre
donc j'avoue j'ai un peu poussé mais ça deviens pénible d'entendre depuis trois mois que les listes vont fusionné et que ça le fait pas
ceci étant c'est SPIP les projets on toujours du mal a être acté la preuve ton fil que tu remet sur la liste pour poussé a prendre une décision
sans doute mon coté râleur de fin d'année sur un produit et des gens que j'admire
bises
+1
Et pourquoi devoir préciser explicitement la liste des champs qu'on veut obtenir ?
Ça peut être vite contraignant.
Pourquoi pas objet_lire('patate', 10) sans précision qui retournerait juste tous les champs de l'objet ?