XSLT를 사용, 학습 또는 권장 할만한 이유가 있습니까? [닫은]

저는 지난 8 년간 개발자입니다. XSLT를 사용하여 XML을 HTML로 변환했습니다. 또한 XML에서 XML 로의 변환에도 사용했습니다.

그러나 지금 우리는 모든 것을 대체했습니다. ASP.Net과 같은 프로그래밍 언어를 통해 HTML을 편안하게 만들 수 있습니다. XML은 모든 표준 고급 언어로 읽고 조작 할 수 있습니다. XSLT에서의 프로그래밍은 약간 복잡하기 때문에 최신 프로그래밍 언어를 선호합니다.

이제 내 질문 : XSLT는 이미 개발 된 XSLT를 유지한다는 사실을 고려하지 않고 미래에 중요한 선택이 될 것입니까? XSLT를 공부할 새로운 프로그래머를 추천 할 수 있습니까?

XSLT가 좋은 선택이 될 수있는 중요한 경우가 있습니다.

• ETL ( Extract, Transform, Load ) 소프트웨어는 경우에 따라 XSLT를 사용할 수 있습니다. 예를 들어 추출 할 데이터와로드 할 데이터가 모두 XML 형식이고 응용 프로그램을 다시 컴파일하지 않고도 변환을 변경할 수있는 경우에 적합합니다.

• XML로 데이터를 저장하는 일부 응용 프로그램은 XSLT를 사용하여이 데이터를 사람이 읽을 수있는 형식으로 제시합니다 ¹. 예를 들어 Windows Live Messenger는 메시지 추적을 XML로 저장하지만 WLM 자체에서 기록을 열면 실제로 XSLT를 통해 HTML이 작성된 예쁜 테이블이 표시됩니다.

• 일부 개발자 지향 또는 데이터 지향 웹 사이트는 웹 사이트의 페이지를 프로그래밍 방식으로 사용하려는 경우 XML에 대한 액세스 권한을 제공하고자 할 수 있습니다 ². HTML 구문 분석기를 사용하는 것보다 HTML 코드가 언제라도 변경 될 수 있기 때문에 어느 정도 더 좋습니다.

• XSLT는 웹 사이트에서 사용될 때 HTML과 코드 숨김을 엄격하게 분리하여 코드 숨김 개발자와 HTML / CSS 관련 개발자를 고용 할 수 있습니다. 다른 질문에 대한 답은 1 번을 참조하십시오 .

XSLT는 앞으로 중요한 선택이 될 것입니까? 글쎄, 이것은 오늘날 중요한 선택이 아니며, XSLT의 사용이 시간이 지남에 따라 증가 할 것이라고 의심합니다. 그 이유를 무시하지만 많은 개발자는 XML을 좋아하지 않고 XSLT를 싫어합니다.

XSLT를 공부하기 위해 새로운 프로그래머를 추천 할 수 있습니까? 확실한! XSLT는 다른 접근 방식이 더 어려운 일부 상황에서 사용할 수있을뿐만 아니라 다른 언어에는없는 매우 구체적인 접근 방식이 있습니다.

^{¹ 이것은 XML이 실제로 사람이 읽을 수 없음을 의미합니다. IT에서 일하지 않는 사람에게 XML을 읽도록 요청하면 충격을받습니다.
² 웹 서비스가 있다는 것을 알고 있습니다. 그러나 때로는 모든 페이지에서 동적 객체를 구성한 다음 XML로 직렬화 한 다음 XSLT를 통해 HTML로 변환하거나 봇이 XML에 직접 액세스하도록하는 것이 더 쉽고 간단합니다.}

XSLT는 소수의 애호가 만 여전히 사용하기 때문에 거의 죽었습니다. 그러나 이에 대한 실질적인 대안은 없습니다. 시맨틱 문서에서 HTML 페이지를 렌더링하는 것과 같이 단일 사용 사례에만 초점을 맞추면 더 나은 도구를 찾을 수 있습니다. 코드 생성 템플릿 엔진을 찾으면 도구가 더 좋습니다. 문서 변환과 동일합니다.

그러나 모든 플랫폼에서 이러한 모든 사용 사례를 지원하는 도구를 찾으면 선택의 폭이 매우 좁아집니다. XML 문서가 이미 있고 도구를 사용할 수 있도록 변환해야하는 경우 XSLT (또는 XQuery)로 데이터를 처리하는 것이 좋습니다.

