JavaScript 코드 블록에 서버 측 스크립팅을 포함하는 것에 대한 논쟁은 무엇입니까?

Question

JavaScript 코드에 서버 측 태그를 포함하는 것에 대해 논쟁을 벌여 왔지만 확신이없는 개발자가 오늘 당장 발표했습니다.

문제의 코드는 기존 ASP 응용 프로그램 이었지만 ASP.NET이나 PHP (예를 들어)에 똑같이 적용될 수 있기 때문에 크게 중요하지 않습니다.

예제는 ServerSide 코드에서 정의한 상수의 사용을 중심으로 진행되었습니다. 이에 대한

'VB 
Const MY_CONST: MY_CONST = 1 
If sMyVbVar = MY_CONST Then 
    'Do Something 
End If 

//JavaScript 
if (sMyJsVar === "<%= MY_CONST%>"){ 
    //DoSomething 
} 

내 표준 인수는 다음과 같습니다

1. 스크립트 주입 : 서버 측 태그는 자바 스크립트 코드를
2. 단위 테스트를 깰 수있는 코드를 포함 할 수있다. 테스트 용 코드 단위를 분리하는 것이 더 힘들다.
3. 코드 분리 : 가능한 한 웹 페이지 기술을 분리해야한다.

이렇게하는 이유는 개발자가 두 곳에서 상수를 정의 할 필요가 없었기 때문입니다. 그들은 그것이 통제하는 가치 였기 때문에 스크립트 주입의 대상이 아니라고 추론했습니다. 이것은 (1) "표준을 단순하게 유지하려고 노력하고 예외 사례를 정의하는 것이 사람들을 혼란스럽게 할 것"이라고 내 정당성을 감소시켰다. 단위 테스트와 코드 분리 인수는 페이지 자체가 HTML, 자바 스크립트, ASP.NET, CSS, XML 등의 끔찍한 아말감이 있습니다. 이 페이지에 포함될 모든 코드는 단위 테스트를 거칠 수 없습니다.

그래서 나는 상황이 주어지면 코드가 변경되었다고 주장하는 약간의 느낌이 들었다.

내 추론을 뒷받침 해줄 수있는 또 다른 주장이 있습니까, 아니면 제가이 주장에서 실제로 약간의 의미를 지니고 있습니까?

Answer 1

• 스크립트 주입 : 서버 측 태그 그래서 제대로 코드를 작성하는 자바 스크립트 코드를

을 깨고 값이 올바르게있는 자바 스크립트 환경에 도입 할 때 탈출 있는지 확인 수있는 코드를 포함 할 수있다. 프레임 워크에 JavaScript "quoter"도구가 포함되어 있지 않으면 (힌트 : JSON 지원은 아마도 필요한 것 일 것입니다), 작성하십시오.

• 단위 테스트. 테스트 용 코드 단위를 분리하는 것이 더 힘들다.

이것은 좋은 지적이지만, 서버가 코드를 사용하기 위해 페이지에 내용을 드롭해야하는 경우 필요하다. 내 말은,이 일을 간단하게해야 할 때가 있습니다. 이를 수행하는 좋은 방법은 페이지가 일종의 최소 데이터 블록을 포함하는 것입니다. 따라서 페이지에서 서버로 작성된 JavaScript는 실제로 테스트 할 "코드"가 아니며 단지 데이터 일뿐입니다. .js 파일에 포함 된 실제 클라이언트 코드는 데이터를 찾아서 사용할 수 있습니다."의 .js"파일 지금 바로 window.pageData를 확인하기 위해 여러분 잘 캡슐화 된 순수 자바 스크립트 코드를

<script> 
    (function(window) { 
    window['pageData'] = { 
     companyName: '<%= company.name %>', 
     // etc 
    }; 
    })(this); 
</script> 

을, 그리고 갈 수있다 :

따라서 페이지가 포함되어있을 수 있습니다.

• 코드 분리 : 가능한 한 웹 페이지 기술을 분리해야합니다.

동의하지만 사실 서버 측 데이터가 클라이언트 측 동작을 유발해야하는 경우도 있습니다. 데이터를 저장하고 규칙을 만족시키기위한 목적으로 만 숨겨진 DOM 노드를 생성하는 것은 그 자체로 매우 못 생깁니다.

