Başsız bölüm php. Bitrix düşmanının itirafı

Bitrix şablonları birkaç türe ayrılabilir:

• Ortak ve Karmaşık Bileşen Şablonları 2.0
• Web sitesi şablonları
• Diğer varlık şablonları ( posta öğeleri, haber bültenleri, web formları, ihracat oluşturucular ve çok daha fazlası)

Bileşen şablonları, şablonlama motorlarını kullanma yeteneğine bile sahiptir. Prensip olarak, herhangi bir şablon motorunu bağlayabilirsiniz, ancak kutunun dışında hayır yardımcı araçlar numara. İhtiyacı olan varsa, çalışan ve üretimde kendileri için oldukça kullanılan dal ve bıçak uzantılarına birkaç bağlantım var. Ama burada bile Bitrixoidler sapıttı. Şablonlama motoru yalnızca bileşenlerle kullanılabilir. Şablon motorunu site şablonunun oluşturucusuna veya diğer varlıklara bağlamak işe yaramaz, çünkü orada oluşturucu yok.

Bileşen şablonlarında, yerleşimleriyle ilgili başka bir can sıkıcı an vardır. Bileşen basit bir yapı kullanılarak bağlanır
$ UYGULAMA-> IncludeComponent ("bitrix: katalog.bölüm", "şablon_adı",);
İkinci parametre, bileşen şablonunun adıdır. yani bağlı olarak farklı koşullar, bu şablonun konumu en beklenmedik yerlerde olabilir:

• bitrix / bileşenler / bitrix / katalog.bölümü / şablonlar / şablon_adı
• yerel / bileşenler / bitrix / katalog.bölüm / şablonlar / şablon_adı
• bitrix / şablonlar / .default / bileşenler / bitrix / katalog.bölüm / şablon_adı
• bitrix / şablonlar / site_template / bileşenler / bitrix / katalog.bölüm / şablon_adı
• yerel / şablonlar / .default / bileşenler / bitrix / katalog.bölüm / şablon_adı
• yerel / şablonlar / site_template / bileşenler / bitrix / katalog.bölüm / şablon_adı
• bitrix / bileşenler / bitrix / katalog / şablonlar / .default / bitrix / katalog.bölüm / şablon_adı
• yerel / şablonlar / site_template / bileşenler / bitrix / katalog / .default / bitrix / katalog.bölüm / şablon_adı

Ve tüm seçenekleri listelemedim ...

Bir site şablonu bir dizi dosya olarak görüntülenebilir: header.php, footer.php (evet, sitede bunlara sahip olmalıdır), description.php ( sistem açıklaması site şablonu), template_styles.css (site şablonu stilleri), bileşen şablonları ve bir dizi daha az önemli dosya içeren bir dizin. Ve hepsi bu. Ve hiçbir şekilde etkilemeyin, bu konuda hiçbir şey yapmayın. Şablon motoru alınamıyor.

Diğer şablonlar için söylenecek bir şey yok. Ya bazı "değişken" verilerin dahil olduğu bir düzen şeklinde veritabanında saklanırlar ya da aptalcadırlar. php dosyası veritabanından parametre almaktan bilgileri görüntülemeye kadar tüm işi yapan . Örneğin, pazar için YML dosya oluşturucusuna bakabilirsiniz. Buraya koymanın bir anlamı yok, çünkü yeterince büyük, yaklaşık 2k satır. Kim ihtiyaç duyarsa onu google'da arayacaktır, /bitrix/modules/catalog/load/yandex_run.php içindedir.

dosya doğası

Yukarıda açıklığa kavuştuğu gibi Bitrix mimarisinde her şey çok iyi değil. Ancak Bitrix'in mimarinin bir önemli yönü daha var.
Bitrix, yarım dosya CMS'dir. Pek çok şey bir tür dosya tarafından kontrol edilir:

• Bir sayfaya ihtiyacınız var - bir dosya oluşturun
• Bir dizi sayfaya ihtiyacınız var - bir dosya oluşturun ve bilgi bloklarıyla çalışan bir bileşen ekleyin
• Sayfa için bir başlık belirlemeniz gerekiyor - dosyayı düzenleyin
• Bölümün tüm sayfaları için bir başlık belirlemeniz gerekir - bu bölümün kökünde özel bir file.section.php oluşturun
• Hakları düzenlemeniz gerekiyor - file.access.php dosyasını düzenleyin
• Sistem başlatmadan önceki ayarlar - dbconn.php, .settings.php ve .settings_extra.php dosyalarında
• sonuç_modifier.php, component_epilog.php, init.php, .parameters.php, .description.php ....

