현재 프로젝트의 경우 HTML을 생성하거나 HTML 템플릿을 직접 사용하기 위해 XML과 XSL 변환을 사용할지 여부를 결정해야합니다.XSL 변환을 선택해야하는 이유는 무엇입니까?
나는 XSL- 접근법에 대한 논쟁에 관심이있다. 다양한 레이아웃을 지원해야하는 경우 XSL 솔루션은 많은 장점을 가지고 있지만 하나의 대상 레이아웃 만 지원해야하는 경우 왜 선택하겠습니까?
편집 : 여기서 자바에 대해 이야기하고 있습니다.
XSL 방식을 사용하면 응용 프로그램의 미래를 보장 할 수 있습니다. 미래에 레이아웃이 다른 템플릿을 추가하기로 결정하면 이러한 장점을 활용할 수 있습니다. 현재 프로젝트에서는 (XMLType 또는 CLOB에 사용 된) XML을 저장하고 다른 애플리케이션이 데이터 및 XSL 템플릿에 액세스하여 웹 서비스를 통해 문서를 생성 할 수 있도록합니다. XML/XSL을 사용하기로 결정했기 때문에 구현하기가 매우 쉬운 원본 디자인을 생각해 보았습니다.
HTML과 달리, 어떤 방식 으로든 템플릿의 구문 분석 및 처리가 필요한 경우 사용할 수있는 많은 XML 도구가 있습니다. 따라서 XML을 위해 도구와 라이브러리를 사용하여 얻을 수있는 이점을 얻으려면 XML을 선택해야합니다.
그러나 XHTML은 현대 웹 브라우저에서 올바르게 처리되는 일반 HTML 인 동시에 XML 도구 및 라이브러리를 완벽하게 지원하므로 필요에 따라 XHTML을 사용할 수 있습니다. 이후에 후 처리를해야하는 경우에도 XSLT를 XHTML 데이터에 적용 할 수 있습니다.
웹 프런트 엔드에 XML/XSLT를 사용하지 마십시오. 나는 이런 프로젝트에 있었고 그것은 끔찍한 일이다. 종종 객체 나 유사한 것으로부터 XML을 생성해야하는데, 이는 의미가 없습니다. 두 번째 요점은 무료로 제공되는 훌륭한 HTML 편집기가 너무 많다는 것입니다. 그러나 XSLT에 대해서는 아무 것도 발견하지 못했습니다. 따라서 복잡한 XSLT를 편집하는 것은 재미 없습니다. HTML 템플릿과 공통 템플릿 엔진을 사용하는 것이 좋습니다.
을 통합하는 자바 프레임 워크, 나는 정력이 정말 좋은 찾을 검토에 관심이있을 수 있습니다 XML 편집시. 또한 : Visual Studio 2008은 XML/XSLT (디버깅 포함)에 적합합니다! –
SingStar에서 작업 할 때
XSLT는 다른 문서 유형 (즉, pdf)에서 출력을 생성 할 수 있다는 장점이 있으며 pdf 출력은 현재 매우 가능성이 있습니다. XML/XSLT는 또한 뷰에서 데이터를 분리합니다.
+1 절대적으로. PDF에 대한 FOP는 좋은 예입니다. –
모든 정직한면에서 비 xml을 생성 할 수는 있지만 거의 완료되지 않습니다. 지원이 좋지 않습니다. 아마도 PDF를 제외하고. 그래서 PDF와는 별개로 중요한 요소라고 생각하지 않습니다. 소스 데이터 자체가 자연스럽게 xml이 아니라면 데이터/뷰와 관련하여 별개라고 생각하지 않습니다. 그렇다면 이미 잠재적 분리가 있습니다 (프리젠 테이션을위한 입력 데이터 -> 템플릿) – StaxMan
귀하의 데이터가 이미 XML 인 경우 XSL 접근법이 얼마나 유용 할 수 있는지보십시오.
하지만 일반적으로 그렇지 않습니다. 그것은 데이터베이스 어딘가에 자리에서 생성해야하거나 일부 서비스에서 온다.
이 소스에서 XML을 작성하면 해당 XML에서 HTML을 작성할 수 있다는 것이 제 생각에는 쓸모가 없습니다. 나는 (X) HTML 템플릿을 고수 할 것이다.
완전히 개인적인 차원에서, 저는 XSL이 모든 XML 용 아이디어의 하위라고 생각합니다. XML은 모든 솔루션에 적합한 데이터 형식이 아닙니다. –
전적으로 동의합니다 - 원본 데이터가 xml이면 xslt가 더 적합합니다. 그것이 아니라면, 아마 거의 이해가되지 않습니다. – StaxMan
다음 XSLT는 또한 당신이 XML 층에 쉽게 웹 서비스를 쓸 수 있는지, meens를 통해 XHTML로 변환하는 XML 층을 갖는, 응용 프로그램에 따라 - 고객이 사이트 데이터를 소비 할 수 있도록를 ...
변환 링크 (정확한 구문을 잊어 버렸습니다 ...)로 브라우저에 XML을 보내면 XSLT 파일이 그대로 유지되고 XML이 생성 된 원시 XML 만 전달하면되므로 필요한 대역폭이 줄어 듭니다.)
+1은 클라이언트에서 변형 할 가능성을 언급하는데, 이는 내가하는 일입니다. –
XSLT는 함수형 프로그래밍 언어이며 모든 템플릿 시스템만큼 풍부한 프론트 엔드를 생성하는 데 사용할 수 있습니다. . 하지만, 당신과 당신의 팀은 미쳐 버릴 수 없습니다.
두 옵션 모두 개체를 논리적 인 방식으로 표현 형식으로 변형 할 수있는 기회를 제공합니다.XSLT는 더 많은 XML을 만드는 데 가장 적합하며 XHTML을 작성하는 데 사용할 수있는 완벽한 후보라고 생각할 수 있습니다. 그러나 XHTML을 만드는 것이 주 목표가되어서는 안됩니다. 사용자 환경을 만들려면입니다. 매체에 신경 쓰지 마십시오.
XSLT의 두 가지 중요한 단점은 구문과 관련이 있습니다. 템플릿과 포함 된 템플릿, 템플릿에 포함 된 템플릿 모두 거대하고 자세한 정보입니다. 둘째, 많은 함수 프로그래밍을해야하며, 경험이 적은 엔지니어는 간단한 for 루프 대신 누적 함수 매개 변수를 사용하여 재귀 템플릿을 만난다면 혼란스럽고 두려워 할 수 있습니다.
논리적으로 생성 된 유효한 XML 엔터티를 변형하는 것이 매력적이라면 대신 빈을 변형하는 형식이 안전한 템플릿 시스템을 고려하십시오. Google XML Pages을 확인하고 미래의 엔지니어가 쉽게 수거하고 확장 할 수 있도록 논리적으로 구성되고 유형이 안전한 템플릿을 만듭니다.
연결된 Google XML 페이지는 2015 년 8 월 24 일부터 Google 코드 페이지로 바뀌기 때문에 아직 베타 0.2 버전입니다. – surfmuggle
이전에 XSLT를 수행했을 때 제품을 확장 할 수있었습니다. 출력은 동일하게 유지되며, 변경해야하는 프리젠 테이션 계층 만 남아 있습니다. 이로 인해 UI를 "사용자 정의"하고 싶은 클라이언트가 있었을 때 많은 유연성을 얻을 수있었습니다. 우리가해야 할 일은 모두 XSLT 파일을 대체하기 때문입니다. 이러한 종류의 변경을 많이 할 필요가있을 경우 XSLT가 답이 될 수 있습니다.
그러나 위에서 설명한 것처럼 XSLT 구문 및 함수 프로그래밍 방식으로 템플릿을 효과적으로 제작할 수 없습니다. 우리는 우리가 배운 속임수에 충실하고 싶었고, 이미 알고있는 바를 벗어난 고객의 요청이있을 때 아무도 그 티켓에 자원하고 싶지 않았습니다. 일반적으로 누군가가 결국 작업을 수행하는 방법을 알아 냈고 "트릭 백"이 커지더라도 새로운 것을 파악하는 것은 종종 매우 번거로운 작업이었습니다.
UI를 변경하지 않거나 적어도별로 신경 쓰지 않는다면 XSLT는 추가 작업을할만한 가치가 없을 수도 있습니다.
우리는 콘텐츠 관리 시스템에서 HTML을 생성하기 위해 XSLT를 사용하며 정상적으로 작동합니다.
몇 가지 힌트 : 하나의 커다란 털이 XML에서 모든 페이지를 한 번에 생성하지 마십시오. 미쳐 버릴 수 있습니다. 삽입 된 마커 (예 : <! - MENU - >, <! - CONTENT - >)가있는 HTML 템플릿 (스타일, 장식 및 기본 마크 업이있는 일반 텍스트/HTML 파일)을 사용하고 마커를 xslt-transformation으로 바꿉니다. 적절한 데이터.
당신이 단지 하나의 레이아웃 만 가지고 있다면 xslt가 정말로 필요하다고 생각합니다.
데이터 소스가 무엇인지 조사해야한다고 생각합니다. 이전에 boris callens가 언급했듯이, 데이터베이스를 가져 오려면 먼저 XML로 변환 한 다음 변환을 적용해야합니다. 데이터 소스가 RSS 등일 경우 XSLT는 당연한 선택입니다.
XPATH와 XSLT는 학습 곡선이 높으며 함수 프로그래밍은 팔을 쥐기가 어렵습니다. 시간의 위기에서 이것이 올바른 선택이 아닐 수도 있습니다.
프런트 엔드 작업용 JSON은 가벼운 페이로드를 가지고 있으며 jQuery 및 기타 Javascript 라이브러리에서 쉽게 지원됩니다. jQuery 라이브러리가 개발자들에게 훨씬 더 접근하기 쉽고 프레임 워크를 사용하는 생산성이 XSLT, 태그에 삽입 된 자바 스크립트, 끔찍한 구문 및 함께 제공되는 다른 모든 세부 사항보다 훨씬 적기 때문에 JSON을 데이터 프로토콜로 간주 할 수 있습니다. 프런트 엔드의 XML/XPATH/XSLT
나는 이전 프로젝트 금융 웹 사이트에서 XML & XSLT를 사용했습니다, 그리고 그것은 우리를 위해 잘 작동하지만, : 우리는 우리가 가진 출력의 수를 다양 여러 고객을했다
:-) 내가 XSLT를 사용하기위한 참조하는 주된 이유를 이해하기 너무 어렵지 않았다 사이트는 모두 동일한 XML을 기반으로하지만 다른 HTML 출력이 필요합니다.
포인트 1 + 3은 모든 템플릿 시스템에서 쉽게 만족합니다. –
사실입니다.그러나 당시에는 그다지 많은 사람들이 없었습니다. –
간단하게 유지하십시오. 그것은 하나가 점점 더 감사하게되는 원리입니다.
Velocity 또는 Freemarker는 믿을 수 없을 정도로 융통성이 있으며 다양합니다. 코드베이스는 명확하고 쉽게 이해할 수 있으며 X 괴물보다 훨씬 빨리 (많이) 실행됩니다.
약 5 년 전에 엔터프라이즈 제품 용 XML/XSLT 기반 UI를 만들었습니다. 우리는 여전히 그것을 사용하고, 그리고 지금은 많은 장점과 단점 내 경험을 되돌아 보면 볼 수 있습니다
장점 :
단점 HTML에 대한 스마트 최신 프로그래머 - 소수의 사람들이 XSLT를 잘 알고 있음
더 많은 문제를 생각하면 업데이트하려고 노력할 것입니다. 나는 지금 되돌아 보면, 평결은 일반적인 템플릿 언어를 고수하는 것이라고 생각한다. XML/XSLT를 선택했을 때 한 번 큰 문제는 주요 템플릿 엔진의보다 새롭고 성숙한 버전으로 해결되었습니다. 우리는 여전히 대부분의 템플릿 엔진이 잘 수행하지 않는 .xslt 파일을 상속하는 기능을 통해 많은 이점을 얻습니다. 하지만 결국 많은 예제를 제공하는 개발자의 가치는 훨씬 큽니다 (예 : StackOverflow에서 ASP.NET 응답과 XSLT 답변 비교).
희망이 있습니다!
XML + XSLT는 정말 멋지다. 앞으로 많은 유형의 대상 형식을 출력 할 수 있습니다. 하지만 XML에 포함 된 HTML을 알고 있습니다. Firefox XSLT는 "disable-output-escaping"을 지원하지 않습니다. Bugzilla을 참조하십시오.
저는 XSLT를 사용하여 상당한 발전을 이루었습니다. 두 사이트에서 엄청난 성공과 완전한 실패를 경험했습니다. 결론 전에
몇 가지 생각 :
나는 사람이 그 XSLT를 주장 할 것이다 생각하지 않는다 훨씬 더 강력한 템플릿 구문 분석 엔진보다, 그것은 기능적인 언어입니다.
대부분의 절차 언어처럼 널리 채택되지는 않았지만 실제 프로젝트에서 사용되는 실제 언어이므로 사람들은 이미 XSLT에 대한 지식을 가지고 고용 될 수 있으며 현재 직원에게 양도 할 수있는 기술입니다.
XSLT도 오래되었습니다. 구현이 성숙했기 때문에 이것이 장기간 실행되는 템플릿 엔진 (Velocity와 같은)이지만 새로운 엔진은 덜 강력 할 수 있습니다.
당신이 결정한 템플릿 언어는 XSLT만큼 잘 나타나지 않을 것입니다. 위대한 참고서를 작성하는 방법에 대한 예제는 Michael Kay Programmer 's reference series를 참조하십시오.
공구 지원은 일반적으로 매우 좋습니다 ... 예산이 있다면. XMLSpy와 Stylus Studio는 과거 나에게 매우 유용했습니다.
XSLT는 단단 할뿐만 아니라 더 중요한 것은 다릅니다. 대부분의 사람들은 컴퓨터 과학 졸업생들이 기능적 프로그래밍을 공식적으로 교육 한 사람이 아닙니다. 대부분의 프로그래머는 XSLT를 절차 적 스타일로 작성하여 언어의 힘을 불어 넣지 않고 유지 관리에 어려움을 겪을 것입니다.
XSLT 변환은 느려질 수 있으며 많은 메모리가 필요할 수 있습니다. 큰 XML 입력이있는 스타일 시트가 있으면 문제가 발생할 수 있습니다.
는 XSLT하기 위해 최선을 다하고 있습니까? XSLT에 대한 사내 전문 지식이 있습니까? 당신은 어떤 것을 얻을 준비가 되셨습니까?
데이터가 XML입니까? 그것은 XML에서 의미가 있습니까? 내부 구조를 잘 지키고 적절한 스키마가 있는지 충분한 데이터를 원하는 사람이 있습니까?
이러한 질문에 대한 대답이 '예'이고 복잡한 렌더링 프로세스가 필요한 복잡한 데이터가 아니라면 XSLT 사용을 고려하지 않습니다. 특히 팀에 경험이없는 경우 특히 그렇습니다. 잘못된 XSLT는 잘못된 템플릿보다 훨씬 나쁩니다.
그러나 오늘날 많은 템플릿 엔진을 사용하여 유지 관리가 불가능한 복잡한 데이터를 렌더링 할 수 있습니다.
당신이 [ReXSL] (http://www.rexsl.com), 실제로 XSL, JAXB 및 JAX-RS – yegor256