it-swarm-ko.tech

XSLT는 그만한 가치가 있습니까?

얼마 전에 필자는 HTML 형식의 XML 스키마를 디자인하여 프로젝트 (교육 과정 자료)를 간단한 형식으로 작성하여 XSLT를 통해 HTML로 변환 할 수있는 프로젝트를 시작했습니다. 나는 잠시 동안 그것으로 놀았고 (매우 어려움을 겪었습니다.) 매우 기본적인 수준으로 가져 갔지만 (제 지식의 한계 일 수도 있었음) 한계와 도랑을 제안하는 블로그를 읽을 때 너무 짜증났습니다. XSLT를 선택하고 원하는 언어로 자신의 XML을 파서로 작성하면 나는 열심히 그것에 뛰어 들었고 훌륭하게 해결되었습니다.

나는 여전히 오늘날까지 그것을 연구하고 있습니다 (실제로 연주하는 대신 지금 당장 연구하고 있습니다), 그리고 점점 더 많은 것들을보고 있습니다 XSLT를 버리는 결정이 좋은 것이라고 생각합니다.

XSLT는 그 표준이 인정 된 표준이며 모든 사람이 자신의 통역사를 작성하는 경우 90 %가 TheDailyWTF 로 끝날 것이라는 점을 알고 있습니다. 그러나 그것이 내 프로그래머와 같은 프로젝트를 시작하는 누군가를 위해 대부분의 프로그래머가 익숙한 절차 적 스타일 대신 기능적 스타일 언어 라는 점을 감안할 때 내가 한 길을 따라 가거나 XSLT 로 튀어 나오도록 권장합니까?

111
nickf

XSLT의 장점 :

  • 도메인마다 XML에 따라 다르므로 출력에서 ​​리터럴 XML을 인용 할 필요가 없습니다.
  • 정규식이 문자열을 쿼리하는 좋은 방법 인 것과 같은 방식으로 DOM을 쿼리하는 좋은 방법이 될 수있는 XPath/XQuery를 지원합니다.
  • 기능적 언어.

XSLT의 단점 :

  • 명백하게 장황 할 수 있습니다. 리터럴 XML을 인용 할 필요가 없습니다. 즉, 코드를 인용해야합니다. 그리고 예쁜 방식은 아닙니다. 그러나 다시 말하지만 일반적인 SSI보다 나쁘지 않습니다.
  • 대부분의 프로그래머가 당연한 것으로 여기는 것은 아닙니다. 예를 들어 문자열 조작은 번거로운 일이 될 수 있습니다. 이로 인해 초보자가 코드를 디자인 할 때 "불행한 순간"으로 이어질 수 있으며, 웹에서 원하는 기능을 구현하는 방법에 대한 힌트를 열렬히 검색 할 수 있습니다.
  • 기능적 언어.

그런데 절차 적 동작을 얻는 한 가지 방법은 여러 변환을 함께 연결하는 것입니다. 각 단계 후에는 해당 단계의 변경 사항을 반영하는 새로운 DOM을 사용할 수 있습니다. 일부 XSL 프로세서에는 한 번의 변환으로이를 효과적으로 수행 할 수있는 확장 기능이 있지만 세부 정보를 잊었습니다.

따라서 코드가 대부분 출력이고 논리가 많지 않은 경우 XSLT는 코드를 표현하는 매우 깔끔한 방법이 될 수 있습니다. 많은 논리가 있지만 대부분 XSLT에 내장 된 양식 (대표적으로 보이는 모든 요소를 ​​선택하고 각 출력 대마다)을 선택하면 매우 친숙한 환경 일 수 있습니다. 항상 XML을 생각하는 것을 좋아한다면 XSLT 2를 사용하십시오.

그렇지 않으면 좋아하는 프로그래밍 언어에 XPath를 지원하고 유용한 방법으로 문서를 작성할 수있는 우수한 DOM 구현이있는 경우 XSLT를 사용하면 이점이 거의 없습니다. libxml2와 gdome2에 대한 바인딩은 훌륭하게 수행되어야하며 잘 알고있는 범용 언어를 고수하는 데 부끄러움이 없습니다.

자체 개발 한 XML 파서는 일반적으로 불완전하거나 (어떤 경우 언젠가는 풀리지 않을 수도 있음) 선반에서 내릴 수있는 것 (이 경우 아마도 시간을 낭비하고있는 것)보다 훨씬 작지 않습니다. 악의적 인 입력과 관련하여 심각한 보안 문제를 일으킬 수있는 많은 기회가 있습니다. 당신이 그것을 통해 얻는 것을 정확히 알지 않는 한 작성하지 마십시오. XML이 제공하는 모든 것이 필요하지 않은 경우 입력 형식으로 XML보다 단순한 것에 대한 파서를 작성할 수는 없습니다.

63
Steve Jessop

너무 많은 부정!

나는 몇 년 동안 XSLT를 사용해 왔으며 진정으로 그것을 좋아합니다. 당신이 알아야 할 핵심은 그것은 프로그래밍 언어가 아니며 템플릿 언어입니다 (이 점에서 asp.net/spit보다 필연적으로 우월하다는 것을 알았습니다).

XML은 구성 파일, 원시 데이터 또는 메모리 표현 등 오늘날 웹 개발의 사실상 데이터 형식입니다. XSLT와 XPath는 데이터를 원하는 출력 형식으로 변환하는 엄청나게 강력하고 효율적인 방법을 제공하여 프레젠테이션과 데이터를 분리하는 MVC 측면을 즉시 제공합니다.

그런 다음 네임 스페이스를 정리하고 이종 스키마 정의를 인식하며 문서를 병합하는 유틸리티 기능이 있습니다.

자체 사내 분석법을 개발하는 것보다 XSLT를 다루는 것이 must 더 낫습니다. 최소한 XSLT는 표준이자 고용 할 수있는 것이므로 팀에 실제로 문제가되는 경우 자연스럽게 대부분의 팀이 XML 만 사용하도록 유지할 수 있습니다.

