.Phtml dosyalarını yalın ve temiz tutma


14

Dosya uzantısının da gösterdiği gibi, .phtmlPHP kodunun HTML ile karıştırılmasına izin verir. Ancak, gerçeği olabilir bir lisans olarak görülmemelidir vahşi gitmek.

Neden hala çok fazla PHP ile yazılmış çok sayıda .phtml dosyası görüyoruz? Ve bir .phtmldosyadaki PHP miktarını azaltmak için iyi bir yaklaşım nedir?

Yanıtlar:


10

Aslında, ne kadar az PHP .phtmlo kadar iyidir, çünkü:

  1. PHP ve HTML karışımının her birinin ayrı ayrı deşifre edilmesi çok daha zordur, özellikle sadece bir tanesiyle rahat olanlar için (örn. ön uç tasarımcıları)
  2. tarayıcıda sunulacak olandan uzak, blokta sunucu koduyla etkileşim kurmak mantıklıdır - bu eski "endişelerin ayrılması" mantrasıdır.

Magento çekirdek dosyası /app/design/frontend/base/default/template/catalog/product/price.phtml , acı verici bir durumdur. Bu HTML "sunum" kodu bir fiyat görüntüler. 471 satır uzunluğunda! Çoğunlukla PHP mantığı nedeniyle.

Daha .phtmlyalın ve daha temiz hale getirmek için :

  1. gereksiz dizilerden kaçının <?php … ?>, bunları tek bir parça halinde toplayın<?php … ?>

  2. .phtml yerine Blok içine mümkün olduğunca çok PHP itin

  3. Yukarıdakilere yardımcı olmak için , Blokta .phtml'de assign(‘myvar’, [expression])belirtilmeyen $ değişkenleri oluşturmak için yararlanın $this->..., böylece gerçekten özlü olabilirsiniz<?php echo $myvar; ?>

  4. Magento'nun gelecekte daha temiz bir görünüm için Twig'i benimsemesini diliyorum

Yukarıdakileri, yukarıda verilen örneğin orijinal kodundan bir pasaja uygulayalım: /app/design/frontend/base/default/template/catalog/product/price.phtml

<?php if ($this->getDisplayMinimalPrice() && $_minimalPriceValue && $_minimalPriceValue < $_product->getFinalPrice()): ?>

    <?php $_minimalPriceDisplayValue = $_minimalPrice; ?>
    <?php if ($_weeeTaxAmount && $_weeeHelper->typeOfDisplay($_product, array(0, 1, 4))): ?>
        <?php $_minimalPriceDisplayValue = $_minimalPrice+$_weeeTaxAmount; ?>
    <?php endif; ?>
    ….
             <?php echo $_coreHelper->currencyByStore($_minimalPriceDisplayValue, $_storeId, true, false) ?>
  1. İlk adım: <?php … ?>şunun gibi bir şeye ulaşmak için tekrarını kaldırın :

    if ($this->getDisplayMinimalPrice() && $_minimalPriceValue && $_minimalPriceValue < $_product->getFinalPrice()) { $_minimalPriceDisplayValue = $_minimalPrice; if ($_weeeTaxAmount && $_weeeHelper->typeOfDisplay($_product, array(0, 1, 4))) { $_minimalPriceDisplayValue = $_minimalPrice+$_weeeTaxAmount; } … echo $_coreHelper->currencyByStore($_minimalPriceDisplayValue, $_storeId, true, false) ?>

Yukarıdaki tüm PHP tek bir kod bloğu koyar.

2 + 3. Daha iyi bir şeye dönüşerek, bu kodu bloğuna taşıyın:

protected function _prepareLayout() {
    $this->assign(‘minPrice’, $this->calculateMinPrice(…));
}

protected function calculateMinPrice(…) {
    if ($this->getDisplayMinimalPrice() && $_minimalPriceValue && $_minimalPriceValue < $_product->getFinalPrice()) {
       // etc...
    }
}

Bunun _prepareLayout()ve assign()işlevlerinin kullanımına dikkat edin .

Şimdi .phtml dosyasının kıvrımlı kısmı sadece bu basit çizgiye indirgenebilir:

<?php echo $minPrice; ?>

Sanırım hepimiz bununla yaşayabiliriz!


5

Güzel yazma, @fris, neredeyse her konuda katılıyorum.

Ana paket, tüm mantığı blok sınıfına taşımak ve şablonu olabildiğince "aptal" hale getirmektir.

Aslında IDE kod tamamlama ve gezinme özelliklerini kaybetmek istemiyorum çünkü şablonda "atanmış" değişkenler üzerinde yöntem çağrıları tercih. "ata" şablonda daha özlü görünmek ama benim zevkime göre çok fazla büyü, sihirli alıcılar ve ayarlayıcılar daha da kötü hale getirir.


Yorumunuzu @fschmengler için teşekkür ederiz. Evet biraz sihir, ama ilk başta tüm sözleşmelerde böyle. Bir .phtml dosyası içinde $ $ kullanarak kesinlikle ilk gördüğümde bana sihir gibi görünüyordu. Şimdi anlıyorum ve sorun değil. Bu kalıpları ve kuralları öğrenme meselesidir. Kodun tamamlanması önemlidir. Bununla birlikte, mimari bir programlama kararında yeterince sofistike olmayan araçlardan kaynaklanan pragmatizmi yerleştirmek adil bir çağrı mıdır?
fris

Mümkün olduğunca az büyü olarak kullanılması olan bir mimari kararı. Kötü bir işaret olan bir kod tabanı ile çalışmak için ek araçlara ihtiyacınız varsa ... Adil olmak gerekirse, Magento bu kararı vermedi, ancak en iyisini yapmak için çaba gösterebiliriz.
Fabian Schmengler

serin yazma fr. Bölüm atama hariç her noktaya katılıyorum. Bunun nedeni, içinden geçen başka bir geliştirici için bu sihirli değişkenleri bulmak zorlaşıyor. bence bundan kaçınmalıyız.
Rajeev K Tomy
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.