2010-07-11 12 views
0

Je suis novice en matière de rails et je travaille sur une application de gestion de contenu interne. J'ai fait un prototype, mais je sens que c'est désordonné et qu'il y a un meilleur moyen. J'ai besoin de ce qui suit:Rails: Structure de gestion de l'application de contenu de ressources imbriquées

Mon prototype actuel utilise le plugin workflow (http://github.com/geekq/workflow) pour gérer l'état du projet et des sujets. J'ai aussi regardé dans acts_as_tree et acts_as_list, mais je ne sais pas comment structurer les choses.

========

Project (a titre, description, date limite, workflow_state) [états: non publié (comme le projet], publié (Les sujets peuvent être vérifiés dans et hors, etc.), archivés (état terminé)]

Module (est un enfant du projet [agissant en tant que groupe], peut être beaucoup, a le titre, la description, le contenu)

Section (est un enfant du module [agissant en tant que groupe ]; peut être plusieurs; facultatif; a un titre, description, content)

Sujet (est l'enfant de la section; peut être beaucoup; peut être commandé; a le titre, la description, le contenu, workflow_state, owner_id, order) [déclare: nouveau, checked_out, pending_review, review_required, complété]

Processus (est enfant du sujet, peut être plusieurs; facultatif; a le titre, la description, le contenu)

ressources (est enfant de processus, peut être beaucoup, en option, fichier, a titre, resource_link)

-

(Il y a aussi 2 autres objets qui sont liés à un projet, l'introduction et fondamentaux (il n'y en aura qu'un par projet)

Introduction (est un enfant du projet; seulement un; a: titre, description, contenu, workflow_state) [déclare: même sujet]

Fondamentaux (est un enfant du projet; un seul; a: titre, description, contenu, état du workflow) [déclare: même sujet]

NB. Je suis conscient que certains de ces mots sont réservés et devront être aliasés.

========

J'espère utiliser la structure d'URL similaire à:

/projets /: project_id/modules /: MODULE_ID/sections /: SECTION_ID/thèmes /: topic_id/processus /: pROCESS_ID/ressources /: resource_id

ou (si l'article est omis)

/projets /: project_id/modules /: MODULE_ID/thèmes /: topic_id/processus /: id_processus/ressources /: resource_id

========

Toutes les réponses sont grandement appréciées.

MISE À JOUR: Rails 2.3.8

Répondre

1

Vous n'avez pas dit quelle version de Rails que vous utilisez. Je suppose la version 2 à cet effet.Dans votre config/routes.rb vous pouvez configurer une relation hiérarchique comme celui-ci:

ActionController::Routing::Routes.draw do |map| 
    map.resources :projects do |projects| 
    projects.resources :modules do |modules| 
     modules.resources :topics do |topics| 
     topics.resources :processes do |processes| 
      processes.resources :resources 
     end 
     end 
    end 
    end 
end 

Les Rails 3 routeur a une capacité similaire.

MISE À JOUR: répondre à des questions supplémentaires dans les commentaires ci-dessous

Les associations règles pour cette application miroir quelque peu la hiérarchie de routage ci-dessus. Une façon de penser à eux est de regarder les URL de ressources que vous avez proposées dans vos questions. La lecture de gauche à droite le long de l'URL vous donne la relation has_many. La lecture de droite à gauche vous donne la relation belongs_to. Par exemple:

class Project < ActiveRecord::Base 
    has_many :modules 
end 

class Module < ActiveRecord::Base 
    belongs_to :project 
    has_many :topics 
end 

class Topic < ActiveRecord::Base 
    belongs_to :module 
    has_many :processes 
end 

Le vous pouvez accéder à des enfants comme:

@project.modules 
@module.topics 
@topic.processes 

etc

La question de la section facultative vous oblige à réfléchir à la fois sur le routage et la représentation du schéma et les associations. Le premier est le plus facile. La seconde est quelque chose dont vous devez faire attention afin de ne pas trop normaliser votre modélisation. Les règles de routage peuvent être modifiées comme suit:

ActionController::Routing::Routes.draw do |map| 
    map.resources :projects do |projects| 
    projects.resources :modules do |modules| 
     modules.resources :sections do |sections| 
     sections.resources :topics do |topics| 
      topics.resources :processes do |processes| 
      processes.resources :resources 
      end 
     end 
     end 
     modules.resources :topics do |topics| 
     topics.resources :processes do |processes| 
      processes.resources :resources 
     end 
     end 
    end 
    end 
end 
+0

J'ai joué avec cette configuration, mais cela semble désordonné et ce serait bien s'il y avait une meilleure façon. Cela rend les variables et les chemins ennuyeux à travailler. – Blake

+0

Je ne sais pas ce que vous voulez dire par ennuyeux ou salissant. Les règles ci-dessus satisfont les itinéraires que vous avez demandés. Pouvez-vous donner un exemple de ce que vous n'aimez pas et de ce que vous aimeriez avoir à la place? – bjg

+0

Je prévois d'avoir deux vues principales. Voir le projet (montre un arbre comme le contour de tous les enfants au niveau des sujets) et Voir le sujet (montre les processus et les ressources). Le reste sera juste des formes d'édition et autres. Cela signifie que je suis parti en utilisant de nombreux partiels dans les partiels, et de devoir continuer à transmettre des variables. – Blake