실제 사용 사례 : 방금 시스템 전체에서 메모리 내 XML 문서를 처리하고 최종 사용자의 요청에 따라 JSON, HTML 또는 XML로 변환하는 앱을 작성했습니다. Excel 데이터로 제공하기 위해 상당히 무작위로 요청했습니다. 전직 동료는 프로그래밍 방식으로 비슷한 작업을 수행했지만 몇 가지 클래스 파일의 모듈이 필요했으며 서버에 MS Office가 설치되어있었습니다! Excel에는 XSD가 있습니다. 3 시간 안에 최소한의베이스 코드 영향을주는 새로운 기능입니다.

개인적으로 저는 이것이 제가 경력에서 마주 친 가장 깨끗한 것들 중 하나라고 생각하며, 명백한 문제 (디버깅, 문자열 조작, 프로그래밍 구조)가 도구에 대한 이해 부족이라고 생각합니다.

분명히 나는 ​​그것이 "가치"라고 강력하게 믿는다.

88
annakata

XSLT에 생계를 가르치기 때문에 편견을 인정해야합니다. 그러나 학생들이 일하고있는 분야를 다루는 것이 좋습니다. 그들은 일반적으로 출판, 뱅킹 및 웹의 세 그룹으로 나뉩니다.

지금까지 많은 답변이 "웹 사이트를 만드는 데 좋지 않다"또는 "언어 X와는 다른 것"으로 요약 될 수 있습니다. 많은 기술 전문가들이 기능적/선언적 언어에 노출되지 않고 경력을 쌓습니다. 내가 가르 칠 때, 경험이 풍부한 Java/VB/C/etc 사람들은 언어에 문제가있는 사람들이다 (변수는 예를 들어 절차 적 프로그래밍이 아니라 대수적 의미의 변수이다). 그것은 많은 사람들이 여기에 대답합니다-나는 결코 Java로 시작하지는 않았지만 그로 인해 언어를 비판하지 않을 것입니다.

많은 경우 웹 사이트를 만들기에는 부적절한 도구입니다. 범용 프로그래밍 언어가 더 좋습니다. 나는 종종 매우 큰 XML 문서를 가져 와서 웹에 제시해야합니다. XSLT는 그것을 사소한 것으로 만듭니다. 이 공간에서 내가 본 학생들은 데이터 세트를 처리하고 웹에 제시하는 경향이 있습니다. XSLT는이 공간에서 유일하게 적용 가능한 도구는 아닙니다. 그러나 많은 사람들이 DOM을 사용 하여이 작업을 수행하고 XSLT는 확실히 덜 고통 스럽습니다.

내가 본 은행 학생은 일반적으로 DataPower 상자를 사용합니다. 이것은 XML 어플라이언스이며 서로 다른 XML 방언을 '말하는'서비스 사이에 위치하는 데 사용됩니다. 한 XML 언어에서 다른 XML 언어로의 변환은 XSLT에서 거의 사소한 것이며이 과정에 참여하는 학생들의 수가 증가하고 있습니다.

내가 본 마지막 학생들은 출판 배경에서 나왔습니다. 이 사람들은 XML로 방대한 문서를 가지고있는 경향이 있습니다 (업계에서 출판이 XML에 접어 들면서 기술 출판이 몇 년 동안 있었고 무역 출판이 지금 거기에 있음). 이러한 문서를 처리해야합니다 (DocBook to ePub가 여기에 있습니다).

위의 누군가는 스크립트가 60 줄 이하인 경향이 있거나 다루기가 어려워 졌다고 언급했습니다. 다루기가 어려워지면 코더가 실제로 아이디어를 얻지 못했을 가능성이 있습니다 .XSLT는 다른 많은 언어와는 매우 다른 사고 방식입니다. 사고 방식을 찾지 못하면 작동하지 않습니다.

확실히 죽어가는 언어는 아닙니다 (내가받는 일의 양이 저에게 알려줍니다). 지금은 Microsoft가 XSLT 2의 (매우 늦게) 구현을 마칠 때까지 약간 '고착'되었습니다.

27
Nic Gibson

우리는 XSLT를 문서화와 같은 용도로 광범위하게 사용하며 일부 복잡한 구성 설정은 사용자가 서비스 할 수 있습니다.

문서화를 위해 XML 기반 형식 인 많은 DocBook을 사용합니다. 파일은 일반 텍스트이므로 모든 소스 코드와 함께 문서를 저장하고 관리 할 수 ​​있습니다. XSLT를 사용하면 자체 문서 형식을 쉽게 구축 할 수 있으므로 일반적인 방식으로 컨텐츠를 자동 생성하고 컨텐츠를보다 읽기 쉽게 만들 수 있습니다. 예를 들어 릴리스 정보를 게시하면 다음과 같은 XML을 만들 수 있습니다.

<ReleaseNotes>
    <FixedBugs>
        <Bug id="123" component="Admin">Error when clicking the Foo button</Bug>
        <Bug id="125" component="Core">Crash at startup when configuration is missing</Bug>
        <Bug id="127" component="Admin">Error when clicking the Bar button</Bug>
    </FixedBugs>
</ReleaseNotes>

그런 다음 XSLT (위의 DocBook으로 변환)를 사용하여 버그 ID가 자동으로 버그 추적기에 연결되고 버그가 구성 요소별로 그룹화되며 모든 형식이 완벽하게 일치하는 Nice 릴리스 노트 (일반적으로 PDF 또는 HTML)로 끝납니다. . 또한 위의 XML은 버그 트래커에 버전 간 변경된 사항을 쿼리하여 자동으로 생성 할 수 있습니다.

