mailRe: [Galette-devel] Rev 412: pb avec $language


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Johan Cwiklinski on October 18, 2007 - 15:52:
Salut,

Eric Boniface a écrit :

    > 4-L'icône mailto dans la liste des adhérents
    (gestion_adherents.php) me
    > semble inutile vu qu'il y a les case à cocher et le lien
    "envoyer un
    > courriel à tous en bas de page.
    >
    Hum... je me suis posé la question aussi, mais cela permet d'envoyer
    'facilement' un mail à un seul adhérent, en passant par le mailer de
    l'utilisateur, et pas par php. Je suis personnellement pour conserver
    cette option.


Je pense aussi qu'il faut garder cette option très pratique.

    > 5-je ne sais pas pour vous mais j'ai des pb d'encodage de caractère
    > (accents dans les nom ou prénoms d'adhérents par exemples qui sont
    > encodé en utf8 dans ma base et s'affichent mal à l'écran)
    >
    Encodés en UTF dans la base ? Mes tables possèdent toutes un
    interclassement "latin1_swedish_ci", ce n'est pas ton cas ?


pareil dans mon cas, latin1_swedish_ci et ça fonctionne bien.
Je ne crois pas que les tables en utf soient gérées actuellement, et ne
le sont pas de façon certaine avec la 'nouvelle' version (enfin, je n'ai
rien fait en ce sens). Est-il envisageable/souhaitable de les introduire
? Il me semble que cela peut causer des soucis au niveau des bases
mysql, mais j'avoue ne pas avoir testé personnellement, quelqu'un a des
retours sur le sujet pour mysql et postgres (et pas forcément rattachés
à Galette) ?
Si l'on introduit le support des bases UTF-8, laissons-nous le choix à
l'utilisateur de créer sa base en utf/iso ou on force ?

    > Pour le reste, superbe commit, merci pour les onglets dans les
    > préférences et tout le reste.
    >
    Héhé, mais de rien, content que tu apprécies ;-)


il faut que je le récupère pour tester :-)
Je suis en train de voir pour mettre une démo du svn chez TF, il faut
que je termine la page d'install avant (ce devrait être OK ce jour).

    > Questions pour lancer la discussion:
    > Vu que cette version est devenu la future v07, quid de la v063
    bugfix?
    >
    Je pense qu'il va vraiment falloir que je prenne le temps et le
    courage
    de m'y remettre et de publier une 0.63 stable. J'aurai à cette
    occasion
    besoin de testeurs, avis aux intéressés ! :-p


Pas de souci pour ça... dès que tu penses que la version est
suffisamment stable tu fais signe

    > S'impose t'on une date de release de la v07 official ?
    >
    Hum... dans le libre la devise est généralement : "on release lorsque
    c'est prêt" :-D


l'idéal c'est "on release lorsque la roadmap est atteinte" non ?  :)
Oui, sauf que la roadmap est pas vraiment à jour là :-p

    J'ai commencé à intégrer la gestion de la base de données par
    PEAR::MDB2, la gestion des logs par PEAR::Log, j'ai implanté une
    classe
    php5 pour la gestion de la langue, commencé aussi des classes php5
    pour
    la gestion des adhérents et des préférences...

    Autant dire pour résumer que je n'ai pas la moindre idée
    aujourd'hui du
    temps qu'il faudra pour finaliser tout cela :/


Perso, je trouve qu'il s'agit là de gros changements et qui devrait
faire partie d'une release majeure de Galette, genre une 0.7 pourquoi pas.
Ne serait-il pas mieux de sortir un 0.63 avec tous les derniers
changements ? il s'agira déjà de grosses modifications par rapport à
la 0.62.
Pour la 0.63 il existe une branche -bugfix qui a été créée peu avant que
je reprenne Galette en main ; cette version propose déjà pas mal
d'ajouts par rapport à la 0.62.2 ; et il s'agira de la dernière
compatible avec PHP4. Il ne sera pas possible (ou plutôt compliqué)
d'ajouter les nouveautés qui ont été greffées depuis, puisque php5 est
requis pour les versions SVN depuis (presque) le moment où je suis arrivé...

