Komentáře uživatele Administrátor

Re: Re: Re: V MySQL se to dá vypnout

zajímavé, tedy feature co umožňuje zablít si databázi nekonzistentními daty, doufám, že nebude nikdy potřeba

Re: V MySQL se to dá vypnout

bavíme se o kontrole na multi null? vypnutí unique_checks mi nic neříká, můžeš popsat co tím přesně myslíš? pokud je sloupec unique tak pevně doufám, že kontrola vypnout nejde? nebo k čemu je něco takového dobré?

Re: Jak ukladat texty

já to řeším zástupnými hesly {__REGISTRATION_LINK__}, což při překladu nahradím aktuálním linkem

Re: open source

když něco budu platit tak to asi nebude open source ne? jinak sorry článek spojuje více věcí v jedno a tak ani z tvého příspěvku není zřejmé na co reaguješ (chyba článku) shrňme to takto - open source je něco na co se nelze spolehnout a je velice nebezpečné na něčem takovém založit business (neexistuje zoodpovědná osoba), - google je něco co vytváří trh, který jen stěží lze ignorovat, ale zároveň podmínky jsou velmi nerovnocenné pro zůčastněné strany, - poslední malý topic je opět o rovnocennosti zůčastněných stran, obchodní vztah mezi nerovnocennými a různě velikými partnery je s velkou pravděpoodbností narušen už v základech z principu věci

Re: exec

tak ono v některých případech to jinak nejde, např. rozbalování 7gz archivů, zjišťování velikosti adresáře by bez toho bylo v mnoha případech nepoužitelné (nebo php snad něco takového umí? nemuselo by projít všechny soubory a sečítat jejich velikosti? = nereálné) ale samozřejmě běžné operace nepotřebují exec, asi by stačilo si to upravit aby přidané fce byly zakázány, např. vypnout archivy, apod.

Re: Podmínky AdSense

Ke které části textu se reakce vztahuje? Btw. to o čem mluvíte je hezké, ale ještě nikdy mi google peníze nevrátil za podobné prokliky, které popisujete. Ale nerozvíjejme flame o tom, jak google nemá žádný support nebo o tom jak "kontaktujte nás" na stránkách google se ztratilo v překladu a všechny pokusy o kontakt vedou na rozsáhlý faq.

Re: Re: A jak to tedy udělat?

myslím, že je to celkem zajímavý nápad, on ale je problém jen vůbec se samotnou represí seznamu, on prostě ze zbozi.cz žije a stěží se dá představit, že si odstřihne platícího zákazníka, nicméně za chvíli nebude chtít nikdo platit, protože všichni ze zbozi.cz utečou a nebude mít návštěvníky (myšleno s nadsázkou ono 10% odliv pro něj zas tak moc neznamená) otázka je, jestli jiné portály to mají jak řešit, umí to řešit? heureka, hledejceny apod.? opravdu je znatelný odliv uživatelů na tyto portály?

Re: Jednodušší postup

pletu se nebo to nebude fungovat? 1. ano, první dva kroky by mohla nahradit fce autoUTF od dg nicméně spoléhá jen na dvě kódování což by nemusela být pravda 2. DOM pozná kódování podle charsetu v meta tagu, proto, by se měl nahradit, ale ani to není spolehlivé, proto byl přidán ještě bod 5

Re: Hrazení nákladů

záměrne v článku uvádím náklady minimálně dopředu domluvené (tedy před koupí = doprava = cca 99Kč)! ze zkušenosti desítek obchodů sleduji, že zákazníci spíše jsou tak drzí, že do telefonu řeknou však je to v pořádku, stejně bych zboží mohl do 14 dnů vrátit, a o nějaké nutnosti platit dopravu nechtějí slyšet, tento trend vidím, ale spíše v poslední době, nevím jestli krize dělá z lidí nezodpovědné barbary nebo jeslti krize přivedla na internet ty klasické české vychcánky, kteří dosud internetu nevěřili a tak přece na něčem tak nespolehlivém, kde je to samý zloděj, nebudou nakupovat

Re: bulvární žvást

že by to tak nebylo v době psaní článku? víme? více fištrónu občane ČR, víme? nebo, že by tolik lidí problematiky určitě lépe znalých než vy toho nevšimlo?

Re: Re: Re: misstatement

update 29.1.2010 je zřejmé, že viditelnost a zapouzdření je nutné rozdělit do bodů 7 a 8, chyba díky za upozornění

