[php] mooi model tegenover 'lekker' coden

[Verwijderd]

Heb ik een mooi OO model gemaakt voor een CMS in PHP, blijkt het dat PHP zich nogal slecht leent voor datsoort modellen.

BV. Ik maak gebruik van 1 database connectie in een klasse DBI die een verbinding maakt bij het eerste gebruik van de functie Query($a_qstr) daarin. Mijn klasse Core maakt een instantie van die DBI. Tevens heb ik een aantal soorten modules die een klasse Module extenden. Deze klassen krijgen ook een instantie in klasse Core. Om deze modules gebruik te laten maken van de database moet ik of core zelf of die dbi in de constructor van die modules meegeven. Het makkelijkst is dan om in module een functie Query(..) te maken die de querie doorgeeft aan $this->core->dbi of aan $this->dbi. Dan kan ik mijn queries uitvoeren door $this->Querie te gebruiken in die modules. Hetzelfde gaat op voor een ErrorHandler, Session, User en Template klasse. Zodoende wordt m'n klasse Module nogal groot en komen er een aantal functies in die door sommige modules niet gebruikt worden. Dit kost allemaal parsetime, beetje jammer...

Dan is het haast makkelijker om die objecten (DBI, User, ErrorHandler, Session en Template) global te maken en gebruik te maken van $GLOBALS['dbi']->Query() etc..

Opties zijn dus:

• Core meegeven aan modules, usage $this->core->obj->func() gebruiken
• Objecten global, usage $GLOBALS['obj']->func()
• Objecten meegeven aan modules, usage $this->obj->func
• Core of Objecten meegeven aan modules en in Module doorgeeffuncties schrijven, usage $this>func()

Beetje jammer dat de scope van php niet gezelfde werkt als die van java, irritant geneuzel met dat $this altijd..

Best een lastige keuze al met al... hoe maak ik mijn keuze?

[Verwijderd]

Ohja, en helemaal irri wordt het als DBI, Template, User, en Session mekaar nodig hebben... Moeten ze dus of global zijn of een reference van Core hebben afhankelijk van hoe en waar ik ze instantieer..

Misschien toch maar eens jsp gaan bekijken

[Postman]

Op vrijdag 15 maart 2002 00:23 schreef fladder het volgende:
Ohja, en helemaal irri wordt het als DBI, Template, User, en Session mekaar nodig hebben... Moeten ze dus of global zijn of een reference van Core hebben afhankelijk van hoe en waar ik ze instantieer..

Misschien toch maar eens jsp gaan bekijken

Tja, je zegt het zelf al: JSP.
Het wordt bij mijn weten niet zoveel gebruikt als PHP, maar omdat je er meer mee kunt dan met PHP heeft JSP zeker de toekomst (ASP tel ik niet eens mee, ASP.NET ken ik niet). Ik ken een mod die hetzelfde hierover denkt (dat zei hij tenminste tijdens zijn presentatie middleware ).
* Postman is ook van plan om met JSP te gaan werken, maar moet eerst zijn server voorbereiden

[eborn]

JSP is toch weer een tikkie uitgebreider. Op school werken wij vooral met Java en daarom sinds kort ook met JSP. Maar ik moet zeggen dat PHP gewoon veel lekkerder werkt. En tot nu toe ben ik nog geen echte punten tegengekomen waarom ik buiten school ook met JSP zou moeten gaan werken.

[GraasGast]

wat ik meestal doe als een module bepaalde objecten nodig heeft is die objecten gewoon in de constructor global te zetten, en dan in een variablele te gooien als reference:

PHP:

<?class blaat {    var $db;    function blaat() {        global $db;        $this->db = &amp;$db;    }}?>

[Verwijderd]

Dan zou je dus ook weer een verhaal kunnen houden over het nut van OO programmeren binnen PHP.
Uit de manual:

Although not every standard OOP feature is realized in the current version of PHP, many code libraries and large applications (including the PEAR library) are written only using OOP code.

Ikzelf geef er de voorkeur aan om niet OO te programeren. Ik houd niet zo van die abstracte objecten.

