Bagaimana cara menjaga file .phtml ramping dan bersih?


14

Seperti ekstensi file menyarankan .phtmlfile memungkinkan kode PHP untuk dicampur dengan HTML. Namun, kenyataan bahwa Anda dapat tidak harus dilihat sebagai lisensi untuk pergi liar.

Mengapa kita masih melihat begitu banyak file .phtml penuh dengan banyak PHP? Dan apa pendekatan yang baik untuk mengurangi jumlah PHP dalam suatu .phtmlfile?

Jawaban:


10

Memang, semakin sedikit PHP di Anda .phtmlsemakin baik, karena:

  1. campuran dari PHP dan HTML jauh lebih sulit untuk diuraikan daripada masing-masing secara individual, terutama bagi mereka yang nyaman dengan hanya satu dari mereka (misalnya desainer front-end)
  2. masuk akal untuk menempatkan interaksi dengan kode server di Blok, jauh dari apa yang akan disajikan di browser - ini adalah mantra "pemisahan keprihatinan" lama.

File inti Magento /app/design/frontend/base/default/template/catalog/product/price.phtml adalah contoh kasus yang menyakitkan. Kode "presentasi" HTML ini menampilkan harga. Panjangnya 471 baris! Sebagian besar karena logika PHP.

Untuk membuat Anda .phtmllebih ramping dan bersih:

  1. hindari urutan yang tidak perlu <?php … ?>, bundel bersama menjadi satu dengan satu<?php … ?>

  2. dorong PHP sebanyak mungkin ke dalam Blok, daripada .phtml

  3. untuk membantu dengan hal di atas, di Blok gunakan assign(‘myvar’, [expression])untuk membuat $ variabel yang dapat disebut tanpa $this->... di .phtml, sehingga Anda dapat benar-benar ringkas<?php echo $myvar; ?>

  4. berharap Magento untuk mengadopsi Twig di masa depan untuk tampilan yang lebih bersih

Mari kita terapkan di atas pada cuplikan dari kode asli contoh yang diberikan di atas: /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. Langkah pertama: hapus pengulangan <?php … ?> untuk sampai pada sesuatu seperti ini:

    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) ?>

Di atas menempatkan semua PHP dalam satu gumpalan kode.

2 + 3. Berevolusi menjadi sesuatu yang lebih baik lagi, pindahkan kode ini ke dalam bloknya:

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

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

Perhatikan penggunaan _prepareLayout()danassign() fungsi untuk ini.

Sekarang bagian yang berbelit-belit dari .phtml dapat dikurangi menjadi hanya garis sederhana ini:

<?php echo $minPrice; ?>

Saya pikir kita semua bisa hidup dengan itu!


5

Langgan yang bagus, @fris, saya setuju di hampir semua poin.

Takeaway utama adalah untuk memindahkan semua logika ke kelas blok dan membuat templat sebagai "bodoh" mungkin.

Saya sebenarnya lebih suka panggilan metode dalam template daripada variabel yang telah "ditugaskan" karena saya tidak ingin kehilangan pelengkapan kode IDE dan fitur navigasi. "assign" terlihat lebih ringkas dalam template tetapi terlalu ajaib untuk seleraku, membuatnya bahkan lebih buruk daripada magic getter dan setters.


Hargai komentar Anda @fschmengler. Ya itu sihir kecil, tapi itu yang terjadi dengan semua konvensi, pada awalnya. Menggunakan $ this di dalam file .phtml tentu saja terlihat seperti sulap bagi saya saat pertama kali saya melihatnya. Sekarang saya mengerti dan baik-baik saja. Ini masalah mempelajari pola & konvensi. Pelengkapan kode itu penting. Namun apakah itu panggilan yang adil untuk menempatkan pragmatisme yang berasal dari alat yang tidak cukup canggih atas keputusan pemrograman arsitektur?
fris

Menggunakan sesedikit mungkin sihir adalah keputusan arsitektur. Jika Anda memerlukan alat tambahan untuk bekerja dengan basis kode yang pertanda buruk ... Agar adil, Magento tidak membuat keputusan ini, tetapi kami dapat berusaha untuk melakukan yang terbaik dari itu.
Fabian Schmengler

fris writeup keren. Saya setuju dengan setiap poin kecuali menetapkan bagian. alasannya adalah karena menjadi terlalu sulit untuk menemukan variabel-variabel ajaib untuk pengembang lain yang sedang melewatinya. Saya pikir kita harus menghindari itu.
Rajeev K Tomy
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.