Názory k článku PEAR - framework pro PHP

Vyse uvedene priklady mi davno funguji, "zobejktovat" pristup k databazi je otazkou par minut.
Asi je to muj problem, ze se nezajimam o jiz existujici veci, na druhou stranu jsem rad, ze prichazim na shodna reseni.

V podstatě mi přijde velmi jednoduché zaobjektovat db, a udělal jsem to po svém už dávno. Je to velice podobné řešení z PEARu. Ale zatím jsem vepředu, protože jsem zvládl i automatickou obsluhu chyb s možností nadefinovat reakci na chybu. Žádným testováním chyby se vůbec nemusím zabývat. Je to velice příjemné, šetří to spoustu práce a velmi to zpřehledňuje kód.

Osobně takovéto knihovny, jako je PEAR beru kladně, ať už jí používám, nebo ne. PEAR asi používat nebudu, neboť jsem si stihl vyrobit spoustu knihoven sobě na míru. Ale minimálně PEAR zaručí, že bude slušně pracovat objektová vrstva v PHP. Stejně tak, jako třeba v C++ STL způsobila, že kompilátory C++ konečně začaly umět pořádně šablony.

V PEAR sa da nastavit volanie "callback" funkcie pri vzniku chyby.

A taky lze třeba nastavit, aby chyby z modulu mysql automaticky ošetřovala funkce log_mysql_erorrs(). Ale přitom všechny chyby šly do do jiné funkce, které je zobrazí?

Lze nastavit něco ve stylu: "Pokud chyby neošetří skript, tak je pošli do "callback" funkce?

A mnohé další...

Ma niekto prakticke skusenosti s ADOdb a PEAR - vyhody a nevyhody? porovnanie?

http://phplens.com/lens/adodb/

a nasiel som este jednu linku:

http://php.weblogs.com/Compare_PEAR_DB_ADOdb

Poprve jsem se zacal o ADOdb zajimat na zaklade tech benchmarku, ale pouzivam tuto abstraktni vrstvu pro pristup k DB spis proto, ze je mi proste sympaticka pouzivana syntaxe.

Zatim jsem skoncil u pouzivani verze 2.50. Verze 3.x je v nektere oblasti zpetne nekompatibilni.

..zkuste phpLib, taky velice zajimava a uzitecna vecicka, muzu jen doporucit http://phplib.sourceforge.net/

Vážení, jako programátor (byť v jiné oblasti) se živím již řadu let. Každý problém lze řešit mnoha způsoby, některé jsou dobré, jiné lepší a některé zase horší. Jestliže máte lepší řešení než je PEAR, proč ho nezveřejníte? Vaše řešení je možná funkčností na vyšší úrovni, ale leží Vám "v šuplíku". PEAR byl dán k dispozici, stal se součástí PHP, kde je Váš systém? Kde ho najdu, abych mohl porovnat vlastnosti a vybrat si ten "lepší"???

Já bych to nechal na nich :-)

Já třeba napsal pro své účely hodně knihoven. Něco bych si chtěl nechat pro sebe (byl jsem již mockrát svědkem, jak mnoho lidí vydělávalo na mé práci, a já z toho neměl nic), něco si musím nechat pro sebe (zavazují mě smlouvy), a něco bych rád zveřejnil.

Na druhé straně zveřejnění znamená spoustu práce. Musíte napsat alespoň strohou dokumentaci, musíte napsat nějaký pokec, musíte vytvořit stránky, a nebo někoho poprosit. To mě spolehlivě odrazuje.

mno, clanecek "z pohledu zacatecnika" dobrej, ale chtel bych znat nazor nejakeho odbornika. zivim se programovanim v php docela na urovni a par dalsich tymu znam, ale nikdo PEAR nepouziva.