[Verwijderd]

fladder: Ik heb exact hetzelfde probleem gehad. En het is ook de reden dat ik zoveel mogelijk in Java doe tegenwoordig en zo min mogelijk in PHP, als je het zo mooi mogelijk wilt doen loop je tegen zo veel opstakels op. Maar ik ben benieuwd wat/of drm hier over/iets op te zeggen heeft

[LuCarD]

Helaas is OOP niet zo heel sterk bij PHP als sommige andere talen. PHP is oorspronkelijk ook niet ontworpen om OOP te zijn.

Het zal dus altijd behelpen blijven. De manier van GraasGast is een aardige manier.

Zelf doe ik een soortgelijke oplossing. Ik programmeer zoveel mogelijk in de zelfde stijl. En met soortgelijke variable namen.

dus
db heet altijd $_mysql
user heet altijd $_user
xml heet altijd $_xml
etc

Zo kan ik makkelijk de verschillende objecten benaderen.

[Verwijderd]

Misschien leuk voor mensen die niet bekend zijn met de volgende naamgeving om eens te weten waar het op slaat. Erg praktisch om altijd te weten wat de scope van een object is. Voorbeeldje in geval van een Mysqlobject

$a_mysql als het een argument is in een functie
$l_mysql als het een locale variabele is in een functie
$m_mysql voor classvars

// em voor php met z'm globals roepen we dan even g_ in het leven
$g_mysql voor globals

[dusty]

Op vrijdag 15 maart 2002 09:16 schreef GraasGast het volgende:
wat ik meestal doe als een module bepaalde objecten nodig heeft is die objecten gewoon in de constructor global te zetten, en dan in een variablele te gooien als reference:
[..]

OO en Global, in andere woorden: hoe vern*k je het OO idee het best.

[Janoz]

mooi model tegenover 'lekker' coden

hmm.. vreemd.. Ik merk juist dat waneer ik een mooi model heb het coden juist heel lekker gaat. Mischien is je model nog niet mooi genoeg? ..

Mischien komt het omdat ik niet veel moeite heb om veel variabelen met een functie (methode eigenlijk.. we hebben het hier over OO) mee te geven.

Ik moet echter wel toegeven dat ik me af en toe wel behoorlijk heb lopen irriteren aan het toch niet echt OO zijn van php waardoor ik de OO-principes toch wel een aantal keer geschonden heb....

[chris]

Ja als je echt zwaar OO wilt proggen kan je toch beter aan jsp gaan. PHP code in ieder geval wel lekkerder, en als het niet te uitgebreid is kan je het meeste wel OO maken.

[LuCarD]

Op vrijdag 15 maart 2002 11:53 schreef /dev/null het volgende:
Ja als je echt zwaar OO wilt proggen kan je toch beter aan jsp gaan. PHP code in ieder geval wel lekkerder, en als het niet te uitgebreid is kan je het meeste wel OO maken.

Bah.... het begint bijna een windows-linux discussie te worden.

Hij vraagt toch niet of hij beter in JSP moet gaan programmeren of in PHP. Hij vraag welk programmeer model wij hanteren BINNEN PHP.

Dus als je nix nuttigs hebt toe te voegen zeg dan lekker nix.

[Verwijderd]

Op vrijdag 15 maart 2002 12:34 schreef LuCarD het volgende:
Bah.... het begint bijna een windows-linux discussie te worden.

Hij vraagt toch niet of hij beter in JSP moet gaan programmeren of in PHP. Hij vraag welk programmeer model wij hanteren BINNEN PHP.

Dus als je nix nuttigs hebt toe te voegen zeg dan lekker nix.

Vind het wel lief dat je voor me opkomt maar ik begon eigenlijk zelf over jsp

[LuCarD]

Op vrijdag 15 maart 2002 12:55 schreef fladder het volgende:

[..]

Vind het wel lief dat je voor me opkomt maar ik begon eigenlijk zelf over jsp

FOEI... Flamen op je eigen topic

[Verwijderd]