Ve Bitrix'e dağılmış çok sayıda özel dosya var. Bir yandan bu, sistemle çalışırken belirli bir esneklik sağlar. Öte yandan hem geliştirici hem de site yöneticisi için ızdıraba dönüşebilir. Sayfa dosyaları bazen php kodu, düzen ve eklenti bileşenlerinden oluşan bir karmaşaya dönüşür. Sonuç olarak, görsel düzenleyici bu dosyayı yanlış bir şekilde ayrıştırabilir ve düzenlerken kolayca görüntüleyebilir. php etiketleri bazı yerlerde, bu sayfanın çalışmamasına yol açacaktır. Bu tür dosyalara php kodu yazmaya gerek yok mu diyorsunuz? Evet biliyorum. Ancak Bitrix çok sık ve sizi bunu yapmaya zorlayan başka bir alternatife sahip değil.
Ve kafada, ne tür dosyalar oldukları ve hangi verileri içerebilecekleri hakkında sürekli bilgi tutmanız gerekir. Farklı dosyalar, farklı yapıda farklı veriler içermelidir ve her seçenek için bunu hatırlamanız gerekir. Her seferinde belgelerde aramak zor iştir.

Yukarıdakilere ek olarak

Bitrix'te her şeyin ne kadar kötü düzenlendiğinden hiç durmadan şikayet edebilirsiniz. Benim düşünceme göre, tüm bu şikayetler tek bir ifade ile karakterize edilebilir - "bir şekilde sona ermeyecek". Ve gerçekten, Bitrixoidler aniden bir özelliği duyurursa, bir şekilde onu tamamen serbest bırakmayacaklar, bitirmeyin, akla getirmeyin. Pek çok örnek var:

• uygulanmış ORM - tamamlamadı, tam olarak kullanamazsınız
• bir otomatik yükleyici yaptı, standartlara göre değil, yalnızca modüllerde çalışır
• şablon motorunu bağlamayı mümkün kıldı, ancak onu her yerde kullanamazsınız ve tamamen değil
• vesaire. vesaire.

Özetle, her gün yüzleşmemiz gereken diğer sorunları tanımlamaya çalışacağım.

Admin Paneli

Eğer biri admin paneli ile çalıştıysa, sayfalarını Bitrix'in önerdiği şekilde yönetim kısmında oluşturduysa beni anlayacaktır. Sadece cehennem. Bitrix bilmeyenler için her sayfa için bir erişte dosyası kullanmanızı önerir. Örneğin, Bitrix geliştiricileri tarafından gerçekleştirilen admin panelindeki detaylı sipariş görüntüleme sayfası 4k satırdan fazla alıyor. Bu dosyanın içeriğini görüntülerken IDE'm yavaşlamaya başlıyor. Orada php, js ve html var. Eh, en azından SQL'den kurtulduk, ancak diğer admin sayfalarında olduğundan eminim.
Ve yönetim sayfalarının aynı bileşenlerle çalışmasını engelleyen şey net değil. Yönetici sayfalarının çoğunu özelleştirmenin bir yolu yoktur. Bileşenler söz konusu olduğunda, bu çok kısa sürede yapılabilir.
Bu arada, kibar insanlar yönetim sayfaları oluşturmanıza yardımcı olacak bir modül yapmışlar.

js çerçevesi

Bitrix, bir tür istemci çerçevesi görevi gören bir js bileşenine sahiptir. Geliştiricilerin hiçbiri birkaç nedenden dolayı beğenmedi:

• neredeyse belgesiz
• o canavarca
• çoğu kişiye tanıdık gelen jquery'yi büyük ölçüde çoğaltır

Bitrix, bileşenlerinde çok sık kullanır ve bu nedenle geliştiriciler arasında daha da fazla öfkeye neden olur. Bu kütüphanenin küçültülmüş haldeki çekirdeği 85 kb'dir ki bu çok büyüktür. Bitrix'in tüm özelliklerini (bileşik, varlık yönetimi) kullanmak istiyorsanız, onu bağlamaktan kaçınamayacaksınız.

kopyala-yapıştır ruhu

Son zamanlarda, giderek daha az, ancak yine de oldukça sık, Bitrix kopyalayıp yapıştıracak bir şeyler yapıyor. Bir bileşenin çalışmasını değiştirmek istiyorsanız - kopyala-yapıştır. Kendi boşaltma şablonunuzu oluşturmak istiyorsanız, sistem kopyasını kopyalayın ve bitirin. Neredeyse sahip olduğunuz şablonun aynısını yapmak istiyorsanız - kopyalayıp yapıştırın ve biraz değiştirin. Ve bu, yeni başlayan geliştiriciler için kurslarda bile konuşuluyor. sözüm yok

Varlık yönetimi ve CDN