prevlada hlavne nazor, ze nema cenu si kod komplikovat milionem includu cizich dlouhych souboru, ktere stejne nepracuji uplne podle nasich predstav a vysledny parsing jen zpomaluji. A dale by se dalo diskutovat napr. o prakticke potrebe abstrakce db. Projekty jsou vetsinou presne na miru a alespon se nepripravim ani o vykon, ani o vychytavky prislusne db.

co si o tom myslite, vy ostatni profici? co pouzivate vy?

ja osobne som zapojeny do jedneho projektu na SF. chceli sme pouzivast pear lebo sa zdalo je je to velmi dobry system a hlavne dokaze zjednotit programatorov. zial realita je ina. pear pouziva kniznice ktore zial pri safe mode v php nefunguju. jedna sa hlavne o funkcie zistovania ci dana class ktoru mate pousivat le loadnuta. zial ako som spominal safemode to nepovoluje.

takze vysledok? duch pear zachovame ale pear kniznice urcite nie ... nikde kde je poriadny webhosting to proste nepobezi.

ja nevim, v dnesni dobe uvazovat o nejake ztrate vykonu diky par abstrakcim... on si to procesor uz nejak prebere, toho bych se nebal! :-) (navic kdyz uz potrebuju opravdu vykon s velkym V, tak rozhodne nepouziju php) jakykoliv framework je podle me nezbytna vec pro udrzeni prehlednosti a snadne upravitelnosti do budoucna - proste krasne se s tim pracuje, nemusite psat hromadu inicializacniho a jineho balastu kolem, objektove zapouzdreni napriklad systemu sablon je desne fajn atd... nevim, uz bych asi nic nepsal "z fleku", ani kdyby to melo byt "na miru", jak rikate.

Zase jeden kdo ma dost penez na to aby kazdych pul roku koupil novy pocitac ...

Ne, zase jeden, co to pochopil. V dnesni dobe se az na velice malo vyjimek nevyplati neco prodat lepsi architekturu vymenou za rychlost. Takovy projekt, pokud ovsem nedelate software stylem "napis, prodej, zapomen, zahod" se totiz dlouhodobe dost prodrazi na udrzbe a pri delani zmen. To se projevuje tim vic, cim je projekt slozitejsi a vetsi.

Nerikam ze se ma vsechno psat v assembleru. Jde mi o to ze nekteri programatori (napriklad autori KDE, GNOME, mozilly) zavadi tolik vrstev abstrakci (a navic casto spatne napsanych) ze na mem pocitaci (Duron 700) je videt jak je to pomale.
Pravdepodobne mi reknete ze Duron 700 je dneska jiz zastaraly procesor, cimz prokazete ze mam pravdu. Staci se podivat co vsechno behalo na DOSu na jeste horsich pocitacich a uvidite ze "vseho moc skodi".
Spravne reseni je podle meho nazoru shodnout se na nekolika malo vrstvach abstrakce (nestavet jich na sobe cele hory) a hlavne, samotne abstrakce napsat co nejoptimalneji a ne jako GTK.

Nejak mi dela problem predstavit si profika, ktery programuje v php.
PHP + profesionalni programator mi proste nejde dohromady.

Ale mozna mame kazdy jinou predstavu o "profikovi".

To bych tedy opravdu rád věděl v čem podle vás programují profíci.
Podle mě se profík pozná podle toho, že svůj úkol splní v libovolném prog. jazyku než podle toho že používá třeba javu nebo assembler. Je to stejné jako by jste chtěl tvrdit že ti kdož umí HTML nebo XHTML nejsou profíci ve svém oboru, jenom proto že těch tagů je málo.

1. Za profesionala se povazuju, protoze kdo je to profesional? Ten, kdo se tim a jenom tim zivi. Samozrejme PHP samo o sobe nebylo navrzeno primarne jako objektove, dodnes je to jeho slabina.

2. Nic mi nebranilo v tom, prepsat neprivetive API php na sve objektove metody.

