Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Něco navíc v zeleném?
A proč ne...

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Klub PHP [ŽP: neomezená] (kategorie Programování) moderuje makovec.
Archiv
Diskuse o vybornem skriptovacim jazyku php. Dulezite odkazy, pred polozenim dotazu zkuste hledat odpoved zde:
  1. www.php.net - domovská stránka PHP
  2. www.kosek.cz - spousta tutorialu pro PHP v češtině
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: lfuzaua
[ 1845 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
pepak pepak - Pepak.net 2.8.2007 08:50  2003

Řeším teď otázku, jestli jde v PHP nějak rozumně zařídit dědičnost mezi statickými třídami. Rád bych dosáhl toho, abych měl sérii základních tříd, od kterých bych mohl odvozovat potomky s tím, že aplikace prostě použije posledního nadefinovaného potomka. Kdybych chtěl ty třídy instancovat, byla by to trivialita:


// Tohle se nachazi nekde v zakladni casti aplikace

class ZakladniTrida { ... }
$aktivniTrida = new ZakladniTrida();

// Tohle si napise uzivatel
class OdvozenaTrida extends ZakladniTrida { ... }
$aktivniTrida = new OdvozenaTrida();

// Kdekoliv v aplikaci pak pracuju s instanci $aktivniTrida
// a neresim, ktery konkretni potomek je pouzit.
$aktivniTrida->vykresli_zahlavi();
$aktivniTrida->vykresli_telo();
$aktivniTrida->vykresli_paticku();


Na instancích se mi nelíbí pár věcí, hlavně to, že pak musím řešit viditelnost proměnných, správné přiřazování (použít nebo nepoužít referenci) a tak nějak se mi to zdá méně bezpečné (vždycky si někdo může usmyslet, že zrovna proměnnou $aktivniTrida potřebuje pro svoje celočíselné ID pro třídu výrobků).



Pro statické třídy nelze přímo použít žádnou proměnnou, že bych měl třeba $aktivniTrida = 'ZakladniTrida';. Nicméně jsem si našel způsob, jak tohle obejít (na vstupu mám $aktivniTrida = 'ZakladniTrida';, z toho potom vytvořím novou třídu AktivniTrida pomocí eval("class AktivniTrida extends $aktivniTrida { } a skutečně pak můžu požívat věci jako AktivniTrida::vykresli_hlavicku(); a opravdu to funguje tak, jak by člověk od zděděného zpracování očekával.¡V tom není problém.



Spíš se teď zabývám tím, jak tenhle systém udělat co nejjednodušší pro použití. Teď na to mám funkci založenou na tom, že vím, jak se ty třídy mají jmenovat: Na vstupu dostanu string se jménem třídy, kterou potřebuju dostat, a vycházím z předpokladu, že se předdefinované třídy budou jmenovat Zakladni${jmeno} a uživatelské jen ${jmeno}, takže můžu prostě naincludovat soubory, podívat se na to, jestli existuje třída ${jmeno} a pokud ne, udělat ten eval výše. To funguje docela uspokojivě pro dva možné potomky třídy (základní a uživatelský), už ne tak pro tři (základní, modifikovaný základní [možno si představit třeba jako cachovanou variantu základní verze]) a víc. Teď přemýšlím o tom, jak to udělat pro větší počet možných potomků. Zatím mi připadá docela použitelné jít na to přes get_declared_classes() a prostě si po vložení příslušných souborů najít poslední odpovídající třídu a tu evalnout. Co byste na takové řešení řekli?

etdirloth EtDirloth 31.7.2007 13:49  2002
pepak [1999]:
4) ja som podobny problem riesil vytvorenim Data Access Layer -> samostatna kniznica, ktora riesi vsetky pristupy k DB vo forme funkcii/metod, zapuzdrujucich samotne SQL statementy a ich volania, pricom samotna aplikacia/engine/system neobsahuje ani ciarku SQL, ale dotazuje sa prave prostrednictvom tejto kniznice (analogia ulozenych procedur) -> ked sa rozhodnes pouzit novy SRBD, proste prepises celu kniznicu pre tento novy system a linknes ju namiesto povodnej

pridanim novej vrstvy ziskas vacsiu volnost v sposobe jej implementacie (moze byt okrem ineho napisana v inom jazyku, vyuzivat specifika daneho SRBD a tym optimalizovat pristup k datam, ...), ale zaroven si pridas potrebu reimplementacie kazdeho pouziteho SQL statementu pre kazdy pozadovany SRBD (ale to by si konec koncov aj tak musel urobit)
mach 31.7.2007 11:59  2001
Hm, prispevek s id 2000 a hned je v nem chyba:

"ted se rozmyslim" <— "ted kdyz se rozmyslim"
mach 31.7.2007 11:58  2000
Dlouho jsem nepouzival templaty a v PHP generoval semanticky HTML kod. Ted na par veci pouzivam Smarty a jsou fajn. Co se tyce porovnani obou pristupu: pomoci stylovani CSS se neda udelat plnohodnotna view cast MVC-like frameworku; ted se rozmyslim, ze na nejakou stranku chci pridat detailni prehled produktu v kosiku, tak proste nekam pripisu:

{include file=cart_overview.tpl}
pepak pepak - Pepak.net 31.7.2007 08:39  1999
A neprilis souvisejici druha otazka: Rekneme, ze chci napsat vicemene univerzalni system, kde si uzivatel muze pomoci nejakych promennych upravit chovani k obrazu svemu. Hezky je to videt treba na databazovych nebo jazykovych tridach - system by mel byt schopen prizpusobit se uzivatelovu prostredi (ja bych treba chtel Firebird, ale nekdo hned zacne vyskakovat s PostgreSQL a spousta lidi samozrejme zna a pouziva akorat MySQL, takze je treba pocitat i s nim), ale je docela otazka, jak to udelat, kdyz kazde prostredi bude mit sva specifika: I treba u jazyku je to uz videt (kazdy jazyk pouziva jiny format data a casu, napriklad, ale muzou tu byt treba otazky slovosledu - pro nektery je lepsi "100 uzivatelu online", pro jiny "online 100 uzivatelu" a ne vzdycky to pujde osetrit pres printf), u databazi uz je to docela extremni (i kdybych se drzel jenom MySQL, bude diametralni rozdil, jestli budu pouzivat trojkovou radu, ctyrkovou radu nebo petkovou radu - nemluvim o tom, ze jednou se vola mysql_* a podruhe mysqli_*, jde treba o takovou vec, ze na MySQL 5 si spoustu veci napisu jako ulozenou proceduru nebo trigger a tim mi odpadne obrovska spousta PHP kodu).

Jaky je vas nazor na to, jak tohle resit? Vim o nekolika cestach, kudy do toho, kazda se mi ale zda do jiste miry nevyhovujici:

1) Nekolik souboru, kazdy pro jednu variantu implementace (jako to dela treba PHPNuke): Mam treba soubory mysql.php, postgresql.php, interbase.php apod., ktere vsechny obsahuji stejnou strukturu trid nebo funkci (kazda obsahuje treba funkce jako sql_connect() nebo sql_query() se stejnou strukturou parametru a implementuje je pomoci specifickych funkci toho ktereho rozhrani). V programu proste includuju tu verzi, kterou si uzivatel vyzada. Problem je v tom, ze me to stavi pred dilema, jestli radsi vyuzivat jen ty funkce, ktere jsou spolecne vsem implementovanym systemum (a obetovat tak spoustu vykonu i moznosti) nebo jestli timhle zpusobem rozepsat strasne velkou cast kodu (fakticky si nevystacim s sql_query(), potrebuju spis neco jako sql_read_article() nebo sql_create_user()) a stejne mit neefektivni aplikaci (tentokrat spis spotrebou pameti - vsechna data se musi najednou nacist do promennych a teprve pak zpracovat) a navic to nejspis bude tak neprehledne, ze se v tom nevyzna ani prase.

2) Jeden soubor a v nem na kazdem vhodnem miste spoustu vetveni podle jednotlivych parametru (tak funguje nebo aspon drive fungovalo phpBB): Proste mam funkci create_user() a v ni je na vhodnem miste vetveni typu if ($database_engine=='mysql') { ... } elseif ($databaseengine=='postgresql') { ... } else ... Je to taky neprehledne, ale asi o neco min nez predchozi pripad, naproti tomu se mi vubec nelibi, ze to znamena pri kazdem provadeni skriptu prinejmensim zparsovat, kdyz uz ne primo spustit, obrovskou spoustu zbytecneho kodu.

