Ses derniers messages sur les forums
Ça faisait un bail qu'on avait pas vu de spam par ici.
Pour écrire des cahiers des charges, et prendre en charge la visibilité d'une entreprise, il faut déjà savoir écrire en français. Ou à défaut, connaitre les bons outils pour se corriger.
En ce qui concerne les technos... je ne vois pas les concepts du Web 2.0. Car en fait, AJAX ce n'est pas du Web 2.0, c'est uniquement un plus pour rendre les pages plus interactives.
Mais dîtes moi, quand on est Freelance, on est seul, non ? Vous êtes donc un marchant de viande, profitant de la solitude des Freelances pour tenter de les exploiter ?
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Il faut prier, bien évidemment. Prier pour être touché par la grâce de l'Expression Normale !
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Je pense que tu as loupé quelque chose, car en faisant l'essai, j'ai bien accès à la variable attendue. Mais fais attention à ne pas confondre les crochets avec les accolades.
Pour l'orientation. Il y a autant de solution que de développeurs. Pour ma part, j'ai un jeu de classes qui me permettent de spécifier les variables attendues à l'aide d'un fichier XML, et qui prépare les données à l'usage, et génère des erreurs au cas où.
Enfin bref, c'est à toi de faire des essais et de décider ce qu'il te convient le mieux.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
(Amery) list ? each ? Beurk ! :p
(glab) En fait, il faut d'abord construire le nom de la variable, puis l'indirecter :
<?php ${"champA{$i}"}=trim($_POST['champ_'.$i]); ?>
Mais dans l'absolu, c'est pas très propre ce que tu veux faire. Sauf si c'est pour découvrir le langage et t'amuser.
En ce qui concerne Bzh, je crois qu'il est effaré qu'on puisse trouver normal de faire des tests d'existence de variable, pour vérifier qu'elle existe, alors qu'en C on fait plus simple : on la déclare et on l'initialise. C'est plus propre et moins équilibriste.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Owned ! Je me suis bien fait avoir.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
(Koboneil) Pourquoi n'y ais-je pas pensé plus tôt ? Ton intervention m'avance beaucoup.
Lorsque je fais quelque chose, je ne le fais pas pour rien. Si tu veux m'aider, relis mon explication. people_id est là pour référencer le People associé au compte utilisateur.
(mojorisin) Merci pour ta réponse constructive. Ben en fait, les insertions se passent très bien, puisque la clé étrangère people_id peut être nulle (puisqu'à un compte n'est pas forcément associé un people). Mais c'est la suppression, qui même lorsque je faisais un delete sur plusieurs tables me bloquait.
Merci pour l'astuce de la désactivation des contraintes.
Cependant, je pense que je vais utiliser une table de jointure :
create table profiles
( account_id integer not null
, people_id integer not null
, primary key (account_id,people_id)
, foreign key (account_id) references accounts(id)
, foreign key (people_id) references peoples(id)
) type='innodb' ;
Ça m'éviteras les problèmes ;) Même si ça me plait moins (ça me parait goret en fait).
Merci en tout cas !
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
mIRC est un logiciel client du protocole IRC. Ce n'est pas le protocole ! Non à la confusion !
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Bonjour tout le monde,
J'ai créé les tables suivantes (j'élude volontairement les attributs qui ne sont pas pertinent ici :
create table accounts
( id integer auto_increment
, people_id integer default null
, username varchar(255) unique not null
, foreign key (people_id) references peoples(id)
, primary key (id)
) type='innodb' ;
create table peoples
( id integer auto_increment
, creator_account_id integer not null
, foreign key (creator_account_id) references accounts(id)
, primary key (id)
) type='innodb' ;
Le principe est le suivant. Sur le site, on créé un compte (table accounts) pour pouvoir se loguer. Lors de l'inscription, un compte est créé ainsi qu'un profil (table peoples). Un compte ne correspond pas forcément à un profil (par exemple, les comptes god et admin ne sont pas des personnes), mais un profil est forcément créé par un compte.
Comme je m'en doutais lorsque j'ai écris ces tables, on a droit à un joli deadlock lorsqu'on veut supprimer un compte.
Est-ce que c'est le genre de cas où la table de jointure est obligatoire ? Et est-ce que mes tables sont mal analysées, ou est-ce une limitation du modèle des contraintes SQL ?
Merci de vos réflexions !
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Je vais essayer d'être plus concret que Bzh ;)
Le classement sera, dans un temps plus ou moins éloigné, faux. Ce n'est pas parce que le code est faux, c'est simplement parce que ton site est multi-utilisateur.
Personnellement, je suis partisant de faire le maximum en base de données, pour éviter les incohérences de données. Si tu ne fais pas comme ça, tu dois locker la table pendant que tu traites les données, pour t'assurer de la cohérence de la base.
Mais locker, c'est mal ©. Pour plein de raison que je ne vais pas exposer ici, mais locker une table rime avec
[i]deadlock et indisponibilité. Bon, maintenant, si t'as pas le choix, t'as pas le choix ;)
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Le PHP sert à générer le contenu côté serveur. Le Javascript est généralement utilisé côté client. Or, tu souhaite rendre ton interface interactive, ce qui veut dire que ton interface va réagir indépendamment du serveur. Il faut donc utiliser le langage ad hoc, à savoir le Javascript dans ton cas.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