XSLT가 유용한 다른 곳은 실제로 핵심 제품입니다. 때로는 타사 시스템과 인터페이스 할 때 복잡한 HTML 페이지에서 데이터를 처리해야하는 경우가 있습니다. HTML 파싱은 추악하므로 TagSoup (SAX XML 이벤트를 생성하여 HTML을 XML로 올바르게 작성하는 것처럼 본질적으로 처리 할 수 ​​있도록)와 같은 데이터를 통해 데이터를 공급 한 다음 일부를 실행할 수 있습니다. 이에 대해 XSLT는 데이터를 실제로 사용할 수있는 "안정된"형식으로 바꿉니다. 변환을 XSLT 파일로 분리하면 HTML 형식이 변경 될 때 응용 프로그램 자체를 업그레이드 할 필요가 없으며 최종 사용자가 XSLT 파일을 직접 편집하거나 전자 메일로 보낼 수 있습니다. 전체 시스템을 업그레이드 할 필요없이 업데이트 된 XSLT 파일입니다.

웹 프로젝트의 경우 오늘날 XSLT보다 뷰 측을 처리하는 더 좋은 방법이 있지만 기술로는 XSLT를 확실히 사용하고 있습니다. 그것은 세계에서 사용하기 가장 쉬운 언어는 아니지만 확실히 죽지 않았으며 내 관점에서 여전히 많이 사용됩니다.

24
Adam Batkin

XSLT는 declarative programming 언어의 예입니다.

선언적 프로그래밍 언어의 다른 예로는 정규식, Prolog 및 SQL이 있습니다. 이들 모두는 표현력이 뛰어나고 콤팩트하며 일반적으로 설계 작업에 매우 적합하고 강력합니다.

그러나 소프트웨어 개발자는 일반적으로 배우고 디버깅하기 어려운 주류 OO 또는 절차 언어와는 다르기 때문에) 이러한 언어를 싫어합니다. 실수로 많은 피해를 입었습니다.

따라서 XSLT는 데이터를 프리젠 테이션으로 병합하는 효율적인 메커니즘이지만 사용하기 쉬운 부서에서는 실패합니다. 나는 그것이 실제로 잡히지 않은 이유라고 생각합니다.

19
Bill Karwin

표준이 새로 릴리스되었을 때 XSLT와 관련된 모든 과대 광고를 기억합니다. '단순한'변환으로 전체 HTML UI를 만들 수 있다는 것에 대한 모든 흥분.

직면하기는 어렵습니다. 디버깅하기가 거의 불가능하고 종종 견딜 수없는 속도입니다. 최종 결과는 거의 항상 기발하고 이상적입니다.

더 나은 방법이 있지만 XSLT를 사용하는 것보다 내 다리를 더 빨리 빼낼 것입니다. 여전히 간단한 변환 작업에 적합합니다.

12
Crusty

XSLT (및 XQuery)를 다양한 용도로 광범위하게 사용했습니다. 빌드 프로세스의 일부로 C++ 코드를 생성하고, 문서 주석에서 문서를 생성하고, 일반적으로 XML 및 특히 XHTML과 함께 작동 해야하는 응용 프로그램 내에서 . 특히 코드 생성기는 약 12 ​​개의 개별 파일에 분산 된 XSLT 2.0 코드 10,000 줄을 초과했습니다 (클라이언트 용 헤더, 원격 프록시/스텁, COM 래퍼, .NET 래퍼, ORM 등). 몇). 나는 언어를 잘 이해하지 못하는 다른 사람에게 물려 받았으며, 오래된 비트는 결과적으로 엉망이었습니다. 우리가 작성한 최신 내용은 대부분 제정신이며 읽기 쉬웠지만,이를 달성하는 데있어 특별한 문제는 기억 나지 않습니다. C++에서하는 것보다 확실히 어렵지 않았습니다.

XSLT 2.0을 다루는 버전은 확실히 제정신을 유지하는 데 도움이되지만 1.0은 더 간단한 변환에는 여전히 괜찮습니다. 틈새 시장에서는 매우 편리한 도구이며 특정 도메인 별 기능 (가장 중요한 것은 템플릿 일치를 통한 동적 디스패치)에서 얻는 생산성이 일치하기 어렵습니다. XSLT의 XML 기반 구문의 장황한 인식에도 불구하고 LINQ to XML (VB XML 리터럴을 사용하는 경우))의 경우에도 보통 몇 배 더 길지만, 종종 가치가 부족합니다. 어떤 경우에는 XML을 불필요하게 사용하기 때문입니다.

요약하자면, 그것은 도구 상자에있는 매우 유용한 도구이지만 매우 전문적인 도구이므로 올바르게 사용하고 의도 된 목적으로 사용하는 한 좋습니다. XSLT 2.0의 올바른 네이티브 .NET 구현이 있었으면 좋겠다.

10
Pavel Minaev

XSLT (더 나은 대안이 없음)를 사용하지만 프레젠테이션에는 사용하지 않고 변환에만 사용합니다.

  1. Maven pom.xml 파일에서 대량 편집을 수행하기 위해 짧은 XSLT 변환을 작성합니다.

  2. XMI (UML 다이어그램)에서 XML 스키마를 생성하기위한 변환 파이프 라인을 작성했습니다. 그것은 한동안 작동했지만 마침내 너무 복잡 해져서 헛간 뒤에서 꺼내야했습니다.

  3. XML 스키마를 리팩토링하기 위해 변환을 사용했습니다.

  4. XSLT를 사용하여 실제 작업을 수행하기 위해 XSLT를 생성함으로써 XSLT의 일부 제한 사항을 해결했습니다. (런타임까지 알려지지 않은 네임 스페이스를 사용하여 출력을 생성하는 XSLT를 작성하려고 했습니까?)

필자가 시도한 다른 접근법보다 XML을 처리하는 데 더 나은 작업을 수행하기 때문에 계속 돌아옵니다. 이는 필연적으로 손실되거나 XML을 오해하는 것처럼 보였습니다. XSLT는 불쾌하지만 Oxygen 을 사용하면 견딜 수 있습니다.

즉, XML 변환을 수행하기 위해 Clojure (LISP)를 사용하여 조사하고 있지만 그 접근 방식이 나에게 이익이되는지 여부를 아직 충분히 알지 못했습니다.

9
bendin

