Dans une certaine mesure, ActiveRecord permet déjà tout ça, mais peut-être pas de la manière la plus élégante qui soit. C'est à dire qu'il est conçu pour te permettre d'utiliser une BDD qui existe déjà, si tu ne peux pas la créer en respectant les conventions qu'il aime bien.
Après, si tu atteinds vraiment les limites de ce qu'AR permet, ou bien si ça devient vraiment trop porc, tu peux coder ton propre truc pour faire ça. Deux possibilités: soit tu le codes comme tu veux, sans te préoccuper de Rails, et tu perdras quelques aides fournies par Rails dans la suite, soit tu prends soin de faire les choses comme Rails apprécie.
Si tu veux conserver tout ce que permet Rails, en gros tu vas avoir besoin de réimplémenter à ta sauce les méthodes d'AR. Du moment qu'elles sont nommées pareil, ça va fonctionner. En particulier, si tes modèles possèdent des méthodes "save", "update_attributes", "delete" et "find", tu couvres la plupart des cas.
Ensuite, quel intérêt dans Rails à part AR ?
Déjà, tu as un framework MVC tout prêt, c'est un début. Si aucun de tes modèles n'hérite d'ActiveRecord, ça ne t'empêche pas de les utiliser, et ça fonctionne très bien. Pouvoir coder du web en autre chose que PHP, pour moi, c'est déjà un plus.
Le framework, en plus d'AR, est composé d'ActionController, ActionView, et quelques trucs mineurs (ActionMailer...).
Si tu combines AC et AV, tu vas disposer:
- d'un moteur de templates pour générer du XHTML, XML, Javascript, avec du code ruby dedans, un peu à la PHP
- d'un autre moyen pour générer des documents XML, sous forme arborescente cette fois
- des outils nécessaires pour que tu puisses développer ta propre gestion des vues qui ne sont pas couvertes par les cas précédents
- d'une gestion très simple des urls "jolies", c'est à dire qu'au lieu d'avoir catalogue.php?action=voir&id=3, tu vas avoir http://hote/catalogue/voir/3
- d'un système de vues partielles ou de composants, qui te permettent d'éviter de dupliquer ton code de présentation
- de plein d'outils tout faits pour intégrer de l'ajax
- de plusieurs systèmes de caches, chacun adapté à différents types d'applications (selon que tes pages sont plus ou moins dynamiques)
J'en oublie certainement :) En plus de ça, tu as un système de plugins vraiment bien fait. Tellement bien fait que tu te retrouves parfois à faire toi-même un plugin pour ta propre application, parce que ça rend le code vraiment plus élégant de faire comme ça. Tu as également un framework de tests qui est très élaboré. Plus un profiler, un débugger, etc. qui te permettent d'interrompre l'exécution de ton programme et d'aller l'inspecter, puis de reprendre. C'est très classique pour un développeur C ou Java, mais je n'ai aucune idée de comment on peut faire ça en PHP, par exemple.
[^] # Re: Concours de b.....
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie de Ruby on Rails 2.0. Évalué à 7.
D'abord, est-ce qu'on peut ?
Dans une certaine mesure, ActiveRecord permet déjà tout ça, mais peut-être pas de la manière la plus élégante qui soit. C'est à dire qu'il est conçu pour te permettre d'utiliser une BDD qui existe déjà, si tu ne peux pas la créer en respectant les conventions qu'il aime bien.
Après, si tu atteinds vraiment les limites de ce qu'AR permet, ou bien si ça devient vraiment trop porc, tu peux coder ton propre truc pour faire ça. Deux possibilités: soit tu le codes comme tu veux, sans te préoccuper de Rails, et tu perdras quelques aides fournies par Rails dans la suite, soit tu prends soin de faire les choses comme Rails apprécie.
Si tu veux conserver tout ce que permet Rails, en gros tu vas avoir besoin de réimplémenter à ta sauce les méthodes d'AR. Du moment qu'elles sont nommées pareil, ça va fonctionner. En particulier, si tes modèles possèdent des méthodes "save", "update_attributes", "delete" et "find", tu couvres la plupart des cas.
Ensuite, quel intérêt dans Rails à part AR ?
Déjà, tu as un framework MVC tout prêt, c'est un début. Si aucun de tes modèles n'hérite d'ActiveRecord, ça ne t'empêche pas de les utiliser, et ça fonctionne très bien. Pouvoir coder du web en autre chose que PHP, pour moi, c'est déjà un plus.
Le framework, en plus d'AR, est composé d'ActionController, ActionView, et quelques trucs mineurs (ActionMailer...).
Si tu combines AC et AV, tu vas disposer:
- d'un moteur de templates pour générer du XHTML, XML, Javascript, avec du code ruby dedans, un peu à la PHP
- d'un autre moyen pour générer des documents XML, sous forme arborescente cette fois
- des outils nécessaires pour que tu puisses développer ta propre gestion des vues qui ne sont pas couvertes par les cas précédents
- d'une gestion très simple des urls "jolies", c'est à dire qu'au lieu d'avoir catalogue.php?action=voir&id=3, tu vas avoir http://hote/catalogue/voir/3
- d'un système de vues partielles ou de composants, qui te permettent d'éviter de dupliquer ton code de présentation
- de plein d'outils tout faits pour intégrer de l'ajax
- de plusieurs systèmes de caches, chacun adapté à différents types d'applications (selon que tes pages sont plus ou moins dynamiques)
J'en oublie certainement :) En plus de ça, tu as un système de plugins vraiment bien fait. Tellement bien fait que tu te retrouves parfois à faire toi-même un plugin pour ta propre application, parce que ça rend le code vraiment plus élégant de faire comme ça. Tu as également un framework de tests qui est très élaboré. Plus un profiler, un débugger, etc. qui te permettent d'interrompre l'exécution de ton programme et d'aller l'inspecter, puis de reprendre. C'est très classique pour un développeur C ou Java, mais je n'ai aucune idée de comment on peut faire ça en PHP, par exemple.