2013-04-11 2 views
1

Я в настоящее время рассматривает код и нашел CDI преобразователи, как:JSF конвертер сфера при использовании CDI (Шов 3) вид в области видимости

@Named 
@RequestScoped 
public class BankConverter implements Converter, Serializable 
{ 
    @EJB 
    private BankService bankService; 

    @Override 
    public Object getAsObject(FacesContext ctx, UIComponent comp, String identifier) 
    { 
     if (identifier == null || identifier.trim().isEmpty()) 
     { 
      return null; 
     } 

     Bank bank = null; 

     try 
     {  
      bank = this.bankService.findByPrimaryKey(Long.valueOf(identifier)); 
     } 
     catch(Exception e) 
     { 
      // omitted 
     } 

     return bank; 
    } 

    @Override 
    public String getAsString(FacesContext ctx, UIComponent comp, Object obj) 
    { 
     if (obj == null || ((Bank) obj).getId() == null) 
     { 
      return null; 
     } 

     return ((Bank) obj).getId().toString(); 
    } 

} 

Преобразователи в основном всегда так (обратите внимание на converter="#{bankConverter}"):

<p:autoComplete id="bank" 
       value="#{employeeDepotManager.selectedBank}" 
       var="bnk" 
       converter="#{bankConverter}" 
       completeMethod="#{autoCompleter.completeBankSearch}" 
       itemLabel="#{bnk.name}" 
       itemValue="#{bnk}" 
       forceSelection="false" 
       minQueryLength="3" 
       global="true" 
       validator="#{employeeDepotManager.validateBank}" 
       scrollHeight="200"> 
    <p:ajax event="itemSelect" update="bank-code bank-name" /> 
    <p:column>#{bnk.code}</p:column> 
    <p:column>#{bnk.name}</p:column> 
</p:autoComplete>      

Я в настоящее время обсуждает с коллегой о которой сфера будет лучшим для преобразователей ...

95% бобов менеджера, на которые ссылаются страницы JSF, - @ViewScoped, и поэтому я думал, что лучше всего для конвертеров быть @ViewScoped (вместо @RequestScoped, что, насколько я понимаю, воссоздает экземпляр конвертера на запрос AJAX).

Тогда мой коллега добавил, что конвертер, вероятно, должен быть @Dependent, поскольку это автоматически помещает конвертеры в область, в которой находятся окружающие бобы. Мое чувство сказало, что это не сработает. Однако я не мог не согласиться с тем, что мои знания в значительной степени заканчиваются здесь.

Итак, что могло бы быть Возможно, будет лучшим вариантом для преобразователей, когда почти все бобы, на которые ссылаются JSF, являются @ViewScoped?

PS: Обратите внимание, что мы используем Шов 3 смешивать @Named и @ViewScoped

ответ

2

Как большая часть преобразователей на самом деле являются лицами без гражданства, они могут быть легко @ApplicationScoped, что, на мой взгляд, наиболее естественный простор для их. Тем не менее, некоторые конвертеры фактически не являются. Например, DateTimeConverter позади <f:convertDateTime> тег имеет некоторое состояние. Более того, в реализации по умолчанию @FacesConverter используется Application#createConverter(String converterId), которая создает новый экземпляр конвертера, когда это необходимо, поэтому его можно создавать более одного раза для каждого запроса.

Кроме того, насколько я понимаю, пользовательские преобразователи не имеют пересечения с указанными бэкэндами в терминах области видимости, поэтому не имеет значения, являются ли они ViewScoped или нет. Что действительно имеет значение при выборе области действия конвертера, это область состояния, хранящегося в экземпляре конвертера, поскольку это было правильно определено BalusC.

Насколько конвертер в вашем вопросе фактически является без гражданства, он может безопасно быть @ApplicationScoped.

+2

Обратите внимание, что не * все * преобразователи не имеют гражданства. Например. ['DateTimeConverter'] (http://grepcode.com/file/repo1.maven.org/maven2/javax.faces/jsf-api/2.1/javax/faces/convert/DateTimeConverter.java#184) за' 'is not. Однако конкретный вопрос заключается в том, что он действительно может быть '@ ApplicationScoped'. Таким образом, ответ в конечном итоге сводится к следующему: зависит от области действия как удерживаемого в экземпляре конвертера. – BalusC

+0

@BalusC: Мне пришлось искать немного, чтобы найти пример, из которого я скопировал это (вы). Он находится по адресу http://balusc.blogspot.de/2011/09/communication-in-jsf-20.html#ProcessingGETRequestParameters. Почему вы использовали '@ ViewScoped' здесь? @All: для моего конкретного примера (и выше), поэтому, вероятно, наиболее практичным было бы аннотировать аннотацию области до тех пор, пока вы ссылаетесь на фанатичные бобы через '@ EJB' или' @ Inject'? Как только используется бит других областей, область видимости ** должна ** быть одинаковой? Я ищу ** наилучшую практику ** на самом деле ... – Kawu

+0

BalusC использовал аннотацию '@ ViewScoped' ** для управляемых компонентов ** и' @ RequestScoped' аннотации ** для конвертера **.Область запроса, используемая в конвертере, означает, что она будет создана для каждого запроса, тогда как если бы она была помещена в область приложения, она была бы создана один раз и использовалась для преобразования каждого объекта, если это необходимо. Однако последний подход может быть реализован, если ваш конвертер * не имеет состояния *. Опущение области на самом деле является плохой идеей, если вы не знаете, что делаете, потому что в противном случае вы останетесь с [по умолчанию] (http://docs.jboss.org/seam/snapshot/en-US/html /concepts.html). – skuntsel

Смежные вопросы