Question

Je suis en train d’écrire une application qui - comme beaucoup d’apps là-bas - contient 90% de fonctionnalités CRUD standard et 10% de & "jus &" ;, où nous avons besoin d’une logique de gestion désagréable et de davantage de flexibilité et de personnalisation.

En ce qui concerne ces 90%, j’essayais de respecter le principe DRY autant que possible. Tant que les contrôleurs fonctionnent, j'ai constaté que resource_controller fonctionnait vraiment, et je pouvais me débarrasser de tous les contrôleurs de cette zone, en les remplaçant par un contrôleur générique.

J'aimerais maintenant savoir comment obtenir la même chose avec les points de vue. Sur cette application, j'ai une mise en page globale application.html.erb, puis il me faut une autre couche de mise en page, commune à toutes les vues CRUD et enfin une & "Base &"; partie:

  • Sur index.html.erb tout ce dont j'ai besoin pour générer un tableau simple avec les champs et les étiquettes que j'indique.

  • Pour les nouvelles éditions et les éditions, aussi l'édition de formulaire générique, indiquant les libellés et les champs (avec possibilité de fournir des champs personnalisés si nécessaire).

  • Je ne suis pas sûr d'avoir besoin de show, mais si je le fais, ce serait la même chose que new et edit.

Quels plugins et outils (ou même articles et pointeur général) me permettraient de le faire?

Merci, Felipe.

Était-ce utile?

La solution

Si vous avez séché les contrôleurs et souhaitez maintenant sécher les vues, une approche consiste à render :action => *actionname* et stocker le contenu de l'interface utilisateur susceptible de se transformer en variables d'instance (afin qu'elles soient disponibles dans la vue). être en mesure de réutiliser la même vue de modifier , nouveau , liste ou show . Par exemple, vous modifiez quelque chose lié à Foo , votre titre doit alors lire Editing <%= @type %>, ainsi que vos assistants de formulaire. Foo pourrait alors passer à la barre . Ainsi, vous réutilisez la même vue pour différentes entités (ou contrôleurs devrais-je dire). N'oubliez pas que, contrairement à redirect_to, render :action ne restitue que la vue et n'appelle pas l'action du contrôleur de l'action qu'il tente de restituer.

Une chose est sûre, si vous souhaitez assécher quelque chose, vous devez uniformiser ou respecter une convention. Exemple, la structure de vos vues, dans ce cas.

Autres conseils

Vous pouvez exécuter script/generate scaffold test name:string description:text valid:boolean et consulter les vues générées (et exécuter script/destroy scaffold test pour supprimer les fichiers). Cela vous donnera une bonne idée de la méthode standard pour écrire les 4 vues Rails par défaut.

Je vous recommanderais également de lire les chapitres correspondants dans & "Développement Web agile avec Rails &"; et & "La voie des rails &";

Si vous avez des vues existantes à nettoyer, cet épisode de Railscasts est génial: Nettoyage de la vue

Dary

On dirait qu'il y a juste un nouveau joyau qui est très proche de vos exigences:

http://github.com/codez/dry_crud

Sur la base d'une super-classe commune (CrudController), vous pouvez hériter de la fonctionnalité CRUD de vos différents contrôleurs de modèle et y adapter ce qui est spécial. C’est ce que vous avez déjà fait, très probablement.

La nouvelle chose à propos de dry_crud est que les vues et les partiels sont héritables. Vous définissez un modèle de base commun pour chaque action CRUD, éventuellement divisé en plusieurs partiels. Grâce aux aides fournies, les formulaires et les tableaux peuvent être définis de manière générique en consultant les définitions de colonne du modèle actuel. Dans les vues de votre modèle spécifique, vous ne pouvez alors adapter que les vues partielles ou les vues à personnaliser.

Consultez la documentation disponible sur le site ci-dessus et restez au sec!

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top