여러 페이지에서 같은 양식을 사용하는 레일스 모범 사례

Question

레일즈 2.3.1 웹 사이트를 개발 중입니다. 웹 사이트 전체에서 여러 페이지 (홈 페이지, 게시물 작성 페이지, 게시 목록 페이지, 설명 목록 페이지 등)에 게시물을 작성하기위한 양식이 있어야합니다.이 양식은 여러 페이지에 있어야합니다. 다양한 컨트롤러). 이 페이지들 각각은 대응하는 컨트롤러/동작에서 검색되는 다양한 다른 정보를 표시합니다. 예를 들어, 홈 페이지는 최신 게시물 10 개, DB에서 가져온 콘텐츠 등을 표시합니다.

그래서 저는 게시물 작성 양식을 자체 부분으로 이동하고 필요한 부분에이 부분을 포함 시켰습니다. PostsController :: create에 대한 경로 인/questions에 대한 부분 POST의 양식은 기본 레일스 동작입니다.

내가 실행중인 문제는 양식이 올바르게 완료되지 않은 경우입니다. 기본적으로 PostsController :: create 메서드의 질문/new.html.erb를 작성합니다. 양식이 홈 페이지 (/ home/index.html.erb).

"submitting_controller"및 "submitting_action"을 제출하기 위해 부분적으로 양식을 변경하고 PostsController :: create에서 @ post.save를 사용하려고 시도 했습니까? == false, 액션을 렌더링 => "../submitting_controller/submitting_action"(어느 쪽이 약간 해키지만 PostsController가 아닌 사람의 액션을 렌더링 할 수 있습니다).

표면에서 정상적으로 작동하는 것 같습니다. 불완전한 폼은 모든 올바른 @ post.errors 메시지와 함께 제출 된 뷰에서 렌더링되었습니다. 실제 submitting_controller/submitting_action 메소드가 호출되지 않았기 때문에 문제는 페이지의 다른 모든 데이터가 표시되지 않았습니다. 관련 뷰. (Remeber, 나는 모든 오류 메시지와 제출 된 값을 가진 @post 인스턴스 객체를 보존하지 않는 redirect_to가 아닌 인스턴스 객체를 보존하는 렌더링을 수행했습니다.

나는 두 가지 옵션을 가지고 있습니다. :

1) @ post.save를 사용할 때 세션에 @post 객체를 저장할 수 있습니까? PostsController :: create, redirect_to submitting_controller/submitting_action에서 실패합니다. 어떤 시점에서 @post 객체를 세션에서 꺼내서 양식/오류 메시지를 다시 채 웁니다. (내가 아는 한, 세션에서 객체를 저장하는 것은 나쁜 연습이다.)

2) 게시물이 아닌 작성 양식 데이터를 가져 오는 데 사용되는 모든 로직을 다양한 submitting_controller/submitting_action에서 옮길 수 있습니다. ApplicationController, submitting_controller/submitting_action에 대한 PostsController :: create에서 거대한 switch 문을 생성하고 ApplicationController의 메소드를 호출하여 각 제출 페이지의 렌더링에 필요한 모든 추가 데이터를 가져옵니다.

레일스에서 ​​이것을 수행하는 가장 좋은 방법에 대해 생각해보십시오.

Answer 1

우연히 포스트 모델이 폼을 렌더링하는 데 사용할 컨트롤러의 각 모델과 belongs -to 관계에 있습니까? 포스트 컨트롤러에서 Post.create(params[:post]) 이상의 특별한 프로세싱을하고 있습니까?

첫 번째 질문에 yes라고 대답하고 두 번째 질문에 no라고 대답하면 사용자가 게시물을 만들 수있는 각 컨트롤러에 accepts_nested_attributes_for를 추가하여 최소한의 mangling으로 얻을 수 있습니다.

로버트 포스틸은 AJAX를 보면서 페이지의 섹션을 바꾸기 시작한 것이 맞습니다. 유일한 문제는 사용자가 자바 스크립트를 사용할 수없는 경우해야 할 일입니다. 개인적으로 비 자바 스크립트 케이스의 디자인을하고 편리한 메소드를 추가하고 싶습니다. 당신이 당신의 두 가지 옵션을 고려 무엇인지에 대한 생각에 대해서는

,

1) 나는 플래시 해시에서 개체의 단순 복사본을 저장하기 위해이 방법을 사용했습니다. 리디렉션을 통해이를 보존합니다. 그러나 이것은 게시물의 가변 특성을 감안할 때 당신을 위해 작동하지 않을 수도 있습니다. 약 4K 분량의 데이터 만 보낼 수 있으므로 얕은 사본 외에도 다른 정보가 포함됩니다. 그것은 참으로 악몽으로 미끄러운 경사를 돌 수 있었다 같은 DB 소리에 옵션 1) 추적 OBJS :

2) robertpostill의 반응

Answer 2

이것은 전체 페이지 업데이트에서 AJAX를 사용하여 페이지의 섹션을 업데이트하는 단계입니다. 고려해야 할 사항이 많지만 AJAX 응답과 일반 HTML 응답 사이의 응답을 분할하는 것이 가장 방대한 방법입니다. this ONLamp article, this register article 또는 the awesome agile web development with rails book을 확인하십시오. 기본적으로 컨트롤러는 부분을 제출 한 결과를 포함하는 이전 div를 대체하는 새로운 div를 렌더링합니다. 귀하의 질문에

당신은 두 가지 방법을 언급하고 그래서 나는 시도하고 왜, 왜 당신이 여기에 몇 가지 포인터를주지 :를 Ths 옵션을 개조하면 되겠 어의 부부와 함께 그렇게 나쁘지 않다

옵션 1). 주된 비꼬는 점은 객체를 직렬화 된 형태로 DB에 저장하는 것입니다. 그런 다음 직렬화 된 객체의 ID를 전달하면됩니다.세션 데이터가 지속되면 세션 복구가 간결 해지고 세션이 계속 빛을 발합니다. 이것의 단점은 귀하의 DB에 세션 cruft의 양동이가 귀하의 응용 프로그램을 오염시키고 DB에서 사용하지 않는 세션 크래프트를 만료하는 방법에 대해 생각할 필요가 있다는 것입니다. 나는이 끝을 잘 본적이 없다 ...

옵션 2) Eeek 안에 application_controller! :) 진지하게, 그것을 최후의 수단으로 생각하십시오. 당신은 헬퍼를 insade 할 수 있고 콘트롤러와 뷰 내부의 메소드에 접근 할 수 있습니다. 그러나 그 물건을 테스트하는 것은 그리 쉬운 일이 아니므로 그 경로를 선택하기 전에주의해야합니다. switch 문은 약간의 생각으로 OO 앱에서 대체 될 수 있습니다. 물론 요청한 시점에 앱 상태에 대해 현명한 방법을 사용하기 위해 옵션 해시를 사용할 수 있습니다.