Re: overloading vs. overriding

Máte pravdu, bod 6. je poněkud zmateně napsaný, kombinuje překrytí a přetížení (celý odstavec kombinuje přetížení a překrytí), nicméně v PHP něco jako přetížení dost dobře udělat nejde. Tedy 29.1.2010 update bodu 6. který pojednává pouze o překrytí, přetížení je o jiných jazycích než je PHP. Bohužel v době psaní článku je to celkem rozšířený nešvar (pro články o PHP) a tak najdete podobných článků více. Co se týče atributů vs. vlastnosti zkuste rozvést jaký je v tom rozdíl.

Re: DB Error

DB to právě neřeší, kdyby vyskakovala chyba bude určitě mít svoje číslo, záleží na sql_mode jestli máme možnost měnit, jinak mysql striktně tyto chyby nevyhazuje

Re: Re: Re: Re: Re: Re: Komentář

1. v zahraničí je to neuvěřitelně rozšířené, na webexpu jsem potkal jednoho fina žijícího v Praze, co se zabývá tvorbou těchto systémů, především pro finský trh 2. i poker proti počítači musí být kontrolovaný, stejně jako automaty v restauracích, a měli by být pověřeny ministerstvem financí, shledávám tady stejnou potřebu vzhledem k tomu, že si mohou dovolit reklamu na Nově, asi na tom nebudou špatně, a asi by zvládli i nějakou odměnu některému z politiků přihrát (takže tento business si myslím, že bude vzkvétat, jako každý hazard)

Re: YAGNI

já nesouhlasím, bojuji hodně s tím, abych tento princip dodržoval a čím víc se nutím tím méně mám stresu každá funkčnost určitým způsobem je pro projekt svazující, klade určitá omezení, kdyby už ne žádné tak minimálně nutí programátora přemýšlet jestli nějakým dalším krokem nenaruší něco jiného pracuji na vlastním systému, který je vyvíjen po dobu tří let, neuvěřitelný problém jsou funkce, které využívá např. jen jeden zákazník a zvykl si na ně, vznikli bonusem, jako vedlejší efekt něčeho, bylo velice snadné je tam dodělat, proč ne jenomže vývoj projektu si vyžádal nefunkčnost této funkce, která pro celkový koncept vůbec není důležitá, stojíme před otázkou, že buď musíme zajistit zpětnou kompatibilitu projektu pro chod této funkce nebo musíme tuto funkci opravit, až jich budete takových mít 30 už bude každá změna problém pochopitelně zákazník si za své peníze nenechá nic vzít! už mu nevysvětlíte, že ta funkce není žádoucí! takže z původního bonusu se stává do budoucna sleva uplatňována zákazníkovi za to, že mu bereme něco co jsme udělali z dobré vůle (nebo z blbosti) **YAGNI**

Re: Re: Re: Re: Komentář

1. věřím, že by to klaplo, už jsem o tom přemýšlel, ale styl businessu mi nějak jde proti srsti (český člověk je správná cílová skupina) 2. naplňuje to formu hazardu, mělo by to být kontrolované stejně jako každá internetová sázkovka, nebo jste nikdy nehrál poker přes net? a věřil jste, že můžete vyhrát? že Vám počítač nekouká do karet?

Re: Re: Komentář

snad bych jen dodal, procento lidí, kteří sedí na zadku a přemýšlí jak zbohatnou a co, že je ta vlna, je v současné době čím dál vyšší, až snad alarmující, protože kdo za chvíli bude pracovat :) řekl bych, že pár lidí chce naskočit do rozjetého vlaku, ale tady asi záleží na rychlosti, je to podobné jako, když začal boom internetových obchodů, kdo nasedli první sedí v kupé, zbytek se tlačí v posledním vagonu a umírá na nedostatek kyslíku

Re: Komentář

já sem přesvědčený, že výdělečné jsou! vždyť co lidí hraje automaty spíše bych se věnoval otázce, je to hazard, a neměl by být regulovaný? je to letadlo které není ani nijak kontrolovatelné a proto mne zajímá jestli nějaký ten provozovatel sem tam do hry nepustí nějakého virtuálního černého pasažéra je to podobné jako internetové kasino, taky tam můžete hrát výherní automat a počítač točí třešničkama, a věříte mu, že vám tam vždycky tu náhodnou otočku šoupne? že nepodvádí?

