[ruby-on-rails] Ruby on Rails의 시작 / 홈 페이지-모범 사례

Program / 글쓴이

내 홈페이지 (또는 환영 페이지)는 두 모델의 데이터로 구성됩니다 (작성자 및 게시물이라고 부름). 저는 rails를 처음 접했고 이것을 달성하는 가장 좋은 방법이 무엇인지 잘 모르겠습니다.

작성자와 게시물에서 데이터를 수집 한 다음 환영 인덱스보기에 표시하는 welcome이라는 새 컨트롤러를 만들어야합니까? 아니면 저자로부터 데이터를 가져 오는 게시물 모델 아래에 환영보기를 가져야합니까? 아니면 이것을 달성하는 다른 방법이 있습니까?

이 모든 것을 기술적으로 수행하는 방법을 이해하지만 레일 프레임 워크를 사용하는 모범 사례 방법이 무엇인지 확실하지 않습니다.

답변

문제는 귀하의 홈페이지가 단지 랜딩 페이지입니까 아니면 페이지 그룹입니까? 랜딩 페이지 인 경우 사용자가 다른 곳으로 이동하는 경우를 제외하고는 오래 머무를 것으로 기대하지 않습니다. 페이지 그룹이거나 기존 그룹과 유사한 경우 컨트롤러에 가장 유사한 작업을 추가 할 수 있습니다.

현재 프로젝트에서 내가 한 일은 컨트롤러를 Static 3 개의 정적 페이지가 필요하기 때문에 입니다. 다른 곳으로 이동하는 것 외에는 보거나 할 일이 없기 때문에 홈페이지는이 중 하나입니다.

기본 경로를 매핑하려면에서 다음을 사용하십시오 routes.rb.

# Place at the end of the routing!
map.root :controller => 'MyController', :action => :index

제 경우에는 다음과 같습니다.

map.root :controller => 'static', :action => :index

원하는 경우이 홈 페이지 전용 컨트롤러를 만들 수 있습니다. 나는 그것을 메인이라고 부르거나 홈페이지와 관련된 것을 기억할 수있는 것입니다. 거기에서 데이터와 모델을 가져오고 출력보기로 연기 할 수 있습니다.

class MainController < ApplicationController
  def index
    @posts = Posts.find(:all, :limit => 10, :order => 'date_posted', :include => :user)
  end
end

모델 관계가 올바르게 정의되었다고 가정하면 일치하는 템플릿이 매우 간단합니다.

행운을 빕니다. 도움이되기를 바랍니다.

답변

하나의 모범 사례가없는 것 같습니다.

(1) 표준 config/routes.rb파일은 루트 페이지 (또는 홈 / 웰컴 페이지)를 welcome#index. 이에 따라 안내를 받으면 해당 welcome#index컨트롤러 / 액션 을 생성 하려면 다음 명령을 사용할 수 있습니다.

rails generate controller Welcome index

그런 다음에서 생성자가 자동으로 추가 한 config/routes.rbGET 라우트 ( get "welcome/index")를 제거하고 루트 라우트 root 'welcome#index'(또는 root :to => 'welcome#index'Rails < 4)를 파일 맨 위에 배치 할 수 있습니다.

또한 public/index.htmlRails 에서 삭제 하는 것을 잊지 마십시오 < 4.

(2) 레일 라우팅 가이드에 공식 루비 사용 PagesController. 실제로는를 제안 pages#main하지만, 나에게는 함께가는 것이 더 합리적입니다 pages#home( “홈페이지”가 ​​유비쿼터스 용어 / 개념이기 때문에). 또한이 컨트롤러는 다른 처리 할 수있는 페이지 지향 등의 작업을 pages#about, pages#contact, pages#terms, pages#privacy, 등

(삼) 레일 자습서에 루비 로 이동 static_pages#home하고static_pages#help 내가 “정적”이 컨트롤러를 나타내는의 생각처럼 안하지만, 등. 이러한 페이지에는 여전히 동적 측면, 특히 홈페이지가있을 것입니다!

(4) 취급 방법에 대해서는 논의하지 않지만 홈페이지 , Semi-Static Pages의 RailsCast # 117 은 전용 리소스 를 표시하는 또 다른 접근 방식을 제안 합니다.

1 및 / 또는 2를 선호합니다. “and”시나리오에서는 welcome # index 및 pages # about 등을 사용할 수 있지만 “or”시나리오에서는 pages # home, pages # about, 등. 강제로 선택하면 코드가 줄어들 기 때문에 옵션 2를 선택하겠습니다. 그리고 btw, 2, 3은 “정적”이라는 단어를 제외하면 거의 동일합니다.

