XSLT는 그만한 가치가 있습니까? [닫은]
얼마 전에 필자는 HTML 형식의 XML 스키마를 디자인하여 프로젝트 (교육 과정 자료)를 간단한 형식으로 작성하여 XSLT를 통해 HTML로 변환 할 수있는 프로젝트를 시작했습니다. 나는 잠시 동안 그것으로 놀았고 (매우 어려움을 겪었습니다) 매우 기본적인 수준으로 가져 갔지만 (제 지식의 한계일지도 모르는) 한계와 도랑을 제안하는 블로그를 읽을 때 너무 짜증났습니다. XSLT를 선택하고 원하는 언어로 자신의 XML을 파서로 작성하십시오. 열심히 뛰어 들었고 훌륭하게 해결되었습니다.
나는 여전히 현재까지 계속 노력하고 있으며 ( 실제로 연주하는 대신 지금 당장 작업하고 있어야합니다. ) XSLT를 버리는 결정이 좋은 것.
나는 XSLT가 그 표준을 수용 할 수 있다는 점을 알고 있으며, 모든 사람들이 자신의 통역사를 작성한다면 90 %가 TheDailyWTF에 올 것 입니다. 그러나 그것이 대부분의 프로그래머에게 익숙한 절차 적 스타일 대신 기능적 스타일 언어 라는 것을 감안할 때 , 내 자신과 같은 프로젝트를 시작하는 누군가를 위해 내가 한 길을 따라 가거나 XSLT를 사용하는 것이 좋습니다 ?
XSLT의 장점 :
- 도메인에 따라 XML이 다르므로 출력에서 리터럴 XML을 인용 할 필요가 없습니다.
- 정규식이 문자열을 쿼리하는 좋은 방법과 같은 방식으로 DOM을 쿼리하는 좋은 방법이 될 수있는 XPath / XQuery를 지원합니다.
- 기능적 언어.
XSLT의 단점 :
- 명백하게 장황 할 수 있습니다. 리터럴 XML을 인용 할 필요가 없습니다. 즉, 코드를 인용해야합니다. 그리고 예쁜 방식은 아닙니다. 그러나 다시 말하지만 일반적인 SSI보다 나쁘지 않습니다.
- 대부분의 프로그래머가 당연한 것으로 여기는 것은 아닙니다. 예를 들어 문자열 조작은 번거로운 작업 일 수 있습니다. 이로 인해 초보자가 코드를 디자인 할 때 "불행한 순간"으로 이어질 수 있으며, 웹에서 원하는 기능을 구현하는 방법에 대한 힌트를 웹에서 검색 할 수 있습니다.
- 기능적 언어.
그런데 절차 적 동작을 얻는 한 가지 방법은 여러 변환을 함께 연결하는 것입니다. 각 단계 후에는 해당 단계의 변경 사항을 반영하는 새로운 DOM을 사용할 수 있습니다. 일부 XSL 프로세서에는 한 번의 변환으로이를 효과적으로 수행 할 수있는 확장 기능이 있지만 세부 정보를 잊었습니다.
따라서 코드가 대부분 출력이고 논리가 많지 않은 경우 XSLT는 코드를 표현하는 매우 깔끔한 방법이 될 수 있습니다. 많은 논리가 있지만 대부분 XSLT에 내장 된 양식 (블라와 같은 모든 요소를 선택하고 각 출력 블라에 대해)을 선택하면 매우 친숙한 환경 일 수 있습니다. 항상 XML을 생각하는 것을 좋아한다면 XSLT 2를 사용하십시오.
그렇지 않으면 좋아하는 프로그래밍 언어에 XPath를 지원하고 유용한 방법으로 문서를 작성할 수있는 우수한 DOM 구현이있는 경우 XSLT를 사용하면 이점이 거의 없습니다. libxml2와 gdome2에 대한 바인딩은 훌륭하게 수행되어야하며 잘 알고있는 범용 언어를 고수하는 데 부끄러움이 없습니다.
자체 개발 한 XML 파서는 일반적으로 불완전하거나 (어떤 경우 언젠가는 풀리지 않을 수도 있음) 선반에서 내릴 수있는 것 (이 경우 아마도 시간을 낭비하고있는 것)보다 훨씬 작지 않습니다. 악의적 인 입력과 관련하여 심각한 보안 문제를 일으킬 수있는 많은 기회가 있습니다. 당신이 그것을 통해 얻는 것을 정확히 알지 않는 한 작성하지 마십시오. XML이 제공하는 모든 것이 필요하지 않은 경우 입력 형식으로 XML보다 간단한 것에 대한 파서를 작성할 수는 없습니다.
너무 많은 부정!
나는 몇 년 동안 XSLT를 사용해 왔으며 진정으로 그것을 좋아합니다. 당신이 깨달아야 할 핵심은 그것이 프로그래밍 언어가 아니라 템플릿 언어라는 것입니다 (이 점에서 asp.net / spit보다 필연적으로 우월하다는 것을 알았습니다).
XML은 구성 파일, 원시 데이터 또는 메모리 표시 등 오늘날 웹 개발의 사실상 데이터 형식입니다. XSLT와 XPath는 데이터를 원하는 출력 형식으로 변환 할 수있는 매우 강력하고 효율적인 방법을 제공하여 프레젠테이션과 데이터를 분리하는 MVC 측면을 즉시 제공합니다.
그런 다음 네임 스페이스를 정리하고 이종 스키마 정의를 인식하며 문서를 병합하는 유틸리티 기능이 있습니다.
있어야 자신의 사내 방법을 개발보다 XSLT 처리하는 것이 더합니다. 최소한 XSLT는 표준이자 고용 할 수있는 것이므로 팀에 실제로 문제가되는 경우 자연스럽게 대부분의 팀이 XML 만 사용하도록 유지할 수 있습니다.
실제 사용 사례 : 방금 시스템 전체의 메모리 내 XML 문서를 처리하고 최종 사용자의 요청에 따라 JSON, HTML 또는 XML로 변환하는 앱을 작성했습니다. Excel 데이터로 제공하기 위해 상당히 무작위로 요청했습니다. 전직 동료는 프로그래밍 방식으로 비슷한 작업을 수행했지만 몇 가지 클래스 파일의 모듈이 필요했으며 서버에 MS Office가 설치되어있었습니다! Excel에는 XSD가 있습니다. 3 시간 안에 최소한의베이스 코드 영향을주는 새로운 기능입니다.
개인적으로 저는 이것이 제가 경력에서 마주 친 가장 깨끗한 것들 중 하나라고 생각하며, 명백한 문제 (디버깅, 문자열 조작, 프로그래밍 구조)가 도구에 대한 이해 부족이라고 생각합니다.
분명히 나는 그것이 "가치"라고 강력하게 믿는다.
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의 (매우 늦게) 구현을 완료 할 때까지 약간 '고착'되었습니다. 그러나 여전히 거기에 있으며 제 관점에서 강력 해 보입니다.
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가 자동으로 버그 추적기에 연결되고 버그가 구성 요소별로 그룹화되며 모든 형식이 완벽하게 일치하는 멋진 릴리스 노트 (일반적으로 PDF 또는 HTML)로 끝납니다. . 또한 위의 XML은 버그 트래커에 버전 간 변경된 사항을 쿼리하여 자동으로 생성 할 수 있습니다.
XSLT가 유용한 다른 곳은 실제로 핵심 제품입니다. 때로는 타사 시스템과 인터페이스 할 때 복잡한 HTML 페이지에서 데이터를 처리해야하는 경우가 있습니다. HTML 파싱은 추악하므로 TagSoup 과 같은 것을 통해 데이터를 제공합니다.(이것은 적절한 SAX XML 이벤트를 생성하여 본질적으로 XML을 올바르게 작성된 것처럼 HTML을 처리 할 수있게합니다) 그런 다음 XSLT를 실행하여 데이터를 실제로 사용할 수있는 "안정적인"형식으로 변환 할 수 있습니다 . 변환을 XSLT 파일로 분리하면 HTML 형식이 변경 될 때 응용 프로그램 자체를 업그레이드 할 필요가 없으며 최종 사용자가 XSLT 파일을 직접 편집하거나 전자 메일로 보낼 수 있습니다. 전체 시스템을 업그레이드 할 필요없이 업데이트 된 XSLT 파일입니다.
웹 프로젝트의 경우 오늘날 XSLT보다 뷰 측을 처리하는 더 좋은 방법이 있지만 기술로는 XSLT를 확실히 사용하고 있습니다. 그것은 세계에서 사용하기 가장 쉬운 언어는 아니지만 확실히 죽지 않았으며 내 관점에서 여전히 많이 사용됩니다.
XSLT는 선언적 프로그래밍 언어 의 예입니다 .
선언적 프로그래밍 언어의 다른 예로는 정규식, Prolog 및 SQL이 있습니다. 이들 모두는 표현력이 뛰어나고 콤팩트하며 일반적으로 설계 작업에 매우 적합하고 강력합니다.
그러나 소프트웨어 개발자는 일반적으로 OO 또는 절차 언어와는 다르기 때문에 배우고 디버깅하기가 어렵 기 때문에 이러한 언어를 싫어합니다. 그들의 컴팩트 한 특성은 일반적으로 부주의하게 많은 피해를 입히는 것을 매우 쉽게 만듭니다.
따라서 XSLT는 데이터를 프리젠 테이션으로 병합하는 효율적인 메커니즘이지만 사용하기 쉬운 부서에서는 실패합니다. 나는 그것이 실제로 잡히지 않은 이유라고 생각합니다.
표준이 새로 릴리스되었을 때 XSLT와 관련된 모든 과대 광고를 기억합니다. '간단한'변환으로 전체 HTML UI를 만들 수 있다는 것에 대한 모든 흥분.
그것을 직면하자, 사용하기 어렵고 디버깅하기가 거의 불가능하며 종종 견딜 수 없을 정도로 느립니다. 최종 결과는 거의 항상 기발하고 이상적입니다.
더 나은 방법이 있지만 XSLT를 사용하는 것보다 내 다리를 더 빨리 빼낼 것입니다. 여전히 간단한 변환 작업에 적합합니다.
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 (XML 리터럴이있는 VB에서도 마찬가지)에서 일반적으로 같은 것이 몇 배 더 길었습니다. 그러나 종종 XML을 불필요하게 사용하기 때문에 처음에는 불필요하게 결함이 발생합니다.
요약하자면, 그것은 도구 상자에있는 매우 유용한 도구이지만 매우 전문적인 도구이므로 올바르게 사용하고 의도 된 목적으로 사용하는 한 좋습니다. XSLT 2.0의 올바른 네이티브 .NET 구현이 있었으면 좋겠습니다.
XSLT (더 나은 대안이 없음)를 사용하지만 프레젠테이션에는 사용하지 않고 변환에만 사용합니다.
maven pom.xml 파일에서 대량 편집을 수행하기 위해 짧은 XSLT 변환을 작성합니다.
XMI (UML 다이어그램)에서 XML 스키마를 생성하기위한 변환 파이프 라인을 작성했습니다. 그것은 한동안 작동했지만 마침내 너무 복잡 해져서 헛간 뒤에서 꺼내야했습니다.
XML 스키마를 리팩토링하기 위해 변환을 사용했습니다.
XSLT를 사용하여 실제 작업을 수행하기 위해 XSLT를 생성함으로써 XSLT의 일부 제한 사항을 해결했습니다. (런타임까지 알려지지 않은 네임 스페이스를 사용하여 출력을 생성하는 XSLT를 작성하려고 했습니까?)
필자가 시도한 다른 접근법보다 XML을 처리하는 데 더 나은 작업을 수행하기 때문에 계속 돌아옵니다.이 방법은 불필요하게 손실되거나 XML을 오해하는 것처럼 보였습니다. XSLT는 불쾌하지만 산소를 사용하면 견딜 수 있습니다.
즉, XML 변환을 수행하기 위해 Clojure (lisp)를 사용하는 방법을 조사 하고 있지만 그 접근 방식이 나에게 이익이되는지 여부를 아직 충분히 알지 못했습니다.
개인적으로 저는 완전히 다른 상황에서 XSLT를 사용했습니다. 당시 내가 작업했던 컴퓨터 게임은 XML을 사용하여 정의 된 수많은 UI 페이지를 사용했습니다. 릴리스 직후 주요 리팩터링 과정에서 이러한 XML 문서의 구조를 변경하려고했습니다. 우리는 게임의 입력 형식이 훨씬 더 좋고 스키마 인식 구조를 따르도록 만들었습니다.
XSLT는 이전 형식-> 새 형식에서이 번역에 가장 적합한 것으로 보였습니다. 2 주 안에 수백 페이지에 걸쳐 오래된 문서에서 새 문서로 작업을 전환했습니다. 또한 UI 페이지의 레이아웃에 대한 많은 정보를 추출하는 데 사용할 수있었습니다. 상대적으로 쉽게 포함 된 구성 요소 목록을 만든 다음 XSLT를 사용하여 스키마 정의에 작성했습니다.
또한 C ++ 배경에서 온 것은 마스터하기에 매우 재미 있고 흥미로운 언어였습니다.
XML을 한 형식에서 다른 형식으로 변환하는 도구로는 환상적이라고 생각합니다. 그러나 XML을 입력으로 사용하여 Something을 출력하는 알고리즘을 정의하는 유일한 방법은 아닙니다 . 알고리즘이 충분히 복잡한 경우 입력이 XML이라는 사실은 선택한 도구와 관련이 없습니다. 즉 C ++ / Python / 무엇이든 롤링하십시오.
귀하의 예와 관련하여 가장 좋은 아이디어는 비즈니스 논리를 따르는 XML-> XML 변환을 작성하는 것입니다. 다음으로 서식에 대해 잘 알고 영리한 XSLT 번역기를 작성하십시오. 그것은 좋은 중간 입장 일지 모르지만 그것은 당신이하는 일에 전적으로 달려 있습니다. 출력에 XSLT 변환기를 사용하면 인쇄 가능, 모바일 등 대체 출력 형식을보다 쉽게 만들 수 있습니다.
예, 많이 사용합니다. 다른 xslt 파일을 사용하면 동일한 XML 소스를 사용하여 여러 폴리 글 로트 (X) HTML 파일 (같은 방식으로 동일한 데이터를 표시), RSS 피드, Atom 피드, RDF 설명자 파일 및 사이트 맵 조각을 만들 수 있습니다. .
만병 통치약이 아닙니다. 잘하는 것과 잘하지 않는 것이 있으며 프로그래밍의 다른 모든 측면과 마찬가지로 올바른 작업에 적합한 도구를 사용하는 것입니다. 그것은 당신의 툴박스에 가치가있는 툴이지만 그렇게 할 때만 사용해야합니다.
나는 그것을 찌르는 것이 좋습니다. 특히 XSLT 용 편집,보기 및 디버깅 도구가 내장 된 Visual Studio를 사용하는 경우.
그렇습니다. 배우는 동안 고통이지만 대부분의 고통은 친숙 함과 관련이 있습니다. 언어를 배우면서 고통이 줄어 듭니다.
W3schools에는 다음과 같은 두 가지 기사가 있습니다. http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp
XSLT가 작업하기가 매우 어렵다는 것을 알았습니다.
나는 당신이 묘사 한 것과 다소 비슷한 시스템에서 일한 경험이 있습니다. 우리 회사는 "중간 계층"에서 반환 한 데이터가 XML로되어 있으며 페이지는 XHTML 일 수있는 HTML로 렌더링되어야하며 XSL이 XML 간 변환을위한 표준이라고 들었습니다. 형식. 따라서 "아키텍처"(심각한 디자인 사고를 생각하지만 코드를 작성하지 않는 사람들을 의미 함)는 데이터를 XHTML로 변환하여 표시하기 위해 XSLT 스크립트를 작성하여 프론트 티어를 구현하기로 결정했습니다.
선택은 비참한 것으로 판명되었습니다. XSLT는 쓰기가 어렵다는 것이 밝혀졌습니다. 따라서 모든 페이지를 작성하고 유지하기가 어려웠습니다. 우리는 JSP (Java에 있음) 또는 출력 형식 (HTML)에 대해 한 종류의 마크 업 (앵글 괄호)과 다른 종류의 마크 업 (<% ... 메타 데이터의 경우 %>). XSLT의 가장 혼란스러운 점은 XML로 작성되었으며 XML에서 XML로 변환된다는 것입니다. 3 개의 서로 다른 XML 문서를 모두 염두에 두는 것은 매우 어렵습니다.
상황은 약간 다릅니다. XSLT에서 각 페이지를 작성하는 대신 XSLT (템플릿에서 디스플레이로 변환하는 코드)에 1 비트의 코드 만 작성하면됩니다. 그러나 당신이 내가했던 것과 같은 종류의 어려움에 처한 것처럼 들립니다. 나는 당신과 같은 간단한 XML 기반 DSL (도메인 특정 언어)을 해석하려고 시도하는 것이 XSLT의 장점 중 하나가 아니라고 말합니다. (이 작업을 수행 할 수는 있지만 결국 튜링 완료입니다!)
그러나 만약 당신이 한 것이 더 단순했다면, 하나의 XML 형식의 데이터가 있고 전체 페이지 설명 DSL이 아니라 간단한 간단한 수정을 원한다면 XSLT는 그 목적을위한 훌륭한 도구입니다. 선언적 (절차 적 아님)은 실제로 그 목적에 유리합니다.
-마이클 켐 사이드
XSLT는 다루기가 어렵지만 일단 정복하면 DOM과 스키마에 대해 매우 철저하게 이해하게됩니다. 또한 XPath를 사용하는 경우 함수형 프로그래밍을 배우는 데 문제가 있으며 이는 새로운 기술과 문제 해결 방법에 노출됩니다. 경우에 따라 연속 변환이 절차 적 솔루션보다 강력합니다.
사용자 지정 MVC 스타일 프런트 엔드에 XSLT를 광범위하게 사용합니다. 모델은 xml serializaiton이 아닌 xml로 "직렬화"된 다음 xslt를 통해 html로 변환됩니다. ASP.NET에 비해 XPath와 자연스럽게 통합되고보다 엄격한 형식의 요구 사항이 있습니다 (대부분의 다른 언어보다 xslt의 문서 구조에 대해 추론하기가 훨씬 쉽습니다).
Unfortunately, the language contains several limitations (for example, the ability to transform the output of another transform) which mean that it's occasionally frustrating to work with.
Nevertheless, the easily achievable, strongly enforced separation of concerns which it grants aren't something I see another technology providing right now - so for document transforms it's still something I'd recommend.
I used XML, XSD and XSLT on an integration project between very dis-similar DB systems sometime in 2004. I had to learn XSD and XSLT from scratch but it wasn't hard. The great thing about these tools was that it enabled me to write data independent C++ code, relying on XSD and XSLT to validate/verify and then transform the XML documents. Change the data format, change the XSD and XSLT documents not the C++ code which employed the Xerces libraries.
For interest: the main XSD was 150KB and the average size of the XSLT was < 5KB IIRC.
The other great benefit is that the XSD is a specification document that the XSLT is based on. The two work in harmony. And specs are rare in software development these days.
Although I did not have too much trouble learning the declarative nature XSD and XSLT I did find that other C/C++ programmers had great trouble in adjusting to the declarative way. When they saw that was it, ah procedural they muttered, now that I understand! And they proceeded (pun?) to write procedural XSLT! The thing is you have to learn XPath and understand the axes of XML. Reminds me of old-time C programmers adjusting to employing OO when writing C++.
I used these tools as they enabled me to write a small C++ code base that was isolated from all but the most fundamental of data structure modifications and these latter were DB structure changes. Even though I prefer C++ to any other language I'll use what I consider to be useful to benefit the long term viability of a software project.
I used to think XSLT was a great idea. I mean it is a great idea.
Where it fails is the execution.
The problem I discovered over time was that programming languages in XML are just a bad idea. It makes the whole thing impenetrable. Specifically I think XSLT is very hard learn, code and understand. The XML on top of the functional aspects just makes the whole thing too confusing. I have tried to learn it about 5 times in my career, and it just doesn't stick.
OK, you could 'tool' it -- I think that was partly the point of it's design -- but that's the second failing: all the XSLT tools on the market are, quite simply ... crap!
The XSLT specification defines XSLT as "a language for transforming XML documents into other XML documents". If you are trying to do any thing but the most basic data processing within XSLT there are probably better solutions.
Also worth noting that the data processing capabilities of XSLT can be extended in .NET using custom extension functions:
I maintain an online documentation system for my company. The writers create the documentation in SGML ( an xml like language ). The SGML is then combined with XSLT and transformed into HTML.
This allows us to easily make changes to the documentation layout without doing any coding. Its just a matter of changing the XSLT.
This works well for us. In our case, its a read only document. The user isn't interacting with the documentation.
Also, by using XSLT, you are working closer to your problem domain (HTML). I always consider that to be good idea.
Lastly, if your current system WORKS, leave it alone. I would never suggest trashing your existing code. If I was starting from scratch, I would use XSLT, but in your case, I would use what you have.
It comes down to what you need it for. Its main strength is the easy maintainability of the transform, and writing your own parser generally obliterates that. With that said, sometimes a system is small and simple and really doesn't need a "fancy" solution. As long as your code-based builder is replaceable without having to change other code, no big deal.
As for the ugliness of XSL, yes it's ugly. Yes, it takes some getting used to. But once you get the hang of it (shouldn't take long IMO), it's actually smooth sailing. Compiled transforms run quite quickly in my experience, and you can certainly debug into them.
I still believe that XSLT can be useful but it is an ugly language and can lead to an awful unreadable, unmaintainable mess. Partly because XML is not human readable enough to make up a "language" and partly because XSLT is stuck somewhere between being declarative and procedural. Having said that, and I think a comparison can be drawn with regular expressions, it has it's uses when it comes to simple well defined problems.
Using the alternative approach and parsing XML in code can be equally nasty and you really want to employ some kind of XML marshalling/binding technology (such as JiBX in Java) that will convert your XML straight to an object.
If you can use XSLT in a declarative style (although I don't entirely agree that it is declarative language) then I think it is useful and expressive.
I've written web apps that use an OO language (C# in my case) to handle the data/ processing layer, but output XML rather than HTML. This can then be consumed directly by clients as a data API, or rendered as HTML by XSLTs. Because the C# was outputting XML that was structurally compatible with this use it was all very smooth, and the presentation logic was kept declarative. It was easier to follow and change than sending the tags from C#.
However, as you require more processing logic at the XSLT level it gets convoluted and verbose - even if you "get" the functional style.
Of course, these days I'd probably have written those web apps using a RESTful interface - and I think data "languages" such as JSON are gaining traction in areas that XML has traditionally been transformed by XSLT. But for now XSLT is still an important, and useful, technology.
I have spent a lot of time in XSLT and found that while it is a useful tool in some situations, it is definitely not a fix all. It works very well for B2B purposes when it is used for data translation for machine-readable XML input/output. I don't think you are on the wrong track in your statement of its limitations. One of the things that frustrated me the most were the nuances in the implementations of XSLT.
Perhaps you should look at some of the other markup languages available. I believe Jeff did an article about this very topic concerning Stack Overflow.
Is HTML a Humane Markup Language?
I would take a look at what he wrote. You can probably find a software package that does what you want "out of the box", or at least very close instead of writing your own stuff from the ground up.
I'm currently tasked with scraping data from a public site (yeah, i know). Thankfully it conforms to xhtml so I'm able to use xslt to gather the data I need. The resulting solution is readable, clean and easy to change if need occurs. Perfect!
I've used XSLT before. The group of 6 .xslt files (refactored out of one large one) was about 2750 lines long before I rewrote it in C#. The C# code is currently 4000 lines containing lots of logic; I don't even want to think about what that would have taken to write in XSLT.
The point where I gave up is when I realized not having XPATH 2.0 was significantly hurting my progress.
To answer your three questions:
- I've used XSLT once some years ago.
- I do believe XSLT could be the right solution in certain circumstances. (Never say never)
- I tend to agree with your assesment that it is mostly useful for 'simple' transformations. But I think as long as you understand XSLT well, there is a case to be made for using it for bigger tasks like publishing a website as XML transformed into HTML.
I believe the reason many developers dislike XSLT is because they do not understand the fundamentally different paradigm it is based on. But with the recent interest in functional programming we might see XSLT making a comeback...
One place where xslt really shines is in generating reports. I've found that a 2 step process, with the first step exporting the report data as an xml file, and the second step generating the visual report from the xml using xslt. This allows for nice visual reports while still keeping the raw data around as a validation mechanism if needs be.
At a previous company we did a lot with XML and XSLT. Both XML and XSLT big.
Yes there is a learning curve, but then you have a powerful tool to handle XML. And you can even use XSLT on XSLT (which can sometimes be useful).
Performance is also an issue (with very large XML) but you can tackle that by using smart XSLT and do some preprocessing with the (generated) XML.
Anybody with knowledge of XSLT can change the apearance of the finished product because it is not compiled.
I personally like XSLT, and you may want to give the simplified syntax a look (no explicit templates, just a regular old HTML file with a few XSLT tags to spit values into it), but it just isn't for everyone.
Maybe you just want to offer your authors a simple Wiki or Markdown interface. There are libraries for that, too, and if XSLT isn't working for you, maybe XML isn't working for them either.
XSLT is not the end-all be-all of xml transformation. However, it's very difficult to judge based on the information given if it would have been the best solution to your problem or if there are other more efficient and maintainable approaches. You say the authors could enter their content in a simplified format - what format? Text boxes? What kind of html were you converting it to? To judge whether XSLT is the right tool for the job, it would help to know the features of this transformation in more detail.
I enjoy using XSLT only for changing the tree structure of XML documents. I find it cumbersome to do anything related to text processing and relegate that to a custom script that I may run before or after applying an XSLT to an XML document.
XSLT 2.0 included a lot more string functions, but I think it's not a good fit for the language, and there's not many implementations of XSLT 2.0.
참고URL : https://stackoverflow.com/questions/78716/is-xslt-worth-it
'programing tip' 카테고리의 다른 글
| OpenSSL을 사용하여 공개 키를 추출하는 방법은 무엇입니까? (0) | 2020.07.28 |
|---|---|
| Android : ActionBar“홈”아이콘을 앱 아이콘 이외의 것으로 변경하는 방법은 무엇입니까? (0) | 2020.07.28 |
| Gacutil.exe은 (는) 무엇 이죠? (0) | 2020.07.27 |
| rvm pkg install zlib를 사용한 후에도 해당 파일을로드 할 수 없습니다. (0) | 2020.07.27 |
| thymeleaf와 함께 data- * 속성 사용 (0) | 2020.07.27 |