Re: Re: Re: Re: jako ASP.NET MVC

1. Model=řádek tabulky to je jasné, tam není co vymýšlet, ať už bude umět cokoli nebo odkazovat na cokoli co to dělá a vrací přes tento model výsledek (to máme tedy náš Customer, Product, User, Order, Invoice) 2. akorát dál mi není jasná ta podobnost mezi třídou co tahá věci z tabulky a repository, přijde mi, že celkem úspěšně tohle můžeme spojit, nebo považujete Repository za v podstatě db layer? je o tom někde nějaký rozumný a čitelný výtah? nějaký tip?

Re: Re: jako ASP.NET MVC

A není Repository to co říkám? CustomerTable, ProductTable? To je přece vzor Repository ne? Ono ale podle mne i model řádku v tabulce, tedy Product1 (name=šroubovák), nebo Product2 (name=vrtačka), by měl snad umět pracovat s databází ne? Co třeba potřeba 1. ukaž produkty které si někdo zakoupil společně tak asi zavolám Product1->getProductsWhoBuyAlso() samozřejmě bych to mohl předat nějaké Repository (ProductRepository extends Repository) a říci ProductRepository::getProductsWhoBuyAlsoWith(Product1->id) ale není to krkolomné? no možná je to v pořádku, pak tedy model je jen hloupá cache, instance databázového řádku a všechny akce nad ním vykonávám prostřednictvím nějaké černé krabičky případně můžeme implementovat metodu Product1->getProductsWhoBuyAlso() { return ProductRepository::getProductsWhoBuyAlsoWith(this->id) }

Re: getDb v Ormionu

1. prosím určitě to neber jako kritiku, to jakým způsobem bude tahle funkce napsána je dost zásadní, proto jestli má smysl funkce typu **static function find()**, protože pokud je nutné přistupovat k db instančně tak tyhle funkce nemají smysl ve statickém kontextu 2. no to je zhruba to co píšu v článku, tedy mám nějakou abstraktní třídu Customer? a tu podědím do Db1Customer a Db2Customer a každý znich bude pracovat s jiným connection? je to tak, to je jediná možnost využití? Chtěl sem vědět jen jestli to lze nějak reálně použít a jestli tahle funkce má význam protože, jak jsem psal, Customer může někde uvnitř spolupracovat s Productem a ten už zase neví se kterým connection pracovat? tedy existuje příklad využítí takového Dependency Injection? můj názor je, že v případě, že je to konstruováno tak, aby šlo využít DI, tak si odpálím větev pod nohama, aniž bych věděl jestli mám kam skočit

Re: Re: Re: Dva detaily

Chápu, že Dependency Injection má dobré myšlenky, ale dá se to v tomto příkladě nějak v budoucnu použít? Tedy říkáš, že statické metody ne, že Customer::find(1) není správně, protože chceme umožnit využívat instanční metody a vlastnosti instance, tedy tato metoda může v nějakém případě mít potřebu přistupovat k něčemu co je instanční a zaměnitelné, krom přístupu k databázi, tedy getDbConnection, což by mne prakticky také zajímalo jak je realizovatelné? save(); $c2=new Customer(); chceš říct, že tady je správné provést něco jako $c2->setDbConnection(dibi::getConnection('db2')); $c2->save(); mě totiž děsí, že pod nohama objektu Customer odpálím připojení k databázi se kterým třeba počítá kdy člověk pracuje v rámci jednoho objektu, jednoho modelu s více databázemi zároveň? napadá mne jedině nějaká forma synchronizace (musí se tedy jednat o naprosto totožné databáze, co když před metodou save ověřujeme jestli má zákazník nějaké produkty objednané a pokud ano zapíšeme i rezervace s jeho registrací? pak tedy voláme objekt Product, který nepočítá s tím, že Customer je už někde jinde, že zákazníka ukládá jinam a produkty by měl ověřovat také v databázi jiného systému? no nevím)

Re: Re: Re: Předávat DibiConnection.

a já měl pocit, že to je jeden z důvodů proč lidi toli požadují late static binding, protože ono i bez toho se dá obejít

Re: Re: Re: Dva detaily