3. Pochybuju, ze na placenem webhostingu bude nekdy Java nebo Perl. PHP umozni jen to, v cem je samo omezene :)
Moje API je pouzitelne i tam, i na mem serveru v zakladni konfiguraci.

4. Mam pocit, ze je dnes moda delat vse maximalne robustne, ackoli to neni potreba. Tyto trendy uspesne ignoruju, CELE me php API zabira ani ne 100kb a jedno spusteni skriptu parsuje maximalne 20kb. A to mam vlastni session management, databazovou vrstvu, jednoduchy aplikacni server,...

PHP vypada, jako kdyz pejsek s kocickou varili dort, ma nestabilni API a nedostacujici vyjadrovaci prostredky. Neni to seriozni programovaci nastroj.
Jeho obliba prameni z toho, ze se v nem jednoduche veci delaji VELMI jednoduse.
To ze se nekdo programovanim zivi, podle mne z nej nedela "profika" podle Vasi definice.
Pro tvorbu dynamickych www stranek se podle mne hodi napriklad mod_perl, mod_ruby, mod_python, nebo i jsp a aplikacni servery.
Ted mi reknete, v cem je php lepsi. Argument o nedostupnosti hostingu neberu, neni to pravda.

haha. to je vtip? nechame definici profika (ono to bude jako v tom vtipu - lamer si mysli, ze je hacker, loser si mysli, ze hacker je lamer, hacker vi ze je lamer atd.)

rozjizdet flame o tom, ktery jazyk je lepsi nema cenu. kazdy ma sve vyhody a nevyhody. podle me je php dobre i na docela rozsahle projekty. jde o to, kdo to pise - a jsme zpatky u tech profiku. php je dobre svym masovym pouzivanim - alespon je relativne odladene a chyb-proste, coz o mod_perl/ruby/python lze tvrdit jen ztezi.

Mne zase nejde nejak dokopy to, ze o tom kto je alebo nie je profesionalny programator, rozhoduje pouzity programovaci jazyk. Mozno o tom bude za chvilku rozhodovat taktovacia frekvencia vyvojarovej pracovnej stanice alebo farba pozadia na jeho desktope. Hm...

pokud chcete opravdu komplexni php framework, nemuzu nedoporucit php sitemanager (http://roadsend.com/siteManager). sice z pear(u) vychazi a myslim, ze ho pouziva prave pro pristup k databazi, ale ma i spoustu dalsich vlastnosti, ktere ulehcuji tezkou programatorskou praci :-). rozhodne stoji aspon za vyzkouseni, zatim jsem na nic lepsiho nenarazil (samozrejme v open source kategorii).

Jak to vidim - PEAR je posledni zoufaly pokus udelat z php nejakou levnou napodobeninu perl. V perlu unifikovane databazove rozhrani existuje od roku 1992 (soucasny DB.php uz je funkcne nekde vedle DBI z roku 1995) :) Zbytek knihoven, nabizenych PEAR take maji v perlu mnoholetou historii...

me prijde phpko proti perlu pokrok
kdo videl cecko i objeky treba jen z vlaku muze klido zacit psat v phpku, co se mu zachce

zato perl me dostal do kolen, udelat tridu a metodu
bez navodu to je o zivot
uz me na stole lezi 2 knizky o perlu
prvni s velbloudem mi prisla totalne nesrozumitelna
ackoliv je na ni na netu sama chvala
spousta obratu typu: VYRAZ dela neco, pozor ale MIRNEPOZMENENYVYRAZ se ale nechova, jak byste cekali, dela neco uplne jinyho - skoda, ze uz tam neni napsany, z jakyho duvodu
- dobra asi jako mentalni cviceni, ale ja potreboval
funkci skripty do par hodin

abych jen nekritizoval, foreach je super vec, uz sem se 3x pristih, jak ho pisu do javascriptu a nechapu, proc na me zase rve :)
implicitni $_ taky nema chybu, (teda jednu)

