Open-source může být i placené. Jako příklad můžu uvést Suse Linux Enterprise Desktop, který jsem dostal OEM k notebooku.

Hmm, nezbývá mi než jim popřát, ať si ty nespokojené uživatele co nejdéle udrží...

Jasně, nějaké náklady tu jsou a AFAIK je podle zákona má platit zákazník. Problém je ale v tom, že prý někteří obchodníci tyto náklady nastavují neúměrně vysoko (to jsem slyšel, nemohu potvrdit nebo vyloučit).

Možná bychom sem mohli přesunout diskuzi z http://www.webfaq.cz/clanek/ORM-Row-Data-Gateway-Table-Data-Gateway-Active-Record-Data-Mapper#commentary478 : Jako řešení bych viděl instanční implementaci (stejně by na omezené tabulky byla potřeba) + statickou obálku pro ty, kdo ji chtějí.

To, že za chvíli by neměl kdo pracovat, byla, doufám, nadsázka, že? Protože jinak by to muselo nejspíš být nezvážení principů ekonomiky.

To použití instancí je do jisté míry spíše filozofický postoj: Ano, v rámci databáze máš tu tabulku jen jednu. Ale můžeš mít více databází. Byl by to asi trošku extrém je používat v jedné aplikaci během jednoho požadavku zároveň. Ale má to i praktické dopady, minimálně: * Tabulka může implementovat nějaké rozhraní a lze potom pracovat s tabulkou obecně. * Výše zmíněné omezené tabulky.

"$this->auctions = Auctions::get­SubtableForOw­ner($this->user->userId);" To možné teoreticky je, ale pak k podtabulce přistupuješ poněkud jinak než tabulce. Kompromisem by bylo to implementovat instančně a udělat statickou obálku. "opravdu ale přesuňme debatu sem" No toto se týká spíše samotných ORM modelů než připojení. "proč do toho plést v jakém stavu je Customers / což více méně spíše chápu jako knihovnu funkcí než, aby zaznamenávala nějaký stav" Zaznamenává stav tabulky (uložené řádky). Takových tabulek můžu mít i víc. To je důvod, proč mám principiálně radši instance.

Takto určitě ne, instanci připojení bych předával v konstruktoru.

Tak si představ toto: máš Presenter s aukcema jen aktuálního uživatele. Použiješ tam tedy něco jako: $this->auctions = $auctions->getSubtableForOwner($userId); Pak se nemusíš starat o user id při výběrech, vkládání ani úpravě, kde zapomenutí není na první pohled vidět, ale je to dost důležité.

Ano, pokud bude ta třída mít ty metody statické. Což jsem rozebíral vedle.

1. "relačními databázemi (RDBMS)" 2. Ano, přesně takto, ale vytvářet stačí jen jednou. Jinak použití instancí může mít výhodu použití omezené tabulky - například mám tabulku aukcí. Typickým příkladem omezené tabulky je zde fixace sloupce s vlastníkem tabulky, takže výběr bude filtrován a při vkládání to bude automaticky doplněno. Při update taky není potřeba myslet na přidání další podmínky. Dělat to bez instancí by byl teprve hnus. Jinak můj názor je částečně ovlivněn i tím, že prostě nemám rád tento přístup a preferuji nějakou formu Dependency Injection. (Neříkám, že jsem jej nikdy nepoužil.) Pokud mám Singleton nebo obecně třídu se statickýma metodama, neměly by IMHO nijak umožnit měnit logický stav. (Úprava cache nemusí být změna logického stavu.)

Principiálně bych doporučil odněkud brát instanci DibiConnection, třeba v konstruktoru. Pokud to bude nevyhovující, je možné vytvořit potomka, který bude mít: function __construct(){ parent::__construct(dibi::getConnection()); }

1. Databáze není databázový systém (rozdíl asi jako fieldy třídy a metody pro práci s nimi). 2. Proč je tu ten magický přístup (ve smyslu statických metod apod.) a ne *instance* tabulky?

Začnu od konce. Nelíbí se mi především ta nízká srozumitelnost a výše popsaný side-effect při přístupu k neexistující vlastnosti. O isset teď nemluvím. Kvůli té nízké srozumitelnosti jsi to asi špatně pochopil. Při prvním přístupu k nějaké vlastnosti se zavolá __get, načtou se data, zapíšou se ve foreach do vlastností a vrátí se požadovaná vlastnost. Při každém dalším přístupu (přistupuju-li k existující vlastnosti) se __get nevolá, protože daná vlastnost existuje. Magická metoda __get je jen fallback.

