Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: dl 01. 09. 2012, 16:05:08
-
Pěkný den, jsem začátečník v PHP OOP. Mam vytvořeny dvě třídy. Jednu na generování zpráv a druhou pro připojení k databázi.
Chtěl bych metody třídy Zpráva použít ve třídě Databáze, kde mi budou generovat chybové hlášky. Jak na to?
Ještě bych se chtěl zeptat co vše by měla třída Databáze umět, jestli všechny metody dát do jedné třídy nebo vytvořit více specializovaných na dotazy do DB, připojení a výběr DB atd.
Děkuji.
-
ad 1. vytvorit v tride Databaze instanci tridy Zpravy a pomoci toho pouzivat dane metody, nebo druha vec, udelat metody tridy Zpravy jako staticke a ty tam pak pouzivat (zalezi, co presne ty metody delaji)
ad2. zalezi, na co tu tridu budes pouzivat, nicmene ja osobne delam jednu tridu Databaze, ktera obsahuje vsechno
-
Děkuji moc za radu.
Zatím třída Message obsahuje vlastně jen metodu getMessage, která přijíma jako parametry "typ" a "obsah" zprávy.
Podle typu ji pak obaluji css třídami z Twitter Bootstrap, http://twitter.github.com/bootstrap/components.html#alerts
Povedlo se mi ve třídě databáze v konstruktoru vložit třídu Message a pak v metodách používám Message::getMessage($typ, $obsah), udělal jsem metodu uvnitř třidy jako statickou.
-
Ja tu vidím problém v prístupe. Prečo by Databáza mala vedieť, že existuje niečo ako Správa? Trieda Databáza by mala podľa mňa obsahovať metódy týkajúce sa prístupu k databáze. Ak pošleš kus kódu, pomohli by sme viac
-
Ja tu vidím problém v prístupe. Prečo by Databáza mala vedieť, že existuje niečo ako Správa? Trieda Databáza by mala podľa mňa obsahovať metódy týkajúce sa prístupu k databáze. Ak pošleš kus kódu, pomohli by sme viac
Ano, přesně tak. Třída pro přístup k databázi je poměrně nízkoúrovňová, proto by neměla rozhodovat o tom, co se stane s chybou, čili zda se vygeneruje zpráva, nebo zda se stane něco jiného. Čistější postup je vyhodit výjimku a tu zpracovat na vyšší vrstvě, protože co když budeš chtít tu databázovou třídu použít opakovaně na jiném místě, kde budeš chtít chyby zpracovat jinak než zasíláním zpráv?
-
Ještě bych se chtěl zeptat co vše by měla třída Databáze umět, jestli všechny metody dát do jedné třídy nebo vytvořit více specializovaných na dotazy do DB, připojení a výběr DB atd.
Nejsem sice odborník na PHP, ale snad i zde bude fungovat běžný OOP DAO pattern. Já bych udělal třídu s daným rozhraním pro ukládání a načítaní objektu/více objektů, např. (použita Java syntaxe):
void save(SomeObject object);
SomeObject load(SomeIdentificator id);
+ třeba nějaké metody pro optimalizované dotazy.
Pokud by ukládané dokumenty byly složitější, můžeš si udělat pro každý objekt jednu DAO třídu. Rozhraní metod DAO třídy by rozhodně neměly řešit výběr DB, vytváření připojení apod., to má řešit implementace.
Potom když toto dodržíš, je úplně jedno, jaká bude implementace vespod – můžeš vše nacpat do jedné třídy, a když tam toho bude moc, tak to můžeš rozložit do více tříd, které bude zastřešovat tvá DAO třída, jejíž rozhraní se nezmění, tudíž při změně implementace nebudeš muset měnit kód, který DAO třídu používá. Můžeš třeba i změnit implementaci na ukládání do souboru namísto do databáze, volající nic nepozná.
-
Myslím, že se jedná o log / debug, nevidím jediný důvod, proč to v malém projektu řešit třídou.
OOP je mocná zbraň hlavně v rukou těch, co ním neumí a mohou s ní nadělat pěknou paseku.
Proč prostě nezavolat něco add_to_log ("Databáze je v hajzlu");
Proč to řešit samostatnou třídou?
Nejlepší řešení je to nejjednodušší a opravdu nemá smysl dělat třídu pro každou kravinu.
Něco jiného by to bylo ve velkém megaúberprojektu, tam by dávalo smysl místo connection vracet v resultu třeba chybu.
Jeden můj projekt používá po celém světě určitě pět lidí!! ;D a má asi 5k řádek kódu, ale log je prostě jen seznam.
Dělat pro to třídu by mělo myslím smysl, kdybys chtěl s tou chybou nějak dál pracovat, třeba dát uživateli možnost znovu nastavit connection nebo zadat heslo.
-
Dělám to prostřednictvím tříd, právě proto že se chci naučit to dělat objektově, naplácat jen funkce už umím. A PHP jsem zvolil proto, že funguje na každém hostingu. Jinak se učím v Javě, kde to jinak nejde, ale web sem v ní ještě nezkoušel. Samozřejmě to není velký projekt, ale nevidím jinou cestu než prostě začít. Nějaké praktické zkušenosti jak postupovat při učení se OOP jako samouk?
Myslel jsem to se zprávami tak, že to nebudej jen log pro mě, ale i výstup například pří instalačním procesu. Databáze OK vs. Problém s připojením.
Mám tedy řešit jako výjimky? Zkusím si to ještě ujasnit. Nejvíc mi dělá problém, že když něco navrhnu, vždycky mi někdo řekne, že by zvolil přesně jiný návrh než mi poradil někdo před tím :). Více tříd které dědí, málo tříd s hodně metodami, statické metody... OOP někde a funkce kde to není potřeba atd.
Díky moc.
-
OOP je jako řešení "pomocí trojúhelníků", skoro všechno se dá vyřešit pomocí trojúhelníků, ale kruh bývá jednodušší nakreslit pořád pomocí kružítka. Stejně tak k tomu přistupuj, ve své třídě můžeš zapouzdřit přístup k MySQL i PGSQL, ostatně MySQL zadarmo tu už dlouho nebude. To je super příklad toho, kdy je použití třídy dar z nebes. Používáš jeden objekt a přitom je jedno, jakou DB máš.
Tedy, chválím ti, že se učíš OOP, ale zkus se zaměřit na ty části, kde použití OOP dává smysl a vynechat ty části, kde je OOP blbost.
Píšeš o PHP, ale PHP dlouho OOP nebylo a původem je to prostě jen strukturovaný skript.
Neuč se otevřít zuby pivo, zůstane ti to a když to budeš dělat ve slušné společnosti, budou tě mít za podivína.
-
Něco podobného jsem řešil jakousi naivní implementací "observer" patternu (google pokud nevíš o co jde).
V zásadě to vypadalo tak, že třídy, které generují nějaké zprávy, implementují "IObservable" interface. A třídy, které ty zprávy zpracovávají (např. logování do souboru, logování do prohlížeče, logování pro Munin/Nagios/Zabbix, maily...) implementují "IObserver" interface.
Interface vypadají zhruba takto:
interface IObserver
{
function onMessage($sender, $message, $code);
}
interface IObservable
{
function addObserver($observer);
function sendMessage($message, $code);
}
onMessage a addObserver jsou očividné. sendMessage prostě volá onMessage s $message a $code všem observerům v $this->observers, které se nastavují přes addObserver.
Člověk pak třídě přes addObserver dá observery (třeba podle konfiguráku, podle $_GET parametru apod.) a třída pak už volá jenom $this->sendMessage a nestará se, kdo co s tou zprávou stane.
-
OOP je jako řešení "pomocí trojúhelníků", skoro všechno se dá vyřešit pomocí trojúhelníků, ale kruh bývá jednodušší nakreslit pořád pomocí kružítka.
Já tomu rozumím, že OOP bylo do PHP dodělané a že to jde i jinak. Takže prakticky, chci si udělar RS, který bude nad obyčejnou MySQL databází, bude mít správu uživatelů a příspěvků atd. a při nejlepším se bude moci rozšiřovat. Může se někdo tedy podělit o to jakou strukturu tříd a s jakými metodami bych měl vytvořit? Klidně mi to popište jen ideově, ale objektově. Mě se tedy PHP moc nelíbí, s tím, jak se mění, jak jsou pojmenovávanéné funkce jedna tak, jiná jinak. To pro mě je čitelnější i Lisp nebo Clojure, ale chci to popřípadě komukoliv dát a říci, to poběží všude (tedy PHP) a ještě si říci, že návrh je dobrý a dá se na tom stavět dál i to přepsat v jiném jazyce s OOP přístupem (třeba Java).
Však já s tebou zatočím ty jeden atlete – Muž z Acapulca
-
Jestli chceš dobrý OOP jazyk, tak začni s Java.
Pravda, J2EE je ohromný moloch a začít s ním je jako kdybys autoškolu měl začít dělat hned s raketoplánem, ale Java tě to nutí dělat správně. Nemusíš hned dělat weby.
V PHP se to správně dá dělat taky, ale co je správné řešení, pokud PHP umožňuje některé věci řešit jednoduše, není pak správné je jednoduše používat? Učil jsem OOP spoustu lidí, nějakou dobu vedl kroužek C# a C# je okopčená Java.
Na tvém místě bych si přečetl něco o modelech a začni třeba singletonem.
Zkus to použít, ne jen používat OOP, ale OOP se správným modelem.
Pokud se budeš snažit naučit na motorce tím, že jí budeš nosit na zádech, tak se jen nadřeš a naučíš dělat nesmyslný věci.
Taky se rozhodni v čem chceš vlastně programovat, protože Java a PHP to je jako Mercedes a Tráboš.
Jo, nedávno do Tráboše taky přidali airbag (OOP), ale ještě včera se nafukoval ručně pumpičkou.
-
Dělám to prostřednictvím tříd, právě proto že se chci naučit to dělat objektově, naplácat jen funkce už umím. A PHP jsem zvolil proto, že funguje na každém hostingu. Jinak se učím v Javě, kde to jinak nejde, ale web sem v ní ještě nezkoušel. Samozřejmě to není velký projekt, ale nevidím jinou cestu než prostě začít. Nějaké praktické zkušenosti jak postupovat při učení se OOP jako samouk?
Samozřejmě by se to dalo "nějak splácat tak, aby to fungovalo", protože aplikaci stejně "nikdo jiný kromě tebe nebude používat". Ale vidím, že ty se naopak snažíš postupovat pečlivě, najít co nejsprávnější řešení. A i když to třeba napoprvé nebude úplně ono, tak myslím, že jsi na dobré cestě, a že se to časem podobým zkoušením, byť i na jednoduchých aplikacích, naučíš ;-)
Jinak zkus při učení se OOP přemýšlet o objektech jako o reálných fyzických objektech, jak je vidíš ty zvenčí, a co ve skutečnosti dělají. Jakou mají zodpovědnost. Například takový vypínač světla na zdi – pro tebe je to jen zařízení, které se dá zmáčnout, čímž se rozsvítí nebo zhasne světlo. Už tě nezajímá, jestli je se světlem propojený dráty, nebo (což je zrovna případ u nás v práci) je to bezdrátový ovladač, který ovládá světla "dálkově". Stejně tak tvoje databázová třída by měla oddělovat implementaci perzistence objektů od vyšších vrstev, kterým je úplně jedno, jestli data budou uložená v databázi, v souboru, na nějaké web-service, nebo kdo ví, kde jinde. Pro ně je pouze důležité, že ta data budou uložena, nechtějí řešit nic víc...
Myslel jsem to se zprávami tak, že to nebudej jen log pro mě, ale i výstup například pří instalačním procesu. Databáze OK vs. Problém s připojením.
Mám tedy řešit jako výjimky? Zkusím si to ještě ujasnit. Nejvíc mi dělá problém, že když něco navrhnu, vždycky mi někdo řekne, že by zvolil přesně jiný návrh než mi poradil někdo před tím :).
...a naopak zase databázová třída by neměla vědět, co s chybami chceš dělat, ale to už jsem psal. Výjimky určitě nejsou jediné řešení, ale mysli na to, že co použiješ v databázové třídě, to budeš muset používat ve všem, co tu databázovou třídu bude volat. Pokud tam nasadíš nějakého kočkopsa, tak ti pak bude smrdět všude, proto se snaž najít nějaké co nejvíce univerzální řešení, které nezavádí příliš mnoho závislostí na tvých vlastních třídách, jinak každé chyby v návrhu budeš litovat.
Více tříd které dědí, málo tříd s hodně metodami, statické metody... OOP někde a funkce kde to není potřeba atd.
Pokud budeš využívat rozhraní (doufám, že PHP stejně jako Java má interface), tak pak bude úplně jedno, jestli více nebo málo tříd. Vyšší vrstva bude využívat jen to rozhraní a bude od něj očekávat, že jeho implementace bude dělat to, co má.
Statické metody doporučuji (alespoň v Javě) používat co nejméně (kromě oprávněných případů), ale vysvětlení důvodu by bylo asi na delší diskuzi. V krátkosti: hůře se pak řeší zaměnitelnost jinou implementací.
-
Rozumím vám, mě se Java líbí. Vykašlu se na PHP a nezaleknu se Mercedesu, když vlastně chci také jezdit po dálnici :D
-
Ehm...vážně se mi nezamlouvá způsob jakým je PHP věčně zadupáváno do země. Přirovnání Mercedesu (Javy) a Tráboše (PHP) je trochu přehnaný, ale budiž. Něco pravdy na tom je. Jen je třeba si vzpomenout pro kterou klientelu byly auta (i jazyky) určeny. Třeba Meďour nikdy nebyl stavěnej na naše český polňačky, i když se jim nadává do dálnic a zároveň si nikdo nebude kupovat Mercedes, když si chce dojet pro pár lahváčů do sámošky. Nebo pro tuzemák :-)
Ruku na srdce, kdo měl tu kliku a dělal web, který se může pochlubit třeba 100k/d návštěvností? Většina webů jsou nejsou ani tak velký ani tak vytížený. I kdyby byly, pořád nevidím důvod, proč by to PHP nemělo zvládnout. Kterej web se dá napsat v J2EE a v PHP ne? Xichtokniha (čti Facebook) jede taky na Trábošovi a ten je s vytížením úplně jinde. Takže pokud budu dělat jakýkoliv web normální velikosti, proč se mám učit molocha J2EE? Je to jako s kanónem na vrabce...
S tím lepením OOP do PHP...nebylo taky náhodou OOP přilepovaný třeba do Céčka? Není C++ stejný hybrid jako PHP? Myslím, že v obojím můžeš psát procedurálně i objektově. Přesto se o obou dá mluvit jako o úspěšných jazycích. Jasně, v PHP jsou "perly", který lezou krkem, ale vzpomínám si taky na diskuze javistů i céčkařů a ti měli ze svýho jazyka taky slušný headache...
Někde na zdrojáku nebo rootu byl zveřejněn průzkum jak si stojí server-side jazyky na serverech. No, Java se svými 4% mě hodně zklamala. Nevím jakou metodikou se došlo k těm cifrám, ale asi to nebude asi tak daleko od pravdy. Stejný výsledky jsem našel zde:
http://w3techs.com/technologies/overview/programming_language/all (http://w3techs.com/technologies/overview/programming_language/all)
A teď se musím zase přiklonit k názorům co tu už padly. Bohužel já šel směrem Pascal->Assembler->C->PHP->Java. Faktem je, že u PHP2.0/FI to bylo až do PHP4 ok, u PHP5 s OOP jsem byl mimo, protože jsem neuměl myslet objektově. Pak jsem se to naučil a lákala mě Java a tam jsem narazil, protože OOP v Javě a PHP je vážně jiný kafe. Design patterns pro Javu nebudou úplně stejný i pro PHP. Už jen tím, že třeba PHP není silně typovaný jazyk, nezná výčtové typy, generiku, vlákna atd. Proto se o phpčkařích říká, že jsou to bastlíři. Někdo ano, někdo ne. Ale je to taky dané tím, co ti jazyk umožňuje. V PHP se naučíš poloviční OOP a taky snadno můžeš sejít z cesty.
Takže rada: vybodni se na PHP a zůstaň u Javy. Naučíš se lepším návykům a nebudeš v tom mít zbytečně bramboračku. Nauč se základních cca 13 návrhových vzorů pro Javu nebo C#, poznáš v tom řešení svýho problému a ušetříš si moře času nedokonalým PHP.
Mimochodem, prasit se dá ve všem. V Javě, PHP a dost možná i v Karlovi :-)
-
A kdybych přesto trval na PHP a bastlil to ano bastlil, ale v tom nejlepším slova smyslu -- objektově PHP, protože Java se mi nezdá o nic složitější než dnešní PHP, ale zkrátka kamarádovi na jeho xyz hostingu ji nespustím, jaký objektový přístup zvolit na malý RS. Na světě je spousta pěkných jazyků, a když ne pěkných, tak aspoň praktických to vím.
-
Taky se rozhodni v čem chceš vlastně programovat, protože Java a PHP to je jako Mercedes a Tráboš.
Jo, nedávno do Tráboše taky přidali airbag (OOP), ale ještě včera se nafukoval ručně pumpičkou.
To přirovnání je totálně mimo, alespoň na té úrovni, na které se bavíme. Dnes už to není o jazycích, ale spíše o (MVC) frameworcích (když jsme u toho webu). Pokud chceš mluvit o nějaké produktivitě, či efektivitě obecně, tak je to téměř nevyhnutné. Tam je pak jedno, jestli bastlíš javu nebo php. Návyky jsou stejné a pokuk je FW dobře navržený a ty nejsi střevo, tak to funguje všude stejně (to, že bastlíš v jave, z tebe něco víc neudělá). Jak vidno, někteří jedinci dodnes žijí v historii a nekodážou žít v přítomnosti. Blbý je, že těmahle demagogickýma a omezenýma kecama zrazují ostatní.
-
presne tak. kdyz to vezmu jinak: kreativni grafik udela pekny navrh skoro i v Malování. Ja ani kdybych mel Fotokrám CS99 ultraprofi edition s automatickým čtením myšlenek...
PHP je na drtivou vetsinu webovych veci GOOD ENOUGH.
-
jak psal Alt+F4 - nezahazuj php, kdyz se v nem naucis delat poradne, bude to stacit
nicmene to RUM myslel spise tak, ze zacni javou a az se naucis objektove myslet (tj neobalovat kazdou blbost vlastni tridou), tak delej objektove i v php
hlavne si ale precti dost veci ohledne php a tvorby webovych aplikaci v nem, jelikoz to momentalne vypada tak, ze kazdy paty php programator tomu trochu rozumi a zbytek to patla pate pres devate, pak je samozrejme par takovych, kteri tomu fakt rozumi :)
...
Na tvém místě bych si přečetl něco o modelech a začni třeba singletonem.
...
no se singletonem bacha :) neni to zrovna idealni vec, jak zacit
-
Já bych radší kdyby mi někdo poradil s tou strukturou RS nějakým návrhem nebo odkazem. Aby to bylo jednoduché, nehraju si na to že budu vymýšlet Nette nebo Drupal, ale chci si tím projít pokud možno sám. PHP je pro mě na web optimální volba. Zatím se mi tu hádají zase jen který jazyk je lepší.
Díky.
-
A lepší na co?
Je to jako se hádat jestli je lepší nůž nebo sekera.
Na namazání chleba nůž a na štípání dřeva sekera.
Jestli se chceš učit OOP, zkus nejdřív Java.
Jestli hned bouchat WEBy, tak klidně PHP.
Já PHP nezatracuju, pořád v něm něco bastlím a ty naše kunhůty všechny jedou na PHP, protože J2EE je moloch.
Ale až když se trochu naučíš Javu, poznáš, jak je krásná a jak dlouho cestu musí ujít ještě PHP, než se jí do krásy vyrovná.
-
Já bych radší kdyby mi někdo poradil s tou strukturou RS nějakým návrhem nebo odkazem. Aby to bylo jednoduché, nehraju si na to že budu vymýšlet Nette nebo Drupal, ale chci si tím projít pokud možno sám. PHP je pro mě na web optimální volba. Zatím se mi tu hádají zase jen který jazyk je lepší.
Díky.
Napřed si ujasni, co chceš. Dle mého názoru nemá smysl dělat CMSko od píky, resp. ano, ale za použití OOP frameworku. V PHP zvol si mezi ZendFW, Symfony, Nette nebo Yii Framework (nebo googluj "php mvc framework"). Projdi si jednotlivé fw a koukni do dokumentace, stáhni si jednodušší ukázkové aplikace a zůstaň u toho fw, co ti přijde nejbližší srdci (jestli jsi někdy něco málo naprogramoval, tak poznáš, co ti sedí). V budoucnu sice narazíš na věci/omezení, které se ti třeba nebudou líbit, ale tu už budeš mít nějaké zkušenosti a přechod na jiný fw/jazyk tě nevykolejí. Pak teprve můžeš přejít k realizaci něčeho konkrétního. Dle mého těžko najdeš článek, co hledáš. Nic tak komplexního nikdo nikdy nenapíše. Prostě si tu koncepci svého RS musíš v hlavě "navařit" sám. Funkčně se inspiruj u již existujících RS, doplň do nich věci/myšlenky, co sám potřebuješ - ideálně to sepsat na papír. V tomto bodě vznikne první skutečný zádrhel - máš vybraný FW a potřebuješ v rámci svých možnosti/znalostí nastřelit dobrý základ aplikace. Takže google a hledej opensource CMS/WCM s názvem vybraného FW. Koukni na dema a zdrojové kódy. Důležité je pochopit životní ckyklus vybraného fw (hold něco málo z OOP a návrahových vzorů budeš muset nastudovat) v kombinací toho, jak to má implementované vybrané CMSko. Ze začátku se "myšlenkově" inspiruj, později budeš doplňovat a ještě později refaktorovat.
-
Diskobolos: ted mu radis to nejhorsi, co momentalne muze udelat (vzhledem k tomu, ze se to teprve uci)
a diky tomu je scena s php programatorama takova, ze 90% to dela v zendu/nette, neco tam splacaji, ale kdyby meli udelat stranku, ktera zvladne statisice lidi denne, ani nebudou vedet, kde zacit
moje rada: na frameworky se zamer az potom, co to budes umet
-
Já bych radší kdyby mi někdo poradil s tou strukturou RS nějakým návrhem nebo odkazem. Aby to bylo jednoduché, nehraju si na to že budu vymýšlet Nette nebo Drupal, ale chci si tím projít pokud možno sám. PHP je pro mě na web optimální volba. Zatím se mi tu hádají zase jen který jazyk je lepší.
Díky.
neztracej cas blbostma. daleko vyhodnejsi je se venovat prave treba tomu nette nebo drupalu. pochopit jeho principy a umet s nim.
-
Nechci bouchat weby. Chci mit svuj nastroj, ktery mi neujede hned pod rukama, kdyz nebudu sledovat kazdy den, co se deje, viz. Drupal, neco sem v nem udelal, ale neverim ze tomu jeden clovek rozumi. Pokud nechci delat super modularni system, myslim ze si vystacim s tim co si napisu, pripadne dopisu, ci prepisu. S Drupalem si kazdy modul zije na muj vkus moc samostatnym zpusobem a polovinu casu clovek ztravi na jejich zkouseni, plus obcas katastrofa. Navic Drupal dlouho nebyl OOP, nevim jak ted, takze ani motivace se to ucit moc nebyla. Takze chci se naucit PHP, chci si napsat vlastni vec a klidne ho pak i zahodim, ale podle me se i David Grudl naucil nejvic tim ze to proste zacal delat sam. Yii framework se mi zatim libi, kdyz bych si mel vybrat. Snad neni nic spatneho na tom neco zkouset od zacatku, jedna vec je pouzivat vestavene funkce napriklad na razeni a druha si ji sam napsat, jejichQuicksort vs. muj Quicksort, jasne ze bude asi stejny, kdyz ho napisu dobre, ale bude muj. Da se Nette pochopit, nebo je take tak velke, ze po nekterych vecech radsi nepatrat jak funguje? Existuje tedy i nejaka varianta Nette v Jave? Porad opakuji ze od pohledu mi Java prijde normalne citelna, co se tyka syntaxe.
-
Pěkný den, jsem začátečník v PHP OOP. Mam vytvořeny dvě třídy. Jednu na generování zpráv a druhou pro připojení k databázi.
Chtěl bych metody třídy Zpráva použít ve třídě Databáze, kde mi budou generovat chybové hlášky. Jak na to?
Co takhle to otočit a z třídy Zpráva volat metody třídy Databáze? Odpovídalo by to MVC.
Ještě bych se chtěl zeptat co vše by měla třída Databáze umět, jestli všechny metody dát do jedné třídy nebo vytvořit více specializovaných na dotazy do DB, připojení a výběr DB atd.
Do třídy Databáze bych dal metodu, která vrací skalár (počet ovlivněných řádek), vektor (asociativní pole s jedním záznamem) a tabulku (pole asociativních polí, s více záznamy). Tyto 3 metody by měly v jednoduchých případech stačit. Prvním parametrem je SQL dotaz, druhým je pole parametrů dotazu.
-
--> KIT
Díky za radu.
-
Co takhle to otočit a z třídy Zpráva volat metody třídy Databáze? Odpovídalo by to MVC.
Volat z View (zpráva) funkce Modelu (databáze)?
Já myslel, že apríl je jen 1x ročně.
-
Co takhle to otočit a z třídy Zpráva volat metody třídy Databáze? Odpovídalo by to MVC.
Volat z View (zpráva) funkce Modelu (databáze)?
Já myslel, že apríl je jen 1x ročně.
Záleží na použití - pokud posíláš do šablony objekt ActiveRow a přes getter v šabloně dosazuješ názvy sloupců, tak to možné je, ne?
-
Diskobolos: ale naprosto neprakticke
-
No, mohu se plést, ale View by obecně měl dostat data a pro jejich zpracování by určitě neměl potřebovat nic víc, než co sám umí.
Určitě by se neměl starat o to, jestli je připojená databáze a jestli existuje nějaká instance třídy DB nebo v jakém je stavu.
Pak to není model MVC ne?
Nebo chceš ve View řešit i třeba ověření uživatele?
Ostatně jak si to kdo napíše je jeho věc.
-
Controller si vyptá z Modelu data a Viewer je zobrazí. Je na tom snad něco špatně?
Ověření uživatele dělám ještě před spuštěním Factory. Controller obdrží jeho ID.
-
1) Chci mit nastroj, ktery mi neujede hned pod rukama, kdyz nebudu sledovat kazdy den, co se deje, viz. Drupal,
2) neco sem v nem udelal, ale neverim ze tomu jeden clovek rozumi. ....
3) S Drupalem si kazdy modul zije na muj vkus moc samostatnym zpusobem a
4) polovinu casu clovek ztravi na jejich zkouseni, plus obcas katastrofa.
5) Navic Drupal dlouho nebyl OOP, nevim jak ted, takze ani motivace se to ucit moc nebyla.
nic nenutim, nechci flejmovat, jen osvetluju par veci konkretne k drupalu ktery trochu znam pokud by to cetl nekdo jiny a zajimalo ho to:
1) drupal 6.0 = 2008. drupal 7.0 = 2011. takze cca 6 let lifetime (drupal 6 je podporovan do vydani drupalu 8).
2) to je pravda, tusim ze i Dries nekde prohlasil ze uz nevi presne co dela ktery kousek kodu. ale je to potreba? mame api.drupal.org , je v podstate par modulu ktery potrebujes na kazdym webu a ty jsou velmi dobre dokumentovane vcetne API. Nakonec se naucis jak kdyz bicem mrska par hooku, db api, forms api, pak pridas entity api a zvladnes vsechno co bys zvladl jinym nastrojem.
3) castecne viz 2). vetsina toho podstatneho spolupracuje pres API. co lepsiho nez zdokumentovane API chtit?
4) to je otazka maximalne prvnich mesicu, casem pochopis a mas v hlave presne co pouzit a jak to slozit, cim to doplnit, co si dopsat
5) ano, toto je "slabina". zlepsuje se to. Drupal 8 adoptuje dalsi casti ze symfony. Treba Entity API, Views API jsou docela zhusta OOP. nemyslim, ze je nutne mit 100% OOP kod jen abych vypadal cool.
-
Co takhle to otočit a z třídy Zpráva volat metody třídy Databáze? Odpovídalo by to MVC.
Volat z View (zpráva) funkce Modelu (databáze)?
Já myslel, že apríl je jen 1x ročně.
Model nerovná se databáze! Model je reprezentace informací, doménové objekty poskytované business vrstvou (výpočty, zpracování informací, funkční logika aplikace). Zpracování zpráv je tedy business logika. Databáze je až pod tím a view by s ní vůbec nemělo přijít přímo do styku (to možná bylo myšlenkou toho komentáře, ale pojmy byly popleteny). View naopak má sloužit právě k zobrazení modelu. Databáze by se měla volat jen v business logice, nikoliv ale přímo ze Zpráv, protože přece nechceme mít zprávy těsně svázané s databází, třeba je budeme chtít využít i na jiném místě než v souvislosti s DB.
-
...pindy pindy...
Viz:
třídy Zpráva použít ve třídě Databáze
Tazatel má dvě třídy, třídu Zpráva a třídu Databáze, proto jsem uvedl do závorky, kam zhruba v modelu MVC která patří.
Nevím, proč máš chuť mě poučovat, vím jak má třída Model vypadat >:( a že Model se nerovná databáze...
Grrrrrrrrr!
Ty **autor příspěvku použil speciální HTML značku <XXX> pro vyjádření svého názoru na určitou osobu slušným způsobem**