Pour le devéloppement, faire un propel-build-all qui DROP la base n'est pas un problème. Juste après on reload les fixtures pour avoir des données de test et c'est bon. Pour la prod, c'est plus problèmatique et c'est un manque de Symfony par rapport à RoR (cf un autre sujet de ML) Une solution, faire un dump de la base avant de regénérer totalement le modèle puis réinjecter le dump dans DB, mais ça ne fonctionne que si l'on n'a pas une base énorme.
Pour le deuxième point, je ne comprend pas trop ce que tu veux dire. En quoi ta méthode est plus simple que la méthode classique. Tu dois de toutes façons faire un Criteria $c ? Nautile On 28 mar, 15:39, "Jeremie" <[EMAIL PROTECTED]> wrote: > Salut, > > Sur la méthode d'approche du FrameWork, je suis tout à fait d'accord > avec toi, il est préférable de se caler dans la mesure du possible > dans le cadre du framework plutot que faire à sa sauce. Pour > l'authentification utilisateurs, je me suis jetté à l'eau et ai plus > appris dans un cas concret qu'à lire et relire la doc et n'en > mémoriser que le quart. > > Néanmoins, pour le schema des données, notamment en base, j'ai > l'impression qu'il reste plus judicieux de travailler avec des outils > dédiés à ce genre de tâche, de modéliser la base et de rétro générer > le schema.yml pour enfin générer les gabarits de classes objets. > Sachant, d'après ce que j'ai lu, que cette méthode permet une > évolution beaucoup plus simple. Propel étant un fan du DROP TABLE, je > ne m'amuserai donc pas trop avec la commande build-all :) j'abuserai > juste du build-model :) > > Si tu as une solution pour gérer du ALTER TABLE via un schema propel > qui sait me garder intelligement la dégradation de ma base, je veux > bien regarder :) > > P'tite question maintenant , y'a t il un moyen d'éviter de passer par > la collection d'objet lorsqu'on ne souhaite qu'un seul objet ? > Plutot que : > $c = new Criteria(); > $c->add(UserPeer::LOGIN, $login); > $c->add(UserPeer::PASSWORD, $password); > > $this->user = UserPeer::doSelectOne($c); > > on aurait, une fabrication avec initialisation indépendante du > contexte : > > $this->user = User::InitWithData(User::GetDataFromDB($c)); // qui > renverait un nouvel objet instancié et initialisé à partir des données > issues de la BD. > > ?? > > Jeremie > > On 28 mar, 13:29, "nautilebleu" <[EMAIL PROTECTED]> wrote: > > > D'une façon générale (mais bon c'est pas facile quand on commence un > > framework comme symfony, pas très complexe mais très riche) toujours > > essayer d'utiliser des fonctions du framework plutôt que d'essayer de > > réinventer la roue. C'est le principe même d'un framework. Il faut > > avoir "confiance" dans le fait que le framework offre toutes les > > fonctionnalités dont on pourrait avoir besoin (et c'est bien le cas de > > symfony, sauf rares manquement, pour lesquels on en profitera pour > > fournir un snippet/plugin, selon la situation) > > Plutôt que d'essayer de "bidouiller" en fonction de ses compétences en > > PHP, plutôt essayer de lire la doc/le Wiki/les snippets/les forums > > pour trouver ce que l'on cherche à faire. Cela permet d'utiliser la > > "méthode symfony", souvent meilleure (plus rapide, plus simple, plus > > élégante, utilisant les bonnes pratiques en matière de développement) > > > Par ex, là tu saisies ta base dans MySQL, puis tu la recopies dans ton > > fichier yml. Symfony invite plutôt à faire le contraire: tu configures > > l'accès de symfony à MySQL, tu crées ton schema dans le fichier > > schema.yml, puis tu utilises le helper symfony propel-build-all qui va > > exécuter toutes les tâches nécessaires. > > si tu préfères commencer par la BDD (ou que tu as déjà une BDD), il > > existe des helpers qui vont construire tout le schéma à partir de > > base. > > > Nautile > > > On 28 mar, 13:04, "Jeremie" <[EMAIL PROTECTED]> wrote: > > > > Bonjour Nicolas, > > > > Oui, bien sûr pour les password en clair mais je n'ai fait que le > > > minimum. > > > Merci pour sfGuard , je regarde, ça a l'air très bien. > > > > On 28 mar, 12:57, Nicolas Perriault <[EMAIL PROTECTED]> wrote:> Jeremie a > > > écrit : > > > > > > Y a til une meilleure solution ou une solution toute faite ? > > > > > Merci de votre retour > > > > > Perso, j'éviterai absolument de stocker les passwords en clair dans la > > > > base. Sinon tu as le plugin sfGuard qui fait la même chose avec la > > > > gestion des roles et permissions en plus > > > > :http://trac.symfony-project.com/trac/wiki/sfGuardPlugin > > > > > ++ > > > > > -- > > > > Nicolas Perriault http://www.clever-age.com > > > > Clever Age - Conseil en architecture technique > > > > GSM: +33 6 60 92 08 67 Tél: +33 1 53 34 66 10 > > > > > Clever Age vous invite à ses > > > > petits-déjeunershttp://www.clever-age.com/actualites/petits-dejeuners/-Masquer > > > > le texte des messages précédents - > > > - Afficher le texte des messages précédents - --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe Groupe "Symfony-fr" de Google Groupes. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement à ce groupe, envoyez un e-mail à l'adresse [EMAIL PROTECTED] Pour afficher d'autres options, visitez ce groupe à l'adresse http://groups.google.com/group/symfony-fr?hl=fr -~----------~----~----~----~------~----~------~--~---
