jQuery 및 AngularJS와 같은 JavaScript 라이브러리를 사용하여 UI를 구현할 수있는 경우 JSF의 필요성
JSF에 대해 UI 프레임 워크이며 UI 구성 요소를 제공한다는 것을 읽었습니다. 그러나 jQueryUI, AngularJS, ExtJS 또는 일반 HTML, CSS 및 JavaScript에서 사용 가능한 구성 요소의 수와 다른 점은 무엇입니까?
왜 누군가 JSF를 배워야합니까?
JSF에서 일반 JSP / 서블릿 / HTML / CSS / JS는 jQuery에서 일반 JS와 비슷합니다. 적은 코드로 더 많은 작업을 수행하십시오. 취할 PrimeFaces을 (+ jQuery를 jQuery를 UI 기반) 예를 들어, 자신을 검색 쇼케이스는 전체 코드의 예를 표시. BootsFaces (jQuery + Bootstrap UI 기반)에도 완전한 코드 예제가 포함 된 쇼케이스 가 있습니다 . 이러한 예제를 자세히 살펴보면 기본적으로 모델로 간단한 Javabean 클래스와보기로 XHTML 파일이 필요하다는 것을 알 수 있습니다.
JSF를 HTML / CSS / JS 단독의 대체로 보지 말아야합니다. 또한 서버 측 부분 (특히 JSP / 서블릿)도 고려해야합니다. JSF는 HTTP 요청 매개 변수 수집, 변환 / 검증, 모델 값 업데이트, 비즈니스 수행을위한 올바른 Java 메소드 실행 및 HTML / CSS / JS 상용구 코드 생성에 대한 모든 상용구의 필요성을 제거합니다. JSF를 사용하면 기본적으로 뷰 정의로 XHTML 페이지가, 모델 정의로 Javabean 클래스가됩니다. 이것은 개발 속도를 크게 향상시킵니다.
모든 컴포넌트 기반 웹 MVC 프레임 워크와 마찬가지로 JSF에서는 렌더링 된 HTML / CSS / JS를보다 세밀하게 제어 할 수 있습니다. 사용자 정의 JS 코드를 추가하는 것은 서버 측에서 JSF보기 상태를 고려해야하기 때문에 쉽지 않습니다 (예 : JS 측에서 비활성화 된 버튼을 활성화하면 JSF 측에서 버튼이 활성화되지 않습니다). 큰 보안 이점). 그것이 주요 쇼 토퍼라면 Spring MVC 와 같은 액션 기반 웹 MVC 프레임 워크를 찾으십시오 . HTML / CSS / JS 코드를 직접 작성해야한다는 점만 고려해야합니다 . 또한 Facelets에서 JSP로 돌아 가면 고급 템플릿 기능도 놓칠 수 있습니다.
반면에 큰 JSP / Servlet / HTML / CSS / JS / jQuery 기반 웹 사이트가 있고 반복 된 JSP / Servlet / HTML / CSS / JS / jQuery 상용구 코드를 재사용 가능한 구성 요소로 리팩토링하려는 경우 해결책 중 하나는 JSF입니다. 사용자 정의 템플릿, 태그 파일 및 구성 요소가이를 지원할 수 있습니다. 이러한 관점에서 JSF는 JSP / Servlet / HTML / CSS / JS / jQuery보다 우위에 있습니다 (그리고 JSF에 뛰어 들기 전에 이러한 기본 사항을 이해하는 것이 매우 중요합니다).
실제 킥오프 JSF 기반 프로젝트는 Java EE Kickoff App에서 찾을 수 있습니다 . JSF 옆에 좋은 HTML5 , CSS3 및 jQuery 가 포함되어 있음을 알 수 있습니다 .
또한보십시오:
- 요청 MVC와 컴포넌트 MVC의 차이점
- JSP, 서블릿 및 JSF의 차이점
- jQuery를 위해 어떤 Java 웹 프레임 워크를 선택해야합니까?
- JSF 2.0의 주요 단점은 무엇입니까?
- HTML 4/5에서 JSF + Facelets를 사용할 수 있습니까?
- <ui : include>, 태그 파일, 복합 구성 요소 및 / 또는 사용자 정의 구성 요소를 사용하는시기
JSF는 자바 상점이 jQuery와 같은 것을 배우지 않고 복잡한 JS를 구축 할 필요없이 순수한 Java 스택에 집중할 수 있도록하기 위해 만들어졌습니다. 시간이 돈이 들고 이미 Java 개발에 중점을 둔 많은 장소에서 스택의 언어 / 조각이 줄어들면 교육과 유지 관리가 더 빠르고 저렴 해집니다.
특히 프로젝트의 일부 개발자가 웹에 정통하지 않은 경우 큰 팀에서 JavaScript가 유지 관리의 악몽이되기 쉽다고 덧붙입니다.
jQuery와 같은 자바 스크립트와 프레임 워크를 사용하면 모든 유연성과 완벽한 제어가 가능합니다. ext 등을 사용하면 많은 제어력을 잃고 프레임 워크에 적응해야합니다. JSF를 사용하면 완전히 통제력을 잃고 프레임 워크에 완전히 적응해야합니다. 라이프 사이클 등에서 호출되며 마지막으로 서버 호출이 가능하고 불가능한 시점을 제어 할 수 없습니다. '특별한'것으로 여겨지는 것을해야한다면 매우 어려운 위치에있는 것입니다. 그리고 JSF 세계에서는 다중 열 테이블 정렬 또는 숫자 필드와 같은 제한된 문자 집합 만 입력 할 수있는 필드와 같은 기본 항목도 '특별한'것으로 간주됩니다.
그러나 유연성이 높을수록 더 많은 오류나 나쁜 관행을 만들 수 있습니다. 높은 유연성은 고도로 지능적인 프로그래머와 만 작동하며 다른 사람들은 프로젝트를 다루기 어려운 악몽으로 바꿀 것입니다.
그러나 JSF와 그 유연성이 제한되어 있기 때문에 항상 무언가를 수행 할 수있는 올바른 방법은 거의 없습니다. 당신은 매우 제한적이며, 지름길을 만들 수 없으며, 더 많은 XML 등을 작성해야합니다. 그러나 표준에 적응할 때 경험이 없거나 숙련되지 않은 프로그래머가 생성하는 코드를 더 잘 제어 할 수 있습니다. 결과적으로 대기업은 JSF가 '사페'하기 때문에 JSF를 좋아합니다.
내가 GWT에서 JSF로 이사했을 때, 나는 충격을 받았으며, 나에게 자연스럽고 많은 것들이 매우 비정형 적이며 달성하기 어려운 것들이 얼마나 많은 것으로 여겨졌다. 또한 GWT / jQuery 기반 앱에서 하나의 함수 생성 레이블을 변경하고 현지화 된 속성으로 수십 개의 파일을 변경 해야하는 레이블 뒤에 ':'기호를 추가하는 것과 같이 가장 작은 변경조차도 고려하지 않았습니다. 나를 제외한 누구든지 이상한 ...
jsf가 무엇이든 추가한다는 것에 동의하지 않습니다. 오버 헤드 만 추가합니다. 서버에서 UI 작업을 수행하는 것은 지금까지 들었던 가장 우스운 일입니다. 그리고 대규모 팀의 Javascript는 재사용 코드라는 훌륭한 기능을합니다.
jquery 태그를 jsp 태그로 감싸면됩니다. 필요하고 수행 한 모든 것 .jsf 및 richfaces와 관련된 .shackles 및 확장 성 문제를 견뎌 내지 마십시오.
JSF 사용의 이점은 xhtml + css + js를 생성하는 것만이 아닙니다. 때때로 JSF는 컴포넌트 기반 프레임 워크처럼 생성 할 수있는 마크 업에 제한을가합니다. 그러나 JSF는 단순한 것이 아니라 생명주기가 크게 도움이됩니다. 입력의 유효성을 검증 한 후 모델을 업데이트하고 아무런 노력없이 서버 측 Bean을 동기화 할 수 있습니다. "사용자가 여기에 입력 한 것이 무엇이든, 숫자인지 확인하고, 그렇다면 XX 개체의 YY 속성에 저장하십시오"라고 JSF가 모든 것을 수행합니다.
예, 여전히 JQuery, JS 등을 사용할 수 있습니다. 그러나 JSF는 서버 측 코드를 작성할 때 많은 이점을 제공하고 많은 보일러 플레이트에서 절약합니다.
JSF, Spring MVC, Struts, Grails, JQuery 및 ExtJS와 함께 일한 결과 Grails + ExtJS는 강력한 조합입니다.
나는 언젠가 JSF를 통해 Grails를 선택할 것이다. 클라이언트 측 프레임 워크 및 라이브러리로서 ExtJS의 완전성을 좋아하지만 JQuery보다 학습 곡선이 더 큽니다.
jQuery와 JSF의 가장 큰 차이점은 다음과 같습니다.
- MVC 아키텍처 없음
- 상태 제어 없음 (세션 또는 대화에 저장 날짜, 자동 정리 등)
- 아니오 (기본) 유효성 검사 라이브러리
- 템플릿 라이브러리 없음
- 고급 탐색 / 라우팅 없음
- 고객 입장에서
jQuery는 전체 스택 웹 프레임 워크로 사용되도록 의도 된 것이 아닙니다. 적은 수준의 코드에서 JS 작성이 더 쉽고 강력 해 지도록 저수준 JS 코드를 대체하기위한 것입니다.
따라서 HTML 요소에 동작을 추가하는 데 주로 사용됩니다.
Having used ExtJS framework for a large web application, I know how easy it is to use. The ExtJS (Schena) is best suited for (Oracle 11g) database interactions in MVC architecture. The View was for the visual / user interactions. The controller specified the 'processing' and the triggers that needed to be used form the PLSQL packages (the API for the CRUD, SQL select queries etc.). The Model and the store files were used to 'map' the data items to the Viewer / inputs.
ExtJS is not suitable for non database intensive web interfaces - where Angular JS may be a better fit.
'Programming' 카테고리의 다른 글
| SQL에서 뷰와 테이블의 차이점 (0) | 2020.07.23 |
|---|---|
| C # 4.0에서 메서드 오버로드 및 선택적 매개 변수 (0) | 2020.07.23 |
| Visual Studio 2015에는 cl.exe가 없습니다 (0) | 2020.07.23 |
| 포스트 백과 콜백의 차이점 (0) | 2020.07.23 |
| 자식 서브 모듈을 추가 할 때 "당신은 아직 태어나지 않은 지점에 있습니다" (0) | 2020.07.23 |