복잡한 EL 표현식을 단일 javabean getter로 바꿔야합니까?


10

JSF에서 많은 변수를 기반으로 조건부로 렌더링하는 구성 요소가있는 경우 렌더 문을 처리하는 최적의 방법은 무엇입니까? 논리가 구성 요소 선언이나 도우미 클래스의 형태로 존재해야합니까?

텍스트 woof는 동물이 코끼리 또는 개이고 동물이 음소거되지 않은 경우에만 표시됩니다.

옵션 1:

관점에서 구현 :

<h:outputText id="text" value="woof" 
  rendered="#{animal.type == 'elephant' 
                  or animal.type == 'dog' and not(animal.mute)}"/>

또는 옵션 2 :

캡슐화 :

<h:outputText id="text" value="woof" rendered="#{animal.barkingAnimal}"/>

구현 :

public class Animal {
     public boolean isBarkingAnimal() {
         return ("dog".equals(getType()) || "elephant".equals(getType())) && !isMute();
     }
...

둘 다 작동하지만 시나리오를 처리하는 올바른 방법은 무엇입니까?


이 특정 예에서는 el을 사용합니다. 관련 데이터를 보는 것 같습니다. Java 코드에 논리 barking animals가있는 경우 해당 메소드가 이미 존재하기 때문에 해당 메소드를 호출합니다. 여러 사이트에서 사용하는 뷰 로직 인 경우 뷰 로직을 사용하여 el 함수를 작성할 수 있습니다.

표현 언어는 원래 불렀다 간단한 가능한 표현 언어를 그 의도 된 사용을 암시 할 수 있도록. 내 자신의 견해 : 그것이 견해 논리라면 EL이 적절할 수있다. 비즈니스 로직이라면 그렇지 않습니다.
McDowell

답변:


5

대부분의 경우, 그것은 단순히 맛의 문제입니다. 우려가 단순히 상태를 재사용하는 것이라면 다음과 같이 할 수도 있습니다.

<ui:param name="animalCanBark" value="#{animal.type == 'elephant' 
              or animal.type == 'dog' and not(animal.mute)}" />
...
<h:outputText id="text" value="woof" rendered="#{animalCanBark}"/>

작성해야하는 표현식에 둘 이상의 객체가 관련되어있는 경우에 유용합니다.

<ui:param name="showBarking" value="#{animal.type == 'elephant'
              and not facesContext.validationFailed" />

Java 컴파일러는 Java 코드에서 유형 검사를 수행 할 수 있기 때문에 많은 사람들이 EL 대신 Java 로이 유형의 논리를 작성하는 것을 선호한다고 생각합니다 (또한 대부분의 IDE는 .XHTML 파일보다 Java에 대한 자동 완성 기능이 더 우수합니다). 일부.

언젠가 다른 Facelets / JSF 페이지가 아닌 다른 장소에서 사용될 수있는 모델에 대한 정보라면 Java 코드에서 수행해야 할 합당한 이유가 될 것입니다. 제시 한 예제에서이 메소드 isBarkingAnimal()는 모델 ( Animal) 에 대한 정보를 제공합니다. 모델 ( )은 언젠가 다른 Facelets 페이지가 아닌 다른 오브젝트가 주어진 동물 껍질이 있는지 알아야 할 때 유용 할 수 있습니다. 그래서 아마 그와 함께 갈 것입니다.


3

경험상 .xhtml 파일을 가능한 한 논리가없는 상태로 유지하여 프리젠 테이션 만 처리하십시오. 따라서 옵션 2로 이동하십시오.


2
모델이 신경 써야 할 논리입니까? 두 번 이상 사용되면 왜 별명을 사용 <c:set>하거나 별명을 사용 <ui:param>합니까?

이 예제에는 모델 논리가 없습니다. 뷰 로직을 모델 로직으로 전환하여 Java 내에서 호출되지 않은 Java 코드를 생성합니다. 수업 Animal이 다른 환경 (원격)에 있거나 프로그래머가 관련이없는 경우.

1

개인적으로 옵션 # 2를 사용합니다. EL을 사용하여 문제를 해결하고 함수 또는 ui : params를 사용하여 xhtml 문서에서 약간의 재사용을 얻는 것이 가능하다는 것을 알고 있지만 실제로 Java bean 구현의 이식성, 유지 관리 성 및 테스트 가능성이 부족한 것 같습니다.

개발자가 EL과 Java에 능숙하고 xhtml과 Java bean을 모두 소유하고 있다면 EL을 사용하여 크기가 1보다 큰 조건부 평가를 수행하는 것은 의미가 없습니다.

Java 측에서 구현하면 너무 많은 이점이있는 것 같습니다.

  • IDE + 컴파일러에 의존하는 능력
  • 상수 또는 열거 형 ( "dog"및 "bark"의 경우)을 사용하면 비교를 위해 코드의 다른 곳에서도 사용될 가능성이 있습니다 ... 문자열 값이 변경되면 문자열 값이 변경되는 경우 코드베이스
  • 적절한 데이터로 문제의 페이지를 탐색하는 대신 단위 테스트를 사용하여 논리를 연습 할 수 있습니다

옵션 1에 찬성하여 내가 들었던 주요 주장 중 하나는 다음과 같습니다.

"논리에서이 로직을 유지하면 컴포넌트가 렌더링되는 시점을 훨씬 쉽게 확인할 수 있습니다."

나는 이것이 경량이고 덜 복잡한 인생의 초기 단계에서 응용 프로그램의 경우 일 수 있음을 발견했습니다. 그러나이 방법을 더 큰 규모로 적용하고 더 작은 응용 프로그램이 성숙 해지면 쥐에게 조건부 둥지가 생겨 유지하기가 악몽이 될 수 있습니다. 다음은 내가 야생에서 본 것과 비슷한 몇 가지 예입니다.

<h:outputText value="grrr" 
    render="#{animal.type == 'dog' or animal.type == 'cat' or animal.type == 'horse' 
        or animal.type == 'pony' or animal.type == 'mule' or animal.type == 'lion'
        or animal.type == 'tiger' or (animal.type == 'bird' 
        and animal.subType == 'macaw') or .... continue this for another line or two}"
/>

또는 내가 좋아하는, 서로 다른 독점적 인 렌더링 조건을 가진 여러 구성 요소를 사용하여 표시 할 수있는 다른 값을 나타냅니다.

<h:outputText value="grr" render="#{theMonstrosityFromPreviousExample} />
<h:outputText value="cry" 
    render="#{animal.type == 'human' and animal.subType == 'baby'}" />
<h:outputText value="yo" 
    render="#{animal.type == 'human' and animal.subType == 'teenager'}" />
<h:outputText value="hello" 
    render="#{animal.type == 'human' and animal.subType == 'adult'}"/>

한 번에 최대 4 개의 텍스트를 표시 할 수 있습니까? 언뜻보기에 각 상태를 확인해야합니다. 부수적으로 나는이 예제가 ac : choose에 넣을 수 있기 때문에 디자인이 좋지 않다는 것을 알고 있습니다. 그러나 나는 이것을 전에 보았습니다.

마지막 날에는 이것이 실제로 표시되는 것을 결정하기 때문에 이론적으로 '보기'논리입니다. 그래서 xhtml에 있어야하는 개념적 논증이 있습니다. 내가 찾은 문제는보기 템플릿에 이와 같은 논리를 포함하면 레이아웃을 장기적으로 이해하기가 훨씬 어려울 수 있지만 문제를 해결하는이 방법이 Java를 사용하는 것보다 실질적인 이점을 가지고 있음을 아직 알지 못했습니다 빈 구현.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.