Doufám, že se někdo přidá do diskuse k tvému názoru, protože si nejsem jist části: "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." prosím příklad, nebo bližší vysvětlení ad. názor: už pár let používám to co ty vyzdvihuješ a opravdu mi vadilo pokud sem chtěl například vytvořit form s několika selecty a nemohl jsem použít $form->addSelect("IDexpedition", ExpeditionTable::fetchPairs()); $form->addSelect("IDguaranty", GuarantyTable::fetchPairs()); atd. příjemnější mi bylo i $form->addSelect("IDguaranty", Guaranty::table()->fetchPairs()); než $guarantyTable=new GuarantyTable(); $form->addSelect("IDguaranty", $guarantyTable->fetchPairs()); dále proběhli nějaké další funkce a opět potřebovali vrátit něco od tabulky guaranty a opět sem musel vytvářet novou instanci, takže během jedné funkce jsem třeba 3x musel vytvořit instanci tabulky, jen proto, abych vypsal nějaké páry ale to jen názor, protože funkce na 30-40řádků se stávali hodně nepřehlednými, nicméně stále je to přístup, který upřednostňuje X orm frameworků, řekněme si tedy proč je to špatné nebo je to jen otázka názoru

Re: Dva detaily

1. ? která věta konkrétně? přijde mi slovo databáze všude v kontextu použitelné a pochopitelné? 2. opět, která část konkrétně? name="František"; CustomerTable::insert($customer); ?> navrhuješ snad name="František"; $customerTable=new CustomerTable(); $customerTable->insert($customer); ?> ? jendak mi to přijde o řádek navíc a jednak mi přijde, že instance se vytváří úplně zbytečně, pokud to využiji v jedné metodě tak dobrá, ale to mám složitější kód, tak budu pokaždé vytvářet instanci? má to výhodu?

Re: Předávat DibiConnection.

problém s instancí bude, že stěží lze použít např. ve statické metodě Customer::find(1) jak si tady šáhnu na instanci (resp. každá statická metoda co vrací sadu objektů si musí nejprve jeden vytvořit, aby získala připojení k databázi)? to mne nutí ke statické vlastnosti

Re: Postřehy k článku

no doba pokročila, pokud budeš chtít koukni se na další části (tohle jsem psal po jednodenní známosti s dibi i nette), jde mi hlavně o vyvolání diskuse, stále mne připadá, že je tady obrovské množství programátorů, včetně mne, kteří neumí tyhle témata rozumně uchopit (tedy co se týče PHP, ale proč teda většina dělá v PHP - to je jiná pohádka) je někde to tvé ORM vidět?

Re: Re: Re: Re: Lazy loading

