ugrás a tartalomhoz

rövid webcímek: több mappa mélységben, illetve 404-es header

jeti · 2007. Jún. 14. (Cs), 18.05
Sziasztok!

Rövid webcímeket szeretnék használni. Addig el is jutottam, hogy rewrite-al átadom az index.php-mnak a $REDIRECT_URL-t. De a következő problémákba ütköztem:
1.) Több mappa mélységben eltűnnek a stíluslapjaim, és a képeim is. Pl.: localhost/forum ez még oké, de a localhost/forum/tema/2007 már nem. (Ráadásul tudom is, hogy mi a hiba: forum/tema/2007 mappába nincsenek meg a stíluslap fájlok, se a képek.) Ezt a hibát, hogy lehetne kikerülni?
2./a) A másik probléma meg a következő. Korábban a programjaim folyamatosan kiírták az adatokat a böngésző felé. Pl.: Fejléc, és a menü kiírása... munkamenet folyamat kezelése, megfelelő modul kiválasztása... modul nevének, címének kiírása... a modul tartalmának kikeresése az adatbázisból... a feldolgozott tartalom kiírása
Most a rövid webcímeknél ki kell adnom a header("HTTP/1.0 404 Not Found");-t. Emiatt vagy kétszer kell mindent elvégezni (bárminemű kiírás előtt is), vagy valamilyen ideiglenes tárba kéne kiírnom minden egyes oldalbetöltést, és csak ha kész akkor kiírni az egészet. Ez hogy oldható meg? Nem terheli nagyon a szervert?
2/b.) Emellett a címeket (<TITLE>) is szeretném egyedivé tenni. Megint majdnem ott vagyok, mint előbb: Fejléc, és a menü kiírása... munkamenet folyamat kezelése, megfelelő modul kiválasztása... modul nevének, címének kiírása... Már rég kiírtam a TITLE tag-et, és hogy fogom belevarázsolni még ezt a címet is? (javascript nélkül! ;-) ) a modul tartalmának kikeresése az adatbázisból... a feldolgozott tartalom kiírása
Erre van egy ötletem (de szerintem sokkal szebben is meg lehetne oldani). A menü kiírását egy függvénybe teszem, és csak akkor hívom meg ha megvan a cím. Erre kiírja a fejlécet, és a menüt. Az egyik bemeneti paraméter, pedig a TITLE tag-ek közé beillesztendő szöveg lenne... Esetleg arra is gondoltam, hogy az "a" ponttal is variálhatnám, de nem, mert a munkamenet használatát nem tudom ennyire későre hagyni. Az meg már hagy nyomot maga után...

Előre köszönöm a segítséget.
‹ Dinamikus kép... nincs hiba, de nem megy file letoltese ›
 ■
1

rövid válaszok

gex · 2007. Jún. 14. (Cs), 18.15
1. használj base tag-et
2./a ezt nem teljesen értem, miért is kéne kiadnod a 404-es fejlécet? persze nem létező oldalnál ki kell adni, de mit kell kétszer csinálni?
2./b elkezdhetnél valamilyen sablon-rendszert használni (pl: smarty)

2./a-ra kíváncsi vagyok, többit remélem érted, ha nem, kérdezz bátran!
3

1.) és 2/b.)

jeti · 2007. Jún. 14. (Cs), 21.26
1.) Már használom a base tag-et, de ennek ellenére nem megy.
Lehet, hogy a forráskódomban van valami hiba...

<base href="http://localhost/" />
<link href="kekpir.css" rel="stylesheet" type="text/css" media="screen, print">
...
<IMG SRC="email.gif" WIDTH="20" HEIGHT="20" BORDER="0" ALT="E-mail küldés">
Köszönöm fraki, majd figyelek erre is. Sajnos, abszolút nem jelenít meg semmilyen (jpg, gif, png) képet.

2/b.) Sablonrendszer, ez jó ötlet.
Már gondoltam a smarty-ra, de nem akarom nagyon túl bonyolítani a dolgot. Tudom ez kényes téma, olyan, mint a webmesterek "böngésző vallása"... :-D
Az a megoldás, amit korábban írtam, mennyire járható út? Esetleg annyi változtatással, hogy csinálok egy tömböt, amit átadok a beágyazott fájlnak, és az szép sorjában feltölti a lyukakat a fájlban (amit előzőleg bejelöltem)...
Talán már ez is hasonlít egy kezdetleges sablon rendszerre.

Amúgy azt hittem, hogy erre valamilyen kimenet szabályzó függvényt fogtok javasolni, ami megállítja a kiíratást. Bár, a sablonrendszer tényleg jobb ilyen szempontból.
5

Sablonrendszer = PHP

Wabbitseason · 2007. Jún. 15. (P), 10.00
Ha PHP-t használsz, az már eleve sablonrendszer. Magánvéleményem szerint -- hogy az értelmetlen flame-elést elkerüljük -- nulla értelmét látom a Smarty-féle borzalmak használatának (már a nevétől is undorodom ;).

