ToursAnnonces.fr

J'ai mis 2 mois pour construire le site Tours annonces, voici mes notes, une sorte de blog bouillie pas très intéressante pour la plupart des gens, mais pour moi, c'est une archive qui contient l'essentiel de mes pensées, sans détour. Avis aux amateurs.

**** 31-03-2010

07h58 : start

Petite séance de débugguage avant d'attaquer...


08h43 : basiquement, j'arrive à envoyer un mail à une ou plusieurs personnes,
avec contrôle total de ce qui est affiché, et possibilité de mettre du html et de joindre des pièces.
Essayons de créer un html assez beau.
(je teste sur yahoo uniquement pour le moment.)

http://www.pompage.net/pompe/emails-html-dompter-la-bete/

09h14 : hey : intéressant : http://www.campaignmonitor.com/templates/
Leur outil est vraiment top, et le mail n'arrive pas dans les spams.
mais beaucoup trop cher pour moi, snif.
Mais au moins j'ai capté que les images doivente être stockées sur mon serveur,
et pas envoyées en pièces jointes avec le mail;

pause
téléphone...

12h18
Création de la news pour email en ligne
http://www.toursannonces.fr/mailing/general/lancement-tours-annonces-5/index.html

12h45 : test de l'affichage en mail dans yahoo et gmail.
Chez yahoo ça tombe direct dans les spams, tant pis je dois avancer..., chez google par exemple ça marche.
Il faut encore que je trouve un moyen pratique d'envoyer les mails en masse.

15h16 : après avoir testé plusieurs trucs, rien de vraiment concluant, et la yahoo se bloque,
je passe à autre chose je reviendrais dessus plus tard.

16h01 : après quelques essais encore, bon là vraiment je vais faire le système moi même pour faire vite...

16h25 : la table mailing_sended_list est créée, et le système fonctionnel en local...

16h38 : en place en ligne en mode bridé, j'attends de recevoir mon mail pour balancer, mais je ne le reçois pas.
Sinon,s i je le configure à 20 mails par minute,
comme il y a 8 498
ça fait 425 minutes soit 7 heures, ça me va, pas pressé...

En attendant de recevoir ce mail je dois intégrer une nouvelle ville pour un pote : bobigny annonces ::

choses de la vie...

02h32 : bon j'ai intégré basiquement le design de bobigny annonces, pour un pote,
et du coup je vais m'en servir pour Tours annonces.
http://93annonces.fr

Putain j'ai pas fait le cache...

Gasp (chcrois qu'chui bon pour faire le cache demain matin, snif, j'étais censé avoir fini...)

Pour ie6 et autres, on verra plus tard, en mai...
(pakça à faire... non mais..., zonka prendre un vrai navigateur..., et surtout plus l'temps)


03h25 : bon, voilà, officiellement la fin de cette première sessiono,
même si demain je fais encore 3 choses en rapport avec Tours annonces :
apprendre à faire des backups de tables (je sais faire que les database pour l'instant, avec putty je parle)
Vérifier que la fonction mail est bien implémentée sur le site.
Faire enfin ce système de cache.
En fait il est déjà fait mais fopen a pas l'air de marcher avec phpcli, donc faut trouver autre chose...

AAAH putain je vais savourer ce moment de pouvoir exprimer toute ma joie,
la joie du mec qui a finit son travail et qui peut enfin passer à autre chose.
(même si demain matin ...)

Attention 1, 2, 3 ...

..




z

;)

**** 30-03-2010

07h55 : start

Bon, le but est de reprendre le travail d'hier :

08h59 : le système de republication est en ligne en mode bridé, j'ai juste à changer une ligne pour le débrider.
Mais avant il faut que je republie toutes les annonces vieilles de plus du ANNONCE_LIFETIME, je vais me créer un script pour cela.

09h11 : le script est fait;

09h16 : le script est mis en ligne et exécuté.

09h22 : débridage du script de relance des annonces sur le point d'être périmées, et mise en place de la tâche cron qui le lance toutes les heures.
Toutes les 20 minutes aurais peut être été mieux.

sauvegarde de la base de données.

10h33 : téléchargement d'une classe facilitant la gestion des mails sur phpclasses...dSendMail2... étude de la classe...
Bon en fait l'envoi d'un mail avec du html ne fonctionne pas bien, ou plutôt je n'arrive pas à le faire fonctionner simplement,
je vais voir phpmailer, ce que j'aurais du faire dès le départ...
11h19 : ah ben si en fait ça marchait, fallait juste attendre un peu, trop tard, maintenant chui sur phpmailer.

Découverte d'une erreur pour le formulaire d'ajout d'annonces ... un scooter.


12h40 : ajout d'une question à la fac : comment supprimer mon annonce ?

12h50 : j'ai pas fini avec les mails, mais avant j'ai oublié la fonction qui doit effacer rééllement les annonces :
création de l'état : STATUT_EXPIREE pour une annonce;


Le but sera plus tard d'éradiquer une annonce et toutes ses dépendances du système (incluant les photos liées),
mais on n'est pas pressé, ça peut attendre quelques mois.
Pour l'instant, marquons toutes les annonces expirées .
Une tâche cron sera exécutée une fois par jour et marquera ces annonces, fastoche...

13h07 : le script est écrit, petite vérification que les annonces affichées n'affichent pas les annonces expirées. ..

13h08 : ok, reste plus qu'à le mettre en ligne...
13h13 : le script est en ligne et la tâche cron le fera tourner une fois par jour;

Petite pause et après on continue notre investigation sur les mails qui est une fonction clé d'un système web comme le mien;
D'ailleurs faudra remettre j'ai perdu mon mot de passe ...
Ben d'ailleurs on va faire ça avant la campagne d'emailing...

15h10 : le système de renvoi de mot de passe est actif en local.
15h16 : le système est en ligne et fonctionnel;

Corrections de petits trucs...


choses de la vie...

00h50 : putain !
choses diverses : récupération d'annonces, mise en ligne de site dans l'annuaire et ...

bref, mais j'ai pas avancé et je commence à avoir du mal... Grrrrr...

La désagréable impression d'avoir rien foutu aujourd'hui.

01h33 : toujours dans le bidouillage avec des utilisateurs... grrr...

Bon cette fois j'ai vraiment pas beaucoup d'énérgie,
j'aurais du envoyer la campagne de mail, mais là je suis en retard.
Pourtant je ne veux pas faire n'importe quoi avec phpmailer, car c'est un outil très bien et si je l'utilise bien je peux gagner
beaucoup de temps par la suite.

Il me reste demain pour :
finir le système de cache,
envoyer un mail global pour prévenir tous les utilisateurs que j'ai republié une dernière fois leurs annonces et que le système
de rotation des annonces (avec une durée de vie de 2 mois pour l'instant est opérationnel) est en place.

Ca a l'air simple comme ça, mais comme je veux le faire relativement bien, ça va me mettre toute la journée.
Pour le reste, c'est pas très important pour moi, car le système est fonctionnel, et c'est tout ce qui m'importe.

Demain théoriquement : dernier jour de travail sur Tours annonces jusqu'au 1er mai.

Le programme d'avril : faire le myspace d'une copine, faire un logiciel de gestion de base de données clients-produits pour un commerce type restaurant,
maîtriser au maximum Joomla pour faire des sites rapidement.


Certains diraient qu'il vaut mieux ne rien produire que de produire de la merde.

Ben moi si j'écris pas ce que je fais, j'existe pas, je préfère faire de la merde que faire rien,
parce que au moins la merde elle existe.

Très philosophique tout ça, tout ça pour dire que je vais continuer ce système de narration monologue explicatif pseudo post carnet de bord pour
la suite de mes projets, enfin sans garantie...
Bon assez parlé, dormons maintenant, demain est une journée où nous allons gérer des grands problèmes...

**** 29-03-2010

07h26 : malgré la liste impressionnante des tâches que je devrais réaliser aujourd'hui,
ou du moins essayer, je pense que la priorité est de remettre chartres annonces.
En effet, il n'y a carrément plus de service actuellement.

10h14 : Ca y est, c'est en place, en soi c'était pas long mais comme c'était la première duplication,
j'ai du construire et penser la structure.

Du coup c'est kool, j'ai plus que 1 site à gérer, ça simplifiera mon travail de sauvegarde des données.
Une ptite pause et j'écris la news sur Chartres annonces.

10h43 : euh avant corrigeons le flash pour les commerces... annuaire libre

---Grosse boulette de régis again, je me hacke tout seul !
Bref, pas envie de rentrer dans les détails

16h41 : mise au clair de mon système de modération, étape préliminaire pour coder correctement
le système de republication d'une annonce.
Le détail du système de modération se trouve dans la fac dans la partie systeme;


--téléphone, patatipatatata, et trucs personnels..
Putain j'ai l'impression de pas avancer depuis tout à l'heure.
Attaquons enfin le système de rotation-republication des annonces bordel de merde, et encore chui poli.
chips au lit.

19h15 : volonté ferme de niquer sa gueule au système de republication des annonces.
19h23 : écriture de la doc. (maintenant j'écris la doc avant, comme ça ça me fait un guide de développement
et en plus je l'utilise presque tel quel dans la fac, ce qui m'oblige à le concevoir de manière claire).

19h34 : amélioration comportementale : le lien qui mène vers l'aperçu s'ouvre dans la MEME fenêtre,
c'est plus agréable.
19h34 : le champ republication_id est en place dans la table annonce_en_attente et effectif sur le site en local.

19h35 : volonté d'écrire un script qui écrira un republication_id pour chacune des annonces.
Le but est de l'écrire en local d'abord.

pause le temps du plantage de netbean suite à un raccourci clavier foiré de ma part

19h52 : écriture du script réussie en local.

pause

19h58 : reprise, alors, quoi ...

maintenant occupons-nous de la requête qui sélectionne les annonces à relancer.
Ben le script de relance en fait...

20h01 : Ca y est je commente mon code naturellement, je deviens bon ?
ou rêve d'un débile profond ?


20h38 : Bon j'ai un peu pris mon temps pour tester les fonctions date mysql, vite fait :

Ca, c'est pour relancer toutes les annonces plus vieilles d'un certain temps.
$relanceTime = ANNONCE_LIFETIME;
$stmt = "
select id, date, republication_id from annonce_en_ligne
WHERE TO_DAYS(NOW()) - TO_DAYS(date) >= $relanceTime
ORDER BY date DESC
";

20h56 : le script de republication d'une annonce est actif.
21h06 : le mail de relance est écrit d'un jet.
22h18 : le système de republication d'une annonce me semble fonctionnel en local;
avec 3 tables en jeu;
Je vais faire un schéma pour voir si c'est sûr que déjà sur le papier ça marche,
je le mettrai dans la faq.


22h29 : Sur le papier ça fonctionne, comme sur mon poste.
Je vais écrire une doc à l'attention des développeurs php dans mon cas,
c'est à dire ceux qui ont besoin de savoir ce qui se passe sous le système.

22h49 : le schéma est fait, faut que je le mettes en ligne dans la fac,
même si il est pas encore opérationnel, il le sera certainement demain...

23h25 : écriture dans la fac en local, et petite modif sur le schéma.

Il faut maintenant que j'élabore ma stratégie avant de procéder...
Le but est d'intervenir le moins possible sur le serveur.

23h50 : création d'une possibilité de mettre le site en maintenance.

petite modif sur l'organisation du cache, en département cette fois.
1h14 : tiens ! jade a mis un commentaire dans evolution : génial.
Par contre il faut que je fasses des petites modifs car le lien vers le pseudo n'est pas actif et je ne peux pas mettre de commentaire sans valider...


03h21 :bon, je suis confronté au problème suivant : lancer une tache cron qui doit connaitre l'id du département,
pour envoyer les mails en signant avec le bon nom du site.
Je pourrais le récupérer à partir de l'annonce concernée, mais faudrait voir pour une autre solution.
Bon là vais m'coucher.
Heureusement en mars ya 31 jours, ça me fait un jour supplémentaire à développer sur Tours annonces.

**** 28-03-2010

06h35 : start
Hélas mon logiciel de téléchargement se déconnecte, ce qu'il faut que je sois derrière lui.

Bon, pendant qu'il continue à rappatrier les photos, terriblement long,
je vais penser au système pour qu'il puisse être exploitable sur toute la France,
ça m'évitera de faire la boulette hier : effacer Chartres annonces, sans sauvegarde récente.


07h44 : en observant ma page d'accueil, j'ai finalement trouvé un erreur,
il y avait donc bien une erreur;
Les performances sont améliorés par 10 en corrigeant cette erreur :
0.4s au lieu de 4s
et le cache divise encore presque par 10 ce nombre.
Ca c'est fait.


10h22 : tous les codes postaux sont dans ma base;

10h27 : mise à jour du comportement "national" sur la page d'accueil pour les annonces;
La page est sensiblement plus lente, normal.

10h35 : ajout du comportement national sur toute la page d'accueil.

10h47 : apprenitssage sur le net de divers articles concernant la sécurité.

11h39 : "nationalisation" pour la partie annonces.
11h51 : ajout de la "nationalisation" pour la partie commerces.
...
choses de la vie

23h26 : bon ça y est je viens d'enlever tous les trucs bizarres du site au niveau de la faq et
de la partie evolution, des tests de webmasters...
Oups seulement 2 annonces postées, bon avançons...
En fait pour l'instant, pas besoin de cache, enfin c'est pas urgent, les performances restent
acceptables et le gain engendré par le cache n'est pas toujours évident, bizarre, à étudier de plus près...
Au programme ce soir :
faire le système de rotation des annonces : tous les 2 mois.
Au bout de ce temps moins quelques jours, une relance mail doit être faite à l'utilisateur, et lui permet de relancer son annonce.
Relancer toutes les annonces vieillent de plus de 2 mois une dernière fois.
Faire un mail général à tous les utilisateurs pour leur annoncer la nouvelle version.
Améliorer mes techniques de sauvegarde.
Remettre ce blog en place.
Remettre chartres annonces en place.
Dans l'urgence, j'ai fait une reinstall du système,
et j'ai carrément effacé Chartresannonces (régis où es-tu?), ma dernière sauvegarde de chartres annonces remonte à perpet.
C'est mort pour cela, autant recommencer viergement, et tester donc le système "national" par la même occasion;

Mais cela met bien en évidence mon point faible : la sauvegarde régulière d'un système.

Si j'ai fait la moitié de ce que j'ai dit là ce soir, c'est bien...
allez, attardons-nous sur le système de rotation.

Ben comme ça de manière abstraite, ça a l'air tellement fastoche que je vais décrire le scénario ici :
une tâche cron est exécutée une fois par jour.
Cette tâche exécute les actions suivantes.

regarder toutes les annonces dont le temps est inférieur à :
AUJOURD'HUI - ANNONCE_DUREE_VIE + ANNONCE_RELANCE_TIME
Pour toutes ces annonces envoyer un mail de relance à l'utilisateur.
Pour éviter que le jour d'après le même mail soit envoyé à l'utilisateur,
nous créérons une table qui stockera le fait que nous avons envoyé un mail à cet utilisateur à telle date.
relance_annonce pourrait être le nom de cette table;

La relance, c'est une chose, mais notre processus sera également constitué d'une 2ème partie,
qui, pour des raisons de propreté de code, sera codée dans une autre tâche cron.
Cette 2ème tâche sera encore plus simple : elle regardera chaque soir les annonces qui sont vieilles de plus de 2 mois et les effacera.

Ah oui, j'oubliais, ce soir : vérifier/corriger aussi la notification mail entre utilisateurs...
Ah oui, et aussi mettre une autre photo par défaut pour les annonces sans photo, le transparent c'est bof...
En fait, je me donne jusqu' à la fin du mois pour finir le travail.
Appelons ça la période de décompression.
Ah oui, expliquer comment cacher son mail dans la faq.
Ah oui, et l'ajax loader pour le chargement des photos;..

Bon chui dead, que la nuit me donne des forces, la période de décompression va être un autre rush pour moi...

**** 27-03-2010

07h13 : start :
Sans déconner !!!
Il est même pas à 20%.
Bon ben je vais refaire le logo en attendant.

09h41 il est à 42% des photos des annonces...

J'ai trouvé un moyen kool pour bien utiliser le cache;..

En fait, si on part du principe que je sais appeler une tâche cron toutes les heures
qui efface les caches à effacer,
le problème est la création des caches.
Sans technique supplémentaire de ma part, le premier utilisateur qui ouvrira une page
crééra le cache pour CETTE page (conditionnée par tous les paramètres de liste: tri, numéro de page, catégorie, prix, mots pour le moteur de recherche ...).

Hélas, le nombre de paramètres d'une liste est important si bien
qu'il est fort possible que les utilisateurs n'utilisent le cache que occasionnellement alors que
le but du cache est d'être utilisé un maximum de fois.

Pour maximiser le nombre de fois qu'un cache est utilisé, et pour réduire le temps d'attente de l'utilisateur,
mon idée est de créer le cache à l'avance;
Je ne l'ai pas encore fait, mais je viens de faire un test concluant qui me prouve que cela va fonctionner :

$handle = fopen($fileToOpen, "r");

Cette fonction toute simple php permet d'ouvrir la page $fileToOpen.
Génial.
Exactement ce dont j'ai besoin, pas besoin de sélénium ou autre.

Ainsi, en faisant une simple requête dans ma table des statistiques (que je devrais peut être mettre à jour avant afin qu'elle récupère toute la chaîne
$_SERVER['REQUEST_URI']), alors, si ce n'est pas trop gourmand en ressource, l'idée et d'appeler toutes les url stockées dans cette table;
Ainsi, la création du cache est invisible pour les utilisateurs.

Le point sensible est le suivant :
cette technique consiste à dire qu'à chaque fois qu'un appel à une liste avec un nouveau paramètre est crée,
il est enregistré en bdd et sera recrée.
Au début c'est très bien,
après aussi, mais il faudra juste être attentif lorsque de nombreuses pages auront été créées : combien de temps ce processus va-t'il mettre à ouvrir toutes les pages.
Dans tous les cas, mieux vaut que le système trime tout seul plutôt qu'il pénalise en plus un utilisateur.

Mon premier test de performance donne ceci :
J'ai mis 6.4726099967957 secondes à m'éxécuter pour 9 entrées
J'ai mis 7.0770411491394 secondes à m'éxécuter pour 9 entrées
J'ai mis 6.166090965271 secondes à m'éxécuter pour 9 entrées

Juste pour tester, en utilisant la fonction file à la place de fopen:
J'ai mis 10.84568810463 secondes à m'éxécuter pour 9 entrées

10h16 : mise à jour d'une table pour enregistrer les performances de recréation de stats
schema-stat2.png


10h18 : 49%...



Tests sur le cache : excellent, pas de mauvaise surprise, et le fait de tout passer dans l'url
apporte une facilité de gestion des plus agréable.


10h25 : 50% Putain, et pendant ce temps les utilisateurs mettent des annonces,
the nightmare continues...


Ma procédure de rappatriement est trop lourde, mais bon...
keepkool.


Bon tant pis je mets en ligne maintenant, sinon je vais me faire trop enchaîner...
non, au moins attendre que toutes les photos soient chargées, oh et puis si.
Hélas ça entrainerait encore plus de complication à cause des droits sur les photos.
Tant pis, j'attends...

11h49 : bon ça y est c'est en ligne,
malgré le stress que la version en ligne soit complètement buggué, je préfère cela plutôt que d'essayer d'enlever l'eau d'un bateau qui prend l'eau.
La, on a un bateau tout neuf, il suffit de le retaper ;)

La bonne nouvelle, c'est que je peux continuer l'upload terriblement long des photos tout en débuggant le site.

?? : hacké, misère.

17h44 : Ce qui est bien c'est que j'apprends vite.
Je ne sais pas comment le hacker a fait, mais
l'environnement linux me fait de moins en moins peur.
Et là, c'est avec une douce agréable surprise que je constate que les fichiers se chargent plus vite.
Comme sur windows en fait, parès une reinstall du diskdur...

Maigre compensation par rapport au crime, mais c'est toujours agréable.

**** 26-03-2010

07h02 : start :

Bon aujourd'hui c'est mon dernier jour de travail, il y a encore plein de trucs qui vont pas : l'automodérateur,
les liens non satisfaits, le plan du site, la gestion du cache.

07h03 : quand netbeans aura fini son scan, je ferais le plan du site.
Cela doit me prendre une heure.

07h43 : en fait je vais le faire à la main.
08h16 : Ok.

Pause

choses de la vie

17h10 : le système d'automodération est en place d'une manière que je trouve propre;
J'ai pu également me frotter aux nombreux conflits de permissions dus aux droits des images,
ce qui améliore mon expérience.
Reste le système de cache et un gros débuggage général, et enfin la mise en ligne avec un gros rappatriement
des données.
Pfiou, beaucoup de boulot pour quelques heures...

Vu le temps qu'il me reste, commençons par le débuggage.

choses de la vie

04h36 : en train de poser les photos des annonces sur le serveur, c'est long, très long.
Il me restera le système de gestion de cache à mettre en place, sinon ça va ramer grave...

En plus il y a certaines photos manquantes, disons que j'ai le droit à un pourcentage de perte,
comme à la guerre.

Bon j'ai au moins 1 heure devant moi, ptit somme fera du bien...

05h21 : putain, le logiciel s'est deconnecté pendant mon somme.
On remet ça...

06h30 : et le logiciel n'a même pas chargé 20%¨, gasp !
Bon ben je vais finir ma nuit...

**** 25-03-2010

05h29 : start

06h39 : Les photos en front office sont rappatriées, correction de bugs.
06h56 : mise en place du backbouton "intelligent", qui ramène toujours à la dernière liste visitée.

07h20 : correction sur l'affichage des prix

08h56 : Travail sur l'offre commerciale et corrections diverses.

08h58 : Déplacement des statistiques sur une page dédiée.

09h05 : déplacement des news sur une page spécialisée

09h34 : maquette rapide de la page d'accueil.
screenshot155.png

Mon but est de faire des grosses sections : annonces, commerces, plus tard événements, ...
et que en fonction du nombre de visites, l'ordre d'affichage des sections est déterminé.
(tiens c'est marrant je commence à parler comme yoda).

pause avant l'intégration...

10h09 : ling is in the place.

14h58 : pourquoi faut-il que netbeans me lâche maintenant :
il scanne sans arrêt et met 3 plombes à résoudre les dépendances,
obligé de continuer avec ... notepad...

17h48 : La page est intégrée,
j'avoue avoir bien pris mon temps, mais cela fait partie de ma méthode de travail.

17h51 : création d'un lien "suggérer un bug" dans le footer qui amène sur le formulaire
de contact avec le sujet prérempli.

choses de la vie.

Bon, ma mission ce soir était de passer à php5.3,
mission foirée.
Par contre j'ai réussi à passer de Debian Etch à Debian Lenny et à passer à Php5.2.13.
A ma grande surprise le site ta5 a l'air de fonctionner sous cette version de php,
à vérifier.

Bon demain c'est mon dernier jour de travail, il y a encore plein de trucs qui vont pas : l'automodérateur,
les liens non satisfaits, le plan du site, la gestion du cache.

Où est la corde que je me pendes...

**** 24-03-2010

06h48 : start

En fait, j'opte pour le téléchargement direct.

écriture d'une news
Rappatriement des annonces (encore, suite à des tests)

pause

09h01 : désir de réalisation du système de todolist.
09h11 : création du schéma sql :
schema-todo.png


09h18 : le téléchargement des photos pour les annonces en ligne est terminé : cela a donc pris
exactement 2h30 !
Ca va, je pensais que 2h30 c'était le temps d'ouvrir le dossier, j'en ai fait un drame pour rien.

téléphone.

10h40 : le formulaire d'ajout de suggestion est opérationnel (fancybox)
pause
11h22 : ajout d'un message de confirmation de l'insertion de la suggestion (oubli de ma part)
 choses de la vie.

14h25 : Mise en place d'une liste5 de base pour mon admin qui m'affiche les suggestions en attente de validation.


14h43 : oups! en fait j'ai pas besoin de liste des suggestions, je ne valide pas les suggestions,
je créé une todotask à partir en éventuellement m'aidant d'une suggestion, ou de rien.


15h29 : l'admin semble en place, avec possibilité de marquer le statut parmi :
    const STATUT_EN_ATTENTE_DE_REALISATION  = 0;
    const STATUT_EN_COURS_DE_REALISATION    = 1;
    const STATUT_ABANDONNE                  = 2;
    const STATUT_REALISE_AVEC_SUCCES        = 3;

Le temps de fin s'ajuste automatiquement sur le datetime courant si l'état est	STATUT_REALISE_AVEC_SUCCES.

15h39 : affichage basique sur le site.
Allez un ptit screenshot pour la forme :
screenshot153.png


16h30 : amélioration de la liste
screenshot154.png
Ajout d'îcones en fonction du statut;
Lorsque l'utilisateur passe la souris sur le lien Inspiré par la suggestion #4,
la suggestion #4 se highlite en rouge.

16h34 : ajout du lien vers évolution dans le menu horizontal principal.

16h37 : correction d'un bug d'affichage en cas de store vide.

16h37 :
Je ne sais pas pourquoi mais l'affichage des annonces met :
2.2564549446106 s
à s'afficher en local, ce qui est évidemment au moins 2 secondes de trop,
je dois résoudre impérativement résoudre ce problème de fond (sans cache bien sûr)
avant de faire quoique ce soit d'autre...



17h55 : bon sang de misère, je ne trouve pas d'erreurs dans mon script !

choses de la vie.

22h25 : en fait, je peux relativiser et me dire que ce n'est que si l'utilisateur cherche globalement sur toutes
les catégories et toutes les communes que le script met entre 1 et 2secondes.
Sinon, si je choisis voiture par exemple :
j'obtiens :
0.55257415771484


Et plus la recherche est précise, plus le résultat est rapide.
Peut être ai-je fait une erreur de mettre toutes les marques et modèles dans mon arborescence ?
Hélas, plus le temps de faire des tests.
Mais à regarder de près.
Avec le cache, ça devrait panser les plaies les plus ouvertes...

Passons maintenant au dispatchage des photos par rapport à ma nouvelle organisation.

00h17 : quelques tests à petite échelle s'avèrent satisfaisant.
La chui mort, faudra faire ça demain.
Bon sang, c'est l'arrache total.

**** 23-03-2010

06h24 : start
Plus que 4 jours.
4 jours, c'est long ou c'est court ?
Ca devrait être très court.

07h27 : les spécialités sont rappatriées.
Découverte d'un bug bizarre sur le pagelink commun de mes listes...
pause
08h43 : Correction des liens à partir de la carte, mais le système de carte en soi n'est vraiment pas au point...
08h55 : bug sur le page link résolu, en fait comme d'hab le bug venait de moi, mis pas des listes.
09h14 : rappatriement des textes de présentation et indications supplémentaires des commerces.
09h34 : réécriture des mentions légales.
09h45 : réécriture des mentions légales. décidemment, j'ai un problème avec les mentions légales apparemment;
10h08 : amélioration des mentions légales. Rassurez-vous je fais autre chose en même temps...
10h20 : rappatriement de la page perso billythegrill
10h24 : rappatriement de la page perso gouttatout
10h48 : rappatriement de la page perso lileauxpizzas
10h53 : rappatriement de la page perso pizzaono
10h58 : rappatriement de la page perso lebloisphilippe (agréable surprise, je pensais que cela me prendrait une petite demi-heure)
11h14 : rappatriement de la page perso gouterchezsam (je ne fais que sous ffox par manque de temps...)
pause téléphonique
12h45 : rappatriement de la page lapizza.
Les autres commerces n'existent plus ou n'ont pas payé, donc z.

12h46 : Désir de rapptriement des vidéos.

téléphone..
14h43 : la vidéo de leblois philippe est en place.
14h46 : les vidéos de billy the grill et cap music sont intégrées.


14h56 : ajout du sous-titre aux blogs.
15h03 : mise à jour des différentes listes d'affichage de l'item web.
15h08 : mise à jour du formulaire d'ajout de site blog avec le sous-titre.
15h12 : mise à jour des moteurs de recherche pour qu'il recherche dans sous-titre
15h14 : correction bug affichage photo blog.
15h17 : correction d'un bug pour les stats du blog.
15h20 : création de la catégorie événements pour les blogs.
 téléphone;..

 16h07 : téléchargement des photos des utilisateurs.
 téléphone
 17h06 : les photos utilisateurs sont chargées;
 17h41 : rappatriement des news

 choses de la vie



 23h04 : dans l'urgence, j'ai juste killé tous les links des news qui mènent maintenant vers une page désuette.
 Je ferais mieux, quand avec le temps...


 00h25 : en train d'écrire un script shell qui me permet de prendre les fichiers photos dans le dossier
 qui est très très gros, et les extraire dans 3 dossiers en fonction des années dans un premier temps.
 ou autre chose, du moment que je puisse "rapidement" extraire ces photos du serveur;
 Vu mes connaissances en shell, il vaut mieux une bonne nuit de repos et un esprit vif.

**** 22-03-2010

06h39 : start
En fait, il y  a un point sur lequel je me demande si je prends la bonne décision :
si je supprime toutes les annonces plus vieilles de 2 mois,
est-ce que cela va fâcher des utilisateurs qui ont beaucoup d'annonces ?
En regardant les annonces des annonceurs ayant le plus d'annonces, il apparaît que certains ont des annonces datant jusqu'à 2008.
On pourrait se dire 2008, c'est mort, mais il y a toujours le doute que l'annonceur garde ses annonces quand même.

Bonbref, en fait je vais tout republier et au bout de 2 mois l'utilisateur recevra un message qui lui demandera s'il souhaite republier son annonce ou la supprimer.

En fait, dans la version ta4, j'avais proposé le choix temporaire - permanent,
je vais donc conserver toutes les annonces avec le statut permanent.
Et mieux redéfinir ces 2 cas, du coup à développer car rien n'a été fait à ce niveau.

temporaire = dure 2 mois.
Au bout de 2 mois, un testtest est fait pour savoir si l'on doit envoyer un mail à l'utilisateur, qui lui permet de la rafraîchir.

permanent = mode de republication automatique.
Une notification système est envoyée à l'utilisateur pour lui indiquer que son annonce a été republiée.

pause
14h36 : le rappatriement des blogs, en gros, est effectué.
pause

17h19 : une grosse erreur de ma part était de vouloir refaire toutes les catégories :
2 inconvénients : c'est très long à faire (dans le sens où il faut convertir toutes les anciennes catégories en
nouvelles),
et je ne suis pas sûr que les nouvelles catégories plaisent mieux que les anciennes.

Bref, c'est certainement très bête, mais maintenant c'est fait...

00h13 : oups,
ça risque de mettre plus longtemps que prévu,
peut être demain ou après demain (encore...)

Là, j'en suis aux commerces, les spécialités...
J'ai fait les annonces, sans grosses vérifications, et sans les photos.

J'ai fait la partie web.
Me reste les news, les commerces, et les annonces bien, avec photos;


Et surtout mettre php à jour...
C'est pas gagné...

**** 21-03-2010

06h33 : start :
Après une première rencontre avec les problématiques liées au transfert des données de TA5 vers TA5.

14h03 : oups mes fichiers de véhicules ne sont pas bons.
Il manquait 1 espace dans ma regex !

16h04 : oups, je me rends compte que le modèle de la centrale n'affiche que les marques à partir du moment où il y en a au moins une.
La liste que j'ai n'est donc pas exhaustive.
Il faudrait que les utilisateurs puissent proposer leurs catégories plus tard...

17h42 : ok pour les données des annonces section voitures..., mais sans les photos.

choses de la vie...

Bon, ça avance, j'ai bientôt fini les annonces, mais j'ai pas tout vérifié, et je parle pas de photos.
Je pense que j'aurai fini demain soir ou après demain soir pour le rappatriement du site.
Par contre, je vais enlever les annonces de plus de 2 mois,
ca va faire un gros vide du coup,
Je croyais avoir mis cela en place sur la v4, mais cela n'avait pas fonctionné et j'ai jamais pris le temps de corriger le problème...

00h44 : good night u.

**** 20-03-2010

05h24 : start

00h26 : dodo

;)

**** 19-03-2010

06h12 : start

scrogneugneu...
avec le recul j'aurais du faire une seule table pour les questions et réponses pour la FAQ, cela m'aurati permis de partager au moins l'id.s

08h50 : mise à jour du schéma sql
schema-faq2.png
08h56 : mise à jour de l'affichage dans la fac.
09h00 : mise à jour de mon admin pour la faq.


11h26 : ajout de la possibilité de passer des constantes dans la faq.


choses de la vie.


17h55 : ajout du détail d'un promo

choses de la vie...

23h37 : bon j'ai pas fini la FAQ, mais j'ai bien dégrossi la partie sur les offres commerciales.
00h19 : bon demain je commence le rappatriement des données.

**** 18-03-2010

06h59 : start

création de l'offre compte de base et compte vendeur ok.

pause

09h57 : c'est marrant, c'est en écrivant la faq que je me rends compte de ce qu'il manque concrètement sur le site,
par exemple j'ai oublié de faire la notification de décision d'acceptation/refus d'un commentaire qui est adressée à l'utilisateur,
pour l'informer si son commentaire a été validé ou refusé par le commerçant.

Bref.
10h26 : la notification est créée, et quelques minibugs corrigés.


Voici le genre de textes que j'aime bien :
qui servent à la fois pour la FAQ et à la fois pour moi en tant que guide de développement
et même référence de l'application...

notification système :
Une notification système est un message à caractère informatif dont :
- l'expéditeur est le SYSTEME TOURS ANNONCES
- le destinataire est un utilisateur X
- le mode de transmission du message est déterminé en fonction des préférences de l'utilisateur X;
Par défaut, l'utilisateur X recevra la notification système dans son compte Tours annonces > messages, onglet Messages Système
De plus, si l'option "Faire une dérivation des notifications système vers ma boîte mail" ( dans moncompte > profil > Mon compte Tours annonces ) est activée,
alors l'utilisateur X recevra également la notification système dans sa boîte mail (email indiqué sur le compte Tours annonces de l'utilisateur X).


11h28 : le système est en place.

Par rapport à l'orientation de mon écran et l'intensité du soleil,
j'ai tout le soleil dans la face, ce qui est très appréciable,
par contre je vois quedalle des fois, en fait il faut me forcer.
Et quand j'ai besoin de regarder l'heure qui est tout en bas à droite,
là c'est mort.

Je vais voir si yapas une montre en javascript quelque part;

ah ben plus le temps...

choses de la vie


14h39 : de retour au devant le pc, j'ai ma nouvelle imprimante, une samsung CLP310.
Pour l'instant elle fonctionne (encore heureux).

17h06 : en train d'écrire la FAQ, (très long),

choses de la vie ...

00h33 : bonben pas fini la FAQ, oups...

**** 17-03-2010

07h01 : start

Comme il fallait s'y attendre, mon diagnostic d'hier concernant le reste des tâches techniques à faire est incomplet.

En fait j'ai oublié de mentionner l'automodérateur, qui va m'aider à valider les annonces.
Sinon, ce matin, sous la couette, j'ai conceptualisé le système de cache de Tours annonces,
ça m'a pris moins de 10 minutes, et cela est tout à fait normal vu qu'il n'y a pas grand chose à conceptualiser.

Si j'ai mis le moteurs de recherce en GET, et que mon référencement en sera fortement affecté (en négatif),
c'était non seulement pour me permettre des facilités de débogguage, mais également pour le permettre des facilités de mise
en cache.
Les triggers de liste5 sont également tous orientés dans cette perspective :
en fait tous les paramètres de mes listes transitent dans la barre d'adresse (GET),
aussi,
il est très facile d'identifier une page, n'importe laquelle, par exemple la 4ème page avec tri descendant sur les prix,
pour la catégorie voiture, marque peugeot, et toutes les communes,
bref tout,
TOUT est dans l'url.

Donc la mise en cache est hyper fastoche : je prends l'url et je créé un fichier à partir de cette url : il sera forcément grâce au fait
que tous les paramètres identifiant la liste se trouvent dans l'url, basta.

Pour la modération, j'aime que ça soit simple :
toutes les listes seront soumises au systéme suivant :
-effacement périodique toutes les X minutes, où X vaudra 20 au lancement, ce sera une tâche cron.
-possibilité dans l'administration d'effacer manuellement le cache.

Basta.
En fait il n'y a rien de difficile dans la mise en cache des listes du site.
Maintenant, il ne faut pas que j'oublie la mise en cache des select dans les formulaires, et notamment le plus visité :
celui du moteur de recherche d'annonces.

Pour cela, le système est nettement plus complexe:
Les catégories doivent se mettre à jour automatiquement lorsque j'ajoute une catégorie.

En fait cela revient à créer un script placé au moment du formulaire d'ajout d'une catégorie, auquel seul moi ait accès,
et qui fait en sorte que en fonction de la catégorie ajoutée, les caches des selects du site situés à des endroits que ce script connaît
sont effacés.

Voilà, en gros.

Ah oui, et dernier point à voir, lorsque les listes du site sont effacées, il y a toujours un utilisateur malchanceux
qui se tape le rechargement des listes, j'aimerais, après avoir fini ce premier travail, éviter cela et lancer un robot
qui revisite automatiquement les pages du site (si c'est possible, peut être avec sélénium?) afin d'éviter un temps de chargement
très long à l'utilisateur. (quoique en fait ça me paraît démesuré, on verra)


Commençons donc par l'automodérateur...

Hmmmm,
le problème si je le mets au niveau du formulaire d'ajout d'annonces, comme dans la v4,
c'est que si l'automodérateur valide l'annonce, il le fera directement, et l'utilisateur ne sera même pas au courant que j'ai créé tout le système derrière,
il croira qu'il peut mettre toutes les annonces qu'il veut, et... tant pis c'est pas grave,
l'autre solution était d'appeller l'automodérateur toutes les 20 minutes, juste avant l'effacement des listes en cache,
mais ...
non ok, je pense que je vais faire un automodérateur appelé périodiquement.

Merde, en fait j'ai besoin d'installer php 5.3 pour faire mes tests sur le serveur en prod, mais j'ai trop peur de foutre la merde,
n'étant pas du tout sysdamin, je suis incapable de réparer et même de diagnostiquer en cas de problème,
je ferais mes tests ce soir, quand la plupart des gens n'utiliseront plus Tours annonces.


Cela ne m'empêche pas de faire le systèe de cache....

pause.

09h58  résolution d'un bug d'affichage mineur..

Mon diagnostic sur le cache des listes est bon, mais maintenant on entre dans le concret....
La question est cruciale : où mettre le système de cache.

Tout dépend du fichier,
nous allons distinguer
-les listes : 20 minutes
-les pages quasi statiques : l'accueil par exemple ne change que si il y a une nouvelle news, ou plus tard, si de nouvelles photos sont ajoutées.
Appelons les plutôt pages à cache conditionné

pages à cache périodique
pages à cache conditionné
pages sans cache.

typecache =
cp
cc
sc


Nous ferons théoriquement 3 dossiers, mais donc 2 (débile) :
cache-periodique
cache-conditionne

Les identifiants de page des fichiers impactés par le cache périodique sont :
annonces/liste-annonce

Ben ouai en fait c'est tout pour l'instant parce que pour les autres, j'ai le temps de voir venir...

Les identifiants de page des fichiers impactés par le cache conditionné sont :
commerces/liste-commerce
commerces/liste-promo
commerces/liste-evenement-a-venir
commerces/liste-evenement-passe
commerces/liste-cadeau
taostore

On pourrait pousser la logique dans les listes de mon compte, mais pour l'instant on va faire déjà ça.


Les nombre d'identifiants de page des fichiers impactés par le cache périodique pourra
très bien augmenter dans le futur,
par exemple
commerces/liste-commerce
pourra passer un jour en cache périodique ?

Il faut donc prévoir une méthodologie plutôt qu'un cas par cas.

En fait c'est très simple, je vais créer une variable dans l'index qui me dira si le type de cache
de la page : cp, cc ou sc
si cp, sauver le cache si il n'existe pas sinon l'afficher.
si cc, idem
si sc rien.


10h24 : ajout du champ time dans ma table de statistiques,
le champ time est un float qui représente le temps de calcul de la page par php.
Ainsi, avec une simple requête sql je pourrai savoir quels sont les scripts qui mettent le plus longtemps à charger et donc travailler sur eux en priorité.
mowHAHAHAHAHAHAHA, machiavélique....

10h56 : le système de mise en cache est en place basiquement, pour le cache périodique.
Un truc que j'adoooooooooooore faire, c'est constater le gain de performance entre
sans le cache et avec le cache.
sans cache : 0.19989395141602
avec cache : 0.0085930824279785

mowHAHAHAHAHAHIHIHIHIHOHOHOHO

Evidemment, maintenant il faut échapper les caractères spéciaux...


Ok,
Par contre, il faut être conscient que si le script renvoie une erreur, l'erreur est en cache également
et là c'est la honte car tout le monde la voit, et rapidement en plus.

Ce n'est qu'après coup que je constate ceci (c'est pour ça que chui développeur du dimanche) :
du fait que l'utilisateur peut choisir librement son prix min et max pour les véhicules,
et pire: le prix min max et la surface min et max pour l'immobilier :
le nombre de paramètres différents possibles est tout de suite énorme, si bien qu'il devienne rare, voire exceptionnel
que 2 utilisateurs utilisant ces paramètres aient exactement les même, ce qui réduit l'effet bénéfique du cache sur ces listes.
Je pourrais prier et me dire que les utilisateurs n'utiliseront pas beaucoup ces catégories,
manque de bol, immobilier et véhicules sont peut être les plus visitées, ah.
C'est pourquoi il aurait été judicieux de canaliser les requêtes en créant des filtres sur les listes,
en proposant par exemple des fourchettes de prix ou/et de surfaces.
Bon, ceci dit, j'aime bien que l'utilisateur soit libre, et j'ai pas beaucoup de temps.
Si ça passe comme ça je laisserai comme ça, et si il le faut je ferai les fourchettes.
Intéressante remarque...


Il me reste moins de 20 minutes pour créer dans l'admin un outil qui me permette d'effacer les listes de cache.

Ca y est, sans vérifier.
Sauvegarde antirégisque.

11h36 : ouf . Ca y est, pas de fautes.

choses de la vie...

13h59 : agisson vite mais bien;
je ne vais pas faire un système de cache très compliqué.
Pour le cache conditionné, en fait, j'ai anlaysé que ::
cela revient à créer un cache statique, qui est effacé selon certaines conditions.
Ces conditions sont l'ajout ou la modification d'un item de la liste pour les listes,
ou d'un élément de la page pour d'éventuelles autres pages.


Mon rôle va être de centraliser les chemins d'accès aux caches afin de ne pas tomber dans le piège dans lequel
je tombe si vite : la multiplication de méthodes similaires : éparpillement des données, confusions au niveau de la conception,
et plein d'autres ennuis...


Un objet unique centralise tout cela.
Go.
Mon idée est de créer l'objet Tan_Private_Cache
qui a pour méthodes statiques :
createConditionalCache(îdPage)
deleteConditionalCache(îdPage)

Ces 2 méthodes font appel à la propriétét statique
$aCachePath =  array(
	'identifiantDeCache' => 'nomDuDossierDeCacheAEffacer',
	'identifiantDeCache2' => 'nomDuDossierDeCacheAEffacer2',
);

Cela implique que tous nos caches soient dans des dossiers et on n'a pas la précision de choisir quel fichiers de cache on élimine.
Mais la manière dont sont imbriqués liste et items est complexe et variante d'une liste à l'autre.
Par manque de temps, et par souci de simplicité, mon cache sera global.

14h42 : Le système de suppression du cache est fonctionnel, avec simplement 2 fonctions, je n'ai pas créé les classes mentionnées ci-dessus,
car pas nécessaire.

Par contre, je pense que pour commerces ça ne vaut pas le coup,
en fait je passe tout en cache périodique c'est plus simple.
Voilà, ça c'est fait...

Bonben comme je vais attendre d'avoir php5.3 pour tester, du coup je retourne sur l'offre commerciale.
Ahnon j'ai oublié le cache des listes select des moteurs de recherche;..

En fait je peux pas, c'est débile, mais si je mets ces listes en cache, comment puis-je différencier l'état select ?
en javascript ?
C'est une limite que je ne veux pas dépasser.
En fait ce qui m'embête c'est surtout la liste de website qui met 0.6s à s'afficher.
Certainement parce qu'elle supporte mal la profondeur de l'arborescence.

15h27 : En optimisant la requête de sélection, j'arrive à obtenir
0.13s.
C'est beaucoup mieux, ça me va.


Pour mes statistiques, je vais ajouter le champ cache qui vaudra
from-cache
create-cache
ou rien

Cela me permettra d'avoir une idée plus précise sur ce que les gens recherchent et le but est d'arriver à mapper au mieux
les caches avec les requêtes... enfin sur le long terme.

pause

15h44 : le système décrit juste avant est en place.



choses de la vie

23h25 : la page offre commerciale offre compte-vendeur est créée,
mais les liens ne sont pas encore déterminés.
Chui un peu dég d'avoir passé toute la journée sur ça, mais bon...


Maintenant, la partie ultra délicate où Régis va peut être ressortir..
Gloups...

Mise à jour de php sur le serveur en prod...

00h17 : bon j'y arrive pas,
c'est au-dessus de mes connaissances en linux.

Je demanderai demain conseil à qqn si il peut m'aider.

Je vais devoir m'organiser autrement donc,
on va dire que demain j'essaie de terminer les offres commerciales et le plan du site, et la faq, et essayer d'avancer sur php5.3

Et sinon, je commence la conception du rappatriement.

Blasé...


Au fait voici un jpeg de mon offre compte-vendeur
screenshot152.png

**** 16-03-2010

06h51 : start :
Hélas les choses de la vie vont mem prendre de plus en plus de temps, temporairement, mais au moins jusqu'au 27 mars,
= moins de temps de développement
= j'ai vraiment intérêt à me mettre en mode decapant.


Ahnon, en fait la liste des annonces n'affichait pas les annonces non validées, j'ai du halluciner...


07h45 : le switch au niveau des marques impacte la requête,
de même pour les prix, 4 conditions réparties par groupe de 2 permettent de cibler tous les cas de prix.

07h53 ; Ide m pour l'immobilier.
Il ne me reste plus qu'à  faire transiter les nouvelles variables d'une page à l'autre...

08h06 : Ca y est le moteur de recherche est complètement fonctionnel, fastoche avec liste5.

Et après ?
On pourrait penser à un moteur de recherche statique sur une autre page, très poussé (recherche dans les options par exemple),
mais alors là c'est vraiment pas urgent, je le mets quand même sur ma todo liste pour la session de mai.

Avant de faire google map,
je vais voir le nb de visites des items : annonces et webitems (commerces ont déjà leur système de stats.)

Bonben le compteur a priori ça va être très simple :
un champ compteur pour les annonces en ligne et un pour les webitems en ligne;
Chaque fois que la page de détail de l'annonce ou du webitem est chargée, ce compteur est incrémenté de 1.
L'affichage du détail sera modifié pour afficher le niveau du compteur.

Commençons par modifier les schémas sql.
Oups, apparemment j'ai déjà prévu le coup dans webitem : le champ compteur_visite existe déjà.

08h18 : ok, le champ compteur_visite existe pour les 2 tables qui m'intéressent.

Passons maitenant directement à l'affichage dans le détail des items.
Ok pour les annonces, le rendu est ok dans tous les 4 navigateurs testés
screenshot148.png

08h29 : le comportement est fonctionnel pour annonce, passons à webitem.

Bon, pour les webitems c'est un peu différent dans le sens où il n'y pas de détail,
il faut en fait récupérer le nombre de fois que le blog ou site a été visité.
Je vais placer une fonction javascript qui sera lancée à chaque fois qu'un visiteur humain (et utilisant javascript)
cliquera sur le lien vers le site.

Mais faisons d'abord le html.

08h38 : ouf : même rendu pour les 4 navigateurs.
08h58 : dépatouillage de logique : la liste web n'était pas faite de la même manière que celle de annonces.
Bref, maintenant création du webservice.
09h02 : bien.
Maintenant créons la fonction javascript qui appellera ce webservice lorsque l'utilisateur cliquera sur le lien du blog/site.

Je sais que ce n'est pas recommandé d'utiliser toute la librairie jquery juste pour cela alors qu'une simple fonction javascript aurait suffi.
= moins de 1Ko Vs 55Ko
Mais je connais pas bien le javascript, et je me dis qu'à force de naviguer sur mon site l'utilisateur aura forcément la librairie jquery en cache au bout d'un moment.
Sauf cas exceptionnels...

pause

09h28 : Ca y est, la fonction est en place.
On pourrait faire la même chose avec le profil d'un utilisateur, mais gardons cela pour la session de mai.

Passons maintenant à Google Map,
et là ça va devenir vraiment intéressant;..

Pour commencer, je dois me rappeller mon expérience perso avec google map : google map ne trouve pas TOUTES les adresses.
Des fois 50-52 rue de la Bourde par exemple (n'importe quoi) n'aura pas de correspondance sur le plan.
C'est pourquoi, toujours aussi ingénieux que je suis, je propose 2 adresses pour les commerces : une normale et une google map.
La normale est celle remplie par les commerçants lors de l'ajout d'un commerce.
La googlemap est une copie de l'adresse normale, les commerçants ne la voient pas, mais elle est présente en base de données.
La personne qui va contrôler le commerce A POUR RESPONSABILITE de vérifier que le google map trouve l'adresse AVANT de valider le commerce.
Si google map ne trouve pas, le contrôleur peut et doit changer l'adresse juqsu'à ce que le plan trouve...

Deuxièmement, toujours d'après mon expérience,
avec les sous-domaines, j'ai du faire autant de demandes d'autorisation google map que de sous-domaines.
Très très lourd à gérer, très chiant, pas pratique...

Maintenant, j'ai trouvé une solution pour contourner le problème :
un seul nom de domaine, et quand bien même plusieurs noms de domaines,
créer un seul script d'affichage qui prend quelques paramètres et le placer sur un sous-domaine,
puis afficher le plan par des iframe dans le site.
Je n'ai pas testé cette technique, mais normalement, ça devrait le faire.

Bon avant de commencer, voyons voir du côté de jquery,
j'avais déjà utilisé une api bien faite de jquery-googlemap pour un autre projet,
et j'avais abandonné à cause de ie6, mais maintenant je n'aurai plus ce problème.
ie6 is dead : let the webmaster be.


Oh putain ça déchire
http://marcgrabanski.com/webroot/resources/jquery-ui-google-maps/tutorial-part1.html

J'ai toujours trouvé que ce que produisait ce mec était bon, ça c'est un bon gars qui déchire...
http://marcgrabanski.com/article/jquery-google-maps-tutorial-basics

10h01 : en plein dans le tutorial, ben en fait je peux tester en local, kool.

Ici, c'est pratique pour trouver un point
http://itouchmap.com/latlong.html


10h28 : en fait le tutorial est pas vraiment ce que je veux faire ...
ici c'est mieux...
http://code.google.com/intl/fr/apis/maps/documentation/

11h08 : Bon, je peux faire une intégration basique de google map,
avec les controls,
mais basée sur des points, j'aimerais trouvé concrètement
une manière de faire qui me simplifie la vie (je me vois mal placer les points un par un...)


screenshot149.png


Apparemment dans la version précédente j'utilisais l'objet GSmapSearchControl,
mais je vais mieux me renseigner avant de faire n'importe quoi.
Ah ben tiens justement :
http://code.google.com/intl/fr/apis/maps/documentation/services.html#Geocoding

Bon, effectivement, c'est le bon objet (Geocoder).
Il me reste juste à récupérer les données du commerçant pour les afficher dans la petite bulle;
Bon, depuis tout à l'heure cela fonctionne mais j'essaie d'ajouter des events, pour que quand on passe la souris sur le point
par exemple, la bulle s'affiche, mais j'y arrive pô. (m'affiche des erreurs javascript au secours...)
Tantpis, je vais pas passer trois heures su ça.

Passons maintenant à l'ajout donc d'un champ spécial googlemapadress dans la table commerces, et impactons le formulaire.
Ok pour l'ajout du champ sql, mais par contre là il me faudrait vraiment les codes postaux sinon ça augmente carrément les chances que l'affichage foire
au niveau du map...


http://nrco.co.nr/list-of-france-postal-codes


pause


Le plus simple serait certainement d'ajouter un champ code postal à la table des communes,
mais en fait pour garder la propreté, je vais faire une table séparée.

En fait non, c'est vraiment trop dangereux après pour les liaisons sql, je vais juste rajouter un champ à la table commune.
Au pire, certains codes postaux manqueront et je les ajouterai à la main.

14h18 : simplement en remplaçant ST par SAINT et les espaces par des tirets, j'ai pu effectuer cette manip facilement
(je me suis crée un script qui fait cela.)

Google recommande de géocoder au maximum à la main les adresses,
malheureusement je n'ai plus beaucoup le temps,
je dois avancer, espérons que cela ne soit pas trop lent.


Remplacement dans le formulaire d'ajout/modification
Mise en place dans le plan.
Ok.
Mise en place du formulaire spécial de changement d'une googlemap address : seulement pour l'admin.

Maintenant il me reste un dernier problème et ce sera bon pour googlemap :
par défaut le plan s'ouvre avec les coordonnées du centre de Tours, j'aimerais
qu'il s'affiche avec directement les coordonnées du commerce.
Non, vraiment j'y arrive pas, bon tant pis, la suite svp...


Essayons de corriger le calendrier des événements, qui est compètement buggué sur tous les navigateurs sauf firefox.

15h54 : ouf, ça y est j'ai trouvé, c'était un truc bizarre en css...


16h41 : j'avais envie de me faire plaisir :::
screenshot150.png

16h56 : et une deuxième pour le fun
screenshot151.png

Mais ça me rajoute du boulot...
Les 2 bannières tourneront de manière aléatoire...

17h55 : Ca y est !
A par ie7 qui m'affiche pas le titre prochain événement,
je ferais ça ce soir, je dois y aller...

choses de la vie

22h28 : Ca y est, le titre s'affiche sous ie7.

Putain demain je bosse à midi, et jusqu'à samedi idem, misère,
vivement que je ne fasses que des sites...


22h41 : limitation du taostore aux cadeaux TAO offerts par les commerçants.
En fait pour les plugins et les cadeaux utilisateurs, on verra éventuellement dans une autre version.


Là dans l'urgence pas le temps, et de toutes façons pas vraiment d'idée sur quoi mettre à l'intérieur.


22h55 : ajout de la question de base : "Qu'est-ce qu'un tao ?" dans la fac.


Techniquement, hormis le rappatriement des données de l'ancienne version,
la seule difficulté qui me reste, je crois, est le système de cache,
indispensable.
Maintenant, je n'ai pas assez de force pour commencer la conception, je vais donc faire des pages qui ne demandent pas beaucoup d'effort :
il me reste les mentions légales, le plan du site, et aussi des pages qui expliquent tous les services du compte vendeur.

Je crois que je vais faire le plan du site...

23h12 : j'ai fait les mentions légales en fait....

01h37 : création du graphisme de la page tout savoir sur le compte vendeur, mais pas intégrée, je me rajoute du boulot...

Demain, je commence par le système de mise en cache, je poursuivrai demain soir sur les offres commerciales.

**** 15-03-2010

07h18 : start
08h03 : la liste journal est créée
08h31 : ajout du code cadeau sur le détail de la preuve d'achat.
08h46 : ajout de la liste des preuves d'achat pour les commerçants.
09h55 : dans ma phase de résolution des bugs liés à mon compte.
pause : achat imprimante à la fnac.. ;)

11h57 : résolution de bugs /////
11h57 : croisement de liens entre l'aperçu et l'aperçu en ligne pour l'ajout d'un commerce.
12h00 : ajout du texte "Aucune promo pour l'instant" lors de l'aperçu d'une promo, à la place de rien.
12h12 : ajout des commerces refusés par le modérateur à la liste des commerces d'un utilisateur.
Les commerces refusés apparaissent avec le fond rouge, et la seule option pour l'instant de l'utilisateur est alors
de supprimer ce commerce. Le but de l'opération est d'informer l'utilisateur que le commerce qu'il a proposé a été refusé.
12h15 : le système de validation de commerce est correct;
12h21 : correction du switch de commerce de mon compte qui affichait tous les commerces, maintenant il n'affiche que les commerces avec le statut validé.
12h41 : mise à jour des phrases d'accroche personnalisées en fonction de l'action pour vendre le compte vendeur lorsque le switch appelle un service compte vendeur sur un commerce qui ne le possède pas encore.
13h13 : résolution d'un bug sur l'activation du compte vendeur pour un commerce (le compte de l'utilisateur n'était pas débité)
13h18 : amélioration des explications concernant le formulaire d'ajout d'événement.
14h05 : j'étais frustré de toujours devoir choisir un commerce pour chaque action. Pour la liste Liste des nouveaux commentaires proposés pour un événement,
j'ai enlevé le choix du commerce et par défaut, tous les commentaires s'affichent : c'est moins casse couilles.

14h45 : ajout de la liste des cadeaux tao sur l'espace perso du commerçant.
15h08 : résolution de gros problèmes d'affichage sous ie7
15h40 : mise à jour de la liste des promos avec liste5 pour l'espace perso du commerce.
15h48 : mise à jour de la liste des cadeaux avec liste5 pour l'espace perso du commerce.
15h59 : mise à jour du système de stats du commerçant qui check également les commentaires, événements, promos et cadeaux tao.
16h05 : ajout des totaux sur le système de stats de l'espace perso du commerçant. (array_sum était mon ami)
pause
19h45 : mise à jour de la liste web
screenshot143.png
Ce qui m'inquiète énormément, c'est la lenteur, même en local.
Mais bon je sais pourquoi : c'est le calcul et l'affichage des différentes catégories dans le select pour la partie site.
Cela sera résolu avec la mise en place d'un cache.

20h02 : améliorations diverses de l'affichage en liste des webitems.

Bon, faisons un petit point.
Au niveau pages, il me reste surtout le taostore à faire.
Voici la liste de ce qu'il me reste à faire avant la mise en ligne basique (à peu près) :
-indiquer où le moteur de recherche recherche
-moteur de recherche avancé
-googlemap
-faq
-ajouter nb visite annonce
-cache

Voilà, sinon, j'ai plein d'idées pour ma session de développement de mai, mais on verra ça plus tard.


20h12 : ajout du premier tip pour le moteur de recherche de la liste web.
screenshot144.png
Le tip peut servir à tout le monde, mais à la base je l'ai créé pour moi pour 2 raisons :
éviter d'ouvrir mon code pour faire mes tests de vérifications sur le moteur de recherche,
et avoir l'air moins con quand j'irais démarcher les commerçants, comme ça je pourrai leur dire exactement
où le moteur de recherche cherche, une sorte d'antisèche ;)
Dommage que ça soit pas dynamique (misère).
20h16 : ajout pour annonce (fo)
20h21 : commerces > établissements (fo)
20h24 : commerces > promos (fo)
20:27 : commerces > liste événements & cadeau TAO (fo)
20h34 : ...
20h38 : mise à jour de toute la partie mon compte.


J'en peux plus, j'veux m'allonger sur la plage la nuit avec un top modèle qui m'fait des massages...

euh... ouai non ok.


Passons maintenant au moteur de recherche avancé (passionnant, ..., j'en bave déjà d'impatience,
nonon, chui pas dégoûté d'être seul devant mon pc, tout va bien, sisi, nonon)


La mode maintenant c'est de mettre plein de javascript pour que l'utilisateur arrive au confort maximum en le minimum de clics.
Cela voudrait dire que si je commence à choisir la catégorie véhicule, hop
une autre liste apparaît qui affiche les critères spécifiques aux véhicules par exemple la marque et le modèle...

Mais comme je suis dans une démarche de propreté et que ça ...

Non, ok, on va faire comme ça après tout,
ça me coûtera le poids de la librairie jquery 1.3 qui fait déjà 55Ko !!! GASP !!!
Et heureusement que je prends pas la 1.4 qui fait plus de 80Ko !!!

Si jamais ça rame, on avisera à ce moment là.
En attendant c'est vrai que ça peut être kool de tout faire rapidement.

Je viens de regarder la version ta4,
même si c'est codé comme un porc, le moteur n'utilise pas jquery (plus rapide) et est relativement complet.
Ah misère, et moi qui voulais faire un truc moins bien mais difficile de sortir une nouvelle version avec le moteur
de recherche moins bien que la version précédente, déjà que j'ai retiré les médailles...
Je suis âs sûr que ce soit Très utile, mais c'est vrai qu'il est bien ce moteur, le coup de pouvoir choisir rapidement ce que l'on cherche.
Ok, grande respiration, on va faire le même.


Commençons par les véhicules :
si l'utilisateur choisit un véhicule et que le système connaît les marques associées à ce type de véhicule, ajouter le champ select des marques pour ce véhicule.
Lorsque je valide ce nouveau formulaire, une autre variable est créée et elle est récupérée par ma liste qui cherche du coup dans le champ marque pour le véhicules.

Je vais commencer par créer le html déployé.

21h27 : screenshot145.png


Passons maitenant à l'affichage dynamique des données, toujours dans l'optique de vérifier visuellement ce qui se passe.
Au niveau du comportement, garder en tête ce qui devrait se passer en cas de réaffichage statique de la liste.
Ici, vu qu'on passe tout en GET, pas trop de problèmes, on fera une condition au niveau de l'affichage en dur dans le code php
du moteur de recherche ::: si telle variable existe, alors affiche le moteur de recherche.

Bref...


Ce qu'il faut bien penser, c'est la cinématique.
Ici, je viens de vider mon div#plugin-moteur qui contenait la partie ajoutée du formulaire.
Cela ne change pas l'aspect de mon formulaire : il est comme avant.
Un bon point pour moi,
cela veut dire que ce div peut exister déjà au moment de la création de la page,
je n'aurais plus qu'à le remplir dynamiquement avec jquery, ou bien statiquement avec php (plus tard).

Essayons de coder la fonction de base jquery.


J'aime bien passer par des webservices pour faire ce genre de trucs.
Ici, la fonction de base semble fonctionner :

$("#a2").change(function(){
    var url = "/webservice/xform/getPluginMoteurContent.php";
    var id_categorie = $(this).val();
    $("#plugin-moteur").load(url,{id_categorie:id_categorie},function(data){
        alert(data);
    });
});


Pour économiser des ressources, je vais créer un tableau qui contient les valeurs susceptibles d'être appelées dynamiquement,
cela évite de faire des appels pour les catégories qui n'appeleront pas de plugin.

Ne maitrisant pas javascript, je suis obligé de me faire une fonction de test ::

var aCategories = [3,4,5];

$("#a2").change(function(){

    var id_categorie = $(this).val();

for(x in aCategories)
{
   if(aCategories[x] == id_categorie)
   {
        alert("oui");
   }
}



//    var url = "/webservice/xform/getPluginMoteurContent.php";
//    $("#plugin-moteur").load(url,{id_categorie:id_categorie},function(data){
//        alert(data);
//    });
});


Qui fonctionne comme prévu.


Maintenant, cette fonction

var aCategories = [3,4,5];

$("#a2").change(function(){

    var id_categorie = $(this).val();
    var callPlugin = false;

    for(x in aCategories)
    {
       if(aCategories[x] == id_categorie)
       {
            callPlugin = true;
       }
    }

    if(callPlugin == true)
    {
        var url = "/webservice/xform/getPluginMoteurContent.php";
        $("#plugin-moteur").load(url,{id_categorie:id_categorie},function(data){
            //alert(data);
        });
    }
    else
    {
        $("#plugin-moteur").empty();
    }
});



permet de n'appeler un plugin que si son identifiant numérique se trouve dans le tableau aCategories.
Il ne reste plus qu'à setup ce tableau.

Dans mon framework, ce bout de code est généré par php et je n'ai aucun mal à générer dynamiquement les identifiants de catégorie à appeler...



Voyons maintenant ce qui se passe du côté du réaffichage dynamique.

Comme prévu, si on poste le formulaire, les variables passent en GET.
Pas bon pour le référencement, mais tellement plus agréable pour le développeur....
Et plus logique sémantiquement.


Commençons donc par déterminer des noms de variables très court, étant donné que le nombre de caractères est très limité en GET.
Basons nous sur 256, bien que les résultats soient divers et variés sur Internet...


Profitons-en pour coder réellement le select des voitures, puisque c'était mon exemple.

Afin d'éviter les duplications de code, nous allons utiliser ce même formulaire (/webservice/xform/getPluginMoteurContent.php)
dynamiquement ET statiquement avec juste une petite bidouille php
au début du script.

22h15 : kool ! Le test de base fonctionne comme prévu : les variables sont passées et le réaffichage statique opère.
Il ne restera plus qu'à les faire transiter d'une page à l'autre, ce qui ne sera pas le plus difficile avec mon système de liste...
quoique une petite prise de tête sera peut être nécessaire, on verra...


Bref, maintenant, passons au codage concret.
Comme son nom l'indique : getPluginMoteurContent appelle un plugin, donc il gère tous les plugins, y compris immobilier.
C'est plus simple pour moi d'avoir un seul coupable en cas de problème ;)

Faisons déjà toutes les marques de tous les véhicules.


22h34 : ok.

Voyons maintenant ce que nous avons à proposer du côté de l'immobilier.
Mouai en fait le modèle ancien est vraiment pas mal :
on propose le type de bien, avec possibilité de laisser indifférent,
puis des fourchettes de surface, c'est mieux que de déterminer soi-même la surface, car
taper soi même la surface implique :
lâcher sa souris, taper la surface min, la surface max reprendre sa souris ...
Ce n'est pas que je prends les utilisateurs pour des fainéasses, mais au contraire
voyez avec quel souci du détail je pense à leur confort.
(si c'était juste pour moi ça aurait été un formulaire de recherche avancée sur une autre page, rien de dynamique quoi,
avec plein de paramètres pas jolis à lire.)

Bref,


comme ça avait bien marché pour les véhicules, nous allons utiliser la même technique avec l'immobilier :
coder d'abord le html déployé.
Apparemment aucun problème.
Bien, passons maintenant à la structure générale du fichier php.
Ok, fastoche, et maintenant création des constantes pour passer les paramètres en GET :
surface, et type de bien.
Ok,
maintenant, création des formulaires proprement dit.
Hélas j'ai fait le cakos et j'ai 2 listes de types de bien différents : une pour location et une autre pour vente.
Normal en même temps...

En fait ça m'a pris 1 minute de plus, je sais pas de quoi je me plains...

J'ai du mal à croire que dans la version précédente c'était une vraie corvée de faire ce moteur de recherche alors qu'ajourd'hui c'est un
vrai jeu d'enfant.
Jquery ?

Certainement il y est pour beaucoup,
et j'ose espérer que mon expérience de développeur m'aide également un peu.

Comme je n'ai aucune idée pour les surfaces, je vais reprendre telquel l'ancienne version.

Minute,,,

en fait en écrivant les tranches
0 14
15 24
25 49
...
je me suis demandé mais comment il fait le gars si il veut entre 20 et 100 ?
Mouai, en fait je pense que le mieux c'est de le laisser déterminer manuellement sa fourchette, tant pis pour le confort.
Quand on veut un truc on se bouge le cul.


Non mais...


Visuellement cela donne
screenshot146.png

Ce qui me convient.
Oups,
juste pour le plaisir des yeux, voyons le rendu sous ie7
screenshot147.png

Quel farceur, il a de la graine d'ie6 celui là.

Bref,...


23h14 : résolu, juste mettre un width 100% au div#plugin-moteur.

C'est mon css sens qui me l'a soufflé ;)

Bon, intéressons-nous maintenant à la persistance des données en mode statique (une fois que l'utilisateur vient de poster le formulaire,
tous les champs qu'il a rempli doivent restés renseignés avec les valeurs que l'utilisateur a entrées.)

23h23 : Ca y est la persistance est gérée, par contre j'aime pas qu'il m'affiche tous les champs à 0 par défaut.
C'est logique, mais moche esthétiquement, je vais les mettre à null plutôt.


Bon, maintenant, chui un peu fatigué, mais il semble que la prochaine étape soit que la requête sql soit impactée.

Poussons un peu les limites de notre fatigue...


Oups des bugs dans la liste d'annonces : elle affiche les annonces non encore validées, et en plus elle les affihce mal.

Bon je vais me coucher, j'ai besoin d'énergie et de beaucoup d'attention pour ça.


Reagarder des débilités sur internet , je suis plus bon kaca....

**** 14-03-2010

07h18 : start
Améliorations diverses.

09h26 : en réponse au problème suivant : lorsque un utilisateur vient d'acheter un produit,
s'il joue avec les boutons précédent et suivant de son navigateur, il est probable qu'il rachète une 2ème fois,
"involontairement", le produit.

J'ai mis en place le comportement d'achat dans un webservice appelé par javascript.
Si le traitement est ok, alors l'utilisateur est redirigé vers une page d'affichage de succès, inoffensive.
Ainsi, après l'achat, l'utilisateur peut naviguer librement, d'une page à l'autre, même avec la page de succès.
Ce n'est qu'en cliquant sur le bouton acheter ce produit que l'utilisateur appellera le script qui gère l'achat d'un produit.

09h48 : mise en avant du code cadeau
screenshot139.png

10h30 : liste5 : taostore > preuves d'achat, aucune mise en forme
La liste :
Le moteur de recherche cherche dans le libellé du produit et dans le nom du commerçant
Tris : par date, prix, libellé ou nom du vendeur

12h01 :
correction de bugs importants sur la logique métier d'achat d'un produit.

13h31 : écriture de la preuve d'achat
screenshot140.png

et la liste des preuves d'achat faite tout à l'heure
screenshot141.png
Et le popup qui s'ouvre (tant qu'on y est) lorsque l'on n'a pas assez de crédit pour acheter le produit.
screenshot142.png

14h32 : travail sur le css pour intégrer le module de liste5 dans le compte de manière plus élégante dans tous les navigateurs testés.

15h01 : refonte de la liste des cadeaux pour un commerce (compte vendeur)
15h12 : mise à jour de : Liste de mes événements
15h16 : mise à jour de : Liste de mes promos
15h37 : mise à jour de : Liste des nouveaux commentaires proposés pour un événement
15h42 : mise à jour de : Modération des commentaires proposés pour un événement

16h33 : suppression du comportement de liste pour les photos, ce n'est pas vraiment fait pour cela.
16h34 : mise à jour de : Modération des commentaires pour un commerce
16h53 : mise à jour de : Liste de mes commerces

Ouf, ça y est, pour la mise à jour de la forme, pour la partie commerce.
Mais je suis sûr qu'il y a plein de bugs pour le fond.

choses de la vie

22h50 : mise à jour avec liste 5 des la liste des items web.

23h14 : mise à jour de la liste des messages utilisateurs./... pfff...


pause, blasé, ... la faiblesse me gagne ?

00h05 : La liste message système

00h13 : la liste message externe anonyme est mise à jour.
01h00 : mise à jour de la liste des annonces ... mode web
pause ...
end...

**** 13-03-2010

06h42 : start
Je crois que le plus dur est de pouvoir décrire EXACTEMENT le comportement que je souhaite
AVANT d'écrire la moindre ligne de code.

Je pense que je veux avant tout des pages statiques fonctionnelles.
Pour inciter l'utilisateur à mettre un commentaire, je pense que le mieux est de lui présenter directement le formulaire,
de telle manière qu'il n'ait plus qu' à écrire, une sorte d'invitation;

Pour ne pas casser ma logique de base de données, seuls les utilisateurs de Tours annonces pourront poster des commentaires.
(car un commentaire DOIT forcément appartenir à un utilisateur d'après mon design, et je n'ai pas envie de créer un utilisateur anonyme comme dans la v4,
je ne trouve pas cela propre).

Le formulaire est là.
L'utilisateur le remplit.
Au moment où il manifeste son désir d'envoyer le message, une vérification javascript est effectuée pour voir si l'utilisateur est connecté.
Si l'utilisateur est connecté, le formulaire est posté.
Sinon, un popup d'avertissement apparaît et invite l'utilisateur à se connecter.
Si il le fait, le message est posté et le message de confirmation apparaît.
Le message porte la mention sous réserve de validation du commerçant.

Comme l'utilisateur n'utilise pas forcément javascript,
une vérification doit être réalisée côté serveur :
si l'utilisateur n'est pas connecté, un message d'erreur apparaît.

06h52 : Commençons par créer le formulaire statiquement, avec sa vérification sur l'authentification de l'utilisateur.

Ah oui, j'ai oublié de répondre à une question : combien de commentaires max par utilisateur ?
Pour l'instant ma réponse est l'infini, mais peut être plus tard je voudrais limiter ce nombre à 1, ou 3 ?
C'est quelque chose que je dois prévoir dès maintenant.
Cette vérification sera faite par mon formulaire, par rapport à la constante
COMMERCE_COMMENTAIRE_NB_MAX_PAR_UTILISATEUR qui vaudra -1 pour l'infini et tout autre nombre pour un nombre fini.

07h13 : création d'une solution qui me permet de faire revenir l'utilisateur sur la page sur laquelle il était précédemment,
(alors que celle-ci n'est pas naturellement sécurisée).
Cela me permet d'écrire un message d'erreur à l'utilisateur : vous n'êtes pas connecté, et de lui proposer un lien connectez-vous
qui, si loggué correctement, le renvoie sur la même page.

/*******************************************************************************/
// POSSIBILITE DE REDIRECTION VERS L'ANCIENNE PAGE
/*******************************************************************************/
/*
 * Si GET PARAM EXTRA vaut http_referer, alors à l'issue du formulaire, l'utilisateur
 * sera redirigé vers la page sur laquelle il était précédemment
 */
if(isset($_GET[GET_PARAM_EXTRA]) && $_GET[GET_PARAM_EXTRA] === 'http_referer')
{
    $redirect = $_SERVER['HTTP_REFERER'];
}

07h16 : le formulaire est créé et gère les erreurs.
screenshot134.png

Il faut maintenant qu'il insère une entrée... oups, j'ai oublié la vérification sur le nombre de messages max...ok.

Lorsque le formulaire sera rempli avec succès, l'utilisateur sera redirigé vers une page dans laquelle le formulaire n'existe plus,
cela évite les problèmes de rechargement de page qui repostent le formulaire.
Mais l'utilisateur pourra faire précédent.
En espérant que l'utilisateur ait javascript, la page de succès redirigera vers la page des commentaires.
07h41 : ma redirection vers l'ancienne page ne fonctionne pas...
08h00 : ouf, une grosse erreur d'inattention...
Maintenant, il faudrait que la liste affiche également les commentaires en attente de validation, pour un utilisateur donné.
pause.
08h13 :
08h44 : design du commentaire grâce à quickdesign

09h06 : screenshot135.png
A part les photos qui sont redimensionnées par le navigateur, le reste est ok.
Pour les photos, en fait il faudra que je fasses une routine côté serveur, ou pas...
J'ai désactivé le moteur de recherche et le tri car jugé trop lourd pour les commentaires, visuellement parlant.
Ajout du datetime aussi, à la place de date.

Je passe directement côté commerçant, je ferais javascript interaction plus tard.

pause

10h55 : correction de bugs divers.
la liste de modération est créée et les fonctionnalités actives.
Le commerçant peut accepter ou refuser les commentaires proposés.
Lorsqu'un commentaire est accepté, il est affiché dans son espace perso section commentaire sur le site.
screenshot136.png


11h38 : le système de switch me casse les couilles, je vais le refaire en mieux conçu.
12h45 : le système est mieux organisé, bien que visuellement identique pour l'instant.
Mais j'aurai plus de facilité à le faire évoluer par la suite, humpf, je respire.

Résolution de bugs métiers... aïeaïeaïe
Des fois je me demande à quoi je pense quand je code..., résolu.

13h59 : Ajout d'une liste de modération des commentaires déjà postés.
screenshot137.png
Je pense que je mettrais le moteur de recherche et le trigger de cette liste en vente sur le taostore à genre 5 tao.
Histoire de tripper.
Une bonne intro au système de vente sur Tours annonces, mais plus tard.

Pour l'instant, ah oui, il me reste la partie javascript côté interface utilisateur, avant de dupliquer-adapter le tout pour les événements.

14h38, bon en fait je vais pas faire EXACTEMENT l'interaction que j'ai dit en javascript, car c'est un peu long et j'ai pas vraiment le temps.
Lorsque un utilisateur non connecté tente un message, si le popup apparaît et
si l'utilisateur clique sur le lien de connexion,
à l'issue d'une connexion réussie, son message est ... perdu,
ben oui désolé, mais là ça me casse les couilles, à mettre dans la liste des trucs à améliorer plus tard...

Passons maintenant à la duplication du système de commentaires pour les événements.

Non, en fait je peux pas faire ça, il faut que je trouve la solution pour le problème précédent.
En fait j'ai plusieurs solutions mais elles sont complexes,
la moins complexe est de transiter les données en POST d'une page à l'autre :
du formulaire d'ajout du commentaire vers le formulaire de connexion
puis du formulaire de connexion vers le fomrulaire d'ajout de commentaire.

Bon je vais tenter cela alors.
et en fait je peux pas parce que je transite en GET un moment avec window.location.href
Donc POST c'est mort/

Je vais faire avec les sessions alors...grmblblbl

15h37 : ça fonctionne, mais l'implémentation est misérable :
2 scripts supplémentaires save-temp-message.php et get-clean-message.php sont utilisés pour gérer l'existence et l'utilisation de la variable message.

Bref.

16h31 : au niveau du front office, l'ajout des commentaires est possible sur un événement,
de la même manière que c'était possible pour un commentaire sur un commerce.

17h15 : l'interface de modération des nouveaux commentaires pour événement semble fonctionnelle.
Détection de bugs légers pour l'affichage dans le fo.

ouf, je viens de trouver la soluce, un vrai mal de crâne pour un novice comme moi :
voici mon problème


cela était faux:

string(560) "SELECT c.id, c.commentaire, c.note, c.date_creation, c.statut, u.id AS uid, cu.pseudo, ut.photo FROM commentaire_evenement c
INNER JOIN utilisateur u ON u.id=c.id_utilisateur
INNER JOIN compte_utilisateur cu ON cu.id_utilisateur=u.id
INNER JOIN utilisateur_tan ut ON ut.id_utilisateur=u.id
INNER JOIN evenement e ON e.id=c.id_evenement

    WHERE c.statut=3
    AND e.id=1
    OR (c.statut=1 AND u.id=1 AND e.id=1)
             AND (cu.pseudo LIKE :mots
                     OR c.commentaire LIKE :mots
                ) ORDER BY c.date_creation asc LIMIT 0,20"


Mais cela était juste:
string(562) "SELECT c.id, c.commentaire, c.note, c.date_creation, c.statut, u.id AS uid, cu.pseudo, ut.photo FROM commentaire_evenement c
INNER JOIN utilisateur u ON u.id=c.id_utilisateur
INNER JOIN compte_utilisateur cu ON cu.id_utilisateur=u.id
INNER JOIN utilisateur_tan ut ON ut.id_utilisateur=u.id
INNER JOIN evenement e ON e.id=c.id_evenement

    WHERE (c.statut=3
    OR (c.statut=1 AND u.id=1 AND e.id=1))
    AND e.id=1
             AND (cu.pseudo LIKE :mots
                     OR c.commentaire LIKE :mots
                ) ORDER BY c.date_creation asc LIMIT 0,20"


Je n'avais pas capté la logique booléeenne du OR et du AND en mysql.
Maintenant, je n'ai toujours pas capté, mais je suis conscient des problèmes que cela peut engendré.

Choses de la vie.


22h44 : activation des triggers et du moteur de recherche pour la Liste des nouveaux commentaires proposés pour un événement.

23h01 : la Modération des commentaires proposés pour un événement est ajoutée dans le compte vendeur.

23h05 : le nombre de services proposé commence à être intéressant, et cela déborde du cadre prévu initialement : simplification du design pour contenir
la totalité des services de mon compte vendeur sans déborder...
screenshot138.png

Il faudrait maintenant que je teste l'ensemble des services liés à la section commerce,
et si possible tout mettre à jour au niveau des listes, certaines ne sont pas encore en liste5.

23h27 : ajout du lien vers le commerçant depuis le détail d'un produit. (tao-produit)
23h28 : update du lien annuler lors de l'achat d'un produit, qui mène maintenant vers http_referer.
23h52 ajout d'un bubble info qui est un lien vers la question de la FAQ à rédiger ::
Comment se déroulent les achats sur Tours annonces ?

00h25 :aïe, je ne sais pas quoi faire avec les preuves d'achat, dois-je les implémenter ou bien pas.
Car finalement, si je veux laisser la possibilité au commerçant de savoir que tel utilisateur a acheté son cadeau à telle date,
le plus simple dans mon cas est d'avoir déjà créé la preuve d'achat.
Je verrai demain, même si les délais se resserrent...

**** 12-03-2010

05h37 : start

06h48 : fun :
-webkit-border-radius: 6px;
-moz-border-radius: 6px;

http://www.css3.info/preview/

Mais lent... surtout pour les multiples shadows

je vais utiliser fontface, trop kool!

08h02 : bon je me suis bien éclaté avec css3, ca va déchirer, on pourra même faire des animations...

Bref, mon formulaire se comporte maintenant exactement comme prévu dans firefox.

08h54 : le comportement d'ajout des photos fonctionne comme je le souhaite sur ffox, je ne teste pas les autres nav pour l'instant,
car je suis pas en avance.

Maintenant, il faut faire la validation côté commerçant.

Alors déjà il manque la liste des événements d'un commerçant dans l'espace perso du commerçant.

Je prends bien mon temps pour éviter au maximum les boulettes de conception;
11h02 : les listes des événements ont été ajoutées sur l'espace perso du commerçant;

pause;
Réorganisation de l'espace de mon compte.
screenshot127.png

Il faut aussi que je prévoies l'état de départ : avec le compte vendeur grisé.
16h22 : bon dieu ce que je mets du temps...
La liste des photos à modérer est ajoutée au compte perso du commerçant, le comportement effacer est actif,
je suis en train d'ajouter fancy box pour qu'il puisse agrandir la photo, et il me reste le comportement de validation
à faire, ainsi que 2, 3 liens et de la mise en forme/...

16h28: le comportement fancy est ajouté avec une galerie d'images que l'on peut défiler...

16h44 : le comportement de validation est actif.

16h52 : sauvegarde antirégisque : avant de corriger un petit bug d'affichage qui aurait pu tout effacer (mais en fait je vais changer de technique)

16h56 : ok bug corrigé;

17h02 : z
Préparation des visuels pour le maître....
même si le design est pas top, mais pas mal par rapport à mon niveau;


Maître ?


oui.


Voici :

screenshot128.png
screenshot129.png
screenshot130.png
screenshot131.png
screenshot132.png
screenshot133.png


Lorsque un utilisateur consulte un événement, il y a une icône qui lui permet d'ajouter ses propres photos : lorsqu'il clique dessus, 2 cas peuvent se produire :
soit il n'est pas connecté, et dans ce cas, c'est le visuel 128 qui apparaît.
Si depuis 128, l'utilisateur clique sur le lien connecter, alors 129 apparaît.
C'est un formulaire de connexion classique, qui gère ses messages d'erreurs.
Si l'utilisateur remplit le formulaire correctement,
alors le 130 apparaît, qui permet à l'utilisateur de concrétement ajouter ses photos.
Le nombre de photos maximum qu'un utilisateur peut ajouter par événement est déterminé dans la constante EVENEMENT_MAX_KUSTOMPHOTOS_BY_EVENEMENT qui vaut pour l'instant 3.
Avant chaque ajout de photo, ce chiffre est comparé au nombre de photos actuellement postées par l'utilisateur.
131 montre le formulaire qui apparaît lorsque l'utilisateur essaie d'ajouter une photo supplémentaire,
alors qu'il a déjà atteint le nombre maximum.

De son côté, le commerçant a une autre option dans son compte qui lui permet de modérer la liste
des photos en attente de validation pour un événement de l'un de ses commerces.
132 montre cette liste.
Les comportements sont aussi simples que la représentation que l'on peut s'en faire :
supprimer supprime, et accepter accepte (mais qu'il est bête).

133 montre l'écran que voit le commerçant lorsqu'il clique sur une photo.
Voilà.

17h15 : ok
Peut on faire la même chose pour les commentaires ?
Et où sont les commentaires d'un commerce, je ne les vois pas, peut-on les remettre ?

-------------interne:start
17h18 : firefox 3.6 est arrivé, je prends.
A première vue la fenêtre "utile" est plus haute, j'aime bien...
J'ai pris un persona au pif, c'était tellement facile de le faire...

Pour les commentaires, je vais stocker tous les commentaires dans 1 table.
Ils seront différenciés par type, qui sera un tinyint, ce qui me laisse 256 types à choisir.
Pour l'instant, pour l'exercice en cours, j'ai besoin de 2 types : commerce et evenement;
Il me faut une classe pour stocker les types : Tan_Private_Commentaire

Un commentaire appartient à un utilisateur.

Il y a un texte, une note.
Ma foi c'est à peu près tout.

codage du schéma

Oups , apparemment j'avais déjà une table commerce_avis, mais je m'en rappelle plus//..

En cherchant dans le code, je crois que je ne m'en sers pas du tout.
Donc c'est bon.

Concernant les commentaires sur les événements, j'ai le choix de mettre les commentaires par date
(dans le cas d'un événement qui s'étale sur plusieurs jours, ou bien par événement.).


Je vais prendre par événément parce qu'il me semble que c'est plus convivial.

En fait, si je fais ce que j'avais l'intention de faire, je n'ai pas mes liaisons dans mysql,
sans doute que ce n'est pas prévu pour cela.
Je préfère que tout reste le plus propre possible, c'est pourquoi je vais diviser en autant de tables
de commentaires que de tables à commenter.
Il me suffira de dupliquer cette table et de la décliner pour un prochain objet à commenter,
duplication, mais au moins je garde la cohérence = certitude qu'un commentaire appartient forcément à une table.

schema-commentaire.png



17h54 : la classe est créée, je viens de setup la liste, pour l'instant ya aucun commentaire donc je peux pas vraiment tester, mais si ça marche
yaura tri sur le pseudo ou sur la date, et moteur de recherche sur le,, ah merde j'ai oublié le commentaire, j'ai mis le pseudo/..
Ca yest corrigé.
Bon ben choses de la vie...


23h04 : peut être que le système de notes est un peu trop scolaire, je préfère que les commentaires ne soient que littéraires,
si les autres utilisateurs veulent se faire une idée en lisant les commentaires des autres, et bien ils n'ont qu'à lire...

23h52 : problème de conception : j'étais en train de refaire le même système que pour les photos,
mais en fait, je m'aperçois que ce n'est pas pratique pour un commentaire, quoique...
Bonbref, chui fatigué, vais m'coucher demain j'aurais les idées plus claires;







-------------interne:end

**** 11-03-2010

09h16 : Ca y est je viens de finir une bonne partie de l'autre projet, j'attends les retours...
En attendant je continue la partie commerces

09h35: super, mon script de liste est à la hauteur de mes attentes, j'ai pu refaire la liste des commerces avec mon système sans souci.
screenshot121.png

Maintenant, il me reste à faire en sorte que lorsque un canton est cliqué,
toutes les communes de ce canton figurent dans la liste.

choses de la vie ...relou...

11h17 : ca y est, le système de choix par canton est en place.
pause.

11h38 : pouvez-vous mettre à jour la liste des promos avec votre liste5 ?
11h48 : ca y est.

Bien. Les liens en savoir plus ne fonctionnent pas, pouvez-vous corriger le problème, et par la même occasion créer si nécessaire l'espace d'affichage
des promos au sein de l'espace perso du commerçant;


---- interne:start
Autre projet, le client a validé, faut finir et s'occupper du référencement...
14h15 : Ca y est, j'ai enfin terminé l'autre site entièrement, et référencé, faudra juste modifier une photo que le client apportera plus tard :
http://www.lejardindolivier.fr/


14h27 : confronté au problème de duplication de mes listes5,
je vais plutôt construire une classe liste5...,
non en fait c'est beaucoup de code pour pas grand chose, une duplication va pas me tuer (erreur fatale ?).

---- interne:end

14h55 : Le lien en savoir plus fonctionne et mène sur la liste des promos du commerçant:
screenshot122.png

Bien (c'est moche mais on lui dira plus tard).
Pouvez-vous maintenant mettre à jour avec liste 5 la liste des événements ?

15h05 : Ca y est.

Bien, veuillez mettre à jour le lien qui mène vers l'espace perso du commerçant.

15h09 : Ca y est.

D'accord.
Pour l'instant affiche tous les événements, y compris ceux qui sont périmés.
Pouvez-vous différencier les événements en 2 listes, qui seront accessibles depuis le menutop, l'une normale : événements et l'autre historique des événements
ou bien qqchose de similaire ?

---- interne:start
oups, j'aurais dû créé un datetime sur l'événement plutôt qu'un date + des horaires, car là mon rayon de précision est la journée et non pas la seconde,
du coup, par simplicité, un événement ne sera considéré périmé que si le jour est différent, les horaires ne sont pas prises en compte.
J'espère qu'il n'y verra que du feu.
choses de la vie
---- interne:end

15h32 : Ca y est.
screenshot123.png

Bien, (la précision de son système n'est pas top mais bon...)
Lorsque je clique sur un événément périmé dans la liste des événéments périmés, je tombe sur l'événément, et le système m'indique que cet événément est périmé.
Pouvez vous réactiver cet événement, et prévoir un lien ajouter une photo,
ce lien sera utilisable par un utilisateur de Tours annonces.
Il arrivera sur un formulaire par lequel il pourra simplement envoyer une photo, ou plusieurs, à vous de voir, mais laissez-moi le choix
de changer ce nombre facilement.
Toute photo proposée arrivera dans le compte du commerçant, à un endroit que vous déterminerez, et
le commerçant validera ou non les photos.
Le commerçant aura également la possibilité d'effacer les événements passés.

---- interne:start
ouf, il a pas vu pour mon système de péremption...
Bon, balèze ce qu'il me demande là, faisons dans l'ordre.
15h39 : réactivation du détail d'un événement périmé.
15h54 : ajout du lien : screenshot124.png
Je pense que le commerçant devra pouvoir choisir d'activer ou pas ce lien;
La solution la plus simple est certainement de faire une page séparée pour le formulaire.
Mais j'ai envie de tester un truc : un formulaire qui apparaît en popup au milieu de la page et qui ajoute dynamiquement les photos au diapo.
Je sais que c'est pas le moment de perdre du temps, mais ça me permet de voir comment faire ce genre de choses, car je ne l'ai plus en tête.
C'est un entraînement à la méthodologie en qq sorte.
16h04 : création d'un formulaire bidon dans un webservice. (vive les code template de netbeans... = copier collé puissance 3)
16h10 : ajout de fancy box pour appeler dynamiquement le formulaire dans une popup, ca marche nickel pour l'instant kool;
15h54 : ajout du lien : screenshot125.png
Mais ce qui m'intéresse rééllement, c'est d'utiliser au (automatic upload) depuis fancybox;
Faisons déjà des test plus simples.
Si je clique sur le bouton du formulaire, cela doit lancer une fonction déterminée avant dans la page.
Commençons déjà par jouer avec l'API
16h50 : le chargement d'une image est réalisé, avec un au légèrement modifié.
Par contre, il n'y a pas de restriction au niveau du nombre de photos, je vais restreindre en comptant à chaque fois le nombre
de photos déjà en proposition et dire:
"Le nombre maximum de photos en proposition est déjà atteint.Veuillez attendre que le commerçant valide les photos
avant d'en poster de nouvelles"
ou un truc comme ça...
17h18 : ah ben non en fait c'est géré automatiquement, donc tout marche comme prévu,
auf que il n'y a pas de message d'erreur qui apparaît lorsque l'utilisateur dépasse le nombre autorisé.
Je devrais rajouter une condition préalable qui fait que lorsque l'on clique sur le lien, si on est connecté, le formulaire s'ouvre
normalement, et si on n'est pas connecté, un message apparaît pour dire que l'on doit se connecter.
J'aurais voulu que la connexion se gère au sein de fancy box, comme impromptu , pour tester l'enchaînement des étapes,
mais le délai ne me permet plus de m'amuser, je me suis déjà bien éclaté, je vais faire simplement un panneau qui dit que l'utilisateur n'est pas connecté, avec un lien
vers le formulaire de connexion et un autre lien vers l'inscription
17h52 : screenshot126.png
17h56 : le système fonctionne : et le nombre de photos max est attribué PAR UTILISATEUR, ce qui est pus juste.
Pour l'instant j'ai fixé à 10 ce nombre maximum.
Mais le problème c'est que si l'utilisateur ne le sait pas, il va croire des choses, comme par exemple le fait que toutes ses images sont chargées,
Alors qu'en fait une rotation des images est effectuée.
Il faudrait que lorsqu'il se connecte, les anciennes images qu'il a chargées apparaissent.

Choses de la vie.

00h01 : bon en fait je n'ai pas pu m'empêcher d'aller un peu plus loin :::
ce fancy box est plus puissant que l'utilisation basique que j'en faisais :
il permet d'afficher des contenus, mais il peut appeler du contenu dynamique et ...
bref, j'ai trouvé le moyen de chaîner 2 formulaires grâce à fancybox, du coup,
l'utilisateur n'aura pas à se logguer sur une autre page, puis revenir avec son navigateur,
enfin, j'ai pas tout  fait réussi mais le test de base est satisfaisant, faisons cela...

Bon chui naze, mon corps met 3 plombes à réagir et mon cerveau n'est pas aussi perçant que le matin,
je préfère pas travailler dans ces conditions.

---- interne:end

**** 10-03-2010

07h06 : start :
la journée où théoriquement, je termine la version de Tours annonces, fonctionnellement parlant.

Prions pour que personne ne me dérange... go.

07h10 : donc la page accueil est fonctionnelle,
le système de news également (faits hier),
ainsi que les liens de la page d'accueils qui mènent aux bons endroits.

07h17 : la partie moncompte>accueil semble ok
07h17 : la partie moncompte>profil semble ok, MAIS les points d'expérience sont obsolètes :
il n'y aucun autre endroit sur le site pour l'instant où ils servent à qqchose et où on peut les gagner.
Il est temps de redéterminer comment et à quelle vitesse un utilisateur gagne des points d'expérience,
et à quoi ils servent.
Dans la version actuelle, un utilisateur est au grade de commandant,
j'aimerais vraiment mettre en valeur les annonceurs les plus gradés, mais à cause du temps qu'il me reste, je ferai
cela plus tard, de même que de rajouter des icônes pour les grades, pour l'instant, restons du côté du code.
Sur la version actuelle, le nombre de points tao et de points d'expérience gagnés sont déterminés par 2 contantes :
define('ANN2PETA_RATE',5);
define('ANN2TAO_RATE',0.1);

Concernant les médailles, je crois que je vais arrêter cela.
Bien sûr, ceux qui ont des médailles les gardent, mais c'est plus simple pour moi de retirer le système.
Je réfléchirai plus tard à comment mettre en valeur les utilisateurs, puisque c'est de cela qu'il s'agit,
mais pour l'instant cela m'évoque plus un gadget qu'autre chose, donc stop la rigolade, il y a des trucs plus
importants à développer.

Bon, et bien gardons les même quotas.
5 points peta ET 0.1 TAO par nouvelle annonce postée.
Du coup, l'ajout des nouveaux statuts possibles d'une annonce va me simplifier fortement la gestion
d'attribution des points.

07h42 : mes 2 nouvelles constantes :
define('TAO_GAIN_PAR_ANNONCE',0.1);
define('PETA_GAIN_PAR_ANNONCE',5);

08h06 : Les points sont attribués.
08h13 : ajout du lien vers le profil utilisateur depuis l'aperçu de l'annonce.
pause
09h40 : tri des photos par ordre chronologique pour l'annonce.
09h42 : ajout d'un message de confirmation de suppression sur lors de la suppression d'une annonce;
09h47 : correction d'un bug mineur d'oublide mise à jour de constante.
09h59 : correction d'un bug concernant l'envoi d'un message à un autre annonceur.

12h42 : gros travail sur les listes (encore), mise à jour de la liste d'annonces avec mon nouveau modèle de listes :
liste5 qui comprend 5 éléments, d'où son nom :
le moteur de recherche, les triggers, le search-info, la liste, et le pagelink.
Cette fois, j'ai bien séparé les 5 parties (cela se ressent d'ailleurs dans le design) de telle sorte que
je puisse identifier le problème ou bien améliorer chaque partie séparément, enfin c'est le but, après...
screenshot117.png
Bref.

Choses de la vie.




13h57 : du coup malgré que cela soit censé être une journée php, je n'ai pas pu m'empêcher de rajouter quelques icônes, c'est plus joli ..
screenshot118.png


14h07 : les liens sont ajoutés et du coup je m'aperçois d'un bug majeur :
la requête qui sélectionne les annonces par catégories ne prend pas les sous catégories en compte...

14h21 : ca y est c'est réparé.
Par contre j'ai oublié de remettre le style d'annonces journal en ajoutant ma liste5.

14h31 : les triggers spéciaux de style sont ajoutés, par contre la liste des annonces journal est bugguée.
14h34 : ca y est c'est réparé, mais le pagelink s'affiche dans la liste, je le voudrais en dessous.
14h36 : Ca y est le pagelink est en-dessous. Oups, mes annonces apparaissent en double, j'ai du merder la requête pour
l'arborescence tout à l'heure.
14h39 : Ok
14h44 : ajout du lien vers le formulaire d'envoi de message depuis la liste des annonces en mode journal : pratique (+1 pour la liste mode journal)

Lorsque je suis sur la page de détail d'une annonce, je n'ai aucun moyen pour revenir en arrière (à part précédent de mon navigateur);
Je vais ajouter un bouton, que l'on reconnaît facilement (sinon, personne ne va l'utiliser).

15h08 : le backbutton est en place sous firefox, très ludique et en évidence j'aime bien.
Pour l'instant je ne le laisse qu'ici.
screenshot119.png

Bon maintenant faudrait que je codes la partie annonces similaires.
Et comme j'ai été bête, (avant j'étais bête mais maintenant chui intelligent), j'ai pas pensé à créer à l'avance mon module vierge,
du coup je vais devoir repasser dans chacune des occurrences...
Mais pourquoi je raconte ça moi...


15h41 : création d'une fonction générique quickdesign afin d'avoir déjà un élément vierge par défaut.

16h14 : utilisation de quickdesign pour faire une liste d'items.
Lequickdesign est bien pensé, dans le sens où la spécificité est utilisée à bon escient :
Voici mon code de base, si ça peut donner des idées :


/*.qd-item{background:#ddd;}
.qd-item h4{background-color:#bbb;}
.qd-item span{background:#666;}
.qd-item em{background:#999;}
.qd-item p{background:#ccc;}*/

.qd-item{margin-bottom:5px;padding-top:5px;}
.qd-item img{float:left;margin:0 5px 5px 5px;}
.qd-item h4{margin:0;}
.qd-item span{float:right;}
.qd-item hr{clear:both;height:0;}

#annonces-similaires .qd-item {width:230px;}
#annonces-similaires .qd-item h4{height:64px;}
#annonces-similaires .qd-item h4 a{color:#333;}
#annonces-similaires .qd-item em{font-weight:bold;font-size:15px;}


Petit rappel sur les fonctions random avant de se lancer dans le codage de la fonction :
http://dev.petitchevalroux.net/mysql/requete-select-random-sql-mysql.287.html

D'après mes souvenirs, dans la version précédente,
pour faire un choix aléatoire des annonces, je prenais l'id de l'annonce donnée,
puis je donnais un nombre X à ma fonction très compliquée qui alors tentait d'abord
de récupérer X annonces dans la même catégorie.
Si elle ne trouvait pas, la fonction stockait alors le nombre d'annonces trouvées et
cherchait dans la catégorie supérieure jusqu'à ce qu'elle ait trouvé X annonces.

Je trouve ça trop compliqué, je vais faire plutôt une seule requête qui récupère X résultats
dans la catégorie et supérieure, ordonnée par niveau de profondeur descendant.

17h05 : ca y est.
Par contre, j'ai remarqué que les annonces de véhicules ne sont pas enregistrées dans leur catégorie la plus spécifique
(le modèle, puis la marque), mais dans la grosse catégorie (par exemple voiture) qui les contient.
Je pense que j'ai fait ce choix pour une raison mais je ne me rappelle plus laquelle, en tous cas c'est très dommage pour le référencement.
Quoiqu'il en soit, il me faut avancer...
Ah oui, je sais pourquoi, parce que c'est plus pratique de chercher par catégories pour le moteur de recherche.
Mouais bof.

Bon, de toutes façons c'est plus clair comme ça et je préfère la clarté du code que le référencement.

Mais en gros ma fonction n'est pas pleinement utilisée tant que les catégories d'annonces ne descendent pas en-dessous du niveau 2.

17h29 : ok, donc la partie annonces me semble tout à fait correcte maintenant;



choses de la vie :

23h52 : puatin chui naze...
vais m'coucher...
j'ai fait la mise en forme de mon slider sur la   partie commerces>accueil et j'ai ajouté un titre "joli" sur la carte des commerces;
D'ailleurs je me demande si ça vaut le coup de sortir la carte tout de suite, alors qu'il n'y aura pas grand monde dessus, mais bon
c'est un autre probleme...

Demain hélas c'est une journée morte pour moi je dois travailler sur l'autre projet;
Peut être arriverais-je à gratter quelques heures de travail.

A mon avis, rien que pour la partie commerce, il y en a au moins pour 3 jours complets;
Rhalala chui complètement en retard, c'est très stressant.

**** 09-03-2010

05h59 : start
06h13 : système de stats terminé
Affiche cela :
---------------------------
Nombre de hits :

depuis le dimanche 07 mars 2010 : 264
Accueil : 215
Annonces : 6
Forum : 1
Commerces : 6
Web : 4
Faq : 8
Taostore : 4
Inscription : 11
depuis ajourd’hui à 00h00 : 159
Nombre de visiteurs uniques (par IP):

Depuis aujourd'hui : 2
---------------------------

choses de la vie.

Bon, j'ai joué avec flash aujourd'hui principalement,
c'est pour ajouter du dynamisme au site.
Et aussi un slider jquery tout lent codé manuellement pour faire défiler lentement
les images de la page d'accueil, j'espère qu'elle ne sera pas trop lourde.
screenshot115.png

J'ai également intégré une galerie flash pour les photos de la ville.
screenshot116.png

Ca faisait longtemps que j'avais pas flashé comme ça,
ça fait du bien de se remettre dans le bain une fois de temps en temps.

Bref, par contre demain c'est code, php's back to correct the bugs!

Alors là franchement j'aurais pas fini demain,
et après demain il faut que je finisses encore une fois le site pour l'autre projet.
Apparemment, il reste quelques détails à corriger.

Demain, il me reste 17 jours pour, dans l'ordre :
corriger les bugs
ajouter les dernières fonctionnalités (google map, notamment)
rappatrier les contenus
(ajouter la fonction mail sur le serveur)
mettre le site en ligne

La partie ajouter les fonctionnalités risque d'être très longue
Mauvaise nouvelle, il s'avère que les nouveaux serveurs, s'ils sont plus puissants en terme de processeurs,
offrent moins de bande passante,
donc je vais peut être rester sur les mêmes serveurs, ce qui m'éviterait d'ailleurs de me casser une côte
sur l'install de la fonction mail sur un dédié (chui vraiment un bitos en linux...)

Bref, c'est pas gagné, mais on se rapproche, heureusement que je me prévois des bonnes marges au niveau des délais ...
01h36

**** 08-03-2010

07h39 : start

Bon cette fois, espérons que le temps libre soit avec nous.

Hier, nous avons été coupés, veuillez poursuivre votre tâche sur les commerces.

réflexion interne start-------------------------------------------

08h10 : tiens! la liste des commerces est en vieux mode, je vais essayer de l'updater avec mon système de listes...
08h29 : en fait non vu que ca marche déjà et que le moteur de recherche est plus compliqué (gestion
de la catégorie et des communes, donc laissons intact pour le moment.)
08h47 : ok pour la liste des établissements
09h06 : ok pour les promos, enfin ruditairement.
09h45 : hélas mon calendrier ne s'affiche correctement que sous firefox, tant pis je le laisse, et je repasserai plus tard.
10h15 : ok pour la liste des événements, basiquement.
10h18 : ok pour la liste des cadeaux.
10h22 : ok pour la page compte vendeur.

pause.

14h17 : création d'un visuel comme accueil des commerces :
screenshot114.png
Sur le visuel je décris des services qui ne sont pas encore faits (historique des événements),
c'est pour me foutre un coup de pied au cul et j'epère que j'aurais le temps de les faire...
Implémentation...

choses de la vie

21h17 : bon sang j'ai passé toute la journée sur cette page, j'ai ajouté un slider codé par mes soins,
mais pas fini le design.
Beaucoup d'interrogations aujourd'hui, je ne sais pas quoi faire, une partie de moi veut continuer les offres
commerciales et le côté design du site, et l'autre me dit de résoudre tous les problèmes techniques d'abord.
Et il y a plein de problèmes techniques.

Je crois que je n'avais plus la force jusqu'à cette minute de reprendre le code et de le corriger.
Mais maintenant, ça me revient petit à petit, dommage que j'ai pas un bon steack à manger.

Ok, je vais résoudre tous les problèmes techniques.

23h23 : les news sont ok pour moi.
Création de la table statistique.
schema-stat.png

23h27 : le système de capture de stats est en place.
00h29 : je suis trop inefficace ce soir : arrêt des dégâts...




réflexion interne end-------------------------------------------

**** 07-03-2010

07h46 : start

Bien, ajourd'hui, espérons que nous ne serons dérangés par rien.
Nous aurons donc ...  à peu près 8 heures de tavail.
Profitons-en pour avancer sur Tours annonces au maximum.

Le 10 le site basiquement doit être bouclé.
Ling, veuillez terminer la partie message.
Le nombre de messages de chaque catégorie n'apparaît pas encore,
et vous ferez également une aide sur le sens des sections,
dans le sens où

    * Messages utilisateurs (99)
    * Messages Système (99)
    * Messages externes anonymes (99)

	n'est pas compréhensible par un étranger au système au premier abord.
	Il faut assumer votre système


réflexion interne start-------------------------------------------
07h59 : les nombres de messages par catégorie sont effectués
Cherchons une icône point d'interrogation sur le net que
nous placerons dans un dossier icône sur notre arborescence.
Afin de donner du dynamisme je vais faire un cadre qui apparaît lorsque l'utilisateur
met sa souris sur le point d'interrogation.
http://jqueryfordesigners.com/coda-popup-bubbles/
Ici, nous avons un système de bulles,
mais je le trouve trop lourd au niveau du code html,
je fais donc quelquechose de plus moche , mais plus léger.
De plus, étant donné que je compte réutilser ce plugin avec plusieurs settings
différent mais que ce n'est pas prévu dans la version de base,
j'ai modifié le code source du plugin pour en faire un plugin avec des options :
jquery.codabubble.asplugin.js

Il faut donc maintenant appeller le plugin depuis jquery,
je ne sais pas si ce que j'ai fait est propre, car j'ai des lacunes
en jquery javascript, mais bon ça marche...
De plus, j'ai ajouté l'option zeclass qui permet de choisir sa classe qui est par défaut "popup"

$(".bubbleInfo").codabubble({distance:10, time:	250, hideDelay:	100, zeclass:"popup"});

09h03 : ouf, j'ai fait une intégration qui est "identique" dans tous les navigateurs que j'utilise, dont ie7

réflexion interne end-------------------------------------------

09h03 : screenshot112.png

D'accord, bien.
Maintenant, occuppons-nous de la grosse partie commerce.
Créez sur papier toute l'organisation des pages au niveau de la partie commerces :
sur quelle page l'utilisateur arrive lorsqu'il clique sur l'onglet commerces,
les liens, la mise en page.
Vous mettrez en avant le confort utilisateur et favoriserez la facilité d'accès à l'information
pour les commerçants désireux de s'inscire.

Vous pouvez prendre une douche avant de commencer.

réflexion interne start-------------------------------------------
ouf, une douche, yes;
09h50 : j'ai conceptualisé la disposition que je veux faire sur papier.
Je vais la traduire sur photoshop :
en gros: le taostore disparaît.
Sous commerce, on a un sous-menu :
1. les établissements
2. les promos
3. les événements
4. les cadeaux


Certains de ces éléments mais pas tous ont eux-mêmes des sous-menus :
1. les établissements possède un sous-menu : la carte - la liste
et
3. les événements possède un sous-menu : le calendrier - la liste.

Photoshop est mon ami....
10h18 : j'ai ajouté le compte vendeur également,
voici la maquette que j'aimerais intégrer, la difficulté va être pour les sous-menus,
dois-je utiliser jquery, et sinon puis-je en css ?
screenshot113.png

Intégration...
http://www.cssplay.co.uk/menus/cssplay-pushpull.html

10h59 : en fait le css ça me casse les couilles, je vais refaire en javascript.

Hélas : j'aurais autre chose à faire pour midi : normalement dernière passe pour l'autre site.

11h42 : l'intégration est réalisée basiquement sur les navigateurs normaux (ffox, chrome et safari),
sans effet jquery avec affichage statique des liens des sous menus;
11h52 : les corrections sont effectuées sur ie7: le navigateur paranormal.

réflexion interne end-------------------------------------------

11h54 : la présentation papier est réalisée.

Bien, veuilez intégrer votre réalisation.

réflexion interne start-------------------------------------------
Héhé, il ne sait pas que j'ai déjà commencé...
Ca me fera gagner un peu de temps.


réflexion interne end-------------------------------------------

Hélas, grosse coupure sur toute la journée sur l'autre site...
03h36 : ben ça y est j'ai fini l'autre site,
chui dégouté d'avoir paummé ma journée de travail...

On essaiera de reprendre demain.

**** 06-03-2010

07h32 : start

23h22 : aujourd'hui c'était la journée d'install du nouveau serveur qui accueillera
la nouvelle version de Tours annonces, journée remplie avec du linux et des commandes.

Je suis carrément nul à chier en linux, ça prend donc un certain temps...

Résultat : tout semble ok, à part les mails,
peut être que demain sera la journée où j'essaie d'installer la fonction mail, ou pas.
Dans tous les cas j'en ai absolument besoin pour la sortie du site.

Le petit problème est que je ne suis pas sûr de réussir l'install.

Bref,

Voici mon planning mental :
le 10 je dois avoir fini le site dans sa version de base.
oups très court.

Et demain je ferais peut être que le mail, ou pas.

Bonbref, là je crois que je vais me coucher, ou pas.


Ah oui, j'ai oublié de dire que les nouveaux serveurs sont plus puissants que les serveurs actuels,
sensiblement, ou pas.


Hey, ling, qu'en est-il des 3 types de messages que l'utilisateur est censé reçevoir ?

Ah oui, il faut que je fasses visuellement une distinction
Ceci serait-il good enough ?
screenshot111.png


Oui pas mal, fais le!

00h15 : design is done.


00h38 :start list
00h42 : stop
01h49 : les fonctionnalités de la liste utilisateur_message ont été copiées
sur les autres listes : message_systeme et commerce_message_externe_anonyme

**** 05-03-2010

07h24 : start :

Travail sur l'autre projet...

09h13 : ca y est.

Ecriture et mise en place de la fonction d'envoi de message.

09h24 : Un nouveau problème se pose maitenant.
Lorsque u envoie un message, il est d'abord sur l'annonce,
puis il clique, il tombe sur le formulaire d'envoi de message;
ici, il me semble logique de le rediriger sur l'annonce une fois le formulaire rempli.
Problème : si u clique sur le bouton précédent de son navigateur,
il s'attend à être redirigé certainement vers la liste des annonces dont il provient,
ou sinon un autre lien venant d'une annonce similaire.
Mais actuellement, en cliquant sur précédent, u est redirigé vers le formulaire et
ce qui est très embêtant c'est que le formulaire est reposté dans la foulée,
spam.

http://forums.asp.net/p/1132444/1806081.aspx
Hélas ne marche pas sous firefox

Apparemment en javascript c'est pas possible ou du moins pas fait pour ça :
http://www.dynamicdrive.com/forums/archive/index.php/t-5284.html


09h40 : bingo !
Une solution simple et efficace :
le lien vers le formulaire s'ouvre dans un autre onglet du navigateur, pas de redirection à l'issue du formulaire validé, juste un message.

Finalement le mieux aurait été de l'appeler dynamiquement sur la page d'annonce;
Finalement le mieux aurait été de ne pas rediriger après remplissage du formulaire;

?

Ouai en fait chui pas fan du popup, je vais simplement ne pas rediriger l'utilisateur et mettre un lien en évidence retour à l'annonce;

choses de la vie...

10h47 : Bon ça me casse les couilles,
y a toujours un hic alors j'ai pensé à une solution :
window.close();
Pour ffox et safari et chrome, ça passe:
le formulaire s'ouvre dans un autre onglet et à l'issue du remplissage, si j'appelle window.close();
L'onglet se ferme et on se retrouve sur la page de détail d'annonces, avec l'historique nickel.

Sur ie7, hélas target _blank ouvre carrément une nouvelle fenêtre et lors du window.close();
dans mon cas me demande une confirmation de fermeture.

Pas top, mais me permet de garder une structure propre.
Pour l'instant garder comme ça, et au moment du fignolage si ya le temps faire un truc plus agréable pour l'utlisateur.

Aujourd'hui, plein de trucs à faire hélas...

choses de la vie.

13h05 : un petit peu de temps pour développer : j'ai activé le comprtement décrit ci-dessus.
Ok c'est pas mal.

Mon imprimante est en réparation, Tentative de décrassage aux ultrasons,
si jamais elle y laisse sa peau j'achéterais une laser couleur niarf niarf...


13h45 : affichage des messages dans la messagerie de mon compte.
screenshot108.png

Ok, pouvez-vous créer une mise en forme plus complète, avec des liens d'archivage, le lien de suppression,
et classer ces messages par section, avec la section archivés et la section normale.
Vous différencierez également de la manière qui vous plaît les messages lus des nouveaux messages pas encore ouverts.

Réflexion interne start------------------------------------------------------------------
Pour satisfaire au maximum un utilisateur,
je vais faire des boîtes qui s'ouvrent et se ferment, la boîte contient le message.
Mais ces boîtes auront une mémoire, de sorte que lorsque l'utilisateur recharge la page, les boîtes conservent
leur état d'ouverture
13h52 : ajout du champ ouvertferme dans la table utilisateur_has_utilisateur_message
13h56 : mise à jour de la méthode qui insère les messages;
14h16 : rien à voir mais j'ai une idée kool : rajouter une biographie dans le compte utilisateur;
cela permet à l'utilisateur de se décrire, et aux autres d'en savoir plus sur lui (on arrive vers les rencontres...)
Et l'idée kool c'est de rajouter à ce système un système de vote.
Ce qui découle sur un système de popularité des annonceurs.
Par exemple, je lis la biographie d'une meuf et je la kif, même juste visuellement;
Sans lire le texte je vais voter pour elle et si tout le monde fait comme moi elle apparaîtra dans le classement des
utilisateurs les plus populaires.
Bref, pour l'instant pas le temps.
Mais c'est bien de noter ce qui passe par ma tête.

14h50 : le comportement d'ouverture fermeture du message est en place avec mémorisation des boîtes.
Mais vu qu'on est en 2010, je vais l'amliorer un peu et ajouter un effet de slide pour l'ouverture et le fermeture plutôt que juste
montrer/cacher le message.
14h55 : slideToggle était mon ami

Le lien archiver implique une hiérarchisation, faisons d'abord supprimer qui ne pose aucune problème.
Si, en fait depuis tout à l'heure j'ai un problème pour savoir si j'utilise mon système de liste rapide.
J'aimerais bien mais comme il y a 3 types de messages, et que en plus ça peut évoluer, mon système de liste ne gère que un type à la fois.
Que faire ?
Améliorer mon système de liste (au risque de perdre la simplicité du système actuel)
Séparer les 3 types sur des sections différentes (seems good)
Faire le tri à la main.

Je vais prendre une douche d'abord.

15h22 : j'ai trouvé que je ne devais pas corrompre ma conception et donc faire 3 listes séparées.
Ca fait bizarre pour l'utilisateur d'avoir 3 types de message, mais c'est encore plus bizarre pour moi
d'essayer de faire comme si 3 structures différentes étaient la même.
Evidemment si j'étais un bon programmeur, j'aurais fait un adaptateur,
mais je pense pas que j'aies le temps maintenant, même si cela semble être une solution adaptée (mais lourde).

16h09 : organisation basique des messages en 3 parties, amélioration de mon script de liste
et mise en place de la liste pour les messages, avec tri sur le titre du message, sa date, mais aussi le pseudo
de l'expéditeur et enfin sur l'état ouvert/fermé, le moteur recherche sur le titre, le message et le pseudo.

16h29 : le comportement supprimer est en place.
16h45 : séparation des block par catégorie : nouveaux messages, messages lus, messages archivés.
Du coup, l'archivation d'un message ne consiste qu'à changer son état pour archivé,
puis visuellement déplacer le message de [nouveaux messages|messages lus] vers [archivé].
17h07 : le comportement est ruditairement en place, satisfaisant dans le sens où jquery permet
de faire un fadeOut() sur un objet, de l'appender à un autre puis de le fadeIn(),
ce qui donne l'illusion du transfert de l'objet d'un endroit à un autre.
Après mon implémentation présente encore quelques bugs légers.
17h15 : le comportement est activé,
il ne me reste qu'à mettre un lien sur le pseudo de l'expéditeur vers son profil et je pourrais montrer le résultat au maître.
Mais j'ai un truc perso à faire avant, ok plus tard...

En fait il n'y a pas encore de page pour voir le profil d'un utilisateur, il faut la créer avant.
Du coup, cela implique de terminer la page de profil (le compte des annonces, messages, etc, n'est pas fait.)

choses de la vie

23h53 : reprise sur Tours annonces,
écriture de la fonction qui compte le nombre d'items d'un utilisateur,
par exemple le nombre de nouveaux messages, ou encore le nombre d'annonces, etc...
00h29 : en fait la méthode que je voulais utiliser ne fonctionnera pas, car je voulais faire une requête globale
qui récupérait tous les items d'un coup, seulement certaines requêtes nécessitent un inner join et du coup le union
ne fonctionne pas correctement.

Du coup j'ai splitté cette requête en autant de requêtes que nécessaires.
Mise à jour des infos du profil et de l'accueil de mon compte avec les nouvelles données dynamiques.

Création d'une page sur laquelle on peut voir le profil d'un utilisateur (poursuite du trip de tout à l'heure en gros)

00h46 : la page d'affichage d'un profil est créée.
Bien entendu, elle respecte les choix faits par l'utilisateur au niveau de la visibilité du mail et du tél.
screenshot109.png

Bon, nous pouvons donc montrer le résultat final au maître.

Réflexion interne end------------------------------------------------------------------

00h48 : le système de messagerie est créé.
L'utilisateur peut lire ses messages,
il peut les archiver,
il peut les supprimer.
En réalité il peut ouvrir et fermer un message,
l'état d'ouverture de ce message est conservé en mémoire par le système.
Pour chaque message, un lien vers le profil de l'expéditeur est fourni.
Les messages sont ordonnés en liste.
Nous avons fait une séparation nette entre 3 catégories :
Nouveaux messages,
Messages lus,
Messages archivés.

Les tris possibles sont effectués sur les champs suivants :
titre, date, ouvert-fermé, pseudo

Le moteur de recherche cherche dans le tittre du message, ainsi que sa description, également le pseudo de l'expéditeur.
screenshot110.png

Le bonus : Lorsque l'utilisateur clique sur archiver, la transition du message de la catégorie Nouveaux messages (ou messages lus)
vers la catégorie Messages archivés se fait automatiquement, avec un fondu disparaissant, suivi d'un fondu réapparaissant dans
la catégorie Messages archivés.

00h56 : Ok, good job, you can go to bed.

**** 04-03-2010

07h13 : start


07h27 : l'affichage en liste d'un événement est réalisé basiquement sur ffox, chrome et safari,
pb affichage ie7.

07h32 : résolu en inversant l'ordre d'apparition du lien Voir le détail et du span proposé par le commerce XXX

07h33 : recherche d'une photo par défaut pour les événements
07h43 : la photo par défaut est intégrée aux listes.
07h44 : mise en forme de la liste pour le compte utilisateur store vendeur : ajout de la possibilité d'éditer et supprimer son événement.
07h46 : sauvegarde antiregisque
07h58 : ajout du texte de confirmation de suppression (alert simple en javascript)
A noter que :
comme le champ statut se trouve sur un événement, le fait de supprimer (qui revient dans ma conception à modifier le statut pour "effacer par l'utilisateur")
efface gloabelement toutes les occurrences de cet événement.
Théoriquement pour pouvoir le contrôle sur la désactivation des événements au cas par cas, il aurait fallu mettre le statut dans la table commerce_has_evenement.
Ceci dit, la possibilité d'éditer son évenement revient au même, puisque lors de l'édition, on choisit les dates liées à son commerce.
Si on enlève les dates, ces dates sont supprimées (et elles le sont réellement) de la table commerce_has_evenement.

08h13 : le comportement de suppression d'un item est en place.
Comme prévu, lorsque l'utilisateur confirme son choix d'effacer toutes les occurrences de son événement,
toutes les occurrences disparaissent visuellement et le nombre de résultats est dynamiquement décrementé du nombre d'occurrences de l'événement.

08h20 : constat de 3 problèmes :
1. la tailles des photos n'est pas correcte lors de l'au
2. Lorsque je clique sur éditer, les horaires multiples n'apparraissent pas
3. Lorsque je clique sur éditer, l'ordre des photos n'est pas préservé

08h27 : compréhension du pb 1 :
la fonction resize de phpthumb redimensionne une photo en préservant ses dimensions.
J'avais fait 2 photos pour cet au : la première au format 500x300 et thumb au format 100x100.
Sur mon serveur, la deuxième (et toutes les suivantes) est calculée à partir de la première et a donc 100x59.
En tant qu'administrateur, lorsque je dis 100x100, je m'attends à 100x100.
D'un autre côté les images distorsionnées ne m'intéressent pas et même jamais, c'est une erreur de ma part.

La fonction cropFromCenter dans ce cas là pourrait me servir,
mais en fait la plus adaptée est adaptiveResize, qui se débrouille pour transformer le format 500x300 en 100x100 en gardant les dimensions.
Elle est pas belle la vie.
08h33 : Correction du problème1.
08h37 : Le problème1 est résolu, et les feuilles de style à jour.

08h40 : compréhension du problème 2 et élaboration de la stratégie de résolution du problème :
Lorsque user clique sur éditer, il se retrouve sur le formulaire d'ajout/edition de l'item.
Il y a 2 choses à faire :
	A. Préremplir le champ date afin que lorsque user clique sur le calendrier, il retrouve tous ses événements (géré par jquery date-pick ;))
	B. Afficher la liste des horaires individuelles, dans mon cas, bien renseigner le tableau kustomData qui est automatiquement parsé pour afficher les
	horaires individuelles si il est correctement rempli.

08h58 : La partie A est résolue.
09h06 : la partie B est presque résolue, il me reste à déterminer si user a utilisé des horaires différentes ou common horaire,
afin de pouvoir réafficher exactement son setting.
09h15 : Partie B résolue.

09h17 : A chaque fois qu'on clique sur un lien lié à un compte vendeur, on doit remettre le nom du commerce dans la liste déroulante de nos commerces.
C'est chiant et source d'erreur d'incompréhension du système= pas intuitif, pas bien, bouh.
Tentative d'amélioration de la navigation.

09h25 : Amélioration effectuée, reste à prouver que c'est une amélioration.
Cela devrait en être une dans le sens où la majorité des commerçants n'auraont qu'un commerce à gérer, cela évite de choisir bêtement un commerce (sauf la première fois)
alors qu'on sait pertinnement qu'on en n'a qu'un.
Pour les autres cas, l'expérimentation dira si il est préférable de passer l'identifiant du commerce en cours (ce que j'ai fait là) sur chaque lien,
où si il vaut mieux forcer l'utilisateur à choisir son commerce à chaque action du menu.

09h29 : Compréhension du problème 3 et élaboration d'une solution.
L'avantage de ne pas utiliser une table dédiée pour les photos, c'est qu'on utilise pas de table pour les photos.
L'inconvénient de ne pas utiliser une table dédiée survient lorsque l'on souhaite trier ou ordonner ses photos.
Ici, nous sommes dans événement.
On peut concevoir que l'ordre n'est PEUT ETRE pas primordial, mais qu'au moins la première photo soit la bonne,
car c'est celle qui apparaît dans les listes d'items.
Pour juste résoudre le problème de la première photo, je pourrais imaginer de nommer les photos de manière incrémentale,
afin que l'ordre soit préservé.
Car en fait actuellement mes scripts parsent un dossier trouvé et le font donc en fonction du nom de la photo (je n'ai pas vérifié).

Le fait d'ajouter une table dédiée pour les photos m'oblige à revoir toute ma conception.
Du moins au moment de l'enregistrement (donc dans la phase de validation du formulaire)
et dans la phase de réaffichage.

Etant donné qu'il s'agit du compte vendeur, qui doit être la crème de mes services,
étant donné que j'arrive à visualiser à peu près l'ensemble du problème,
étant donné que ceci  contribuerait à une amélioration du service,
étant donné que cela pourrait être fait une fois pour toutes et que si je ne le fais pas ce problème sera forcément récurrent,
je vais corriger cela;..
pause

Stop : je viens de penser à une solution alternative :
et si je j'arrivais à dire à php de trier les fichiers par ordre de création.
Cela résoudrait (facilement) le problème de la première photo (qui est en fait à l'origine de ma réflexion).
Evidemment ça ne résout pas le problème d'un ordre choisi par l'utilisateur, mais comme dit plus haut,
ce n'est que un événement, je me permets de tester avec la solution de secours énoncée plus haut.


09h41 : ben pause annulée, tentative d'affichage par ordre chronologique.
oh et puis pause.
Apparemment hélas, avec les itérateurs pas de fonctions magiques qui permettent de trier automatiquement par ordre chronologique,
bon ben j'vais le faire à la main...

10h14 : le tri par ordre chronologique fonctionne, cela résoud mon problème pour l'instant donc je vais pas chercher plus loin.
Et en plus en fait ça respecte exactement l'ordre que l'utilisateur a indiqué dans le formulaire.
HAHAHAHA
Problème résolu à 100%.

10h19 : Désir d'améliorer la liste
10h20 : le trigger tri par nom a été ajouté

10h21 : screenshot98.png

10h23 : oups! J'ai oublié de formaté la date
10h25 : La date est formatée

10h25 : Création du détail d'un événement
10h27 : Je vais pas me faire chier, je vais repiquer le design du détail d'une annonce (J'ai une supervision globale du projet et des délais qui me
met en mode maquette expéditif: la stratégie : je place des petits tas à gauche et à droite pour avoir la forme générale, et plus tard je peux modeler ces tas.
En fait c'est du sable, je créé un château de sable, sable humide.
)

10h34 : OhMyGod j'ai oublié que l'adresse dans le formulaire, avec par défaut la valeur de l'adresse du commerçant.
10h37 : mise à jour du schéma sql : schema-commerce-evenement3.png

11h02 : sauvegarde antiregisque
11h05 : le formulaire est à jour. Mise à jour de l'affichage d'un item de liste evenement...
11h11 : l'item de liste événement est mis à jour.

11h28 : Des bugs dans le formulaire ont été corrigés;
11h34 : au niveau de la conception, de la même manière que en-dessous du détail d'une annonce on devra avoir un bloc affichant d'autres annonces
en rapport avec l'annonce sélectionnée,
ici pour les événements, on créera plus tard un module qui affichera les événements ayant lieu la même soirée

11h38 : Un nouveau réflexe de programmation arrive dans mon cerveau.
En fait pour afficher une page de détail d'annonce, il faut passer son id en GET.
Il se peut que un malotru ou google essaie tombe donc sur une page avec une annonce existante.
Dans le but de savoir qui a appelé quoi, je peux récupérer l'ip de l'entité ayant demandé cette page.
Enfin, d'après le navigateur.
Bref, en prévision de filtrer si c'est un robot ou un humain je sais que je pourrais faire une fonction
qui filtre et trouve si c'est un robot ou un humain à partir d'une ip.
Même si je n'ai pas encore cette fonction, rien ne m'empêche de l'appeler en prévision qu'elle sera écrite plus tard.
Pour l'instant
function getInfoIp($ip)
{
    return $ip;
}

et plus tard
function getInfoIp($ip)
{
	$ipOrBotname = $ip;
	// do everything you can to get the botname from this ip,
	// if you cannot, then it's an human return ip
	// else return the botname
    return $ipOrBotname;
}


Bref, tout ça pour dire qu'on a pas besoin d'avoir la fonctionalité pour l'utiliser,
cela permet simplement d'avoir un squelette opérationnel plus rapidement, et donc de développer
en ayant une logique organisationnelle très proche de la conception du développeur.


Ou
11h46 : comment perdre 8 minutes en blogguant de la merde.

11h58 : pause

13h47 : autre idée à développer, enfin je le dis là mais j'aurais certainement pas le temps de le faire ::
les utilisateurs peuvent mettre des photos après coup,
j'ai vu un site qui faisait cela, me rappelle plus le nom mais
ça permet de se remémorer la soirée.
Si jamais je le fais, il faudra également que le commerçant puisse modérer les photos en cas de débordements.

14h03 : le détail en d'un événement est créé, avec lien vers le commerce posteur.
screenshot99.png


14h06 : Bon ben chui pas en avance, il me reste environ 3h30 de travail pour aujourd'hui,
peut être 1-2h plus avec ce soir mais pas sûr, l'autre site à faire...

Faut maintenant concevoir et mettre en place le système d'ajout de promos des commerçants;
Aïe.

Dans les grandes lignes, ma pensée en construction à chaud sur ces lignes toutes froides....
Le commerçant doit pouvoir annoncer ses réductions, ses promos :
1 pizz achetée = 1 pizz offerte.
Son interface est variable :
(possibilité ou non de)
ajouter des photos
des titres
des légendes
des bidules
...

Sur le site possibilité de trier les promos afin de voir directement les promos.

Les promos devraient avoir pour finalité un affichage en liste et/ou en mur.
Pourquoi pas le mur des promos ?
Gardons liste pour l'instant car mur est synonyme de bordel dans ma ptite tête.


Donc une liste de promos.
Faîtes moi un visuel svp.

screenshot100.png

Bon ok,
donc ça c'est pour la partie recherche d'une promo, ensuite il faudrait un onglet promo incorporé avec les autres onglets (sections)
du commerce en question, c'est d'ailleurs la destination du lien en savoir plus.

Maquette ?
screenshot101.png

14h37 : Mouais, ok.

Champs de la bdd ?

titre (required)
validité (not null)
description complémentaire (not null)
date_creation (en interne)
statut (pour pouvoir déployer la logique du Design ItemUpdate)

[[[Coup de gueule
Yen a marre des champs null, j'ai abusé de mettre heure_debut, minute... en null, ca sert à rien, à corriger si le temps de le faire...]]]

Schéma sql ?
Aide : une promo appartient FORCEMENT  à un commerçant (on va essayer de simplifier pour aller plus vite)

schema-commerce-promo.png

Ok bien.

14h44 Formulaire ?
screenshot102.png

Ok, est-ce qu'il fonctionne correctement ?
Insère-t'il bien une entrée dans la table commerc_promo comme prévu ?

15h09 : Oui.
Je suis certes content que cela fonctionne, mais
15 minutes pour un formulaire aussi simple que celui là c'est du temps de perdu.
Je sais qu'il est possible de l'automatiser entièrement.
D'ailleurs j'avoue que je n'ai même pas essayé mon générateur alors que je l'avais, mais bon,
certainement qu'inconsciemment je pense qu'il n'est pas prêt ou que j'aurais du faire des modifs et donc que j'irais plus vite à la main.
Bref, lorsque viendra le temps des optimisations, cela sera un point relativement important puisqu'il fera gagner environ 10 minutes,
il ne restera que le "tour" à coder.


15h12 : Ok, liste ?

15h15 : top de fin avec tri sur le nom et la date, recherche sur le nom, mais il me manque la fonction d'affichage d'un item de promo.

Bien, crée donc cette fonction

15h19 : la fonction est créée basiquement, elle affiche les données issues de sql de manière brute.
screenshot103.png
Mais cela constitue un environnement suffisant pour tester la liste.

D'ailleurs je viens de découvrir un petit bug vicieux avec les pourcentages,
pas le classique qui permet l'injection sql, mais un autre dû au design de mon framework qui appelle sprintf pour afficher le résultat du moteur de recherche.
En faisant une recherche  sur la chaîne "-10%", il me dit qu'il n'y a pas assez d'arguments pour sprintf,
normal, vu qu'il a interprété le % et il manque donc un paramètre.
Il faut que j'échappe ce % pour sprintf.
15h32 : Comme cela ne concerne que l'affichage du moteur de recherche,
et comme je ne trouve pas la translation du caractère % en html (yavé pour mille mais bof.)
J'ai pris le caractère ÷ qui ressemble pas mal.

ok, petite pause et après mise en forme de la liste, délai prévu 16h terminé.

15h52 : la liste est mise en forme
screenshot104.png,
j'ai également ajouté la capacité au moteur de recherche de chercher dans l'adresse, le nom de la ville et le nom du commerce.

Bien, pouvez-vous donner vie au comportement de suppression ?
15h58 : le comportement de suppression est actif.

Bien et le comportement d'édition ?
16h00 : le comportement d'édition est en place.

Bien, nous ferons plus tard la page qui affiche les promos sur le site.
Pour l'heure concentrons-nous sur les grosses fonctionnalités pas encore développées.
Je ne parle pas du forum, c'est un peu tard, vu les délais,
mais la messagerie DOIT être active.
Comment pensez-vous créer la messagerie, je parle de la messagerie des annonceurs ?

16h03 : sauvegarde antiregisque


Un utilisateur (u) doit pouvoir envoyer des messages pour une annonce qui l'intéresse et ce depuis l'annonce.
Le résultat doit être que l'annonceur qui a posté l'annonce reçoit le message.
J'aurais aimé développé un système de tchat ou d'avertissement instantanné de notification de message.
Mais je sais que vu les délais qu'on a il faudra reporter cela à une autre phase de développement.
Pour l'heure,
L'annonceur qui reçoit ses messages est capable d'envoyer des mails via sa messagerie.

Le modèle ta4 est une catastrophe en terme d'organisation des données et de complexité.
Nous allons profiter du terrain vierge que nous avons pour purifier le système.

Jetons un coup d'oeil aux tables relatives à la messagerie déjà en place sur cette version.

Pour l'instant nous avons
     * des messages système
     * les messages commerce_message_externe_anonyme

A notre disposition nous avons déjà une classe qui sert en quelque sorte d'adapteur universel à toute forme de message
tel que nous le concevons :

class Tan_Private_MyMessage
{
    const STATUT_ENVOYE             = '1';
    const STATUT_LU                 = '2';
    const STATUT_ARCHIVE            = '3';
    const STATUT_EFFACE             = '4';
}


Peut être est-il nécessaire de commenter ces statuts :
STATUT_ENVOYE : C'est l'état du message dès qu'il est validé par le système (état premier du message)
La boîte mail de u affiche tous les messages avec le statut envoyé ayant pour destinataire u
STATUT_LU : au moment où u ouvre son message, le statut passe à STATUT_LU.
STATUT_ARCHIVE : survient lorsque u décide de volontairement archiver son message : il y aura un bouton qui permettra cette action.
STATUT_EFFACE : survient lorsque u décide d'effacer son message.
La boîte mail de u n'affiche JAMAIS un message avec le statut STATUT_EFFACE.

16h18 ...


Dans la version 4, nous autorisions un utilisateur externe à envoyer des messages à un utilisateur.
Ici, sûrement parce que à cet instant t j'ai mal à la tête (mal dormi ?),
j'ai envie de supprimer ce comportement afin de pouvoir me concentrer sur une réalisation très spécifique :
la messagerie inter-utilisateurs.

Pour les autres, ya le téléphone ou le mail, fppm.

Un problème qui pourrait se poser et comment cibler l'utilistateur à qui on envoie le message ?
Vu le nombre d'utilisateurs, une liste déroulante risque d'être trop grande.
L'autocomplétion semble le seul moyen raisonnable.

MAIS,

tout ceci n'est qu'abtstrait, dans le cas concret, un utilisateur ne peut pour l'instant communiquer avec un autre que par l'intermédiaire de son annonce.
(On évoluera plus tard)

Cela veut dire que l'annonce contient un lien qui permet d'envoyer un message à son destinataire.
Cela nous permet d'éviter de demander à u à qui il veut adresser son message, puisque nous récupérons cette info depuis l'annonce.

Vais me doucher g mal o crâne.

16h44 : ok ca va mieux.
On ne va pas faire l'erreur de ta4 : mettre le formulaire direct sur l'annonce, dynamiquement avec du javascript,
tout ça pour que l'utilisateur gagne 1 clic.
Les u ne sont pas des fainéasses non plus, faut arrêter ce délire.

Une page propre dédiée à l'envoi d'un message à un annonceur pour un n° d'annonce donné,
c'est beaucoup plus stable en terme d'organisation et d'évolutivité,
car la page est du coup attaquable de n'importe quel endroit.
Juste envoyer par GET le n° de l'annonce,
et dans la page, faire des vérifications basiques.

De la propreté, c'est tout ce que j'aime dans un code.


Bon, créons cette page.

Mais avant tout il nous faut un endroit où stocker les données, j'ai nommé une table sql.
Mais quelles données ?
Cela nous amène à réfléchir sur un échange entre utilisateurs.
En effet notre système de messagerie pourra servir de support à une discussion complète entre u,
mais que se passe-til alors lors d'une discussion ?

Je ne sais pas encore, mais imaginons,
(la conception ta4 était rééllement affreuse pour la messagerie)
Basiquement, nous avfons un message, un expéditeur et un destinataire.
Dans le cas qui nous intéresse, both expediteur et destinataire sont des u;

Le message a un titre et une date de creation.
A la limite, et même ça semble bien, on pourrait isoler le message.

Essayons de penser graphiquement.
Création d'un système basique d'organisation des données pour une messagerie interutilisateus.

Le schéma suivant me semble correct :
schema-utilisateur_message.png

Nous avons à gauche des utilisateurs (utilisateur u)

A droite, des messages (utilisateur_mesage).
Dans CE système, un message est forcément écrit par un utilisateur
(clé id_utilisateur dans utilisateur_message m).


Et le message a au moins un destinataire.
Effectivement, il peut également avoir plusieurs destinataires.

La table utilisateur_has_utilisateur_message (h) représente cette double possibilité.

Le statut est mis dans h et non dans m,
car dans le cas d'envoi du message à plusieurs u simultanément,
chaque u modifie le statut du message aà des moments différents.
Impossible donc d'avoir le statut dans m qui serait alors unique.


Imaginons le cas concret d'une discussion entre u1 et u2

u1 envoie le message donc son id est stockée dans m
une entrée est crée (statut= envoyé) dans h avec id_utilisateur = u2
et l'id utilisateur_message est déterminée par mysql lors de la création du m.

Que se passe-t'il ?

u2 arrive sur sa messagerie qui affiche entre autres tous les messages avec l'état (statut) envoyé.

En fait pour répondre à u1, u2 va tout simplement créé un autre message.
C'est donc un envoi de message, il n'y a donc qu'un cas.
On pourra toutefois préremplir comme il se fait dans d'autres systèmes le message avec le message précédent,
mais ce n'est qu'un particularité.
Ok ça me semble tenir la route;

17h13 ...

Pour revenir à notre formulaire ce n'est qu'un formulaire qui oriente les données.
Par exemple le titre sera préécrit.
On va éviter la bourde de la version précédente :
mettre A propose de l'annonce n°45230.

Oui t'es un brave gars mais c'est laquelle la 45230 ?
On va plutôt mettre le titre de l'annonce en littéral hein ?
Oui, c'est ça brave garçon...

La stratégie que nous allons employer pour satisfaire notre maître est relativement simple :
1. Créer une page qui contient notre formulaire.
2. ajouter le lien sur les annonces qui permet d'arriver à cette page.

Evidemment,
cela implique que la page créée en 1 soit réactive aux infos passées en GET.
Bon j'arrête de raconter ma vie...


Simplement pour moi, comme mémo :
La page 1 est protégée par secure_shell
Elle doit avoir un id d'annonce valide pour fonctionner,
car elle récupère l'id du destinataire à partir de cet id d'annonce;

Créer une classe pour l'envoi des messages,
UtilisateurMessage
notamment la méthode envoyer message Envoyer message qui prendra en paramètre
l'expéditeur, le destinataire, messageInfos

17h28 : création d'un script qui fait les vérifications de base et affiche l'id de l'utilisateur
destinataire (à partir de l'annonce) si les vérifications précédentes sont successfull.

En fait au niveau de la navigation,
je viens de m'apercevoir qu'il y a beaucoup de place sur le détail d'une annonce;
L'utilisateur a déjà cliqué une fois pour voir l'annonce,
il paraît logique qu'il puisse mettre son message directement.

17h38 : ajout du lien dans l'annonce.
screenshot105.png
En fait je l'ai mis directement dans Contacter l'annonceur,
et le lien mène bien vers une autre page;
Amélioration du script d'authentification qui propose maintenant un lien vers l'inscription:
screenshot106.png

Il y a un truc qui me casse les couilles c'est que mon générateur de formulaires gokin
génère des formulaires qui ne sont pas itemupdate.
Il est déjà tard, je dois arrêter,
mais je crois que demain ou ptet ce soir, je vais mettre à jour gokin.


choses de la vie.


23h39 : j'ai eu un petit peu de temps :
Je ne sais pas pourquoi je voulais utiliser itemupdate, il n'y en avait pas besoin.
screenshot107.png

Le formulaire est tout simple, il insère les données aux endroits prévus puis redirige
sur l'annonce dont on provient.
(C'est un script dédié pour cette fonction très précisément)


Par contre il y a un truc tout bête que je n'ai pas mis encore en place mais que je vais faire tout
de suite si j'ai le temps :
la vérification que le destinataire est différent de l'expéditeur.
Même si ça ne pose pas de problème particulier techniquement parlant.
Ca évite toute tentation qui aurait pour seul résultat d'encombrer la base inutilement.

01h43 : hélas j'ai du avancé sur l'autre projet.
Et demain matin je dois travailler encore un peu sur l'autre projet, j'estime 3 heures environ.

Donc je reprendrais demain vers midi mon travail sur Tours annonces, la messagerie.


Résumé : je suis quand même relativement soulagé d'avoir fini dans les grandes lignes la partie
commerce, je croyais que ça ne se terminerait jamais.
Mais les deadlines se rapprochent dangereusement...

**** 03-03-2010

07h27 : start
10h35 : j'ai fini pour l'autre site pour ce matin.

10h51 :
aH merde c'est pas celui là comme plugin mais celui là :
http://keith-wood.name/datepick.html

11h07 : trop fastoche, et intuitif, même pas besoin d'approfondir la doc.
screenshot93.png

Vraiment je m'en veux de ne pas y avoir pensé un jour plus tôt.

Maintenant, avant d'enregistrer les données, quelles formes auront les données...

Hmmm, intéressant :

http://iambari.com/2009/05/05/create-an-event-calendar-using-php-and-jquery/
http://www.stefanoverna.com/wp-content/tutorials/ical_like_calendar/

Il y a aussi bien sûr l'affichage en liste des événements, mais qui peut le plus peut le moins.

Je vais me taper les 2 liens et après je raccorderais mon formulaire à la base de données.

Ce qui m'intéresse ici, c'est la manière dont il récupère les données en sql :

$result = mysql_query("SELECT DATE_FORMAT(eventDate,'%d') AS day,eventContent,eventTitle FROM eventcal WHERE eventDate BETWEEN  '$current_year/$current_month/01' AND '$current_year/$current_month/$total_days_of_current_month'");

while($row_event = mysql_fetch_object($result))
{
	//loading the $events array with evenTitle and eventContent wrapped with  and 
. We will add them inside 
 in later part
	$events[intval($row_event->day)] .= '
'.stripslashes($row_event->eventTitle).''.stripslashes($row_event->eventContent).'
';
}

Il a une structure très simple avec juste un champ date.

Je pense à la suite, si l'utilisateur cherche les événements avant ou après une date, fastoche.

En fait oui, un seul champ date me paraît une bonne solution pour stocker les dates;
Je me demande pourquoi je voulais faire 3 champs jour, mois et année, certainement parce que intuitivement je pensais que j'en aurais besoin pour
afficher le calendrier, bref...

11h55 primo :
screenshot94.png

pause :
12h14 : mise à jour du schéma sql :
schema-commerce-evenement.png

12h26 : oups! et si l'utilisateur veut des horaires différentes pour chaque jour,
en fait je vais adapter ma conception, en fait il choisit d'abord les jours

16h52 : le formulaire est fait et il insère bien les données dans la nouvelle table.
Le formulaire est effectivement plus intuitif que le précédent :
l'utilisateur commence par choisir une ou plusieurs dates sur un calendrier, visuellement.
Quand cela est fait, il choisit l'horaire.
Une option à côté de l'horaire indique que cette horaire s'appliquera à l'ensemble des dates choisies.
Si l'utilisateur décoche cette case, autant de tranches que de dates choisies apparaissent en dessous
de l'horaire commune.
Si l'utilisateur coche à nouveau l'option utiliser cette horaire pour toutes les dates, les champs en dessous disparaissent
toggle

Si l'utilisateur choisit de remplir les horaires individuelles, le champ horaire commun est grisé.

A tout moment, l'utilisateur peut cliquer sur le calendrier visuel et ajouter/retirer de nouvelles dates.
A chaque fois qu'il le fait, les champs horaires individuelles se mettent automatiquement à jour,
sans pour autant effacer les champs que l'utilisateur a rempli précédemment.


Ce coup-ci j'ai géré ma conception au départ et je n'ai pas perdu de temps au niveau de l'organisation générale,
j'ai envie de dire du microcosme tellement le niveau de minutie me semble élevé;

Sur ce screenshot,
screenshot95.png
je viens de choisir 3 dates grâce au calendrier visuel,
puis je commence à mettre mes horaires individuelles...


choses de la vie.


23h01 : l'affichage des données sous forme de calendrier est en place;
Pour l'instant, je n'ai fait que les modifications nécessaires minimales pour que cela fonctionne,
je n'ai pas approfondi la logique du script, mais ça me paraît tout à fait correct.
screenshot96.png


23h59 : Je dois faire la liste pour afficher les événements d'un utilisateur (réservé compte vendeur)
Je veux voir si je mets vraiment 5minutes top:


00h05 : j'ai fini de configurer la liste, je n'ai pas regardé le résultat (car je dois faire la fonction qui affiche un item de liste avant,
donc je vais faire un visuel photoshop etc.. avant...), mais la liste doit normalement
avoir un tri sur le prix, l'id et le nom, (j'ai oublié la date, mais je la rajouterai après, ça prend 10 secondes)
un moteur de recherche qui cherche dans le nom et la description de l'événement
et un page link bien sûr
;)


00h24 : création du visuel d'un item de liste pour un événement.
A cette heure-ci faut pas trop m'en demander, c'est plus un croquis qu'un apreçu réel.
screenshot97.png

01h13 : bon, mes yeux se ferment, faut que j'y ailles.



                

**** 02-03-2010

05h52 : start
pause cause état léthargique

08h01 : restart

09h49 : moment historique dans ma petite vie de développeur,
l'interface de mon module de planing est prête.
Sur le screenshot, j'ai fait un exemple de chaque.
En face de l'indication "Ajout d'une date", on choisit une méthode,
et en fonction de la méthode choisie, une interface adaptée apparaît
screenshot92.png

On peut ajouter autant de tranches que l'on veut ou retirer la dernière tranche.

Bon, ça c'était la partie facile,
maintenant la partie semi-difficile :
le réaffichage des données en cas d'erreurs dans le formulaire,
puis la partie difficile,
la conversion des données du formulaire dans la base de données...


Oups j'ai parlé un peu vite, ie7 n'affiche pas mon module...

Ca y est il l'affiche : erreur de syntaxe : un tableau avec une virgule après la dernière entrée : erreur fatale apparemment.
Mais il l'affiche presque bien sauf pour la partie calendrier.

10h13 : ca y est après une petite bidouille pas trop méchante : j'ai viré le label et remplacer par un div container...



11h01 : Oups j'ai oublié d'ajouter l'année (pour éviter que l'utilisateur, au mois de décembre ne puisse pas insérer un événement pour l'année suivante.)
11h09 : L'année est rajoutée dans le formulaire, =l'année en cours plus la suivante

Pour la partie délicate de convertir les dates à partir du nom du jour,
j'ai trouvé que strtotime devrait m'aider largement :
http://www.php.net/manual/fr/function.strtotime.php

mais je ne l'ai jamais utilisée encore

13h44 : la partie récupération des données, vérification et préparation pour l'insertion en bdd est faite.

Passons au réaffichage des données dans le formulaire.

pause

14h42 : Je suis bloqué par ma validation au niveau des horaires : pas possible de mettre
debut : 21h
fin   : 01h

car pour mon système la date de début doit toujours être inférieure à la date de fin.

Bon, ben je retire cette validation, les utilisateurs n'ont qu'à faire attention à ce qu'ils mettent.
16h04 : dès fois il suffit de peu : un peu mal mangé et on a ma tête dans le guidon.
J'ai du paumé 3/4 d'heure sur un bug à 2 sous.... pfff...
Ca y est les données se réaffichent bien sous ffox, aussi pour les autres navigateurs,
par contre je viens de trouver un bug de logique...
16h34 : Ca y est réparé, en fait c'était de la même veine que l'autre, un mauvais nettoyage de guillements, grrr.

Bon, plus que l'insertion dans la bdd.

16h50 ajout du champ id autoincrémenté à la table commerce_has_evenement, sinon mysql n'accepte pas les entrées dupliquées...

17h06 : oups ! mauvaise nouvelle, je vais devoir faire l'intégration de pages sur l'autre site qui n'a rien à voir avec Tours annonces,
le problème c'est qu'il veut un carousel à la fotolia et un carousel vertical, bref, beaucoup de temps en moins en perspective...


17h22 : l'insertion fonctionne,

mais il y a un problème au niveau du réaffichage des données statiques, en fait je ne l'ai pas encore fait...
Là j'ai un réél problème : il y a un grand décalage entre les données insérées en bdd et les données du formulaire.
Très difficile de récupérer les données du formulaire à partir de la base : aussi difficile
que de regarder un planning et d'essayer de retrouver comment il a été dessiné, avec quelles méthodes : par jour ? par numéro de jour ?
est-ce que l'utilisateur avait coché un mardi sur 2 ? etc...

En fait il me faudrait une table dédiée pour réafficher le formulaire tel que l'utilisateur l'a laissé.
Ca commence à partir en couilles, mais il n'y a pas beaucoup d'autres solutions que je vois.

Oups, j'ai trouvé, mais c'est pire que ce que je pensais : une autre conception :
un grand planning qui représente toute l'année et l'utilisateur clique sur les cases qui contiennent l'événement.
A chaque fois qu'il clique sur une case, les infos sur les horaires et le prix apparaissent sur le côté.
Il peut cliquer sur toutes les cases si il veut.

Voilà, une journée à blanc, développer un petit module sympa que personne ne verra, je vais le garder quand même,
mais bon il est plus ou moins obsolète maintenant;

Et ce soir, bloqué sur un autre site, je suis ravi...

Le pire c'est que je crois que mon module jquery de datepick le fait de base
si j'arrive à faire un mélange entre ça
http://www.kelvinluck.com/assets/jquery/datePicker/v2/demo/datePickerMultiMonth3.html
et ça
http://www.kelvinluck.com/assets/jquery/datePicker/v2/demo/datePickerMultiple.html

c'est bon.

Encore une fois, je viens de prouver qu'une bonne conception C'EST LE PLUS IMPORTANT,
ça évite de se prendre juste des journées dans la gueule...


Hélas mon temps de travail sur Tours annonces est écoulé pour aujourd'hui...

choses de la vie
02h32 : là j'peux plus, j'ai bientôt fini mon travail sur un autre site, j'ai trouvé le module de apple (comme fotolia, paraît que c'est le module d'itunes)
Il s'appelle coverflow.

Demain faudrait que je finisses rapidement ce travail, puis que je corrige mes boulettes de conception d'aujourd'hui et ..
je pense pas finir demain pour la partie commerce, mais on verra.

                

**** 01-03-2010

06h44 : start
C'est quoi ce mois de merde avec seulement 28 jours,
ca va pas me mettre en avance ça.
A croire que le monde est fait pour tourner avec des exceptions.

Bref, j'ai trouvé ce qui n'allait pas dans ma conception :
c'était basé sur du abstrait.
Au moment d'utiliser mon système de taostore, je ne pouvais pas car je n'en éprouvais aucun besoin
(ajouter un moteur de recherche achetable ? Aucun intérêt).

Cette nuit et ce matin, j'ai trouvé le seul et vrai intérêt concret du taostore (pour l'instant).
Lorsque un commerçant fait un cadeau à Tours annonces (comme pour le loto),
et bien là il le mettra sur le taostore : par exemple la pizza pour 10 tao.
Cela donnera de la valeur au tao, et cela empêchera le flop du loto du genre
personne ne vient chercher son lot.
Enfin disons que cela le réduira, car à partir du moment où vous ahcetez, je considère que vous allez faire la démarche de récupérer ce que vous avez acheté,
ou sinon j'y comprends plus rien.

Donc le taostore est juste fait pour que les commerçants proposent des cadeaux.

De plus le système de preuve d'achat est démesuré,
aucun besoin dans un système de points virtuels.
Je sais pas quelle mouche bizarre m'a piqué lors de la conception : il y a déjà une preuve d'achat :
utilisateur_has_produit, pas la peine d'en rajouter.

Donc ça c'est le premier point.

Ensuite, en pensant aux besoins des commerçants, j'ai trouvé 2 autres choses que je vais développer,
mais de manière très basique pour l'instant (mais évolutive) vu le temps qu'il me reste :

L'activité des commerces (au sens évenementiel) :
pour savoir les soirées qu'il y a.
Par exemple si tel café fait une soirée salsa tel jour, tournoi de poker etc...
qu'il puisse les inscrire de manière périodique (genre une fois pour toute) ou ponctuelle
sera une fonctionalité proposée par Tours annonces.
La mise en forme (je me répète) sera basique pour l'heure, voire rudimentaire,
mais cela permettra de l'autre côté aux utilisateurs d'avoir une idée de l'activité des commerces de Tours annonces.

Deuxième idée : le fait que les commerçants puissent annoncer leurs promos sur une page spéciale,
afin que les utilisateurs puissent voir directement les promos des commerces de la ville (enfin ceux qui sont sur Tours annonces).

Mais quelle est la forme d'une promo en général ?
Pour l'instant je n'ai pas trouvé et pas envie de me prendre la tête sans expérience du terrain.
De tête il y a plusieurs types : par pourcentage, somme fixe, ou X offert(s) pour Y acheté(s).
Il peut également y avoir une date de validité pour la promo.
Mouais à la limite partir sur cela.

Bon voilà le plan de la journée :
commencer par développer l'interface du commerçant.



Le plan :
1. ajout de la possibilité d'ajouter des cadeaux sur Tours annonces
2. ajout d'événement
3. ajout de promos


1. ajout de la possibilité d'ajouter des cadeaux sur Tours annonces
Je vais détourner mon schéma actuel, ou plutôt l'orienter de manière concrète.
Le seul point délicat c'est comment un utilisateur récupère son cadeau.
J'ai pensé à un système de code (mot de passe) que le commerçant fournit en même temps qu'il offre le cadeau (champ special_id)
L'utilisateur doit se présenter au commerce et fournir ce mot de passe pour obtenir le cadeau.

Pas besoin de changer le schéma, c'est juste que la quantité sera très souvent 1 et que la seule catégorie de store_produit sera cadeau.
Et le champ special_id pour un cadeau sera utilisé par le commerçant afin qu'il indique son mot de passe.
Finalement mon travail n'est pas perdu.


Théoriquement avec cette nouvelle conception, il faudrait que je remplace la table store_vendeur par commerce directement.
Mais on ne sait jamais, peut être que plus tard j'en aurais besoin (=je proposerais des plugins à acheter en tao ou les utilisateurs utiliseront le système d'une manière ou une autre ?)

Donc je vais dire que les 3 points que je vais développer sont des extras services pour les commerçants qui ne sont pas
compris dans l'offre gratuite de base.
Ce seront des services donc payant (ah enfin).
Disons voici mon offre :
pour un certain prix le commerçant a une interface professionnelle qui inclut (en plus de l'offre de base gratuite)
les 3 fonctionnalités que j'ai dit que j'allais développer aujourd'hui ou demain ou après demain ??
A savoir possibilité d'ajouter : des cadeaux, des événements, des promos.

Alors oui, cela ferme la possibilité d'être un maximum exhaustif pour les utilisateurs et effectivement cela m'embête.
Tous les commerçants qui ne souscriront pas à l'offre ne pourront pas annoncer leurs événements = information moins exhaustive sur la ville.

Ca m'embête d'un côté et de l'autre si je fais tout gratuit je ne gagnerai jamais d'argent,
et puis si je gagne de l'argent avec cela, mon but est bien de réinvestir 100%
dans la pub de Tours annonces, du coup cela inciterait plus de commerçants à s'inscrire.
Ne m'en veuillez pas pour ce choix, utilisateurs.

Donc si le commerçant a un compte vendeur, il peut ajouter des cadeaux;
Ok...

08h30 : ajout de la possibilité de créer un compte vendeur pour un commerce donné dans l'admin;
pause

09h35 : création d'un squelette de page commerciale pour le compte vendeur


17h52 : de nombreuses choses que je montrerais plus tard,
mais là le plus important c'est que j'ai encore amélioré mon système de listage,
on s'approche d'une abstraction qui est pas trop mal, tout en gardant bien la main sur la kustomization;

18h07 : amélioration de mon framework sur les listes.
Alors là, normalement je dois mettre 5 minutes (vs 1heure) à faire une liste (avec n'importe quel tri, moteur de recherche et pagelink inclus)
: 3 minutes pour faire la requête sql (c'est le plus dur),
et 2 minutes de configuration. MwhAHAHAHAHA
Attention toutefois cela n'est valable qu'à partir du moment où la fonction d'affichage d'un item de la liste est déjà prête.
J'ai hâte de voir si je dis vrai sur la prochaine liste.


18h57 : le commerçant peut ajouter des cadeaux sur Tours annonces.
Si il le fait, oh puis non je raconterais ça ce soir...

pause

et même des vacances...





2. ajout d'événement


20h12 : round 2 : fight!

Bon alors quoi, c'est quoi le délire là !
Des évenements ? ok.
Un évenement appartient à un commerce, ok?
non mais.
création de la table sur papier...
non, réflexion sur le formulaire :
le premier problème intéressant surviendra lorsque l'on demandera à l'utilisateur
de dire :
quand se situe votre événement,
et là c'est la foire ::::
certains vont dire tous les 6 du mois,
d'autres vont dire le jeudi entre 16h et 18h
D'autres vont vouloir sélectionner 3 dates ponctuelles :
le mardi 6 janvier, le lundi 12 mars et le 4 octobre (à des heures différentes évidemment)


L'objectif est de canaliser tous ces désirs en un formulaire simple et intuitif.

Euh, yakelkun pour médé siouplé.

Non ya personne tut'demerdes.


La difficulté est le 6 de chaque mois et tous les mardi.

Ca y est j'ai trouvé :
L'utilisateur ajoute des tranches, et chaque tranche peut se copier de la précédente.
Une tranche est une configuration complète qui inclut les choix suivants .

choix1 : par numéro du jour ou par nom du jour ou par calendrier(choix ternaire)
choix2 : horaires (listes déroulantes)
choix3 : quels mois (12 cases à cocher, seulement si il n'a pas pris par calendrier au choix1)
Si au choix1 il a choisi par nom du jour, proposer également le choix4 : quelles semaines (4 cases à cocher)

Voilà, j'espère que je me gauffre pas trop dans la conception.

Et encore un formulaire qu'il est pas simple, un de plus pour bibi.

Pour les autres champs c'est du gâteau :
nom de l'événement,
description,
prix (entrée)
photos
lieu (normalement c'est le commerce qui inscrit l'événement, mais prévoir un champ autre adresse)


Je sens déjà que la requête sql qui va devoir afficher le calendrier va être infernale,
surtout si elle le fait dynamiquement, à moins qu'il y ait tout bêtement une table qui SOIT le calendrier...

Non en fait j'ai trouvé la soluce qui est pourtant hyper logique et même naturelle :
un commerce a des événements
commerce_has_evenement est la table qui contient toutes les dates.
Fastoche.

Par sécurité la table s'appelle evenement et non pas commerce_evenement, car on ne sait jamais ce qui peut se passer par la suite;

En fait, mon événement est indépendant du commerce qui le propose!

Conceptuellement, c'est assez délicat aussi, ca veut dire qu'un événement n'a pas de date en soi!
mais qu'il lié à une date par un commerce.

Quitte à concevoir de cette manière, autant aller jusqu'au bout du raisonnement :
un événement n'a pas de lieu en soi, mais est lié à un lieu par un commerce ou une autre entité.
Par exemple le festival de la musique à lieu aujourd'hui dans la ville x et demain dans la ville y,
mais c'est le même événement.

Encore un point traumatisant :
un événement peut dans la réalité être proposé par plusieurs commerces en même temps.
Pour refléter cela, faudrait-il que j'inverse la notion d'appartenance pour finalement dire :
que un événement a des commerces ?
evenement_has_commerce.

méditation à mon secours...

Malgré un passage aux toilettes, je n'ai toujours pas trouvé la solution,
pourtant d'habitude ça marche...

par contre j'ai pensé à une case partenaires...


Mouai, c'est le mieux que je peux pour l'instant,
et c'est franchement pas la priorité, si je pense que j'ai le temps je l'ajouterai dans le formulaire sinon tant pis.

De toutes façons cela n'impactera que la table commerce_has_evenement (ça y est j'ai décidé)
donc je pourrais le rajouter ultérieurement.

Finalement j'ai passé le prix dans la table commerce_has_evenement

Cela nous donne :
schema-commerce-evenement.png

Bon maintenant il faut que j'arrête de raconter ma vie et que je me mettes au travail, il est 21h15

Juste pendant le temps de ma sauvegarde antirégisquerie :
21h49 : mon robot gokin m'a généré toute la partie simple du formulaire : nom description et photopath avec l'automatic upload, un vrai bonheur, à peu près 5 minutes
de travail pour le formulaire de base...


Par contre il me génère un formulaire qui n'est pas itemupdate design .... blazé...


00h29 : Je ne sais pas si c'est parce que je suis fatigué ou si c'est parce que c'est dur, mais là ce formulaire est bien balèze,
comme je les aime.
J'espère que j'aurais au moins fini le formulaire demain;

Résumé de la journée :
ben là chui fatigué,
mais disons que j'ai  trouvé une méthode que j'aime bien pour faire les listes relativement rapidement.
Et que j'ai hâte d'avoir d'autres listes à faire.


Au niveau de l'avancée,
j'ai ajouté dans la partie commerce plusieurs liens
screenshot86.png

Donc lorsque l'on clique sur "activer compte vendeur"
On tombe sur cette page
screenshot87.png

sur laquelle on peut choisir son commerce (si on en a plusieurs),
puis on active son compte quoi....
D'ailleurs un petit bug à corriger plus tard, les tao ne sont pas enlevés du compte de l'utilisateur...
Bref,

Le lien "en savoir plus sur le compte vendeur" vers une page toute moche que j'ai fait juste histoire d'avoir la logique en place !
screenshot88.png
Dans ma conception, c'est la page qui présente l'offre commerciale du compte vendeur, à finir plus tard.

Ici la page d'ajout de cadeau pour un compte vendeur donné :
screenshot89.png

Et ici la liste des cadeaux d'un utilisateur pour un compte vendeur donné
screenshot90.png

D'ailleurs on voit bien un bug d'affichage sur le screenshot,
ma fonction affiche Série limitée : encore produit(s) il manque la quantité,
rebref...

Sinon, on peut quand même remarquer mon système de liste qui là est très bien et dans sa version ultime pour l'instant :
moteur de recherche, tri (ici par date et prix), pagelink en bas.

J'ai ajouté la possibilité de supprimer et éditer ses cadeaux.
Normal quoi.
Le compte vendeur cela doit être la crème de mes services...


Et là j'en suis ici
screenshot91.png

Et là rien ne marche, j'en suis encore dans la conception de l'interaction javascript php pour
m'afficher des tranches horaires, bref c'est le chantier...
Comme c'est un gros formulaire, enfin disons difficile pour mon niveau,

je me donne la journée entière pour le finir demain;

Espérons que j'y arrive.

Et un autre jour pour finir la partie commerces que j'ai prévue aujourd'hui : à savoir la liste des événements,
l'ajout de promos et la liste des promos.

Bonbref,


                

**** 28-02-2010

07h40 : start

08h05 : conception du système d'achat :
L'utilisateur clique sur je prends : il arrive sur la page d'achat qui présente un récapitulatif des infos sur le produit acheté et
demande une confirmation d'achat (Etes vous sûr ?).
Cette page est protégée par secure-shell (seuls les utilisateurs loggués peuvent y accéder)

Une fois la confirmation validée,
la même page est rechargée et effectue une série de contrôles.
Un test invalide entraîne le réaffichage de la page avec un message d'erreur correspondant.
Si tous les tests sont validés, la transaction est effectuée,
j'ai pas encore pensé la suite.

08h31 : ajout de règles de validation sur les dates au formulaire d'ajout de produit (oubli de ma part)
: la date d'expiration doit être supérieure à la date de lancement,
et la date d'expiration doit être supérieure à maintenant.


08h36 : mise à jour des requêtes d'affichage pour qu'elles ne prennent en compte que les éléments valides au niveau de la date.

Très content d'avoir misé sur le bon cheval avec date time :
AND NOW() BETWEEN date_lancement AND date_expiration
ajouté à ma reqûete initiale permet de filtrer les résultats comme espéré, et à la seconde près, et en conservant
un confort de lisibilité dans la bdd, dire qu'avant j'utilisais les timestamp, haha.


09h14 : création à la volée de la page d'achat, phase de récapitulation :
screenshot83.png sur ffox.

A part ie7 qui affiche cela :
screenshot84.png

chrome et safari comme ffox


09h26 : ajout de la fonctionalité au framework qui me permet d'écrire des conditional comments (ou quoique ce soit d'autre) pour une page en particulier.
Très pratique.
Le bug d'ie7 est résolu. J'ai mis le div en float:left; pour ie7

09h54 : il y a quelque chose de vraiment embêtant dans mon design : l'utilisateur est obligé de remplir une date de lancement et une date
d'expiration et une quantité : 3 contraintes dont j'aimerais me débarasser.
J'aimerais pouvoir créer un produit de durée infinie en quantité infinie.

10h38 : mise à jour du schéma sql pour accepter la valeur NULL sur les champs date_lancement et date_expiration de la table store_produit,
ainsi que sur le champ quantite de la table store_vendeur_has_store_produit.
Mise à jour du formulaire (méthodes de vérification des données)
Mise à jour de la requête sql d'affichage.
Le snippet suivant

                AND (
                    (date_lancement < NOW() OR date_lancement IS NULL)
                    AND
                    (date_expiration > NOW() OR date_expiration IS NULL)
                )
                AND (h.quantite > 0 OR h.quantite IS NULL )

permet d'avoir exactement le comportement que je souhaitais
http://dev.mysql.com/doc/refman/5.0/en/working-with-null.html

Heureusement qu'il y a la doc, sinon j'y aurais passé la journée.
Donc dans mon nouveau système de conception, NULL = infini.

C'est un peu plus lent théoriquement de travailler avec des valeurs NULL et mysql,
mais ça s'adapte tellement à mon cas, on dirait que cela a été conçu pour mon cas ;)


11h29 :
Pour ma table store_preuve_achat, j'ai besoin de nombreuses infos sur l'utilisateur : nom, prénom, adresse, mail, tel ;..
idem pour le vendeur.
A la question traumatisante dois-je obliger les utilisateurs à remplir toutes ces infos ?
Je dis :
l'expression "forcer un utilisateur à faire qqchose"
m'est très pénible.
En tant qu'utilisateur j'aime bien ma liberté.
D'un autre côté, une ça fait moins sérieux une preuve d'achat sans infos sur l'utiliateur,
mais finalement je me dis qu'on a quand même l'id de l'utilisateur.
Cette donnée est aussi stable que ma base de données et disparaît si la base de données n'existe plus,
c'est en quelque sorte la faille.

Bon, pour revenir au problème, je ne force personne :
si les infos existent, elles sont ajoutées à la preuve d'achat.
Bref.


pause

14h08 : ajout de la table manquante au puzzle : utilisateur_has_store_produit
schema-store6.png

15h36 : oups! le bug d'affichage d'ie7 était en fait pas tout à fait corrigé...
15h48 : bug résolu.
Lorsque l'utilisateur clique sur le lien je prends,
les données sont insérées dans les différentes tables et l'utilisateur est redirigé sur cette page.
screenshot85.png


17h11 : ajout du champ identifiant_numerique dans la table store_preuve_achat :
le but est d'avoir un identifiant unique indépendant de id (en cas de transfert de table)
Numérique car formaté comme ceci :
YYYYMMDDXXX
où XXX est un nombre sur 3 chiffres, permettant donc 999 identifiants par jour.
Numérique donc pour permettre une recherche avec MAX de mysql pour déterminer le nouvel identifiant.

17h33 : Ecriture d'une fonction pratique qui trouve l'identifiant en fonction de la table
/*
 * Retourne un identifiant unique basé sur un timestamp inversé,
 * avec 3 chiffres
 * YYYYMMDDXXX
 * Attention $fieldname doit être un champ numérique BIGINT sinon les résultats ne sont pas
 * prévus
*/
function getIdentifiantNumeriqueFromTable($tablename, $fieldname='identifiant_numerique',$baseDate='')
{
    if(empty($baseDate))
    {
        $baseDate = date('Ymd',time());
    }

    $stmt = "select MAX($fieldname) as max from $tablename where $fieldname LIKE '$baseDate%'";
    $r = Ling_Sql_Basic::freeFetch($stmt, array());
    $max = $r['max'];
    if(NULL === $max)
    {
        return $baseDate . "001";
    }
    else
    {
        return (float)$max + 1;
    }
}



choses de la vie

00h10 : panne sèche :
pas une ligne de code ne sort ce soir,
et les seules lignes qui sortent bien en retard sont celles d'un piètre humain qui ne sait plus quoi faire;
En fait tout d'un coup je ne voyais pas l'intérêt du taostore et tout le tralala.
A qui cela profite ?
Ben un ptit peu aux utilisateurs mais à peine, je vois plus l'intérêt, et donc je peux pas développer qqchose si j'ai pas la motivation pour le faire.
Logique.

Ca me fait chier de perdre 1.5 jour de développement pour rien, j'espère pouvoir réexploiter mon travail plus tard.

Dans ma remise en question solitaire, je me suis demandé entre autres mais comment je vais faire pour gagner de l'argent.
Et je n'ai pas trouvé de réponse toute faite,
mais il fallait d'abord développer un service béton, et
donc se recentrer sur le service de base d'annonce.
Et pas le gadget qu'est le taostore.
Je vais mettre toute le nuit à m'en remettre.

L'avantage d'être seul est d'être libre de ses mouvements.
L'inconvénient d'être seul c'est que qu'il n'y personne pour vous dire que vous êtes en train de vous prendre un mur.


Mon but c'est de sortir une version le 27 mars.
Rien à branler du taostore,
mais je veux un super service au niveau des annonces, et bon des ommerces.

Toujours dans ma réflexion, je me suis dit que les commerçants voulaient annoncer des choses,
mais qu'ils n'avaient pas besoin de taostore pour cela.

Leur interface leur permettra théoriquement d'ajouter autant de sections qu'ils le désirent.
C'est plutôt l'offre pour les commerces que je devrais développer, ou un système d'alerte pour les annonces.


Je crois que demain je vais commencer la phase finale. Un grand coup de finalisation sur tout le site,
avec juste les annonces et les commerces et plus tard travail sur la procédure de rappatriement des données de ta4 vers ta5.

Et seulement dans un deuxième temps les gadgets, genre forum, taostore, etc...
Sinon, j'ai peur de me perdre dans les détails.

Il y a encore des tas de choses que je dois voir même juste avec les annonces et commerces.
Il faut que je lâche prise pour l'instant et que je me recentre.

Que la nuit me porte conseil.


                

**** 27-02-2010

07h37 : start

09h06 : mon script d'upload a un comportement qui me plaît, je vais essayer de l'intégrer directement dans mon formulaire.

09h48 : le comportement est intégré semi-automatiquement :
j'indique au dans la partie commentaire du champ dans la table mysql (automatic upload)
et il me génère toute la partie formulaire;
je dois finir en créant (copier coller) un fichier de configuration à la main.

10h38 : ajout d'une fonction qui affiche les select heures et minutes et mise en place d'un design agréable
dont le code permet de facilement convertir les différents formats de date du formulaire au format datetime.
avec un hack myself tout de même.

En fait hier j'étais trop fatigué pour en parler mais j'ai beaucoup travaillé sur
un design de formulaire (paske les formulaires ça commence à grave me péter les couilles),

ITEMUPDATE DESIGN
c'est en très très gros un formulaire qui se base toujours par rapport à un item existant, et l'item appartient à un utilisateur
Il n'ya pas d'insertion au moment de la validation, que des update, d'où son nom.

L'init du formulaire fait qu'à la fin de l'init,
NOUS AVONS $id_item disponible pour le reste du script.

Du coup, au moment de la validation, on fait forcément un update sur id_item, entre autres...

L'init implique simplement un champ dédié nommé statut dans mon cas, qui peut prendre au moins les valeurs suivantes :
créé, en cours de création.

Algoritme de l'init
if(isset($_GET[id_item]))
alors c'est une modification
on récupère les données par rapport à id_item fourni

sinon
on essaie de récupérer l'item par rapport au statut en cours de création et à l'utilisateur
Si une telle entrée existe, on récupère les données à partir de l'enregistrement trouvé,
sinon on créé un enregistrement vierge avec le statut en cours de création pour l'utilisateur donné,
et on récupère bien sûr id_item;


Il me semble que c'est le cas typique de formulaire que je rencontre.
On verra au fur et à mesure si mon design couvre la plupart des formulaires ou pas.

En gros pour ceux qui captent :


if(isset($_GET[GET_PARAM_ITEM]))
{
    $id_item = (int)$_GET[GET_PARAM_ITEM];
    $kustomData = Ling_Sql_Basic::freeFetch($fetchRequest1, $aValues1);
}
else
{
    // recherche d'un item en cours de création pour l'utilisateur présent.
    $kustomData = Ling_Sql_Basic::freeFetch($fetchRequest2, $aValues2);

    // pas d'item en cours de création trouvé, c'est un insert
    if(false === $kustomData)
    {
        // partie specifique
        $id_item = Tan_Private_ItemUpdate_StoreProduit::insertVierge($insertOption);
    }
    // l'item en cours de création est trouvé, c'est un update
    else
    {
        //a($kustomData);
        $id_item = $kustomData['id'];
    }
}


11h47 : ajout d'un champ spécial dans la table store_produit,
conçu dans le but d'ajouter des fonctionalités supplémentaires sur des produits particuliers.
Par exemple, si je propose à la vente un moteur de recherche,
Lorsqu'un utilisateur achètera mon produit, des interactions auront lieu dans la bdd qui feront
que cet utilisateur obtiendra le moteur de recherche.
Je créé donc le champ special_id qui contient dans ce cas moteur_recherche par exemple;

pause

13h16  : simplification du schéma store
schema-store4.png

La table store_produit_has_store_categorie a été supprimée.
Après avoir réfléchi, c'est un peu trop abstrait d'avoir un produit qui appartient à plusieurs catégories.
Dans mon cas concret, les catégories sont pour l'instant :
plugin

Je rajouterai plus tard des catégories du genre
promo

Mais bon, on voit mal l'intérêt d'appartenir à plusieurs catégories en même temps,
ou peut être ue j'anticipe pas assez, mais bon, pour l'instant c'est plus simple de
me dire qu'un produit appartient à une catégorie, basta.

13h33 : dans ce cas là, autant utiliser l'arborescence qui est faite pour cela;
schema-store5.png

13h56 : le formulaire d'ajout de produits est en place dans l'admin
screenshot76.png


15h02 : création dans l'admin d'une deuxième liste qui affiche les produits en fonction du magasin,
mais il existe des conflits entre les variables utilisées par les différentes listes.
screenshot77.png

15h08 : Ah non, en fait c'était juste une erreur d'inattention de ma part...
Par contre il y a des conflits entre les moteurs de recherche : résolu en changeant simplement le nom de la variable.


pause

Création avec des données factice du design de la page taostore
screenshot78.png
sur firefox.
A part ie7, chrome et safari affichent comme firefox.
ie7 : affiche la couleur de fond aléatoirement.
En passant le div en display:inline-block;, le problème disparaît,
par contre, les marges du bas sont doublées.
Peu importe ça passe.


16h51 : ajout de champ date_creation à la table store_produit, le but est que l'utilisateur puisse browser les plugins
par date, afin d'avoir les plus récents en tête.

Je viens de m'apercevoir d'un truc débile :

Voici ma fonction que je viens de coder pour l'affichage d'un tao-item :

function displayTaoItem(
        $id,
        $class,
        $libelle_store,
        $prix,
        $mainphoto,
        $mainphotoAlt,
        $libelle
        )
{
    ?>
< div class="< ?php echo $class; ?>">
    < p class="info">
        Proposé par 

        < ?php echo $libelle_store; ?>

        < span>< ?php echo $prix; ?> TAO
    < /p>

    < img src="< ?php echo $mainphoto; ?>" width="< ?php echo SIZE_PHOTO_STORE_W; ?>" height="< ?php echo SIZE_PHOTO_STORE_H; ?>" alt="< ?php echo $mainphotoAlt; ?>" />
    < p>
        < ?php echo $libelle; ?>
        

        < a href="#< ?php echo $id; ?>">En savoir plus
    < /p>
    < a class="buy" href="#">Je prends
    < hr class="clear">
< /div>
    < ?php
}


On voit bien que je passe tous les paramètres dans l'appel de la fonction;
Je faisais cela parce que cela me semblait plus clair.
Mais qu'arrive-t'il en cas de modification de la structure des données :
je dois me taper les modifs dans chaque script qui fait appel à la fonction.
Vous me direz qu'avec une recherche par netbeans c'est pas la mort, mais bon,

étant donné que mes données viennent de la base de données , je peux remplacer avantageusement ma vielle fonction
par celle là :

function displayTaoItem($row, $class='tao-item')
{

$mainphotoAlt = $row['mainphoto'];

    ?>
< div class="< ?php echo $class; ?>">
    < p class="info">
        Proposé par 

        < ?php echo $row['libelle_store']; ?>

        < span>< ?php echo $row['prix']; ?> TAO< /span>
    < /p>

    < img src="< ?php echo $row['mainphoto']; ?>" width="< ?php echo SIZE_PHOTO_STORE_W; ?>" height="< ?php echo SIZE_PHOTO_STORE_H; ?>" alt="< ?php echo $mainphotoAlt; ?>" />
    < p>
        < ?php echo $row['libelle']; ?>
        

        < a href="#< ?php echo $row['id']; ?>">En savoir plus
    < /p>
    < a class="buy" href="#< ?php echo $row['id']; ?>">Je prends
    < hr class="clear">
< /div>
    < ?php
}



Et là, on voit bien qu'en cas de changement, je n'ai que la fonction à modifier, trop fastoche.
Je me demande pourquoi j'avais pas remarqué cela avant..


Mon idée à la base était de faire autant de requêtes que de catégories,
afin d'avoir un contrôle plus fin sur chaque liste,
mais maintenant la tendance est d'essayer, commer pour la faq, de ne faire qu'une requête.
Ca risque d'être plus délicat au niveau des tris par liste, mais si on peut faire des ORDER BY avec champs multiples
genre ORDER BY r.nom, p.prix, ...
(je sais qu'on peut en faire au moins 2 mais plus pas sûr...)
alors ça devrait le faire.

La suite dira si j'ai été trop gourmand ou pas.


Mise à jour d'un tao item et liste avec données réelles
screenshot79.png

J'ai ajouté le texte série limitée, à mettre seulement pour les produits dont la quantité est un nombre fini.


17h55 : très content d'avoir fait l'organisation en catégories avant que le gong ne sonne,
juste avec un petit bout de code concis très pratique qui tient dans la main :

        $allRows = Ling_Sql_Basic::freeFetchAll($stmt, array());
        //a($allRows);

        $currentCat = '';
        $cpt=0;

        include 'fonction/taostore.php';
        foreach($allRows as $row)
        {
            if($row['nom'] !== $currentCat)
            {
                if($cpt!==0)
                {
                    echo '< /div>< /div>';
                }
                echo '< div class="box bh-jaune">
            < h2>'. $row['nom'] .'
            < div class="tao-list">';
            }
            displayTaoItem($row);
            $cpt++;
            $currentCat = $row['nom'];
        }
        echo '< /div>< /div>';

        ?>

Ce qui donne le résultat visuel suivant :
screenshot80.png

Séparation par catégories


23h43 : ajout des triggers (liens qui permettent d'enclencher un tri) pour
le tri par date, nombre de produits, prix.
Mise en forme du paragraphe d'intro avec ajout de l'icône du caddie.
screenshot81.png


00h19 : Création d'une page à la volée (sans préparation) de détail d'un item,
avec liens vers les items précédents et suivants, si toutefois ils existent.
screenshot82.png

L'image est agrandie bêtement avec les propriétés de l'image par navigateur.
Il faut que je mettes à jour le formulaire pour qu'une image dédiée soit créée;
c'était juste pour tester rapidement...
Je suis satisfait étant donné que je n'avais rien préparé.

00h24 : ajout d'un lien de retour vers la liste depuis le détail de l'item.
00h25 : ajout d'un lien depuis l'image : quand on clique sur l'image, cela revient au même que quand on clique sur en savoir plus.

00h39 : Ajout d'une image lors du formulaire : maintenant, le formulaire d'ajout de produit crée 2 images : une pour l'affichage du détail et une pour l'affichage en liste.
Je suis très content que mon travail sur l'automatic upload m'ait extrêmement simplifié la tâche.
En réalité pour rajouter cette fonctionnalité il ne m'a fallut modifier qu'un seul fichier,
mais après cela impactait les autres fonctions d'affichage du frontoffice.



Demain grosse journée,
je ne sais pas si j'aurais fini, mais voici le programme :
mise en place d'un système qui permet à l'utilisateur d'acheter le produit (page, popup ?, à déterminer)
Création de la preuve d'achat.

Puis dans un deuxième temps, permettre aux commerçants d'ajouter des produits sur le taostore.



                

**** 26-02-2010

08h20 : start
09h46 : le formulaire d'ajout de compte vendeur admin est créé.
Il récupère dynamiquement les infos en bdd pour un admin donné, choisi dans une liste déroulante.

00h19 :
Lorsque l'on créé un framekensteinwork,
il est bon de temps en temps de prendre du temps pour mettre de l'huile, revoir les méthodes qui ont été faites, optimiser
des petites fonctions.

Aujourd'hui, c'est ce que j'ai fait,
malgré les délais relativement torrides, la passion du maître pour sa créature est plus forte.

J'ai amélioré mon script d'automatic upload, bien que je n'ai pas tout à fait fini.
Bon, par contre, je ne peux pas hélas faire cela tous les jours.
Demain, si Dieu le veut, je reprends  le développement du taostore,
enfin, je finis mon fignolage demain matin pendant 1 ou 2 heures et après j'enchaîne sur le système de taostore.




                

**** 25-02-2010

08h27 : start;

Un système de magasin en ligne
La conception :
La réalisation :

Je pense que :

La conception la plus juste sera celle que je devrais trouver.
juste = simple = évolutive
Les performances ne sont pas à prendre en compte dès la conception, mais dans un deuxième temps.

Je ne suis pas du tout littéraire, ou du moins ma pensée n'est pas assez claire pour que je puisse
taper des mots sur le clavier et que cela reflète ma pensée,
je travaille plutôt de manière graphique avec des schémas,
j'abandonne donc l'idée d'expliquer tout ce que je fais et pourquoi je le fais ici, considéré comme une perte de temps;

Je ne fais pas de tutoriel ni quoique ce soit, j'essaie juste de développer mon site....


Le magasin est une chose indépendante.

Le magasin propose des produits.

Un produit a plusieurs propriétés :
libellé, description, photo principale, prix.

La quantité ? le nombre de visites de chaque produit ?
Ce genre de choses il me semble ne sont pas propres au produit et ne doivent pas être inscrit dans la même table que les propriétés.

Mettre les stocks dans une table séparée semble plus logique à première vue,
mais pourtant à froid comme ça je ne trouve aucun bénéfice à avoir une table dédiée pour la gestion des stocks.
Peut être que je manque d'imagination, mais je ne trouve pas.

En fait dans ma table, je n'essaie pas forcément de modéliser un produit de magasin,
mais plutôt l'affichage d'un produit dans le magasin.

C'est pourquoi finalement je vais mettre les stocks.

Minute! Ca y est j'ai trouvé l'intérêt d'avoir les stocks dans une autre table :
imaginons que 2 commerces vendent exactement le même produit.

Si la quantité est stockée directement avec le produit, on est bloqué : impossible de dire le commerce X possède tant de produits et Y possède tant+5 produits.

Ouf, je viens de m'éviter une erreur de conception.
Donc oui, ca sera dans une table séparée, car il pourra il y avoir des cas où le même objet est utilisé plusieurs fois, pas forcément entre commerce mais entre utilisateurs,
un peu tôt pour en parler maintenant;...

Donc les données (propriétés) statiques et les données dynamiques organisées dans des tables différentes.

Un produit appartient forcément à ... un vendeur à qui le bénéfice du produit va revenir lorsque le produit sera acheté.

Mon système de magasin (store) doit être très ouvert à l'évolution ( surtout à ce moment de la conception où je ne sais pas du tout vers quoi cela peut évoluer )
et indépendant d'un autre système.
Je ne vais pas lier directement les commerces de Tours annonces au produits.
La table store_vendeur
est l'interface qu'utilisera mon système de magasin, et tout vendeur devra se plier à renseigner les informations dans CETTE table.

Ceci me permet d'être intègre dans la conception, ceci dit je n'aime pas la duplication de données, ma table vendeur fera donc référence à d' autre(s) table(s)
pour prendre les informations nécessaires à l'affichage.
Si le vendeur est un commerce, ou si c'est un utilisateur, ou si c'est le système Tours annonces, tout cela doit être pris en compte.

C'est pourquoi je mettrai un champ type qui reflètera ceci, et en fonction du type, un traitement adéquat sera appliqué.
Un type et un id de référence, ou du moins un identifiant unique (l'id dans mon cas)


Un produit appartient à une catégorie.
La question est de savoir si il n'appartient qu'à une seule et unique catégorie,
ou bien si il peut posséder plusieurs catégories.

C'est là un avantage du monde virtuel sur le monde réél : dans le monde réél, le produit se trouve a une seule et même place,
soit on l'a dans la main soit pas.
Le monde virtuel offre la possibilité de pouvoir acheter un produit de plusieurs endroits différents : le produit peut se trouver à plusieurs places
simultanément (virtuellement du moins).
Après une petite réflexion, je pense qu'il n'est pas illogique de profiter de ce mécanisme.
Un produit pourra donc théoriquement appartenir à plusieurs catégories, disons groupes.
Ca serait bête de se fermer la porte dès la conception.

Comme je voudrais certainement évoluer vers du commerce plus tard,
et que ceux qui font du commerce aiment bien les factures,
il nous faut une table facture, je préfère l'appeler preuve d'achat, car correspond mieux à ma conception.
Cette table a la particularité de contenir des données pas dynamiques : ben oui c'est la preuve d'un achat on va pas s'amuser à la changer, sinon ça vaut plus rien.

Donc cette table fige les données relatives à une transaction à un instant t.


Cela donnerait ce premier schéma :
schema-store.png

Mais un truc me chagrine au niveau de la table store_vendeur, je ne sais pas encore quoi ...


En fait, c'est le fait que la table est trop dépendante d'une autre table.
Si pour une raison ou une autre l'autre table disparaît, on a plus d'infos sur le store_vendeur!

Ok, rappatrions les données then.

De plus, pour l'instant l'affichage d'un produit sur la boutique est très rudimentaire (binaire) :
soit le poduit s'affiche soit non (j'ai rajouté le statut avec actif ou inactif),
mais que se passe-t'il lorsque le commerçant veut faire une promotion du 12 au 15 février 2010 ?
Evidemment il pourrait venir le 12 et activer son produit et revenir le 15 et le désactiver : lol.

Je ne serais pas webmaster si je laissais cela comme cela.
Notre but est clairement de proposer des services qui facilitent la vie du commerçant, et ici
c'est une opportunité de le faire.
Pour l'instant, restons simple, nous fixerons simplement une date de début et une date de fin.


Cela nous donne le schéma suivant :
schema-store2.png

Je suis convaincu qu'une bonne conception à la base fait gagner au moins 50% du temps (ou du moins évite d'en perdre 50%)
pour le reste du développement, si ce n'est plus.
Espérons simplement que ma conception n'est pas trop pourrave...

Bon, maintenant on a pas mal de boulot sur la planche.
Ma première mission (si je l'accepte), est d'ajouter un produit qui est une fonctionnalité à ajouter sur son compte (par exemple le tri par date sur les listes de commerces de mon compte)
et de la proposer en vente sur le taostore.
Le vendeur est le système tours annonces (sta).

pause

mauvaise nouvelle pour le projet tours annonces, je vais devoir intégrer un autre site qui n'a rien à voir dans à peu près 2heures, ou 1.
L'intégration me prendra à peu près 2 jours.
Gloups!

Mais continuons,...

Quelque chose me gène encore dans mon schéma : les contraintes sur la table store_vendeur ne sont pas assez fortes,
ce qui veut dire qu'en cas de boulette on se retrouve avec des données incohérentes dans les tables, et j'aimerais éviter
cela étant donné mon côté régissque assez développé.

J'avais pensé à une table par type de vendeur : sta, utilisateur, commerce.

Mais si j'arrive à faire une clé primaire sur l'id ET l'id du vendeur ça résoud le problème.
Mes connaissances en sql ne me permettent pas de prédire si cela est possible ou pas avant de le tester.

La doc est formelle : une seule clé primaire par table est autorisée:
http://dev.mysql.com/doc/refman/5.0/fr/create-table.html


Bon, je ne trouve pas de solution rapidement,
je ferais juste gaffe à ce que je fais, hum.

Ajout de libelle_store à la table store_vendeur.
schema-store3.png

Cette table doit contenir TOUTES les informations nécessaires à l'affichage en liste des items proposés.

11h37 : oups, conceptualisons bien : en fait on va commencer par créer des store_vendeur
Il y a 3 types admin (système), commerce ou utilisateur.
Théoriquement, tout admin du site est capable de créer un compte store_vendeur.
Mon compte personnel store_vendeur aura pour libelle_store : Tours annonces System.

// création des références des différents types
// création dans l'admin section taostore d'un formulaire par type.

ajout du statut pour le store_vendeur


12h16 : changement de projet

choses de la vie

02h07 : Ca y est j'ai fini ce que je pouvais faire :
Je ne peux pas en dire plus pour le moment, si ce n'est que l'autre site est en ligne, mais pas encore référencé.
Je tais volontairement son nom pour l'instant parce qu'il n'est pas encore terminé.
Reste le référencement, et j'attends les autres textes du client (j'espère qu'il mettra du temps à les fournir, ou pas, en fait je m'en fiche.)

J'espère par contre avoir du temps demain pour développer Tours annonces.



                

**** 24-02-2010

06h58 : start

08h35 : la liste des items web est disponible dans le compte utilisateur
screenshot73.png

11h21 : pour des raisons de délai et de clarté, simplification du chéma sql, la table web_proposition est supprimée;
l'utilisateur passe par un formulaire de contact pour proposer des nouvelles catégories.

14h33 : ok pour le système de web.

Note : je pense que mon corps est en phase de déprime :
je pense à mon ex, lenteur dans les mouvements, blaseur générale,
manque d'envie face au code, temps morts fréquents.

Heureusement mon mental me tire de cette galère.
Mais je ne suis pas du tout content du code fourni,
peut être n'avais-je pas le choix.
J'ai dupliqué adapter la partie de validation avec modification, plutôt que de centraliser son essence en un point.

Je pense que c'est pour cela que je déprime, c'est la structure du code qui me déprime, moi qui avait fait des efforts pour réduire
l'anarchie, mais elle finit toujours par trouver une faille.
(développeur du dimanche).
Il y aussi des trucs que je voudrais améliorer mais par manque de temps je ne le fais pas;
Cela peut contribuer à ma frustration intérieure.

Bref, la ça va un peu mieux.
il me reste la partie FAQ à finir aujourd'hui et je serais à peu près dans le timing prévu.

Le système de FAQ en soit c'est tout con (j'ai fait exprès de le choisir pour me rattrapper ;)),
c'est des questions et des réponses, chaque question a sa propre réponse.
Le but ici comme on a encore environ 3 heures + 1h30 de boulot,
c'est d'essayer de faire un module.
Cela a certainement été déjà fait :::
si je tape php module faq dans google ça me donne ....
des résultats mais ils ont l'air d'être tous dépendants d'un système, bon j'ai pas creusé...

De toutes façons pas besoin de repiquer ce truc là :
voici comment je vais faire :
une table faq_question
et une table faq_reponse
en gros il faut un champ ordre dans la table faq_question pour pouvoir modifier l'ordre des questions si besoin, et c'est tout.
Une réponse est dépendante (appartient) d'une question.
Je crois qu'on a fait le tour.
Evidemment le plus difficile c'est de trouver les questions.
Commençons par la partie facile, de structuration de la base .
Il est 14h44 à mon signal ::::
top

14h47 : le schéma est construit
schema-faq.png

En fait j'ai rajouté des groupes pour les questions pour les grouper évidemment par catégorie.
Euh sinon je suis pas sûr de la liaison multiple que j'ai faite entre faq_question et faq_groupe,
peut être qu'une simple liaison aurait été la bonne solution, mais je n'ai pas les connaissances techniques nécessaires actuellement pour
savoir ce qui est mieux...
Mouais si ça doit être ça : non-identifying relationship.


Bref, et maintenant création de l'administration;
oups je dois réparer une erreur de régis que j'ai faite avant...
j'ai effacé la table annonce_en_attente de mon schéma du coup toutes les dépendances sont parties avec;;
Ouf, ca y est j'ai récupéré le fichier initial.

Bon alors 15h10 : utilisons notre outil fastadmin pour créer notre admin.
15h12 : Ca y est !!
Ajout des groupes : "général"

15h48 : mise en forme de mon admin renommée pour le coup quickadmin, car légèrement différente de fastadmin.
fastadmin était un peu plus poussé : il me faisait les triggers de tris automatiquement sur chaque champ,
mais bon quickadmin est plus adapté pour l'instant à mes besoins.

A noter que certains formulaires générés sont buggés, à développer...
A faire: les triggers de tri et le moteur de recherche sur l'ensemble des tables.
Sinon, ça fait gagner un temps fou mine de rien.
screenshot74.png

Reste plus qu'à trouver les questions et les réponses...
Puis les mettre en forme après sur le site.

Peut être un peu tôt pour faire des questions réelles, je vais tirer avec des balles à blanc
16h22 Les questions factices sont créées.
Une interrogation est comment faire des liens dynamiques dans une faq dont les q-r sont stockées statiquement dans une bdd ?
Avec str_replace ça le fera : [[12]] est un lien vers 12 : une référence stockée ailleurs.

17h48 : ayé, pour la plus grosse partie.
screenshot75.png

En fait une seule requête sql est suffisante, cette requête est exploitée 2 fois.

$stmt= "SELECT *
            FROM faq_question q
            INNER JOIN faq_groupe g ON g.id=q.id_faq_groupe
            INNER JOIN faq_reponse r ON r.id_faq_question=q.id
            ORDER BY g.id ASC
";

Le système de navigation traditionnel est en place : un clic sur le lien de la question mène directement à la réponse,
et un lien vers le haut de page n'est jamais très loin de la réponse.
Le lien dans l'entête mène le formulaire et autoremplit l'objet du formulaire, il place le focus sur le message.
TODO : si l'utilisateur est connecté, et que son mail est une info publique : autoremplir son mail.

Un système de couleurs par thème est également actif, même si sur le screenshot on se demande ce que j'ai fait,
mais bon c'est actif, et les couleurs sont déterminées dans les constantes de l'init, normal.
Cela permet d'avoir en gros une couleur dominante par thème.

Me reste le remplacement des liens dynamiques, en fait str_replace suffira pas,
preg_replace (ou preg_match) sera nécessaire.


Merde plus le temps, mais en fait j'avais vu quelqu'un une fois , je crois que c'est phpfreaks ou php chaipakoi,
qui faisait appel à une fonction dans son preg_replace ou preg_match, il disait que c'était la clé des gros cms.
Faudra que je retrouve ça sinon je serai bloqué.

choses de la vie.


Voici ce que j'avais vu :


// create a string with some template vars. the string and
// the vars would easily have been called from a template.
$string = 'This is the {_FOO_} bought to you by {_BAR_}';

// create an array of template vars
// of course, each variable could be an array itself
$template_vars=array("FOO" => "The PHP Way", "BAR" => "PHPro.orG");

// preg replace our variables and evaluate them
$string = preg_replace("/{_(.*?)_}/ime", "\$template_vars['$1']",$string);

// echo the new string
echo $string;

ici :http://www.phpro.org/tutorials/Introduction-to-PHP-Regex.html

Incroyable, je viens de tester de mettre une fonction à la place de template_vars dans preg_replace et ça marche.
Vraiment impressionnant, et dire que je ne le savais même pas depuis tout ce temps là.

Pour le coup ça résout direct mon problème.

En fait ça marche grâce au modifier e.

22h55, ayé, ma toutes mes réponses sont parsées et les liens sont évalués, vraiment klass cette petite fonction.

Par contre je viens de m'aperçevoir que je n'ai pas encore fait la partie affichage des listes de webitems pour le front office,
un oubli de ma part.

23h34 : la liste des webitems est en place sur le front office,
elle inclut une recherche par mots qui cherche dans le titre, le mot, la catégorie,
les tris suivant sont disponibles : par nom, par date, par type (blog ou site).

Que vaut l'idée de pouvoir ajouter des commentaires sur les sites et blogs ?
Well, si l'utilisateur ne souhaite pas forcément qu'on commente son site ou son blog, cela peut être gênant pour lui,
si on fait un système de modération cela peut être moins radical, mais plus de développement, pas le temps tout de suite;


Il est 23h37,
je vais faire la partie taostore.
Le but c'est de proposer des produits que les utilisateurs peuvent acheter grâce aux tao qu'ils ont gagnés (ou pourquoi pas achetés).
Disons gagnés.
Malgré toutes les dérives que cela peut avoir,
Mon but en tant que technicien est de proposer un magasin en ligne.
Il y a une donnée que je dois prendre en compte quand même, mais dans un second temps :
les commerçants pourront proposer leurs promotions à des prix réduits sur leurs commerces.
Et ils seront même récompensés pour cela.

Mais dans un premier temps la boutique doit être opérationnelle;


Ok let'(s start the fucking boutik then!!!

C koi une boutique ?

L'utilisateur peut acheter de choses :
donc il y a des choses
une chose a un prix
un titre ? plutôt un libellé. Une description, oui mais facultative (moins relou), ou obligatoire (plus formaté, et plus joli donc pour l'aspect visuel global) ?
Combien de magasins ?quels sont les points de vente ?
Chaque commerce est-il potentiellement un magasin ?
ou bien le système tours annonces est-il le seul point de vente ?

Cela revient à dire qu'une chose est un produit et qu'elle a un propriétaire.
une date de création;


le papier me réussit mieux...
j'essaie de travailler en musique, pas facile...
Non, c'est mort je peux pas.

oula, chui fatigué moi, mon cerveau n'est pas au taquet ça sert à rien de continuer...
Un cerveau reposé en vaut 2.

                

**** 23-02-2010

07h27 : start
07h47 : page d'accueil : la flèche bleue est ajoutée, c'est un lien vers la page toutes les news
screenshot68.png

08h19 : amélioration de la kustomisation de ma liste.
quickTable : ajout du fx BBcode2Html.
La liste est opérationnelle sur le front office.
screenshot69.png

La conversion fut aisée, un simple copier coller adapter.
pause

En fait, je ne vais pas rappatrier les news de la version 4 maintenant,
je le ferais comme prévu initialement dans la phase de rappatriement des données,
en dernier.

Et donc, la partie news étant opérationnelle, je peux tout naturellement passé à la partie web.
Ce qui ne me plaît pas dans la version 4 au niveau de la partie web,
ce sont les catégories.
Elles sont très mal choisies je trouve, je les avais repiquées à l'arrache;
Peut être que c'est difficile de trouver les bonnes catégories,
en tous cas donc, il faut absolument que l'utilisateur puisse proposer ses propres catégories,
c'est ça l'évolutivité.

Aussi, il y a les couleurs, que je n'ai toujours pas mis en place : rouge bleu.
Cela veut dire que je vais prévoir un style de cadre dont la couleur change facilement.

Bon, voici le plan d'attaque :

créer le schéma sql
trouver les catégories
faire le formulaire si besoin d'ajout de catégories
penser et créer le formulaire pour ajouter un item web
faire le fake design facilement kustomizable

//Création du schéma sql
Dans la version 4,  j'avais fait 2 tables différentes : une pour les blogs et une pour les catégories,
ceci était du au fait que j'avais repiqué les catégories sur le web et que les catégories que j'avais trouvées
étaient différentes pour les blogs et pour les sites web.
Aujourd'hui, je pense qu'il est plus simple de ne faire qu'un annuaire de catégories :
non seulement l'utilisateur ne se perd pas, mais aussi c'est plus simple en termes de développement.
Notamment, cela me permet de n'avoir qu'une table avec une distinction par type.

Egalement, ce qui manquait dans la v4, c'était que l'on ne pouvait pas modifier ses infos une fois qu'elles sont en ligne.
Je vais corriger le tir.

09h20 le schéma est créé :
schema-web.png

Le type vaudra s ou b (site ou blog)
Pour les statuts, je n'ai plus en tête le scénario, mais je regarderai plus tard.
En gros ça doit être quelque chose comme :
l'utilisateur poste un item en attente,
le validateur voit la liste des items en attente.
il valide -> validé
ou refuse -> refusé

si validé, l'utilisateur peut editer,
au moment où il le fait, le statut devient en cours de modification
si refusé, l'utilisateur peut (consulter et) supprimer l'item -> refusé et supprimé par utilisateur

Lorsque une modification est validée par l'utilisateur -> modification en attente
le validateur voit également la liste de items en modification en attente.
il valide -> modification acceptée
il refuse -> modification refusée

sur modification acceptée, l'utilisateur peut éditer,
au moment où il le fait, le statut devient en cours de modification
sur modification refusée, l'utilisateur peut réinitialiser ou supprimer l'item.
réinitialiser -> validé, et l'item est copié de la table en ligne vers la table en attente
supprimé -> supprimé par utilisateur.

Bref, on verra ça plus tard.

//trouver les catégories
Essayant de copier sur google pour l'arborescence de l'annuaire, il est intéressant de noter que celle-ci n'est pas mise en avant,
http://blogsearch.google.fr/blogsearch?hl=fr&ie=UTF-8&q=&btnG=Rechercher&lr=
http://blogsearch.google.fr/blogsearch/advanced_blog_search?hl=fr&ie=UTF-8&q=&lr=

En fait je trouve pas du tout,
par contre, j'ai trouvé ces catégories là qui me parlent plus
http://www.annuaire-blogs.net/
c'est assez simple j'aime bien.

Sinon il y a celui de yahoo qui est pas mal
http://fr.local.yahoo.com/France/23424819-idx.html

Mais bon tout de suite on passe au niveau supérieur,
étant le nombre restreint de blogs et sites qu'il y a sur mon site, je pense que le plus sage
est de prendre le premier lien plus simple comme modèle,
et de laisser aux utilisateurs le choix de proposer des spécialités, comme pour les commerces.

Mettons à jour le schéma sql.
09h54 : schema-web2.png

Mouais c'est tout de suite moins simple pour moi, mais ça ne me fait pas peur, il reste du temps...
Donc les catégories sont trouvées :


 actualité
 amour
 animaux & dressage
 art
 autos & motos
 business
 cinéma
 cuisine
 décos pour
 DOM TOM
 pour filles
 humour
 immobilier
 informatique
 internet
 jeux
 littérature
 loisirs
 maisons & jardins
 mer & bateaux
 musique
 nature
 parents & enfants
 persos
 photos
 politique
 radios
 rencontres
 santé & bien-être
 sciences
 skyblog
 spiritualité
 sports
 voyages
 sexe


//faire le formulaire si besoin d'ajout de catégories
Ben oui, bonne idée,...,
Ah ben non chui bête c'est l'arborescence, c'est déjà fait.
En regardant la catégorie décos pour blogs
http://www.annuaire-blogs.net/27-deco-pour-blogs.html
je me demande si ça vaut vraiment le coup de le mettre pour mon annuaire,
par contre l'idée du compteur de visites est une bonne idée je trouve,

je me rends compte que je n'arrive pas à classer tours annonces dans les catégories choisies, nul.
En fait les catégories ne sont pas top :

http://www.yakoila.com/
Très intéressant pour les sites.

Ce qui nous donnerait le fichier suivant
10h19 : web-sites.txt

Je ne sais pas quoi faire, et le temps avance mine de rien;
Ca y est j'ai trouvé : dans mon fichier web-sites, il y a cela :
En fait je vais séparer les 2, comme avant : sites et blogs,
sauf qu'ils sont dans la même arborescence, ça ne change rien pour moi, ou peu.


10h30 : les catégories sont importées, mon fichier est sauvegardé, la table arborescence contient 2732 entrées.

Du coup avec une arborescence comme celle là, plus besoin de spécialités:
cependant l'utilisateur peut quand même proposer de nouvelles catégories.
Le champ indication_categorie sert à donner des indications sur la catégorie parente lorsque l'on propose une nouvelle catégorie,
car le validateur ne peut pas toujours deviner dans quelle catégorie l'utilisateur voulait ajouter sa catégorie.

10h40 : schema-web3.png

Bon je m'en sors bien, pas de spécialités (héhé fainéasse)

pause

//penser et créer le formulaire pour ajouter un item web
Il me faut un environnement : où créer le formulaire : dans le compte utilisateur
11h14 : ajout de la section web dans le compte utilisateur

11h28 : création d'une classe qui centralise les statuts pour un item en attente dans le cadre d'une modération avec validation d'items modifiés.
Modification du schéma : les statuts sont des tinyint

11h47 : Depuis tout à l'heure je me rendais même pas compte que j'avais oublié la photo :
Mise à jour du schéma sql : ajout du champ photo dans les 2 tables en attente et en ligne.

pause

15h59 : le formulaire est en place du côté compte client.
On peut se demander pourquoi j'ai mis tant de temps à le faire,
à vrai dire je n'ai pas de réponse.
C'est que je dois être lent, même si je n'ai pas cette impression, c'est factuel.

A propos de vitesse, j'ai un ami qui utilise les cms joomla et compagnie et il m'a montré des sites qu'il a fait :
c'est franchement bluffant.
L'avenir est réellement du côté des cms je pense : en 25 minutes il est capable de faire un site plus joli esthétiquement
que Tours annonces (pas très très dur mais bon...) et avec plein de petites fonctionnalités dynamiques cachées.
C'est simple, pour faire le site qu'il m'a montré, il me faudrait à peu près un mois (gestion des commentaires, module annonces, module forum, patati patata,
sans compter les plugins flash et jquery intégrés, et l'admin) : c'est tout simplement incroyable, je me demande encore ce que je fous là à coder à la main;
Le pire c'est qu'il ne sait pas vraiment créer un site de toutes pièces (à la main), mais comme il se démerde bien...

Bref, Joomla et Cms pour moi c'est l'avenir du web, donc j'ai hâte de finir Tours annonces pour pouvoir moi aussi vendre à peu près 4-5 site par mois
et ...
et ...
toucher de l'argent .
HAHaHAHAHAHAHOUIHAHAHOUI ENFIN.

Bref, arrêtons ce délire avant que quelqu'un me voie.
Chaque chose en son temps.

Bon sang, aucune interaction de validation n'est en place et il est déjà 16h08, plus que 2 heures,
et moi qui croyait torcher ça, honte sur moi.


17h04 : le fait de pouvoir modifier le formulaire avant la validation est actif

17h55 : mise en forme des listes de web
screenshot70.png

Le design est très minimaliste, je fais ça par rapport au temps que j'ai.
rose pour les filles, gris pour les garçons en gros.
Très facile de changer de couleur.

L'avantage est que c'est très lisible.

choses de la vie

23h40 : confronté au problème suivant : l'utilisateur peut très bien vouloir raconter sa vie dans la description comme il peut ne mettre qu'une phrase,
cela impacte le design.
=> Solution mise en place : un design extensible avec une hauteur minimum.
La description a une hauteur minimum afin que si elle ne contient qu'une phrase, la catégorie et la date s'affichent correctement.
Si la description est très longue, le texte pousse la catégorie et la date tout naturellement.
Heureusement que je n'utilise pas ie6, autrement je n'aurais pas pu faire cela, car j'utilise min-height.

screenshot71.png

Intégration d'une photo de robot webcam en cas de succès d'ajout d'un blog ou site.
screenshot72.png


Clairement je n'ai pas du tout atteint mes objectifs aujourd'hui,
je n'ai même pas fait la moitié.

Pour me rattrapper, il faudra que demain soir j'aie fini cette partie ET la faq.
01h04 : ajout d'une image par défaut pour les webitems.

                

**** 22-02-2010

06h40 : start:
système de news donc.

Je vais en profiter pour voir à quoi ressemble jquery editor.

Principalement, voici les endroits auxquels je pense qui seront liés au système de news

backoffice :
le formulaire d'ajout/modification de news
page de liste des news avec possibilité d'édition des news
detail d'une news

front office
page de liste des news sans possibilité d'édition
detail d'une news

Si je suis malin, ca ne fait que 3 fichiers différents.

Voici mon schéma tout simple pour les news
schema-news.png

15h31 : en fait depuis tout à l'heure je suis en train d'optimiser des anciennes méthodes,
bon bref revenons au système de news...

J'ai trouvé ça ça a l'air génial :
http://markitup.jaysalvat.com/home/


16h04 : première intégration réussie, comme toujours avec les plugins jquery, c'est que du bonheur.
17h26 : j'ai fait le tour des options qui m'intéressaient, vraiment ce mec est génial (jay salvat).

Je vais me créer les émoticones bleues et essayer d'intégrer l'engin à mon générateur de formulaire
que j'ai remis à jour (depuis ce matin).


19h59 : à force de prendre mon temps, je n'ai pas vu l'heure qui tournait,
je n'ai pas encore commencé le système de news, à part le côté graphique du formulaire.

screenshot64.png

Il est temps de s'y mettre.

21h22 : amélioration des méthodes pour les listes.
Mon modèle par défaut propose maintenant un moteur de recherche très basique, mais présent donc kustomizable.
Correction d'un bug d'affichage des smileys dans ie7.
Ajout de l'effet htmlspecialchars sur LingQuickTable
screenshot65.png

21h42 : ajouter l'effet htmlspecialchars était débile, car LingQuickTable le prenait en charge nativement,
j'avais mal lu... (pas lu du tout en fait),
ajout du fx substr afin de n'afficher que les x premiers caractères d'un champ.

La partie admin est finie pour les news : je peux ajouter des catégories via fastadmin (le formulaire est généré automatiquement)
et le formulaire d'ajout de news est opérationnel.
Seul manque, je n'ai pas d'autre visuel que le l'aperçu du valeureux markitup.
Ce n'est pas suffisant, mais je vais justement coder maintenant la partie front office afin d'avoir le script
d'affichage des news, il comprendra la partie traduction du bbcode en vrai html, à moins que cela soit déjà
fait dans le parseur de markitup (j'ai survolé les lignes, j'ai pas bien vu).




21h52 : oups pas possible de chaîner les effets dans LingQuickTable,
faudrait que je corrige à l'occasion.
Retrait de htmlspecialchars par défaut.


22h10 : les effets sont maintenant chaînable;
Cet outil devient pratique pour moi, j'espère seulement que cela ne se ressentira pas trop au niveau des performances.

23h21 : le module de news est pas mal avancé :
liste des X première news sur la page d'accueil, la première est dévoilée avec un lien lire la suite :
screenshot66.png

Et le détail d'une news est affiché, certes rudimentairement,
mais la bonne nouvelle c'est que effectivement c'est bien la fonction du parseur html de markitup
de transformer le bbcode en html.
screenshot67.png

Evidemment les images sans float c'est un peu moche, mais disons que la priorité n'est pas là pour l'instant, enfin je sais pas.
Mais pour une première news c'est pas mal du tout.
Il me reste donc à retirer les caractères bb dans l'affichage en liste des news,
mettre en forme un minimum le détail d'une news, je pense aux blockquotes;
Faire une page sur laquelle l'utilisateur browse toute les news, comme dans mon admin en fait.
Pourquoi pas faire un lien vers le détail de la news suivante et précédente dans le détail d'une news ?
Rappatrier les news de Tours annonces actuel.

Hélas mon énergie ne me permettra pas de tout faire ce soir,
je ferais ce aue je pourrais.

Autant faire le résumé tout de suite comme ça j'aurais l'esprit libre pour la suite :
Bon ben encore une fois et spécialement aujourd'hui je me tire pas le chapeau.
J'ai beaucoup flâné sur des détails mais bon :
grosse découverte : markitup gain de temps énorme, j'ai tout rattrappé ;)

J'ai mis à jour mon fastadmin et retravailler sur les listes.

En fait progressivement je reviens à un codage intuitif manuel.
Je fais maintenant mes requêtes sql direct à la main dans le code;
Elles passent juste par un objet et non pas deux : Ling_Sql_Basic.

Je crois que c'est le bon équilibre.

Je pense que demain armé avec ces vieux outils mis à jour et ce mode de fonctionnement,
je n'aurais aucun problème à torcher le système web.
héhé, on verra bien.

Bon, me reste plus qu'à errer tel un zombie devant mon ordi jusqu'à ce que mes neurones ressemblent à un champ de navets.
Mais petite pause avant;...
http://www.youtube.com/watch?v=8GaNnVBWafE&NR=1

00h30 : reprise :euh ouai un peu tard.
00h32 : les bbcodes sont filtrés sur la page d'accueil.
00h48 : le style des quotes est fait. il ne marche comme prévu que pour firefox. Les autres navigateurs n'affichent pas les quotes.
On s'en fout c'est que des quotes...

01h13 : le système de news suivante /précédente est en place.
A noter que je suis content que tout ce que je fais dans cette version est réellement mieux fait que dans la version précédente.
C'est un plaisir de coder;

Bon j'arrête là, je préfère avoir la forme pour demain : finir les news + faire la partie web.
                

**** 21-02-2010

06h53 : start
Je vais insérer des commerces...
Mon idée de base était de créer un générateur mais le temps de le faire j'aurais déjà inséré 10 commerces, ce qui est suffisant pour mes tests.

07h26 : insertion de plusieurs commerces (x9)

pause

10h00 : le moteur de recherche est en place pour les commerces, il cherche par catégorie, commune, et mot.
Les mots sont cherchés dans les noms de commerce et les adresses.
Mon design hélas ne me permet pas de faire facilement une recherche sur les spécialités du commerce, ce qui est assez embêtant,
d'autres solutions viennent, mais elles appartiennent au domaine du rafistolage que je n'aime pas trop
(ajouter un champ recherche à la table commerce qui contient tous les mots sur lesquels on peut effectuer la recherche,
dont les spécialités).

10h04 : ajout de la recherche dans les noms de catégorie.

Ceci dit, la solution d'ajouter un champ recherche à la table commerce ouvre vers
une kustomisation plus poussée : possibilité pour l'utilisateur d'ajouter ses propres mots clés,
possibilité d'ajout de synonymes ou mots voisins,
mais non, on en est pas encore là et pour l'instant c'est pas mortel.

screenshot58.png

Il y a des tas de choses plus importantes :
par exemple : faire apparaître le nom de la catégorie dans les listes, ben oui j'ai oublié (enfin disons mal conçu).

Mal foutu mon affaire, le fait de vouloir ajouter le nom de la catégorie m'oblige à parcourir tous mes fichiers qui font appel
à la fonction d'affichage, car j'ai changé la définition de la fonction.
Bon mais c'est un choix de conception que j'ai fait pour des raisons de performance
function vs objet
et que je dois assumer maintenant, heureusement c'est frais dans ma mémoire.

Et en plus chui bête : netbeans ctrl+f displayCommerceItem
fait tout le travail à ma place ;)
10h16 : les noms de catégories sont ajoutés, c'est tout de même plus classe.

screenshot59.png

J'avoue que j'ai mis longtemps à recapter mon système de liste, mais en fait il est super car hyper kustomisable.
En fait aucune encapsulation, juste de la séparation de code par des include et basta.
A moi de savoir ce que je fais et comment modifier les données.
Plus tard, on verra si on peut gagner du temps dans l'écriture de ce code,
mais revenons à nos moutons;

Voici ma phrase qui indique à l'utilisateur ce qu'il cherche, c'est en même temps mon algorythme
Liste des commerces [0=d'Indre et Loire|tours|bléré...] [0=""|"dans la catégorie XXXX"] [dont le nom et/ou l'adresse contient la chaîne "XXXX"]

Très scolaire, mais cela à l'avantage d'être très clair, j'aime bien.

10h42, ma phrase repère est ajoutée.
screenshot60.png

En réfléchissant 2 secondes, la carte par cantons ou commune est plus un gadget qu'autre chose, puisque le moteur de recherche permet une recherche par communes.
Cependant la carte apporte 2 avantages :
- elle permet de sélectionner des zones regroupant plusieurs communes en même temps (la liste déroulante pourrait le faire aussi mais c'est moins beau)
- Elle permet d'être plus zen; quand on clique sur l'onglet commerces de Tours annonces, on tombe sur une carte, ce qui nous met en altitude, on a le choix, c'est kool.
Et non pas:
on est direct plongé dans la liste des commerces, perdu dans les informations.

Enfin bon ca se discute, bref je fais cette carte.

http://images.google.fr/imgres?imgurl=http://www.atlaspol.com/CEVALR/37cantons.bmp&imgrefurl=http://www.atlaspol.com/CEVALR/indre-et-loire.htm&usg=__BSm0NelbAnM_6f5CHfcLMJh9TFY=&h=515&w=484&sz=731&hl=fr&start=116&itbs=1&tbnid=3LzauHlCKOpWrM:&tbnh=131&tbnw=123&prev=/images%3Fq%3Dliste%2Bdes%2Bcantons%2Bindre%2Bet%2Bloire%26start%3D105%26hl%3Dfr%26sa%3DN%26ndsp%3D21%26tbs%3Disch:1
La date de la dernière mise à jour est un peu prétentieuse mais la carte est pas mal.

11h22
Bon finalement j'ai repris la carte que j'avais dans mes maquettes car le style des traits me plaisait (traits droits),
et surtout il y avait la petite zone à droite qui est un zoom des cantons du centres de la ville.
Sans cette carte annexe, difficile de choisir son canton au centre de la grande carte car ils sont trop petits.
L'inconvénient est qu'il a fallu se taper du nettoyage photoshop.
Voici la carte fraîchement nettoyée
carte-cantons.png

12h35 : Je n'aime pas le rendu de la carte,
et clairment je n'ai pas la bonne méthodolagie, en fait je n'ai aucune méthodologie pour créer les cartes,
donc j'ai recommencé en me servant du fond de carte comme canevas et j'ai placé mes points sur un autre calque afin
d'avoir un rendu des countours au moins homogène.

Voici la méthodologie qui marche dans mon cas :
ou plutôt comment faire des sprites propres avec photoshop:
baguette magique tolérance 100%, antialias
Sélectionner la région que l'on veut en cliquant sur le calque qui contient l'apercu de tout le fichier.
Le but est d'essayer de prendre limite un peu le contour noir (sinon après c'est pas propre), très légèrement.
Sauver pour le web en gif avec une couleur autour : matte = noir, cela mélange le bout de contour qu'on a avec du noir,
et comme le contour des zones de l'image est noir, l'illusion passe sans problèmes.

Mettre chaque calque sur un gif
Zipper tous les gifs
Créer le sprite
http://spritegen.website-performance.org/

15h39 : la carte est intégrée, mais je voudrais que lorsque l'on passe la souris sur
la zone de tours, toute la zone se highlight...


16h06 : la carte est intégrée comme je voulais.
Le screenshot suivant ne montre pas mon curseur de souris, mais la zone violette, c'est là où j'ai mis le curseur.
Si je survole le lien tous les cantons, toute la carte est en violet,
si je survole la petite zone verte au centre de la carte principale, toute la petite carte annexe passe en violet.
screenshot61.png


PAr rapport à Google Map ca fait très vieillot, je me demande si ca vaut vraiment le coup de la mettre...
C'est plus sexy qu'une liste déroulante, mais bon, pas top...
Je vais essayer de travailler la mise en page pour voir.

17h50 : toujours dans ma recherche, j'ai trouvé qu'il manque une page : une page qui invite les commerçants à s'inscrire.
La carte toute seule ne vaut rien..

Bref, j'ai pensé à un faq pour les commerces, et dans cette faq il y aurait une page dédiée à la question :
"qu'est ce que c'est l'annuaire des commerces Tours annonces ?".

screenshot62.png

En général je ne prends jamais beaucoup de temps sur la création graphique, mais bon là ca me faisait plaisir,
j'ai pensé qu'il était important que les gens voient que le site ait du caractère,
et puis j'avais besoin de me lâcher aussi.

Bref, le temps s'écoule, je n'ai bientôt plus de crédit.
Finalement je n'aurais encore pas tenu mes délais pour le commerce,
mais peu importe, je me laisse demain pour finir les pages d'accès aux listes des commerces,
et mardi je change de section. De toutes façons je referais une grosse passe générale à la fin.

choses de la vie.

23h19 : la page est intégrée pour ainsi dire telle quelle dans mes navigateurs.
Faudrait que je me fasse une réflexion marketing pour savoir comment, dans quel ordre intégrer les pages et quel contenu ?
Mon but est que les commerçants s'inscrivent ou du moins qu'ils aient envie de le faire.

Mais ma conscience de programmeur me dit de passer à la suite, c'est à dire tout ce qui est programmable :
le plus difficile techniquement quoi ...

Et bien entendu, je donne raison à cette voix, ca sera l'occasion de reposer mon esprit marketing qui trouvera
une solution en temps voulu (j'en suis sûr).

Bref,
avant que mes batteries soient épuisés, je parie que je peux rajouter un formulaire de contact (ah oui tiens j'ai oublié cette page)
sur le front office du site.

23h42 : la page est visuellement intégrée, on y accède lorsque l'on clique sur contact (en bas du site).
screenshot63.png
Trop fastoche, dans tous les navigateurs.
un p avec une image de fond et un padding pour l'image du mail.

Reste plus qu'à savoir où placer les données du formulaire, c'est ça le plus dur.

Cette fois, je vais penser un peu plus large, j'imagine que nous sommes une équipe et que d'autres admins sont avec moi.
L'utilisateur remplit le formulaire et choisit à quel admin il veut l'envoyer.

00h01 : mise à jour du schéma admin avec la table admin_message_externe_anonyme (c'est la même que pour commerce en fait)
schema-admin.png



00h17 : ouf, j'ai cru que j'allais jamais y arriver.
En fait j'ai repris le formulaire du commerce tel quel,
j'ai juste corrigé un petit bug:
en fait lorsque le formulaire est complété, j'affiche un message de succès à la fin pour indiquer à l'utilisateur que le formulaire a bien été envoyé mais surtout
pour éviter qu'un chieur recharge 36000 fois la page et le formulaire avec, hors malgré le message de succès, f5 repostait le formulaire;
J'ai corrigé cela en faisant une redirection au bout de 2 secondes.





Résumé :
Donc non, je n'ai pas fini la partie commerce ce soir,
mais demain en fait je vais passer à autre chose, dégrossir ce qui est gros.
Actuellement, la partie technique qui reste à faire pour finir la partie commerce est minime,
ou du moins considérablement réduite.
Ce que techniquement je n'ai pas fait (mise à part la partie plan google map, et c'est un gros morceau, mais j'attends d'être en ligne pour faire cela, donc ça ne compte pas vraiment) :
L'utilisateur n'a pas encore la possibilité d'ajouter dynamiquement des blocinfo comme prévu à la base (à part celui de présentation).
Mais avant de développer quoique ce soit il faut que je sois certain qu'il pourra le faire et QUI pourra le faire (Mr tout le monde, ou utilisateur privilégié).
Pour l'instant, la description que l'utilisateur entre dans le formulaire n'est pas contrôlée;
elle accepte le html et donc le javascript, et donc à sécuriser. J'ai pensé au bbcode, mais je ne connais pas encore très bien.
strip_tag si je ne trouve pas.
Lorsque l'utilisateur cliquera sur la carte des cantons, il faudra mettre à jour les requêtes de liste.
Qui a le droit de voir quoi ? les stats : qui a le droit de les voir ?

En gros voilà, et aussi je voulais ajouter la carte par arrondissement, mais il faudrait déjà que je saches où placer la carte des communes.

Beaucoup d'interrogations qui prennent beaucoup de temps en fait,
et là pas le temps, donc je considère que c'est fini, je repasserais une couche mais faut que j'avance.

Ca s'annonce pas top : j'aimerais avoir 10 jours pour faire le transfert des données de la version actuelle vers la nouvelle version.
La sortie devrait être le 27 mars 2010, donc faudrait que j'aie fini le 17 mars 2010, vraiment fini et débuggé.

Le but premier est de remettre en ligne la version avec au moins les fonctionalités qu'elle a aujourd'hui, donc il
me reste la partie web, les news, et la faq.
Pour le forum et le taostore, si j'ai le temps.

La partie pub, je la saute, tout le monde s'en fout.

Sachant que je vais devoir intégrer d'autres sites dans le courant des semaines à venir, c'est relativement très tendu.
Demain, le système de news et si possible rappatriement des anciennes news.

Comme on est le 21, faudrait que le 31 j'ai fini les news, le web et la faq.
Et que ça soit plus clair dans ma tête au niveau des commerces.


                

**** 20-02-2010

08h01 : start

Pour commencer, une table message_systeme,
qui contient tous les messages envoyes pas le système Tours annonces à des utilisateurs.
Ces messages apparaissent dans la messagerie d'un utilisateur Tours annonces.
Dans la version précédente, les messages système et les messages utilisateurs n'étaient pas différenciés.
Je pense que c'est une bonne chose de le faire pour un code et une conception plus propre,
de plus, on ne peut pas répondre à  un message système mais on peut répondre et créer une discussion avec un
autre utilisateur, ce ne sont donc pas le même type de message.

08h15 : le modèle est mis à jour. Je n'ai volontairement pas fait de liaison entre les tables utilisateurs
et message_système car je veux utiliser utilisateur_id=0 pour envoyer un message à tous les utilisateurs
simultanément.
Pratique pour envoyer des messages informatifs ou publicitaires en masse.

J'ai ajouté un champ destination, c'est l'endroit dans "mon compte" où apparaît le message :
 par exemple la page d'accueil de mon compte ou la page messagerie

08h58 : ajout du champ pseudo_public à la table adminuser, afin de pouvoir donner le nom de l'admin dans le
message envoyé à l'utilisateur qui a posté le commerce.

09h22 : le message est bien envoyé par le système.

09h44 : en fait ma conception n'est pas bonne, du moins elle est dangereuse :
Je vais faire une table qui ne gère QUE les messages personnels (pas d'histoire de 0=tout le monde).
La nouvelle conception  : un message_systeme est un message personnel qui arrive dans la messagerie de l'utilisateur.
screenshot52.png

10h00 : Mise à jour des méthodes liées.

10h10 : apparition de manière brutale du message dans la messagerie
screenshot53.png

10h27 : l'action d'effacer un commerce est en place.
Elle change simplement le statut du commerce en "effacé par l'utilisateur"

Oups j'ai oublié de valider les propositions de spécialités

pause

12h30 :
0. ajout du comportement qui fait que si j'essaie de valider un commerce qui "possède" des spécialités en attente de validation,
un popup s'affiche et me dit de valider les spécialités d'abord
screenshot54.png

1. ajout d'un script webservice pour accepter-refuser une spécialité proposée.
L'entête de mon script le décrit plus rapidement que si je tapais à la main l'explication
/*******************************************************************************/
// PRINCIPE
/*******************************************************************************/
/*
 * Lorsque une spécialité est validée,
 * elle est insérée dans commerce_spécialité,
 * puis une entrée est également insérée dans la table commerce_has_specialite
 * Le statut de commerce_specialite_proposition est mis a accepté
 *
 * Lors du refus,
 * Le statut de commerce_specialite_proposition est mis a refusé
 */

2. Codage en jquery des fonctions qui appellent ce script lors d'un click sur valider ou refuser
screenshot55.png

Je suis assez satisfait car j'ai codé tout cela sans faire de fautes.
Mais on s'en fout.

15h02 : correction de bugs trouvés + amélioration de certaines parties.
Je viens de résoudre le problème délicat des conflits de session entre les différents commerces d'un même utilisateur.

16h27 : correction de bugs : suite et fin?

16h42 : la liste et l'aperçu des commerces sont disponibles sur le front office.

17h00 : Mise en place du formulaire (pas de comportement de validation) pour envoyer un message.
screenshot56.png

17h05 : mise à jour du schéma sql commerce (ajout de commerce_message_externe_anonyme)
schema-commerce4.png


17h14 : création d'une classe spéciale qui contient tous les états de message :
    const STATUT_ENVOYE             = '1';
    const STATUT_LU                 = '2';
    const STATUT_ARCHIVE            = '3';
    const STATUT_EFFACE             = '4';

Cette classe sert de référence, car je sens qu'on va avoir plusieurs types de messages différents,
et si on veut les gérer simplement dans UNE interface (mon compte), vaut mieux avoir quelques conventions...


17h31 : le comportement d'envoi de message est actif.

17h46 : correction d'une erreur de conception sur mon schéma sql : le message n'appartient pas à un commerce mais à son propriétaire.
schema-commerce5.png

17h57 : affichage des messages, toujours de manière brute dans le compte de l'utilisateur : le propriétaire du commerce.

choses de la vie :

23h32 : mise à jour du schéma sql pour prendre en compte les stats : la table commerce_stat est ajoutée
schema-commerce6.png


23h47 : le système de stat ajoute les entrées dans la bdd.
Qui peut le plus peut le moins : pour l'instant mon système prend tous les hits en compte,
avec distinction de l'onglet (accueil, horaire, plan, ...)
A mon avis tant que le site n'est pas surchargé, ça tiendra le coup.

00h41, j'ai fini quasiment le système de stats, sauf que petit détail, je viens de m'apercevoir que timestamp
est pas du tout pratique (je le savais mais je voulais économiser des performances),
bref, je recommence avec datetime.

01h04 : le système d'affichage est en place : je ne connaissais pas les fonctions de date mysql mais elles sont très pratique :
SELECT ...
WHERE ...
AND DATE(date)=CURDATE()

La dernière ligne filtre simplement les entrées d'aujourd'hui, super pratique.
screenshot57.png


Bon voilà, je voulais au moins finir les stats aujourd'hui, c'était tout juste.
Je ne sais pas qui a inventé les journées de 24 heures, mais si j'étais là à la conception je pense que j'aurais négocié pour 30 heures.

Bref, reste à tester avec une base de données plus fournie et surtout faire les tris, les catégories, le plan.
Disons que pour le plan du commerce, j'utilise mon joker (tout le monde a droit à un joker),
et que j'essaie de tenir mon planing fictif et impromptu pour demain.

Pas facile les délais d'un webmaster, pas facile...
Même pas le temps de changer d'imprimante..

                

**** 19-02-2010

07h48 : start
En réfléchissant sur l'utilisté d'une boîte de messages pour le commercant :
mon idée première était d'envoyer un message au commercant via un formulaire.
Mais l'utilisateur qui a inscrit le commerce n'est pas forcément le propriétaire de celui-ci;

Au final, il semble plus logique que l'utilisateur soit le propriétaire du commerce.

J'ai pensé au système suivant :
Le formulaire d'ajout de commerce :

Sur Tours annonces, un utilisateur peut proposer un commerce.
Lorsque un commerce est proposé, pour des raisons de qualité de l'annuaire,
un contrôleur de l'équipe de Tours annonces
SE REND SUR PLACE pour vérifer les informations soumises :

3 cas se présentent alors :
1. L'utilisateur est le propriétaire du commerce et c'est lui qui est à l'origine de la demande.
C'est un commerçant qui souhaite que son commerce apparaisse sur l'annuaire de Tours annonces.
Dans ce cas, le contrôleur indique au système informatique de Tours annonces que l'utilisateur est
bien authentifié comme étant le propriétaire du commerce.
Le compte de l'utilisateur est alors scellé à ce commerce et les autres utilisateurs peuvent
lui envoyer des messages directement par le site.


2. L'utilisateur n'est pas le propriétaire du commerce (il a inscrit un commerce qui ne lui appartient pas).
Le contrôleur de Tours annonces explique au commerçant qu'un utilisateur a inscrit son commerce,
il lui montre l'aperçu et lui demande de faire un choix :
	a. accepter la proposition de l'utilisateur
	b. refuser la proposition de l'utilisateur

Dans la cas "a", le commerçant accepte d'apparaître sur l'annuaire de Tours annonces.
Un compte est créé (ou bien si le commerçant avait déjà un compte Tours annonces, ce dernier peut être utilisé)
et le commerce est rappatrié sur ce compte.
L'utilisateur qui a fait la proposition du commerce "perd" le commerce (le commerce n'est plus visible sur son compte)
et son compte est crédité de 100 TAO (nombre variable).
Le compte du commerçant contient maintenant son commerce et les autres utilisateurs peuvent
lui envoyer des messages directement par le site.

Dans le cas "b", voir le cas 3.

3. Le commerce n'existe pas, (ou le commerçant refuse d'apparaitre sur l'annuaire de Tours annonces),
la proposition de l'utilisateur est alors rejetée. Le commerce ne figure pas dans l'annuaire de Tours annonces.


Voilà, peut être un peu tiré par le cheveux comme système mais pour l'instant j'ai pas mieux.
Il me faut donc le pouvoir d'octroyer des droits de controleur à un super utilisateur (admin)
Une table droits contiendra les différents droits,
pour l'instant
administrator : administrer le site(peut tout faire),
moderator : modérer une annonce(peut valider ou refuser des annonces)
controler : controler un commerce, accepter une proposition de commerce ou la refuser, transférer un commerce d'un compte à un autre.

Chaque super utilisateur (dans la table adminuser) sera lié à ces droits par une autre table
Et à chaque fois qu'une action nécessitant des droits sera demandée,
on vérifiera tout simplement si cette personne possède les droits nécessaires.

L'interface du contrôleur permettra d'accepter ou refuser une proposition de commerce.
Dans le cas de l'acceptation, une question est posée : est-ce que l'utilisateur est bien le propriétaire du commerce.
Si il répond oui, le commerce est directement validé.
Si il répond non, la liste des autres utilisateurs apparaît et il doit choisir l'utilisateur qui correspond au commerçant.
En validant, le système s'occupper de transférer le commerce au bon utilisateur et de créditer le compte de l'utilisateur
qui a proposé le commerce de X TAO.

allez go...


08h54 : mise à jour du schéma sql
schema-droits.png

09h23 : Système de gestion des droits en place.

09h57 : Intégration de la page de validation sur les 4 navigateurs
screenshot48.png


10h02 : comportement de validation actif.

10h07 : erreur de conception à réparer : les photos pour les commerces étaient posées en fonction de l'id de l'utilisateur au lieu de l'id du commerce.
10h34 : réparé, + ajout de la fonctionalité qui affiche tous les bloc infos en liste sur la section infos du commerce.

pause

13h33 la liste des commerces dans mon compte est prête, avec moteur de recherche sur le nom du commerce et adresse,
tri par nom, date ou statut.
screenshot49.png

14h16 : la liste des commerces à valider est disponible dans mon admin, sans actions.
14h30 : admin : l'action refuser est ajoutée : elle passe le commerce en attente de validation à l'état refusé.
14h33 : admin : l'action valider est ajoutée : elle passe le commerce en attente de validation à l'état validé.

En fait l'action validée n'est pas celle attendue.
L'action validée doit :
->demander le nom ou l'id du propriétaire réel du commerce.
->attribuer les points à l'utilisateur qui a posté le formulaire ssi cet utilisateur n'est pas le propriétaire.
Etant donné que le nombre d'utilisateurs peut être très élevé, les afficher dans une simple liste déroulante peut être hélas inapproprié.
Je propose un ajax autocomplete sur le pseudo, bien que je sois très tenté pour des raisons de délai de ne faire qu'une liste déroulante either.
Heureusement une simple recherche sur google m'amène ici:
http://jquery.bassistance.de/autocomplete/demo/

C'est ce que je vais essayer d'intégrer...


Oups ca va barder, je vais bientôt me taper l'intégration d'autres sites, pas bon pour mon planning...

choses de la vie


23h00 : le plugin autocomplete est enfin intégré à ma validation dans l'admin.
Lorsque je clique sur un lien valider, un popup s'ouvre et m'affiche un champ dans lequel on me demande le pseudo
du propriétaire du commerce.
Ce champ est soumis à l'autocomplétion.
Il me reste à effectuer la validation.

screenshot50.png


23h29 : Le comportement de validation est opérationnel :
le compte de l'utilisateur qui a posté le formulaire est crédité de X Tao,
le commerce est attribué au compte de la personne physique qui est le propriétaire du commerce,
le statut du commerce passe à validé.
Seul petit hic,
puisque le commerce n'appartient plus à l'utilisateur qui l'a posté (à moins que ce soit le commerçant qui ait posté son commerce),
comment avertir cet utilisateur que le formulaire a bien été validé et son compte crédité ?
Mon idée première était d'utiliser le même système que pour les annonces,
ce qui aurait voulu dire que le commerce apparaissait avec une couleur différente dans son compte,
indiquant que le commerce est validé, et il n'aurait que l'option de l'effacer.

En réfléchissant 2 secondes, peut être que la solution la plus logique est d'ajouter un champ id_propriétaire à la table commerce.
Mais cela veut dire un peu de développement, je commence à petre fatigué, mais je sais que c'est la meilleure solution.
Cherchons quand même une solution de fortune relativement propre qui évite du développement...

Il y a évidemment l'envoi de message par la messagerie, mais ça n'a rien à voir : c'est beaucoup moins agréable pour l'utilisateur.

Je ne trouve pas d'autres solutions, mais en fait je suis un peu réticent pour ajouter un champ propriétaire,
car il fait également référence à la table utilisateur et s'il est en primary key ou même foreign key,
ca va ajouter des problèmes de dépendance.
En fait c'est plutôt un champ id_posteur qu'il faudrait ajouter, et qui n'est lié à aucune table,
à la limite ca pourrait être un string.

Bon en fait non, en réfléchissant un peu plus la solution n'est pas si bonne que ca,
car elle m'oblige à modifier mes requêtes de listage d'une manière cochonne.
Bref, un message sera la solution adoptée.


Bon au dodo

                

**** 18-02-2010

07h44 : start

08h01 :
Mon schéma sql actuel a 2 inconvénients : il permet aux utilisateurs d'ajouter leurs propositions sur une table en production,
mais surout il ne me permet pas de réafficher le formulaire avec les propositions de spécialités.
Mise à jour du schéma
schema-commerce3.png


09h17 : le réaffichage des propositions de spécialités fonctionne.
09h25 : Le réaffichage du bloc présentation est ok.

09h59 : rotation et réaffichage des photos pour la galerie en place.
pause

10h44 : Mise en forme de la page étape finale
screenshot43.png

11h01 : 1er jet pour possibilité de modifier son commerce :
2 problèmes :
le réaffichage du switch des horaires.
le réaffichage de toutes les spécialités proposées au lieu de juste celles insérées en dernier.

11h31 : corrections effectuées.

pause

15h24 : Intégration avec des données factices de la page accueil partie Espace Perso dans mon set de navigateurs.
screenshot44.png

La navigation est également en place,
mise à jour de mon routeur pour qu'il comprenne le ? comme séparateur entre un bloc IdentifiantDePage et un bloc Paramètre
(ce n'était pas le cas avant j'utilisais une autre technique)

Note:
Comme je ne peux pas obliger les utilisateurs  à faire un texte de présentation, je pense que la page par défaut
sera "les horaires" (que j'avais oublié d'ailleurs sur mon esquisse) qui présenteront le détail des horaires du commerce.


J'aimerais bien avoir fini tout ce qui concerne les commerces Dimanche;
Reste l'intégration des pages, la validation, le plan, l'affichage et le tri des listes, et moteur de recherche sur le front office...


Je viens de m'apercevoir que mon module horaire ne colle pas quand on veut entrer des horaires nocturnes :
par exemple si je travaille de 18h à 00h30,
actuellement je ne peux pas le dire à mon module car il me renverra une erreur d'incohérence de date (mais qu'il est bête) : à corriger plus tard...

16h20 : le bug de merde :
J'ai pourtant
 dans mon html
header('Content-type: text/html; charset=UTF-8'); dans mon controleur php

                self::$_instance = new PDO($sqlDsn, MOD_DATABASEACCESS_SQL_USERNAME, MOD_DATABASEACCESS_SQL_PASSWORD,
                        array(PDO::ATTR_PERSISTENT => true));
                self::$_instance->query('SET NAMES utf8');

				pour ma database

Là chui dans la merde pour être à l'heure.

Je m'en sors par une pirouette de fortune qui marche dans mon cas

function urlencodeToUtf8($urlencodedString)
{
    //&-â-ê-û-î-ô-ä-ë-ü-ï-ö-é-è-à-ù
    //%26-%E3%A2-%E3%AA-%E3%BB-%E3%AE-%E3%B4-%E3%A4-%E3%AB-%E3%BC-%E3%AF-%E3%B6-%E3%A9-%E3%A8-%E3%A0-%E3%B9
    $ar1 = array(
        "&","â","ê","û","î","ô","ä","ë","ü","ï","ö","é","è","à","ù"
    );
    $ar2 = array(
        "%26","%E3%A2","%E3%AA","%E3%BB","%E3%AE","%E3%B4","%E3%A4","%E3%AB","%E3%BC","%E3%AF","%E3%B6","%E3%A9","%E3%A8","%E3%A0","%E3%B9"
    );

    return str_replace($ar2,$ar1,$urlencodedString);
}


function convertStrangeStringToUtf8($strangeString)
{
    return urldecode(urlencodeToUtf8(urlencode($strangeString)));
}

Même si c'est totalement nul,
mais bon, dans l'urgence je m'accorde le droit de faire des ptites craderies.
Maintenant y a un autre problème, plus à ma portée :
la première spécialité ajoutée s'affiche en double, aaaargh..
16h59 : Bugs corrigés.
Avec ajout d'une exception qui détecte le bug :HY000
et qui renvoie simplement une erreur de formulaire classique.
C'est donc un dérapage contrôlé,
Merci les exceptions.

Choses de la vie

Bon retour au code...
23h42 : la page d'accueil est intégrée avec des données réelles.
Voici à quoi elle ressemble si l'utilisateur qui a rempli le formulaire a laissé vide le champ "présentation" :

screenshot45.png

J'ai également intégré la page horaires :
screenshot46.png

Je suis particulièrement satisfait de mon utilisation de la propriété inline-block,
que j'ai appliquée sur les jours de la semaine sur le screenshot46 :
lundi : de 9H30 à 12H
mardi : de 9H30 à 12H et de 15H à 18H30

On voit que lundi et mardi sont en gras et que l'espace entre le nom du jour et les deux points ":"
est identique quelque soit la taille du nom du jour.
C'est comme si on avait un tableau, sauf qu'il n'y a pas de tableau :
Chaque jour est encadré par la balise gras et un inline-block avec une largeur fixe permet
d'obtenir ce résultat sur les navigateurs que je teste.
Avant je n'utilisais jamais cette propriété, c'est pour cela que je suis content,
car cela me fait une arme en plus.

00h34 : La galerie photos est intégrée.
screenshot47.png

J'ai retiré l'effet de fadeIn() de Jquery, car pour donner une impression de fadeIn, j'utilisais un display none juste avant,
ce qui provoquait un petit clipping de scroll désagréable.
Maintenant la transition est directe et propre.

Pour le plan, il vaut mieux tester en production, je ferais cela plus tard.
Pour les stats, il serait plus intéressant d'avoir d'abord quelques éléments sur le front office afin de pouvoir tester
correctement, et en plus je n'ai pas encore fait les tables.
Bref, occupons-nous de la partie messages.

En fait, j'aime bien avoir l'esprit clair pour conceptualiser des choses, l'esprit énergique du matin,
mais pas l'esprit "je lutte pour ouvrir les yeux" du soir,
donc je me mets en statut désactivé jusqu'à demain,
et je suis déjà en retard, carà mon avis pour finir dimanche la partie commerces, il faut faire vite et bien sans se planter.
Kool, j'adore les challenges...

Résumé :
euh,
donc aujourd'hui j'ai fini le gros formulaire d'ajout de commerces,
c'est une bonne chose, mais la partie commerces est bien plus vaste que simplement la zone couverte par le formulaire.
Beaucoup de travail en perspective.
Le but serait de mettre en ligne le 27 mars 2010, comme ça cela fera pilpoil 3 ans que Tours annonces sera sorti.
Oh kil est mignon le ptit bébé...

                

**** 17-02-2010

08h04 : start
08h34 : le choix des spécialités en fonction de la marque dynamiquement est opérationnel sur ffox au niveau de l'affichage du formulaire:
l'utilisateur choisit une cagégorie, et les spécialités liées apparaissent sous forme de cases à cocher.
ie7, safari, et chrome : cela fonctionne également, mis à part que sous ie7, les checkbox sont décalées verticalement par rapport au texte.
Mettre un line-height:20px; semble résoudre le problème.

09h48 : L'aspect visuel et interactif de l'ajout de spécialités est en place sur ffox.
L'utilisateur a 2 options : ajouter une autre spécialité ou retirer la dernière spécialité.
Chaque fois qu'il clique sur "ajouter une autre spécialité" une nouvelle ligne apparaît.
Chaque fois qu'il clique sur "retirer la dernière spécialité" la dernière ligne disparaît sauf si c'est la première.
Le plus difficile était d'imaginer le comportement du système avant de le faire.
Le test dans les autres navigateurs est passé avec succès.
screenshot41

pause

11h51 : réécriture de ma fonction qui permet d'uploader les images : maintenant elle gère plusieurs galeries simultanément.
Ajout de la possibilité de mettre des photos pour la galerie est opérationnel sur ffox.
Pas de problème dans les autres navigateurs
screenshot42

pause

13h36 : mise en forme finale du formulaire avant d'attaquer la partie traitement.

15h43 : écriture d'un petit algorithme qui détermine si le jour est ouvert pour le matin et pour le soir.
Cela me permet d'afficher mon petit planning qu'il y a sur la version actuelle de Tours annonces,
sans demander à l'utilisateur d'avoir à le taper, déjà qu'il se tape le module horaire...

L'alogrithme n'est pas top, mais bon, j'ai pas trop d'idées :
il vérifie pour chaque tranche horaire si il y a au moins 2 valeurs appartenant au tableau correspondant.
Par exemple pour le matin, le tableau est 9,10,11,12
et pour l'après midi, le tableau est 15,16,17,18

Si l'utilisateur met une tranche horaire de 9 à 12h30 par exemple,
mon algo va aller de 9 à 12, donc il va faire 9,10,11,12, et donc il y a
4 valeurs communes avec le tableau.
Comme il y a au moins 2 valeurs communes, le jour est considéré comme ouvert le matin...
J'imagine où il y a des cas où ça ne marche pas, ou qu'il y a plus simple, mais bon pour l'instant ça fera l'affaire.

17h28 : les insertions dans les tables tranche_horaire, commerce_has_commerce_specialite et commerce_specialite sont réalisées correctement.
Le réaffichage des champs "proposez une spécialité" ajoutés dynamiquement est également pris en charge.

Il me reste à faire l'insertion du bloc présentation, n'il est rempli, dans la table commerce_bloc_info,
et surtout la gestion du réaffichage des images de la galerie, ainsi que l'insertion dans la table commerce_galerie,
et normalement, c'est bon pour ce gros formulaire...
C'est certainement le formulaire public le plus complexe que j'ai du faire depuis mon arrivée dans webmaster land en 2005?

choses de la vie

00h39 : fatigué, gotobed, pas fini le formulaire.
Je viens juste de terminer le réaffichage des données concernant les horaires depuis la bdd.
C'est à dire afficher le formulaire prérempli avec les valeurs contenues en bdd.

Résumé : toute une journée passée sur ce formulaire, et il n'est toujours pas fini.
Etre minutieux, rester concentré...



                

**** 16-02-2010

07h36 : start

10h43 : choses de la vie : un autre boulot web à faire...
12h42 : avortement de l'autre boulot, intéressant mais pas au bon moment...

pause ;

13h53 : la cinématique jquery est en place pour le module horaires,
reste la validation, et le fait que les données doivent rester en place après une validation ratée.
screenshot39

14h38 : la persistance des données est opérationnelle.

15h05 : correction d'un bug de la méthode copier qui décidait de l'ordre des champs aléatoirement.
En fait, je passais par un webservice car je voulais n'avoir qu'une fonction pour gérer l'affichage,
mais vitesse d'appel de chauqe requête est légèrement différente à chaque fois.
Le problème est résolu en codant la fonction (en double) dans le javascript, ainsi le résultat vient instantanément et
on n'a plus ce problème.

16h08 : les règles de validation du module horaires sont établies.
Le système vérifie que les heures vont bien de 0 à 23, les minutes de 0 à 59,
que pour un jour donné, une tranche commence toujours après qu'une éventuelle précédente se termine.
Il vérifie enfin que l'horaire d'ouverture est inférieure à celle de fermeture pour une même tranche.

16h17 : Ajout d'une légende
screenshot40

Cela aurait été trop facile si IE7 affichait tout correctement comme les autres navigateurs...

16h25 : bug non résolu mais évité : ie7 ne m'affichait pas le premier icône de la légende (le plus)
J'ai ajouté un 
 avant.
Evidemment ca descend le contenu sur tous les navigateurs,
I hate ie7, mais je m'en sors pas trop mal pour le coup.

17h19 : ajout du comportement de switch Avez-vous des horaires hebdomadaires réguliers, qui affiche le module.
ffox, safari et chrome sans problème,
ie7, bugs !!
17h28 : résolu! j'avais mis un display:table; je l'ai remis à block, ouf.

17h48 : Mon schéma sql n'est pas top, il ya la table commerce_specialite_groupe qui ne servira pas,
puisqu'en réfléchissant, un commerce_specialite_groupe c'est en fait une catégorie.
Et oui, je vais proposer les spécialités en fonction des catégories.
Si une catégorie n'existe pas, pas de spécialités pour cette catégorie.
Donc le parent de commerce specialite c'est arborescence.
On pourrait presque mettre les spécialités en tant que sous branches de l'arborscence,
sauf que un commerce peut avoir plusieurs spécialités alors qu'il n'appartient qu'à une seule catégorie.
Bref.

Voici le nouveau schéma
schéma-commerce2.png

choses de la vie.


23h55 : Trop fatigué pour continuer.

Résumé : le module horaires est intégré, c'est le premier pas vers une intégration complèe du formulaire d'ajout de commerce.







Mon formulaire comportera plein de jquery,
donc soit ça rame, soit c'est kool,
mais si ça rame ça coule.
Ca serait plus kool avec plus de ram.






                

**** 15-02-2010

06h23 : start
Peu de temps aujourd'hui, vite...

10h33 : la catégorie immobilier location est opérationnelle.
Finalement j'ai fait un mix de pap et seloger.
screenshot37

Au niveau du code,
pour des raisons de propreté, j'ai finalement opté pour la solution
où la location et la vente sont réellement des catégories séparées :
chacune possède son set de table, son formulaire, ses méthodes,...

11h14 : la partie immobilier vente est opérat ... oups, j'ai oublié de changer les types de bien...
11h19 : la partie immobilier vente est opérationnelle.

Bon à ce stade, je pourrais faire la même chose pour la colocation en prenant exemple sur les sites spécialisés en colocation,
de même pour les rencontres en prenant exemple sur meetic,
mais bon timing timing,
passons au système de commerces.

Cette fois-ci je vais essayer de tout conceptualiser AVANT,
à vrai dire c'est ce que j'essaie de faire à chaque fois,
mais il y a toujours un moment où je craque car c'est trop abstrait et j'ai besoin de concret,
mais bon théoriquement si je m'y prends bien...


Restons simples.

La partie commerce du compte tours annonces permet d'ajouter un commerce.
Quelles sont les informations concernant un commerce.

ville

(OUPS, le travail me rattrappe, je vais devoir faire l'intégration d'un site qui n' a rien à voir ce soir)

Donc prenons exemple sur un magasin qui existe déjà pour que ça me parle mieux
En fait ce que j'avais fait était visuellement pas mal,
c'est juste le code qui est du nimportenaouak.

Il me suffit donc de copier sur mon site::

http://coiffure.toursannonces.fr/coiffure+tours/cb-coiffure_0218#coiffure-Tours-Centre-37000


Je vois cela de manière modulaire,
c'est à dire avec des blocs,
comme les cadres vert qui sont sur mon site :
coordonnées, spécialités, infos pratiques, présentation,...
,je dois pouvoir ajouter des cadres facilement.
Appelons les cadres des blocs d'informations=blocinfo

Certains  blocinfo seront déterminés à l'avance, comme coordonnées.
L'utilisateur doit pouvoir créer ses propres blocinfo, le nombre pourra être limité par moi,
en vertu du principe FOPAPOUSSEMEME (si jamais un utilisateur ajoute 1000000000000 de blocinfo...).

Donc un blocinfo a un
titre
texte
position

3 propritétés, kool.
L'utilisateur ne pourra pas faire de lien (j'allais dire le contraire mais en réfléchissant je
préfère protéger mes utilisateurs car il y a trop de personnes qui cherchent à voler les gens,
et qui font du phishing etc..., pas de lien=pas de tentation de mettre son brun sur mon site.)

Donc du texte pur et dur, peut être quelques balises permettant une mise en forme basique :
des couleurs... titre....
Voir si ya un éditeur en jquery.

J'aurais voulu dire que l'utilisateur peut mettre des photos dans les blocinfo, mais par rapport
au temps de dévelloppement, non pour l'instant, plus tard peut être si le besoin se fait sentir...

Toujours si je me base sur la version actuelle, je vois des sections en haut.

section infos, avis, plan, photos, perso, video.


L'utilisateur ne peut pas ajouter des sections.
En fait il peut juste ajouter des blocinfo dans la section infos
mettre des photos dans la section photos.
Le plan devrait être tracé automatiquement par Google, hélas ce n'est pas si simple,
car dès fois le plan ne s'affiche pas, et un simple changement de virgule ou d'espace peut faire
que le plan réapparaisse à nouveau;

Bref,
au niveau des avis,
quelques commerçants m'ont dit que c'était une très mauvaise idée.
D'un autre côté, certains commerçants ont déjà plusieurs avis favorables et je comprends qu'ils souhaitent les conserver.

Je garde donc les avis,
mais l'utilisateur pourra les modérer = interface de gestion des avis.

En plus ça ouvre vers un aspect communautaire qui est intéressant.

Définissons mieux le contenu des blocinfo dans la section infos:
Les blocs infos toujours présents seront :
coordonnées
horaires

--------------------------------------------------------------
La structure du blocinfo coordonnées est déterminée à l'avance.
L'utilisateur doit remplir les champs vides, obligatoires :
Appellation du commerce
adresse
ville, cp

et les champs optionnels :
tel
tel2
fax
mail
site internet
--------------------------------------------------------------

--------------------------------------------------------------
La structure du blocinfo horaires est déterminée à l'avance.
Un formulaire demandera à l'utilisateur pour chaque jour :
êtes vous ouvert le midi, êtes vous ouvert le soir.

J'imagine que certains commerçants n'ont pas des horaires hebdomadaires réguliers,
dans ce cas il leur faut un autre moyen d'indiquer leurs horaires.

Le formulaire se présentera donc comme cela :
*Avez-vous des horaires hebdomadaires réguliers ?
oui->le formulaire par jour apparaît
non->rien ne se passe

*Précisions sur votre horaire (de 06h30 à 13h tous les jours sauf mercredi)
--------------------------------------------------------------


--------------------------------------------------------------
La structure du blocinfo spécialités est déterminée à l'avance.
(Mais ce blocinfo n'est pas obligatoire.)
Une liste déroulante présente les spécialités en base de données.
L'utilisateur choisit d'ajouter une ou plusieurs spécialités.
Peut être que le nombre de spécialités autorisé sera limité par moi
(fppm).
Dans le même formulaire :
*Créer une nouvelle spécialité : [nom]
--------------------------------------------------------------


Note : toute modification dans la partie commerce du compte tours annonces
sera soumise à modération.

--------------------------------------------------------------
La structure du blocinfo Présentation est déterminée à l'avance.
(Mais ce blocinfo n'est pas obligatoire.)
C'est la structure de base d'un blocinfo.
C'est exactement pareil que si l'utilisateur créait un blocinfo avec un titre
présentation, c'est juste que ça lui évite de taper présentation.

Ce bloc est originellement pensé pour permettre à l'utilisateur commerçant de présenter
son commerce.

--------------------------------------------------------------


Ok, jusque là ca ma va.

Voyons les autres sections.
avis,
plan,
photos,
perso,
video,

avis :
Le système déjà en place est pas trop mal :
un lien permet à un utilisateur lambda connecté de laisser un avis via un formulaire avec
juste un champ pour la note et un champ pour le commentaire textuel.
Des icônes sont attribués en fonction de la note.

Faudra remettre le système des couleurs pour les utilisateurs (rouge bleu), et même en ajouter, plus tard...

Donc dans son compte, l'utilisateur a la liste des avis concernant son commerce.
Il peut supprimer l'avis.
Evidemment il ne peut pas le modifier.
En plus , à chaque fois qu'un avis est posté, il n'est pas affiché directement :
à la place :
Votre avis a bien été enregistré sur le système tours annonces.
Le commerçant untel va lire votre avis et décider de le poster ou non.


Bref, l'avis apparaît dans le compte du commerçant et celui ci a alors le choix :
valider, refuser.
Une notification de cette décision est envoyée par mail à l'utilisateur ayant posté le message.



Plan :
dépendant de google.

Photos :
l'utilisateur peut mettre un certain nombre de photos décidé par moi.
La disposition des photos est pour l'instant décidée par le code que j'aurais fait,
ce serait bien dans un futur proche de permettre à l'utilisateur de choisir le mode d'affichage
de ses photos:
galerie style 1
galerie style 2

Imaginons une table commerces_galeriephoto qui contient les champs suivant :
id
style : l'identifiant de style de la galerie, par défaut "default"
folderpath : le chemin vers le dossier qui contient les photos.

La gestion du nombre de photos par dossier est gérée ailleurs.

Le nombre max de galeries qu'un utilisateur peut créer est déterminé par moi.

Tant que ce nombre n'est pas atteint,
l'utilsiateur lorsqu'il se connecte au formulaire d'ajout de galerie voit le formulaire ,
et sinon le formulaire n'apparaît pas.

*Style
*Ajouter une photo


Perso :
euh...
une feuille de style par compte,
une feuille html par compte ou une feuille php.
Si c'est du php évidemment ca passe par moi (fppm).
Le html est une option payante, comme ça ça réduit le risque que n'importe qui
fasse n'importe quoi.

En gros si la feuille de style et le html existent, il sont appelés.
Sinon, le message par défaut appraraît un peu comme sur le site actuel :
exemples de page perso...

Dans le principe, il y aura un formulaire (dont les droits d'accès seront déterminés ailleurs)
comme cela :
* ajouter une feuille html
* ajouter une feuille css

Vidéo :
* ajouter une vidéo


Bon, voilà voilà en gros,
donc tout ça c'est bien gentil mais ça me dit rien sur la base de données et l'organisation des
fichiers.
Les choses de la vie vont me rattraper;;;
12h25 : tentative d'une esquisse de base de données dans le temps trop court qui m'est imparti.
Ah non en fait, avant de faire cela il faut que je résume le système de modération validation en place,
sinon je vais l'oublier;..


Voici mon schéma de règles de validation tours annonces, par rapport à la modération
schema3

choses de la vie.


14h59 : de retour au travail.
Au passage, j'avais oublié la section stat, importante, mais qui en fait serait peut être
plus à sa place dans le compte de l'utilisateur.
Enfin disons que cela dépend de la manière dont on voit les choses :
si on considère que les stats d'un commerce sont des données personnelles qui appartiennent
au commerçant ou si elles sont publiques et appartiennent au site Tours annonces.
N'ayant pas encore tranché, je laisse le destin décider à ma place :
c'est moins coûteux en terme de performance de ne laisser les stats accessibles qu'à un utilisateur
plutôt qu'à tous.
Pour l'instant, je mettrais donc les stats dans le compte de l'utilisateur.

15h17 :
mon premier design à la main comprte 4 tables :
commerces, commerces_blocinfo, commerces_galeries, commerces_has_commerces_blocinfo

En fait ça ne correspond pas tout à fait avec ce que j'explique un peu plus haut, pas le temps
d'expliquer...

15h35 : déclic dans la tête d'un développeur du dimanche sur la compréhension des diagrammes
mysql avec mysql work bench : pas obligé de mettre toutes les tables sur le même diagramme,
kool....

16h29 : mon imprimante n'imprime plus en noir, snif.

16h44 : une page très intéressante
http://www.les-horaires.fr/horaires/ajouter-commerce.php

17h22 : Le fichier commerces.txt a correctement été importé dans la bdd de Tours annonces.
commerces.txt

Comme je suis bête, j'étais en train de les ajouter manuellement en tant que spécialités de commerces et groupe de spécialités,
jusqu'à ce que je me rende compte que ce ne sont que des catégories, ce qui correspond à mon arborescence,
et qui laisse les spécialités vierges, prêtes à répondre aux désirs des commerçants.


17h38 :
petite réflexion sur la stratégie "commerciale" du site.
Surtout comme je suis une grosse fainéasse, je me cherche des excuses pour pas avoir à faire un système de gestion complet
avec modification et modération sur les commerces.
A la place, j'aimerais bien juste avoir une modération binaire :
je valide ou je ne valide pas.

Et j'ai trouvé une solution (honte sur moi en tant que développeur) commerciale :
Tout utilisateur peut PROPOSER  son commerce, c'est à dire remplir le formulaire et voilà.
De mon côté, je valide tous les formulaires qui me semblent correctement remplis et surtout basés sur des données réelles.

L'utilisateur lambda NE PEUT PAS modifier son commerce,
(ce qui m'évite tout le développement de la modération avec modification qui est très lourde.),
mais l'utilisateur qui paie un droit d'entrée en tao ou euros, PEUT modifier ses informations.
Le hic : je n'ai plus le contrôle direct sur la validation des données=porte ouverte sur le zoukmachine.
Cependant, la barrière du prix refute les âmes crasher qui ne veulent pas payer pour crasher, et on les comprend.

Donc la stratégie est la suivante :
JE référence les commerces à la main, en les démarchant, et je les inscris gratuitement.
Je valide également tous ceux qui remplissent le formulaire d'ajout de commerce (ou pas si c'est du factice).
Je propose aux commerçants que j'ai sélectionné (ceux que je démarcherai) mon interface de gestion du commerce,
celle que je n'ai pas encore développée à un prix en euros.
Cette interface est exempte de modération directe(point faible du système).
Je me réserve le droit de supprimer sans conditions tout utilisateur, même s'il a payé
qui mettrait des informations de nature douteuse sur mon site.

Je ne devrais pas permettre à un utilisateur d'acheter ce droit d'utiliser mon interface,
même si j'en meures d'envie.

Ainsi ça limite pas mal les risques que tout le monde essaie de mettre des bêtises sur l'annuaire.
Et je n'ai pas à me taper la modération avec modification.

C'est avec objectivité que je constate que mon ingéniosité se déploie surtout quand il s'agit pour moi d'en faire le moins possible.

Malheureusement, objectivement, cette solution n'est pas la bonne, en terme de développement, car mon idée à la base c'était
la modération avec modification.
Faiblesse.



Je me pardonne;

Ma solution de compensation n'est pas si mal.
Le système d'ajout de commerce est accessible à tous.
Seuls ceux qui m'auront payé pourront utiliser le système complet de gestion.


J'aime beaucoup le formulaire ici
http://www.les-horaires.fr/horaires/ajouter-commerce.php
et surtout la partie horaire,
même si dans la réalité, c'est un peu beaucoup,
oh et puis non pas le temps, il me faudrait peut être 4 ou 5 heures pour le refaire, alors bof,
surtout que ca alourdirait la bdd, pas très justifié.
autant garder mon bon vieux système :
une chaine de caractère du genre
1,1,1,1,0,1,0,1,0,1...
accompagné d'une description textuelle
Vu ce que je vais faire des horaires c'est approprié,
et de toute façons la porte n'est pas bloquée pour l'évolution.

En réfléchissant un peu autant le faire tout de suite,
comme ça pour x raisons, un jour ou l'autre je pourrais proposer les commerces qui
sont ouverts avant telle heure.

Oh et puis non,
il suffit de regarder les horaires et on est aussi bien renseigné.

Je n'y vois pas un énorme intérêt...

En fait si j'ai trouvé l'intérêt :
imaginons qu'il est 17h52,
la personne veut acheter un cadeau pour sa grand-mère, avec qui elle a rdv à 19h,
elle habite tours centre  et cherche une carterie ouverte jusqu'à 18h30.
Heureusement cette personne connaît tours annonces et maitrise le fonctionnement de l'annuaire,
en une recherche, elle trouve son bonheur.

Donc je le fais.

Avant de commencer voici où j'en étais au niveau du design du formulaire :
screenshot38

Heureusement que j'ai pris cette décision,
ca m'a permis de me rendre compte que le schéma 3 était tout à fait incorrect :
mauvaise utilisation des has_
Voici ma correction,
schema4

Concernant la table tranche horaire:
oh = open hour
om = open minutes
ch = close hour
cm = close minutes

J'ai simplement regardé le code source du site les horaires.fr

Choses de la vie

00h47 : toujours au codage visuel du module_horaire, mais là j'ai atteint le point du légume vert, point de non retour.
Pas assez d'énergie pour utiliser mon cerveau.
reload.

                

**** 14-02-2010

08h16 : start
08h53 : le comportement "supprimer" est fonctionnel.

09h08 : Correction d'un bug d'affichage dans les listes journal provoqué par l'encapsulation de l'annonce dans un div container.

09h19 : les actions sur les annonces (Editer, supprimer, réinitialiser) ont été ajoutées sur les annonces en mode journal.

09h50 : activation des tris par date, statut dans la liste des annonces du front-office, et mise à jour des requêtes.

11h16 : mise à jour du schéma sql pour toutes les catégories de véhicule
screenshot36

pause

Corrections de bugs mineurs divers
15h03 : la catégorie moto me semble fonctionnelle.

pause

16h29 : le jet initial est terminé : toutes les catégories de véhicules sont codées.
Débuggage...
ie7 est d'une lenteur effroyable pour l'affichage dynamique des catégories plugin, j'ose même pas voir en ligne...
Les autres navigateurs sont bons. (ffox, chrome, safari)

17h36 : après de nombreux tests, tout me semble en ordre. ouf, mais je suis très en retard...

Analysons le site du pap ::

(Mise à jour toutes les 10 minutes du lundi au samedi de 9h à 18h)
    *  Location immobilière >>>
    * Vente immobilière >>>
    * Location vacances >>>
    * Bureaux & commerces >>>
    * Vide-grenier >>>

	http://www.pap.fr/immobilier/location-immobiliere.htm

Sinon il y a ça,
http://www.seloger.com/annonces.htm?idtt=1

choses de la vie

00h56 : mise à jour du schéma sql pour la partie immobilier

Décevant certes, mais ce soir j'ai rencontré un vieil ami, et donc on a bu et j'étais bourré.
Finalement, je n'aurais pas réussi à tenir mes délais pour cette fois (la partie annonce).





                

**** 13-02-2010

08h10 : start

pause

17h22 :  le code est rattrappé et amélioré;
Tout est propre, et j'ai ajouté un petit effet sympa lorsque l'utilisateur clique sur réinitialiser,
ce qui arrive lorsque une modification d'annonce a été refusée,
l'annonce apparaît alors en rouge dans son compte avec le lien réinitialiser en dessous.
Lorsqu'il clique dessus, l'annonce qui est visuellement celle qu'il espérait voir en ligne se
retransforme dynamiquement en l'ancienne annonce (celle qui est actuellement en ligne).
Pour le côté dynamique encore une fois j'ai utilisé jquery, getJson pour être précis.

Bon il me reste quand même les comportements supprimer à ajouter, mais le gros est fait,
et surtout sauvegardé.

choses de la vie .

00h24 : stop : fatigué.
Résumé :
Le système de modération validation des annonces est quasi en place.
Tenir les délais va être très difficile car hélas je n'ai pas fini le comportement "supprimer" ce soir
et donc je devrais le faire demain.

                

**** 12-02-2010

06h37 : start
07h56 : le système de modération fonctionne basiquement entre le compte de l'utilisateur et le backoffice (aucun développement en frontoffice)
Voici le schéma qui est en place au niveau du compte utilisateur
screenshot35

choses de la vie

11h53 :dans la série Régis est un con, Régis fait du php.
La boulette du siècle! Un script censé effacer quelques photos, mal configuré m'efface toute mon application.
Et pour couronner le tout, pas de backup récente.
Enfin hier, mais depuis hier j'ai pas mal codé alors, c'est pas top.
Il y a même pas les marques et les modèles, misère.


pause


En gros je venais de finir le système de modération, mis à part ce détail sur les photos.
J'ai trouvé un logiciel gratuit qui s'appelle PC inspector file recovery sur le net.
Je suis en train de le tester, mais apparemment il va mettre 1h40 pour scanner mon pc.
Gasp!



Bref, plutôt que de me lamenter c'est l'occasion ou jamais de prendre de l'avance,
je vais voir ce qui a déjà été fait au niveau des forums, comme j'y connais encore rien.
http://forums.phpbb-fr.com/telechargement-maj-phpbb3/

14h23 : le forum est installé, je suis en train de regarder les params...

16h18 : PC inspector file recovery trouve bien les fichiers effacés, mais alors le contenu c'est n'importequoi...
Sinon j'ai essayé glary undelete, il reconnaît même pas les fichiers.
Bref, je vais me faire un recovery à la main.
Et PhpBB, c'est très bien fait, mais peut être un peu trop gros par rapport à ce que je voulais faire.
Et j'ai pas trouvé comment désactiver la modération.
Bon mais c'est quand même bien fait, je vais voir si je peux l'adapter rapidement, mais plus tard,
maintenant c'est réparetesconneries time.
Pause : une ptite douche d'abord pour me mettre dans le bain;

16h41 : début du manual recovering.

choses de la vie

01h56 : Hélas mon manual recovering n'a pas abouti ce soir, j'avais beaucoup codé...
Mais bon ma force positive saura réparer les dégâts d'ici peu.

Voilà, mieux vaut être en forme pour demain.
Ma deadline, finir le système de validation et les catégories véhicules et immobilier pour dimanche soir,
sinon ...
ben sinon je continue...




                

**** 11-02-2010

08h01 : start

09h41 : ajout des champs marque et modèle au formulaire d'ajout de voiture (oubli de ma part)
screenshot33

RDV CréditMutuel pour paiement en ligne

11h19 : écriture d'un petit mémo sur l'organisation du formulaire d'ajout d'annonce
screenshot34


pause

13h36 : Mise à jour de l'aperçu de l'annonce par rapport à la marque et au modèle.

choses de la vie

01h16 :
Surestimer ses compétences, se confronter directement à un problème sans s'y être préparé,
2 erreurs de débutant (que je suis) que j'ai commises aujourd'hui.
Ma mission de mettre à bas le système de modération ce soir a échoué;
Finalement, il m'a fallu longtemps mais j'ai trouvé la conception qui me convient tout à fait du moins spour le moment.
Trop fatigué pour l'expliquer là, mais j'ai de bons espoirs de finir demain,
et si c'est le cas je lèverai le voile à ce moment sur le nouveau système.
Les erreurs de conception sont certainement
la source d'erreur qui fait perdre le plus de temps,
quand on s'en rend compte, c'est déjà trop tard,
tester des choses futiles, se perdre dans les détails,
il faut de l'énergie pour repartir du bon pied.

Le rdv avec le crédit mutuel n'a pas débouché comme je l'espérais sur un dossier finalisé.
Etant donné que je ne suis que le contact technique, je n'avais pas les infos nécessaires pour finaliser
le dossier qui était demandé;
En fait ils sont très select le crédit mutuel.
Il faudra attendre que le contact commercial prenne mon relais.
                

**** 10-02-2010

07h52 : start
09h40 : le dossier admin est rappatrié et la logique de découpage est en place.
Un identifiant de dossier est déterminé qui vaut par défaut admin
et qui est utilisé comme préfixe pour tous les dossiers à inclure en interne.
Pour les fichiers externes : js, css, img
les dossiers ont été fusionnés de telle sorte que l'admin est complètement
intégré dans le front-office.
Seules les règles de routage ont été modifiées afin de "protéger" le dossier ADMIN.
Evidemment ce n'est pas la seule protection...

10h34 : fusion des 2 librairies admin et front-office et des bases de données.

pause

14h25 : ajout des champs statuts et annonce_en_attente_id dans la table annonce_en_ligne.

L'idée est que l'utilisateur peut modifier plusieurs de ces annonces en ligne simultanément.
Plutôt que de recréer des nouvelles annonces_en_attente à chaque fois qu'une modification d'annonce est demandée,
on réutilise l'annonce en attente qui a alors exactement la même forme (tant que l'utilisateur ne l'a pas remodifiée)
que l'annonce en ligne, on n'a donc pas à recréer l'annonce, simplement à la rendre à nouveau active dans le compte utilisateur.
Cela revient à dire qu'une annonce = 2annonces liées : une en ligne et son pendant en attente.

15h10 : la validation d'une annonce voiture est opérationnelle dans mon admin.
Elle copie les tables concernées ainsi que les photos dans un dossier recréé à chaque fois, nommé "enligne",
au même niveau que les photos de l'annonce en attente.

15h29 : Le système de modération permet maintenant le refus d'une annonce:
en réalité, seul le statut de l'annonce est modifié : il passe à "refusée",
ce qui permet de l'afficher dans mon compte avec une couleur rouge par exemple.
screenshot32

15h37 : ajout d'une barre de liens fictive sous les annonces en liste de l'utilisateur, permettant d'éditer ou supprimer l'annonce,
en fonction du statut de celle-ci.

Corrections diverses de bugs mineurs et amélioration visuelle de certains détails.
Pause
Choses de la vie


00h33 :

Voici ce que j'ai écrit qui me servira de "guide de développement" pour demain :
Le synopsis de l'ajout d'une annonce.
L'utilisateur arrive sur son compte et affiche le formulaire d'ajout d'annonce.
Une annonce vide est automatiquement créée avec l'état
STATUT_EN_COURS_DE_CREATION

Il ne peut y avoir qu'une seule annonce avec cet état par utilisateur.

Une fois que l'utilisateur est satisfait du rendu de son annonce,
il la valide, et celle-ci passe à l'état
STATUT_EN_ATTENTE_DE_VALIDATION

Le modérateur va plus tard valider cette annonce ou bien la refuser.

Si il la valide, l'annonce en attente prend l'état
STATUT_VALIDEE,
et l'annonce est copiée dans la table annonce_en_ligne
(et éventuellement dans les tables liées =plugin= )
Le dossier photo, est copié vers le dossier "enligne",
qui est placé au même niveau que les dossiers thumb et photo
de l'annonce en attente.
Ce dossier "enligne" contient donc des copies récursives des dossiers thumb et photo.
Enfin dans la table annonce_en_attente, le champ annonce_en_ligne_id est mis à jour
avec l'id de l'entrée insérée dans la table annonce_en_ligne.

Sinon, il la refuse et elle prend l'état
STATUT_REFUSEE

Quelque soit le choix, l'annonce apparaît dans l'interface mon compte de l'utilisateur.
Si l'annonce a l'état
STATUT_REFUSEE
un lien "supprimer" apparaît sous l'annonce et l'utilisateur peut donc l'enlever de son compte.
Si il fait cela, l'annonce n'est pas vraiment effacée, mais prend plutôt l'état
STATUT_REFUSEE_ET_EFFACEE_PAR_UTILISATEUR

Elle devient invisible à ses yeux.

Si l'annonce a l'état
STATUT_VALIDEE
un lien "éditer" apparaît sous l'annonce et l'utilisateur peut donc modifier son annonce.
Si il fait cela, l'annonce prend alors l'état
STATUT_EN_COURS_DE_MODIFICATION

Une fois que l'utilisateur est satisfait de ses modifications, il valide l'annonce,
qui prend alors l'état :
STATUT_MODIFIEE_ET_EN_ATTENTE_DE_VALIDATION

Le modérateur voit ces annonces dans son interface
et fait un choix :
accepter les modifications :
l'annonce en attente prend alors l'état
STATUT_MODIFICATION_ACCEPTEE

ou refuser les modifications :
l'annonce en attente prend alors l'état
STATUT_MODIFICATION_REFUSEE

Dans ce dernier cas, l'utilisateur peut reéditer son annonce qui reprendra alors
l'état
STATUT_EN_COURS_DE_MODIFICATION

ou bien la supprimer, et dans ce cas l'annonce aura l'état
STATUT_REFUSEE_ET_EFFACEE_PAR_UTILISATEUR


Ben oui en fait la modération des annonces avec possibilité de modifier ses annonces c'est pas super évident,
enfin disons qu'il vaut mieux avoir la tête vide et les idées claires, car c'est assez complexe en fait.
Rien de bien méchant non plus, faut pas exagérer.
Bref,
j'espère que j'aurai fini ce système demain, car ça commence à traîner sérieusement cette partie annonce,
sans compter qu'il me reste les autres véhicules à intégrer, plus la catégorie spéciale immobilier, plus
l'affichage des annonces sur le site.
Oups, si j'ai fini dimanche ca sera bien en fait.
J'ai l'impression d'être une tortue des fois...






                

**** 09-02-2010

07h54 start

09h34 : la cinématique de test avec un seul champ est validée.

10h01 : workaround pour appeler dynamiquement des plugins jquery par javascript.
Ainsi, lorsque l'utilisateur choisit la catégorie voiture,
un nouveau fieldset est ajouté dynamiquement au formulaire,
et ce fieldset peut exécuter du jquery, par exemple datepicker.

L'astuce est donnée ici à la base:
http://old.nabble.com/Calling-functions-in-parent-window-from-iframe-td20611805s27240.html

En gros pour appeler pou(); dynamiquement, il faut la déclarer préalablement comme ceci :
pou = function() {alert("pou");};
au lieu de
function pou()
{
	alert("pou");
}

Terrible!

10h34 : mise en forme de l'icône de calendrier pour le datepicker.
Un bug d'affichage est repéré dans safari, mais pas chrome,
dans le cas suivant : l'utilisateur sélectionne la catégorie voiture, il valide son formulaire mais celui-ci contient des fautes.
Le champ date-picker contient au moins un caractère.
Il change de catégorie.
Lorsque le scénario ci-dessus survient, safari windows a du mal à enlever le fieldset.
Il se transforme alors en mode "paint" : quand on bouge la souris sur les éléments, d'autres qui n'ont rien à faire là apparaissent !
Super désagréable, mais un simple drag'n'drop sur l'ascenceur et la situation redevient normale.

11h14 : Finalement
comme j'arrivais pas à faire en sorte que l'on puisse sélectionner des dates inférieures à la date actuelle,
j'ai intégré celui là :
http://keith-wood.name/datepick.html

il bug encore plus sous safari, mais bon tant pis, il est mieux fait;
11h34 : j'ai trouvé tous les settings que je voulais, une vraie merveille !
Le calendrier, pour le choix de la date de première immatriculation d'une voiture s'affiche :
lorsque l'on clique sur le input ou sur l'image que j'ai choisie.
Il affiche les années de 1900 à aujourd'hui.
Et il est en français.
Que du bonheur.

options = {
yearRange: "1900:'. $actualYear .'",
showOn: "both",
buttonImageOnly: true, buttonImage: "/img/jquery/datepicker/calendar2.png"};
$(".date-pick").datepick(options);

pause
choses de la vie

17h52 : l'ergonomie du formulaire et l'intégration est réalisée, il me reste juste l'insertion dans la
base de données...

20h54 : la partie insertion dans la base de données des données provenant du formulaire d'ajout d'annonce
voiture me semble fonctionnelle.
screenshot28 : options non développées
screenshot29 : options développées

22h06 : l'aperçu de l'annonce avec les nouveaux champs est intégré.
Seuls les champs remplis par l'utilisateur sont affichés.
screenshot30 : options développées

22h26 : Mise à jour du schéma sql en vue d'intégrer le système complet de modération-validation des annonces;
screenshot31

pause

01h02 : J'arrive à visualiser les annonces en attente de validation dans l'admin.
Je peux aussi cliquer sur la photo pour voir l'aperçu

Mais il y a un gros hic : mon admin est en fait un autre site;
j'avais fait cette séparation pour des raisons de sécurité,
mais en fait ca m'oblige à dupliquer certaines parties de codes,
je n'aime pas du tout ça.
Je crois que je suis en train de me planter au niveau de la conception.
Le mieux serait de refaire l'admin et de l'intégrer directement dans le site,
et trouver des astuces pour la sécurité.
Je vais voir ce que je peux faire demain.

Ou sinon je continue comme ca à mes risques et périls.

Résumé de la journée :
le gros du travail sur les annonces est réalisé : l'ajout d'une annonce avec des champs supplémentaires comme dans voitures.
La logique de découpage, l'organisation est encore fraîche mais j'aime bien le code, beaucoup plus propre que la version précédente.
La duplication des autres catégories comme moto prendra moins de temps (heureusement).

Malheureusement le fait d'avoir une admin séparée n'est peut être pas une bonne idée,
et cela va se faire ressentir au niveau de l'avancée de la réalisation du site.



                

**** 08-02-2010

07h55 : start

08h49 : le page link est ajouté sur la page moncompte > liste des annonces
09h23 : Ajout d'un fond de couleur jaune clair sur les annonces en attente de validation de mon compte.
J'aurais pu (du) faire 2 requêtes séparées, mais je me suis dit que c'était abusé au niveau des performances.

pause

En réfléchissant ce n'est pas forcément une plus mauvaise solution,
ca donne un côté sympa au site (mais un peu brouillon certes).
Peut être qu'un autre jour je ferais une séparation nette entre les 2 listes.
fin de la discussion.

11h19 : découverte intéressante en css
inline-block m'a sauvé la vie :

a.mail{
    display:inline-block;/*permet d'afficher un lien avec une image de fond et sans le texte dans les 3 navigateurs*/
    width:21px;height:15px;background:url(mailBg.png) no-repeat left top;text-indent:-10000px;
}

La technique me permet donc d'afficher un lien "as an image", et en mode inline.
Je viens de télécharger safari (ouf, la mise en page de différentes pages est restée)
et le mode inline-block se comporte de la même manière.
Il me semble que safari se comporte comme chrome.

Voici un aperçu du rendu de la liste des annonces de mon compte en mode journal
(j'ai désactivé le fond jaune juste pour le screenshot pour des raisons de présentation : )
screenshot24

Le comportement affichage_mailtel est fonctionnel.

pause

13h50 : ajout du switcher style web style journal sur la page mon compte > annonces

14h55 : le tri par date, prix et statut est fonctionnel
screenshot25

16h41 : un moteur de recherche basique par mots dans les champs titre et description
des annonces de l'utilisateur est opérationnel.
screenshot26

17h07 : pause avant la partie la plus longue : les véhicules...

20h15 : j'ai construit un robot qui récupère les marques et modèles de véhicules sur la centrale.
Je lui passe une url comme celle là :
http://www.lacentrale.fr/occasion-moto.html
et voici le fichier qu'il me génère pour voiture par exemple :
voiture

J'ai mis peut être un peu plus longtemps à construire le robot que le temps qu'il m'aurait fallu à la main
pour tout récupérer.
Mais,
maintenant mon robot est prêt, et la prochaine fois qu'une tâche similaire viendra, je mettrais un peu moins de temps.
Et en cas de mise à jour, à condition que la structure html de la centrale ne change pas,
je pourrais directement utiliser mon robot qui est du coup beaucoup plus rapide que moi.
L'élève dépasse toujours le maître, c'est bien connu.

Testons les performances de notre petite créature sur cette page :
http://www.lacentrale.fr/occasion-camping_car-caravane.html
attention 3.2.1.0
1 minute et 3secondes pour sortir cela :
campingcar

Kool non ?
Il tient de moi c'est sûr...

Il faut que je vous fasses une confidence : j'adore travailler avec des robots.

Pour les bateaux, il faudra que je m'inspire de ce site :
http://www.annoncesbateau.com/

Mais bon pour l'instant j'ai déjà beaucoup à faire avec les véhicules terrrestres.

20h54 : toutes mes catégories sont prêtes et sauvegardées.

J'étais en train de me demander si ca valait vraiment le coup de mettre toutes les options qu'on trouve sur la centrale :
première main, kilométrage, couleur de la peinture, etc...

En regardant vite fait sur mon site, j'ai pris 2 annonces au hasard et ces champs étaient remplis, donc oui.
23h41 : insertion des options de véhicules dans la bdd.
Maintenant, je suis fatigué, mais j'ai une idée de comment faire l'intégration des catégories spéciales dans le formulaire
d'ajout d'annonce :
lorsque l'utilisateur sélectionne une catégorie,
javascript regarde si c'est une catégorie spéciale.
Si c'est le cas, en appelant un webservice,
javascript appelle de manière asynchrone un plugin qui ne contient que les champs du formulaire
à ajouter.
Les champs s'affichent dans le formulaire dynamiquement.
L'utilisateur remplit les nouveaux champs.
En cas d'erreur, la page sera rechargée.
On se sert de la variable post actuelle pour déterminer l'id de la catégorie,
et le même plugin (qui ne contient que les champs du formulaire à ajouter)
est appelé, mais statiquement cette fois, ce qui donne l'illusion de la persistance des données.

Voilà, demain sera l'occasion de mettre cela en place.

J'attaquerai avec la bdd suivante :
screenshot27

                

**** 07-02-2010

08h01 : start

08h12 : Alors que j'étais sur le point de finaliser mon système de sauvegarde des photos pour le formulaire d'ajout d'annonces,
avec le schéma ci-dessous,
screenshot16

je me suis rendu compte que je n'avais en fait pas besoin de bdd pour cela;
Lorsque un utilisateur ajoute une photo, 2 photos sont automatiquement créées et placées ici,
en 2tailles
ex :
/img/annonce-photo/2010/02/07/23/photo/laPhoto.jpg
/img/annonce-photo/2010/02/07/23/thumb/laPhoto.jpg

/img/annonce-photo/ est une partie fixe,
2010/02/07/ correspond à la date du jour  (je ne vais pas recommettre l'erreur d'avoir un seul dossier pour toutes les photos, car après, le dossier
devient extrêmement gros, et il devient extrêmement coûteux de l'ouvrir par le ftp, donc pour les sauvegardes par ftp, c'est la misère...)
23 correspond à l'id de l'annonce_en_attente
photo correspond au format pour les photos que j'ai défini (600x450)
thumb correspond au format pour les vignettes (100x80)
laPhoto.jpg est la photo que l'utilisateur a postée.

Ah ben si en fait j'ai besoin d'une bdd.
Mais je n'ai pas besoin de 2 tables just pour les photos,
en fait je vais juste rajouter un champ photopath et renommer photo en mainphoto dans la table annonce_en_attente (et annonce_en_ligne),
et le champ photopath contiendra /img/annonce-photo/2010/02/07/23/
et le champ mainphoto contiendra /img/annonce-photo/2010/02/07/23/photo/laPhoto.jpg (qui correspond à la photo qui est affichée dans la liste des annonces)

Après, sur le site, sur la page d'affichage du détail de l'annonce,
je récupère /img/annonce-photo/2010/02/07/23/
et je ferais une boucle qui parcourt ce dossier + thumb pour les vignettes
et ce dossier + photo pour les photos, en prenant bien soin de ne filtrer que les images (ça va sans dire).

Ca m'économise pas mal de ressources,
"winning the tours annonces optimisation of the day"
=je suis content

Par contre, il faut bien déterminer les cinématiques afin qu'il n'y ait pas de mauvaises surprises
sur l'ajout et la modification et la suppression des annonces.
Un seul faux pas peut mener à la catastrophe.

09h42 : je viens de conceptualiser le schéma de base :
Modification-Modération d'une annonce

et donc le nouveau schéma sql :
screenshot17

Si l'utilisateur poste une photo le 06 janvier à 23h59 et une autre le 07 janvier à 00h02.
mon système est ko.
Afin d'éviter les soucis du genre :
le chemin photopath est déterminé dès la création de l'annonce_en_attente et "en cours de création".

11h45 : la page d'aperçu de l'annonce est intégrée avec des données factices
screenshot18
screenshot19

pause

15h20 : la page aperçu est intégrée, avec les données réelles,
screenshot20

Je ne remercierais jamais assez john Resig,
l'auteur de la librairie jquery,
qui permet à des noobs comme moi des faire des trucs kool en 2 temps 3 mouvements.

Par défaut, la galerie de photos que j'ai créée est du html pur,
quand on clique sur les vignettes, rien ne se passe, c'est mort.

Grâce à jquery,
3 lignes de code suffisent pour dire que un clic sur une vignette change la photo du haut.
Voici un extrait de mon code:

$hh_jqueryCode[] = '
$(".annonce-photo img:gt(0)").click(function(){
var zeimg = $(this).attr("src").replace("thumb/","photo/");
$(".annonce-photo img.mainphoto").attr("src",zeimg).css("display","none").fadeIn();
});
';

La première ligne cible toutes les images de mon div sauf la première (la grosse image),
et leur assigne un gestionnaire onclick qui exécute ce qu'il y a marqué dans les autres lignes.
La deuxième ligne prend la source de l'image cliquée et transforme le mot thumb/ en photo/
(spécifique à mon organisation des photos) dans cette chaîne, le tout est placée dans la variable zeimg.
La troisième ligne remplace la photo prinicipale par le contenu de la variable zeimg,
et en plus, même si je suis pas fun, juste paske c'était simple à faire, j'ai ajouté un effet de fadeIn() :
l'image apparaît à la manière d'un flash.

On peut difficilement faire plus simple et compact.
En css, ca m'aurait pris 2, 3 heures, peut être une demi-journée tellement c'est compliqué.
Et en plus sans les effets.
Sans compter une organisation de code plus délicate.
Définitevement, jquery est ma librairie favorite pour tout ce qui est animation dans une page html.


17h59 : le comportement valider une annonce est opérationnel :
il passe l'annonce en cours de création en validation.


16h32 :  ajout d'un troisième format de photo : mainphoto pour la photo principale;
Destiné à l'affichage en liste des annonces.
Le formulaire gère ce format.

17h49 : le design d'une annonce en liste est intégré avec des données factices.
screenshot21


choses de la vie

23h46 : finalement, j'avais oublié les dates sur les annonces en liste.
Du coup j'ai du repenser au moyen le plus simple d'afficher les données.
Et ca donne cela, une fois intégré avec les données réelles :
screenshot22

Oups! C'est exactement la disposition du site leboncoin.
A croire que la simplicité n'a qu'une forme.
Bon ok j'avoue je me suis inspiré...

Mais la seule chose qui m'intéresse, c'est la simplicité et l'efficacité,
c'est pourquoi j'ai retiré le format mainphoto ajouté un peu plus haut.
Ca fait des calculs assez inutiles en fait, tout ça pour avoir une photo de quelques pixels plus grands !
Bref, le format est maintenant assez compact comme j'aime et la photo de l'annonce en liste est thumb :
celle de thumb du détail de l'annonce.

00h35 : ajout de la gestion des centimes pour le prix, et si l'annonce n'a pas de photo, une photo transparente est insérée.
screenshot23

Résumé : Le moment le plus intéressant était sans doute l'ajout de la possibilité de charger 10 photos à l'annonce,
ca pourrait être 20, ou 30, ce n'est qu'un nombre à changer.
Plutôt que de passer sur la gestion des catégories spéciales comme prévu, je me suis volontairement préoccupé de
l'affichage en liste des annonces style web.
Bizarrement, je retombe sur une disposition comme celle du bon coin.
Demain, je vais certainement commencer par finir l'affichage en liste des annonces :
c'est à dire ajouter le pagelink,
puis peut être mettre en place tout le système de validation-modération des annonces.
Je ferais les catégories spéciales un autre jour, sauf si je trouve le temps demain,
ca serait bien mais je ne pense pas, on verra.
                

**** 06-02-2010

08h57 : start

Le système d'annonces : juste une petite remarque :
dans l'ancienne version de Tours annonces (actuellement en ligne),
Une annonce appartient à un utilisateur et l'utilisateur est attaché à une ville.
Du coup pour chercher une annonce par ville, je suis obligé de passer par l'utilisateur.

Bref, je pense que conceptuellement c'est une erreur :
en effet, une annonce a elle-même une zone géographique dans laquelle elle est valable (commune),
elle est donc théoriquement indépendante de l'endroit où habite l'annonceur.
Dans la pratique, ce concept peut signifier par exemple que je vends le pc de ma mère qui habite à un autre endroit,
et elle ne sait pas créer un compte tours annonces toute seule donc elle passe par moi pour vendre son pc.
Un peu tiré par les cheveux j'en conviens.

Le réel avantage est que la recherche par lieu géographique est plus directe.
= moteur de recherche plus efficace.

pause

12h40 :
J'ai mis longtemps à me décider sur la technique que j'allais utiliser pour afficher les catégories
dans la liste déroulante.
La méthode manuelle était séduisante pour sa simplicité et les performances,
mais le gros problème de cette technique est la non-réusabilité :
changement de catégorie = recodage à la main.
C'est beaucoup trop de choses à faire attention pour une mémoire de poisson rouge.

La contrainte (et l'avantage) de mon système d'arborescence est qu'il utilise le style nested.
C'est donc un peu moins intuitif de faire des requêtes sql.

La contrainte de mon système : la requête affiche 2 et uniquement 2 niveaux de profondeur de catégories.
A partir du moment où cette contrainte est posée et assumée;

Pour l'affichage, je voulais avoir le contrôle sur l'ordre d'affichage, aussi bien au niveau des catégorie de
profondeur 1 (VEHICULES, IMMOBILIER, EMPLOI)
que de profondeur 2 (voitures, motos,...) au sein des catégories de profondeur 1.

C'est à dire pouvoir dire :
affiche ca
VEHICULE
voiture
moto
IMMOBILIER
EMPLOI

ou ca

VEHICULE
moto
voiture
IMMOBILIER
EMPLOI

ou ca

IMMOBILIER
VEHICULE
voiture
moto
EMPLOI


etc ...

Pour cela, ma technique est d'attribuer une valeur d'ordre élevée aux catégorie de profondeur 1
et un ordre moins élevé pour les catégories de profondeur 2,
afin qu'ils ne jouent pas dans la même cour.

VEHICULE = 100
IMMOBILIER = 200
EMPLOI = 300

moto = 1
voiture = 2

Avec une bonne requête sql de chez mamiesql,
on peut demander à mysql en une requête de trier les résultats en fonction de sommeordre,
où sommeordre est la somme d'un ordre et de son parent.

Bref, voici la requête qui m'a donné du fil à retordre et qui porte ce comportement

$stmt = "SELECT c1.id, CONCAT(REPEAT('--', c1.profondeur), c1.nom) as nom,
(
(SELECT c4.ordre
        FROM arborescence c3
        INNER JOIN arborescence c4
        ON c3.limite_gauche BETWEEN c4.limite_gauche AND c4.limite_droite
        AND c3.profondeur = c4.profondeur+1
        WHERE c3.id = c1.id
        AND c4.id <> c1.id)

+  c1.ordre

) as sommeordre
    FROM arborescence c1
    INNER JOIN arborescence c2
    ON c1.limite_gauche BETWEEN c2.limite_gauche AND c2.limite_droite
    WHERE c2.id = :parentNodeId
    AND c1.profondeur <= (SELECT profondeur FROM arborescence WHERE id=:parentNodeId)+2
    AND c1.statut=1
    AND c1.id <> :parentNodeId
    ORDER BY sommeordre ASC, c1.profondeur ASC
        ";

Le gros avantage c'est que maintenant j'ai la tête vide pour la suite.
Enfin presque car je dois me rappeler que seuls 2 niveaux sont affichés,
et que quand je modifierais le champ ordre de la catégorie annonce
qui contient les catégories de profondeur 1 , cela impactera le système.

14h33 : mise en page de la page de relecture de l'annonce, avec un texte assez pompeux, genre ambiance maillon faible.
screenshot13

15h30 : la page de félicitations d'ajout d'annonce est intégrée. (J'ai mis des lunettes à la place du V)
screenshot14

Au passage une petite fonction que j'ai développée pour cette page, et pour d'autres éventuellement

function getBonneJourneeSoiree()
{
    $heure = date('H', time());
    if($heure < 3)
        $mot = 'une bonne nuit';
    elseif($heure < 10)
        $mot = 'une bonne matinée';
    elseif($heure < 12)
        $mot = 'une bonne journée';
    elseif($heure < 18)
        $mot = 'un bon après-midi';
    elseif($heure < 21)
        $mot = 'une bonne soirée';
    elseif($heure < 24)
        $mot = 'une bonne nuit';
    return $mot;
}


17h54 : de justesse : je viens de finir le roulement des images pour le formulaire d'ajout d'annonce.
Juste un petit bug d'affichage pas très choquant sous ie7, et il faut encore que je teste avec 10 images,
pour l'instant j'ai testé jusqu'à 3.
Qu'est-ce que je suis lent!

Choses de la vie

00h13 : J'avais oublié de blogguer, mais j'ai résolu le bug d'affichage sous ie7 et on peut mettre 10 photos.
Le formulaire fonctionne avec des données basiques : juste le titre, la description, le prix, la catégorie, la commune.
J'ai ajouté la date afin qu'elle se mette automatiquement à jour à chaque fois que le formulaire est posté.

01h04 : Il me faut réfléchir sur comment stocker les photos de l'utilisateur en base de données,
en termes de logique et de droits.
Est-ce que l'utilisateur a le droit d'effacer ses photos sans modération de ma part, oui.
Mais où sont stockées ses photos ?
etc...

Je pense que la gestion des photos était la partie la plus difficile du système d'annonce.
Une autre partie difficile risque d'être la gestion des catégories qui appellent des champs de
précision supplémentaires.
Je pense que demain j'aurai fini le système des photos et que je serai en train de faire le système des catégories spéciales.
Lentement mais sûrement.
screenshot15
                

**** 05-02-2010

08h23 start :
essayer de récupérer rapidement les données de l'insee concernant les données géographiques.

12h51 : j'ai enfin trouvé une fonction qui peut récupérer les données d'un fichier dbf avec les accents français.
(je n'ai pas le module dbase sur ma version de php argghh).

pause

15h35 : Ca y est j'ai fini l'objet Wing_Dbf_ToSql
qui me permet de créer une table à partir d'un fichier dbf;


15h43 : rappatriement des différents fichier dbf de l'insee sur mon poste.
Oups, le premier test n'est pas passé, erreur d'échappement de ma part...
correction
15h53 : deuxième test: ok pour les régions.
15h55 : département ok
15h56 : arrondissement: il me trouve 342 entrées, à vérifier.
15h58 : Les cantons ok (4 036 entrées) : php a mis au moins 1 minute à éxécuter le script! =je suis un pogrammeur du dimanche.
16h00 : Pour les communes : je me prends un "MySQL server has gone away" : je sais pas d'où ca vient! Mais je vais sauvegarder avant d'aller plus loin.
Maximum execution time of 360 seconds exceeded in
25 239 en 600 secondes
Encore raté...
Bon je vais pas me plaindre il va quand même plus vite que moi à la main, mais bon...

Bref, je viens de le relancer, logiquement il va mettre 15 minutes ou 20...
Le temps de réfléchir à d'autres choses...

17h53 : enfin j'ai les données sous forme de dump sql.
Sql a planté plusieurs fois, j'ai du recommencer à plusieurs reprises, mais bon finalement j'ai les données sur la France entière,
ouf.

Choses de la vie

23h23 : Bon, maintenant que j'ai les données géographiques, reste à savoir comment les exploiter.
En réalité, je ne pense pas tout utiliser.
Le découpage en communes ? oui, car ainsi chacun pourra signaler précisément son emplacement.

En fait en reregardant ce que j'avais écrit plus haut :
notamment ce lien là :
http://www.economie-touraine.com/territoires_indre_et_loire/communes_cantons.asp
Ca me donne l'idée suivante :
en mode de recherche poussée, l'utilisateur pourra choisir visuellement une zone comme les cartes que l'on voit sur la page.
Bref, il me faut les communes, les cantons et les arrondissements...

00h05 : :bonbonbon, commençons par filtrer par département, seul le 37 m'intéresse pour l'instant:
les communes
avant : 36 960
après : 277
Ah oui effectivement, ca vaut le coup ;)

les cantons :
avant : 4 036
après : 37

les arrondissement :
avant : 342
après : 3

Sauvegardons cette version light des données de l'insee.

Les données de l'insee ont la particularité de se recouper grandement !
Si en général j'évite de faire cela lorsque je conçois des tables sql,
ici, on peut tirer avantage de cette disposition qui offre du coup des facilités
pour la recherche.
Ainsi, mes tables commune, canton et arrondissement sont toutes liées intrinséquement,
je n'ai pas besoin de rajouter des liaisons mysql.
Les tables canton et arrondissement ne servent que de références pour récupérer un nom de canton ou d'arrondissement.

00h21 mise à jour du schéma de la bdd
screenshot12

00h46 : mise à jour du formulaire d'inscription réussie par rapport à la table commune : et ajout d'une vérification sur le pseudo :
le pseudo d'un utilisateur est maintenant unique.
Mais où sont mes codes postaux ? L'insee n'a pas fourni les codes postaux directement dans les tables que j'ai importées.

http://www.insee.fr/fr/regions/centre/default.asp?page=actualites/act_enquete/act_enquetes.htm

Quelque chose me semble insensé ici :
http://www.insee.fr/fr/regions/centre/default.asp?page=actualites/act_enquete/act_enquetes.htm#Indre-et-Loire

il est dit que la commune de tours a pour code postal
37261

Mais tout le monde d'attend à 37000.
Si j'y pense je contacterai l'insee pour voir ce qu'il en est.
Au pire pas de code postal pour l'instant (pas le temps de me les taper à la main = je suis une fainéasse), c'est pas bloquant.

Résumé de la journée :
Bonbon, je suis content d'avoir au final pu rappatrier les données de l'insee, même si j'ai mis un temps énorme.
Car ces données sont très complètes, j'ai même l'article qui correspond à la commune (LE, LA, L', ...)
et faites pas des personnes professionnelles.
Demain je vais pouvoir reprendre le cours normal de développement du site.
De mémoire j'en étais aux formulaires d'annonces : le gros du site.



                

**** 04-02-2010

08h13 : start

08h23 : l'inscription ajoute maintenant des données dans la table info_inscription.

08h51 : le système de connexion/déconnexion est en place et fonctionnel pour toutes les pages de moncompte.

09h02 : ajout de la table utilisateur_tan qui regroupe les informations d'un utilisateur spécifiques au système tours annonces.

09h18 : à la recherche d'un icône pour l'avatar par défaut, je tombe sur ca :
http://www.iconfinder.net/search/?q=iconset%3Avery_emotional_emoticons_lazy

10h07 : après avoir fait d'autres recherches, j'opte finalement pour ce set d'icônes :
users tours annonces
Je les ai achetées sur fotolia, et ils seront les user pas défaut de tours annonces.
Cela implique qu'il faut que l'utilisateur choisisse son sexe dans le formulaire d'inscription.
L'avantage est qu'on a déjà la donnée du sexe pour l'avenir : si on veut étendre le système de rencontres...
h cherche f ou f cherche h

11h00 : la page moncompte-profil est visuellement intégrée (avec des données factices)
screenshot4

11h39 : ajout de l'information sexe dans la table utilisateur.
L'inscription impacte maintenant les 4 tables info_inscription, compte_utilisateur, utilisateur et utilisateur_tan.
Lorsque le formulaire d'inscription est correctement rempli, le système choisit aléatoirement une photo en fonction
du sexe de l'utilisateur.

Je décide de réorganiser les données en fonction des tables sql, c'est plus logique pour moi,
et je suis conscient que certaines personnes ne vont pas comprendre intuitivement la logique,
et organiseraient les données différemment, cependant, si j'y gagne en clarté, c'est l'essentiel,
car tous les utilisateurs de Tours annonces bénéficieront indirectement de cette simplicité de conception.

12h23 : les informations de moncompte-profil sont calquées sur la base de données,
sauf :
Possède actuellement :
6 annonces en ligne
3 messages
1 commerce
screenshot5

pause

15h29 : le premier formulaire de modification de mon compte est fait : il permet de modifier le tel, le email et la ville.
La cinématique est la suivante : l'utilisateur clique sur le lien modifier, la page se rafraîchit avec le formulaire ouvert
en haut de l'écran grâce au système des ancres, l'utilisateur remplit et poste le formulaire, les erreurs apparaissent normalement
jusqu'à ce que l'utilisateur ait correctement rempli le formulaire.
Lorsque c'est le cas, le formulaire est remplacé par un message de confirmation qui dure 2sec (FORM_SUCCESSMESSAGE_TIMEOUT=2000).

16h03 : Ajout du bouton annuler dans ce formulaire, car c'est frustrant de pouvoir faire apparaître mais de ne pas pouvoir le faire disparaître.
Cinématique : lorsque l'utilisateur clique sur annuler, la page revien comme elle était avant, et avec les ancres.
J'avoue que la technique que j'ai employée est assez complexe, voire tirer par les cheveux, mais je n'ai pas trouvé mieux
et je ne voulais pas utiliser jquery juste pour faire ce petit truc.
La technique :
La propriété alt de mon bouton annuler contient le lien complet (avec ancre) de la page vers laquelle elle doit être rafraîchie.
J'aurais pu faire un lien, mais j'aurais alors perdu le côté bouton au niveau du design et les gens sont habitués aux boutons du web.
Voici ma fonction, appelée à chaque fois qu'un formulaire annulable est appelé.

window.onload = initPage;

function initPage()
{
    href = "";

    if(document.getElementById("unique-canceler"))
    {
        var button = document.getElementById("unique-canceler");
        href = button.alt; // variable globale pour une fonction ultérieure
        button.onclick = function(){
            window.location = href;
        };
    }
}


Sémantiquement, cela implique que l'on ne puisse ouvrir qu'un formulaire à la fois, autrement,
l'id "unique-canceler" ne serait plus unique.
C'est donc quelque chose à garder dans un coin de sa tête (même si en l'occurrence les effets ne seraient pas dramatiques),
et c'est pour ca que je n'aime pas trop cette technique, je préfère avoir la tête vide...


16h13 : En écrivant ce que je viens d'écrire, je me suis aperçu qu'il y avait un moyen que je préférais :
avec les classes au lieu des id.
Plus lourd dans mon code, mais moins dans ma tête ::

window.onload = initPage;


document.getElementsByClassName = function(cl) {
var retnode = [];
var myclass = new RegExp('\\b'+cl+'\\b');
var elem = this.getElementsByTagName('*');
for (var i = 0; i < elem.length; i++) {
var classes = elem[i].className;
if (myclass.test(classes)) retnode.push(elem[i]);
}
return retnode;
};


function initPage()
{
    href = "";

    var links = document.getElementsByClassName("submit-annuler");
    for(var i=0; i< links.length; i++)
    {
        var button = links[i];
        href = button.alt; // variable globale pour une fonction ultérieure
        button.onclick = function(){
            window.location = href;
        };


    }
}


Respecter une convention de nommage du début jusqu'à la fin.
C'est un truc que j'ai jamais réussi à faire, non mais quelle chèvre.
Mon idée est que tout doit être nommé en partant du plus général et en allant vers le plus précis.


17h49 : l'espace profil est opérationnel. L'utilisateur peut
changer son email, son tel, sa ville,
sa photo, et l'affichage de ses coordonnées sur ses annonces : juste son mail, juste son tél ou les 2.
Je suis assez satisfait de la cohérence des informations d'un formulaire à l'autre.
Ce n'est pas le bordel (pour une fois), enfin il me semble.
J'ai quand même un regret, c'est que les sessions qui me servent à gérer les photos,
ben j'arrive pas à les effacer facilement, donc je les laisse...
Pas très écologique mais bon, normalement elles disparaissent lorsque l'utilisateur ferme son navigateur.

screenshot6 : normal
screenshot7 : clic sur modifier de Me contacter
screenshot8 : Message de succès qui reste 2 secondes
screenshot9 : Deuxième formulaire en cours de chargement de photo


choses de la vie

22h37 : reprise :
Lorsque un gros problème est composé de plusieurs petits problèmes, j'aime bien attaquer le gros de la bête
en premier.
Occupons nous du système d'annonce alors.

A la base, une annonce est caractérisée par :
un titre, une description, un prix, une photo principale, une date, une ville.
Une annonce appartient à un utilisateur.
Une annonce appartient à une catégorie.

Concernant la date, ayant fait personnellement l'expérience de mettre des timestamp,
je trouve que ce n'est pas très pratique lorsque l'on regarde directement dans la bdd,
pour comprendre quoique ce soit, bien que ca soit assez simple à manipuler.
Cette fois j'ai envie d'essayer directement les datetime.
Une petite recherche sur google me fait penser qu'il y aura moyen de manipuler sans trop
de peine les datetime mysql (je pense à l'ajout de jours à une date par exemple)
http://www.careerride.com/MySQL-Date-Time-manipulation-functions.aspx

Parce que je ne tiens pas à ce que n'importe qui mette n'importe quoi sur mon site,
je mets en place un système de modération.
Toute annonce postée par un utilisateur sera modérée avant d'être rééllement mise en ligne.

Je vais reprendre mon ancien système pour le coup :
une table annonce_en_attente
et une table annonce_en_ligne.
L'utilisateur insère dans annonce_en_attente,
et à l'issue de la modération, en cas de validation, l'annonce est copiée dans annonce_en_ligne.
C'est un système assez lourd à gérer car on a deux jeux de données, mais bon, à défaut de mieux...
On aurait pu penser à la solution d'ajouter un état à l'annonce (en attente ou en ligne),
et ainsi n'avoir qu'une seule table, mais je trouve qu'on perd en clarté, donc non.

Nous ajoutons un champ statut à la table annonce_en_attente afin de matérialiser le résultat de la modération.
Bon si je travaille comme ca en expliquant tout je suis pas arrivé, même si je tape relativement vite mais
fopapoussémémé.

Pour l'instant la bdd ressemble donc à cela :
screenshot10

Bon essayons d'intégrer ca déjà, à mon avis j'aurais pas fini ce soir...

23h34 : le système de navigation dans la partie annonces est concu et fonctionnel.
screenshot11


Bon, il me faut des données sur les villes.
Certainement qu'un bon point de départ est ici :
http://www.insee.fr/fr/methodes/nomenclatures/cog/depreg.asp?codereg=24

Voilà qui est très intéressant :
http://www.insee.fr/fr/methodes/nomenclatures/cog/telechargement/2009/txt/canton2009.txt

Oups c'est carrément énorme.
J'aime bien ca me rassure, je pense que je vais prendre le temps qu'il faut pour intégrer cela,
peut être plusieurs jours, mais bon une fois que ce sera fait je me sentirais plus serein,
ou pas paske que j'ai pommé trop de temps à l'intégrer.
Bon on verra demain...

                

**** 03-02-2010

08h05 : start : travail sur le module arborescence
08h54 : le comportement modifier est fonctionnel, il inclut le déplacement des branches .
Pause 30 minutes
10h58 : Le système de suppression de catégories est fonctionnel, avec la cinématique suivante :
lorsque l'on clique sur l'élément de la liste que l'on veut supprimer,
une première requête est faite au serveur pour voir si la catégorie contient d'autres catégories.
Si c'est une catégorie orpheline autre que root, l'effacement est immédiat.
Si la catégorie contient d'autres catégories, une boîte de dialogue apparaît (impromptu) pour confirmer le choix.
Si c'est root qui est sélectionnée, root reste en place mais son contenu est vidé.

En cas d'effacement, un message de confirmation d'effacement s'inscrit sur la droite; la page est rafraîchie 1 sec plus tard.

Pause 30 minutes

12h48 : Le système de navigation par catégories est fonctionnel.
Pause

15h38 : L'importeur de catégories à partir d'un fichier texte est fonctionnel.
Seulement 2 niveaux sont gérés : principal et secondaire.
Voici un exemple de fichier (pour la syntaxe)

VEHICULES
	*voitures
	*motos
	*quads
	*scooters
	*camping cars
	*velos
	*bateaux
	*accessoires
	*buggy
	*utilitaires

IMMOBILIER
	*colocation
	*location
	*vente
	*achat
	*en vacances

EMPLOI
	*offre
	*demande

Seuls le caractère * et le saut de ligne sont importants.



16h46 : la page d'accueil de mon compte est intégrée, avec des données fictives.


17h09 : Mise en place du système de navigation pour l'espace mon compte, avec persistance de la couleur sur l'onglet en cours.

17h45 : Une mise en forme de base est conçue pour la base de données, le but étant de pouvoir inscrire un utilisateur. (schema1.png)
schema1.png

Choses de la vie...

01h16 : le formulaire d'inscription est opérationnel, à ceci près qu'il manque l'insertion des données dans la table info_inscription, la page inscription-successfull est intégrée.
screenshot1
screenshot2
                

**** 02-02-2010

Bon, mes yeux se ferment,
je dois aller me coucher,
pour résumer ma journée, ca c'est assez bien passé,
l'intégration de paiement : la demande de création du compte est en cours.
J'ai réussi à récupérer mes générateurs de méthodes, plus ou moins.
Et j'ai refait mon système de liste :
j'étais tombé dans le piège de l'objet à outrance :
tout encapsuler, et au final, mes objets étaient puissants mais bien trop spécifique
à un framework en particulier.
Je ne pouvais tout simplement pas les réutiliser, mon framework ayant trop évolué...
J'ai donc remis tous les paramètres à l'extérieur, en style procédural,
et je préfère nettement cette dernière approche,
facilement configurable,
réutilisable,
plus rapide.

En fait l'objet ce n'est pas trop pour moi, je ne l'utilise que dans certains cas.
Pour les listes, je vois cela en 3 objets ou phases :
le jeu de données (amené par une requête),
l'objet qui affiche le jeu de données,
le pagelink.

J'ai réussi à combiner les 3 dans un script modèle (à éprouver qui tend à me satisfaire pleinement : réutilisabilité, propreté du code)
pour l'admin, ce que j'automatiserais certainement une fois que je l'aurais éprouvé.

Actuellement, je refais mes méthodes d'insertion de catégories (nested model),
il me semble qu'il y a un bug dans le déplacement des branches, mais je regarderais demain,
là mon cerveau ne veut plus.

Le point fort de cette journée, mis à part la reconception d'un système de gestion de liste
avec pagelink et tri.
est l'amélioration de mon objet Ling_QuickTable
qui affiche le résultat d'une requête sous forme de tableau.

Avant cet objet utilisé d'autres objets que j'avais créé pour afficher les colonnes modifier, supprimer...
Maintenant, j'ajoute ces colonnes depuis l'extérieur, je suis indépendant,
et en plus ca va plus vite.
J'utilise pour cela vsprintf et je lui dis par exemple de se baser sur l'id de la colonne en cours.

Ah mais oui, j'oubliais, ici c'est mon serveur et pas le blog, je peux mettre du code !
Voici l'objet dont je parle.


< ?php
/*
 *  This is the Tours Annonces Project Licence
 * do What The Fuck you want to Public License
 *
 * Version 1.0, March 2000
 * Copyright (C) 2000 Banlu Kemiyatorn (]d).
 * 136 Nives 7 Jangwattana 14 Laksi Bangkok
 * Everyone is permitted to copy and distribute verbatim copies
 * of this license document, but changing it is not allowed.
 *
 * Ok, the purpose of this license is simple
 * and you just
 *
 * DO WHAT THE FUCK YOU WANT TO.
 *
*/

/**
 * Ling_QuickTable_Multiple.php
 *
 * @author Ling
 * 6 oct. 2009 08:59:07
 *
 * 02-02-2010 : ajout de setTrigger
 * retrait des fonctions addtrigger qui ancrent l'objet à une technique trop spécifique
 *
 * Changement de la méthode de construction de keys pour permettre de mettre plus facilement des
 * noms humains.
 *
 * Ajout de la méthode add column qui permet d'ajouter des colonnes rapidement,
 * en se basant sur les champs déjà existant
 *
 *
 *
 */
class Ling_QuickTable_Multiple extends Ling_QuickTable
{

    protected $keys;
    protected $extraColumn;
    protected $extraColumnFeederFields;


    public function __construct(array $dataArray)
    {
        parent::__construct($dataArray);
        foreach($this->dataArray[0] as $k => $v)
        {
            $this->keys[$k] = $k;
        }
        $this->extraColumn = array();
        $this->extraColumnFeederFields = array();
    }

    public function getArray()
    {
        $class = (!empty($this->class))?' class="' . $this->class . '"':'';
        $cpt = 0;


        $o = '';
        $o .= '< table'. $class .'>';

        if($this->title !== '')
        {
            $o .= '< caption>'. $this->title .'';
        }

        $o .= $this->header($this->keys, $cpt);

        $style1 = (!empty($this->oddClass))?' class="' . $this->oddClass .'"':'';
        $style2 = (!empty($this->evenClass))?' class="' . $this->evenClass .'"':'';
        foreach($this->dataArray as $k => $v)
        {
            $style = ($cpt%2===0)?$style1:$style2;
            $o .= '< tr'. $style .'>';
            foreach($v as $l => $w)
            {
                $o .= '< td>'. $this->renderField($l, $w) .'';
            }

            // ici, on traite les colonnes supplémentaires ajoutées par l'utilisateur
            // les champs indiqués par l'utilisateur sont utilisés comme arguments
            // de vsprintf pour la chaîne $format
            foreach($this->extraColumn as $m => $format)
            {
                $formatArgs = array();
                foreach($this->extraColumnFeederFields[$m] as $field)
                {
                    $formatArgs[] = $v[$field];
                }

                $o .= '< td>'. vsprintf($format, $formatArgs) .'';
            }
            $o .= '';
            $cpt++;
        }
        $o.= '';
        return $o;
    }

    public function __toString()
    {
        return $this->getArray();
    }

    public function header($keys, &$cpt)
    {
        $style1 = (!empty($this->oddClass))?' class="' . $this->oddClass .'"':'';
        $style2 = (!empty($this->evenClass))?' class="' . $this->evenClass .'"':'';
        $style = ($cpt%2===0)?$style1:$style2;



        $o = '< tr'. $style .'>';

        foreach($keys as $k => $v)
        {
            $o .= '< td>< b>'. $v .'';
        }


        $o .= '';
        $cpt++;
        return $o;
    }

    /*
     * Permet de définir des triggers en les passant sous forme de tableau.
     * Le format du tableau est :
     * array(nomChamp => htmlCompletDuLien)
     *
     * Le principe est que la configuration se fait de l'extérieur, afin que cet
     * objet de vue ne s'occuppe que de l'affichage.
    */
    public function setTriggers(array $array)
    {
        foreach($array as $k => $v)
        {
            if(array_key_exists($k, $array))
            {
                $this->keys[$k] = $array[$k];
            }
        }


        return $this;
    }


    /*
     * Méthode qui permet d'ajouter simplement de nouvelles colonnes,
     * $columnName est le nom de la colonne
     * $format est le format utilisé par vsprintf
     * et
     * $feederFields contient le tableau passé en paramètre de vsprintf
     *
     * Si ce dernier tableau est vide,
     * la chaîne format est ajoutée telle quelle
    */
    public function addColumn($columnName, $format, $feederFields=array())
    {
        //vérification de la cohérence des chmaps demandés dans feederfields
        if(!empty($feederFields))
        {
            foreach($feederFields as $v)
            {
                if(!array_key_exists($v, $this->keys))
                {
                    throw new Ling_Exception("La clé $v n'existe pas!!!");
                }
            }
        }


        $this->keys[$columnName] = $columnName;
        $this->extraColumn[$columnName] = $format;
        $this->extraColumnFeederFields[$columnName] = $feederFields;
    }
}



et son papa :

< ?php
/*
 *  This is the Tours Annonces Project Licence
 * do What The Fuck you want to Public License
 *
 * Version 1.0, March 2000
 * Copyright (C) 2000 Banlu Kemiyatorn (]d).
 * 136 Nives 7 Jangwattana 14 Laksi Bangkok
 * Everyone is permitted to copy and distribute verbatim copies
 * of this license document, but changing it is not allowed.
 *
 * Ok, the purpose of this license is simple
 * and you just
 *
 * Lazy man, I am
 *
 * DO WHAT THE FUCK YOU WANT TO.
 *
 */

/**
 * Ling_QuickTable.php
 *
 * @author Ling
 * 30 sept. 2009 16:49:02
 *
 */
class Ling_QuickTable
{
    const DEFAULT_BACKGROUNDCOLOR1      = '#abc';
    const DEFAULT_BACKGROUNDCOLOR2      = '#def';
    const DEFAULT_TRCLASS_ODD           = 'odd';
    const DEFAULT_TRCLASS_EVEN          = 'even';



    protected $class;
    protected $dataArray;
    protected $evenColor;
    protected $fx;
    protected $image;
    protected $evenClass;
    protected $pageParam;
    protected $oddClass;
    protected $oddColor;
    protected $title;
    protected $type;
    protected $useLROTrigger;
    protected $LROObject;


    public function __construct($dataArray)
    {
        $this->class = '';
        $this->dataArray = $dataArray;
        $this->evenClass = self::DEFAULT_TRCLASS_EVEN;
        $this->evenColor = self::DEFAULT_BACKGROUNDCOLOR2;
        $this->fx       = array();
        $this->image = '';
        $this->title = '';
        $this->useLROTrigger = false;
        $this->LROObject = null;
        $this->oddClass = self::DEFAULT_TRCLASS_ODD;
        $this->oddColor = self::DEFAULT_BACKGROUNDCOLOR1;

        if(!is_array($dataArray))
        {
            $this->dataArray = array();
        }

        return $this;
    }





/*****************************************************************************/
// MAGIC
/*****************************************************************************/

    public function renderField($fieldName, $fieldValue)
    {
        $fieldValue = htmlspecialchars($fieldValue);
        if(isset($this->fx[$fieldName]))
        {
            $fieldValue = $this->fx[$fieldName]['value']->result($fieldValue);
        }
        return $fieldValue;
    }

    public function fx($effectName, $fieldName, $options=array())
    {
        $this->fx[$fieldName] = array();
        $fx = new Ling_QuickTable_Fx($effectName);
        $this->fx[$fieldName]['value'] = $fx;
        return $this;
    }


/*****************************************************************************/
// SETTERS
/*****************************************************************************/
    public function setClass($className)
    {
        $this->class = $className;
        return $this;
    }

    public function oddColor($color)
    {
        $this->oddColor = $color;
        return $this;
    }

    public function evenColor($color)
    {
        $this->evenColor = $color;
        return $this;
    }

    public function oddClass($className)
    {
        $this->oddClass = $className;
        return $this;
    }

    public function evenClass($className)
    {
        $this->evenClass = $className;
        return $this;
    }

    public function cssStyleMode($mode)
    {
        if(!in_array($mode, $this->cssStyleMode))
        {
            throw new Exception("cssStyleMode not allowed");
        }
        $this->cssStyleMode = $mode;
        return $this;
    }

    public function title($title)
    {
        $this->title = $title;
        return $this;
    }
}


Je ne vais pas vous donner tout mon code non plus, sinon vous l'exploiteriez avant moi, mais bon,
c'est mieux que rien non?

Bref, j'arrête mon monologue intérieur de fin de journée, demain sera un autre jour.
Le jour où j'aurai fini ce module arborescence, un des piliers de mon système.



Hélas j'ai du mettre des espaces sur les balises html de mon code sinon, ca serait interprété en html direct.




                

**** 01-02-2010

01-02-2010
Je viens de remarquer ceci :
faire l'addition 99 + 32
Si on essaie directement d'additionner les 2 nombres c'est assez difficile (pour moi),
par contre en faisant rapidement 100 + 32 puis 132 - 1, c'est nettement plus facile.
Au final je vais plus vite à faire 100 + 32 - 1 que 99 + 32 !
Evidemment j'ai fait plus de calculs (2 au lieu de 1), mais le résultat est venu plus rapidement.

Tout est question de la technique utilisée.

Finalement, je vais utiliser la technique du 960 gs,
c'est plus lourd au niveau du html, quoique moins que les tables quand même,
mais la facilité d'utilisation dont on bénéficie vaut le coup, car je vise le long terme,
la réutilisation et le remaniement.

cocalane
Blasé, j'ai l'impression de pédaler dans la semoule avec les polices, je lâche l'affaire, je perds trop de temps :
les polices sont baveuses, ca m'horripile.
On laisse les polices systèmes pour l'instant sur les menus et les boxhead, tant pis, on avance...
cocalane

Moi qui ne voulait pas faire de compromis avec le css et le design,
non seulement j'utilise le 960gs, mais en plus je fais quelques compromis de sémantiques pour ie7,
notamment pour afficher une puce toute con;
pour moi sémantiquement c'est un élément textuel, mais comme le • est tout pourri,
on doit le remplacer.
Je pense que
La suite de mon texte
est le plus correct comme solution de remplacement à une image de puce trop moche,
plutot que
La suite de mon texte
Bref, mais pour ie7 la première soluce ne marche pas tout de suite, j'ai donc fait
La suite de mon texte
ce qui revient à dire que la puce est une image de fond.
Espérons que c'est le dernier compromis que je fais, sinon je vais mourir.

En jetant un coup d'oeil par curiosité sur ie6 c'est un cauchemar,
mais connaissant ie6 ca aurait pu être largement pire.
De toutes façons ce navigateur ne m'intéresse plus.
niarf


Allez encore un ptit compromis :
le css place tout en float, donc du coup pour le bottom de mon site, je mets un 

juste avant pour stopper le flux du float; sinon, le margin top est inefficace sur ffox et chrome.
C'est un compromis que beaucoup de webmasters font sans même se poser la question,
on va dire que celui là est le plus répandu donc pas vraiment de remords sur cela ;)

Et allez encore un : le même :
 mais après le div#bottom,
histoire d'avoir la couleur de fond jusqu'au bas du site.
Rhaîeaîeaîea...


Bon ca y est fini intégration page d'accueil,
maintenant il faut faire la page d'inscription :
inscription = bdd utilisateur
Je vais commencer par ce qui m'embête le plus, la gestion des catégories.
Je l'avais déjà fait il y a quelques mois, mais je vais le refaire avec mon nouveau miniframework, afin que ca soit réexploitable par copier coller.
Le système de tours annonces utilisera les nested categories, c'est plus rapide quand on a un grand nombre de sous catégories,
et cela va être le cas, puisque je vais intégrer les modèles et marques de voitures dans l'arborescence.
Du coup ca veut dire qu'il faut que je fasse mon admin...


Bon, résumé d'ajourd'hui, j'ai intégrer le css de la page d'accueil,
c'est bon je me suis remis le 960gs dans les doigts, ca c'est bien.

Par contre je m'étais construit un générateur d'administration à partir des tables sql, mais il faut que je le mettes
à jour parceque mon framework évolue très vite et que ce que j'ai construit il y a 2 semaines est déjà périmé.
Mauvaise conception certes, mais je fais ce que je peux.

Par contre demain il faut que j'intègre le paiement en ligne pour le site XXXXXX, j'ai reçu le mail de l'assistant technique.
On verra...

Voici le rendu visuel finalement en local :
rendu en local

                

**** 31-01-2010

Ce matin, avant de me lever,
je réfléchissais à un moyen de mettre en page un annuaire de commerçants :
un moyen qui me semble le plus logique, et qui soit pratique pour moi.
et j'ai trouvé qu'une carte à la google map : une carte vue de loin avec tous les petits points
rouges était une bonne idée de base;
après, l'utilisateur doit pouvoir filtrer le type de commerce qu'il souhaite visionner,
mais par défaut tous les commerces s'affichent.

Du coup ca m'a fait penser à autre chose : une idée révolutionnaire au niveau du système d'annonces :
le mode map :
la même chose mais pour les annonces!
Imaginez que vous vous balladez sur un site d'annonces sans trop avoir d'idées :
vous avez une vue globale sur la totalité des annonces avec leur répartition sur une carte : hyper pratique.
Personnellement pour moi je prendrais en priorité ceux qui sont plus proches de chez moi.
Imaginons que le système me propose de filtrer les annonces proches de chez moi
(ca ca existe déjà mais bon visuellement avec une carte c'est plus parlant).
C'est du toutbon.

Bref, par contre, pour ne pas dépayser les gens, il vaut mieux dans un premier temps laisser les modes traditionnels
de style web et style journal cf.30-01-2010.
et ajouter le mode map.

Voilà, et comme tout idée géniale, cela ne reste qu'une idée.

En réfléchissant 10 secondes sur l'intégration, je sais qu'en partant de rien je peux faire le système,
mais j'ai envie d'utiliser google map, si ca ne plante pas trop :
inconvénients :
1. le système est DEPENDANT de google map.
2. le système sera plus lent qu'un système développé en interne (c'est mon estimation personnelle) en terme d'affichage.

avantage :
je bénéficie des évolutions et mises à jour de google map
moins de prise de tête pour la création de la carte

A noter que j'ai regardé sur Tours, la ville est déjà quadrillée en mode street view.


Tout cela semble très intéressant, on verra si je vais le faire,
mais je préfère garder un système de sauvetage sans mode map et mettre mode map comme juste un mode optionnel
plutôt que comme feature principale pour le moment, même si ca serait un coup énorme vis à vis de la concurrence.

Comme toute idée elle vous appartient à partir du moment où vous en avez conscience,
j'en suis conscient mais je suis partageur, c'est ma nature.

Bon, je retourne au design de mon site, notre site...


Anecdote :
en cherchant carte indre et loire dans la partie images de google, je suis tombé sur le carte que j'avais
faite pour tours annonces : talfi le facteur :
http://images.google.fr/images?hl=fr&source=hp&q=carte+indre+et+loire&um=1&ie=UTF-8&sa=N&tab=wi
Mdr.


Je suis tombé sur une carte qui en fait m'a donné une nouvelle idée pour l'intégration du mode map :
sans google map : c'est à dire pas de zoom, ni déplacement :
une carte "à la leboncoin", mais juste sur le secteur indre et loire, je l'ai trouvée elle m'inspire.
Les avantages sur Google map :
rapidité d'éxécution
stabilité de l'application (de temps en temps il y a des pb d'affichage avec google map sur un de mes sites).

En fait je pense que c'est moins bien que google map mais bon c'est plus sympa car plus personnel.
Peut être le top du top serait d'allier les 2...

En fait je viens de me rendre compte que le système est déjà en place par google,
il suffit de taper commerces dans google maps.
whoa, bluffant.

Bon, je ne pense pas que quiconque qui n'est pas milliardaire puisse rivaliser avec l'application de google dans un futur proche.
Leur application Google map est terriblement puissante, c'est super.
Je vais donc dans un premier temps me rabattre sur mon système classique par défaut, et je verrais dans un 2ème temps si j'arrive à exploiter une partie de leur puissance.

Je me rabats donc presque de force sur une carte "à la leboncoin" mais régionale.


J'ai trouvé un truc très bien fait :
http://www.economie-touraine.com/territoires_indre_et_loire/communes_cantons.asp



Concernant la page perso d'un commercant, je reviens à l'essentiel.
info générale, plan, photos.

En observant la version actuelle de Tours annonces, j'ai remarqué que si elle était relativement bien référencée,
la conception était à chier (dans le sens où même moi ca me saoûle grave de faire une amélioration de cette version
tellement c'est mal conçu), et c'est mal conçu car j'ai fait des compromis qui n'ont pas lieu d'être, tout ca pour
gagner du référencement.

Maintenant, j'ai compris qu'il vaut mieux rester pur, quitte à être moins bien référencé, voire pas du tout.
Ce qui compte c'est de savoir ce que l'on veut et de savoir ce que l'on fait.
Je ne suis pas google, ce n'est pas mon boulot de référencer.
Je fais mon site point barre. Google se démerde c'est un grand garçon.
Evidemment, de mon côté en tant que webmaster consciencieux, je m'arrange pour que sémantiquement mon site soit au top,
qu'il soit accessible, etc...
Mais plus de compromis comme j'ai fait du genre mettre le mot tours à côté de chaque catégorie.
Rien à branler.
De même, pas de formulaire en post pour un moteur de recherche, c'est pas fait pour ca, le get est plus approprié.
Bref, je me range du côté des développeurs, chacun son boulot.
Moi je conçois des services.

D'ailleurs l'espace perso des commerçants sera mon coin privilégié de développement de services,
car ce sont eux qui me paieront.
Pour l'instant que des services basiques, infos, plan et photos, stats pour le commercant, qu'il pourra partager
ou non, mais par la suite, boutique en ligne, video...
Très intéressant j'ai hâte d'y être mais continuons.

Petite idée pour les commercants,
dans la partie photos, pour l'instant ils n'ont pas le choix, c'est galerie basique,
mais ils auront le choix : jquery slider ...


Bon, maintenant, petite réflexion avant de commencer le design des formulaires intéressants :
ceux de mon compte.

Tout d'abord, un utilisateur est global :
il peut avoir des annonces comme des commerces
= un seul compte pour tous les services que je propose, c'est plus simple.
Avantage : mon bénéficiaire (client ou utilisateur) bénéficie de tous les services que je développerai ultérieurement sans
avoir à recréer un nouveau compte.
J'aime bien ce principe de centralisation.

Par rapport aux annonces, que peut faire le utilisateur :
ajouter une annonce,
il y 5 grandes catégories :
objets, rencontres, services/emploi, immobilier, véhicules
Si il y a une sous catégorie, cette sous-catégorie s'affiche etc...
Par exemple, il sélectionne véhicule, puis voiture, puis renault etc...

Pas besoin de laisser la possibilité d'afficher son mail ou son tel pour CHAQUE annonce,
l'utilisateur affiche son mail ou son tel sur toutes les annonces en même temps, question de simplicité de gestion
et de performances.
Cela doit être marqué explicitement, afin qu'on ne me casse pas les couilles :

Sur toutes mes annonces afficher :
1. mon mail
2. mon tel
3. mon mail et mon tel

coqalane

J'ai déjà un système de points les tao.
Certains utilisateurs en ont déjà beaucoup, je dois aller de l'avant,
il faut que ces points leur servent et qu'ils les utilisent.
Personne ou presque a compris le système de pub de la version précédente.
lol

Je vais remettre ca au goût du jour.
Pour l'instant je prévois juste une case.

Pour les détails sur les annonces véhicules et immobilières,
étant donné mon manque de connaissance en la matière,
j'irais me renseigner en temps et en heure sur les sites de véhicules et immobilier,
disons la centrale et pap.

Mais ce n'est pas bloquant pour l'instant.

Petite idée pour que les gens comprennent qu'ils peuvent dépenser leur tao,
et qu'ils le fassent : le taostore :
une boutique qui présente les différents "produits" tours annonces.

cokalane

Pour la partie commerces, l'ajout de la fonction "envoyer un message" est intéressante.
Cela permet à un utilisateur de profiter du confort d'un formulaire pour faire une demande
à un commerçant précisément.

kokalane

Dans la série je rajoute une fonctionnalité de base qui n'est pas vraiment de base :
le taostore : l'interface des commerçants leur permet d'ajouter leurs promos et cadeaux directement
dans le taostore sans passer par ling.
Evidemment il faut qu'ils en voient l'intérêt.
Admettons qu'ils le voient, car nous mettrons en place un système qui récompense en fonction de la valeur
réelle du prix offert.
La récompense sera une forme de visibilité accrue sur le site,
seule chose que je peux offrir pour l'instant.

Bon, j'ai plusieurs idées pour la suite, mais je ne peux pas tout réaliser en même temps.
Il est 23h01, je suis un peu las comme tous les soirs,
mais j'ai fini la maquette graphique du système de base.

Je commence l'intégration dès maintenant.
Je parle de l'intégration du design : le css pour être précis,
et comme je l'ai dit plus haut, pas de support pour ie6, du coup
mon intégration devrait être largement plus rapide.

pause

En fait j'vais m'coucher, pas productif...

Résumé de la journée :
6-commerce
7-commerce-liste
8-commerce-espaceperso-accueil
9-commerce-espaceperso-photos
10-commerce-espaceperso-plan
11-commerce-espaceperso-stats
12-contact
13-moncompte-accueil
14-moncompte-profil
15-moncompte-annonces-liste
16-moncompte-annonces-ajouter(1-3)
17-moncompte-annonces-ajouter(2-3)
18-moncompte-annonces-ajouter(3-3)
19-moncompte-commerces-liste
20-commerce-espaceperso-envoyer-message
21-moncompte-messages
22-taostore

En fait j'ai pas du tout fait les formulaires, ni le plan de pages et d'autres pages...
Mais ca constitue une base suffisante pour moi pour intégrer et même développer.

Par contre je ne suis pas du tout sûr du coup de "mélanger" les commerces et les annonces dans mon compte.
Ne valait -il mieux pas faire deux comptes séparés, cela ferait plus crédible vis à vis des commerçants.
Oui, mais il est plus simple d'avoir un compte Tours annonces pour tout gérer.
Les commercants, je les démarcherai moi même.
Que vont dire les commercants lorsqu'ils verront que tout le monde a la possibilité d'ajouter un commerce,
ils vont dire que c'est n'importe quoi !
Oui, mais je contrôlerai chacun des commerces qui tente de s'inscrire.
Evidemment j'admets que c'est plus pro de séparer le compte annonce et le compte commerce,
cela pourrait même générer plus de bénéfices au niveau argent,
mais je préfère le côté simple d'avoir un compte par personne.
C'est le plus logique pour moi.


Je pense que certains diront qu'il y a régression par rapport à la version précédente,
le truc c'est qu'ils ne voient pas le code.
Le code de la version précédente me fait gerber pour rester poli,
c'est comme ie6, ca devrait pas exister.
Impossible d'évoluer avec le code de l'ancienne version, c'est la boucherie,
les pieds dans la merde, d'où mon enlisement d'ailleurs.

L'espoir de cette nouvelle version est un code nettement plus clair,
même si je ne reste qu'un développeur du dimanche,
une bonne organisation est toujours la clé du succès à mon avis.

Qui dit code plus clair dit application plus réactive, évolutions plus faciles.
La réactivité, un autre mot clé extrêmement intéressant.

                

**** 30-01-2010

Le site sera accessible
http://www.accessibilite.org/avantages.php
http://www.siteduzero.com/tutoriel-3-31856-faire-un-site-web-accessible.html
http://www.w3.org/TR/WCAG10/

Je vais peut être utilisé le 960.gs
Au début, j'étais réfractaire, car je pense que le marquage html est intense
et qu'il peut être largement réduit si il est codé à la main.
Mais après réflexion j'ai pas envie de me prendre la tête :
en cas de remaniement intensif du site, le 960 framework offre une rapidité de remaniement
inégalée, ce qui peut être un avantage encore plus grand, d'autant plus que le site sera amené à évoluer
pour ainsi dire en permanence.
Donc pas de prise de tête.


D'ailleurs pour le design pareil,
quelque chose qui me correspond : simple et personnel,
efficace dans les fonctions, le design n'est pas ma priorité.

L'avantage d'avoir un design moche : on se concentre plus rapidement sur le contenu.
2 ème avantage, lorsque l'on change de design c'est moins pénible.

Autre truc, à propos de ie6n, je crois que je vais franchir le pas :
j'ai vu sur un joomla récemment une page qui ne s'affiche que si c'est ie6 et qui dit
"mettez votre navigateur à jour et téléchargez ie8", en gros.
Cela revient à dire nous n'offrons pas de support pour ie6.

Si on s'en réfère aux stats du W3c :
http://www.w3schools.com/browsers/browsers_stats.asp

Il y aurait encore un peu plus de 10% des internautes qui utilisent ie6.

En tant que webmaster consciencieux, je suis habitué à dealer avec les bugs d'ie6,
mais là, je crois que c'est une opportunité de franchir un pas et de dire :
Cette putain de bouse de merde de ie6, on en veut plus : à la poubelle.

Evidemment cela ferme la porte à 10% d'entre nous direct, ce qui n'est pas négligeable.
Mais combien de temps faut il à un internaute pour faire une mise à jour,
comparativement au temps qu'il faut pour un webmaster d'adapter son site juste pour ie6.

La mode c'est que son site soit adapté pour tous les navigateurs,
mais en fait cela ralentit le processus d'éradication de ie6.
Je sais que peu de webmasters oseront franchir le pas à l'heure actuelle.
Personnellement, j'en ai rien à branler maintenant,
il faut vivre avec son temps, et j'ai pas envie de faire des compromis au niveau du css,
enfin pas ceux que l'on fait avec ie6.

C'est peut être un boomerang qui me reviendra en plein dans la gueule, rien à branler.
J'aime pas ie6, c'est une vraie misère pour les webmaster, ca devrait pas exister.
Bref, vivement le css3 et le html5 et vivement l'éradication de ie6,
A moins d'un changement de dernière minute de ma part, Tours annonces n'offrira AUCUN support
pour ie6.


Pour l'instant, je pars dans l'optique minimaliste de refaire le site fonctionnellement égal
à la version actuelle, l'idée est de développer les évolutions dans un SECOND temps.
Donc actuellement, nous avons le système d'annonces, commerces et web.
Quelques pages intéressantes comme l'historique, les news.

Les pages de visites seront sûrement supprimées car pas très intéressantes, un système de stats moins détaillé
suffira, je pense aux performances générales en écrivant cela.

De la même manière j'ai une mauvaise expérience avec l'envoi de mails,
le résultat d'un envoi est très alétoire actuellement et je n'ai pas l'impression de contrôler quoique ce soit.
C'est pourquoi pour cette nouvelle version, pour l'instant, je préfère limiter au maximum les envois de mails qui se
font par le serveur.
Ainsi, sur le détail d'une annonce je ne mets pas d'option envoyer à un ami ou même envoyer un message à l'annonceur,
mais plutôt je laisse aux internautes le soin d'appeler directement les annonceurs, à l'ancienne quoi.
Evidemment si j'ai le temps, la chance ou l'opportunité de travailler sur un système de mail fiable,
je remettrai cette fonctionnalités, afin de ne pas faire moins que la concurrence.


Pour la partie forum, je n'ai pas trop d'idées sur la question, c'est juste intéressant techniquement de développer un forum,
pour moi, car je ne l'ai encore jamais fait, et j'aimerais bien voir comment ca marche,
après concrètement je risque peut être d'être le seul visiteur de mon forum,
bon ok je prends le risque pas grave,
je veux juste faire un service fonctionnel.
Pour l'instant j'ai pas d'idées au niveau du design, je continuerai plus tard.

Maintenant je suis fatigué.

Pour les annonces, je vais faire 2 styles, un style web, et un style journal.
Le style journal, j'en profite pour caser un délire que j'avais en tête depuis la première version de Tours annonces et qui me chatouillait,
aujourd'hui, avec mon rien à branler nature,
je suis heureux de pouvoir mettre cela en place : il s'agit de mettre les annonces dans le format journal,
le défi était d'en caser un maximum par page, tout en gardant une lisibilité correcte.
2 annonces par ligne j'ai essayé sans succès, une ok.
Mon délire c'est de mettre un fond en journal pour simuler un vrai journal d'annonces,
et de mettre une police qui correspond.

Résumé du travail de cette journée :
Avancée sur la charte graphique, doucement tranquillement.
maquette de
1-la page d'accueil
2-annonce-style web
3-annonce-style journal
4-annonce detail
5-forum


Demain sera un autre jour.