개인적으로 저는 완전히 다른 상황에서 XSLT를 사용했습니다. 당시 내가 작업했던 컴퓨터 게임은 XML을 사용하여 정의 된 수많은 UI 페이지를 사용했습니다. 릴리스 직후 주요 리팩터링 과정에서 이러한 XML 문서의 구조를 변경하려고했습니다. 우리는 게임의 입력 형식이 훨씬 더 좋고 스키마 인식 구조를 따르도록 만들었습니다.

XSLT는 이전 형식-> 새 형식에서이 번역에 대한 완벽한 선택 인 것 같습니다. 2 주 안에 수백 페이지에 걸쳐 오래된 문서에서 새 문서로 작업했습니다. 또한 UI 페이지의 레이아웃에 대한 많은 정보를 추출하는 데 사용할 수있었습니다. 상대적으로 쉽게 포함 된 구성 요소 목록을 만든 다음 XSLT를 사용하여 스키마 정의에 작성했습니다.

또한 C++ 배경에서 온 것은 마스터하기에 매우 재미 있고 흥미로운 언어였습니다.

XML을 한 형식에서 다른 형식으로 변환하는 도구로는 환상적이라고 생각합니다. 그러나 XML을 입력으로 사용하여 Something을 출력하는 알고리즘을 정의하는 유일한 방법은 아닙니다. 알고리즘이 충분히 복잡한 경우 입력이 XML이라는 사실은 선택한 도구와 관련이 없습니다. 즉 C++/Python/무엇이든 롤링하십시오.

귀하의 예와 관련하여 비즈니스 로직을 따르는 XML-> XML 변환을 작성하는 것이 가장 좋은 아이디어라고 생각합니다. 다음으로 서식에 대해 잘 알고 영리한 XSLT 번역기를 작성하십시오. 그것은 좋은 중간 지점 일지 모르지만 그것은 당신이하는 일에 전적으로 달려 있습니다. 출력에 XSLT 변환기가 있으면 인쇄 가능, 모바일 등의 대체 출력 형식을보다 쉽게 ​​만들 수 있습니다.

7
Tom Leys

예, 많이 사용합니다. 다른 xslt 파일을 사용하여 동일한 XML 소스를 사용하여 여러 가지 폴리 글 로트 (X) HTML 파일 (다른 방법으로 동일한 데이터를 표시), RSS 피드, Atom 피드, RDF 디스크립터 파일 및 사이트 맵의 조각.

만병 통치약이 아닙니다. 잘하는 것과 잘하지 않는 것이 있으며 프로그래밍의 다른 모든 측면과 마찬가지로 올바른 작업에 적합한 도구를 사용하는 것입니다. 그것은 당신의 툴박스에 가치가있는 툴이지만 그렇게 할 때만 사용해야합니다.

6
Alohci

나는 그것을 찌르는 것이 좋습니다. 특히 XSLT 용 편집,보기 및 디버깅 도구가 내장 된 Visual Studio를 사용하는 경우.

그렇습니다. 배우는 동안 고통이지만 대부분의 고통은 친숙 함과 관련이 있습니다. 언어를 배우면서 고통이 줄어 듭니다.

W3schools에는 다음과 같은 두 가지 기사가 있습니다. http://www.w3schools.com/xpath/xpath_functions.asphttp://www.w3schools.com/xsl/xsl_functions. asp

4
Nat

XSLT는 다루기가 어렵지만 일단 정복하면 DOM과 스키마를 매우 철저하게 이해하게됩니다. 또한 XPath를 사용하는 경우 함수형 프로그래밍을 배우는 데 문제가 있으며 이는 새로운 기술과 문제 해결 방법에 노출됩니다. 경우에 따라 연속 변환이 절차 적 솔루션보다 강력합니다.

3
David Robbins

나는 XSLT가 좋은 아이디어라고 생각했었다. 나는 그것을 의미합니다 is 좋은 생각입니다.

실패한 곳은 실행입니다.

시간이 지남에 따라 발견 한 문제는 XML로 프로그래밍 언어가 나쁜 생각이라는 것입니다. 그것은 모든 것을 뚫을 수 없게 만듭니다. 특히 XSLT는 매우 열심히 배우고 코딩하고 이해한다고 생각합니다. 기능적 측면에서의 XML은 모든 것을 너무 혼란스럽게 만듭니다. 나는 내 경력에서 약 5 번 배우려고 노력했지만 계속 붙어 있지 않습니다.

좋아, 당신은 그것을 '공구'할 수 있습니다-그것이 부분적으로 디자인의 요점이라고 생각합니다. 그러나 그것은 두 번째 실패입니다 : 시장의 모든 XSLT 도구는 아주 간단합니다 ... 쓰레기!

3
Schneider

2004 년 언젠가는 매우 다른 DB 시스템 간의 통합 프로젝트에서 XML, XSD 및 XSLT를 사용했습니다. XSD와 XSLT를 처음부터 배워야했지만 어렵지는 않았습니다. 이 툴의 가장 큰 장점은 XSD와 XSLT를 사용하여 데이터 독립적 인 C++ 코드를 작성하여 XML 문서를 검증/확인한 다음 변환 할 수 있다는 점입니다. 데이터 형식을 변경하고 Xerces 라이브러리를 사용한 C++ 코드가 아닌 XSD 및 XSLT 문서를 변경하십시오.

주요 XSD는 150KB이고 XSLT의 평균 크기는 <5KB IIRC입니다.

다른 큰 이점은 XSD가 XSLT의 기반이되는 사양 문서라는 것입니다. 두 사람은 조화롭게 일합니다. 요즘 소프트웨어 개발에는 사양이 거의 없습니다.

선언적 특성 XSD 및 XSLT를 배우는 데 많은 어려움을 겪지 않았지만 다른 C/C++ 프로그래머는 선언적 방식으로 조정하는 데 큰 문제가 있음을 알았습니다. 그들이 그것을 보았을 때, 아, 그들은 절차를 중얼 거렸다. 그리고 그들은 절차 적 XSLT를 작성하기 위해 진행했습니다. 문제는 XPath를 배우고 XML의 축을 이해해야한다는 것입니다. C++를 작성할 때 OO을 사용하도록 조정하는 구식 C 프로그래머에게 상기시킵니다.