Talán érdemes lehet egy pillantást vetned erre a cikkre:
http://www.sitepoint.com/article/beyond-template-engine
8

sitebuilder

Hodicska Gergely · 2007. Jún. 15. (P), 12.21
Ha PHP-t használsz, az már eleve sablonrendszer. Magánvéleményem szerint -- hogy az értelmetlen flame-elést elkerüljük -- nulla értelmét látom a Smarty-féle borzalmak használatának (már a nevétől is undorodom ;).
Ez esetben használhatsz Template Lightot. ;) Viccet félretéve: ha nem is Smartyt, de valamilyen template kezelőt érdemes használni akkor, ha a projekten dolgoznak sitebuilderek is. Ők általában nem ismerik a PHP-t, és amúgyis elég veszélyes lehet template szinten tetszőleges PHP kódot engedélyezni.


Üdv,
Felhő
9

Most már megkérdezem :)

Wabbitseason · 2007. Jún. 15. (P), 13.42
Igen, ez egy gyakori érv, hogy a betanított, a HTML-t, CSS-t és JavaScriptet éppcsak "néger hajószakács" szintjén makogó sitebuilderek kezébe olyan veszélyes PHP-t adni, mint egy őrült csecsemő kezébe csőre töltött Coltot nyomni.

De ez tényleg valós helyzet?

Nem jobb megbízható sitebuilderekkel dolgozni, akik nem az ellenség beépített szabotőrei?

Nem jobb egy sitebuildernek megtanítani a PHP nyelvnek az általa használandó minimális részét, amely tudásból később továbbfejlesztheti magát, mint egy speciális szintaxist bemagoltatni vele, amivel önmagában nem megy semmire?

Tényleg olyan gyakori, hogy a sitebuilder (főleg az újonc) éles website templatejeit hegesztgeti, ahol valóban kárt tud okozni?
10

PHP és sitebuilder

Hodicska Gergely · 2007. Jún. 15. (P), 16.59
hogy a betanított, a HTML-t, CSS-t és JavaScriptet éppcsak "néger hajószakács" szintjén makogó sitebuilderek kezébe olyan veszélyes PHP-t adni, mint egy őrült csecsemő kezébe csőre töltött Coltot nyomni.
Van ebben némi cinizmus, de nem baj, hisz még ennél sokkal jobb esetben is komoly aggályok lehetnek. Egy profi sitebuildernek sem kell PHP-hoz érteni, és a többség nem is ért, ami nem is baj, hiszen ha valaki manapság komoly tudást szeretne ezen a területen (ide beleértem mondjuk komplexebb AJAX cuccok készítését is) felhalmozni, akkor nem tud könnyen másban is jó lenni. Innetől fogva viszont elég veszélyes lehet, hogy ő PHP kódokat írjon, mégha csak egyszerűbb dolgokat is használ.

Nem jobb egy sitebuildernek megtanítani a PHP nyelvnek az általa használandó minimális részét, amely tudásból később továbbfejlesztheti magát, mint egy speciális szintaxist bemagoltatni vele, amivel önmagában nem megy semmire?
Olyan szempontból nem jobb, hogy ha valamilyen template kezelőt használunk, akkor csak addig mehet el, ameddig az adott template kezelő engedi, míg PHP esetén nem tudod (max. dokumentációs szinten) kikényszeríteni, hogy ne használjanak olyasmit, ami nem engedélyezett a templatekben.

Még egy olyan szempont is lehet, hogy ha PHP a template, akkor valszeg könnyebben előfordulhat, hogy valaki nem tartja magát a megjelenítési és az üzelti logika szétválasztásához.

Tényleg olyan gyakori, hogy a sitebuilder (főleg az újonc) éles website templatejeit hegesztgeti, ahol valóban kárt tud okozni?
Egyrészről nem az újoncsággal van a gond, más részről meg mi mást hegesztene? ;)


Üdv,
Felhő
11

smarty féle borzalmak

Thomas · 2007. Jún. 15. (P), 18.04
Nem tudok veled egyet érteni, jómagam kb 3 éve csak smartyval dolgozok és nagyon megszerettem.

Az eredmény:

Sokkal tisztább, áttekinthetőbb kód.
A logikát és a megjelenést el lehet választani egymástól.
Valóban biztonságosabb, arról nem is beszélve, hogy a programozó dolgozhat a logikán, addig a builder formázhat

Az igazat megvallva, mióta smarty-t használok, a hideg ráz a printekkel és kilométer hosszú stringekkel tűzdelt kódoktól.

Ha már dolgoztál nagyobb lélegzető projekteken, amik bonyolultabb felépítéssel, igényesebb builddel rendelkeznek, megtanulod értékelni a template rendszerek előnyeit.
6

base, ob_* fv-ek

gex · 2007. Jún. 15. (P), 10.03
Lehet, hogy a forráskódomban van valami hiba...