Bitrix'te kaynakları yönetme şeklini gerçekten seviyorum. Prensip olarak, bir dizi özel "kütüphane" kaydetmek mümkündür. Her kitaplık, diğer bazı kitaplıklara bağlı olabilecek bir dizi css / js dosyasıdır. Sayfaya bir kitaplık bağlarsanız, onu bağlamadan önce tüm bağımlılıklar çözülecek ve tüm bağımlı kitaplıklar sayfaya eklenecektir. Her şey yolunda görünüyor, forma yalnızca her kaynak eklenecek ayrı bir dosya bir komut dosyasına veya bağlantı etiketine dönüştürün. Ve bu sayede 30-50 betiği ve aynı sayıda stil dosyasının bağlı olduğu siteler var.
Bitrix'te boktan soru dediler ve tüm bu dosyaları tek bir dosyada birleştiren sihirli bir onay işareti yaptılar. Ve 50 komut dosyası yerine her biri 300-500 kb olan 2 tane olan siteler vardı. Bir süre önce, bu birleştirme hatalarla çalıştı ve aynı kaynakları birkaç kez birleştirdi, ancak şimdi düzeltilmiş görünüyor.
Ve sonra Bitrixoids çıktı - tüm kaynakları bir CDN sunucusuna yüklemeyi mümkün kıldı. Hangi sonsuza kadar düşer ...
Ardından, tüm kaynakların sayfanın altına bırakılmasını öneren Google Pagespeed Insights geldi. Ve Bitrix'te yine, özel bir nitelikle işaretlenmemişlerse, vücuttaki tüm kaynakları aptalca atlayan sihirli bir onay işareti yaptılar.
Ayrıca, yönetici panelinde başka bir sihirli onay kutusu kullanıldığında bağlanan kutuyla birlikte komut dosyalarının küçültülmüş sürümlerini de dağıtırlar.
Genel olarak, sizin için scss yok, TypeScript yok. Kaynakları düzgün bir şekilde yönetmek istiyorsanız - yerleşik Bitrix sistemini kullanmayın, Bitrix ile kolayca arkadaş olabileceğiniz web paketini kullanın.

Çoklu site / çok dilli

Bu muhtemelen ürünün başlangıcından bu yana devam eden en kötü geliştirici baş ağrısıdır. Öylece alıp çok dilli bir web sitesi oluşturamazsınız. Ve farklı fiyatlar ve para birimlerine sahip çok dilli bir kataloğa ihtiyacınız varsa, o zaman una dönüşür ve bunun için de büyük bir meblağ ödemeniz gerekir (sitenin bir sonraki dil sürümü için ek bir lisans satın almanız gerekecektir) .
Çok dilli ve çok para birimli bir site oluşturuyorsanız, Bitrix'in buna çok agresif bir şekilde direneceği gerçeğine hazırlıklı olun. Çoklu site ayarları, yönetici alanı boyunca merkezi değildir. Yönetici panelindeki her varlığın sitenin dil sürümüne kendi bağımlılığı vardır. Bazı varlıklar site/dil bağımlılıklarını hiç desteklemeyebilir ve bazılarının dile yalnızca açık bir bağlantısı vardır, bu nedenle bu varlığı çoğaltmanız ve ardından desteklemeniz gerekir.
Temel sürümde, bilgi bloğunun birkaç dilde çalışmasını sağlamak için bu bilgi bloğunun bir kopyasını oluşturmanız gerekecektir. Ancak pratikte kimse bunu yapmaz ve bir varlığı merkezi olarak depolamak, dile bağlı niteliklerini diğer depolara yaymak için kendi yollarını bulmaya çalışmaz.
Yerelleştirme için varsayılan dili ayarlayamazsınız. Rusça bir cümleyi tanımlayan bir dil değişkeniniz varsa ve bu dil değişkeni İngilizce değilse, o zaman İngilizce sitesinde boş bir dize gösterilir ve bunu hiçbir şekilde etkileyemezsiniz (çoğu durumda, bırakabilirsiniz). Rusça ifade, böylece boşluk kalmaz).

Hak yönetimi mekanizması

Bu alt sistemle çok uğraşıyoruz. Bir varlığı görüntüleme haklarını neden verdiğinizi anlamak genellikle zordur, ancak kullanıcı bunları kullanamaz. Örneğin bir infoblock düzenleme hakkı vermek için /bitrix/admin dizinine erişim vermeniz, belirli bir infoblock için yetki vermeniz ve ana modülde yetki vermeniz gerekir. Bir varlığa izin vermek için çok fazla işlem yapılması gerekiyor. Ve yeterli haklar yoksa, kaynak koduna bakmadan nedenini anlayamazsınız.

yapılandırma