나는 이러한 툴을 사용하여 가장 기본적인 데이터 구조 수정을 제외하고는 전혀 고립되지 않은 작은 C++ 코드 기반을 작성할 수 있었으며, 후자는 DB 구조 변경이었습니다. 다른 언어보다 C++을 선호하지만 소프트웨어 프로젝트의 장기적인 생존 가능성에 도움이되는 것으로 생각합니다.

3
Sam

사용자 지정 MVC 스타일 프런트 엔드에 XSLT를 광범위하게 사용합니다. 모델은 xml serializaiton이 아닌 xml로 "직렬화"된 다음 xslt를 통해 html로 변환됩니다. ASP.NET에 비해 XPath와 자연스럽게 통합되고보다 엄격한 형식의 요구 사항이 있습니다 (대부분의 다른 언어보다 xslt의 문서 구조에 대해 추론하기가 훨씬 쉽습니다).

불행히도, 언어에는 몇 가지 제한 사항 (예 : 다른 변환의 출력을 변환하는 기능)이 포함되어있어 때로는 작업하기가 실망 스럽습니다.

그럼에도 불구하고, 쉽게 달성 할 수 있고 강요된 관심사 분리는 현재 다른 기술이 제공하는 것이 아닙니다. 따라서 문서 변환의 경우 여전히 제가 추천하는 것입니다.

3
Eamon Nerbonne

XSLT가 작업하기가 매우 어렵다는 것을 알았습니다.

나는 당신이 묘사 한 것과 다소 비슷한 시스템에서 일한 경험이 있습니다. 우리 회사는 "중간 계층"에서 반환 한 데이터가 XML로되어 있으며 페이지는 XHTML 일 수있는 HTML로 렌더링되어야하며 XSL이 XML 간 변환을위한 표준이라고 들었습니다. 형식. 따라서 "아키텍처"(심각한 디자인 사고를 생각하지만 코드를 작성하지 않는 사람들을 의미 함)는 데이터를 XHTML로 변환하여 표시 할 XSLT 스크립트를 작성하여 프론트 티어를 구현하기로 결정했습니다.

선택은 비참한 것으로 판명되었습니다. XSLT는 쓰기가 어렵다는 것이 밝혀졌습니다. 따라서 모든 페이지를 작성하고 유지하기가 어려웠습니다. 우리는 JSP (Java에 있음)를 사용하거나 출력 형식 (HTML)에 대해 한 종류의 마크 업 (앵글 괄호)과 다른 종류의 마크 업 (<% ... 메타 데이터의 경우 %>). XSLT의 가장 혼란스러운 점은 XML로 작성되었으며 XML에서 XML로 변환된다는 것입니다. 3 개의 서로 다른 XML 문서를 모두 염두에 두는 것은 매우 어렵습니다.

상황은 약간 다릅니다. XSLT에서 각 페이지를 작성하는 대신 XSLT (템플릿에서 디스플레이로 변환하는 코드)에 1 비트의 코드 만 작성하면됩니다. 그러나 당신이 내가했던 것과 같은 종류의 어려움에 처한 것처럼 들립니다. 나는 당신과 같은 간단한 XML 기반 DSL (도메인 특정 언어)을 해석하려고 시도하는 것이 XSLT의 장점 중 하나가 아니라고 말합니다. (작업을 수행 할 수는 있지만 결국 IS 튜링 완료!)

그러나 만약 당신이 한 것이 더 단순했다면, 하나의 XML 형식의 데이터를 가지고 있고 전체 페이지 설명 DSL이 아니라 간단한 간단한 수정을 원한다면 XSLT는 그 목적을위한 훌륭한 도구입니다. 선언적 (절차 적 아님)은 실제로 그 목적에 유리합니다.

-마이클 켐 사이드

3
mcherm

그것은 당신이 필요로하는 것입니다. 그것의 주요 강점은 변환의 쉬운 유지 관리 능력이며, 자신의 파서를 작성하면 일반적으로 그것을 없애줍니다. 그렇게 말하면 때때로 시스템은 작고 단순하며 실제로 "팬시"솔루션이 필요하지 않습니다. 다른 코드를 변경하지 않고 코드 기반 빌더를 교체 할 수 있다면 큰 문제는 없습니다.

XSL의 추악함에 관해서는 그렇습니다. 예, 익숙해 져야합니다. 그러나 일단 당신이 그것의 걸림돌을 얻는다면 (긴 IMO를 걸리지 않아야 함), 그것은 실제로 부드러운 항해입니다. 컴파일 된 변환은 내 경험에서 매우 빠르게 실행되며 확실히 디버깅 할 수 있습니다.

2
SpongeJim

XSLT specification 은 XSLT를 "XML 문서를 다른 XML 문서로 변환하기위한 언어"로 정의합니다. XSLT 내에서 가장 기본적인 데이터 처리 이외의 작업을 수행하려는 경우 더 나은 솔루션이있을 수 있습니다.

또한 사용자 정의 확장 기능을 사용하여 XSLT의 데이터 처리 기능을 .NET에서 확장 할 수 있습니다.

2
Eric Schoonover

나는 여전히 XSLT가 유용 할 수 있다고 생각하지만 그 언어는 추악한 언어이며 읽을 수없고 유지하기 어려운 엉망으로 이어질 수 있습니다. XML은 "언어"를 구성하기에 충분히 사람이 읽을 수 없기 때문에 XSLT가 선언적이고 절차적인 것 사이에 어딘가에 붙어 있기 때문입니다. 나는 정규 표현식으로 비교를 할 수 있다고 생각하지만 간단하고 잘 정의 된 문제에 사용될 때 사용됩니다.

대체 접근법을 사용하고 코드에서 XML을 파싱하는 것은 똑같이 불쾌 할 수 있으며 XML을 객체로 바로 변환하는 일종의 XML 마샬링/바인딩 기술 (예 : Java의 JiBX)을 사용하려고합니다.

2
Tom Martin

