S'lt
Je fais suite à tes mails et commits. Bon boulot.
Pour spip_societe, cette partie a été codé rapidement par mes pieds
(j'avais un besoin urgent) et du coup j'ai fait au plus simple et
crade. Donc non il n'etait clairement pas sur que cela marche
ailleurs.
Dans tout ce code il va falloir regarder pour utiliser <version_base>
qui est dédié à la gestion des mises à jour base de données.
Est ce que tes commits corrige le pb de compat php <5.2 que tu m'avais remonté ?
Km
Le 27 janv. 09 à 11:01, cam.lafit@azerttyu.net a écrit :
S’lt
Je fais suite à tes mails et commits. Bon boulot.
Pour spip_societe, cette partie a été codé rapidement par mes pieds
(j’avais un besoin urgent) et du coup j’ai fait au plus simple et
crade. Donc non il n’etait clairement pas sur que cela marche
ailleurs.
j’avais un très jolie bandeau de deuil sur tous les espaces privés de mes sites qquesoit la version de php.
Spip proposait de réparer la table spip_sociétés, déclarée mais pas créé. et c’est difficile de réparer quelque chose qui n’existe pas si j’ai bien compris.
Désormais on a plus ce problème et il devient relativement facile de proposer une interface de remplissage de cette table, elle peut-être très utile si cela permet de différentier les infos collectées lors de l’inscription et celles propre au(x) propriétaire(s) du site. D’autant qu’avec les nouveaux extra on peut réver coller au besoin exactement.
Dans tout ce code il va falloir regarder pour utiliser <version_base>
qui est dédié à la gestion des mises à jour base de données.Est ce que tes commits corrige le pb de compat php <5.2 que tu m’avais remonté ?
Non, j’ai juste changé le chemin d’accès à ton fichier de compatibilité pour array_intersect_key qui se trouve dans inc et non dans base
il reste à trouver une solution pour array_fill_keys qui n’a pas encore d’émulateur dans inscription 2,
je n’ai pas réussi à mettre en place la solution proposée dans le forum http://fr2.php.net/manual/fr/function.array-fill-keys.php
Après cela on pourra savoir si cela suffit pour faire fonctionner la table adhérent avec php<5.2
pierre
PS :
l’homogénisation du format de l’identifiant de spip_geo est trop hard, les logs ralent un peu mais le résultat attendu semble être bon.
Pour version_base il suffit de modifier deux fichier si je ne m’abuse : plugin.xml ce qui est facile et inscription2_installer qui est un peu plus délicat car encore un peu embrouillé pour moi. il faudrait en profiter pour faire vraiment coller les message d’installation ou d’upgrade avec la réalité.
La méthode de màj utilisé par spip_agenda semble plus cohérente ou plus lisible ne serait-ce pas aussi une voix à emprunter ?
S'lt
j'avais un très jolie bandeau de deuil sur tous les espaces privés de mes
sites qquesoit la version de php.
eheh 
En effet difficile de reparer ce qui n'existe pas.
Spip proposait de réparer la table spip_sociétés, déclarée mais pas créé. et
c'est difficile de réparer quelque chose qui n'existe pas si j'ai bien
compris.
Désormais on a plus ce problème et il devient relativement facile de
proposer une interface de remplissage de cette table, elle peut-être très
utile si cela permet de différentier les infos collectées lors de
l'inscription et celles propre au(x) propriétaire(s) du site.
Oui l'idée était d'avoir une interface de gestion des coordonnées plus
vaste pour dans un premier temps gerer les cas des
sociétés/associations/...
On m'avait soumis le terme de "organisation" pour rester plus neutre
au niveau de l'objet.
J'avais pensé faire une interface dédiée pour l'ajout des socitétés
mais le besoin c'est tassé dans l'ordre de mes priorité.
L'autre évolution qui aurait du suivre c'etait spip_coordonnées qui
aurait permis de gerer spécifiquement des coordonnées communues, ...
De plus les notions objets, id_ojets et tables spip_*_liens aurait
permis de gerer tout ça.
Pareil manque de temps pour ce projet.
Dans tout ce code il va falloir regarder pour utiliser <version_base>
qui est dédié à la gestion des mises à jour base de données.Pour version_base il suffit de modifier deux fichier si je ne m'abuse :
plugin.xml ce qui est facile et inscription2_installer qui est un peu plus
délicat car encore un peu embrouillé pour moi. [...]
La méthode de màj utilisé par spip_agenda semble plus cohérente ou plus
lisible ne serait-ce pas aussi une voix à emprunter ?
Oui spip_agenda utilise le normalise SPIP2 alors que I2 est encore sauce 1.9
Le code concernant la base de données est encore tres rude car melange
de besoin SPIP2 et beaucoup de reste 1.9
De plus il y avait une gestion de création/modification des champs à
la volée en fonction des valeurs déclaré via CFG. Cette partie à
sauter dans les fait mais le code n'a surement pas suivi.
Est ce que tes commits corrige le pb de compat php <5.2 que tu m'avais
remonté ?Non, j'ai juste changé le chemin d'accès à ton fichier de compatibilité
pour array_intersect_key qui se trouve dans inc et non dans base
il reste à trouver une solution pour array_fill_keys qui n'a pas encore
d'émulateur dans inscription 2,
je n'ai pas réussi à mettre en place la solution proposée dans le
forum PHP: array_fill_keys - Manual
Après cela on pourra savoir si cela suffit pour faire fonctionner la table
adhérent avec php<5.2
Ok
pierre
PS :
l'homogénisation du format de l'identifiant de spip_geo est trop hard, les
logs ralent un peu mais le résultat attendu semble être bon.
On verra ce qu'en penses Kent1, c'est plutôt sa partie là
Km
S'lt
Juste pour dire, j'ai posé une compat php4 pour le array_fill_keys,
est ce que ça marche ?
S'lt
Malheureusement, je viens de tester ça ne permet pas encore d'être
compatible.
En tout cas la page exec=inscription2_adherents avec php5 reste vide des
infos sur les adhérents.
Bon deja si ça ne fait plus d'erreur php c'est deja un début, Raaahh
faut comprendre ce qui coince dans ce code 
- Qque soit la version de php le code compris entre les lignes 151 à 163
"lettre" ne produit qu'une erreur tidy <b></b>
- Avec php 5.2 le reste fonctionne mais avec php5 les ligne 187 à 296 ne
remplissent pas leur office.
Hum ... faudrait regarder les elements genant la dedans.
- Par contre il semble qu'on puisse utiliser des balises à la place du php
(ligne 187 à 296) !
Oui il faudait passer tout ça en squelette, ça sera plus propre et/ou pratique.
Pour le moment il n'y a pas de solution autre que de coder en dur
toutes les colonnes comme tu le suggéres.
Il aurait été sympa de faire un truc dans le gout
#BALISE{mabalise_issue_de_cfg}, mais malheureusement le compilateur ne
le permet pas vu que toutes les données à traiter ne sont pas connues
au bon moment.
J'avais fait une ébauche en utilisant des listes et inclusions ce qui
permettaient de mieux styliser tout ça, je dois avoir encore un bout
de code sur mon ordi
Km