ToursAnnonces.fr

Tours annonces est un ensemble de services conçus pour vous faciliter la vie au quotidien : petites annonces, emploi, annuaires, services et bien + ...

Inscrivez-vous Vous êtes nouveau ?
Vous avez un compte ?
Aide

Le carnet de bord du webmaster

Passez votre chemin c'est mes notes ici...

07 | 31 | 01 | 19 | 20 | 04 | 32 | 10 | 11 | 21 | 34 | 16 | 36 | 17 | 30 | 18 | 28 | 14 | 29 | 08 | 06 | 03 | 27 | 25 | 22 | 05 | 09 | 02 | 13 | 15 | 12 | 23 | 26 | 24 | 33
**** 03-05-2010
07h15 : start

C'est marrant, je ne me sens pas fatigué,
faisons vite fait un petit calcul :
hier j'ai dormi :
1h34 + 2h30 + (7h15 - 4h46)
= environ 6h30.
Ah ben oui normal.

Mais disons que j'ai réparti mon sommeil différemment.

Commençons mon programme sysadmin jusqu' à 09h30.
Et après course. il me faudra des pates du fromage.
Des oeufs, du lait de l'eau, des ptits dej, des tomates,
des biscottes, des yaourts.

Ah ben non en fait je vias essayé de réparer ma voiture (le retour), apparemment il fallait forcer malgré 
l'electricité.

Et du coup je fferais à carrefour et donc chaussures sport

Ical est une application qui me permet de mettre en place ludiquement mon organisation.
Il y a des alarmes programmées.

Bon aujourd'hui, je n'applique pas le planning car c'est une journée spéciale = c'est à dire qu'elle ne respecte pas strictement le planning car je dois aller faire des courses,
mais sinon mon planning pour ce mois ci :

…
07h 09h30 : sysadmin
09h30 13h : tours annonces
13h 14h : musique
14h 18h : tours annonces
18h 19h : sport
19h 21h : joomla
21h 23h : maya
...

Alors évidemment comme c'est très strict et surtout ça ne me laisse pas beaucoup de temps de travail sur Tours annonces je me trouverais mille excuses pour ne pas le respecter, comme
la règle qui dit que si le planing n'est pas respecté strictement, alors il n'est pas valable pour la journée.

Grâce à cette astuce, je peux donc gérer des exceptions ;).

Deuxième règle qui m'arrange: si il fait pas beau le sport peut être annulé.

Et voilà, hormis que ma vie est maintenant une grande todoliste,
cela aura normalement pour effet qu'à la fin du mois j'aurais progressé dans tous les domaines désirés.

Enfin testons cela.


Go.


09h26 : hey kool, je viens de recevoir une notification comme quoi
le bug que j'ai reporté pour améliorer netbeans a été enregistré :

http://netbeans.org/bugzilla/show_bug.cgi?id=185297
Ca se trouve ils vont même corriger ce bug, ça serait trop kool.

Enfin ce n'est pas un bug, mais juste une suggestion d'amélioration.

09h30 : résumé: j'ai envoyé un mail grâce à mailx
echo "test" | mailx -s "sujet du mail" root

Et grâce à la configuration de postfix,
j'ai pu vérifier en utilisant maildir que le fichier arrivait bien à l'endroit prévu :
/root/Maildir/new/

C'est déjà un énorme pas pour moi. happy.

Allons changer la batterie et nous prendre ce coup de jus, puis les courses.

10h24 : bon, j'ai bien mis la batterie, mais entretemps, elles s'est redéchargée.
J'ai fait les courses, mais pas de chaussures de sport.
Bref, la suite, svp…


Formulaire ajout photo : loader ajax
Loader ajax
Ajouter un loader ajax pour le chargement des photos. 

Effectivement, désagréable d'attendre sans savoir ce qui se passe lorsque l'on met des photos.
Lorsque l'on est sur une bête de bécane, le temps d'attente et si court que l'on pourrait largement se passer
d'un loader, mais sur le serveur actuel, on a le temps d'attendre, c'est plus sympa d'avoir le loader.

Parenthèse, j'espère que l'on pourra bientôt utiliser le nouveau serveur, qui pour info a autant de bande passante que celui actuellement, mais au niveau processeur est largement plus rapide.
6x plus rapide pour php ;)
Il y a néanmoins encore certains points que je dois régler, et pas des moindres, d'où mon entraînement
sysadmin.

