Reprise du message précédent :

Je pensais avoir compris le principe de base (commits, repositories, stou), mais en fait pas au point d'en parler avec des gens qui parlent en commandes

C'est au programme

déjà un repository, y'en a qu'un dans SVN.

Pas nécessairement
 
Mais faut aimer la douleur si on veut en utiliser plusieurs sur le même projet

Ca leur permet d'identifier toutes les images qui doivent s'afficher dans un "lightbox".
 
Utiliser un attribut comme rel c'est particulièrement débile.  
 

• Ils doivent fetcher toutes les images puis filtrer par attribut
• Une classe sera matchée par des pseudos selecteurs natif dans la majorité des librairies  
• Une classe sera matchée par document.getElementsByClassName qui est implementé dans les releases de dev de Firefox et Safari (méthodes qui sont infiments plus rapides que celle écrite manuellement, ça va de soit)
• Une classe matchera une règle css, qui définiera par exemple un liseré autour des images qui s'ouvrent dans un lightbox, et ça fonctionne sous tous les navigateurs.

étant donné le contexte si  
 
parce que dans 99,9% des cas y'en a qu'un, dans les autres cas, c'est en cours de migration (ou c'est des cons), enfin le monsieur débute avec SVN pendant qu'il y a un grand bruit médiatique autour des machins distribués.

non mais la question c'etait " ... plutot qu'une classe", hein
enfin, je suppose qu'il y a bien une raison, meme si elle est mauvaise, je ne la vois pas ...

en meme temps, pour des projets qu'on a rien a voir, des repos séparés peuvent etre plus simple a gerer, niveau permissions, hooks,  etc..

class définit le lien, rel définit la chose pointée par le lien (par rapport au document en cours).

pour ceux qui aiment mercurial et qui sont alergiques aux lignes de commandes : http://tortoisehg.sourceforge.net/

enfin maintenant mercurial à un plus sous windows ce qu'il lui manquait au niveau client.