Ik heb nog es ff zitten lezen heh, maar een CMS, kan dat niet veel beter met servlets dan met jsp? Of kun je servlets en beans en jsp ook nog combineren enzo..

[raptorix]

Op vrijdag 15 maart 2002 01:11 schreef FlamerX het volgende:

[..]

Tja, je zegt het zelf al: JSP.
Het wordt bij mijn weten niet zoveel gebruikt als PHP, maar omdat je er meer mee kunt dan met PHP heeft JSP zeker de toekomst (ASP tel ik niet eens mee, ASP.NET ken ik niet).

En geef eens 1 reden aan waarom asp niet mee zou tellen?

[GraasGast]

Jah nu we het toch weer over oop hebben, ik denk dat ik een soort van oplossing heb voor fladders (en mijn) probleem, zij het een beetje laat.

stel je hebt een class core. Classes die nodig zijn voor andere classes instantiëer je in de core. De andere classes derive je dan van de core. Vaag voorbeeldje:

PHP:

<?require_once("db.php");require_once("template.php");class core {    var $db;    var $template;    function core() {        $this->db = &amp;new db;        $this->template = &amp;new template;    }}class foobar extends core {    function foo($bar) {        $array = $this->db->fetch_array("SELECT info FROM table WHERE id = ".$bar);        $this->template->assign($array);    }}$obj = &amp;new foobar;$obj->foo(3);?>

edit: bovenstaande code is onzin niet op letten, ik moet testen voor ik blaat

[Verwijderd]

Dan maak je ontzettend veel db's, tenminste als je geen contructor maakt of de parent (lees:core) constructor aanroept.

Ik doe het ondertussen zo (globaal)

PHP:

