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.
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ší...
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.
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á 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.
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.
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,...
bod 1. No comment.
bod 2. Proc obchazet hloupy jazyk prepisovanim API, kdyz si mohu vybrat lepsi (jazyk/nastroj)?
bod 3. Nesmysl.
bod 4. Samozrejme, ze je treba psat robustne, to byl vtip?
> (cele me API) zabira 100kb
No podle mne se toho na 100 kilo moc nevleze, takze nevim, jak se k Vasemu tvrzeni stavet.
Ale mozna si v zasade neodporujeme. Souhlasim s tezi, ze na jednoduche veci muze byt PHP vhodnou volbou (v duchu "Pretty Home Pages").
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.
Souhlasim, rozjizdet flame, ktery jazyk je nejlepsi je nesmysl, kazdy je dobry na neco.
Ale klidne se pustim do flamu, ktery jazyk je pro kocku --- vyhraje PHP.
Na druhou stranu chapu, ze programatori, kteri k PHP presli od kombinace VBScript+ASP na nej nedaji dopustit.
Jo a zajimalo by me, kde berete sve domnenky o neodladenosti mod_{perl,ruby,python}. Perl je rozhodne lepe odladeny nez PHP, ma za sebou take nejakou historii. Ruby, to je proste naaaadhera, cista prace, je za tim videt myslenka a peclive provedeni. Python neznam, ale pouzivaji ho intenzivne nekteri lide v mem okoli a nedaji na nej dopustit.
Pane Povolny,
dle ceho soudite, ze PHP je pro kocku a ostatni (ktere jak pisete, nepouzivate) jsou naprosto SUPPPEEEER?!?!?! Kolik jste napsal veci v PHP a ostatnich vecech?
Souhlasim, ze PHP neni idealni, ale je asi lepsi na dynamicke stranky nez PERL, nebo snad C ci C++. Pokud potrebuji aplikaci typu shopik, dotaznik a pod, neni asi lepsi volba (ASP je asi volba, ale ta rychlost a hlavne CENA). Pokud ale budu chtit napsat treba bankovni aplikaci, PHP asi nebute tou pravou volbou. Nebo pro vytvoreni auditu log souboru z webserveru nebudu asi take pouzivat PHP, ale PERL.
Podle mne je treba rozlisit co budu psat. Rozhodne bych si netroufl tvrdit, ze jeden jazyk je horsi nez druhy. PERL je mezi nami uz dlouho - asi co se tyce kvality je docela dobry favorit. PHP je mlade, ale uci se - viz. rozdily mezi verzemi, mizeni chyb - PHP je take navrzeno primarne pro webove stranky, proto se vklada do HTML. ASP - to neni jazyk, to je platforma - VBScript, JavaScript, ASP.NET = C#, Delphi.NET (jazykem je samozrejmne Object Pascal - abychom nemichali jabka a hrusky), atd...
btw: proc kdyz pisete ze PHP je pro kocku, mate na nem postaveny alespon jeden ze 3 produktu vasi firmy (webmail)?
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.
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
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.
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?