blby je, ze nektery fce se v php a perlu jmenujou jinak, za to muze php, pac je mladsi
nevim, jaky meli vyvojari duvod
isset <-> defined
ltrim <-> s/^\s+//
rtrim <-> s/\s+$//
shift <-> array_shift
a tuny dalsich

PHP je napodobenina mixu C a Perlu, proto.

Třeba defined v PHP existuje a má význam analogický s #defined v C. ltrim, rtrim, trim jsou zase známé funkce z Basicu a spol.. Uznejte sám, že funkce ltrim bude výrazně rychlejší, než jeho ekvivalent v regulárních výrazech.

Osobně s Vaším názorem na Perl souhlasím. Perl prostě není špatný jazyk, ale můj názor je, že je to hrozná prasečina.

Na druhé straně je nutno říci, že nevýhodou PHP je jeho ořezávání z důvodu komerčního podnikání autorů. Tedy v základním balíku nenajdete ani debugger, ani převod do binárního kódu, jak umí Perl. Pro tyto věci sice je rozhraní, ale to je všechno. Díky aktivitám autorů si celkem můžu být jistý, že nic takového PHP mít nebude.

PHP si také nědělá příliš hlavu se zpětnou kompatibilitou, i zatím z toho byly jen minimální problémy. Nevím, jak zde Perl.

Osobně si myslím, že ani safe mode v PHP není příliš šťastně vymyšlen.

Já sám mám v PHP značnou praxi, ale uvažuji o přechodu na něco jiného.

jeje, ono to vyznelo, ze v php touzim po
s/^\s+//, tak ne, samo ze sem nejdriv v perlu hledal ltrim :(
dejte po prechodu vedet, na co jste presel

Bohužel Vám není kam dát vědět. Určitě nepřejdu do pár dnů a pochybuji, že budete ještě několik měsíců číst tuto diskusi.

Tak to pozor, ta knizka s velbloudem je VYBORNA. Je to nejlepsi knizka o Perlu, co sem kdy videl. Ale vzhledem k tomu, ze Perl nebyl puvodne objektovej, tak ani ta knizka se nesnazi byt navodem k OO programovani v Perlu.

Jo a pouzivani $_ je pekna prasarna ;-). I v Perlu se da psat ciste, ale za 'necistou' syntaxi ho vetsinou kritizujou lidi, co to neumi.

mnohem vic se mi libilo programovani v perlu po pokrocile
-o dve tridy srozumitelnejsi, alespon pro me