3) Docela se mi libi myslenka, mit zdrojak v podobnem tvaru jako bod 2 vyse, ale delat spis necim jako jsou v konvencnich jazycich IFDEFy - s tim, ze pred vlastnim nasazenim na web se kod napred prozene nejakym prepocesorem, ktery podle zadanych parametru vyhazi vsechny zbytecnosti a necha jen cisty PHP kod. V podstate se tak prace s vybranim vhodne vetve prehodi z runtime na install-time, zvetsim praci pro cloveka, co to bude poprve nasazovat, ale zmensim praci pro server pri vlastnim behu. Problemu je nekolik: Jednak nevim o nastroji, ktery by mi tohle umoznil (ale to se da celkem snadno zaridit), hlavne si ale nedovedu predstavit, jak bych takovy system ladil nebo upravoval, protoze tim preprocessingem vlastne prijdu o primou a pruhlednou vazbu mezi zdrojakem a tim, co se skutecne vykonava. Pokud by system bezel na serveru, kde je nejaky akcelerator, tak se to snad da resit nejakou specialni syntaxi komentaru, ale pak bude docela problem vyznat se v tom, kde ktery komentar zacina a konci...
hugo hugo Usmívejte se, - bude hůř!!!! 31.7.2007 08:31  1998
U větších projektů používám Smarty. Ale někdy je to trochu poznat na rychlosti. Ovšem pokud design dělá někdo jiný, tak je to neocenitelné.
pepak pepak - Pepak.net 31.7.2007 08:13  1997
Jak se divate na nejruznejsi templatovaci systemy? Porad tak nejak premyslim, jak by mel idealni templatovaci system vypadat a jestli by nakonec nebylo nejlepsi se na templaty vykaslat uplne (napsat do PHP zdrojaku natvrdo HTML kod, takovy, aby sel snadno stylovat).
johny_g Johny_G - Relaxační terapie pro lopušáky ZDARMA! 26.7.2007 13:32  1996
Ježiš já jsem dement :-)). Kdybych si koukal pod ruce, tak to fungovalo už když radil huh :-). No nic, aspoň to mám rovnou v UTF-8. Díky oběma.
waco 26.7.2007 13:07  1995
Johny_G$email_to = "=?windows-1250?Q?" . imap_8bit( $email_to_name ) . "?= <" . $email_to_email . ">";