Typicky Jakubův krátký kód, nad kterým se ale člověk musí trošku zamyslet :D Po prvním přístupu k některé vlastnosti se vše uloží do vlastností a pak se už __get nevolá. Zajímavé by bylo změnit/smazat jiným kódem (třeba i paralelním) ten řádek v DB a pak se dotázat na neexistující vlastnost. To by poněkud překvapivě (pro ty, kdo neznají kód) způsobilo reload z databáze. Jinak jako nástin dobrý, ale doufám, že v této podobě to nikdo nebude používat.

Teď poté, co jsem projel kód bych měl jednu připomínku: Toto: Environment::getHttpResponse()->setContentType($this->contentType); Environment::getHttpResponse()->setHeader('Pragma', "public"); ... se dá zkrátit a vysušit takto: $httpResponse = Environment::getHttpResponse(); $httpResponse->setContentType($this->contentType); $httpResponse->setHeader('Pragma', "public"); ... Jinak bych připomínky neměl. Volba licence je právo autora. Je zde samozřejmě vhodná nějaká volnější opensource licence (BSD i MIT/X11 sem patří). Přidat to jde na http://addons.nettephp.com/cs/ - je to wiki, takže to může přidat každý.

Co takhle Nette extras + nějaká licence?

Já tu čekal, že ! je všeobecně známý a že se dočtu něco ještě jednoduššího! :D To ale asi chci moc.

Windows bych nezařadil do nucených monopolů - to, že ho používá cca 90% okolí mě nijak nenutí ho používat. Mohlo by být zajímavé debatovat proč ho používají, ale to teď nechci. Na druhou stranu, pokud 90% okolí používá ICQ a nic jiného, určitým způsobem mě nutí ke stejnému chování. ICQ zabírá v ČR drtivou většinu trhu. Volí ho lidé opravdu protože je nejlepší? Existují i lidé, kteří si to nemyslí, ale přesto ho používají. Hádejte proč... Je tu další efekt, který si uvědomujeme čím dál tím víc: shromáždění velkého množství informací u jednoho poskytovatele. S informacemi lze nakládat různě. Dokud se pro to rozhodnou uživatelé dobrovolně, je to ještě OK (např. chci mail u Google, protože je pro moje požadavky nejlepší), ale v kombinaci s nuceným monopolem to je zlo. Nestavím se do role mluvčího. Jen ukazuju, na co lidé jako uživatelé (spolutvůrci trhu!) zapomínají a co si neuvědomují. To neznamená, že by to nevyužili, jen si neuvědomují výhody.

Z principu souhlasím. S Googlem to je ještě dobrý, hlavní problém tu je, že nejste závislí jen na tom, co používáte vy, ale dost i na tom. Co používají potenciální zákazníci. Ještě horší je situace, kdy nejde o praktický monopol (lidé to používají protože chtějí a kdyby nechtěli, mohli by snadno přejít jinam), ale o, nazval bych to nuceným monopolem, kdy jsem nucen to používat, protože to používají ostatní. Proto například nepoužívám icq ale Jabber. Trošku OT: Znáš Google Webmasters tools? Tam AFAIK nabízejí některé věci vysvětlit a případně poslat k novému posouzení. Neříkám, že to je ideální, ale co vám kromě smíření se se ztrátou reálného zbývá?

Nevím, co používáš k databázím, ale pokud PDO, tak tam se dá nastavit, aby používalo výjimky a není nutné dělat šílenosti typu if (!$sql->query($q)) throw new ...

... před časem jsem se o tom rozepsal na http://v6ak.profitux.cz/clanky/jak-by-mel-vypadat-kazdy-autoload.php .

PHP na to má AFAIK přímo nějakou fci.

Co takhle pravit při každé změně názvy stávajících souborů? Jinak, jak to řeší systém? Neměo by to být převáděno na jedno systémové kódování?BTW: já taky mám radši soubory bez diakritiky.

Já bych opatřil noindex hlavě tu stránku next. BTW: není pro vyhledávače nejlepší, když mají Předchozí článek Mysql poředí řádků v dotazu? Stejně to IMHO nezabere moc času.