priklad toho co me na velbloudovi vadilo hodne:
definujeme skalary, pole, hashe
stale v pohode, typegloby zminime, ale uz nikdo nerekne, co to proboha je
a pak se najednou zacne operovat s pojmem seznam,
ktery neni nijak vymezenej vuci predchozimu.
ano, postacujici definici sem nakonec nasel vzadu v seznamu pojmu, ale az po letech :(

duvod, proc jsou regularni vyrazy popsany nejdriv jako regularni vyrazy na str 21 a pak poradne jako porovnani podle vzoru na 61, no to je asi proto, aby az budu neco hledat, tak sem si po prostudovani prvniho dilu popisu na str.21 myslel, ze to v ty knizce popsany neni a byl na ni nasranej?

na strane 54(seznamujeme se s hashem) je priklad s referenci na anonymni hash, ktery se probira na str.261(!), takze nikdo, kdyz to cte, vubec netusi, ktera bije

vyborna knizka je podle me takova, kdyz autor vi, co uz ctenari sdelil a nenuti ho svoje dilo cist 2x,
aby pochopil.

ten 'zda se mi ponekud nestastny zpusob objektu' jsem nevycital knizce, ale perlu samotnemu, teda rikal jsem ze phpko je v tomhle lepsi

-

v pripadech jako tenhle mi treba pouziti implicitni promeny
prijde pekny
foreach (@array) {
if(/prvni/) {
}
}

ciste:
no ja nevim, upsat se k smrti a zahodit pulku syntaxe jen abych psal ciste a ukazal, ze to I v perlu jde, neni zrovna to, co od skriptovaciho jazyka cekam. ja jsem rad, kdyz je to rychle napsany a funguje to

isset() a defined() je v PHP oboji, ale kazde dela neco jineho. isset() je na promenne, defined() je na konstanty definovane fci define().

znate tohle?
http://sqlrelay.sourceforge.net/
na rozdil od PEAR je abstrakce napsana v C jako PHP extension, takze ztrata na vykonu je minimalni.

BTW: Skoda, ze neni rozsireno RUBY. Tenhle jazyk je, podle meho, lepsi nez Python i Perl. Aspon v nem pisu skripty, ktere jsou nadherne prehledne a male. Viz http://www.ruby-lang.org

Rubu neni spatne, akorat podle me autor nedomyslel par veci (naprosto nesmyslne prejata syntaxe Perlu pro praci s regularnimi vyrazy apod.). Ale kazdy jazyk ma svoje, kdybych nebyl pythonista, Ruby by se mi asi docela libilo.

Hmm, kdyz chcete, tak muzete klidne s regexpy pracovat pomoci objektu ... viz Regexp, MatchData ...

To je dobre, diky. Ja jsem nechtel naznacovat, ze se v Ruby neda programovat hezky (koneckoncu, proc by to nemelo jit zabalit do objektu), jenom to, ze je to mala vada na krase. Ale jak rikam, myslim, ze Ruby je docela fajn.

Pickle znamena "nakladany", tedy asi hruskovy kompot v tomhle pripade :), ne pikle kujme :)

... ona uz v PHP abstraktni vrstva pro komunikaci s db existuje. Je zakompilovana primo v php - jedna se o knihovnu dbx. S uspechem ji pouzivam a je _mnohem_ rychlejsi nez PEAR, tedy pokud se jedna o ty db. Celkova filozofie PEARu se mi ovsem velmi libi.

drobna chybka u logu:
$log->("ahoj");
asi spis
$log->log("ahoj");

Osobně si myslím, že v dnešní době nemá cenu honit výkon tím, že nebudete používat nějaký framework. Zvláště u velkých projektů je to nezbytnost, jelikož pomáhá udržet nějakou strukturu v projektu, což ve výsledku napomůže lepší čitelnosti a pomůže udržet programátory v nějakých rozumných mantinelech.

Podílím se na projektu který jako přistup k databázím používá MDAC. Možnosti práce s DB přes MDAC je opravdu hodně, ale u nás prostě stačí jeden, který pokryje všechny požadavky programátorů. Takže v našem projektu se práce s db řeší jedním způsobem a každý může kdykoli pracovat na kódu toho druhého, jelikož 50% věcí je společné pro všechny. Pokud by žádný framework neexistoval, tak by si to každý psal nějak a ve výsledku by se v tom již nikdo nevyznal. Je zde ještě další výhoda a tou je že když se přepíše tato vrstva na jinou db, tak můžete teoreticky fungovat s jinou. Myslím si, ale že to stejně v reálu nebude tak jednoduché.

Závěrem snad tedy to, že v dnešní době se bez těchto frameworku žádný projekt, který má mít budoucnost, prostě neobejde. A pokud jde o výkon, tak si myslím, že se dá nasbírat i jinde, než jen vynecháním frameworku.

moje rec, naprosto souhlasim.

Kdyz jsem se pred casem (bude tomu uz asi rok) o PEAR zajimal, potesil me fakt, ze vubec neco takoveho existuje, ale po blizsim prezkoumani jsem nabyl dojmu, ze to je jen sada ruznych trid, ktere ve vetsine pripadu mezi sebou nijak nekomunikuji. Postradal jsem vetsi vazby mezi jednotl. komponentami. Je to jen muj dojem nebo fakt?