Je vous tiens au courant, j'ai une '0.63' en prod depuis quelque temps,
les bogues commencent à s'estomper (sur les fonctions utilisées en
interne bien sûr, pour le reste, je sais pas).

    J'espère cependant sortir une version alpha avant la fin de l'année,
    afin de proposer une version complètement php5 avant la fin du support
    de php4... Je ne peux rien promettre malheureusement, je suis
    tributaire
    de mon travail :/


La 0.62 moyennant quelques corrections fonctionnent très bien sous PHP5.
Ouép, la 0.63-bugfix aussi, il me semble même qu'il n'y a pas besoin de
modifier quoi que ce soit.

Ceci dit, je ne parlais pas de compatibilité, mais plutôt de
l'utilisation de fonctionnalités propres à PHP5 (comme les objets, qui
n'ont plus rien à voir...).

    > Quel roadmap pour le développemnt de cette version ? (autrement
    dit que
    > choisi t-on d'y mettre et de ne pas y mettre, donc priorité des
    task de
    > la todo list ?)
    >
    Là aussi faut que je m'y colle.
    La todolist est à revoir, pas mal d'éléments manquent. Pour moi, les
    principales modifs seront :
    - relooking
    - ajout de fonctionnalités dynamiques (onglets et autres) grâce à
    JQuery
    - utilisation d'objets PHP au maximum
    - tant qu'à faire, la correction de bogues qui traînent (j'entends par
    bogues ici les bogues strictement reproductibles, pas ceux
    spécifiques à
    un hébergeur particulier sur lequel je ne peux pas tester). 


Je suis d'accord avec toi, il faut revoir la todolist. Une fois
établie, il faut raisonnablement affecter des priorités et un numéro
de version en face... genre (je donne les numéros au pif) : relooking
-> 0.7, objets PHP -> 0.68
Ca permet ainsi de valider et de rendre stable une version en figeant
les évolutions.
Je suis totalement d'accord, c'est une bonne façon de procéder. Ceci
dit, dans la pratique ce n'est pas évident à tenir, puisque je passe
souvent de l'un à l'autre...

Par exemple, je me suis collé au relooking, me suis aperçu que certaines
choses me manquaient et je les ai donc développées. Plutôt dans ce cas
que de partir de la base existante, j'ai fait un bel objet qui sera
amené à évoluer dans le futur.  J'ai donc du bosser sur la '0.7' et la
'0.68' de ton raisonnement...

Qui plus est, j'ai choisi de passer à la 0.7 pour marquer la fin de la
compatibilité php4, même pour des versions de développement, je pense
qu'il faut conserver cette idée, et donc ne pas passer par les versions
entre 0.63 et 0.7

C'est le principe que nous appliquons pour IPCop par exemple.

    S'il est possible de vider au maximum la todolist actuelle, ce sera
    super aussi.


mais il faut toujours une todolist... :-)
Clairement, bien forts nous serons si nous arrivons déjà à vider celle
qui existe avec ma lubie de vouloir tout refaire :-D

    Bref, soyez indulgents, j'ai pas mal d'idées, mais assez peu de temps
    malheureusement pour les réaliser :/


Comment peut-on t'aider à avancer et surtout à te décharger un peu ?
Pour ça, il faut avant que je fasse un tri dans la todolist, et que
j'attribue des priorités. Il reste aussi des bogues à fermer...
En attendant, les propositions/critiques/remarques/remontées de bogues
sont les bienvenues sur la version SVN. La correction de mes éventuelles
coquilles est bien évidemment plus qu'appréciée également :-D

Dès que tout cela sera plus clair dans ma tête (et quand j'aurai eu le
courage de faire un peu "d'administratif", je reviendrai sur ta
proposition :-)

Eric.

-- 
Président de l'Association des Ingénieurs CNAM Dauphiné Savoie (AIPST) 
Merci,
Johan

Attachment: signature.asc
Description: OpenPGP digital signature


Related Messages


Powered by MHonArc, Updated Thu Oct 18 23:20:10 2007