Bitrix, sistem ayarlarını yönetmenize izin verecek merkezi bir hub'a sahip değildir. Ayarlar yine sistem genelinde dağıtılmıştır. Seçenekler, modül ayarlarında, bileşen ayarlarında, COption'da (yönetici paneline taşınmıyor) mevcuttur. Yönetici panelinde, bir modülün seçenekleri, tamamen farklı yerlerde bulunan 3-4 farklı sayfaya bölünebilir. urlrewrite, yönetici panelinden düzenlenebilir! Şimdi ayrıca .settings ve.settings_extra. Bazen hangisinin daha yüksek önceliğe sahip olduğu tamamen belirsizdir, çoğu zaman seçenekler için yeterli açıklama yoktur, ilişki net değildir. Geliştiriciler arasında yapılandırmayı paylaşmanın yerel bir yolu yoktur.
Ayarlar çok mantıksız olabilir. Bazen saçmalık noktasına geliyor ... büyük veri bileşenine bakın - hazırlıksız bir kişi bunu özelleştirebilir mi?

1C ile entegrasyon

Bu, oldukça fazla sayıda müşterinin gagaladığı Bitrix özellikleri listesindeki öğedir. Bitrix, içeriği ve belgeleri bir sistemden diğerine anında iletecek 2 tıklamayla 1C ile iki yönlü bir site entegrasyonu kurmayı vaat ediyor.
Evet, gerçekten öyle, ancak birkaç uyarıyla.
İlk olarak, ek çaba harcamadan entegrasyonu kutudan çıkarmak için, her şeyi tam olarak Bitrix belgelerinde yazıldığı gibi yapmanız gerekir - sitede Bitrix'in sunduğu kurallara göre bir dizin oluşturun ve Bitrix'in 1C'de bir katalog oluşturun gereklilikler. İdeal olarak, her şeyi sıfırdan yaratın ve sonra belki her şey sizin için kutudan çıkarsa işe yarar.
İkincisi, Bitrix, kutudan çıkan tüm 1C konfigürasyonlarıyla uyumlu değildir. önceden okumakta fayda var
Üçüncüsü, ideal bir dünya yoktur. Genellikle bir web sitesi isteyen bir müşterinin zaten bir perakende işi vardır, bu da zaten büyük bir çöp kutusu olan 1C'ye sahip olduğu anlamına gelir. Ve bu çöpler siteye atılabilir. Ve sitenin aynı çöp kutusunu almaması için, değişim mekanizmasını önemli ölçüde değiştirmek gerekiyor.
Çoğu zaman, müşterinin gereksinimleri Bitrix ekibi tarafından oluşturulan ürün vizyonundan büyük ölçüde farklıdır ve daha sonra değişim mekanizmasının değiştirilmesi, emek yoğunluğu açısından benzersiz bir değişim modülünün geliştirilmesine kıyasla oldukça pahalı olabilir. özel bir durum.
Bu nedenle siteyi 1C ile kolayca entegre edebileceğinizi hayal etmeye çalışmanıza gerek yok. Bunların hepsi pazarlamacıların entrikalarıdır.

1C ile değişimi geliştirmek de ayrı bir konudur. \ CIBlockCMLImport sınıfı, dizinin değişimini organize etmekten sorumludur. - 5.7k satır. En sık uzantı gerektiren ana yöntemlerden biri - \ CIBlockCMLImport :: ImportElement, 1k'den fazla satır içerir. Bir kez devralmak, ürünü birkaç kez uzun süre güncellemek yeterlidir ve 1C ile çalışmayan bir takas alabilirsiniz. Bu nedenle, geliştiriciler genellikle bu sınıfa girmez ve olay işleyicileri kullanarak bir şekilde içe aktarma işlemine girmeye çalışır. Bitrix'te, özellikle de bilgi bloğu modülünde olay işleyicilerle çalışmak, yalnızca aynı türdeki olayların tek tip olarak düzenlenmemesi ve bazı olayların yeterli olmaması nedeniyle de pek hoş bir deneyim değildir.
Genel olarak, bu durum eskisi kadar üzücü.

Tutarsızlık

Bazen bana farklı modüllerin geliştiricileri birbirleriyle gerçekten iletişim kurmuyormuş gibi geliyor. Çekirdeğin kaynak kodunu incelerken, aynı motor üzerinde yürütülebilecek çok heterojen çözümlerle karşılaşıyorsunuz, ancak bir nedenden dolayı farklı şekillerde uygulanıyorlar.
Örneğin, infoblocks ve UserField öğelerinin özelliklerini alabilirsiniz. Hem biri hem de diğer varlık aslında başka bir varlık için ek bir alandır. Bir türü, bir anlamı ve bir açıklaması vardır. Değer, veritabanının ayrı bir tablosunda/tablolarında saklanır, kabaca benzer bir veri erişim arayüzüne sahiptirler. Öyleyse neden onları aynı arayüz yapmıyorsunuz?
Mart ayının sonunda, satış modülü şu şekilde güncellendi: En son sürüm ve orada ayrıca siparişler için keyfi mülkler vaat ettiler. Şimdi bir varlığın genişletilmiş özellikleriyle çalışmak için yeni, üçüncü bir arayüz var mı?

