Starší komentáře ke článku: Řízené vkládání zdrojových kódů
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 7.3.2003 2:20:06
Neviem preco ale do teraz som si vzdy vystacil s nastavenim include_path.
Datum vložení: 7.3.2003 20:28:56
Seznam include_path se nastavuje v php.ini. Mate vzdy plny pristup k webovemu serveru, abyste mohl php.ini editovat? Nastaveni include_path je take dobra cesta - zalezi na vas, co vam vyhovuje vic.
Datum vložení: 8.3.2003 19:55:36
u slusneho hostingu mam pristup k .htacces ale obcas se muze hodit i tento zpusob.
Datum vložení: 8.3.2003 22:48:26
ini_set(), include_path je premenna ktora sa moze nastavovat odvsadial (php.ini, .htaccess, skript)
Datum vložení: 10.3.2003 16:00:57
Sem vepište svůj příspěvek.
---> To taky udělám!
Na levním sdíleném webhostingu je obvykle PHP velmi silně ořezáno a běží navíc v bezpečném módu, takže se takovéhle veletoče hodit mohou (a s ../ nemusí vůbec fungovat ;-). Ovšem taky se mi při čtení zamotala hlava.
Datum vložení: 10.3.2003 22:07:13
nastavnie include_path je mozne vzdy! na safe_mode nezalezi.
Datum vložení: 14.3.2003 8:30:04
Ale ale, to neni pravda. Da se to zakazat - a na spouste webhostingu to tak i je.
Datum vložení: 14.3.2003 8:44:23
Chapu, ze na freehostingu nemusim mit vzdy moznost udrzovat soubory v takovem adresari, ktery bude mimo cast <I>public</I> (a tudis takove soubory budou na webu viditelne, prohlizitelne neboli spustitelne).
V tom pripade bych volil mirne odlisnou cestu: vytvoril bych si adresar "adresarstajemnymjmenem" a nacpal soubory pro poradek zde (na tento adresar bych se pak odkazoval CODE MANAGEREM).
Mne ale zajima pripad, kdy <B>mam</B> moznost na freehostingu udrzovat adresar mimo cast <I>public</I> webu a zaroven nefunguje include "../...", jelikoz pak bych opet nemohl vyuzit prostor mimo cast <I>public</I>.
Jak je mozne zakazat napr. <U>require_once '../../../htprivate/code/class_a.php';</U>?
Datum vložení: 7.3.2003 9:50:01
Fuuha, este ze taketo sialenosti nemusime riesit...
Datum vložení: 7.3.2003 14:06:10
<I>Využiji přitom metodu objektového programování, kdy vývojář píše jednotlivé komponenty a udržuje si pořádek stylem co objekt, to samostatný soubor. </I> Jakou metodu objektoveho programovani? Asi hlavni problem bude ten, ze PHP neni objektovy jazyk. To, ze nekomu umoznim vytvorit objekt a zdedit z nej jeste neznamena, ze mam v ruce OO jazyk. Coz PHP urcite neni a pri vsi ucte ani byt nemuze, kdyz byl navrzen jako skriptovaci jazyk. Timto nechci zadneho zaryteho PHPckare urazit. Pro me jako javystu byl sok, neco objektove napsat v PHP. Pokdu se tyka vlastniho <I>code conventions</I> tak pro objekty pouzivam v nazvu vzdy Velka pismena a co nazev souboru to nazev objektu.
Datum vložení: 7.3.2003 20:28:07
Rekneme, ze objektove programovani je nastroj (metoda) programatora. Tolik k Vasi otazce.
Mate pravdu, PHP bylo na pocatku vyvijeno jako jednoduchy skriptovaci jazyk (pro evidenci pristupu na webove stranky), ale co Vas vede k vyroku, ze "PHP neni objektovy jazyk.. ba dokonce jim ani nemuze byt"?? Ja si s Vami urcite dovolim nesouhlasit. Myslim si, ze PHP ma prakticky vsechny atributy OO jazyka. Od OO jazyka ocekavam, ze budu mit moznost definovat tridy (chci definovat jeji vlastnosti i metody) a vytvaret instance techto trid. Navic chci psat kontruktory, obcas vyuzit dedicnosti a pracovat s instanci tridy jako s opravdovym objektem, ktery mi dovoli ty nadefinovane metody kdykoli aplikovat. Toto mi PHP umozni, navic od verze 4 mohu vyuzivat funkce pro praci s tridami/objekty... Proto by mne zajimalo, co u PHP jako OO jazyka postradate a nepovazujete ho za OO jazyk. Neverim, ze by z PHP udelala objektovy jazyk az platforma .NET, <B>PHP podporu OOP ma jiz nyni!</B>
Datum vložení: 10.3.2003 7:45:50
Dobra vezmem treba elementarni vlastnost, zapouzdreni. Jak v PHP udelam public a private funkce?
Datum vložení: 10.3.2003 9:52:27
<a href='http://www.linuxdocs.org/HOWTOs/PHP-HOWTO-7.html' target='_blank'>http://www.linuxdocs.org/HOWTOs/PHP-HOWTO-7.html</a>
Vsechno bude ;-) Java taky prochazela vyvojem.
Datum vložení: 10.3.2003 10:36:13
Dobra tedy, bude a co vicenasobna dedicnost, vynucene prekryvani (abstract) a pretezovani?
Datum vložení: 10.3.2003 20:27:32
Chapu, vicenasobna dedicnost muze vadit.. ani ja jsem z toho nebyl nadseny, proto jsem zvolil strategii, ze dedicnost zatim pouzivat nebudu vubec. Jiste by me to casem omezovalo a zbytecne bych se tim vytacel. Resim to metodou: objekt vyuziva objekt, ten vyuziva treba dalsi objekt.. atd. i tento objekt muze vyuzivat jiny primitivni objekt. Takze vicenasobna dedicnost proti Jave patrne pokulhava. PHP je stale ve vyvoji, snad se casem dockame (podobne viz vyvoj napriklad MySQL.. mirim konkretne na subselecty). Oproti Jave mam pocit, ze se PHP muze chlubit vetsi rychlosti..
Datum vložení: 10.3.2003 20:26:23
Vsechny metody jsou v PHP public. Ostatne v definovani private metod nevidim smysl. Je prece jedno, zda nejakou metodu oznacim jako private (tim tato metoda dostane omezeni pouze na interni volani) nebo ji napisi jako public a budu ji volat pouze z vnitrku (toto si pak ale musim zdokumentovat, abych nezapomnel ;-)).
Datum vložení: 12.3.2003 9:02:06
Jedno to samozrejme neni. Nevidim duvod proc by pomocne metody objektu mely tvorit jeho komunikacni rozhrani. tim, ze mam v ruce private a public metody dokazi realizovat vnitrni chovani objektu. Toto vnitrni chovani objektu je tak interni vec, ze neni duvod zverejnovat je. Bylo by to i proti logice tyto private metody se postupem casu meni, zanikaji nebo se vytvareji uplne nove kdezto verejne metody, tvorici rozhrani objektu jsou trvale, vychazeji jiz navrhu objektu. Samozrejme je to neprijemne i z hlediska volani, klientsky programator muze byt pekne zmaten kdyz urcity objekt umoznuje volat vsechny metody.
Datum vložení: 8.3.2003 21:52:23
Mluvíte o metodě objektového programování. V tom případě vám musím oponovat -- objektově lze programovat i v jazycích bez přímé jazykové podpory pro OOP -- třeba v klasickém starém Pascalu nebo dokonce v assembleru. Je to zkrátka jen přístup k řešení problému a struktuře programu.
Novější, tzv. objektové orientované jazyky, jen přidávají přímou podporu pro OOP, která umí za programátora sama mnoho věcí ošetřit a usnadňuje mu tak používat objektový přístup při řešení problému.
Různé jazyky mají zabudovanou samozřejmě různě vyspělou podporu pro OOP. Java jí má samozřejmě lepší než PHP. Zarytému vývojáři v C++ nebo Smalltalku však bude i vaše Java připadat jako objektové nedochůdče.
Datum vložení: 31.7.2003 16:27:01
teste se.
Datum vložení: 28.1.2004 20:07:15
Pane Jureček, tohle mohl vymyslet opravdu jen matematik :)
Možná, že je ten CODE MANAGER užitečný; pokud ano, tak jste to tu neukázal.
Udělat si vlastní funkci místo include mě možná taky někdy napadlo, ale hned jak mě došlo, že tam nebudou platit globální proměnné bez globalizace, tak mě to přešlo. A ještě mít pro každý objekt (tedy soubor) jiný název funkce... to bych se v tom za chvíli naopak ztratil. No ale možná, že pro matematika pak programování získává teprve ty správné grády :)
---------------------------------
Nejdříve, nemáte tam chybu?
Tady načítáte třídu c:
// index.php
require_once '../../../htprivate/project/code/setup.php';
load_a();
load_b();
$a = new class_a();
$b = new class_b();
// class_a.php
load_c();
class a {
...
}
--------------------
a tady jí načítáte znova ?
// general.php
function load_a() {
global $mycode_manager;
load_c();
$mycode_manager->prequire_once('code/class_a.php');
}
---------------------------------
Píšete:
"... Pak se v takových odkazech na soubory těžko orientujeme a odvádíme pozornost jinam. U většího projektu určitě stojí za to situaci řešit. Princip mého řešení je blízký pointrům z C. Nebudu při každé potřebě určitého kódu psát:
include 'cesta/jmenosouboru.php' ..."
A já se ptám, proč ne? Co je na tom za odvádění? Rovnou vidíte, co načítáte. Hledání chyby jednoduché.
Když budu muset před každým přidáním obektu vytvořit funkci, která mi ho načte, tak se neodvádím od problému?
Když se nemůže použít include_path, tak se použije proměnná, ne?
$gen_code = '/Program Files/Apache Group/Apache/htprivate/general/';
$my_code = '/Program Files/Apache Group/Apache/htprivate/project/';
include_once($my_code.'code/class_a.php');
include_once($gen_code.'code/class_c.php');
----------------------
Dokonce to tam sám jednou používáte při načítání samotného code managera :-) Je něco ve vašem řešení, co toto neumožňuje? Vyzývám vás, jestli má váš code manager ještě jiné (a lepší využití) než zamotávat hlavu, tak sem s ním a napište ho třeba jako nový (nebo aktualizovaný) článek, prosím. Rád se poučím.
P.S.
jdou v phpku udělat skutečné pointery?
Napadá mě akorát skloubení $$ a &, ale nějak to nemohu domyslet.
Datum vložení: 1.2.2004 22:32:23
Rad bych Vas, pokud jde o tridu CODE MANAGER, trochu usmernil. Nedelejte si starosti, ze nevidite prakticke vyuziti - ta trida funguje a parkrat jsem ji pouzil.
Zalezi na kazdem programatorovi, jakou techniku zvoli a o jaky projekt se jedna. V soucasne dobe se nebojim pouzit i takovou techniku, ze si PHP kod ukladam do databaze (namisto souboru na disku). Pokud ale neznate konkretni pripad aplikace, nemuzete rict o nejake optimalizaci ani pul slova.. kazdemu programovani predchazi analyza a v na tomto priklade muzu dokazat vyuziti CODE MANAGERa. V reseni popsane v clanku vychazim z predpokladu, ze PHP kod, ktery chci "includovat", lezi v souboru na disku. V programech mam tedy zapsany volani funkce load_classA1() a pokud se rozhodnu vsechny soubory do DB, staci mi prepsat dve metody v tride CODE MANAGER. Nakonec mi je naprosto jedno odkud ten soubor includuji.. umele si tvorim dalsi stupen abstrakce a grady to opravdu muze mit, pokud nezapomenete na dynamicke volani funkci ;-)
Trosku mi uniklo, co myslite tim "Udělat si vlastní funkci .. nebudou platit globální proměnné bez globalizace". Otazkou je, co mate na mysli tou globalizaci :), protoze uvnitr funkce uspesne mohu pristupovat ke kolekci $GLOBALS a mam k dispozici vsechny globalni promenne. Napsal jste to spise jako vykrik, takze nevim, na jaky problem v teto souvislosti mirite.
Dalsi vase otazka se tykala uvedeneho prikladu.. opravdu tam chyba neni. Nezaznamenal jsem, ze by se volani jedne funkce opakovalo. A mimochodem ani to by zadnou chybu nevyvolalo, jelikoz jde o prikaz reguire_once.
A nakonec vam napisi k tem pointrum... Pointer tedy jako ukazatel na jinou pametovou bunku lze v PHP dobre realizovat treba takto:
$moje_promenna = '20';
$pointer = &$moje_promenna;
$pointer = '21'; "v tomto kroku bude v $moje_promenna hodnota '21'
Jsem s pozdravem,
Ondrej Jurecek
Datum vložení: 3.2.2004 16:36:37
Tak ano. Pokud vkládáte kód php do databáze, tak má takovýto způsob inkludů opodstatnění. Osobně bych se bál, zda to pak není příliš pomalé.
$GLOBALS se dá použít. Pokud máte ale třeba 20 proměnných a všechny je musíte obalovat do $GLOBALS[''], tak to není příliš pohodlné na psaní. Vyhýbám se použití funkcí s globálními proměnnými. Vlastně jeden z největších důvodů, proč používám třídy, je právě to, že metody sdílejí společné vlastnosti objektu.
Tu "chybu" s dvojitým voláím load_c() tam vidím. Poprvé se volá z funkce load_a(), podruhé přímo ze souboru class_a.php. Možná vám ale require_once opravdu zabrání dvojitému vložení, takže se to neprojevuje.
Takovýto pointer ale neumožňuje jednoduše změnit (např. inkrementací) adresu, na kterou ukazuje. Nebo mi to aspoň nedochází.
Datum vložení: 6.3.2004 0:15:42
$moje_promenna = '20';
$pointer = &$moje_promenna;
$pointer = '21'; "v tomto kroku bude v $moje_promenna hodnota '21'
ale vždyť tohle přece nemá nic společného s pointry? :-o
viz. <a href='http://cz2.php.net/manual/en/language.references.arent.php' target='_blank'>http://cz2.php.net/manual/en/language.references.arent.php</a>
Co si "tak nějak vybavuju" - pokud vytvořím pointr na nějakou proměnnou (nebo cokoliv), tak změnou pointru samotného docílím JEN toho, že ten pointr ukazuje jinam, a ne že změním hdonotu proměnné na kterou pointr ukazuje ... opravta mne jestli se pletu ...
Tom