1

(3 réponses, posts Actualités)

J'aime le HyWaN mature qui se prend pas le choux, et qui code juste des trucs biens smile

Hywan a écrit:

On avance, on avance !
J'ai du retard, mais ce n'est pas de ma faute … Un geek célibataire, ça code, mais un geek qui n'est plus célibataire, ça code moins .

Femmes > Geeking, ceci inscris quand même ta copine sur http://www.copinedegeek.com/ smile
Hey sinon si tu veux vraiment coder tu fais comme moi, tu te met à 4700 km de ta copine/femme, ça marche pas mal smile

3

(10 réponses, posts Dépannages)

le modele a pour role d'exploiter les données ton xml en gros c'est comme un sgbd ou une autre source de donnée, à la différence qu'elle est statique donc personellement je stockerais ca dans un dossier data, ou à la limite conf. laisson HyWaN confirmer ou pas ce que je dis smile

4

(10 réponses, posts Dépannages)

ca me choque personellement qu'un xml comme celui que tu décris se retrouve dans le dossier correspondant au modèle, ca tiens plus d'un source de donnée, et je crois qu'il y a dans hoa une notion de data dans le mvc qui correspond tout à fait à ce que tu veux faire avec ce xml, un donnée partagé sur les différents modèles.

5

(5 réponses, posts Bar)

pour un menu fish like tu peux aussi le faire en prototype/scriptaculous assez facilement d'ailleurs smile

6

(4 réponses, posts Dépannages)

yapadkoi, jpassais par la j'ai vu de la lumière smile

7

(4 réponses, posts Dépannages)

es tu familié avec la notion de charset?
UTF-8 est la norme actuellement les systèmes évoluent lentement mais surement vers une généralisation de l'utilisation de ce charset, je serais assez prêt à parier que ton problème est un problème qui tient plus de l'instalation de ton système/browser/php que de HoA lui même. Peux tu confirmer que le charset que tu utilises est bien UTF-8?

8

(6 réponses, posts Vos contributions)

oki c cool, à l'occase j'essaierais d'apporter quelques critiques constructives

Hywan a écrit:

Je fais des mises à jour du miroir SVN très régulièrement (environ toutes les heures si c'est nécessaire) donc vous pouvez presque « suivre » les modifications en temps réel (après, est-ce que c'est intéressant … ).

Est-ce que ce format de journal vous convient ?

Je te conseillerais bien d'éviter, pour la lisibilité de ton svnweb c'est mieux de grouper les commit par thèmes, et d'éviter de commiter des bugs (bon après ca arrive forcément), le sourcing doit pas etre un outil de backup, mais de revisionage de source, commiter moins mais mieux apporte de la lisibilité, après tu peux avoir un branche head instable et une branche stable un peu à l'image de ce que font beaucoup d'éditeur d'os, mais ca reste très compliqué à manager au jorud le jour smile

10

(6 réponses, posts Vos contributions)

la meilleure solution à mon avis, étant de stocker des paires clef/valeur dans un gros array php, le tout dans un fichier taggé fr/en ou autre, c'est rudimentaire mais ca reste la solution la plus efficace en terme de perf/portabilité. le tout étant relativement parsable malgrès tout pour procurer des fonctionalités d'édition au end-user.

le xml est plus sexy mais pas plus performant.

Bon sinon, ça te dit que je t'embète sur le code d'HoA HyWaN parceque ca me tente bien de filer mon avis de temps en temps sur certaines stratégies.