Bitrix24

Bu genellikle konuşma için ayrı bir konudur. Karışıklık genellikle bu sistem temelinde ortaya çıkar. B24'ün 2 sürümü vardır - SaaS ve Standlone. B24 için bir pazar yeri var, ancak yalnızca SaaS sürümü için uygulamalar içeriyor! 200 adetlik kutulu bir sürüm satın aldıysanız, belge oluşturucu gibi popüler uygulamaları yükleyemezsiniz ve genel olarak Bitrix24 pazarından herhangi bir uygulamayı Bitrix24'ünüze yükleyemezsiniz. İşte bir paradoks.
Bunun yerine, Bitrix24'ünüzde normal sürümden bir pazar yeri bulunacaktır. Piyasada çok daha fazla çözüm var, ancak bunlar esas olarak B24'te değil, Site Yönetimi'nde yoğunlaşıyor.

Bitrix24, departmanda bana söylendiği gibi teknik Destek, tam bir sistemdir. Standart sistem bileşenlerinin çalışmasına müdahale ederseniz, bu işlevin sonraki güncellemelerle bozulacağına hazırlıklı olun. Bitrix, müşterilerini resmi olarak iş ortaklarına göndermelerine rağmen, portal bileşenlerini tamamlamanız konusunda size güvenmeyecektir.

Bu arada, bileşenleri rafine etmek için kutulu versiyon B24 başka bir sorun. İle js kodu üreten bileşenler ajax kullanmak hitap eder php kodu yanıt olarak html + js üretir. Bu, gerçekten dalmak istemeyeceğiniz cehennem gibi bir karışım.

belgeler

Bitrix belgeleri, ürün geliştirmenin 1-1,5 yıl gerisinde kalıyor. Kod, phpDoc "s tarafından çok zayıf bir şekilde kapsanıyor ve genellikle sınıfın önündeki yorum yalnızca "göstermek için", IDE'de otomatik olarak oluşturuluyor.
Resmi kaynaklardaki belgelerin sunum tarzı genellikle çok "özgür"dür ve belgelerdeki bazı makalelerin içeriğinin Bitrix'in kendisiyle hiçbir ilgisi olmayabilir.
Geliştiricinin kursunda çok fazla bilgi var, ancak geliştiricinin sistemin yeteneklerini tanıttığı format, gerekli algı düzeyini sağlamaz. Symfony Yemek Kitabı'na giderseniz, her şey raflara yerleştirilir, sürüme bağlı olarak gerekli tüm yönler açıklanır. Bitrix'te ise geliştiricinin eğitim kursu, hangi prensibe göre, önce ayrı olarak sunulan ve daha sonra karıştırılan, yeni başlayanların baş ağrısına sahip olduğu eski ve yeni çekirdekler hakkında yapılandırılmış bilgiler içerir.

Geliştirme sürecinin organizasyonu

Sistemin özgünlüğü nedeniyle, uygun bir geliştirme sürecini organize etmek o kadar kolay değildir. en değil taze versiyon Kurulumdan sonra Business sürümü (el altındaydı), bir düşünün, neredeyse 530 megabayt
$ du -s * | sort -nr | cut -f 2- | okurken a; du -hs yapın $ a; tamamlandı 523M bitrix 204K yükleme 64K bitrixsetup.php 56K desktop_app 20K readme.html 20K lisans.html 4.0K web . config 4.0K urlrewrite.php 4.0K benioku.php 4.0K lisansı.php 4.0K install.config 4.0K index.php
Bu hacmin iyi bir yarısı, genel olarak sürüm kontrolü için gerekli olmayan ikili dosyalar ve yükleyicilerdir. Genel olarak konuşursak, bitrix çekirdeğini sürümlendirmemek gelenekseldir. Bitrix geliştiricileri, çekirdeğin bütünlüğünü kendileri garanti eder, güncellemeler sırasında farklı modüllerin sürümlerinin bağımlılıklarını yönetir. Ancak bu hemen en az bir büyük dezavantaj taşır - tam olarak çalışan bir projeyi sürüm kontrolünden tek bir komutla dağıtmak imkansızdır, onu parçalar halinde birleştirmeniz gerekir: çekirdek kaynağını bitrix yedeklemesinden ve geliştiricilerin kaynağını git'ten alın .
Baz da iyi değil. Geliştirme sırasında geçişleri kendiniz kullanabiliyorsanız, Bitrix, kontrol edemediğiniz sıradan komut dosyalarını kullanarak güncellemeleri veritabanına alır. Bu nedenle, güncellemeler sırasında, yine de veritabanı yedeklerini merkezi geliştirme ana bilgisayarından diğer geliştiricilere aktarmanız gerekecektir.
Nazik insanlar, tüm bunları düzenlemeye yardımcı olan araçları bir kez daha gördüler, ancak ne yazık ki Bitrix'i bu kurallara uymaya zorlamak hala mümkün değil.
Resmi olarak Bitrix, bir dağıtım setinin 2 kopyasına sahip olmanıza izin verir. Biri üretim için, diğeri geliştirme için. Bir projede birden fazla geliştiriciniz varsa, o zaman olduğu gibi yasa dışısınızdır) Aslında, Bitrix makinesi için www.bitrixsoft.com'dan gelen ve giden bağlantıları kesmeniz yeterlidir ve sonra siz geliştirmenin istediğiniz kadar kopyasını perçinleyebilir, ancak kendi başlarına güncellenemezler.