답변

Rails를 처음 시작할 때 이런 질문을했습니다. 알아야 할 사항은 다음과 같습니다.

  • 모델이 반드시 컨트롤러 및 뷰와 직접 관련이있는 것은 아닙니다.

즉, 특정 컨트롤러 / 뷰 조합은 특정 페이지를 생성하는 데 필요한만큼 많은 모델과 함께 작동 할 수 있습니다.

컨트롤러의 목적은 해당 데이터를 저장하는 데 사용되는 모델에 관계없이 표시해야하는 데이터 세트를 준비하는 것입니다.

보기의 목적은 가장 적절한 방식으로 해당 데이터를 표시하는 것입니다.

즉, 컨트롤러 / 뷰 조합은 특정 모델의 ‘아래’가 아닙니다. 그들은 모델을 사용하지만 어떤 계층 적 관계에서도 그 아래에 있지 않습니다. 사실, 그들은 동료입니다 그들이 사용하는 모든 모델의 입니다.

혼란은 AWDR 및 기타 소개 텍스트에서 발견 된 스캐 폴드 생성기 예제에서 비롯된 것 같습니다.

루비 스크립트 / 스캐 폴드 모델 컨트롤러 생성

모델과 컨트롤러 / 뷰 간의이 암시 적 관계가 나를 약간 혼란스럽게한다는 것을 알고 있습니다. 하지만 정말 엄격한 관계는 없습니다. 그렇다면 MVC 접근 방식으로 복잡한 작업을 수행하는 것은 매우 어려울 것입니다. 그리고 분명히 그것은 사실이 아닙니다.

도움이 되었기를 바랍니다.

-존

답변

가장 좋은 방법은 첫 번째 제안입니다. ‘환영’컨트롤러를 만들고 원하는 모델에서 레코드를 호출합니다. 해당 컨트롤러에 대한 루트 경로 지점이 있습니다. 매우 깨끗하고 적절합니다.

답변

Rails3에서이를 처리하는 올바른 방법은 routes.rb 파일 끝에 다음 줄을 추가하는 것입니다.

root :to => "welcome#index"

public / index.html.erb를 삭제합니다.

welcome # index는 WelcomeController의 색인 작업에 해당하며 The Wicked Flea의 ​​답변 코드는 다음과 같습니다.

class WelcomeController < ApplicationController
  def index
    @posts = Posts.find(:all, :limit => 10, :order => 'date_posted', :include => :user)
  end
end

답변

이 답변은 Rails 3.2.1 현재입니다.

먼저 페이지에 대한 컨트롤러를 설정합니다. 예를 들면 static다음과 같습니다.

$ rails generate controller static

파일 app/controllers/static_controller.rb:

class StaticController < ApplicationController
    def index       
    end
end

새보기 파일 만들기 app/views/index.html.erb

마지막으로 다음을 구성하십시오 config/routes.rb.

MyApp::Application.routes.draw do
   match 'home', :to => "static#index"
   root :to => "static#index"
end

이 모두를 만들 것입니다 /home그리고 /당신은 당신이 방금 만든보기 파일에 넣어 어떤로 이동합니다.

답변

가능한 한 적절하게 이름이 지정된 새 컨트롤러를 만듭니다. SummaryController? StartController? DailyFrontPageController? 당신은 아이디어가있을 것입니다.

뿐만 아니라, 나는 당신의 뷰에서 표현하기 위해 당신의 Author 및 Post 모델 (또는 그들의 실제 이름이 무엇이든간에)으로부터 정보를 수집하는 ActiveRecord 기반이 아닌 새로운 모델을 만드는 것을 진지하게 고려할 것 입니다. 대안은 컨트롤러에서 데이터를 어셈블하는 것인데, 거의 확실히 지저분 할 것입니다. 매번 시도 할 때마다 많은 시도를했습니다. 별도의 모델이 훨씬 더 깔끔하게 마무리되는 것 같습니다.

처리가 비교적 간단하다면 먼저 컨트롤러에서 데이터를 빌드 한 다음 Struct에 출력을 래핑 한 다음 Struct를 실제 클래스로 교체하고 구성을 그곳으로 이동하여 리팩토링하는 것이 어떻습니까? 총 시간에 너무 많은 시간을 추가해서는 안되며 (대부분의 코드는 재사용 가능) 자신에게 가장 적합한 방법이 무엇인지 알 수 있습니다.