ha beírod a böngészőbe, hogy http://localhost/kekpir.css, akkor látod magát a css-t? ha úgy igen, akkor a firefox live http headers kiterjesztésével meg tudod nézni, hogy milyen kérések mennek a szerver felé, ott látni fogod, hogy a böngésző hogyan kéri le a css-t és a képeket. ha úgy sem látod, akkor nálad (localhost) van valami hiba (esetleg könyvtárban vannak a css-ek és képek).

Már gondoltam a smarty-ra, de nem akarom nagyon túl bonyolítani a dolgot.

a smarty nem olyan bonyolult, persze más sablonrendszert is használhatsz (sajátot is), a lényeg az, hogy a sablonok használatával megkönnyíted az életed.

Az a megoldás, amit korábban írtam, mennyire járható út?

az ideiglenes tárra (valamilyen ideiglenes tárba kéne kiírnom minden egyes oldalbetöltést) gondolsz? mert arra használhatod az ob_* függvényeket is, aztán dom függvényekkel vagy reguláris kifejezésekkel meg tudod változtatni azt, amit már kiírtál.
7

DOM vs RegExp

Wabbitseason · 2007. Jún. 15. (P), 10.50
aztán dom függvényekkel vagy reguláris kifejezésekkel meg tudod változtatni azt, amit már kiírtál.

Egyszer kísérletképpen írtam egy egyszerű template-rendszert PHP 5-tel, amit elkészítettem DOM-os és RegExpes változatban is.

Speciális XML tageket ismert fel, és meghívta a tag neve szerinti függvényt, átadva az attribútumokat mint paramétereket, majd az eredményt a tag helyére rakta.

A reguláris kifejezéses változat majdnem kétszer gyorsabb volt a DOM-osnál.
2

a 2a-t én se értem

Fraki · 2007. Jún. 14. (Cs), 18.23
A base tag használatakor apró de nem lényegtelen ügyelnivaló, hogy átlátszó png-khez nem jók, mert azokhoz IE-ben dx filtert kell használni, és a dx filter CSS-ben nem veszi figyelembe a base taget. Személyes tapasztalat. (Persze kis rewrite-workarounddal kiküszöbölhető.)

Én a base tagről átálltam a relatív-abszolút (/valami/valami.jpg) hivatkozásokra, ez viszont azzal jár, hogy domain rootban kell fejleszteni. Ez általában megoldható (virtual hostokkal és subdomainekkel).
4

2/a. példával

jeti · 2007. Jún. 14. (Cs), 21.29
Konkrétabban: http://localhost/forum/tema/5 Ez a cím létezik. Indul a lap: (fejléc, menü kiírása... munkamenet folyamat kezelése, megfelelő modul kiválasztása... modul nevének, címének kiírása... a modul tartalmának kikeresése az adatbázisból... a feldolgozott tartalom kiírása)
A másik címem a http://localhost/forum/tema/802425, ami nem létezik. Tehát indul a lap készítése, és itt probléma: utólag nem tudom a 200-as headert 404-re változtatni.
Ezért gondoltam, hogy első lépésben még a session_start() előtt is csinálnék egy lekérdezést a táblából, hogy van-e ilyen téma. Ha van, akkor elkezdődik a lap "legyártása". Ha nincs, akkor: 
 header("HTTP/1.0 404 Not Found");
include('../hiba404.php'); exit();
12

Ágyúval verébre

Marcell · 2007. Jún. 15. (P), 18.40
Ha csak épp ezért nem akarsz áttérni egy sablonrendszer használatára, akkor használhatod az ob_start() függvényt is (a kódod legelején), ez pontosan az amit szeretnél: nem ad kimenetet, csak ha már megkéred rá később egy másik függvénnyel. Mivel gondolom egy darab (még üres) <title> elemed van a kódban, a cseréhez nem is feltétlen kell preg_replace():
<?php

function title($cim) {

	$obdata = ob_get_contents();
	ob_end_clean();
	$obdata = str_replace('<title></title>', "<title>$cim - Pistike oldala</title>", $obdata);
	
	print $obdata;

}

?>
Ha ezt meghívod, utána már mindent ír ki normálisan.
13

link

Marcell · 2007. Jún. 15. (P), 18.53
Volt egy kapcsolodó téma, ami egy az egyben erről szólt: http://weblabor.hu/forumok/temak/13906
14

Megoldások

jeti · 2007. Jún. 16. (Szo), 17.49
Köszönöm a segítséget, végül minden probléma megoldódott.
1.) Több próbálkozás után rájöttem, mi okozza a hibát: csak egy perjel hiányzott... Leírom, ha esetleg másnál is előjön.
Jó:
<IMG SRC="/email.gif" WIDTH="20" HEIGHT="20" BORDER="0" ALT="E-mail küldés" />
Több mappa mélységben ez már nem jó:
<IMG SRC="email.gif" WIDTH="20" HEIGHT="20" BORDER="0" ALT="E-mail küldés" />
2/a.) Tapasztalataim alapján, ha a session_start()-ot korábban adom ki, mint a 404-es header-t. Az attól még nem rontja el, és nem lesz belőle 200-as.
2/b.) Saját sablonrendszer használata, amit javasoltatok.