Karmaşık bir EL ifadesi, tek bir javabean alıcısı ile değiştirilmeli mi?


10

JSF'de koşullu olarak bir dizi değişkene dayalı olarak işlenen bir bileşenim varsa, render deyimini işlemek için en uygun yol nedir ... mantık bileşen bildiriminde veya yardımcı sınıfın bir biçiminde mi yaşamalıdır?

Metin havlaması yalnızca bir hayvan bir fil veya köpek olduğunda ve hayvan sessiz olmadığında görüntülenir.

Seçenek 1:

Görüşte uygulama:

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

veya Seçenek 2:

kapsülleme:

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

uygulama ile:

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

Yani her ikisi de işe yarıyor ... ama senaryoyu idare etmek için doğru yol hangisi?


Bu özel örnek için el. Görünüşe göre sadece veriyle ilgili veriler var. Java kodunuzda bazı mantık barking animalsvarsa, çünkü zaten var olduğundan, bu yöntemi çağırmak istiyorum. Birden fazla sitede kullandığınız bir görünüm mantığı ise, ondan bir el işlevi oluşturabilirsiniz.

İfade Dili başlangıçta Mümkün Olan En Basit İfade Dili olarak adlandırıldı, böylece amaçlanan kullanımına işaret edebilir. Kendi görüşüm: görünüm mantığı ise, EL uygun olabilir; eğer iş mantığı ise, değildir.
McDowell

Yanıtlar:


5

Çoğu durumda, bu sadece bir tat meselesidir. Endişeniz sadece durumu yeniden kullanıyorsa, şunları da yapabilirsiniz:

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

Yazmanız gereken ifade yalnızca birden fazla nesne içeriyorsa, bu genellikle yararlıdır,

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

Bence birçok kişi bu tür bir mantığı EL yerine Java'ya yazmayı tercih ediyor çünkü Java derleyicisi Java kodunda yazım denetimi yapabilir (ayrıca, çoğu IDE'nin Java için .XHTML dosyaları için daha iyi otomatik tamamlama özelliği vardır). bazı.

Bununla birlikte, bir gün başka bir yerde kullanılabilecek model hakkında bir bilgi (sadece başka bir Facelets / JSF sayfası değil), bunun Java kodunuzda yapılması için iyi bir neden olacaktır. Verdiğiniz örnekte yöntem , bir gün başka bir nesnenin (sadece başka bir Facelets sayfası değil) belirli bir hayvanın havlayıp kabuklanmadığını bilmesi gerektiğinde isBarkingAnimal()model ( Animal) hakkında bazı bilgiler verir . Yani, muhtemelen bununla giderdim.


3

Genel bir kural olarak, .xhtml dosyalarını mümkün olduğunca mantıksız tutmaya çalışın, böylece yalnızca sunumla ilgilenirler. Yani, açıkça seçenek 2 için gidin.


2
Modelin ilgilenmesi gereken mantık mı? Bir kereden fazla kullanılıyorsa, neden bir seçenek kullanarak <c:set>ya da <ui:param>olmasın takma adı ?

Bu örneğin arkasında hiçbir model mantığı yoktur. Görünüm mantığını, java içinde bile çağrılmayan java kodu üreten model mantığına kaydırırsınız. Eğer sınıf Animalbaşka bir ortamdaysa (uzak) ya da programcılar bununla alakasız davranırlar.

1

Şahsen, Seçenek # 2'yi kullanırdım. Ben EL kullanarak sorunu çözmek ve fonksiyonları veya ui: xms kullanarak xhtml belgelerde biraz yeniden kullanmak çok mümkün olduğunu biliyorum olsa da, Java fasulye uygulaması taşınabilirlik, sürdürülebilirlik ve test edilebilirlik eksikliği gibi görünüyor.

Bir geliştirici hem EL hem de Java'da akıcıysa ve hem xhtml hem de Java çekirdeklerine sahipse,> 1 boyutunda HERHANGİ BİR koşullu değerlendirme yapmak için EL'i kullanmak çok mantıklı görünmemektedir.

Java tarafında uygulamanın çok fazla faydası var gibi görünüyor:

  • IDE + derleyicisine yaslanabilme
  • Sabitleri veya enumları kullanın ("köpek" ve "havlama" için), karşılaştırmalar için kodun başka bir yerinde de kullanılıyor olabilirler ... String değeri değişirse, kod tabanı
  • Söz konusu sayfaya uygun verilerle gitmek yerine birim testleri kullanarak mantık uygulayabilirim

Seçenek 1 lehine (Stack dışında) duyduğum ana argümanlardan biri:

"Bu mantığı görünümde tutarsanız bir bileşenin ne zaman oluşturulduğunu görmek çok daha kolay."

Bunun hayatının ilk aşamasında daha hafif ve daha az karmaşık olduğu bir uygulama için geçerli olabileceğini buldum. Bununla birlikte, bu uygulamayı daha büyük bir ölçekte uygulamak ve daha küçük bir uygulama olgunlaştıkça, bir sıçan koşullu yuvaya neden olabilir ve bakımı kabus haline gelebilir. İşte benim vahşi doğada gördüklerime benzer birkaç örnek:

<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}"
/>

Ya da benim favorim, görüntülenebilecek farklı değerleri temsil etmek için birbirinden ayrı oluşturma koşullarına sahip birden fazla bileşen kullanma:

<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'}"/>

Aynı anda en fazla 4 metin görüntülenebilir mi? İlk bakışta söyleyemezsiniz, her bir durumun kontrol edilmesi gerekecektir. Bir yan not olarak, bu örneğin aynı zamanda kötü bir tasarım olduğunu anlıyorum: bunlar ac olarak konabilir: seçin ... ama bunu daha önce görmüştüm.

Günün sonunda bu, teorik olarak 'görüntüleme' mantığıdır çünkü gerçekte neyin görüntüleneceğini belirler, bu nedenle xhtml'de yaşaması gereken kavramsal bir argüman vardır. Bulduğum sorun, görünüm şablonuna böyle bir mantık dahil etmenin uzun vadede anlaşılmasını çok daha zor hale getirebileceği ve bu sorunu çözmenin bu yönteminin Java'yı kullanmanın gerçek bir faydası olduğunu henüz görmedim. fasulye uygulaması.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.