Doğru Cevap
-
10 yıl önce yazılmış14 cevap - 0 soruAnladığım kadarıyla prosedür kodlama yapıyorsun.
İçeriği text olarak işlemeden (parsing) yapmadan kolay bir şekilde çözmek zor.
HTML'de genellikle relative path kullanılır.
<script type="text/javascript" language="Javascript" src="jsfile.js"></script> <link rel="stylesheet" type="text/css" href="cssfile.css" /> <img src="imagedir/imagefile.jpg" border="0" alt="" title="" />
gibi...
yapman gereken. template phpde ekrana yazdırılan herşeyi, ekrana yazdırmadan önce yakalayıp içini okuyarak pathleri düzenlemek.
ob_start(); // iceriği yakalamaya başla. include $updir.'template.php'; $template_icerigi=ob_get_contents(); // değişkene ata. ob_end_clean(); // hiç bi şey yollama. $template_icerigi=str_replace('src="jsfile.js"','src="../jsfile.js"', $template_icerigi); $template_icerigi=str_replace('href="cssfile.css"','href="../cssfile.css"', $template_icerigi); $template_icerigi=str_replace('src="imagedir/imagefile.jpg"','src="../imagedir/imagefile.jpg"', $template_icerigi);
kodun çalışıp çalışmadığını denemedim. ama bu şekilde çözebilirsin.
bir diğer yöntem ise.. başlangıçta zor ama daha sonra inanılmaz pratik olarak kullanabileceğin Apache Rewrite destekli tam bir template mantığı... elindeki tüm tasarım öğelerini belirli bir dizin içine atabilirsin. ui/images, ui/jsfiles ui/css gibi... daha sonra apache'ye .htaccess içinde rewrite rule yazarak her altta çağırdığın dizin içinde sanal bir ui dizini varmış gibi davranabilirsin.. örnek bir rewrite rule
RewriteRule ui/(.*) /ui/$1 [L]
en sondaki [L] 302 ile cevap vereceği için kök dizindeki içeriği yönlendirip verecektir. böylece her defasında path okutup düzeltme işinden kurtulabilirsin.
-
buremba
cevabınız için teşekkürler. ilk verdiğiniz yolu düşündüm ve şöyle birşey aklıma geldi: zaten çağırdığım dosyalar en fazla bir alt dizinde olacak. çağırdığım dosya içinde bir değişken tanımlayıp, ona TRUE ya da FALSE değeri döndürüp, template.php'nin içinde de bunu kontrol ettirip değerine göre ya "../" ya da "/" yazabilir. öbür türlü farklı dizinden çağırdığım zaman o dosya içine sizin verdiğiniz kodu yazmam gerekecek ve bunu o dizindeki her dosyadan çağırmam gerekecek ki bence hiç esnek bir yapıya sahip olmayacak. str_replace fonksiyonunun defalarca yaptığı işlemlerle de yormuş olacağız üstüne sistemi.
htaccess çok güzel bir çözüm evet ama ufak çaplı bir cms sistemi yazmaya çalışıyorum ve htaccess'i de her yer çalıştırmıyor kurulumu bazen sorun çıkartabiliyor diye son çözüm olarak saklamak istiyorum.
şimdiye kadar php ile yazdığım projelerimde hep bu şekilde sizden ilk defa duyduğum "prosedür kodlama"'yı kullandım. :) buna alternatif bir yapı var mıdır bildiğiniz merak ettim?10 yıl önce yazılmış
-
risyasin
OOP var denilir genelde !.
Prosedür kodlamaya ilişkin çok yaygın olan "bana göre yanlış" bir kanaat bu,
o da OOP'nin prosedür kodlamaya alternatif olduğu.
aksine 2 si birarada gayet güzel çalışabilirler. kaldı ki OOP'de aslında prosedür kodlamanın çok gelişmiş bir hali diyebiliriz. ama içinde mutlaka prosedür olan bir bölüm olacaktır. Bu yaygın iddia sahipleri genelde bu sorunsala cevap vermekten kaçınırlar. mevzu bahis olan konu PHP ise. prosedür kodlama ön plana çıkıyor. çünkü PHP hala bir yorumlama dili. derleme gerektirmeyen bir dil. öyle yada böyle prosedür kodlama senaryoların çoğunda daha az kaynak ile daha yüksek hızda çalışacaktır. istisnai senaryolar da olabilir. OOP hakkında bilgileriniz güncel ve yeterli seviyedeyse, tasarım desenlerine girebilirsiniz. hatta girmek zorundasınız. Ancak bu şekilde OOPnin gerçek gücünü kullanabilirsiniz. genel tasarım desenleri hakkında wikipediada çok güzel bir başlık açılmış türkçe çevirisi yeterli değil ama...
http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29
Bu listedeki patternlerin tamamını PHP bir şekilde monte edebilirsiniz ama verimlilik konusunda sorunlar çıkacaktır. PHP yaygın olarak kullanılan başlıca patternler şu linkte güzlce açıklanmış.. http://www.ibm.com/developerworks/library/os-php-designptrns/
Daha önce bahsettiğim gibi. PHP tam anlamıyla OOP olmadığı için (buna itiraz eden çok olacaktır) prosedür kodlama halen daha yüksek verimde ve geliştirme hızında çalışacaktır.
** aslında PHP'nin OOP olmasına gerek de yok. ama büyük projelerde OOP kodlamanın avantajlarını taşımak, eski C, C++, Java programcıların PHP syntax'ına geçmesini kolaylaştırıyor. öncelikli amaç PHP ile kod yazabilen programcı sayısını arttırmak. Zamanla PHP'nin tam oalrak OOP'ye destek vereceğini düşünüyorum. ama fikrim hala gerekli olmadığı. neticede hala bir Main loop'umuz yok. işte bu fark PHP'den prosedür kodlamayı çıkartılamaz/vazgeçilemez hale getiriyor.
str_replace düşündüğünüzden çok daha hızlı çalışmaktadır. fonksiyonu birden fazla çağırmamın sebebi de tamamen tembelliktir satır kopyalama sağolsun:) bul ve değiştir parametrelerini array olarak verebilirsin. ki çok daha pratik olacaktır. 2. olarak parse tavsiye etmemin sebebi template.php dosyasını Dreamweaver gibi bir hibrid editörde açma olasılığınız. ki anladığım kadarı ile bu şekilde çalışıyorsunuz. html kodlama olması gerektiği gibi gözükecektir.
Şahsım olarak çok daha farklı bir yöntem kullanıyorum. template'lerim tamamen html uzantılı gerçek html dosyalar şeklinde yine kök dizinde duruyor. içlerinde {icerik}, {solmenu} gibi dnamik içeriğin geleceği yerleri belirten replacementlar koyuyorum. böylece kodlama esansında HTML ve PHP büyük oranda ayrılmış oluyor. ve güzel tarafı layout tamamen html dosyasında oluyor ve günü gelince tamamen başka bir layouta kolayca geçebiliyorum. LAMP sağolsun diyorum. .htaccess ile tüm geri kalan işlem çok daha basit hale geliyor.10 yıl önce yazılmış
- buremba
Cevaplar
-
10 yıl önce yazılmış83 cevap - 0 soruİhtiyacınız olan bir referans noktası. O da şu şekilde olabilir: Veritabanı bağlantısını yapıldığı ve diğer ortak işlerin yapıldığı ortak bir dosyanız vardır mutlaka. Orada
$basePath = realpath(dirname(__FILE__));
derseniz $basePath o dosyanın bulunduğu dizinin tam path'i olacaktır:
/var/www/lib/ ya da c:\wamp\www\ gibi...
daha sonra include ederken
include $basePath.'/included.php';
şeklinde include ederseniz sorun çözülür...
Bu arada madem CMS yazıyorsunuz, temel bir yanlışınız var o da global değişkenler kullanmak. İleride proje büyüdüğü zaman başınızı çok ağrıtır. smarty ya da savant gibi bir template sistemi kullanmak hem bu dizin probleminizi çözer hem de global değişkenlerin çakışması riskini ortadan kaldırır...
-
madpoet
Pardon kıçımla okumuşum soruyu :)
Statik içerik için de mantık benzer, yine bir referans noktasına ihtiyacınız var.
Bunun için $baseUrl = '/proje'; tanımlarsınız.
<img src="<?=$baseUrl?>/images/x.jpg">
derseniz sorun çözülür. Tabii dezavantajı tek tek bunu yazmak gerekiyor ama sadece ortak kullanılan dosyalarda yazmak gerekeceği için çok zor olmuyor uygulaması. (Tecrübeyle sabittir).
Diğer dezavantajı da örneğin paket olarak indirilip kullanılan bişeyse (open source gibi) dizin adı değişirse $baseUrl'i de değiştirmek gerekir her kurulumda.
Öteki alternatifleri risyasin vermiş... str_replace yerine daha gelişmiş regexp'ler kullanılabilir, performans çok önemliyse cache kullanılabilir, ilk çalışmada bu değiştirmelerin yapıldığı dosyalar başka bi yere kaydedilir, bi dahaki çağırışta dosyanın son hali çağrılır her seferinde tekrar tekrar yapılmaz vs.10 yıl önce yazılmış
- madpoet
-
10 yıl önce yazılmış70 cevap - 0 sorusabit bir url verirseniz hiçbir problem kalmaz konu ile ilgili