어느 쪽이든, 몇 일, 몇 주 안에 XSLT를 배울 수 있습니다. 직접 체험하는 것은 당신을 해치지 않습니다. 그냥 쏴 나중에 사용할 수 있도록 이런 종류의 패턴 (규칙 기반 변환)을 머리에 저장하는 것이 좋습니다. 이것만으로도 XSLT 학습을 정당화 할 수 있습니다.

흠 코드에서 HTML을 생성하는 고급 API가 "언제나 다른"XSLT를 사용하는지 궁금합니다.

XSLT는 XML을 하나의 소스 형식에서 다양한 다른 형식으로 변환하기 위해 광범위하게 사용됩니다. XML을 비 XML 출력으로 변환하는 데에도 사용할 수 있습니다. 나는 이것을 많이하지 않았지만 PDF와 PostScript를 대상으로하기 위해 수행되었다고 들었습니다.

예.

지속적인 통합의 단위 테스트 보고서 : 좋은 예를 보자. 대부분의 단위 테스트 및 코드 적용 프로그램은 단순히 읽을 수없는 수많은 XML을 출력합니다. 그러나 몇 가지 간단한 XSLT를 사용하면 동일한 데이터에서 유용한 보고서를 12 개 만들 수 있습니다. 다른 사람들도이 보고서를 재사용 할 수 있습니다.

이제 CI 도구가 플러그인에 사용하는 언어로 언어를 작성할 수 있지만 해당 언어를 모르는 경우 (예 : Jenkins를 사용하는 .NET 개발자) 해당 언어를 배울 필요가 없습니다. 이미 XSLT를 XML 파일에 적용하는 플러그인을 사용하고 유용한 XSLT를 작성하면됩니다.

프로그래밍 언어에는 항상 선택과 다양성이 있으며, 하나가 다른 언어보다 우선적으로 선택되는 이유는 기능성, 생산성 및 성능과 같은 객관적인 기준과 마찬가지로 친숙성과 패션과 관련이 있습니다. 아무도 패션을 예측할 수 없으므로 프로그래밍 언어의 미래 트렌드를 예측할 수 없습니다. 그러나 XSLT의 초기 학습 장벽을 넘어서서 매우 다양한 작업을 수행하는 데 매우 생산적인 도구라는 사실을 알게 된 사람들이 많이 있습니다 (아마도 태클하기 위해 설계된 것보다 훨씬 다양 할 수 있음).

XSLT가 사용되는 많은 작업 (및 내가 직접 사용하는 작업)의 경우 작업을 수행하기 위해 Java 또는 ASP 코드를 작성하면 고용주의 예산을 낭비하게됩니다. 그러나 Java 작성에 능숙하고 XSLT 작성에 능숙하지 않다면 아마도 그렇지 않을 것입니다.

XSLT는 사람이 읽을 수 없습니다. 메타 정보 (태그)가 실제 정보 (텍스트, xpath 요청)보다 너무 많이 사용됩니다. 좋은 코드는 문서처럼 보여야하며 XSLT의 경우에는 그렇지 않습니다. 오히려 매핑 도구에 적합한 지속성 형식입니다.

좋은 변환 언어를 사용하면 변환 결과를 미리보고 변환 흐름 (IF, ELSE, FOR, WHILE)을 동시에 볼 수 있습니다. 이것은 유지 관리에 중요합니다. 이러한 측면에서 Velocity 또는 GenearateXY 가 XSLT보다 낫습니다. GenerateXY는 미리보기와 흐름을 분리하기 때문에 조금 더 좋습니다. Velocity를 사용하면 읽을 수있는 흐름을 제공하기 위해 미리보기 들여 쓰기를 불행히도 중단해야합니다.

XSLT의 유일한 장점은 "xsl : template"요소를 사용하고 심지어 남용함으로써 모듈화에 관심이 있다는 것입니다. 이것의 문제점은 데이터 처리 언어 (Java, C, ...)에는 좋지만 프리젠 테이션 언어에는 매우 부차적이라는 것입니다.

과연

XSLT는 언젠가 배우고 사용하기에 약간 번거로우므로 XSLT보다 우선합니다. 그러나 현재 구현에있어 유연하고 "순결한"템플릿 / 변환 언어는 사용할 수 없습니다.

XSL-T는 몇 가지 다른 목적으로 사용될 수 있습니다.

• 템플릿을 사용하여 데이터에서 HTML 형식으로 콘텐츠를 "생성"할 수 있습니다.
• 한 XML 형식에서 다른 XML 형식으로 변환 할 수 있습니다
• XML을 다른 형식으로 조작 할 수 있습니다.