Je ne peux rien promettre, mais dès que cela sera possible, j'hébergerai Tours annonces sur des serveurs
plus performants.

Pour l'ajax loader, il y en a déjà un qui est fait sur le changement de photos dans mon profil,
voyons voir si c'est simple de repiquer..


Oups, je m'aperçois d'un bug au passage, la liste des villes affichées pour la modification du profil :
c'est la liste des villes de France, et non pas de la région, et en plus ya pas les codes postaux…
Résolvons d'abord cela.
11h00, le bug est corrigé, ça va nettement plus vite…


Mouais, en gros, le loader est déjà présent dans le code html, et les requêtes ajax le font apparaître 
ou disparaître suivant l'action réalisée…

Le loader doit disparaître sur les événements
onAuImageLoaded
et
showAuImageError

Il est initialisé avec :
$(".ajaxloaderCtn").css("display","none");

et apparaît sur le onchange :
$(".ajaxloaderCtn").fadeIn();

11h08 : et hop, voilà le travail pour le formulaire d'ajout d'annonces.
Bon le loader apparaît complétement sur la droite, mais c'est pas horrible,
et au moins il rentre pas en conflit avec l'affichage des vignettes chargées, donc je laisse comme ça.

Faisons la même chose pour l'ajout d'un commerce…



*********** Bribes à copier coller ***************
1.
Formulaire :