Meslektaşlar

VE son soru dokunmak istediğim.
Bitrix'in giriş eşiğinin düşük olması nedeniyle bu pazarda hizmet veren firmalar arasında vasıfsız personel sayısı oldukça fazladır. Kariyerim boyunca (toplamda yüzden fazla) 1C-Bitrix'te yürütülen birçok farklı proje gördüm. Bunların %95'inin "domuz gafı" yapıldığını güvenle söyleyebilirim. Çok nadiren, gelişimi için bir yaklaşımın hissedildiği projeler vardı, ancak bunlar sadece birkaçıydı. Bütün bunlar çok üzücü.

sonuçlar

Tabii ki, bir makaledeki tüm dezavantajlar dikkate alınamaz. Her gün, her gün işinizi engelleyen bazı küçük şeylerle karşılaşıyorsunuz. Ancak tüm bu önemsiz şeyleri düşünmek imkansızdır ve muhtemelen hiçbir şey için değil.

Buradan ne gibi sonuçlar çıkarılabilir. Bitrix, kötü düşünülmüş bir mimariye sahip olması, üründe uzun süre yaşamaya devam eden birçok kusur nedeniyle son derece karmaşık bir sistemdir. Öte yandan Bitrix, çerçevelerden farklı olarak başlamak için çok daha düşük bir beceri seviyesi gerektiren oldukça basit bir sistemdir.
Bu ürünü desteklemek Symfony, Laravel, Yii gibi ürünlere kıyasla çok nafile bir iştir. Ürün, hem deneyimsiz hem de deneyimli geliştiricilerin tekerleklerine bir jant teli koymaya çok düşkündür, bu da Bitrix için deneyimli geliştiricilerin hizmetlerinin maliyetini etkileyebilir.

Bu sistemle çalışmak için bu kadar zaman harcadığım için pişman mıyım? Hayırdan ziyade evet. Bu zamanı daha doğru ve daha mantıklı bir şey öğrenmeye harcamak daha akıllıca olacaktır (şu anda aktif olarak yapmaya çalışıyorum). Ama öyle oldu ki, yolculuğumun başında beni doğru yola yönlendirecek kimse yoktu.

Yeni başlayan bir php geliştiricisiyseniz, Bitrix Symfony, Laravel, Yii, ZendFramework gibi öğrenme çerçevelerini tercih eder. İnanın ilerde faiziyle ödeyecek. Bu çerçevelerden herhangi birinde uzmanlaştıktan sonra, gelecekte Bitrix için bir şeyler geliştirmeniz zor olmayacaktır. Başka seçeneğiniz yoksa Bitrix'i inceleyin, ancak boş zamanlarınızda beyninizi yerine oturtmak için kendinizi çerçeveler dünyasına daldırmaya çalışmak daha iyidir.

Bitrix'te deneyimli, ancak diğer çerçevelerde deneyimi olmayan bir geliştiriciyseniz, başka bir dünyaya daldığınızdan emin olun, 1C-Bitrix için çok daha iyi çözümler yazmanıza yardımcı olacak birçok yeni ve faydalı bilgi keşfedeceksiniz. Projelerinizde diğer çerçevelerden çözümler kullanmaya çalışın, çünkü bunu ikincisinin ve bestecinin bileşen yaklaşımı sayesinde yapmak zor değil.

Bir müşteriyseniz, Bitrix pazarlamacılarına güvenmeyin. Bitrix sunumlarında hiçbir şey söylendiği kadar kolay olmayacak. Ve geliştiricilerinizi suçlamayın, bununla hiçbir ilgileri yok. Eldorado / mvideo / sportmaster düzeyinde büyük ve karmaşık bir çevrimiçi mağaza oluşturmak istiyorsanız, belki de Bitrix en iyi seçim olmayacaktır.