jinak bych doporucoval spise utf-8 nebo iso-8859-2, je sance ze to ne/bude umet vice klientu :-) Pokud nejedes utf-8, iconv rad prekoduje...
johny_g Johny_G - Relaxační terapie pro lopušáky ZDARMA! 15.7.2007 19:00  1994
huh [1993]: To nejde :-/
huh huh 15.7.2007 18:07  1993
Johny_G [1988]: to musis delat uplne stejne jako pro ten subject, to je prece uplne stejne pro vsechny hlavicky
johny_g Johny_G - Relaxační terapie pro lopušáky ZDARMA! 15.7.2007 13:29  1992
eso [1990]: Aha, to je mi pěkné :-). Díky.
knedle knedle online - Krabice živých 15.7.2007 11:41  1991
mach [1986]: jsem na tom stejne - lomitko na konci v adrese si definuju jako podadresar
napr:
www.server.cz/test = soubor test.php
a
www.server/test/ = test/index.php'htm

makovec [1940]: zvolil bych www.server.cz/3/24/vzdelani (bez koncovky)
- pokud ono 3/24 je treba 3 mesic, 24 den a jdou prepsat vsechny clanky 3 mesice, potazmo 3 mesice a 24 dne
- pokud 3/24 oznacuji uplne neco jineho, coz neumoznuje dalsi logicke zobrazovani, nechal bych to ve stylu /3-24-vzdelani
eso eso 15.7.2007 09:33  1990
Kdysi jsem si s tim taky hral a nakonec jsem radsi vsechno pri odesilani prevadel na standard iso-8859-2, protoze rada postovnich serveru si s tim v predmetu a dalsich polich proste neporadila.

Kazdopadne, RFC 2049 rika o postovnich klientech a serverech:

Recognize the "ISO-8859-*" character sets to the
extent of being able to display those characters that
are common to ISO-8859-* and US-ASCII, namely all
characters represented by octet values 1-127.

O Windows 1250 se tam nerika nic, takze si nemuzes nikdy byt jist, jestli bude fungovat.
johny_g Johny_G - Relaxační terapie pro lopušáky ZDARMA! 14.7.2007 19:05  1988
Odesílám v PHP email a mám drobný problém s kódováním.
Charset těla jsem nastavil klasicky v hlavičce:
Content-Type: text/html; charset=windows-1250

v předmětu pak trochu komplikovaněji:
$email_subject = "Pozvánka na Chladnou hlavu";
$email_subject = imap_8bit($email_subject);
$email_subject = "=?windows-1250?Q?".$email_subject."?=";

Nicméně to obojí funguje. Problém je v tom, že nevím, jak nastavit charset jménu odesilatele. Když to poleze přes něco v tomto smyslu:
From: Žluťoučký kůň <zlutoucky@kun.cz>

tak se kupříkladu v Thunderbirdu nezobrazí ž. Nevím, zda je to vinou klienta, nebo se dá charset nějak nastavit v hlavičce. Nevíte?

[ 1845 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt