Komentáře uživatele Administrátor

Re: virtual a blocklist

jo ale to bych nedělal nic jiného než blokoval čísla, dříve na Windows Phone 6.5 existovala app, která se snažila podle seznamu najít kdo volá, není něco takového na adroid / iOS? Možná je čas tohle oživit.

Re: Re: Trademark publisher - podvod jak Brno

ano také jsem to dostal znovu, je to jednoduché sází na to, že už se zapomnělo každopádně mám nápad, možná jsou dvě možnosti první ÚOOÚ ochrana osobních dat a druhý používají očividně ke komerčním účelům ochrannou známku, která jim nepatří, čehož by je majitel ochranné známky mohl vyzvat, aby se vzdali?

Re: :-o

ja myslel, že jsem to vysvětlil? :( nechával jsem si přeposílat zprávy z free emailu na centrum.cz na svůj soukromý email na své vlastní doméně, tudíž nemám důvod se přihlašovat do free schránky? ale psal jsem to v textu ne? a jinak ano emailů mám více než 50

Re: Re: Re: Blbost

díky za komentář, to se hodí, byl hodně přínosný

Re: Proč tak složitě?

článek je obecné řešení, vaše řešení funguje pouze v konkrétním případu, představte si nějaký obecný datagrid, kde si uživatel podmínky vyhledávání, řazení atd. nakliká sám, pak je vaše řešení nepoužitelné

Re: Index

nj ale to jsou dva dotazy potom, a co když chceme například stránkovat? bude union rychlejší než neindexovaná verze?

Re: tapetování zbozi.cz

řekl bych, že v tomhle se mýlíte, jedná se o stejné produkty! např. máte eshop s kočárky a s hračkami, určitě na zbozi.cz můžete mít z jednoho shopu kočárky a z druhého třeba jezdící autíčko, ale když Vás napadne přidat i do hraček nějaký kočárek, protože by se to mohlo líbit maminkám co tam nakupují hračky je to špatně, resp. chápejte jako úplně totožný produkt! tedy jde o to, že pod jedním IČO nelze prezentovat duplicitně stejný obsah! je to logické jednalo by se o zřejmé tapetování, představte si podnikatele, který si udělá 20 shopů a do každého z nich si dá mobil IPHONE, a ještě odstupňuje u každého eshopu ceny od koruny, tedy výsledkem budou vytapetované první dvě stránky
K článku: UTF FIX BOM

Re: Skript

cca 2,5 cm pod nadpisem tohoto článku je odkaz "Zdrojový kód ke stažení"

Re: Blbost

nejsem si jist jestli jsem to vysvětlil dostatečně, ale problém spočívá, že není rozumný nápad používat diakritiku v názvu souboru, je to tam napsané? nebo není? ale určitě to tam někde bude, snad to vyplívá alespoň z kontextu

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();

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