어디에서 템플릿을 사용해야하며 뷰 객체를 프로그래밍 방식으로 생성해야합니까?

Question

다른 뷰를 많이 포함하는 applciation에 Backbone.js를 사용하고 있으며, 다른 뷰를 중첩하여 다른 뷰를 중첩시킬 수 있습니다.

또한, 프리젠 테이션, 사용자가 인증 된 경우 예를 들어, 일부 콘텐츠 만 표시됩니다, 또는 경우 체크

의 또 다른 유형은 어도비 플렉스의 세계에서 오는 모델의 특정 속성에 따라보기 필자는 마크 업을 사용하여 거의 완전히 내보기를 선언하는 데 익숙하다. Flex는 마크 업에서 구성 요소 선언을 케이크 조각으로 만듭니다.

순수한 뷰 프리젠 테이션과 백본의 뷰 로직 사이에서 동일한 종류의 분리를 달성 할 수 있었으면 좋겠지 만, 지금까지 나는 그것에 대해 애써 왔습니다.

그 이유는 절대로 템플릿을 사용하여 합성보기를 선언 할 수 없기 때문입니다. 따라서 BB의 render() 메서드를 사용하여 하위 뷰를 인스턴스화하고 상위 뷰에 부모 뷰를 추가해야합니다. 이것은 괜찮습니다 ...하지만 뷰가 실제로 세분화되면 JS를 사용하여 선언하는 것은 지나치게 과장됩니다. 필자는 문자 그대로 순수한 HTML 문자열을 추가하기 때문에 이는 완전히 엉망입니다. 이는 템플릿에 템플릿을 사용하고 JS를 사용하여 모든 것을 수행하는 대신 템플릿을 렌더링하는 것이 훨씬 낫다는 것을 의미합니다.

두 가지 접근법을 모두 사용하면 응용 프로그램의 일관성이 깨지기 쉽지만, (전문적으로 작성된) 백본 코드를 많이 읽었 기 때문에 나 자신도 괜찮습니다. 다른 사람들이 고생하는 것을 보았습니다. 똑같은 것.

렌더링 방식의 이러한 분리를 피할 수 없다면 최소한 뷰를 템플릿으로 렌더링해야하는 특정 경계를 지정해야하며 일부 경계가 아닌 부분적 경계를 지정해야합니다. 문제는 그 기준이 무엇인가하는 것입니다.

Answer 1

내 방법론은 모든 마크 업을 템플릿에 포함시키는 것입니다.

Backbone Views에 대한 나의 개념은 실제로 그것이 컨트롤러라는 것입니다. 좀 더 전통적인 웹 애플리케이션 프레임 워크에서 Controller를 고려한다면, 그들의 임무는 이벤트를 받고, 모델을 마샬링하고, 템플릿을 가져오고 렌더링하고, 모델을 전달하고, 결과 출력을 반환하는 것입니다.

백본에서보기는이 작업을 담당하는 요소입니다. 하지만 http가 입력/출력 매체에있는 대신 DOM은 입력/출력 매체입니다.

그래서 뷰는 화면의 특정 UI 영역에 대한 컨트롤러라고 생각합니다. 그들은 이벤트를 듣고, 모델을 마샬링하고, 템플릿을 가져 와서 렌더링하고, 결과적으로 DOM을 수정합니다.

하위보기를 생성하는 대가로 루프를 반복 할 때 템플릿을 렌더링 할 때의 결정은 상당히 느슨합니다.

여러 개의보기에서 사용 될 가능성이있는 경우보기를 만들 것입니다.

"부모"개체에 실제로 영향을주지는 않지만 이벤트 자체 나 사용자 상호 작용이있는 경우이를 볼 수 있습니다.

실제 로직이 있다면, 나는 그것을 밖으로 볼 것입니다.

관련 모델 또는 컬렉션 인 경우이를 볼 수 있습니다.

그러나 이러한 경우 뷰는 HTML을 직접 생성하지 않습니다. 템플릿에 항상 마크 업을 저장합니다.