přidal jsem ukázku na git, článek byl updatován a jsou tam odkazy na zdrojáky co se týče defaultních hodnot budou nestěžejnější metody getValue($name); } public function __set($name, $value) { $this->setValue($name, $value); } public function __isset($name) { if (isset($this->data[$name])) return true; if (isset($this->$name)) return true; return false; } public function __unset($name) { if (isset($this->data[$name])) { unset($this->data[$name]); unset($this->modified[$name]); } else unset($this->$name); } public function setValue($name, $value) { $columns=self::config()->getColumns(); if (isset($columns[$name])) { // vlastnost se uklada do db if (!is_null($value)) { // typova kontrola $type=$s[$string]['type']; if ($type=="%i") $value=(int)$value; elseif ($type=="%f") $value=(float)$value; elseif ($type=="%s" || $type=="%t") $mixed=(string)$value; else throw new DbUndefinedDataTypeException(); } $this->data[$name]=$value; $this->modified[$name]=1; // byla hodnota zmenena? phpactiverecord to oznacuje jako dirty } else { // nejedná se o vlastnost ukladanou do db $this->$name=$value; } } public function & getValue($name) { if (array_key_exists($name, $this->data)) { return $this->data[$name]; } elseif (array_key_exists($name, $this->defaults)) { return $this->defaults[$name]; } else { return $this->$name; } } ?> 1. se domnívám, že chceme zajistit při každém přístupu k vlastnosti objektu volání metody __get a __set 2. metoda __set vždy provádí typovou kontrolu, je to vhodné? 3. je na zvážení jak by se měli chovat hodnoty isset a unset, předpokládám, že defaultní hodnota neznamená že isset bude vracet true, 4. unset předpokládám, že zruší i informaci o tom, že záznam byl někdy modifikován? nějaký další názor na kód?

Re: Re: Lazy loading

k věci, ať z toho zase není bezvýznamný flame, neodpověděl si na otázku

Re: Re: Re: Re: Re: Lazy loading

citace z článku: "Vytvářet novou instanci new Customer by mohlo být matoucí, co takhle tedy, jak navrhuje Jakub (getByPrimary), to ale také trochu zavání tím, že se to načítá z databáze (programátor by to tak mohl chápat?) a mohlo by to být matoucí." řekněme tedy jiná metoda než konstruktor, tedy new Customer, máš nápad??

Re: Re: Re: Lazy loading

zkusím na to udělat příklad snad to bude jasnější

Re: Re: Re: Lazy loading

proč by to nešlo, já právě nechci pokaždé načítat záznam, představte si že děláte tohle for($i=0;$i<=40000;$i++) { $p=Product::getByPrimary($i); $p->salesPrice= "slozity vypocet zalozeny na nekolika funkcich a okolnostech, ktere nedovoluji volat hromadne zpracovani, nebo je hromadne zpracovani z mnoha duvodu problematicke, nebo dokonce chci vratit pouze dotaz, ktery volam pozdeji hromadne"; $p->save(); alternativně $update[]=$p->getUpdateSql(); } alternativně $sql->multi_query(implode(";", $update)); protože multi_query je tisíckrát rychlejší a z několika minut zpracování dělá několik sekund! ale to už je jiný článek a opravdu je to tak, věřte tomu prosím, je to tak!

Re: Re: Re: Lazy loading

to si opět nerozumíme, 1. právě proto, aby si orm pamatovalo co se změnilo, je nutné využívat magické metody a proto nemůže být nikdy nastavena vlastnost/hodnota právě v takto $this->name, tedy public $name;, ale právě v nějakém jiném poli _data[$name] to už sem psal 2. problém je právě v defaultních hodnotách, následující postup 2a. new Customer - v této chvíli mi to nastaví defaultní hodnoty, tedy $this->payerOfVat=0; tedy ORM si myslí, že payerOfVat byl nastaven, což není úplně pravda protože ve chvíli, kdy provedu update 1. $c=Customer::getByPrimary(1); 2. $c->password="Franta"; 3. $c->save(); mi to změní i hodnotu payerOfVat což jsem vůbec změnit nechtěl, já chtěl změnit jen jeho heslo! samozřejmě je možnost, že metoda getByPrimary, by defaultní hodnoty nenastavovala, ale opět nevím jestli je to OK

Re: Re: Lazy loading

tak já se obávám, že __get se bude volat po každé, protože data budou asi uložena jinde než v $this->name, většina ORM, alespoň napsaných v PHP je má uloženy v nějakém poli, tedy typicky $this->_data['name'], hlavně proto, aby poznali při přístupu k hodnotě, že se jedná o hodnotu uloženou v mysql "Jinak jako nástin dobrý, ale doufám, že v této podobě to nikdo nebude používat." co je na podobě špatné?

Re: Lazy loading

no asi rozumím jak to myslíš jen mi něco uniká, že nevidíš ten problém (třeba tam není), ale já když provádím save() tak přece vždycky budu k těm hodnotám přistupovat!!! a to je to co nechci! já chci změnit cenu výrobku, aniž bych načítal ten řádek z databáze! Chci udělat tohle 1. $c=Customer::getByPrimary(1); 2. $c->name="František Omáčka"; 3. $c->save(); aniž bych provedl jakýkoli SELECT do databáze

Re: Re: Re: Re: Re: Re: Re: Re: Re: Položka (Název) nesmí být prázdná

Ujasněme si to: 1. bavíme se stále o DEFAULT, měl by být nastaven už při vytváření nového objektu? a. David říká, že ano b. Jakub říká, že ...

Re: Re: Re: SQL mode

tak to je jiná to jsem nevěděl, máte s tím někdo zkušenost, nicméně je to až tak rozhodující, pro to co by měl jednoduchý ORM umět?

Re: Re: Re: Re: Re: Re: Re: Položka (Název) nesmí být prázdná

OK díky, za názor, jestli jsem to dobře pochopil odporujete si s Davidem v tomto (ten naopak lazy loading co se týče default považuje za nevhodný, mimochodem dosud to tak řeším, ale právě je to opravdu zmatečné, v mnoha případech bych logicky očekával to a potřeboval opak a kdykoli se ke kódu vracím po delší době, tak musím přemýšlet jak to autor myslel - není to intuitivní)

Re: SQL mode

o sql mode píši v článku také, ale podle mne jsou mizivé šance pro 99% lidí tohle nějak ovlivnit, stejně tak ani když mám vlastní server bych si nedovolil změnit sql mode kvůli 10projektům, protože dalších 90 by mohlo přestat fungovat! nebo se mílím, že taková změna, pokud nejde o stavění serveru přímo na míru dané aplikace je nemožná?

Re: Re: Re: Re: Re: Položka (Název) nesmí být prázdná

takže navrhuješ při každém updatu objekt nejprve načíst z databáze? to se mi moc nelíbí, hlavně třeba pro hromadné updaty apod. nebo navrhuješ oddělit nastavení defaultních hodnot od konstruktoru? i getById() přece musí objekt vytvořit, pokud teda navrhuješ tohle pak by to znamenalo, že budeš nový objekt vytvářet nějak takto $c=new Customer(); $c->setDefaults(); $c->name="test"; $c->save(); ? nebo jsme se nepochopili?

Re: Re: Re: Položka (Název) nesmí být prázdná

S těmi defaultními hodnotami je jiný problém, pokud by to bylo opravdu tak, že při vytváření instance nastavím hodnoty na default, pak bude problém při vykonání pouhého updatu. Mám formulář, který např. pouze nastavuje, jestli má zákazník přijímat newsletter, nebo nastavuje jen heslo, tedy chci upravit jen hodnotu password. V takovém případě by nebylo možné udělat. $c=new Customer(); $c->ID=5; $c->password="heslo"; $c->save(); protože by to updatovalo na default hodnoty! v opačném případě bych musel vždy načít obsah objektu z databáze před jeho uložením což je dost značný problém pokud např. z nějakého xml upravuji 40000 řádků stylem, že chci upravit jen cenu, tedy potřebuji $p=new Product(); $p->ID=56; $p->salesPrice=1024; $p->save();

Re: Re: Re: Položka (Název) nesmí být prázdná

2. MANDATORY ------------ Tedy navrhuješ, že ORM by mělo kontrolovat a vyhazovat vyjímku v případě, že vlastnost objektu je mandatory? a) Ovšem jak MANDATORY chápat, někdy je nesmyslné, aby prošla i prázdná hodnota. A je to dle mého už omezení databáze, ale to ostatně je i délka řetězce apod. b) Kombinace DEFAULT a MANDATORY je tedy také nesmyslná ne? Pokud se tedy DEFAULT vytvoří už při vytovření instance, tak abych mohl uplatnit omezení nebo ho vůbec testovat, platí to jen pro případ, že později hodnotě nastavím null?