<?class Core{  var $m_Config;  var $m_DB;  var $m_User;    function Core($a_Config)  {    $this->m_DB = new DBM(&amp;$this, $a_Config['dbm']);    //etc...  }    function Error($a_Errstr)  {    $this->m_Errors[] = $a_Errstr;  }}class DBM extends Module{  // alles, dus ook DBM extend Module  // welke zorgt voor een terugkoppeling met core}function Module {  var $m_Core;    function Module($a_Core)  {    $this->m_Core = &amp;$a_Core;  }    // functies aan core koppelen  function Error($errStr)  {    $this->m_Core->Error($errStr);  }  //etc..}?>

verder heb ik nog wat standaard classes, Section, Plugin, Agent die allemaal Module extenden en die weer ge-extend worden door de implementatie van de site, bijvoorbeeld

class Login extends Plugin
class Article extends Section

[GraasGast]

Op maandag 13 mei 2002 12:32 schreef fladder het volgende:
Dan maak je ontzettend veel db's, tenminste als je geen contructor maakt of de parent (lees:core) constructor aanroept.

dohhhh...

* GraasGast voelt zich een beetje dom nu

[GraasGast]

krijg jij nu niet meerdere core's?

PHP:

<?function Module($a_Core) { //moet hier geen &amp; voor staat?        $this->m_Core = &amp;$a_Core;}?>

[Wortelpudding]

Op vrijdag 15 maart 2002 18:04 schreef fladder het volgende:
Ik heb nog es ff zitten lezen heh, maar een CMS, kan dat niet veel beter met servlets dan met jsp? Of kun je servlets en beans en jsp ook nog combineren enzo..

JSP Pagina's worden volgens mij eerst geparsed door een JSP-engine, en vervolgens omgezet in servlets
Conclusie: Als je met JSP werkt, werk je automatisch met servlets

[Verwijderd]

Op maandag 13 mei 2002 13:42 schreef GraasGast het volgende:
krijg jij nu niet meerdere core's?

Ja je krijgt meerdere cores. Correct:

PHP:

<?function Module(&amp;$a_Core){$this->m_Core = &amp;$a_Core;}?>

[ACM]

Op vrijdag 15 maart 2002 18:04 schreef fladder het volgende:
Of kun je servlets en beans en jsp ook nog combineren enzo..

Beans zitten altijd al in beide.
JSP wordt meestal naar een Servlet gebakken en inderdaad je kan er prima mee samenwerken.

[chris]

offtopic:
[quote]
Op vrijdag 15 maart 2002 12:34 schreef LuCarD het volgende:


Bah.... het begint bijna een windows-linux discussie te worden.
[/quote]

Huh?[quote]
Hij vraagt toch niet of hij beter in JSP moet gaan programmeren of in PHP. Hij vraag welk programmeer model wij hanteren BINNEN PHP.

Dus als je nix nuttigs hebt toe te voegen zeg dan lekker nix.
[/quote]

Hmz? Misschien moet je de thread ff goed doorlezen. En ik probeer echt wel te helpen.... De topicstarter begon iig zelf over servlets. Maarja, * chris zal het wel weer bij het verkeerde eind hebben.

[GiLuX]

tja,
er gaat natuurlijk een boel veranderen met php5 (zend engine2)

heb eens met de test binary gespeeld en dat werkt op het eerste gezicht al heel aardig.

testje gedaan met static en private variabelen en dit werkt nu bv ook al:
$foo->bar()->bla();

dat hele gedoe met gecopieerde objecten is er ook uit gegooid en alles is nu netjes een pointer zoals in java.

ik heb alleen nog niet try/catch aan de praat gekregen maar het is me ook niet helemaal duidelijk hoe ze verwachten dat je dat gebruikt

ook multiple inherentence werkt nog niet zoals voorgesteld.

maar je zou in feite al met die die test versie van ZE2 aan de gang kunnen gaan zodat je klaar bent als het spul officieel uitkomt.

aan de andere kant zit je natuurlijk wel een beetje met de gebakken peren als ze op het laatste moment besluiten bepaalde dingen toch anders te doen.

het is natuurlijk een hele grote stap voorwaarts op dit gebied al zullen de echte OO puristen php nooit voor vol aan zien denk ik.

verder, als je in java echt met OO aan de gang gaat kom je eigenlijk automatisch op j2ee uit en komt er nog weer een heleboel bij kijken zoals het opzetten/configureren/beheren van je container zoals orion/jboss/weblogic/websphere, bakken van deployment descriptors/jar/war files etc terwijl je daar in php nauwelijks tijd aan kwijt bent.

het is maar net een afweging hoeveel tijd je er aan uit wil geven en hoe schaalbaar het moet zijn.

[Verwijderd]

Op maandag 13 mei 2002 13:42 schreef GraasGast het volgende:
krijg jij nu niet meerdere core's?

Nee, want ik maak me modules met &$this

PHP:

<?function Core($a_Config)  {      $this->m_DB = new DBM(&amp;$this, $a_Config['dbm']);}?>

[Nielsz]

Op vrijdag 15 maart 2002 11:42 schreef dusty het volgende:

[..]

OO en Global, in andere woorden: hoe vern*k je het OO idee het best.

OF NIET ACM! _{<---- hele grote letters}
Ik heb er een tijdje geleden een discussie met ACM over gehad, want ik liep tegen hetzelfde aan.
Hij gaf toen aan dat hij ook zo iets gebruikt. Voor mijn laatste project gebruik ik deze methode:

code:

class poll
{
    var $database;
...


$poll = new poll();
$poll->database=&$sql;

[GraasGast]

Op dinsdag 14 mei 2002 09:19 schreef Nielsz het een en ander...

is dit dan niet makkelijker?

code:

class poll
{
    var $database;
      function poll(&$database) {
            $this->database = &$database;
      }
...


$poll = new poll($sql);

[GraasGast]

Op dinsdag 14 mei 2002 09:04 schreef fladder het volgende:

[..]

Nee, want ik maak me modules met &$this

PHP:

<?function Core($a_Config)  {      $this->m_DB = new DBM(&amp;amp;amp;$this, $a_Config['dbm']);}?>

woei! nu snap ik het!

[Nielsz]

Op dinsdag 14 mei 2002 10:24 schreef GraasGast het volgende:

[..]

is dit dan niet makkelijker?

code:

class poll
{
    var $database;
      function poll(&$database) {
            $this->database = &$database;
      }
...


$poll = new poll($sql);

Ja, dat doe ik ook wel
Het ws een voorbeeld

[Dennis]

Nielsz :
Ja, dat doe ik ook wel
Het ws een voorbeeld

Ik gebruik die methode idd ook .
Voor mn huidige project gebruik ik een flink aantal hoofdclasses en die worden steeds in functies doorgegeven met &$objectnaam .

Je zou dus kunnen zeggen dat ik 5 core classes heb .

[Nielsz]

Op dinsdag 14 mei 2002 10:59 schreef ddc het volgende:

[..]

Ik gebruik die methode idd ook .
Voor mn huidige project gebruik ik een flink aantal hoofdclasses en die worden steeds in functies doorgegeven met &$objectnaam .

Je zou dus kunnen zeggen dat ik 5 core classes heb .

Wat was het ook al weer?
Listen to the master,
Follow the master?

[Dennis]

Nielsz :
Wat was het ook al weer?
Listen to the master,
Follow the master?

Heb jij capsonertjes gegeten?
Bovendien heb ik dit niet van jou

[drm]

Zef:
Maar ik ben benieuwd wat/of drm hier over/iets op te zeggen heeft

woei

Nou, here goes:
Ik denk dat het probleem een beetje overrated is. Als je een constructor maakt voor een object, bedenk je wat het object nodig heeft om te kunnen "werken". Als 1 van die dingen een instantie is van een ander object, zijn er imo een aantal mogelijkheden

1: je verplicht het als argument van de constructor

code:

class DBI
{
   function DBI ()
   {
   }
}

class Template
{
   var     $dbi;
   function Template ( &$dbi )
   {
     if ( !is_object ( $dbi ) || strcasecmp ( get_class ( $dbi ), "dbi" ) != 0 )
         trigger_error ( "Template::Template () > Argument moet van het type DBI zijn", E_USER_ERROR );
     $this->dbi =& $dbi;
   }
}

$db = new DBI ();
$t = new Template ( $db );

2: Je verplicht enkel bij de functies waar de db nodig is een DBI-argument, en laat het bij einde van de functie voor wat het is

code:

class Template
{
   function Template ()
   {
   }

   function parse ( &$dbi )
   {
     if ( !is_object ( $dbi ) || strcasecmp ( get_class ( $dbi ), "dbi" ) != 0 )
         trigger_error ( "Template::parse () > Argument moet van het type DBI zijn", E_USER_ERROR );
   }
}

3: Je maakt een parent class met een method setDBI () waarin je het DBI object meegeeft
(imo oop-wise de mooiste)

code:

// of whatever namingconventions u use ;)
class UsesDBI
{
   var    $dbi;
   
   function UsesDBI ()
   {
   }

   function setDBI ( &$dbi )
   {
     if ( !is_object ( $dbi ) || strcasecmp ( get_class ( $dbi ), "dbi" ) != 0 )
         trigger_error ( "UsesDBI::parse () > Argument moet van het type DBI zijn", E_USER_ERROR );
     $this->dbi =& $dbi;
   }
}

class Template extends UsesDBI
{
   function Template ()
   {
   }
}
$db = new DBI ();
$t = new Template ();
$t->setDBI ( $db );

Het grootste probleem met die laatste, is dat het behoorlijk complex wordt wanneer je multiple wil gaan inheriten, wat (zeker in deze context) eigenlijk wel mogelijk moet zijn.

Ik heb daar al wat work-arounds voor bedacht, maar die zijn eigenlijk gewoon te ranzig om te posten

_edit:
Was vergeten nog even wat te concluderen
Dus ik ben het ermee eens, dat een mooi OO model niet voor elkaar te krijgen is zonder ranzig te coden. Maar als je de ranzige code binnen een werkende OO structuur houdt en de nette code "bovenop" ligt (het "main"-script za'k maar zeggen) is het misschien stiekem wel geoorloofd smerig te coden