Reprise du message précédent :

Bah, un MVC plus strict est sûrement faisable déja : si la vue envoie un type de contenu, c'est normal que ce soit elle aussi qui gère sa réception... Et tout le routing serait dans la vue, logique.
 
Forcément ça va encore déborder un peu dans le controlleur, mais moins.
 
La vue serait la face visible, elle gère tout le protocole HTTP et serait ainsi à la limite interchangeable avec une UI bureau (ouais c'est théorique ).

Tout comme mon shop et mon user

Ton shop et ton user sont déjà partie du modèle. Ce qui n'a pas de sens, c'est que les concepts d'utilisateur courant et de shop courant y soient. D'autant plus qu'ils n'ont qu'une durée requête, pas session

clairement. Il me semble que ça fait longtemps que ça a été dit sur ce topic - en web la différenciation entre le contrôleur et la vue est tellement mince qu'elle est plus gênante à mettre en place qu'utile...

Et ton document, il est pas courant lui aussi ?
 

La session est simulée
 
Si j'avais une appli bureau qui faisait la même chose, mon user courant et mon shop courant auraient la durée de la session...

Pas vraiment, fondamentalement il dure aussi longtemps que le logiciel, quand tu fermes le document tu peux aussi bien couper le logiciel, c'est équivalent. Le modèle dans un éditeur de texte n'existe que dans la mesure et l'étendue du document, parce qu'il n'y a que ça qu'il manipule. Le document est fondamentalement la donnée, c'est toute l'étendue du modèle.

L'"utilisateur courant", non.

Et tu les stockerais sûrement pas dans ton modèle. Parce que plus fondamentalement, "le user courant" ou "le shop courant" ne sont pas des données. Ce sont simplement des pointeurs vers un user précis, ou un shop précis, qui eux font partie du modèle.

Est-ce que vous vous servez du champ ID dans vos url ? (si vous voulez faire des permaliens).
Si non, qu'elles sont les conditions pour pouvoir s'en passer, parce que j'ai un champ name unique, mais symfony galère si je lui enleve l'id de l'url ..

Bah ya tout ce qu'il faut dans symfony pour faire des jolies urls, ya même tout un bout juste sur ça dans le tuto Jobeet

Je sais, mais ils gardent l'ID dans le tuto Jobeet.
(y'a une question assez précise dans mon post hein )

 
Pour les annonces oui ils gardent l'ID, mais pas pour les catégories.

Suffit pas de déclarer la colonne comme primary key dans l'ORM?

edit: http://forum.symfony-project.org/index.php/m/62444/ tin apparemment symfony gère pas ça

Même pas, faut juste qu'elle soit unique, et encore je sais pas si c'est vérifié.

Au final c'est juste un WHERE sur la colonne voulue (si je ne m'abuse)

Tfaçon les primary keys pas auto-incrément ça pue du cul

Ben justement j'en ai pas l'impression. Un peu la flemme de me replonger dans le code mais demain je vérifierais çà

Une PK c'est unique par définition  

Non

Oui mais un champ unique n'est pas forcément une primary key, d'où l'adverbe "juste"

Ah oui j'avais mal lu ton post
 
Mais perso je parlais bien de remplacer la PK ID autoincrémentée par une PK naturelle, vu que c'est exactement ce que boblenain demande

Si je ne m'abuse, il cherche simplement à avoir des urls jolies sans numéros. Le reste est à la discrétion de chacun

Mais les PK "naturelles", berk Et encore pire quand ça marche par couple
Les fois où j'ai commencé avec ça comme design, il a pas fallu 2 jours de vrai code pour que ça commence à m'emmerder : plus de notion de chronologie, risque de prendre comme unique une clé qui ne l'est plus au moindre (ou pas) changement de design, fonctionnement différent pour chaque table... bugs de Doctrine...

Et puis rien n'empêche de faire des foreign keys vers des colonnes uniques non-primaires si on veut avoir des données plus lisibles...

Nan ?

Ta DB est plus normalisée, c'est sale
 
Dénormaliser pour des raisons de perfs pourquoi pas, mais au niveau du design de base bof

Le fait qu'une foreign key ne pointe pas vers une primary tu veux dire ?

Autant pour moi, dans le cas auquel je pensais (liste des pays), j'ai mis le code ISO en PK  

Mais j'en abuse pas

Comment vous faites pour utilisez des programmes javascripts (genre SyntaxHighlither dans mon cas) qui ne sont pas juste un css et un js ?
 (avec Symfony)

Comme d'hab, qu'est-ce qui gène ?
 
Sinon faudrait ptet faire un topic symfony au point où on en est

 
C'est-à-dire , tu le places où, t'édites quels fichiers ?

Ben je sais pas, je connais pas SyntaxHighlither... Ca reste JS + CSS + HTML, non ?
Si c'est ça, le JS et le CSS tu les inclues, et le HTML tu l'écris dans une template, de rien

Mouai en faite c'est à cause de leur doc moisi que çà marchait pas ..
Mais merci quand même pour les précisions, c'est bien ce que j'avais fait mais j'étais pas sur de moi .

pour commencer symfony j'attaque par quoi ?  
le tuto du site officiel , ou il y a mieux ?

Jobeet normalement ça passe bien. Quand j'avais commencé c'était Askeet. Et ensuite j'avais enchainé sur le livre de référence.

 
DONE
 
http://forum.hardware.fr/hfr/Progr [...] 5989_1.htm

Bonjour,
 
 
J'ai un doute. Est-ce recommandé de créer un fichier vue par fichier modèle ?
 
 

Salut a tous
 
Je suis en trains de coder une boutique en ligne. Je ne la code pas en orienté objet, c'est grave?
 
Après je voudrais coder proprement.
 
Pour le moment j'ai fait comme organisation:
 
../index.php
../fonctions/commande.fonction.php --> Mes fonctions
../fonctions/panier.fonction.php
etc
../page_commande.php --> HTML + php pour chercher les fonctions + conditions et boucles + Requêtes MySQL
../page_panier.php
etc
 
Je pense que c'est pas mal mais le gros problème c'est les conditions, les boucles et les Requêtes MySQL avec de l'html, c'est pas bien non?
 
Comment vous faites pour les séparer? Merci

Ca dépend de ton application et comment tu l'architectures.

non.
Le but du jeu c'est de découpler vue/controleur/modèle. Si tu te poses cette question c'est que tu as déjà perdu.

(même si dans la pratique ce sera peut-être le cas sur ton appli, on ne sait jamais...mais parce-que tu en as besoin pour répondre aux besoins de l'appli, pas juste pour créer une vue par modèle)

Ce qu'il faut séparer avant tout, c'est la recherche/traitement des données (i.e. requêtes SQL, opérations de calcul etc, = "model" en MVC), et leur affichage (= "vue" ).

La façon la plus basique de faire ça dans un même script en procédural, c'est de faire le traitement des données dans une première partie, et l'affichage dans un deuxième temps.

Après tu peux en plus séparer les requetes SQL dans d'autres fichiers, et faire une fonction/méthode statique (bien nommée) pour chaque.

C'est pas encore du MVC, mais c'est déja plus lisible et maintenable.

Sinon, les boucles et les conditions pour l'affichage c'est obligatoire, ça n'a rien de déconseillé.

 
En fait, je n'ai pas été assez précis. Par exemple, j'ai :
-un formulaire avec un vue
-une vue pour l'affichage d'une news ( communes à toutes les news )
-une vue pour l'index
ect...
 
Je suis toujours perdu ?  
 
Merci pour les précisions  

Là c'est moi qui suis perdu, je ne comprends absolument pas ce que tu demandes

Pose toi la question autrement: tu vas afficher des infos de diverses tables dans ta vue, n'est-ce pas? Il n'y a rien de répréhensible à cela.

 
Donc je fais tous le traitement en haut de page, je met tous en variables et en bas j'affiche juste les variables?

Voilà. C'est la séparation minimum.

question symfony :

je lui demande de générer le frontend

dans le  formulaire généré, il n'y a pas le champ matricule

J'ai raté quoi ?
( "ta vie" n'est pas une réponse acceptée)

Déja juste pour info, t'es pas obligé de tout mettre, ton schéma peut s'écrire au plus court :

Sinon tes relations sont zarb :
- Groupe est du many-to-one j'imagine ? donc idGroupe est un champ de Agent, non ? Si oui il doit apparaitre dans les "columns". Et "matricule" n'a aucun de rapport avec la relation si ? Ou alors j'ai mal pigé le truc.
- Idem pour le profil (sauf que c'est du one-to-one mais ça change pas gd-chose)

Je le réécris comme je l'ai compris :
- Le modèle Agent est lié au modèle AgentDansGroupe par une foreignKey idGroupe
- Le modèle Agent est lié au modèle AgentDansProfil par une foreignKey idProfil, et est one-to-one
Ca donne :

"local" désigne le nom de la foreignKey (le bout "local" de la relation), et "foreign" désigne le nom de la clé dans la table liée (le bout "étranger" de la relation)

edit : rajouté foreignType