php dizisini sayfada kullanmak için nasıl saklarım.
Merhaba kimseler görmeden sayfaya getirdiğim php dizim var :)
Şaka bi yana..
Ürün sayfamda ürün ve varyantları var.
Sorgudan gelen varyant bilgilerinin olduğu dizi :
$vary_info; // array
ÜRÜN ADI X
Ürün fiyatı xx
Renk
Siyah - Beyaz
Matterial
Cotton - Keten
Varyant seçtiğimde fiyat ve ürün adınıda varyanta göre değişmesini istiyorum
$vary_info içinde varyant id var ve varyant seçtiğimde seçtirmek için kullanacağım id
hazır oluyor ama sorunum
$vary_info dizisini nerede tutacağım form içinde
araştırmama göre sorgudan gelen diziyi tutamıyorum.
Ajax kullansam kullanıcı sürekli varyantlarla oynadığında sürekli sorgu atılacak
Acaba local storage kullansam sayfa açıldığında varyant bilgilerini saklamak için bunu nasıl yapıyorlar
Soru hatalı mı? 👎
Eğer sorunun kurallara aykırı olduğunu düşünüyorsanız lütfen bize bildirin!
Cevaplar (6)
hepsiburada'nın attığı sık istekler de büyük ihtimalle sunucu taraflı tutulan cache mekanizmasından yanıt alıyordur. Siz de benzeri şekilde cache mekanizmasını sunucu taraflı kurabilirsiniz.
Diyelim ki select elementinin her change olayında newdata.php dosyasına get isteği atıyorsunuz.
/newdata.php?productid=123&value=1
Normalde newdata.php bu isteğe şöyle bir kurguyla cevap verir:
1) Bu istekle gelen parametreleri al.
2) Güvenlik için parametrelerin doğru formatta gelip gelmediğini kontrol et.
3) Veritabanına bağlanıp gerekli SELECT sorgusunu yapıp cevap al.
4) Veritabanından gelen verileri istemciye göndermek üzere organize edip json'a dönüştür.
5) Verileri istemciye gönder.
Burada veritabanından direkt sorgulama yaptığınız için en güncel veriye ulaşmış oluyorsunuz.
Bir de cache mekanizmalı bir kurgu belirleyelim ve aynı istek newdata.php'ye atılmış olsun:
1) Bu istekle gelen parametreleri al.
2) Güvenlik için parametrelerin doğru formatta gelip gelmediğini kontrol et.
3) Bu isteğe karşılık gelen bir cache dosyası oluşturulmuşsa bu dosyanın içeriğini direkt gönder ve işlemi sonlandır.
4) Cache dosyası elimizde olmadığı için veritabanına bağlanıp gerekli SELECT sorgusunu yapıp cevabı al.
5) Veritabanından gelen verileri istemciye göndermek üzere organize edip json'a dönüştür.
6) Json'a dönüştürdüğün bu verileri bir cache dosyasına yazıp kaydet.
7) Verileri istemciye gönder.
Bu kurguda da eğer sunucuda cache'lenmiş bir dosya varsa sunucu o veriyi gönderir ve 3 adımda işlemi bitirir. Hem veritabanını hem kendini çok yormamış olur.
Cache'lenmiş bir dosya yoksa normal kurgusundaki gibi verileri oluşturur ve istemciye göndermeden önce cache dosyasını da oluşturur. Böylece sonraki isteklerde bu kadar uğraşmaz.
Cache dosyalarını nasıl isimlendireceğiniz size kalmış. Birbiriyle çakışması mümkün olmayacak ve sizin de manuel aradığınızda belli bir dosyası kolayca bulabileceğiniz dosya adları tercih etmeniz güzel olur.
Örneğin: /cache/active/product~id-1234~color-buz mavisi~beden-34.json gibi bir dosya adı hem göz yordamıyla aradığınızda bile kolayca bulabileceğiniz, hem ~ karakterlerinden explode etmenin kolay olması, hem de belli bir istek için benzersiz olması açısından güzel görünüyor. Ama bu sefer de dosya adı çok uzayabilir veya Türkçe karakter sorunları yaşayabilirsiniz. Verilerinizi nasıl bir dosya adıyla saklayacağınız tamamen size kalmış. İlle de göz yordamıyla bulmanın kolay olması gerekmiyor tabi. Belli bir şifreleme yöntemiyle benzersiz bir dosya adı da oluşturabilirsiniz. O zaman da dosyanın adı product-asdf123abc.json gibi bi'şey olur mesela.
İyi ama bu cache dosyaları bir kez oluştuktan sonra sunucu artık hep cache dosyalarının yanıtlarını döndürecekse veritabanında sonradan meydana gelen bir değişiklik olduğunda nasıl yeni veri istemciye iletilecek?
Bunun için cache dosyalarını silen bir mekanizmamız olması gerekiyor. Yani veritabanında bu cache dosyalarını etkileyecek bir güncelleme yapıldığında cache dosyaları sistemden silinecek. Böylece istemcilerin yaptıkları ilk istekte yeni cache dosyaları oluşturulmuş olacak.
Cache dosyalarını silen mekanizma da 2 türlü yapılabilir:
1) Yönetim panelinden veritabanında bir değişiklik yapıldığında, mesela bir ürünün fiyatı değiştiğinde, ilgili ürünle ilgili bütün cache dosyaları silinebilir. Yani bu UPDATE sorgusundan sonra bir de ilgili cache dosyalarını bulup silecek kodlar eklenir.
2) Yönetim paneline bir buton: "Cache Sil". Benim favorim bu. Sistenin tüm cache dosyalarını silen bir buton da olabilir, ürün ürün veya sayfa sayfa silen birkaç silme butonu da olabilir. Ama başlangıç için tüm siteyi temizleyen buton iyidir. Bu butona basmak yönetim panelindeki kullanıcının sorumluluğundadır. Panelde yapacağı tüm değişiklikleri yaptıktan sonra Cache Sil butonuna basar ve bütün cache dosyalarının silinmesini sağlar. Sonra siteye giren ilk istemciler yavaş cevap alsa da sonraki istemciler cache'ten cevap alacakları için hızlı yanıt alırlar.
Back-end tarafında böyle bir cache mekanizması kurarsanız sunucunuz çok yorulmaz. Veritabanınız da normalde yorulduğundan çook çok daha az yorulur. Veritabanına yapılan istekler azaldığı için sunucu maliyetleriniz de düşer.
Back-end taraflı bu önlemleri aldıktan sonra bir de üstüne front-end temelli önlemlerinizi alır, PHP'ye hiç istek atmadan döndürülebilecek verileri de istemci harafında dönebilirseniz (verileri tarayıcının ram'inde tutma yöntemiyle) iyiden iyiye hem çok performanslı hem de mininum sunucu maliyetli bir sistem geliştirmiş olursunuz.
Elbette back-end tarafında tüm bu işlemleri yaparken kendinize ayrı bir php dosyasında fonksiyonlar hazırlamalısınız. Kod tekrarına düşmemelisiniz.
Mesela addCache($key, $value) adında bir fonksiyon ile cache eklemelisiniz. Burada $key dediğim değişken, json uzantılı cache dosyanızın adı, $value da bu json dosyasına yazacağınız içeriktir.
removeCache($key) adında bir fonksiyonunuz da olmalı ve bir cache dosyasını sileceğiniz zaman hep bu fonksiyonu kullanmalısınız. Fonksiyonunuz, $key adıyla aldığı dosya adını cache dosyaları içinde bulup silecek.
Bu arada bir cache silme işleminde tabii ki cache dosyasını ille de silmek zorunda değilsiniz. Onun yerine silinecek dosyayı dosyayı mesela cache/archive/2022-06-21 09:35:32/ adlı bir klasöre de taşıyabilirsiniz. Böylece bir hata durumunda mesela undoLastCache() gibi bir fonksiyonunuz olur ve son arşivlenen cache dosyalarını bulup geri yükleme şansınız olur. Başlangıçta gerekmese de ilerleyen zamanlarda böyle tedbirler kriz yönetimi açısından iyidir.
Tabii getCache($key) gibi bir fonksiyon ile cache dosyasının içeriğini alabileceğiniz fonksiyonunuz da olmalı.
Bunun haricinde bir cache dosyasının oluşturulup oluşturulmadığını kontrol edebileceğiniz bir issetCache($key) fonksiyonunuz da olsa pek hoş olur.
Eğer bir json dosyasını cache'lerken json içine dosyanın oluşturulduğu tarihi de eklerseniz sunucu üzerinde bir cron tanımlayıp belli zamanlarda removeOutOfDateCaches() gibi bir fonksiyonla tarihi geçmiş cache dosyalarının silinmesini sağlayabilirsiniz. Veya bir cache dosyasını okuduğunuzda isCasheOutOfDate($cacheData) gibi bir fonksiyonla tarih kontrolü yapıp tarihi geçmiş bir cache dosyasının kullanıcıya gösterilmesini engelleyebilirsiniz. Örneğin bir kampanya tanımlanmıştır ve bu kampanya 3 gün geçerli olacaktır. Bu durumda bu kampanyadan etkilenen ürünlerin cache dosyaları 3 gün sonra sıfırlanmalı ve yeni cache dosyaları oluşturulmalıdır.
Muhakkak düşündükçe pek çok senaryoya göre pek çok yeni fonksiyona ihtiyaç olduğu görünecektir ama başlangıç için sadece ekleme-silme-okuma işlemleriyle başlamak uygun olur.
Yani bir cache.php dosyanız olmalı ve içinde cache klasörünüzü yönetebileceğiniz fonksiyonlarınız olmalı.
Gibi gibi şeyler...
@kartal, local storage ile ilgili sorularınıza yanıt vereyim.
- local storage için domain başına 5mb alan ayrılır. Bu alanı açmak için sizin yapmanız gereken bi'şey yok. Bu alan hep açıktır.
- Başka sitelerin local storage'yi doldurması mümkmün değildir. Tarayıcı, local storage'yi her domain için ayrı ayrı tutar.
- Başka bir sitenin sizin local storage'ınıza ulaşma şansı yoktur. Dizin domain'inize ayrılmış local storage'a sadece sizin domain'inizle erişilebilir.
- Eğer bir tarayıcının sizin siteniz için ayrılan local storage'ı dolmuşsa yeni veri ekleyemezsiniz. Eklemek istediğinizde konsolda QUOTA_EXCEEDED_ERR hatası fırlatıldığını görürsünüz. Daha doğrusu o kullanıcı bu hatayı görür. Bu hata çıktıysa tarayıcı local storage'a veriyi yazmaya çalışmaz. (yani verinin yarısı yazıldı, geri kalanı yazılamadan kota doldu gibi bir durum olmaz. yeni veri yazıldıktan sonra kota dolacaksa tarayıcı local storage'ı değiştirmeyecektir.)
- Bazı tarayıcılar local storage'ın alanının artırılmasına izin verebiliyor (Opera, Firefox) sanırım ama tabi bunun bir anlamı yok çünkü kullanıcılardan tarayıcı ayarlarına girip bizim için düzenleme yapmalarını bekleyemeyiz.
Aklıma tajılan birşey var local storage nin biz kayıt eklemeden öncw başka sitelwr tarafından tamamen kullanılmış olma ihtimali varmıdır yoksa tarayıcı eklenmek istenen veri için öncekilerden silermi ayrıca
biz javascript ile local storagede biz eklemesek de yer açabiliyormuyuz.
Bu tür senaryolar olabilirse olumsuz yönde,
sanırım direkt olaraj ajax sorgu yöntem8 cache query olur gibi.
Ürün sayfamdaki varyant seçeneklerim :
/*
attribute-1 (1 : property id / value : Renk)
attribute-0 (0 : property id / value : Matterial)
input hidden value="sayfada ki property id leri string içinde(bu durumda '0-1' Renk ve Matterial)"
radio type içinde ki diziyi php sayfasında explode ile dizi yapıp select_variants ? [] 'ı döndüye alacağım
Bu bölüm sepete eklenirken kullanılıyor.
*/
<div id="attribute-1" class="attribute_list">
<strong class="attribute_name">Renk</strong>
<label for="variant_option-6" data-property="6" class="propertys propertys_active">
<input type="radio" name="select_variants1[]" id="variant_option-6" value="6" class="variants_radio">
Sarı
</label></div>
</div>
<div id="attribute-0" class="attribute_list">
<strong class="attribute_name">Matterial</strong>
<label for="variant_option-52" data-property="52" class="propertys propertys_active">
<input type="radio" name="select_variants1[]" id="variant_option-52" value="52" class="variants_radio">
Sarı
</label>
<label for="variant_option-51" data-property="51" class="propertys">
<input type="radio" name="select_variants0[]" id="variant_option-51" value="51" class="variants_radio">
Sarı
</label>
</div>
Diyelim ki
attribute-1 => select_variants1[] => value : 6 seçildi
diğer property de olmayan varmı diye kontrol edip olmayanları pasif hale getirmek
şimdilik burasını yapmadım.
attribute-0 => select_variants0[] => value : 52 seçildi
SKU : 6-52 olmuş oldu
kullanıcı önce 52 yi seçerse 52-6 olur ve istenmeyen durum veri tabanında küçükten büyüğe doru sıralanıyor çünkü.
Yani kayıt edilecek attribute id leri sort ile 52-6 değilde 6-52 şeklinde sıralanıp kayıt ettiriliyor.
Bu yüzden aynı kayıt ettirirken yapıldığı gibi seçilenleride sort ile uygun hale getiriyoruz.
ÖNEMLİ KISIM ?
1.) 6-52 SKU kodunu veri tabanına gönderip varyant bilgilerini alıp kullanıcıya değişik fiyat ve ürün adını gösterebilirim. js tarafında.
2.) Böyle yapmayıp her ürün sayfası açıldığında ürünün varyant bilgilerini ajax ile bir seferde alıp
local storage kayıt ederim.
Ve 6-52 geldiğinde sku = 6-52 diyerek gerekli objeyi alırım.
Kullanıcı başka ürün sayfasına gittiğinde varsa objeyi sildirip üstüne tekrar yazdırırım
Böyle bir dögü olur
Kullanıcı sayfayı açıp varyantları değiştirdiğinde veri tabanından değilde
tarayıcı deposundan alırım.
array (size=2)
0 =>
object(stdClass)[23]
public 'varyant_id' => string '38' (length=2)
public 'urun_id' => string '461' (length=3)
public 'sku' => string '6-51' (length=4)
public 'urun_adi' => string 'Cotton Matterial Sarı Renk yeni varyant' (length=40)
public 'single' => string '1' (length=1)
public 'shop_id' => string '1' (length=1)
public 'quantity' => string '15' (length=2)
public 'price' => string '75.00' (length=5)
1 =>
object(stdClass)[24]
public 'varyant_id' => string '39' (length=2)
public 'urun_id' => string '461' (length=3)
public 'sku' => string '6-52' (length=4)
public 'urun_adi' => string 'Poly Matterial Sarı Renk yeni varyant' (length=38)
public 'single' => string '1' (length=1)
public 'shop_id' => string '1' (length=1)
public 'quantity' => string '10' (length=2)
public 'price' => string '100.00' (length=6)
BU şekilde düşünüyorum.
Not bu varyant sistemi ikili yani sadece 2 özellik üstünden gidiyor.
hepsi buradanın varyantlı ürününü test ettim
network de istek gönderildiğini gördüm
sanırım ajax kullanmalarının sebebi
veri güncellenirse hatalı veri sepete eklenmesin diye
düşünüyorum.
Ama düşündürücü bir kısım burası sonyçta hepsiburada
sonuçta kendi sunucuları ve kimbilir ne kadar güçlüdür yani ajax orada uygun
ama küçük ölçekli bir site için uygun değil.
Sayfa ikl kez yüklendiğinde varyant bilgilerini javascript değişkende tutmak olur gibi sanki.
Şimdi
Merhaba. PHP dizinizin içinde kimsenin görmemesi gereken bir veri yoksa dizinizi javascript'e iletmelisiniz. Böylece sayfa içinde dizinizdeki değerleri dilediğiniz gibi gösterebilirsiniz. (PHP dizinizdeki değerleri javascript'le değiştiremezsiniz. Javascript'le değiştirdiğiniz veriden PHP'nin haberi olmaz.)
<script>
const vary_info = <?=json_encode($vary_info)?>;
console.log(vary_info);
</script>
Eğer dizinizde çok büyük bir değer varsa bu yöntem performans kaybına neden olur. Söylediğiniz gibi sadece görüntüleneceği zaman ilgili veriyi ajax yardımıyla PHP'den istemek sayfanın açılış hızını olumlu etkileyecektir.
Ama yine söylediğiniz gibi bu sefer de aynı isteğin tekrar tekrar ajax ile PHP'den istenmesi sorunu olabilir. Bu da sunucuyu gereksiz yorar.
Sunucunun gereksiz yorulmasını önlemek için attığınız istekleri bir javascript değişkeninde tutabilirsiniz. Böylece aynı isteği yeniden atmanız gerektiğinde önce bu değişkeninize bakıp bu isteğin daha önce alınmış bir yanıtı olup olmadığını kontrol edersiniz ve gereksiz yere aynı isteği tekrar atmamış olursunuz. Yani attığınız her isteği cache'lemiş olursunuz.
Bunu yaptığınızda tarayıcının kullandığı ram miktarını bir miktar şişirmiş olursunuz. Eğer her bir istekten gelen veri çok büyük boyutluysa bu da çok ram harcamak demektir ama bence bu durum göz ardı edilebilir.
Eğer ram'in de çok şişmesini istemiyorsanız veriyi tarayıcının hafızasına kaydetmelisiniz. Yani bahsettiğiniz gibi local storage veya session storage burada size yardımcı olur. Tabi bunların 5'er mb sınırı (Chrome için) olduğunu da unutmamak lazım.
Eğer aldığınız veriyi session storage'a kaydedecekseniz önce string'e çevirmelisiniz çünkü bu storage'ler sadece string veri tutuyorlar.
<script>
sessionStorage.setItem("vary_info", JSON.stringify(<?=json_encode($vary_info)?>));
const vary_info = JSON.parse(sessionStorage.getItem(vary_info));
console.log(vary_info);
</script>
Bu örnekte session storage'ı kontrol ederseniz verinizin orada tutulduğunu görebilirsiniz. Veriniz json formatına uygun olduğu için tarayıcınız size veriyi json gibi gösterebilir ama aslında tutulan veri string'dir. Bu yüzden kullanmak istediğiniz zaman JSON.parse() fonksiyonu ile string'i json'a dönüştürmelisiniz.
Bu örnekte veriyi ram'da tutmak yerine storage'da tuttuk diyebilir miyiz? Diyemeyiz. Sonuçta veriyi okumak için yine bir değişkene aktarıyoruz ve aynı veri ram'da da yer kaplıyor. Burada session storage'ın bize sağladığı şey, sayfa yenilense bile bu veriyi kaybetmeyecek olamız. Ama tarayıcı kapatıldığı zaman bu veri kaybolabilir.
Tarayıcı kapatıldığı zaman da veri saklansın istiyorsak session storage yerine local storage kullanabiliriz. Kullanımı session storage ile birebir aynı. yine .setItem(key, value) ve .getItem(key) fonksiyonlarına sahip.
Bana göre; PHP ile tüm verileri sayfaya çağırmak yerine sadece sayfa ilk yüklendiğinde görünecek olan verilerin sayfaya çekilmesi daha uygundur.
Eğer kullanıcı diğer verileri görecekse ajax isteği atılır ve PHP'den gerekli veriler istenir. Aynı zamanda yapılan istek ve isteğin sonucu bir js değişkeninde (ram'de) tutulur.
Her ajax isteğinde önce bu değişken kontrol edilir ve yeniden istek atılıp atılmayacağı buna göre belirlenir. Daha önce atılmış istek tekrar atılmaz. (ta ki sayfa yenilenenene kadar)
Bunu nasıl yaparız? Mesela bir select'in change olayıyla PHP'den veri isteyeceğiz diyelim:
// Yaptığımız istekleri cache'leyecek olan değişkenimiz:
const requests = [];
// #my-select id'li select elementinin change olayı tetiklendiğinde çalışacak fonksiyon:
$("select#my-select").on("change", function() {
// Bu elemente kolayca (ajax fonksiyonu içinden de) erişebilmemiz için bir değişkene alıyoruz.
const $this = $(this);
// Ajax isteğimiz sonlanana kadar bu element'in kullanıcı tarafından tekrar değiştirilememesi gerekiyor. Elementi disabled edelim.
$this.prop("disabled",true);
// Kullanıcının seçtiği değeri alalım.
const value = $this.val();
// Ajax ile get isteği atılacak url'yi belirleyelim.
const url = "newdata.php?value="+value;
// Bu url'ye daha önce istek atılmış mı?
const lastRequest = requests.find(function(request) { return request.url === url });
// Eğer daha önce istek atılmışsa yeniden istek atmaya gerek olmadığı için veriyi direkt console'a yazdıralım.
if(lastRequest) {
console.log(lastRequest.data);
alert("Bu istek daha önceden atıldığı için yeniden ajax isteği atılmadı. Elimizdeki veri console'a yazıldı.");
// Bu adımdan sonra change olayının yapacağı başka bir işlem yok. select'in disabled değerini kaldırıp fonksiyonu return ile sonlandırabiliriz.
$this.prop("disabled", false);
return;
};
// Eğer buraya kadar geldiysek daha önce hiç istek atılmamış demektir. İsteği atabiliriz.
$.ajax({
url: url,
type: "get",
success: function(response) {
// Verimizi başarıyla aldıysak gelen veriyi console'a yazdıralım.
console.log(response);
alert("İlk kez istek atıldı ve veriler alındı. Console'a yazıldı.");
// Ayrıca bu veriyi cache'leyelim ki bi'daha bu istek atılmasın.
requests.push({url: url, data: response});
},
error: function(err) {
alert("Hata var!");
console.error("Ajax isteğinden hata döndü: ", err);
},
complete: function() {
// Olumlu veya olumsuz bir sonuç döndüğüne göre elementin disabled özelliğini kaldırabiliriz ki yeniden change edilebilsin.
$this.prop("disabled", false);
}
});
});
Kodları test etmeden yazdığım için hatalar olabilir. Ama aşağı yukarı kurgusal bir cevap yazdım sanıyorum. :)