09-03-2010, 09:28 AM
(09-03-2010, 12:52 AM)PommeCassis a écrit : J'essaye de mettre en application ce que j'ai appris pendant les cours. Et puis je trouve la programmation avec framework beaucoup plus agréable. Ça m'aide aussi à ne pas partir dans tout les sens avec mes idées farfelues :ange:
J'ai vue sur le net que la release de Symfony 2 sortirait cette année et offrirait de très bonne performances, du coup je vais peut être attendre pour commencer.
En attendant je peux m'éclater sur le cahier des charges, la bdd, commencer à apprendre Symfony et essayer de l'utiliser avec JSON avec une carte test (CakePHP étant un framework simple d'après mon prof, je risque de souffrir avec Symfony et doctrine) Enfin bref y a de quoi faire :O
La pre-release de Symfony 2 est déjà sortie : Symfony Reloaded.
CakePHP est assez simple oui. Quand je l'ai utilisé, il y a 2 ans, j'ai trouvé ça sympa : beaucoup de choses sont devinées par le frameworks, grâce à des conventions de nommage (principe "Conventions over configuration"), etc. Et puis j'ai découvert Ruby on Rails, qui a (parfois fortement) inspiré CakePHP et Symfony. Et là je me suis rendu compte que CakePHP ne jouait pas dans la même cour que Symfony et Rails.
Symfony a l'air d'avoir une courbe d'apprentissage plutôt lente. Il ne faut pas avoir peur de la quantité de configuration et autres trucs à écrire/générer. Il paraît que, dans Symfony 2 tout doit être explicite. Au vu de la masse de code des projets Symfony 1.x, j'ai du mal à imaginer qu'il ai pu en être autrement…
Après, le choix n'appartient qu'à toi. Et selon ton expérience et ta capacité d'apprentissage, tu peux peut-être regarder du côté des frameworks pour d'autres langages.
(09-03-2010, 02:33 AM)Zamentur a écrit : Moi votre serialisation de colonne je suis pas pour, même si je l'ai utilisé. On a une base de donnée faut s'en servir.
Que se passe t'il si on veux mettre en couleur toutes les cases maudites parce que le gars à la nouvelles compétences qui voit tout...
En l'occurrence je conseille:
tile_map(#id, x ,y ,id_map, id_terrain,id_building=>building) en supposant qu'il n'y a qu'un terrain par case et un éventuel bâtiment
tile_malediction(#id, id_tile_map=>tile_map, id_malediction) on peux virer l'id si on est sur qu'il ne peux y avoir 2 malédictions identiques sur une case et faire porter la clef primaire sur les 2 champs
on peux faire une table à coté pour faire des malédictions de zones.
Enfin bref à toi de voir ce qu'il convient le mieux, moi je choisis toujours les solutions les plus évaluable si les ressources limites pas, afin d'éviter d'avoir à tout changer après.
Ça dépend… Au début, je me disais systématiquement que faire des relations n, n était plus propre.
Mais en fait, à partir du moment où tu n'as pas à interroger ta base selon les critères des tables jointes, ça ne sert pas forcément.
Comme d'habitude : il faut choisir une solution adaptée aux besoins.
Sephi-Chan