php komponenty

12.1.2007 11:21 | Přečteno: 2049× | Programování

Ještě mám dvě otázky na PHP. V tom softu(viz minulý zápis) zkouším používat komponenty podle tvaru url, takže např.: main.php?com=article&task=edit&item=13 nastartuje komponentu pro psaní článků a editaci položky 13

A problém mám právě s tím com=neco. Prozatím to řeším tak, že z hlavní stránky main.php(ukázka je z admin rozhraní, takže index.php slouží pro přihlášení) zavolám funkci :

$menu= isset ($_GET["com"]) ? $_GET["com"] : NULL;
showamenu($menu);

, která je definována takto:

function showacontent($com) {
	global $basePath;
        //To je jenom prozatím, než mě napadne co dát na úvod.
	if (is_null($com)) {
		echo "domů";
	} else {
		if (!(file_exists($basePath.'/components/'.$com.'/'.$com.'.php'))) {
			msg('NE_COMPONENT', 0);
		} else {
			include_once $basePath.'/components/'.$com.'/'.$com.'.php';
		}
	}
}

Tedy pomocí includování různých souborů. Protože se na tom to PHP učím, tak by mě zajímalo, jestli se to dá řešit ještě nějak lépe?

---

A ještě ta druhá otázka: Když mám html hlavičku definovanou v main.php, dá se nějak upravit v těch komponentách? Něco jsem zahlédnul o ob_start/flush. Pomůžou mi tyto funkce.

Za odpovědi předem děkuji.

       

Komentáře

[Martin Keder]

Nevím, připadá mi, že include s parametrem uvedeným u URI je potenciální bezpečnostní díra. Celkem v pohodě se tak můžu dostat i jinam, než se očekává. Radil bych to řešit spíš pomocí pole, které bude mít v klíčích povolené hodnoty.

[repli]

vetsina webhostingu ma vyrazene includovani url adres a pak by melo stacit zajistit aby se tam nikdy nedostalo ../

[Arnošt Málek]

Tak tak, urcite nepripojovat to, co se posle jako parametr. Ja bych pouzil reseni:

switch($parametr):
  case 'p1':
    include('./Inc/soubor1.php');
  break;
  case 'p2':
    include('./Inc/soubor2.php');
  break;
  case 'p3':
    include('./Inc/soubor3.php');
  break;
  default:
    echo 'Chybny parametr'; exit;
endswitch;

Samozrejme osetreni chyby atp. je treba napsat tak, aby to bylo podle predstav ...

[Martin Keder]

Switch ma tu nevyhodu, ze se musi konfigurovat zasahem do kodu. Radeji bych to udelal tak, ze si udelam konfiguracni soubor, ve kterem zalozim pole. To bude mit prvky ve formatu hodnota_URL_parametru -> pripojovany_soubor. Pak staci jen overit existenci klice a smele includovat.

[happy barney]

- switch: toto určite nie, radšej:

$map = array (
  'p1' => 'inc/service1.php',
  'p2' => 'inc/service2.php',
   ...
);

a funkcia array_key_exists

- "konfiguračný súbor": v tom prípade bude bezpečné, ak budete vstupný parameter kontrolovať, napr, nesmie obsahovať iné znaky ako "[-.a-zA-Z0-9]"

[filbar]

To je něco takového co jsem hledal, akorát že lepší to bude asi dát do databáze, ještě přemýšlím jestli by to nešlo udělat úplně bez includování, že zavolám funki, která se rozhodne zavolá podle com=neco a zavolá to neco.

[Martin Keder]

No, vzhledem k tomu, že stejně bude potřeba udělat konfigurák pro připojení k databázi, neváhal bych tam přidat i výše zmíněné pole. Ušetří se tím pár dotazů.

[filbar]

Ale zase by se zkomplikovalo přidání dalších komponent. Kdybych tam udělal instalátor, tak mi komponentu do databáze přidá jednoduše, zatímco do souboru by už to bylo složitější.

[rgb]

pole a vypisovani vsech moznosti je naprosto zbytecny, bohate staci osetrit parametr na vyskyt nechtenych znaku:

if (!preg_match("/^[a-z0-9\-]+$/i", $parametr)
{
        header('HTTP/1.1 404 No hackers please');
        exit();
}

[Arnošt Málek]

Switch sem daval proto, ze autor mel uvedeno if - else ... tudiz sem usoudil, ze bude pridavat dalsi moznosti a chtel jsem jej navest na switch, misto if - else {if - else}, pripadne if - elseif - elseif ... switch me pripada "cistsi" - citelnejsi.

Co se tyka pouziti nejakeho "konfiguraku" - at uz pole, objektu, XML, databaze nebo ja nevim ceho, jiste je to dobry napad. Ja pouzivam obe varianty, v zavislosti na tom, co se mi zda v danem okamziku lepsi. Nekdy mi prijde vhodnejsi napr. ten switch, jindy konfiguracni soubor ... to si musi kazdy zvazit.

[Josef Kufner]

Includovat všecko do jednoho souboru je pěknej humus. Udělej si adresář, kde budou jen "knihovny", tj. deklarace trid a tela funkci, co neco delaji. Pak pro kazdou akci udelej jeden soubor, ktery si includne co potrebuje. Jednoduche "hello world" by mohlo vypadat tedy takto:

hello_world.php:

<?
require_once 'lib/page.php';
$pg = new Page();
$pg->data['text'] = "hello world";
$pg->render();
?>

A v lib/page.php bude veskery kod, ktery uplaca html kod stranky a treba i jednoduchy sablonovaci system. Ten u sveho posledniho webu delam tak, ze lib/page.php si includne template/neco.php, kde je kopec html doplneny o <? echo $d['neco'];?>. Je to jednoduche a prakticke. V sablonach pak muze byt i slozitejsi kod treba na vykresleni tabulky, ale je dobre udrzovat poradek a udrzovat oddelene vykreslovani a logiku aplikace.

[Goffix]

Proc byto mel byt humus? Mne naopak pripada "cistsi", prehlednejsi a uzitecnejsi prepsat ten tvuj hello world nejak takhle:

hello_world.php:

<?
$pg->data['text'] = "hello world";
......
?>

index.php:

<?
require_once 'lib/page.php';
$pg = new Page();
require('hello_world.php'); // Zde by mohl byt ten switch, apod...
$pg->render();
?>

Mozna jsem te jen nepochopil, ale takhle mi to osobne vyhovuje mnohem vic a nemusim v kazdym skriptu typu "hello_world.php" psat to same dokola .

[Josef Kufner]

Toho co se opakuje v každém souboru je málo – jeden require_once pro každou použitou knihovnu a jedno vytvoření objektu. Na oplátku vidíš v jednom souboru naprosto všecko, co ta která část aplikace používá a přehlednost jednotlivých části je úplně někde jinde. Hlavně pro ty, ktří to budou luštit po tobě – include je jen jednosměrná vazba, takže dohledávat to v opačném směru je velmi obtížné.

Dále taky dostaneš zadarmo hezčí URL. Přidání něčeho, co nepoužívá index.php nenaruší návrh celé aplikace a výjimky celkově se dělají daleko pohodlněji. Taky je výrazně menší šance, že jedna úprava někde ovlivní něco úplně jiného. A počkej až se ti to trošku rozroste.

[Goffix]

Ja pracuji na hodne velkem projektu (teda bude hodne velkej) timto zpusobem a prave, ze mi prijde, ze v tom je velice hezkej poradek. A prijde mi i tak nejak lepsi, kdyz se prave pouziva jen a pouze index.php, nez to mit rozestrkany vsude mozne... takhle mam sjednoceny osetreni vstupu, zpracovani vystupu, apod.. a nemusim to upravovat vsude mozne..

Argument hezci URL bych rekl, ze v tomto pripade docela pada, jelikoz reseni pres index.php + mod_rewrite je neomezene .

PS: Je jasny, ze se o tom moc neda debatovat, jelikoz je to kazdymu podle vkusu .

[Josef Kufner]

Právě tyhle ošetření všeho možného ti udělá ta jedna knihovna, kterou si napíšeš. A rozstrkaný to nemáš všude možně, ale úplně stejně jako když použiješ jen index.php + includy jednotlivých modulů.

Klíčový rozdíl je ten, že při použití index.php+include nevidíš z includovaného souboru co mu index.php předává a kde se to inicializuje. Kdežto pokud máš pro každou funkci jeden soubor, který si includne co potřebuje, tak to vidíš a máš v tom přehled. Což ti hodně usnadní orientaci v kódu a dohledávání chyb. V tom ostatním to vyjde skoro nastejno.

ps: Dělám na jednom projektu, který používá právě index.php+include a má >100K řádek.

[Goffix]

Tak kdyz vim, ze je kolem meho skriptu, ktery includuju do indexu jen ten obsah indexu, tak prave mam velkej prehled o tom, co mam ve skriptu za promenne .

No jak pisu. Je to dost subjektivni pohled na vec.

[Josef Kufner]

Mno, jak myslis. Ja te varoval …

[Goffix]

No programuju v php uz vic jak 5 let a tak jak to myslis ty, tak jsem to delal driv... vim moc dobre, proc to ted delam jinak . Ono je to taky hlavne dost o tom, co od te aplikace clovek ocekava.