제출은 응답이 렌더링되는 동안 javascript를 사용하여 모든 버튼을 비활성화해야합니다.
일반적인 방법으로 구현하는 것이 가장 쉽습니다. <f:ajax>을 독점적으로 사용하는 경우 jsf.ajax.addOnEvent()을 사용하여 일반적인 방식으로 작업을 수행 할 수 있습니다. 다른 JavaScript 접근법은 최종 사용자가 더 이상 기본 페이지와 상호 작용할 수 없도록 UI를 차단하는 "로드 중"오버레이를 만드는 것입니다. 이것은 기본적으로 어떤 뷰어 전체에 걸쳐 opacity (투명도)으로 숨겨진 절대적으로 배치 된 숨겨진 <div>입니다. 제출할 때 그것을 보여주고 렌더링시 숨길 수 있습니다. 이 기술의 키워드는 "modal dialog"입니다. UI 지향적 인 JSF 컴포넌트 라이브러리는 최소한 이러한 컴포넌트를 이미 가지고있다. 예 : <p:ajaxStatus> 내부 <p:dialog modal="true">, 또는 <p:blockUI>
유일한 단점으로 PrimeFaces는 클라이언트가 JS 사용할 수있는 경우 작동하지 않습니다하거나 사용하지 않고이 때문에 더블을 제출에서 HTTP 클라이언트를 방지 할 것입니다.
그것을 말하는 세션 범위에서 플래그는 이미 활성화되어 있으므로 구분 코드는 생략하고 바로 이전의 제출에 대한 응답의 재 렌더링을 진행한다.
이 더 "synchronizer token pattern"로 알려져 있으며 지금까지 2.2 대상 표에 현재 spec issue 559에 의해 JSF에 대한 요구되었지만, 거기에 모든 활동이 될 것 같지 않습니다. 탐지 및 차단 부분은 기술적으로 구현하기가 쉽지만 최종 요청자가 궁극적으로 초기 요청에 의해 생성 된 응답을 검색하기를 원하면 동기식 대응 처리 부분을 쉽게 구현할 수 없습니다. 비동기 응답 처리는 쉽습니다. 업데이트 할 구성 요소를 지정하지 마십시오. 즉, PartialViewContext#getRenderIds()에 의해 반환 된 컬렉션을 비 웁니다. 결국 이것은 JS를 사용하여 버튼을 비활성화하거나 UI를 차단하는 것보다 훨씬 강력합니다.
알고있는 한, <s:token>을 재사용 할 수있는 JSF 구성 요소를 제안한 사람은 Seam 2뿐입니다. 그러나 이것은 새로운 OmniFaces 구성 요소에 대한 흥미로운 아이디어라는 것을 인정해야합니다. 어쩌면 개인적으로 살펴볼 것입니다.
이전 요청이 완료 될 때까지 프로세싱을 지연시키는 동기 블록. 그런 다음 이미 처리되고 건너 뛴 것으로 감지되어야합니다.
이것은 일반적으로 구현하기 쉽지 않습니다. 작업이 이미 완료되었는지 확인하기 위해 모든 작업 방법을 변경해야합니다. 또한 웹 애플리케이션이 여러 서버에서 실행되는 경우에도 작동하지 않습니다. 동기화 메소드 토큰은 조치 메소드가 호출되기 전에 수행되므로 더 쉽습니다. 싱크로 나이저 토큰은 스레드/자원의 비용만을 요구하는 큐의 여러 요청으로 끝나지 않으므로 비용이 적게 듭니다.
검출을 처리 할 수있는 변환과 같은 "새로운"범위 중 하나를 사용하십니까?
이 문제는 관리 대상 범위를 사용하여 해결할 수 없습니다. Managed Bean 범위는 다른 목적, 즉 Bean 인스턴스의 수명을 제공합니다.
jQuery blockui와 같은 것을 사용해 보셨나요? BTW 동기화 된 블록은 클러스터에서 작동하지 않습니다. –
아직 아무 것도 시도되지 않았습니다. 이것은 "잘, 어떻게합니까?" 단계. –