그러나 기본적으로 모든 XML 데이터 파일을 다른 XML 데이터 파일로 변환하는 것은 동일합니다. 이제 XSLT 대신 사용할 수있는 몇 가지 도구를 살펴 보겠습니다.

XHTML 페이지의 내용을 조작하려면 regexp를 사용할 수 있지만 regexp는 구조적 요소로 인해 지저분합니다. 문자열을 조작하는 데 도움이되지만 무언가를위한 목차를 만들거나 다른 레이아웃으로 제시하는 데는 사용하지 않습니다.

다음은 ASP.Net입니다. 우리는 레이아웃을 ASP 페이지에 넣고 동적 부분을 위해 약간의 코드를 삽입합니다. 또 다른 대안은 레이아웃 부분을 포기하고 데이터베이스라고 말하고 C #을 사용하여 원하는 출력을 생성하는 것입니다.

첫 번째 접근 방식의 문제점은 설명 데이터에서 실제 컨텐츠로 이동하는 것이 어색하다는 것입니다. 전화 번호가 포함 된 일부 데이터 파일에 각 문자의 머리글을 표시하려는 경우 총 항목 수 등을 표시하십시오. 레이아웃 파일에 레이아웃 중 일부와 생성중인 코드에 일부가 있어야합니다. . 또 다른 옵션은 웹 그리드의 일종을 사용하는 것입니다. 나는 그것들을 꽤 지저분하게 발견하고 갑자기 원하는 모든 데이터를 제공하는 특정 HTML을 출력하는 것이 어리석은 그리드가 어떻게 작동하는지 배워야합니다.

완전히 역동적으로 진행하는 것은 선택 사항이지만 다소 어색합니다. LINQ와 같은 것을 사용하는 가장 좋은 경우에도 프로그래밍 코드와 출력을 약간 못생긴 방식으로 혼합해야합니다. 또한 HTML이 일반적으로 사용되는 구조화되지 않은 재귀 문서 스타일 내용을 올바르게 처리하는 좋은 방법이 없습니다.

XSLT를 사용하면 그대로 또는 부모의 컨텍스트에서 특정 태그에 대한 템플릿을 만들 수 있으므로 예를 들어 다른 것에 의해 부모 인 경우 다르게 렌더링됩니다.

다소 긴 답답한 대답이지만 예, 설명 템플릿 언어에는 큰 가치가 있으며 XSLT는 지금까지 우리가 얻은 가장 훌륭하고 표준화 된 언어라고 생각합니다.

XSLT의 가장 큰 단점은 효율적인 처리를 위해 한 번에 메모리에 보관해야하는 문서의 양을 최소화 할 수 없다는 것입니다 (실제 구현에서). 대신 전체 문서를 어떤 형태의 DOM 표현으로 읽어서 처리합니다. 문서가 매우 큰 경우 메모리 요구 사항도 큽니다. 그러나 많은 스타일 시트는 현재 태그와 태그의 조상과 같은 몇 가지 다른 태그 만 필요할 뿐이므로 최소한의 메모리와 효율적인 스트리밍으로 처리 할 수 ​​있습니다.

그렇습니다. 언어의 관점에서 보면 이상하지만, 그것은 진입 장벽입니다. XSLT를 아는 경우 대안보다 더 쉬운 경우가 많습니다. 그러나 큰 문서 (또는 많은 문서를 한 번에 처리하는 경우)가 많으면 XSLT의 메모리 영향으로 인해 더 많은 시간이 소요되는 다른 대안이 필요합니다.

실제로 데이터를 표현하기 위해 다른 언어보다 XSL을 사용하는 것이 더 효율적이라고 생각합니다. 예를 들어 XSL-FO를 사용하여 XML을 PDF로 표시 할 수 있으며 모든 인치를 제어 할 수 있지만 RDLC (.NET)로 작업하는 경우 원하는 것을 정확하게 표현하기가 매우 어렵다는 것을 알 수 있습니다.

XSL에서 각 요소에는 자체 템플릿이 있으므로 진화 / 수정조차 매우 쉽습니다. XSLT와 XSL-FO처럼 XSL의 확장이 더 중요하다고 생각합니다. 그렇기 때문에이 언어가 앞으로도 계속 사용될 것입니다 (그러나 실제로는 더 안정적이고 덜 복잡해지기를 바랍니다).

저는 데이터 통합 ​​회사에서 일하며 XSLT를 독점 도구와 함께 XML to HTML / XML / Ascii와 관련된 훌륭한 솔루션으로 사용합니다.