Autor Zpráva
obj3ct
Profil *
Řeším docela zajímavý problém: v db v tabulce mám seznam uživatelů. Mám 3 třídy jako pluginy. Pro každého uživatele z tabulky se generuje v html tabulka s nějakými hodnotami na základě tříd pluginů. Nejdříve jsem tohle řešil čistě pomocí tříd, tj.: postupně procházet řádky v tabulce v cyklu foreach a každý nový cyklus pracovat s třídou pluginu(tu jsem naplnil nějakým obsahem) a rovnou vypisoval obsah. Tohle řešení má výhodu, že zabere asi jen 600KB paměti. Jako další řešení jsem zkoušel v 1 cyklu vytvořit objekty objekt['uzivatel']['plugin1'] .... s nějakým obsahem a pak v dalším cyklu objekty číst a generovat layout tabulky. Tohle řešení, ačkoliv místo jednoho kroku/cyklu provedu 2, tak je rychlejší než předchozí, ale zabere asi 30 MB paměti. Jaké řešení je správnější/čistější a proč PHP potřebuje tolik paměti pro nový objekt?

... snad je problematika z tohoto popisku dost jasná (protože vlastní kód je hrozně dlouhý)
Lamicz
Profil
"(protože vlastní kód je hrozně dlouhý) "
To je spatně - vlastní třídy by měly být co nejkratší. Nevím přesně jak je to udělaný, ale většinou se to dělá tak, že naplním asoc. pole a předám data šablonám, kde ho projdu a obalím HTML.
30MB RAM to je už dost síla, tam se něco IMHO krutě zacykluje, ale i tak se mi to číslo moc nezdá na pouhým procházení polem s HTML.
Hlavně moc nechápu, v čem mi v tomto případě to OOP pomůže mimo toho, že to bude děsně složity.
obj3ct
Profil *
Pomůže to hodně. Pokud budu chtít přidat plugin, tak přidám jen třídu. Je to aplikace na správu uživatelů. Vlastně se jedná o to, že když chci třeba vypsat 700 uživatelů, každý má 6 pluginů, tudíš 6x700 objektů zaplněných daty... nakonec jsem se raději vrátil k původnímu řešení = co třída to 1 objekt(protože v php se špatně přistupuje ke statických třídám pomocí cyklů, pač pak musím volat call_user_func a různé podivnosti). Celé to funguje např. při vypisování uživatelů takhle: projde se login.php který includuje všechny pluginy a vytvoří objekty. Pak se includuje listusers.php, který projde db a příslušným objektům pošle data, ty si vyberou z daného řádku v db vyberou to co potřebují/podporují.. pak se zavolá statická třída glayout, které předám všechny objekty a ta vygeneruje hezkou tabulku pro daného uživatele a pak se pokračuje dalším uživatelem .... Celé to spočívá v tom, že 1x vytvořím objekty a pak do nich postupně jak se prochází db sypu data(což je rychlejší než kdybych ty objekty znovu vytvářel).
obj3ct
Profil *
... jen škoda, kdyby se použilo XML, tak by to bylo tak o 50% kratší a přehlednější. Bohužel některé hodnoty jednotlivých parametrů v pluginu se generují automaticky a proto to není možné.

Tady mám kus kódu pluginu:

$this->table_layout = array(
array( array('title', array('mail_username' => $this->val_names['mail_username'])),
array('input_text', array("mail_local_part" => $this->mail_local_part, 'tsize' => 5, 'tmax' => 20)),
array('text', "@"),
array('select', array('mail_domain' => $this->mail_domain, 'list' => $this->listDomains())) ),

.....
obj3ct
Profil *
... ten pak budu asi nahrazovat funkcema.
Lamicz
Profil
No, doporučuji prostudovat autoloading. Obvykle se používá model co soubor to jedna třída (protože je to nejjednodušší právě ve spojení s autoloadem).
Co se týče té ukázky toho pluginu, ručně bych to asi napsal rychleji, navíc jsou to - alespoň pro mne - naprosto nenaučitelné konstrukce. Asi bych doporučil se podívat "k sousedům", např. NForms v Nette frameworku. Já to sice nepoužívám, ale jak jsem koukal, je to určitě přehlednější a logičtější. Alespoň pro mne.
P.S. Ta Vaše aplikace na mne nepůsobí nijak dobrým dojmem.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0