Re: Re: Re: Položka (Název) nesmí být prázdná

1. DEFAULTNÍ HODNOTY -------------------- ok, TEDY ŘENĚME, že už při vytváření nové instance objektu, budou nastaveny defaultní hodnoty, tedy každé volání konstruktoru způsobí iteraci nad všemi definovanými sloupci a nastaví defaultní hodnoty, tam kde mají být dosud jsem se bránil tomu, protože zpomalení při vytváření 25000 objektů bylo znát, ale to je asi stejně ojedinělý úkol a všechno něco stojí ? V tomto případě mi nastavení databáze a kombinace NULL a DEFAULT přijde nesmyslná? k tomu přece nikdy nedojde?

Re: Položka (Název) nesmí být prázdná

samozřejmě je nutné řešit validitu na úrovni modelu, ale bavím se tady o základní validitě, kterou může řešit už abstraktní třída objektu v orm, která k tomu ví všechny potřebné údaje (ví co může být empty, default, mandatory), samozřejmě validita je mnohem složitější, ale jde mi o to co ještě je potřeba ošetřovat za např. validním formulářem nette - jak jsem ale ukázal v příkladech, něco jako mandatory asi model ošetřovat bude muset, protože mysql to nedělá bame se ale o konkrétních věcech 1. defaultní hodnoty, měli by se tedy nastavovat už ve chvíli new Customer?tedy ihned po nějaké metodě setValues nebo podobně se nesetnute hodnoty nastavi na default? 2. mandatory - jak to myslíš, takový parametr by měl existovat ne? protože jak říkám mysql to neřeší (bohužel mandatory právě jde chápat několika směry a jedním z nich může být prázdná hodnota, kterou mysql dovolí zapsat i pro not null)

Re: plurály