edit : on me dit que masklinn (nerd de l'année 2008) a déjà posté le lien, donc ce post est sans grand intérêt
edit2 : mIRROR me fait remarquer que le bébé existe déjà depuis le 12/3/2007 avec install windows, mais je soupçonne la date d'etre au format MM/JJ/AAAA

ouais, mais non, parce que le monsieur DEBUTE

ouais enfin un class semble valide aussi, dans la mesure ou de toutes façons le nom de la classe est pas supposé etre relative a la tronche qu'on lui donne ... <a class="modal-image-link"...> ça me paraitrait au moins aussi valable que rel="lightbox"
(surtout dans le cas de slimbox )

... si t'y vas comme ça, tu dis qu'il n'a qu'un projet et que donc la question ne se pose pas ...

 
C'est valide aussi, mais théoriquement moins bien vu que rel est un outil spécifiquement destiné à la définition de la chose pointée alors que class est un fourre-tout qu'on utilise pour 40 raisons différentes.
Par contre, une valeur rel de "lightbox" est aussi intelligente qu'une class="red-bold"....
 
( Et en pratique, on s'en tappe complètement du point de vue utilisateur, je suis pas sur qu'il existe vraiment d'outil ou d'être humain qui exploite l'information potentiellement contenu dans le nom d'une classe, et donc qu'il y ait un vrai intérêt pour l'utilisateur à avoir une class="important" plutôt que class="redBold". )
 

si la question se pose, parce qu'en ce moment y'a une grande mode des système distribués où y'a des noeuds dans tous les sens pour le même projet.
 
et si le monsieur parlait de "dev", "staging", "prod", il pourrait largement penser qu'il a un serveur par environnement.

C'est exactement ce que je dis, y'a aucun interêt à utiliser un rel, et mon post montre les interêts d'utiliser une classe

Le rel est simplement un identifiant qui sert à fetcher les élements concernés par le lightbox dans ce cas précis, y'a effectivement aucun interêt à mettre une telle valeur pour cette attribut

Une bête question de sémantique. (Pour la maintenance)
 

Intérêts un peu réduits en ce qui concerne les api js modernes qui utilisent les backend xpath qui tappent sur les class comme les rel sans faire de différence.
 

la valeur de l'attribute (lightbox) n'a aucune intérêt, l'utilisation de l'attribut (rel) me semble justifiée par contre.
À strictement parler, le fait que la chose pointée par le lien soit une image-en-grand *  n'a pas nécessairement à être couplé avec définition du lien et de son contenu, définition donnée par la classe.  
* et donc le détail d'implémentation qui est d'utiliser lightbox pour emmerder l'utilisateur avec une fausse fenêtre modale pour voir un document lié au document en cours.
 

Je parlais précisément du point de vue utilisateur et pas de celui du dev
Et même d'un pointe vue maintenance&dev, la méthode sémantique pure n'est pas forcément celle qui scale le mieux, preuve en est les règles css "quickfix" qu'on peut trouver dans certains fw ou kits css où ça n'est plus possible de tapper pile sur le bon élément avec uniquement des classes sémantiques et des règles avec imbrications (ça l'est ptêtre théoriquement, mais la complexité de la règle et des jeu de priorité de règles deviennent ingérables).

.isd_Hpaddings_sm {padding-left: 5px !important; padding-right:5px !important;}

Nous sommes d'accord, c'est mal utilisé

J'imagine bien, rares sont les utilisateurs qui regardent le code source quand ils naviguent

Quel projet?

Surtout quand au final on fait du sémantique mais dans la variante abréviation incompréhensible du genre vchmnt_imprt
 

sfr zik ( http://singles.sfr.fr/zikplayer/zikplayer.js )
 
Ça c'est pas de moi par exemple :  

function cleaner(str) {
        var s = new String(str);
        s = s.replace("nosurligner", "" );
        s = s.replace("surligner", "" );
        return s;
}

function AttendrePourLireLaSuite(Duree)
{
  LS = setTimeout(LireLaSuite,Duree);
}

On dirait le nom des fonction en C

J'adore les alert pour le debug _o/
 

 
ca fait toujours du bien de reposter ce genre de lien  
 
( et ca me rappelle que je devrai vraiment m'y mettre un de ces jours )  
 
 
sinon, ici , il n'y avait pas des personnes qui ont monté leur boite pour faire des site ( cible particulier > petite structures ) ? J'aurai un bout de design a faire faire, et je voudrai savoir le coût

 
Oki merci
Pas d'autre avis ? ( cette question s'adresse surtout à la GatsuCorp )

2 questions, qui n'ont rien  voir l'une avec l'autre. (edit : juste pour info le point 1 utilise un exemple totalement fictif, le vrai site n'a rien à voir avec les auto/moto )

1> Imaginons un site de véhicule (Auto + Moto), et admettons que nous ayons dans la BDD une table "auto" et une table "moto". Nous voulons stocker des images pour ces 2 types de véhicules. Quelle est la meilleur solution parmi ces 2 possibilités :

* Créer une table "images", avec les champs "type, rel_id, etc.". Le champ type contiendrait donc un code "auto" ou "moto" pour dire à quelle table le "rel_id" est lié. Ce qui permet d'avoir toutes les images dans une même table, mais par contre on perd la possibilité de clé étrangère.

* Créer une table "images_auto" et une table "images_moto", avec respectivement un champ "auto_id" et "moto_id". Dans ce cas on peut créer une clé étrangère, mais il faut par contre créer une table par type de véhicule... ce qui peut faire beaucoup de table si on a beaucoup de type.

Donc quel est le meilleur choix ?

2> J'ai trouvé une classe Php pour filtrer certaines balises HTML dans un champ envoyé par les utilisateurs (en fait on défini les balises et/ou attributs qu'on accepte, et la classe se charge de supprimer tout ce qu'on accepte pas), très pratique pour les champs WYSIWYG. Par contre elle ne me plait pas, et j'aimerai savoir ce que vous avez à me proposer

Wala, merci

Vu que tu as déjà une table par type pour les tables d'origine, si c'était pas un problème à la base ça devrait pas l'être une fois ajouté les tables d'images, tu ne fais que changer le nombre de table par un facteur constant

Quel est l'intérêt de tout mettre dans la même table, si tu as des tables distinctes pour les objets de base?

"L'intérêt" c'est juste que les tables de "bases" sont des choses différentes... alors que toutes les images sont... des images

C'était juste pour regrouper les images ensemble, surtout que toutes les tables "images*" auront exactement la meme structure (ce qui ne sera pas le cas des tables de bases, les structures seront totalement differentes)

...et rien que pour te faire chier, tu peux aussi faire une table 'images', et deux tables qui font le lien entre id_auto et id_image ou id_moto et id_image...

[edit]

...ce qui répond à ton dernier post - même si l'intérêt d'avoir une seule table comportant des images reste très limité amha.

 
J'y avais songé aussi.
 
Mais niveau dev ça fait une jointure en plus.
 
En fait je voulais surtout savoir ce qui est mieux au niveau perf ... même si je pense savoir quelle est la solution la plus performante

Oui, mais tu as à la fois une seule table d'images et toutes les FK que tu veux.
Remarque ya une autre solution que t'as pas envisagée, c'est de mettre une seule table, et deux champs id_auto ET id_moto, chacun étant une FK, renseignés ou pas.
...et si t'as une photo sur laquelle figurent à la fois une auto et une moto ça marche.

Sauf que si t'as deux motos ou deux autos sur la même photo il n'y a que ma proposition à 3 tables qui marche, à moins de dupliquer l'image en base, ce qui est over-moche.

 
Oui mais 10 tables de "base" voudrait dire 10 champ FK Et je trouve ça particulièrement crade
 
Sinon la méthode à 3 table, je ne la comprends pas ... Si j'ai ça :

 
Si je veux une table supplémentaire elle devra contenir :
 
ID
TYPE
REL_ID
IMAGE_ID
 
Je trouve ça encore plus complexe ...

 
 
Non, tu auras autant de tables 'de liaison' que de tables de 'base'. Si tu as Auto, Moto et Bato, tu auras ImageContientAuto (id_img, id_auto), ImageContientMoto (id_img, id_moto) et ImageContientBato (id_img, id_bato).
C'est la seule méthode qui te permet de ne stocker ton image qu'une fois quoi qu'il arrive, et ça reste facile à étendre si tu veux ajouter des avions...

Le contenu de ce message a été effacé par son auteur

cytrouille > Vu que son exemple est fictif, peut être que son cas réel est "auto, arbre, microbe, constellation" et là, difficile de trouver un élément commun (qui ai autre chose qu'un simple "id" ) à tous ces types. Mais si c'est juste "arbre, fleur" ou "auto, moto", je suis d'accord avec toi : autant créer une table de base.

ben a priori  ses tables existent deja

mais la , je suis en train de bosse sur un soft de gestion de stocks et pour l'instant, j'en suis la ( c'est pas définitif )

j'ai des tables pour definir la struture de mes objets

• def_objet : libelle, famille, id , date et login de creation
• def_attribut : libelle, unité : metre, litre, kilogramme, aucune, ...
• def_obj_att : liaisons entre ces tables + un champ our marquer un attribut obligatoire, + un champ our la valeur par defaut

des tables pour stocker les objets

• objet : idObjet, id_def_objet,date de creation , stock  courant
• attributs : id_def_attribut , valeur

l'avantage c'est que ca me permet d'jaouter d'un coup une fonctionnalité a l'ensemble des objets , par exemple un controle periodique  , ou une image

 
Il se passe quoi s'il veut 2 photos de la même moto?

Le contenu de ce message a été effacé par son auteur

sans dec?

Le contenu de ce message a été effacé par son auteur

et quand j'ai installé le merdier, je vais le chercher à quelle url le bousin ?

Fait gaffe si t'as besoin de faire des recherches sur les attributs de tes objets, tu seras obligé de faire une jointure par critères de recherche, avec des possibilités d'index limitées.
 

Ça génère des fichiers dans /var/www/munin/.
Je me souviens plus si c'est disponible sur Apache directement (je crois pas). Au pire, suffit de faire un lien symbolique dans un de tes répertoires servi par Apache.

 
c'est vrai , mais pour l'instant, j'ai pas trouvé de meilleures idee , sachant que je dois stocké de la vis de 12 a la bouteille d'oxygene en passant par le camion  
 
et puis de toute manier,e pour la recherche, je passe apr une solution externe (lucene )

http://nraynaud.fr/munin/