2

제 동료는 클라이언트 브라우저에 올바르게 형식이 지정되고 들여 쓰기 된 html을 매우 '핫'합니다. 이것은 페이지 소스가 사람이 쉽게 읽을 수 있도록하기위한 것입니다.ASP.Net MVC에서 출력 들여 쓰기 제어

첫 번째로, 내 사이트의 여러 영역에서 사용되는 부분보기가있는 경우 렌더링 엔진이 자동으로 들여 쓰기 서식을 지정해야합니다 (예 : XmlTextWriter의 서식 속성 설정).

둘째, 제 동료는 응답에 쓰기위한 여러 가지 HtmlHelper 확장 방법을 만들었습니다. 이것들은 모두 CurrentIndent 매개 변수를 전달해야합니다. 이 냄새는 나에게 잘못이다.

아무도 도와 드릴 수 있습니까?

답변

6

유지하기가 어렵습니다. 누군가 HTML에서 외부 요소를 제거한 경우 코드의 CurrentIndent 값을 업데이트해야합니까? 요즘 대부분의 개발자들은 어쨌든 HTML을 방화문을 통해 보며, 들여 쓰기로 마크 업을 자동으로 포맷합니다.

포맷 필터를 통해 HTML을 후 처리하려면 .NET port of HTML Tidy을 사용해보십시오.

+1

Firebug에 표시된 HTML이 소스 HTML이 아닙니다. 그것은 DOM의 반영입니다. Firefox에 이해가되지 않는 소스는 DOM에 추가되지 않으며 Firebug의 디스플레이에는 나타나지 않습니다. –

+0

동의하지만, 대부분의 경우 충분히 근접한 것 같습니다. 예를 들어 잘못된 형식의 마크 업을 추적하려는 경우 또는 스크립트로 DOM을 업데이트하기 전에 원본 HTML을 확인하는 경우와 같이 실제로 렌더링 된 소스를 구체적으로 볼 필요가없는 경우는 예외입니다. –

+0

+1에 깔끔합니다. 사후 처리가 올바른 접근법입니다. 소스 코드는 클라이언트 렌더링 시간이 아닌 개발시 읽기 쉽도록 포맷되어야합니다. 클라이언트가 도구를 멋지게 렌더링하게하십시오. – Val

3

브라우저는 HTML 들여 쓰기가 얼마나 아름다운 지 신경 쓰지 않습니다. 무엇보다 깊이 중첩 된 HTML은 페이지에 다운로드하는 바이트의 측면에서 약간의 오버 헤드를 추가합니다. 물론 응답을 압축 할 수 있으며 잘 들여 쓰기가 쉬운 HTML은 지원하기가 더 쉽습니다.

+0

html을 들여 쓰면 안되는 것이 좋습니다. –

+1

오른쪽. 이 경우 부분 뷰는 개발 파트 (aspx/ascx 파일)를 유지 관리하고 최종 결과 HTML이 클라이언트에 전달되지 않으므로 별도의 엔터티입니다. 들여 쓰기는 개별 파일에만 관련되어야하며 응답을 끝내지 않아야합니다. –

3

어떤 미친 이유가 있어도 에 들여 쓰기가 "적절하게"들여 쓰기 되더라도 동료가 제안한 방식대로 수행해서는 안됩니다.

이벤트에 연결된 HttpModule은 개체가 트릭을 수행해야합니다. 그리고 물론,이 들여 쓰기를 처리하는 필터가 필요합니다.

public class IndentingModule: IHttpModule { 

    public void Dispose() { 
    } 

    public void Init(HttpApplication context) { 
     context.ReleaseRequestState += 
      new EventHandler(context_ReleaseRequestState); 
    } 

    void context_ReleaseRequestState(object sender, EventArgs e) { 
     HttpApplication app = (HttpApplication)sender; 
     app.Response.Filter = new IndentingFilter(app.Response.Filter) 
    } 
} 
2

모든 HTTP 요청에 영향을 미쳐 CPU 및 대역폭 오버 헤드를 추가하는 적절한 들여 쓰기 솔루션을 구현하는 데 시간을 낭비하지 말고 동료에게 HTML 미화를 사용하는 것이 좋습니다. 그런 식으로 걱정하는 한 사람이 비용을 지불하는 한 사람입니다.

This Firefox plugin은 미감 기능이 포함 된 HTML 검사기입니다. 설명서 here을 참조하십시오.