jak gettext tak moje navrhované řešení s asoc. polem umožňuje definovat libovolné množství pluralu, zapisuje se tam forma pluralu, tedy od X je to tato forma, od XY tahle atd. každopádně podle mne by to mělo stačit, v kolika jazykových verzích je linux? a používá gettext. samozřejmě nejzajímavější je japonština, protože tam se s počtem mění i pořadí slov a způsoby oslovení atd. pak by prý měla být zajímavá ruština, protože tam se to počítá nějak po desítkách, ale co se týče množství pluralu mělo by se to vejít do tří

Re: Je

Moje řešení, které navrhuji spočívá (a je to snad v článku uvedeno): 1. v centralizaci překladů v databázi (trochu ještě o úroveň výš co se týče správy) 2. centralizovaná verze umožňuje aktulizovat distribuovaným implementacím aplikace překlady a navíc je upravovat dle své libosti 3. při každé aktualizaci se automaticky vytvoří asociativní pole z databáze 4. měřil jsem to při 1000 překladech a nevidím sebemenší zpomalení, opět nedá se to měřit (samozřejmě sofistikovanými nástroji ano, ale pohybujeme se v desítkách milisekund - ani ne) 5. moje řešení i předestírá metodu, kdy se generuje gettext z dtb místo pole 6. stále nechápu to vyhledávání v databázi jsou pouze dvě metody: a. jedním dotazem si stáhnu celý obsah potřebných slov a vytvořím asociativní pole (jsem tam kde jsem byl) b. s každým překladem hledám v databázi, čímž se množí počet dotazů do dtb a to už je jiná pohádka, kterou jsme spolu už jednou řešili (stále trvám na tom, že transakční náklady na neustálé dotazování do dtb jsou vysoké) pochopte prosím, nechci si měřit pindíky, ale opravdu mi jde o nejvhodnější řešení za takové a takové situace, osobně už bohužel/bohudík nejsem běžným programátorem, který bere každou zakázku a tak bohužel/bohudík už nespatřuji tu koloritu každé jiné aplikace, ale už se soustředím pouze na určitý směr aplikací (proto nehledám řešení toho co řešit v příštích 10 letech nebudu, i když ocením když tady o tom bude zmínka a směr, kde se o tom dozvědět více), pojďme si říct pro co je jaké řešení vhodné a proč a pro koho a jestli vůbec se s tím můžeme setkat nebo alespoň více než 5% programátorů P.S.: gettext by měl být vhodný od 5000 překladů, jestli jeho vhodnost končí na 10000 nevím, ale bude někdy nekdo z nás řešit takovou aplikaci? stojí za to to usílí s optimalizací databází a hledáním řešení přes databáze? P.S.2.: mimochodem článek je hlavně o tom, jak řešit překlady aniž bych v budoucnu změnou metody si nějak ublížil

Re: Plurály

jde mi o kontext, nebo o to že časem se význam identifikátoru změní a pak může být zavádějící %d window na místě, kde by třeba podle vývoje mělo být popup, to byl opravdu rychlý nástřel, nebo menu není vždy jídelníček a nebo výpis kategorií nebo rozbalovacího menu, bojím se toho že se změnami aplikace by si programátor mohl vytvořit svůj vlastní slovník pro programátora, a překládal by identifikátory do podoby identifikátorů kterým rozumí

Re: Nette extras

moc mi nejde php fashion a ty komentáře a tak aby to bylo hezké, takže extras ... klidně pokud to za to stojí a někdo se koukne na krásu kódu a komentářů licence? na tohle snad není potřeba licence je to pár řádků kódu, BSD, MIT je něco volnějšího?

Re: Re: Re: Další řešení

odpovídám trochu se spožděním, ale mysql je přece známé že neumí používat v poddotazech indexy ne? tedy klasická chyba na mysql SELECT count(*) FROM (poddotaz) není zrovna nejvhodnější způsob zjištění počtu řádků kdo používá dibi, tak bude znát, že datasource má tento problém

Re: Re: Další řešení

Asi záleží na které verzi mysql je to testováno, co vím tak stále by neměla být opravena chyba v IN. Snad někdy ve verzi 6.4, WHERE IN je podle mého testování nepoužitelné, mám takový pocit, že Jakub Vrána už o tom taky psal, ale abych si nevymýšlel, sorry nezbývá mi teď čas hledat články a bugy v mysql, ale bezpečně vím, že v WHERE IN mám při velkém množství záznamů obrovský problém na mysql +- 5.0.86

položek 0-50 z 129 [1 / 3]
[1] [2] [3] >>