코딩 규칙 및 미학은 좋은 것입니다. 그러나 실용 주의적이어야하며 모든면을 고려해야합니다. 그러한 규칙의 맥락은 항상 완벽한 신성한 창조물은 아니며, HTML, CSS 및 JavaScript의 경우 사실은 분명히 분명하다고 생각하는 것을 기억하는 것이 중요합니다. 이러한 불완전한 환경에서 강경 규칙은 불필요한 작업과 코드를 만들 수 있습니다. 실제로는 유지 관리가 더 어려워집니다.

편집 — 오, 여기 제가 생각한 또 다른 것입니다. 일종의 타협. "마이크로 템플릿"기능 (실제로이 첫 번째 사실을 알게 된 웹 천재에 사과)을 통해 jQuery 갱단에 의해 대중화 된 "트릭"은 일종의 "중성화 된"태그 <script>을 사용하는 것입니다.

<script id='pageData' type='text/plain'> 
    { 
    'companyName': '<%= company.name %>', 
    'accountType': '<%= user.primaryAccount.type %>', 
    // etc 
    } 
</script> 

이제 브라우저 자체에서 해당 스크립트를 실행하지 않습니다. "유형"속성은 코드로 인식되는 것이 아니므로 무시됩니다. 그러나 브라우저 은과 같은 스크립트를 사용할 수 있으므로 코드에서 "id"값으로 스크립트를 찾은 다음 사용 가능한 경우 안전한 JSON 라이브러리 또는 기본 브라우저 API를 통해 표기법을 구문 분석하고 필요한 것을 추출합니다 . 값은 여전히 ​​적절히 인용되어야합니다. 그러나 JSS로 파싱되기 때문에 XSS의 구멍보다 다소 안전합니다. "본격적인"JavaScript가 아닙니다.

Answer 2

1. 단순히 읽을 수 없게됩니다. 서로 다른 언어를 나누려면 면밀한 관찰을해야합니다. 자바 스크립트와 혼합 언어가 동일한 변수 이름을 사용하면 상황이 더욱 악화됩니다. 이것은 특히 다른 사람들의 코드를 봐야하는 사람들에게는 어렵습니다.

2. 많은 IDE에는 혼잡 한 문서의 구문 강조 기능에 문제가있어 자동 완성 기능이 중단되고 적절한 구문 강조 기능이 작동하지 않을 수 있습니다.

3. 코드 재사용을 줄입니다. 배열을 반복하는 것과 같은 일반적인 작업을 수행하는 JavaScript 함수를 생각해보십시오. JavaScript 로직과 반복되는 데이터를 분리하면 애플리케이션 전체에서 동일한 함수를 사용할 수 있으며이 함수의 변경 사항은 한 번만 수행하면됩니다. 반복되는 데이터가 자바 스크립트 출력 루프와 섞인다면 각 루프 앞에 언어에 혼합 된 if 문이 있기 때문에 자바 스크립트 코드가 반복 될 수 있습니다.

Answer 3

나에게

The reason for doing this was so that the developer did not have to define the constant in two places.

, 이것은 당신이 그것에 대해 할 수있는 인수보다 더 나은 인수입니다. DRY 원칙입니다.코드 유지 관리가 크게 향상되었습니다.

모든 스타일 가이드/규칙이 극단적 인 것으로 받아 들여 안티 패턴을 만듭니다. 이 경우 기술 분리에 대한 귀하의 주장은 DRY 원칙을 깨고 잠재적으로 코드를 유지 관리하기 어렵게 만듭니다. 극단적 인 경우 DRY 자체조차도 반 패턴으로 이어질 수 있습니다 : softcoding.

코드 유지 관리의 균형이 잘 잡혀 있습니다. 스타일 가이드가 균형을 유지하는 데 도움이됩니다. 그러나 당신은 그 바로 그 가이드가 도움이되는 때와 그들 자신이 언제 문제가되는지를 알아야합니다. 예에서이 코드 구문 hilighting 또는 구문 분석이 손상되지 준 (심지어 유래 제대로 hilights) 때문에 IDE가 여전히 제대로 그 코드를 분석 할 수 있기 때문에 IDE 인수가 작동하지 않을 것이라는 점을

는

---

참고.