제3장 기본 정적 페이지 만들기

3.1 설정

이 장에서부터 본격적으로 앱을 제작한다(트위터와 유사한 사람).
웹 페이지라고 하면 HTML과 CSS라는 인상을 주지만 Rails도 이룰 수 있을지 모르겠다.
즉시 집행rails new 또는bundle install.
계속 진행하면 훈련을 진행하겠습니다.
Bitbucket이 Markdown 메모의 README (목록 3.3) 를 HTML로 올바르게 그렸는지 확인하십시오.
github을 직접 사용하지만 HTML로 그린 것 같습니다.

공식 환경(Heroku)의 노선 URL을 방문하여 depro가 성공했는지 확인하세요.
다 된 것 같은데.

3.2 정적 페이지

다음git checkout -b static-pages은 화이트.
어쨌든'static-pages'라는 지점을 먼저 잘라내면 이 지점에서 일할 수 있다.
덕분에 마스터에게 예상치 못한 영향을 주지 않겠죠.
이어서 rails generate controller StaticPages home help의 명령을 집행하다.
이렇게 하면 home와 help 같은 페이지를 만들 수 있다.잘 모르겠지만 편한 것 같아요.
그나저나 단어의 이니셜을 대문자로 맞추는 이름은'낙타 껍질'이라고 불리는 것 같다.
단어 사이에 밑줄을 그어 연결된 이름은'스nake Case'인 것 같습니다.
Foo라는 컨트롤러를 만들고 bar와 baz 동작을 추가하십시오.
수동으로 생성되었습니다.
열3.1에서 설명한 기술을 사용하여Foo 컨트롤러와 관련된 동작을 삭제해 보십시오.rails destroy controller コントローラー名 アクション名 가능합니다.

3.3 시험 시작

테스트 프로젝트를 더하면 코드를 쓰는 시간이 늘어난다고 한다.
하지만 재작업이 줄어 개발 속도가 높아질 것으로 보인다.
참고로 rails generate controller에서 테스트 파일을 무단으로 생성한 것 같습니다.
테스트 중
"실패한 테스트 먼저 쓰기".
"다음에 프로그램 코드를 써서 성공시키기(통과)"
"필요하면 팩스 보내드릴게요".
이렇게 진행해.어디요?
팩스는'외부에서 보는 행동을 바꾸지 않고 프로그램의 내부 구조를 정리하는 것'을 말한다.팩스를 통해 시스템을 장기간 사용할 수도 있고 고장 시 대응을 가속화할 수도 있다.
그렇다면 GET 요구는 무엇일까.
시험이 진행될수록 "틀이 없는 것 같다"고 말하게 된다.Rails에서 템플릿은 뷰입니다.

3.4 동적 페이지

이 장에서 약간 동적 인 페이지를 만든 것 같다.
동적이란 페이지 내용에 따라 표시를 바꾸는 행위를 말한다.
반대로 정태는 고정에 가깝다는 뜻이다.
이번엔'레드·그린·리팩토어'순환을 해야 할 것 같다.

페이지 제목을 쓰는 간단한 테스트(red)

세 페이지에 제목(green) 추가

레이아웃 파일을 이용하여 코드의 중복을 해결

이런 거.assert_select "title", "Home | Ruby on Rails Tutorial Sample App" 이 코드는 태그에'Home | Rubi on Rails Tutorial Sample Apps'같은 문자열이 있는지 확인하는 것 같습니다.
이번 연습은 매우 길다...
StaticPages 컨트롤러의 테스트 (목록 3.24) 가 몇 번이나 중복되었는지 아십니까?특히'Ruby on Rails Tutorial Sample App'이라는 기본 제목은 각 테스트에서 매번 같은 내용을 썼다.따라서 이 문제를 해결하기 위해 setup이라는 특별한 방법(각 테스트가 시작되기 전에 실행하는 방법)을 사용하고 싶습니다.우선 리스트 3.30의 테스트가 그린인지 확인하십시오. (리스트 3.30에서 2.2.2에서 약간 접촉한 실례 변수와 문자열식 전개 기술을 사용했습니다. 각각 4.4.5.5와 4.2.2로 상세하게 설명하였으나 지금은 알 수 없습니다.)
내용이 명확하지 않기 때문에 중복된 코드는 setup을 이용하여 효율을 높일 수 있습니다.같은 코드를 반복하는 것은 좋지 않겠지.
계속 읽으면.
같은 코드를 반복하는 것은 루비의 DRY(Don't Repeat Yourself: 중복불가) 원칙에 어긋난다.
그래서 역시 중복할 수 없다.
다음은 중복을 배제하기 위해provide 방법을 사용해야 한다.
이용<% provide(:title, "Home") %>과<%= yield(:title) %>로 교체가 가능할 것 같습니다.
연습도 어려워졌어요.
샘플 응용 프로그램에서 Contact(안내소) 페이지 16을 작성하십시오(팁: 우선 목록 3.15 참조, URL 페이지에 "Contact | Rubi on Rails Tutorial Sample Appl")우선 제목의 존재 여부를 확인하는 테스트를 만들어보자.이어 3.3.3에서 About 페이지를 만들었을 때와 마찬가지로 Contact 페이지에도 목록 3.40의 내용을 표시해 보았다.
한 마디로 하면 테스트 파일에 contact 페이지가 존재하고 제목에'Contact'가 포함된 코드를 확인합니다.그 다음은 루트.편집마지막으로 명령touch을 사용하여contact 페이지를 만듭니다.테스트 후 그린으로 확인됩니다.
목록 3.41에 루트, 루트 경로를 추가하여이 Rails 어시스턴트는 사용할 수 있습니다. (예전 static pages 홈 URL을 사용할 수 있을 때와 같습니다.)목록 3.42 FILLIN에 기재된 부분을 바꿔서 루트 루트의 테스트를 써 보십시오.test "should get root" do
get static_pages_home_url
assert_response :success
end이렇게 써서 시험에 통과했는데 정답인 줄 알았는데 아니다static_pages_home_url인 것 같다root_url.어디서 오셨어요...
실제로 리스트 3.41 코드를 썼기 때문에 아까 과제 테스트는 그린이 됐을 거예요.이 경우 변경 테스트 전에 성공했는지 변경 후 성공했는지 판단하기 어렵다.목록 3.41의 코드가 테스트 결과에 영향을 미치는지 확인하기 위해 목록 3.43처럼 루트를 논평하여 레드인지 확인해 보세요(또한 루비의 주석 기능은 4.2.1로 설명됩니다).마지막으로, 평론이 출력된 곳을 제자리에 놓고, 테스트가 그린인지 확인합니다.
이 수정된 곳이 정말 정확합니까?확인을 위한 것 같습니다.