회사의 온라인 문서 시스템을 유지 관리합니다. 작가는 SGML (언어와 같은 XML)로 문서를 작성합니다. 그런 다음 SGML을 XSLT와 결합하여 HTML로 변환합니다.

이를 통해 코딩 작업없이 문서 레이아웃을 쉽게 변경할 수 있습니다. XSLT를 변경하면됩니다.

이것은 우리에게 잘 작동합니다. 우리의 경우 읽기 전용 문서입니다. 사용자가 설명서와 상호 작용하지 않습니다.

또한 XSLT를 사용하면 문제 도메인 (HTML)에 더 가까이 다가 가고 있습니다. 나는 항상 그것이 좋은 생각이라고 생각합니다.

마지막으로 현재 시스템이 작동하면 그대로 두십시오. 기존 코드를 휴지통에 버리지 않는 것이 좋습니다. 처음부터 시작했다면 XSLT를 사용하지만 귀하의 경우에는 내가 가진 것을 사용합니다.

2
Mashed Potato

XSLT를 선언적 스타일로 사용할 수 있다면 (나는 그것이 선언적 언어라는 것에 전적으로 동의하지는 않지만) 그것이 유용하고 표현 적이라고 생각합니다.

데이터/처리 계층을 처리하기 위해 OO 언어 (C #))를 사용하지만 HTML이 아닌 XML을 출력하는 웹 앱을 작성했습니다. C #은이 용도와 구조적으로 호환되는 XML을 출력하기 때문에 매우 매끄러 웠으며 프레젠테이션 논리는 선언적이었습니다. 태그를 보내는 것보다 추적 및 변경이 더 쉬웠습니다. 씨#.

그러나 XSLT 레벨에서 더 많은 처리 로직이 필요하므로 기능적 스타일을 "얻을"경우에도 복잡하고 자세하게 표시됩니다.

물론 요즘에는 RESTful 인터페이스를 사용하여 해당 웹 응용 프로그램을 작성했을 것입니다. JSON과 같은 데이터 "언어"는 XML이 전통적으로 XSLT에 의해 변환 된 영역에서 인기를 얻고 있다고 생각합니다. 그러나 현재 XSLT는 여전히 중요하고 유용한 기술입니다.

2
philsquared

이전 회사에서는 XML 및 XSLT로 많은 작업을 수행했습니다. XML과 XSLT 모두 큰 규모입니다.

예, 학습 곡선이 있지만 XML을 처리 할 수있는 강력한 도구가 있습니다. XSLT에서 XSLT를 사용할 수도 있습니다 (때로는 유용 할 수 있음).

성능은 (매우 큰 XML에서) 문제이지만 스마트 XSLT를 사용하여 문제를 해결하고 (생성 된) XML로 일부 전처리를 수행 할 수 있습니다.

XSLT에 대한 지식이있는 사람은 완제품이 컴파일되지 않기 때문에 완성품의 apearance를 변경할 수 있습니다.

1
Toon Krijthe

이전에 XSLT를 사용했습니다. 6 개의 .xslt 파일 그룹 (하나의 큰 파일로 리팩터링 됨)은 C #으로 다시 작성하기 오래 전에 약 2750 줄이었습니다. C # 코드는 현재 많은 논리를 포함하는 4000 줄입니다. XSLT로 무엇을 작성해야하는지 생각하고 싶지도 않습니다.

내가 포기한 요점은 XPATH 2.0이 없다는 점을 깨달았을 때 진전이 크게 손상된다는 것입니다.

1
Sam Harwell

세 가지 질문에 대답하려면 :

  1. 몇 년 전에 XSLT를 사용했습니다.
  2. XSLT가 특정 상황에서 올바른 솔루션이 될 수 있다고 생각합니다. (절대로 말하지 마십시오)
  3. 나는 그것이 '간단한'변환에 주로 유용하다는 당신의 의견에 동의하는 경향이 있습니다. 그러나 XSLT를 잘 이해하는 한 HTML로 변환 된 XML로 웹 사이트를 게시하는 것과 같은 더 큰 작업을 위해 XSLT를 사용하는 경우가 있다고 생각합니다.

많은 개발자들이 XSLT를 싫어하는 이유는 기본적으로 다른 패러다임을 이해하지 못하기 때문입니다. 그러나 최근 함수형 프로그래밍에 관심을 가지면 XSLT가 컴백 할 것입니다 ...

1
Dawie Strauss

나는 XSLT에서 많은 시간을 보냈고 어떤 상황에서는 유용한 도구이지만 모든 것이 아니라는 것을 알았습니다. 기계가 읽을 수있는 XML 입력/출력을위한 데이터 변환에 사용될 때 B2B 목적으로 매우 잘 작동합니다. 나는 당신이 그 한계에 대한 진술에서 잘못된 길을 가고 있다고 생각하지 않습니다. 나를 가장 실망시킨 것 중 하나는 XSLT 구현의 뉘앙스였습니다.

사용 가능한 다른 마크 업 언어 중 일부를 살펴보아야 할 것입니다. Jeff가 Stack Overflow에 관한이 주제에 관한 기사를 작성했다고 생각합니다.

HTML은 Humane Markup Language입니까?

나는 그가 쓴 것을 보겠다. "바로 사용하기"를 원하는 소프트웨어 패키지를 찾거나 최소한 처음부터 자신의 물건을 쓰는 대신 아주 가까운 소프트웨어 패키지를 찾을 수 있습니다.

1
Jason Jackson

Xslt가 실제로 빛나는 곳 중 하나는 보고서를 생성하는 것입니다. 보고서 데이터를 xml 파일로 내보내는 첫 번째 단계와 xslt를 사용하여 xml에서 시각적 보고서를 생성하는 두 번째 단계가있는 2 단계 프로세스가 있음을 발견했습니다. 따라서 필요한 경우 원시 데이터를 유효성 검사 메커니즘으로 유지하면서 멋진 시각적 보고서를 만들 수 있습니다.

1
Jack Ryan

나는 개인적으로 XSLT를 좋아하고 간체 구문 룩을 보여주고 싶을 수도 있습니다 (명시 적 템플릿은 없으며 XSLT 태그가 몇 개있는 일반적인 오래된 HTML 파일로 값을 뱉어냅니다). 모두를위한 것은 아닙니다.

아마도 저자에게 간단한 Wiki 또는 Markdown 인터페이스를 제공하고 싶을 수도 있습니다. 라이브러리도 있으며 XSLT가 작동하지 않으면 XML도 작동하지 않을 수 있습니다.

1
brianary

나는 현재 공공 사이트에서 데이터를 스크랩하는 일을하고 있습니다 (예, 알고 있습니다). 고맙게도 xhtml을 준수하므로 xslt를 사용하여 필요한 데이터를 수집 할 수 있습니다. 결과 솔루션은 읽기 쉽고 깨끗하며 필요한 경우 쉽게 변경할 수 있습니다. 완전한!

1
Goran

당신이 옳은 일을했다고 생각합니다. 필자의 경험에 따르면 XSLT 개발자는 고용하기가 가장 어렵다. 왜냐하면 언어는 웹 개발자 나 일반 프로그래머에게 결코 걸리지 않는 언어이기 때문이다.

따라서 "주류 이외의 언어를 아는 고급 프로그래머"보험료를 지불해야하지만 해당 프로그래머가 선호하지 않는 언어에 대해서는 비용을 지불해야합니다.

0
Larry OBrien

XSLT에 대한 경험이 많았지 만 HTML로 변환하지 않았습니다. XSLT-HTML 콤보는 작업을 수행하기가 매우 어려운 것일 수 있습니다.

0
Rolf

내 의견으로는 그렇습니다.

XSLT의 멋진 사용법에 대한 훌륭한 예를 보려면 블리자드의 월드 오브 워크래프트 무기고를 확인하십시오.

http://www.wowarmory.com

0
Vinh

XSLT 1.0은 최소한 데스크탑 및 서버 컴퓨터에서 가장 휴대하기 쉬운 코드 중 하나입니다. 대부분의 시스템에서 하나의 (그리고 종종 많은) 런타임을 가지고 있기 때문에 :

  • Microsoft Windows에는 Windows 2000 이상부터 기본 시스템에 MSXML이 설치되어 있습니다. MSIE, 명령 줄에서 (WSH 사용) 또는 Office 응용 프로그램에서 모두 사용할 수 있습니다.
  • Java Runtime Environment (JRE)에는 XSLT 런타임이 있으며 JRE는 대부분의 데스크탑에 설치됩니다.
  • 거의 모든 주요 웹 브라우저에는 하나가 있습니다. Opera는 예외입니다.
  • 메이저 GNU 기반 운영 체제 (libxslt, xsltproc))에 기본적으로 설치되는 무료 구현이 있습니다
  • MacOS X를 확인하지는 않았지만 Safari에서 적어도 구현되어 있습니다.