$form->setControl('free', 'ajaxloader')
        ->setContent('
ajaxloader
');
$form->elementTagReplace(Ling_Form::ELEMENTTAG_ALL_BEGIN, '
', 'ajaxloader'); 2. $fieldset1 = new Ling_Form_FieldSet('Paramètres et autres données', array( $controlName, 'ajaxloader', 'affichage_mailtel', 'ns2mail', 'id_traitement', )); 3. $(".ajaxloaderCtn").css("display","none"); $(".ajaxloaderCtn").fadeOut(); $(".ajaxloaderCtn").fadeIn(); *********** Fin de Bribes à copier coller *************** 12h01 : Ca y est, mais le problème était qu'il y avait deux containers de photos sur ce formulaire, et je n'ai pas trouvé d'autres solutions que de dupliquer ma fonction javascript, grrr, startbehaviour, certainement parceque je manque de connaissances dans ce domaine là, mais là pas le temps d'apprendre, vu que le but n'est pas extraordinaire… Par contre, j'ai pu déceler un autre bug :… quand je charge une image dans le premier container, celui de la photo principale, et que j'appuie sur f5, un deuxième lien supprimer apparaît! Ahben non ça le fait plus, certainement des résidus pendant que j'étais entrain de tester… Bon passons aux autres formulaires, ça devrait aller plus vite… Bon sang, il y a encore des bugs au niveau de l'activation du compte_vendeur, honte sur moi. Il me faut absolument une doc sur ça, ça ne peut plus durer;.. L'heure est grave, ce bug là n'aurait pas du être. De même qu'une personne qui scie une planche de bois regarde la trajectoire et pas sa scie, je n'ai pas besoin du code pour coder, mais juste de savoir ce que je dois coder. Autrement dit, la doc est LE document de référence, et il doit être béton; Ah non en fait, c'était bon c'était une grosse parano pour une erreur de rien du tout, comme d'hab… Ceci dit, je veux une doc… Et en même temps que je fais la doc , j'ajoute les loaders... Le système de commerce sur Tours annonces : 12h53 : ajout du loader pour le formulaire d'ajout de promo 12h56 : ajout du loader pour le formulaire d'ajout d'événement 13h03 : correction du formulaire d'ajout d'événement qui affichait toutes les villes de France. 13h06 : ajout du loader pour le formulaire d'ajout de cadeau Bon, en guise de doc, j'ai trouvé un document qui résume la situation, c'est ce dont j'ai besoin, pas besoin de faire plus pour l'instant. sch-storevendeur.png Il manque peut être une ou 2 explications mais bon, on va pas chipoter, j'ai déjà assez de retard. Un compte vendeur est en fait un terme abstrait et commercial. Le compte vendeur permet de vendre sur Tours annonces. Le compte vendeur permet d'accéder aux services privilégiés sur Tours annonces. Ca c'est la tchatche commerciale. Maintenant la partie technique : Un utilisateur possède 1 commerce. Ce commerce peut posséder DES promos. Ce commerce peut être lié à DES événements. Un store vendeur est lié à DES produits. Les petites notes supplémentaires : le type de store_vendeur peut être : admin, utilisateur, commerce. Concrétement, seule la valeur commerce est utilisée. La couche commerciale ajoute des règles invisibles sur le schéma tel quel : à savoir que pour bénéficier des 3 possibilités (ajout de promo, ajout d'événement, ajout de produit(actuellement nommé cadeau TAO)), un commerce doit être lié à 1 store vendeur (compte vendeur). Lorsqu'il le fait, une entrée est inscrite dans store_vendeur, avec : type = 3 (commerce) vendeur_id = id du commerce Voilà, je crois qe j'ai tout dit. 13h19 : Passons au formulaire d'ajout de site/blog 13h21 : ok. Il doit me rester le formulaire d'ajout de photos sur les événements d'un commerce, et je pense que c'est fini après. Ben en fait ce formulaire est un peu spécial, je ne le fais pas tant pis. (bou, remboursez, remboursez … tais toi maraud, c'est gratuit.) La suite svp : Formulaire inscription : 2 améliorations Faire en sorte que le formulaire reconnaisse automatiquement la disponibilité du pseudo (en cours de frappe) ainsi que le niveau de sécurité du mot de passe (faible, fort, ...) Dans la série "j'te mets une tâche pas très utile vers le haut de la todolist" … Pfff, bon, ne cherchons pas la petite bête codons, c'est tout. Commençons par le pseudo, à chaque fois que l'utiisateur clique sur une touche du clavier lorsque le focus est sur le input du pseudo, une requête ajax doit être envoyée à un script "disponibilite-pseudo.php" (un webservice supplémentaire). Ce script se démerde et au final, il dit ok ou paok. Si c'est ok, ça veut dire que le pseudo est disponible, on affiche un icône check vert qui indique que le pseudo est disponible. si c'est paok, alors on affiche le forbidden rouge. Commençons par créer le webservice… 13h43 : header('Content-type: text/html; charset=UTF-8'); /*******************************************************************************/ // VERIFICATION DE LA DISPONIBILITE DU PSEUDO D'UN UTILISATEUR /*******************************************************************************/ /* * Renvoie ok ou paok */ if(isset($_POST['pseudo'])) { $pathPrefix = '../../'; require_once '../../init.php'; $pseudo = $_POST['pseudo']; $pseudo = str_replace('%','\%',$pseudo); $aPdoBindedValues = array('something' => array($pseudo, PDO::PARAM_STR)); $stmt = "select count(*) as count from compte_utilisateur where pseudo like :something"; $r = Ling_Sql_Basic::freeFetch($stmt, $aPdoBindedValues); if ($r['count'] == '0') { echo 'ok'; } else { echo 'paok'; } } Testons maintenant. Pour cela, on va ajouter du jquery dans le formulaire d'inscription;.. $("#id_pseudo").keyup(function(){ checkDispo(); }); checkDispo = function() { var pseudo = $("#id_pseudo").attr("value"); var url = "/webservice/utilisateur/disponibilite-pseudo.php"; $.post(url, {pseudo:pseudo}, function(data){ alert("data=" + data); }); }; 13h59 : passons maintenant à la partie design, il faut créer un check vert et un forbidden, et les placer dans le formulaire. 14h29 : ok. Maintenant le mot de passe. En fait c'est vraiment un gadget plus qu'autre chose ce truc là. Ca me casse limite les bonbons mais bon c'est bon. On va faire. Par contre, on va pas sortir le grand jeu : c'est à dire pas de requête contre un dictionnaire stocké dans une table. Pourquoi ? pour des raisons de performances : quand qqn voudra m'attaquer, si j'avais ce service, il l'utiiserait contre moi, en l'utilisant à outrance. Il lui suffirait de taper plein de fois sur son clavier pendant longtemps pour saturer le service. Si tout le monde fait ça, j'imagine que le serveur sql en prend plein la gueule, bien sûr il faudrait faire des tests pour voir si ce que je dis est fondé ou pas du tout. Mais hélas, nous ne prendrons pas le temps de faire des tests, car vu l'enjeu de ce truc, étant donné que de toutes façons la sécurité repose sur bien d'autres choses qu'un mot de passe, on va donc se fier à mon intuition. Je vais déterminer d'autres règles pour déterminer le niveau de sécurité d'un mot de passe : voici : un bon mot de passe est constitué de au moins 6 caractères, avec des minuscules, majuscules, chiffres et signes de poncutation; Imaginons que je fasses une échelle de 0 à 10. Les bonus sont attribués comme ceci : présence minuscule = +1 présence chiffre = +1 présence majuscule = +1 présence caractère spécial = +1 présence majuscule + minuscule = +2 présence majuscule + chiffre = +2 présence chiffre + minuscule = +2 présence cs (caractère spécial) + majuscule = +2 présence cs + minuscule = +2 présence cs + chiffre = +2 malus = 10 - nombre de caractères Testons cet algoritme : bonjour (7) bonus = 1 malus = -3 total = -2 : très mauvais mot de passe. BONjour (7) bonus = 1 + 1 + 2 = 4 malus = -3 total = 1 : très faible BONjour123 (10) bonus = 1 + 1 + 1 + 2 + 2 + 2 = 9 malus = 0 total = 9 Très bon mot de passe Pl57kalp (8) bonus = 1 + 1 + 1 + 2 + 2 + 2 = 9 malus = -2 total = 7 : bon mot de passe Et juste pour le fun, le mot de passe ayant la plus forte sécurité : AZE123klm, (10) bonus = 1 + 1 + 1 + 1 + 2 + 2 + 2 + 2 + 2 + 2 malus = 0 total = 16 : bestof mot de passe with deluxe chicken. 14h54 : Cet algoritme est bien trouvé, il m'évite bcp de travail, impléméntons le. D'abord le webservice. Il renverra un chiffre de -10 à 16 15h15 :: if(isset($_POST['mdp'])) { $pathPrefix = '../../'; require_once '../../init.php'; // init $mdp = $_POST['mdp']; $total = 0; $hasMin = preg_match('![a-z]!', $mdp); $hasMaj = preg_match('![A-Z]!', $mdp); $hasNum = preg_match('![0-9]!', $mdp); $hasPunct = preg_match('!:punct:!', $mdp); // algo if (true === $hasMin) { $total += 1; } if (true === $hasMaj) { $total += 1; } if (true === $hasNum) { $total += 1; } if (true === $hasPunct) { $total += 1; } if (true === $hasMaj && true === $hasMin) { $total += 2; } if (true === $hasMaj && true === $hasNum) { $total += 2; } if (true === $hasNum && true === $hasMin) { $total += 2; } if (true === $hasPunct && true === $hasMaj) { $total += 2; } if (true === $hasPunct && true === $hasMin) { $total += 2; } if (true === $hasPunct && true === $hasNum) { $total += 2; } $malus = 10 - strlen($mdp); if ($malus < 0) { $malus = 0; } echo ($total - $malus); } Maintenant occupons nous du design, comment va t-on afficher les données ? Je pense à une barre représennt une échelle allant du rouge vers le vert en passant par le jaune (correct) Ptite douche svp; 15h42 : ok, bon, l'échelle. Bon, un peu de math : j'ai une échelle qui mesure 257px de large. Je veux pouvoir la diviser en 16 : chaque partie fait donc 257/16 = … En fait on va faire 256, comme ça ça fait 256/16 = 16 ;) rien à voir, un truc pour les fans de racourcis claviers comme moi : http://docs.info.apple.com/article.html?artnum=75459-fr Notamment le précedent suivant bien pratique. 16h28, le graphisme est intégré, reste plus qu'à faire la bidouille jquery, voici ce que j'ai prévu. Je décale le left de 16px x la valeur retournée par le webservice, fastoche non? Voyons si c'est vraiment si facile que ça en a l'air; Par contre rien à voir, mais je viens de penser que cette méthode est complètement nulle : enfin je veux dire que je fais transiter le mot de passe en clair sur le réseau pour savoir si il est sécurisé. C'est une abération. Si quelqu'un écoute le réseau (je ne sais pas si c'est facile à faire), il voit alors le mot de passe transiter. Après, je ne sais pas jusqu'à quel point on peut écouter le réseau, c'est à dire, est-ce qu'il est capable de voir les données post en clair qui sont postées ? Car si oui, alors il est capable d'associer le mot de passe à un pseudo, autrement dit le système lui a permis de mieux le hacker… La solution consiste à tout coder en javascript, sans appel ajax. N'ayant pas le temps de tester wireshark maintenant, je dois faire comme si c'était facile d'écouter le réseau et de voir toutes les données qui transitent. Bref, je passe l'algoritme du côté javascript, et heureusement que l'algoritme est simple; C'est juste au niveau des regex que ça me fait un peu mal au cul… regex en javascript, j'connais pas du tout… misère… Heureusement il y a findus : http://www.regular-expressions.info/javascriptexample.html encore mieux : http://www.jslab.dk/tools.regex.php Hélas colle pas avec mes besoins ... 17h06 : et voilà le travail, bien joué bibi : // détermine le niveau de sécurité du password, retourne un chiffre entre -10 et 16 getPasswordSecurityLevel = function(zestring){ var total = 0; var regMin=new RegExp("[a-z]"); var regMaj=new RegExp("[A-Z]"); var regNum=new RegExp("[0-9]"); var regPun=new RegExp("[^a-zA-Z0-9]"); var hasMin = regMin.test(zestring); var hasMaj = regMaj.test(zestring); var hasNum = regNum.test(zestring); var hasPun = regPun.test(zestring); if (true == hasMin) { total += 1; } if (true == hasMaj) { total += 1; } if (true == hasNum) { total += 1; } if (true == hasPun) { total += 1; } if (true == hasMaj && true == hasMin) { total += 2; } if (true == hasMaj && true == hasNum) { total += 2; } if (true == hasNum && true == hasMin) { total += 2; } if (true == hasPun && true == hasMaj) { total += 2; } if (true == hasPun && true == hasMin) { total += 2; } if (true == hasPun && true == hasNum) { total += 2; } malus = 10 - zestring.length; if (malus < 0) { malus = 0; } return (total - malus); }; Bon ben il reste qu'à déplacer e curseur en fonction du résultat obtenu. 17h13 : ok. Bon même si j'ai perdu beaucoup de temps pour un gadget, j'avais que c'était amusant. LA suite… Section Vos Projets Annoncez vos projets Faire une section Vos Projets : par exemple : Bonjour, je suis cinéaste amateur et je cherche des peoples pour faire des films amateurs dans la rue, ... Bon alors là il y a 2 manières de résoudre le problème : la manière rapide et la manière lente. rapide: ajouter une catégorie Autres/projets lente : faire tout un système qui permet à une personne de lancer un projet, de le décrire, et d'inviter les autres utilisateurs à le rejoindre sur ce projet. Les autres utilisateurs peuvent s'inscrire et celui qui lancé le projet devient alors le "maître de projet", il a le pouvoir d'envoyer des invitations et d'organiser un planing disponible pour tous les membres du projet. Chaque membre peut consulter le planing, et faire des suggestions sur une sorte de forum restreint aux membres du projet. Le maître de projet peut découper son projet en objectifs et ainsi l'état d'avancement du projet et automatiquement calculé par le système. etc… euh, je crois que je vais prendre la solution rapide, non pas que l'autre me fasses peur, mais j'ai moi même une sorte de dead line (non officielle) à respecter, alors vu que l'intérêt est certes louable, mais un peu hors sujet par rapport à un site d'annonces, quoique. Disons que je garde l'idée en tête et que pour l'instant je vais faire au plus simple. Désolé de brider ta créativité mais t'inkiet t'as le même genre de boulot avec la section emploi.. et rencontres … 17h25 : ajout de la catégorie autres/projets perso. ;) au moins 2 jours de gagnés, voire une semaine; Vive moi. (tu me déçois ling) Mais non mais t'as vu ya pas la place en haut dans le menu c'est blindé. (tu me déçois) Et puis si c'est pour que personne n'utilise le service… (tu me déçois) .. T'inkiet, je te dis je garde l'idée et elle resurgira au bon moment (tu me déçois) La suite… il me casse les couilles l'autre là… Annonces alerte Annonces L'utilisateur peut créer des alertes sur des types d'annonce. Ah, ça au moins c'est intéressant (tu me déçois) relou… aidez moi… Donc l'utilisateur peut créer des alertes sur des types d'annonce. Par exemple, l'utilisateur, on va dire je c'est plus rapide à écrire, par exemple,je veux être alerté dès qu'un véhicule de type Ford qui coûte moins de 153euros arrive (je peux attendre longtemps mais là n'est pas le sujet). Ou alors alertez moi des qu'une blonde à forte poitrine veut sortir avec un geek, ou alors à chaque fois qu'il y a une proposition de location ou location sur Tours centre. ou alors si une annonce avec le mot clé epouse sort. Aha, j'adore le défi proposé. Voyons comment on pourrait réaliser cela… Disons tout de suite que pour la blonde à forte poitrine, étant donné que la rubrique rencontres n'est pas encore modularisée, ou du moins sectionnée en paramètres, on utilisera la technique du mot clef, en faisant une alerte sur blonde + poitrine + geek. Par contre dans le futur, il faudra pluginiser la partie rencontre et créer plein de critères de recherche… Bref, 2 techniques semblent se pointer à l'horizon : la surveillance de paramètres. la surveillance de mot clés. Commencons par le plus facile, ce qui est quasiment naturel u la structure de la base. Histoire de dégrossir le fonctionnement général d'une alerte. Donc X veut être alerté chaque fois qu'une Ford sort. Y poste une Honda Z poste une Ford L poste une location immobilière M poste une Ford que se passe t'il ? titi, tata et toto sont sur un bateau, qui tombe à l'eau ? (débile) utopiquement, il y a une table alerte, et une table utilisateur_has_alerte Un utilisateur peut donc créer autant d'alertes qu'il le souhaite. Et à chaque annonce postée, donc en sortie de formulaire, un script parcourt la table alerte et vérifie les critères de chacun, et à chaque fois que ça matche, le script retrouve le propriétaire, formate et envoie un mail. L'alternative cron le script est exécuté toutes les heures, est tout aussi gourmande. L'alternative de la file d'attente est risquée (risque de saturation, vaut mieux prévoir large...) Je propose tout de suite une idée comme ça : des tables dynamiques. L'idée principale derrière cela serait de dispatcher les alertes par domaine d'application. (diviser pour mieux régner). Par domaine j'entends rubrique d'annonce. En effet, on peut considéré, (exception pour la recherche par mots clés), que une alerte est toujours faite par rapport à un domaine identifiable. Dans le cas de la ford, le domaine serait voiture, voire ford si on pousse la logique d'atomisation un peu plus loin. Les avantages : Lorsque Y poste la Honda, le script devra traiter la table vehicule, ce qui sera plus aisé pour lui que de traiter une table générale contenant toutes les alertes. La contrepartie : Et si l'utilisateur fait juste une alerte par prix comment tu fais ? Ca colle pas ton système. Mouais, effectivement. Mais tout de même la solution idéale du point de vue utilisateur est que l'alerte doit se faire immédiatemment, donc déclenchée par un utilisateur qui poste un formulaire. Au pire une tâche cron toutes les 10 minutes, si ca peut te sortir d'un trop grand problème. Mais réactivité bordel, RE A CTI VI TE. Disons que si on place un gros script en sortie de formulaire, l'annonceur qui poste l'annonce va s'en prendre plein la gueule, ça va pas lui donner envie de reposter une annonce. En même temps si dans la table alerte ya 10 alertes, même 100 ça pose pas trop de souci. L'idée de tout dispatcher n'et pas si mal. Combien il y'a t'il de critères au maximum ? général : prix, date, immobilier : surface, type de bien véhicule : marque Ben alors c'est quoi le problème : on fait les tables alertes suivantes : alerte_prix, alerte_date, alerte_surface, alerte_type_de_bien, alerte_marque, et au fur et à mesure que le site évolue, on rajoute des tables d'alerte. alerte_blonde, alerte_taille_poitrine, alerte_type_animal. A ces tables on ajoute une table d'alerte par catégorie : alerte_immobilier, … Ah ben non chui con, plutôt une table alerte_type_categorie. Mais oui. Une alerte sur un prix, sur une date, sur une catégorie, sur une expression, une ville puis des alertes plus spécifiques aux catégories, par exemple pour immobilier alerte_surface, alerte_type_de_bien et pour les véhicules alerte_marque, et plus tard pourquoi pas alerte_modele. Et plus tard, alerte_type_animal … Pas mal, développe… Donc le posteur poste, il déclenche le script de recherche d'alerte. Comme données de base, constante à notre environnement, le posteur poste TOUJOURS dans une catégorie, il poste TOUJOURS un prix, même si ce prix peut etre null, et un titre et une description, son annonce se fait TOUJOURS dans une ville. Et si il choisit une catégorie spéciale : immo ou véhicule, il DOIT choisir type de bien, surface, et marque si c'est un véhicule. Les critères obligatoires forment des groupes dont on peut se servir pour nos alertes. Nous laissons volontairement les options de côté pour l'instant, chaque chose en son temps; Le scénario optimal serait donc celui-ci : On a une table alerte_generale avec les champs expression prix_max prix_min date commune categorie une table alerte_vehicule : marque une table alerte_immobilier surface type_de_bien Rappel: Donc X veut être alerté chaque fois qu'une Ford sort. Y poste une Honda Ybis poste un chien Z poste une Ford L poste une location immobilière M poste une Ford j'ai rajouté un chien… X fait le prmier pas et il créé une alerte : ce sera une entrée dans la table alerte_vehicule_marque (et une dans utilisateur_has_alerte pour faire la corresponance) Y poste une honda En réalité Y poste donc titre description commune prix categorie marque A l'issu de son post, l'annonce est insérée normalement, puis Le script maitre des alertes fait ceci : expression = titre + description try "select from alerte_generale where expression like expression or prix " STOP LE MASSACRE, nononononon. Il te faut qu'une seule table avec des préfixes qui sont des trigrammes et qui représentent le domaine général: gen pour générale, imm pour immobilier et veh pour véhicules. Ca t'évite de faire 3 requêtes alors que tu peux n'en faire qu'une. Pour l'instant ça tiendra. Et grâce qaux conventions tu peux étendre pas mal. Fais confiance, code... table alerte : gen_exp (expression) gen_primax (prix max) gen_primin (prix min) gen_datmax (date max) gen_datmin (date min) gen_com (commune) gen_cat (catégorie) imm_typ (immobilier type de bien) imm_surmax (immobilier surface max) imm_surmin (immobilier surface min) veh_mar (véhicule marque) Et basta. Le gars poste son annonce et après le script fait un : select something from alerte innerjoin utilisateur_has_alerte innerjoin utilisateur where à améliorer = gen_exp in postedExpression or postedPrix between gen_primin and gen_primax or postedDate between gen_datmin and gen_datmax or if not empty STOP... C'est quoi le mieux c'est de faire une recherche dans le sens alerte posted ou bien posted alerte ? J'ai une idée ? Ta gueule toi? Non mais j'ai une idée . C'est koi ? Pour économiser des ressources, on peut rajouter un champ sqlrequest qui est en fait le précalcul de ce… Tagueule, c'est nul; On n'a pas le choix, on va s'taper du sql à fond les manettes, ça va faire un truc du genre : select something from alerte… where if not empty expr, expr founded in posted expr Putain déjà 18h49 et j'ai pas de solution ! A 19h normalement, Joomla! jusqu'à 21H (faut bien que je mange) et de 21h à 23h normalement Maya (faut bien que je m'amuse) gasp… après 23 heures alors ? putain putain… La ce qui va pas, c'est que le sql est trop abstrait pour moi, j'arrive pas à travailler avec des choses dont je doute sur la cohérence, il faut que je rabattes sur des donnée un peu plus concrètes… J'ai les yeux explosés, faut que je change de trip … 18h56 Musique;.. 20h26 : Joomla! jusqu'à 22h Un menu à continuer. 22h04 : http://zecommerce.fr/declochez/ Le menu commence vraiment à ressembler à celui du club med. Et maintenant maya, car je n'ai plus beaucoup de forces, et j'ai envie de progresser dans maya, et mon esprit a besoin de toute sa lucidité pour le problème complexe des alertes. Juste un truc qu'il faudra ajouter : le cache des annonces de la page d'accueil, ben oui du coup ya 3 styles, et il faut effacer les 3 styles… Je ferais cela ce soir… 23h23 : putain chui mort, enfin j'ai les yeux explosés. 23h33 : correction du bug de mise à jour du cache. En fait c'est de lire la doc de maya en anglais, surtout là ça parlait de l'interface, que des explications de menus et de possibilités : super abstrait : ça a toujours le don de m'assommer. Je crois que je vais me coucher tôt ce soir et demain j'attaque de bonne heure… Paske là chui plus bon à grand chose. Bon ben allez, j'ai plus qu'à placer ce fichier dans mon carnet de bord et rsyncer le tout et espérer qe ça marche direct … ling exit;
AgenceWeb37, agence web de création de site vitrine en Indre et Loire (37)
0.010002136230469