UPD. Yazının Bitrix çalışanları tarafından okunduğu görülüyor. Pazarlama ile ilgili bölümde Bitrix geliştirici kursunun Mimari bölümünde pazarlama çağrılarının yazıldığını yazmıştım. Şimdi orada değiller. Kendilerini bile mühürlediler, görünüşe göre aceleleri vardı.

Gözleminiz ve keskin bakışınız için teşekkürler :)

Etiketler:

• 1c-bitriks
• cms
• web Geliştirme
• sandık odası
• nefret dolusu
• habr'da sızlananlar
• Kendini tut

Etiket ekle

Bölümleme kategorisindeki HTML bölüm öğesini araştıran bir makale.

Bölüm öğesinin amacı

Bölüm öğesi, bir belgede bazı konu içeriğini birlikte gruplayan bir bölüm oluşturmak için kullanılır. Belgedeki her bölüm için adı (konu) belirtilmelidir. Bu genellikle başlıklarla (h1-h6 öğeleri) yapılır.

Bölüm başlığı

Bölüm içeriği...

Bölüm öğeleri genellikle aşağıdaki durumlarda kullanılır:

• Bir bölüm içindeki bölümleri işaretlemek için. Örneğin, bir makaledeki bölümleri, bir iletişim kutusundaki sekmeleri, bir tezdeki bölümleri vb. işaretlemek için.
• birkaç bölümü tek bir tematik grupta gruplamak için. Örneğin, gruplama için son Haberler web sitesinde, makaleyle ilgili yorumlar vb.

Bu nedenle, bölüm öğesi yalnızca bir başlığı varsa ve başka bir şeyin parçasıysa bazı içerikler için kullanılmalıdır.

Bölüm öğesini kullanma

Örneğin, yorumlar içeren bir makale içeren bir sayfa kodu pasajı düşünün. Kullanıcı tarafından sayfada yayınlanan yorumların her biri bir miktar eksiksiz içerik içerir ve bu nedenle bir makale öğesi olarak kabul edilebilir. Ancak aynı zamanda tüm yorumlar belirli bir tematik grubu temsil eder ve bu nedenle bölüm öğesine, yani. verilen eleman sayfadaki tüm bu yorumları birlikte gruplayacaktır.

Makale başlığı

Yorumlar (1)

Yorum başlığı

Yorum metni...

Yorum başlığı

Yorum metni...

Makale Başlığı Yorumlar Yorum Başlığı Yorum Başlığı

Örneğin, bir makale öğesi içinde bölümler oluşturmak için bölüm öğelerini kullanmayı düşünün:

Kitap başlığı

İlk bölüm

İkinci bölüm

Üçüncü bölüm

Ek Bölüm A

Ek B

Yukarıdaki örnekte aşağıdaki ana hat olacaktır:

Kitap Başlığı Birinci Bölüm İkinci Bölüm Üçüncü Bölüm Ek A Ek B

Bölüm Öğesini Kullanmanın Sınırlamaları

HTML 5'teki bölüm öğesi, içeriği gruplamak için genel bir öğe değildir, yani. Beğendiğiniz herhangi bir içeriği sarmak için kullanılmamalıdır. Ana amacı, belgeye anlambilim eklemek ve ana hatlarını oluşturmaktır.

Bir yazarın içeriği yalnızca JavaScript'te biçimlendirmek veya değiştirmek için gruplaması gerektiğinde, onun için en iyi yer div öğesini kullanmalarıdır. Div öğesi, bölüm öğesinin aksine, belgeye anlam katmaz ve anahattının (anahat) oluşturulmasına katılmaz.

Bölüm ve makale öğeleri arasındaki fark

Bölüm ve makale öğeleri, ilk bakışta çok benzer görünse de, farklı anlamsal anlamlara sahiptir. Makale öğesi, eksiksiz, bağımsız ve sayfa içeriğinin geri kalanından ayrı olarak görüntülenebilen içeriği gruplamak için tasarlanmıştır. Ve bölüm öğesi farklı bir anlamsal anlam taşır, başka bir şeyin ayrılmaz bir parçası olan içeriği gruplandırmayı amaçlar.