따라서 이식성과 경량/무 설치가 필요한 일부 응용 프로그램을 구축하기에 적합합니다.

또한 XSLT는 런타임 만 필요하며 (컴파일러 필요 없음) 텍스트 편집기를 사용하여 코드를 만들 수 있습니다. 따라서 모든 데스크탑에서 프로그램을 쉽게 만들 수 있습니다.

0
dolmen

XSLT를 두 시간 동안 광범위하게 사용했습니다. 요소 이름을 변경하거나 입력 문서를 필터링하는 등의 작업이 필요하지 않습니다.

다른 것들은 매우 빠르게 복잡해집니다. 이것은 복잡성과 다른 프로그래밍 언어 (변수와 같은)에서 사용되는 대부분의 부족과 XPath 표현식을 읽을 수 없도록 만드는 쉬운 방법을 상속합니다.

결국 XSLT는 Schisma로 고통받습니다. 프로그래머는 한계 때문에 그것을 좋아하지 않으며 다른 모든 사람들은 그것을 사용할 수 없습니다 (예 : 웹 디자이너 또는 다른 비 프로그래머 유형).

XSLT가 일종의 SQL for XML로 승격 된 경우 상황이 약간 다를 수 있습니다. 첫째, 사람들은 그것을 보려고 귀찮게하지 않았을 것입니다. 그리고 그 고통에 놀라지 않았을 사람들.

0
Aaron Digulla

나는 그 개념이 건전하다고 생각한다. 아마도 실행이 '깨끗한'것이 아닐 수도있다.

그러나 도구로 취급해야한다고 생각하지만 모든 경우에 도구를 사용하는 것이 현명하지는 않지만 솔루션을 해결할 때 도구를 무시해서는 안됩니다.

XSLT가 매우 우수하고 XSLT가 매우 잘못 사용 된 것을 보았으며 일부는 개발자의 기술에 달려 있다고 결론을 내 렸습니다. 개발자가 동시에 여러 도메인에서 생각 해야하는 것이 있다고 생각합니다.

미래인가? 더 나은 해결책이있을 수도 있습니다.

새로운 기술이 어떻게 될지 모르겠지만 적어도 그것을 배우는 것이 가장 좋습니다. 자체 툴 세트를 늘리는 것이 반드시 나쁜 것은 아닙니다.

0
Darknight

XSLT를 사용하여 매우 복잡한 XML 파일의 오류를 수정합니다. 따라서 XML의 오류를 처리하는 대신 xslt를 사용하여 오류를 수정합니다.

대단하다. 언어가 너무 강력하고 XML 사용 사례에 적합하기 때문입니다. ususal 프로그래밍 언어에서 동일한 작업을 수행하려면 새로운 맛이 생길 때마다 코드를 수정하는 데 오랜 시간이 걸렸습니다.

또한 Microsoft가 변경할 사항을 결정하지 않고도 Visual Studio 솔루션을 마이그레이션하는 데 유용합니다. 따라서 하나의 솔루션을 변환하십시오. 변경된 내용을 확인하십시오. 변경하지 않으려는 사항을 되돌리고 모든 파일에서 작업을 수행하는 xslt 스크립트를 실행하십시오.

그래서 웹 프리젠 테이션이나 이와 같은 것을하는 데 사용하지는 않았지만 XML 기반 문제에서 도움이됩니다. 이러한 문제를 해결하기 위해 정말 강력하고 살펴볼 가치가 있습니다.

0
Totonga

XSLT는 XML 변환의 전부가 아닙니다. 그러나 문제에 대한 최상의 솔루션 이었는지 또는 더 효율적이고 유지 관리 가능한 다른 접근 방법이 있는지에 대한 정보를 바탕으로 판단하기는 매우 어렵습니다. 작성자가 간단한 형식으로 콘텐츠를 입력 할 수 있다고 말합니다. 어떤 형식입니까? 텍스트 상자? 어떤 종류의 html로 변환하셨습니까? XSLT가 해당 작업에 적합한 도구인지 판단하려면이 변환의 기능을보다 자세히 이해하는 데 도움이됩니다.

0
Shmoggle

나도 XSLT의 세계에 진출했고, 그것이 장소에서 조금 어색하다는 것을 알았다. 내 주요 문제는 "순수한 데이터"XML을 완전한 HTML 페이지로 변환하는 데 어려움이 있다고 생각합니다. 뒤늦은 관점에서 XSLT를 사용하여 SSI (Server Side Scripting)를 사용하여 다른 조각과 함께 구성 될 수있는 페이지 조각을 생성했을 수 있습니다.

가능한 실수 중 하나는 document () 함수를 사용하여 XHTML 또는 다른 XML 데이터를 가져 와서 내 데이터를 둘러싸는 공통 페이지 레이아웃을 구성하려고 시도하는 것입니다.

다른 실수는 특정 값을 가진 행에 대해 서로 다른 배경 행 색상을 사용하고 필터링 할 열을 지정할 수있는 논리를 사용하여 XML 데이터에 테이블을 생성하는 일반 템플릿 만들기와 같은 프로그래밍 작업을 수행하려고했습니다.

재귀 템플릿 호출을 사용하여 해결할 수만있는 것처럼 보이는 XML 데이터에서 문자열 값 목록을 구성하려고 시도하는 것은 말할 것도 없습니다.

무엇을 얻었습니까? 글쎄, 페이지 소스는 바로 XML 데이터이며 뷰어가 사용할 수 있습니다. 데이터와 프레젠테이션은 깔끔하게 분리되어 있습니다.

다시할까요? 정적 페이지에서 데이터/프레젠테이션 분리를 원하지 않는 한 아마도 아닐 것입니다. 그렇지 않으면 아마도 템플릿을 사용하여 XML보기 또는 HTML보기를 생성 할 수있는 Rails 또는 Java EE 앱)을 작성했을 것입니다. 내 손끝에서 훨씬 더 자연스러운 (나를 위해) 프로그래밍 언어.

0
Mike Tunnicliffe

XML 문서의 트리 구조 변경에만 XSLT를 사용하는 것이 좋습니다. 텍스트 처리와 관련된 작업을 수행하고 XSLT를 XML 문서에 적용하기 전이나 후에 실행할 수있는 사용자 지정 스크립트로 전달하는 것이 번거 롭습니다.

XSLT 2.0에는 훨씬 더 많은 문자열 함수가 포함되어 있지만 언어에 적합하지 않으며 XSLT 2.0의 구현이 많지 않다고 생각합니다.

0
Ben

생산성의 측면에서 pyQuery, phpQuery 등의 jQuery 스타일 라이브러리 중 하나를 사용하는 것이 좋습니다. 대부분의 XML 라이브러리는 빠지고 XSLT는 본질적으로 본격적인 언어로 패키지되었지만 적절한 도구 세트가없는 다른 XML 라이브러리 일뿐입니다. . jQuery를 사용하면 원하는 언어로 XML 스타일 데이터를 순회하고 조작하기가 쉬워집니다.

0
Jimmy

이질성에 대해 말하면 XML은 정보 저장의 표준입니다. 많은 도구가 XML로 출력을 생성하며 앱에 브라우저를 포함시키고 XML을 형식화하여 브라우저에 넣는 것보다 더 나은 (또는 더 쉬운) 방법입니다.

0
Midhat

주어진 문제를 해결하는 것이 좋은 생각이라고 생각하기 때문에 XSLT로 작업해야합니다. 여러 XML 파일에서 일부 데이터를 추출하여 추가 처리를 수행하는 다른 도구에 대해 다른 출력 형식으로 결합해야합니다.

Fisrt XSLT는 신뢰할 수있는 표준이기 때문에 XSLT가 매우 좋은 아이디어라고 생각했습니다. 이는 코드에서 많은 프로그래밍 논리 나 알고리즘이 필요없는 간단한 형식 지정 작업에 해당됩니다.

그러나 not 절차 적이므로 단계 학습 곡선입니다. 절차 적 프로그래밍 (C, Java, Perl, PHP 등)에 익숙하다면 많은 일반적인 구조체를 놓치게 될 것입니다. 예를 들어 "재사용 가능한"코드 작성 : 절차 적 프로그래밍에서 다른 장소에서 반복해서 무언가를 수행해야하는 경우 그렇게하는 함수를 정의합니다. XSLT에서도 그러한 것들을 달성 할 수는 있지만 더 많은 코드를 작성하기 위해서는 정상적인 기능만큼 읽기 쉽고 이해할 수 없습니다.

내가 가지고있는 주요 문제는 절차 적 배경에서 오는 많은 사람들이 XSLT-Files에서 지금까지 일했으며 거의 ​​모든 사람들이 필요한 것을 "모방"했다는 것입니다.

결론적으로 XSLT는 더 이상 "궁극의"솔루션이라고 생각하지 않습니다. 실제로 XSLT에서 일부 구문을 읽거나 쓰는 것은 고통입니다. 대부분의 경우 응용 프로그램을 고려해야합니다. 간단한 변환을 위해 XSLT를 다시 사용합니다. 그러나 더 복잡한 소프트웨어의 경우 다시 사용하지 않습니다.

0
Murphy