Ancak bir yazar, bir sayfadaki bazı içeriğin ne olduğunu nasıl bilebilir? Buna bir makale parçası örneğini kullanarak bakalım. Snippet, bir makalenin parçasıdır ve bu nedenle içeriğini gruplamak için bir bölüm öğesi kullanılmalıdır. Ancak daha önce bir yorum olarak bırakılan aynı parça, bütün ve eksiksiz bir şeyi temsil edecektir. Bu nedenle, bu bağlamda, makale öğesi onu gruplamak için kullanılabilir. Ancak, elbette, kişi akıl yürütebilir ve bunun tersi de olabilir. Bu nedenle, içeriği gruplamak için hangi öğenin kullanılacağı çoğu durumda bir yazar olarak öznel görüşünüze bağlıdır. Ancak bu yaklaşımda en önemli şey seçilen pozisyonu korumaktır. Bu nedenle, yazar yapıyı oluştururken ne kadar tutarlı olursa, yapıya o kadar anlam katabilir.

). Her etiket (Bölüm) bir çifti olmalı (/ Bölüm)... Gerekli parametreler isim ve döngü... Döngünün (bölüm) adı, harf, sayı ve alt çizgiden oluşan herhangi bir ad olabilir. döngüler (Bölüm) iç içe olabilir ve iç içe geçmiş adlar (bölüm) kendi aralarında benzersiz olmalıdır. Değişken döngü(genellikle bir değerler dizisi) döngü yinelemelerinin sayısını belirler. Bir bölümün içindeki değişkenleri yazdırırken, bölüm adı köşeli parantez içinde değişken adının yanında belirtilmelidir. (bölüm başka) parametre çalıştırılırsa döngü hiçbir değer içermez.

Özellik adı	Bir çeşit	Zorunlu	Varsayılan	Açıklama
isim	sicim	Evet	yok	Bölüm adı
döngü	karışık	Evet	yok	Döngü yinelemelerinin sayısını belirleyen bir değer.
Başlat	tam sayı	Numara	0	Döngünün başlayacağı konumun indeksi. Değer negatifse, başlangıç ​​konumu dizinin sonundan hesaplanır. Örneğin, döngü değişkeni 7 elemana sahipse ve başlangıç ​​özniteliği değeri -2 ise, başlangıç ​​dizini 5 olur. Geçersiz değerler (dizi dışındaki değerler) otomatik olarak en yakın geçerli değere kısaltılır.
adım	tam sayı	Numara	1	Diziyi geçmek için kullanılan adım değeri. Örneğin, adım = 2, 0,2,4 ... öğeleri tarafından dizinin bir geçişini gösterir. Adım negatifse, dizi ters yönde geçecektir.
maksimum	tam sayı	Numara	1	Maksimum döngü yineleme sayısı.
göstermek	boole	Numara	NS	Bu bölümün gösterilip gösterilmeyeceğini belirtir

Not

Smarty 1.5.0 ile başlayarak, oturum özelliği değişkenlerinin sözdizimi (% bölümadı.varname%) yerine ($ smarty.bölüm.bölümadı.varadı) olarak değiştirilmiştir. Eski sözdizimi hala desteklenmektedir, ancak yalnızca yeni sözdiziminin örneklerini göreceksiniz.

dizin sıfırdan başlayarak (veya belirtilmişse başlangıç ​​özelliğinde) ve bir (veya belirtilmişse adım niteliğinin değeri) artan dizinin geçerli dizinini görüntülemek için kullanılır.

Teknik not

Adım ve başlangıç ​​öznitelikleri belirtilmemişse, dizin 1 yerine 0'dan başlaması dışında yineleme bölümü özniteliği ile aynıdır.

yineleme, döngünün geçerli yineleme numarasını görüntülemek için kullanılır.

Not

Bu değer, özelliğin aksine start, step ve max özelliklerinden bağımsızdır. dizin... Ayrıca, yinelemeler, sıfır benzeri endeksler yerine bir ile başlar. satır sayısı yineleme ile eş anlamlıdır, aynı şekilde çalışırlar.

Örnek 7.38. özellik (bölüm) yineleme

atama ("vekil", $ id); ?> (bölüm adı = cu döngüsü = $ custid başlangıç ​​= 5 adım = 2) yineleme = ($ smarty.section.cu.iteration) dizin = ($ smarty.section.cu.index) id = ($ custid)
(/ Bölüm)

Bu örneğin sonucu:

Yineleme = 1 dizin = 5 kimlik = 3005
yineleme = 2 dizin = 7 kimlik = 3007
yineleme = 3 dizin = 9 kimlik = 3009
yineleme = 4 dizin = 11 kimlik = 3011
yineleme = 5 dizin = 13 kimlik = 3013
yineleme = 6 dizin = 15 kimlik = 3015

Bu örnek, her beş satırda bir tablo başlığını görüntülemek için yineleme özelliğini kullanır ( (Eğer) mod operatörü ile).

(bölüm adı = ortak döngü = $ kişiler) (eğer $ smarty.section.co.iteration% 5 == 1) (/ Eğer) (/ Bölüm)

	isim>	Ev	Hücre	E-posta
görüş	($ kişiler.adı)	($ kişiler.ev)	($ kişiler.hücre)	($ kişiler.e-posta)