[PHP] OOP of niet bij forum?

[Verwijderd]

bij gebrek aan een nuttig levensdoel hebben wij besloten ons forumpje te herschrijven. met noemt het ook wel bezigheidstherapie. doch wij vroeger ons af wat voor voordelen het heeft bij het proggen van een forum om object georienteerd te proggen.
wat denken jullie dat het best is? en als OOP het best is, kan iemand dan een concreet voorbeeld noemen hoe het bij een forum goed kan worden toegepast?
tnx alvast. kusje, baz

[Verwijderd]

als er in je code nog global voorkomt is het slordige OO

[Stephan Oudmaijer]

in principe moet je al je programma`s maken met het oog op object orientatie. Let wel op dat dit soms betekend dat je performance inlevert! Tevens html leent zich niet voor object orientatie.

[RedRose]

Op vrijdag 22 februari 2002 00:29 schreef fladder het volgende:
als er in je code nog global voorkomt is het slordige OO

Hoe ga je om met de post vars dan? $GLOBALS[""] ? $_POST ?

[Nielsz]

Op vrijdag 22 februari 2002 00:44 schreef RedRose het volgende:

[..]

Hoe ga je om met de post vars dan? $GLOBALS[""] ? $_POST ?

Een goede methode is het meegeven van argumenten aan een methode van een object. dus:

$blaat->a($http_post_vars["zooi"]);

nou kan er door creatief postvar gebruik weinig tot niets verknald worden.

[Verwijderd]

Ja jongens ik ben gewoon benieuwd wat ebter is voor een php forum, OOP of zonder OOP, en als OOP het beste is, waarom dan, en hoe moet dat pcies worden gebruikt (met een concreet voorbeeld als het ff kan want ik snap het neit helemaal)...

[Nielsz]

Op vrijdag 22 februari 2002 01:00 schreef Baz_ het volgende:
Ja jongens ik ben gewoon benieuwd wat ebter is voor een php forum, OOP of zonder OOP, en als OOP het beste is, waarom dan, en hoe moet dat pcies worden gebruikt (met een concreet voorbeeld als het ff kan want ik snap het neit helemaal)...

zoals er al net verteld is, je moet gewoon OO gebruiken.

[DRvDijk]

Hum wat we willen weten is dus.. Waarom we niet doorleuk gewoon een zooi PHP-bestanden kunnen maken en daarin een zooitje functies kunnen maken.. Waarom dat perce met objecten moet..

We hebben dus nu al een forum (ranchorelaxo), OOP durin.. Maar wij zien nu niet meer in waarom we dat erin zouden stoppen.. User-systeem is zo gemaakt (zonder OOP), messages in topics in forums in boards ook.. Waarom OOP?

[Nielsz]

Op vrijdag 22 februari 2002 01:03 schreef elviver het volgende:
Hum wat we willen weten is dus.. Waarom we niet doorleuk gewoon een zooi PHP-bestanden kunnen maken en daarin een zooitje functies kunnen maken.. Waarom dat perce met objecten moet..

We hebben dus nu al een forum (ranchorelaxo), OOP durin.. Maar wij zien nu niet meer in waarom we dat erin zouden stoppen.. User-systeem is zo gemaakt (zonder OOP), messages in topics in forums in boards ook.. Waarom OOP?

Dat merk je wel als je ermee begint
Ik kan je uren vertellen over de voordelen, maar zodra je er mee begonnen ben en je hebt het een beetje door, dan wil je niets anders meer
In feite is het gewoon een 'hogere' manier van programmeren; dus kan ik de vraag stellen: waarom maak je het niet gewoon in ASM, als je het toch 'ouderwets' wil doen?

_{kort door de bocht}

[Verwijderd]

Een aantal redenen waarom OOP zo nuttig kan zijn (voor mij athans).

Je zorgt ervoor dat samenhangende functies allemaal bij mekaar zitten. Zo kan je bijvoorbeeld een class fiets hebben en daarin zitten allerlei samenhangende functies over die fiets. Er zit een functie rem, bel, licht, wiel, etc... in. Deze kan je allemaal makkelijk met elkaar laten samenwerken, zonder dat je bijvoorbeeld specefiek een argument hoeft mee te geven (bv. bel($var)) je kan namelijk binnen een class gebruik maken van de vars die je van te voren gedefinieerd hebt, binnen alle functies van de class.

kweet niet goed hoe ik het verder uit moet leggen, maar ik kan zeggen dat toen ik er eenmaal mee begon er niet meer af kwam

[Verwijderd]

Over OO heb ik ook nog enkele vragen, ik wil er zelf ook mee beginnen.

Hoe doen jullie de html? Spugen de functies in de classes html uit of geven jullie alleen de variabelen terug die een ander gedeelte van het script in html maakt (tabellen er om heen etc).

Is het niet zo dat in php niet alles in OO gaat? Ik bedoel je hebt toch een begane grond in je php code die de objecten aanroept en dit is niet OO lijkt mij.

Hoe spreken jullie de database aan, maak je daar ook een object van of maak je gewoon de $connect (waar de database connectie in staat) global en zet je de query's in de functies van de objecten.

[Verwijderd]

Op vrijdag 22 februari 2002 08:32 schreef Xenith het volgende:
Hoe doen jullie de html? Spugen de functies in de classes html uit of geven jullie alleen de variabelen terug die een ander gedeelte van het script in html maakt (tabellen er om heen etc).

Ik heb een aantal classes die ik gebruik voor bijvoorbeeld de volgende dingen, registreren van gebruikers, inloggen van gebruikers, queryen met de database (en het connecten). Dit wordt daarna allemaal terug gespuugd naar het script dat de class aanriep, zodat ik daar de verkregen waardes kan gebruiken. Hoe ik me HTML doe is met templates van PHPLIB.

Is het niet zo dat in php niet alles in OO gaat? Ik bedoel je hebt toch een begane grond in je php code die de objecten aanroept en dit is niet OO lijkt mij.

Waarom zou alles OO zijn?

Hoe spreken jullie de database aan, maak je daar ook een object van of maak je gewoon de $connect (waar de database connectie in staat) global en zet je de query's in de functies van de objecten.

Zoals eerder vermeld, met een aparte class.

[ACM]

Op vrijdag 22 februari 2002 09:02 schreef DiStance het volgende:
Waarom zou alles OO zijn?

Idd, zelfs een java applicatie heeft vaak stukjes non-OO code
(De main methode etc)

[Dennis]

OK, ik ben momenteel een forum aan het rewriten en die is volledig OOP, dus ik zal ff antwoord gaan geven op zoveel mogelijk vragen die tot nu toe zijn gesteld.

Op vrijdag 22 februari 2002 00:29 schreef fladder het volgende:
als er in je code nog global voorkomt is het slordige OO

Hoewel ik momenteel nog wel globals gebruik, ben ik het wél met je eens en ik zal ze er later ook nog wel uit gaan halen.

Op vrijdag 22 februari 2002 00:42 schreef CK het volgende:
Tevens html leent zich niet voor object orientatie.

Dat is ook niet echt een programmeertaal

Op vrijdag 22 februari 2002 01:00 schreef Baz_ het volgende:
Ja jongens ik ben gewoon benieuwd wat ebter is voor een php forum, OOP of zonder OOP, en als OOP het beste is, waarom dan, en hoe moet dat pcies worden gebruikt (met een concreet voorbeeld als het ff kan want ik snap het neit helemaal)...

Nielsz heeft mij ook omgepraat om OOP te gaan gebruiken in mn forum, en het is hem dus gelukt. Ik heb eerst flink smeergeld betaald en toen heeft hij mij een cursus gegeven

Op vrijdag 22 februari 2002 01:05 schreef Nielsz het volgende:
Ik kan je uren vertellen over de voordelen, maar zodra je er mee begonnen ben en je hebt het een beetje door, dan wil je niets anders meer

Ook waar. Ik begon met 1 simpele class voor database connectivity, maar al snel kwam daar nog een class bij om de persoon die de pagina bezoekt als object weer te geven, daarna een object om de browserversie te detecteren en er eigenschappen aan toe te kennen, en ik ben nu bezig met een object die de output van de pagina's gaat regelen.

Op vrijdag 22 februari 2002 08:13 schreef DiStance het volgende:
kweet niet goed hoe ik het verder uit moet leggen, maar ik kan zeggen dat toen ik er eenmaal mee begon er niet meer af kwam

Wat ook wel vet is dat al die dingen er zo netjes uitzien, met een pijltje. Je spreekt continue alleen maar objecten aan.

Op vrijdag 22 februari 2002 08:32 schreef Xenith het volgende:
Hoe doen jullie de html? Spugen de functies in de classes html uit of geven jullie alleen de variabelen terug die een ander gedeelte van het script in html maakt (tabellen er om heen etc).

Ik werk knap ingewikkeld. Ik heb een object output, en die kent in principe drie vars, namelijk: top, page, footer en func. Top bevat de header van de pagina, die wordt on-the-fly samengesteld, zelfde geldt voor footer maar dan de onderkant. Page bevat alle code voor die ene pagina (de eigenlijke content) en func zit in alle functies, die het daarin uitpoepen. Aan het eind van elke functie wordt die func toegevoegd aan page.

Aan het eind van de pagina doe ik met $output->print(); de werkelijke output in 1 keer. Dit heeft flinke voordelen, want als ik een foutmelding krijg kan ik nog alles cancellen op een simpele manier en een alternatieve fout-pagina in de variabelen zetten. En ik kan heeel makkelijk gzip compressie toepassen.

Is het niet zo dat in php niet alles in OO gaat? Ik bedoel je hebt toch een begane grond in je php code die de objecten aanroept en dit is niet OO lijkt mij.

Je hebt een basis php pagina die alle objecten creëert, maar het is nooit 100% OOP nee, dat klopt.

Hoe spreken jullie de database aan, maak je daar ook een object van of maak je gewoon de $connect (waar de database connectie in staat) global en zet je de query's in de functies van de objecten.

Net als bij dit forum Topix het geval is, heb ik een class voor elke database-soort en daarin zitten de functies om de database aan te spreken. Topix heeft het iets anders, die heeft namelijk allemaal predefined functies voor alle queries, ik heb alle queries ook nog in een los bestand staan.

[Verwijderd]

Op vrijdag 22 februari 2002 09:04 schreef ACM het volgende:

[..]

Idd, zelfs een java applicatie heeft vaak stukjes non-OO code
(De main methode etc)

Haha, ja ja me eerste java applet was zo ongeveer puur en alleen main method... geïntereseerden: http://www.zinn.nl/java/Postcode.html

rara, een postcodechecker

[ACM]

Op vrijdag 22 februari 2002 09:11 schreef DiStance het volgende:
Haha, ja ja me eerste java applet was zo ongeveer puur en alleen main method... geïntereseerden: http://www.zinn.nl/java/Postcode.html

Hehehe, ik ken het. ALhoewel mijn eerste applet binnen m'n opleiding viel en de eerste erbuiten op mijn 'huisje' te vinden is.
Vrijwel volledig OO-based, maar vast niet efficient/logisch/duidelijk genoeg etc

Anyway, om terug te komen op het topic, je moet gewoon voor jezelf afwegen in hoeverre je je classes met html laat werken. Je kan alle objecten een "toHTML" methode meegeven oid die dan stukjes tabel genereren voor messages en complete pagina's voor topiclistings. Of dat de meest efficiente manier is is ook maar de vraag

[Verwijderd]

Op vrijdag 22 februari 2002 09:17 schreef ACM het volgende:

[..]

Hehehe, ik ken het. ALhoewel mijn eerste applet binnen m'n opleiding viel en de eerste erbuiten op mijn 'huisje' te vinden is.
Vrijwel volledig OO-based, maar vast niet efficient/logisch/duidelijk genoeg etc

Anyway, om terug te komen op het topic, je moet gewoon voor jezelf afwegen in hoeverre je je classes met html laat werken. Je kan alle objecten een "toHTML" methode meegeven oid die dan stukjes tabel genereren voor messages en complete pagina's voor topiclistings. Of dat de meest efficiente manier is is ook maar de vraag

Geloof dat ik langzaam gek begin te worden van dat spelletje van je kan maar niet winnen van die verdomd 'slimme' computer

Maar om idd ff terug te komen op het topic..besluit voor jezelf wat jij het makkelijks vind werken, ikzelf vond templates erg handig.... HTML en PHP volkomen gescheiden in aparte files..das toch wel makkelijk

je kan idd ook functies maken voor HTML generatie... functie HTMLhead() en HTMLfoot() ofzo... deze genereren dan de boven en onderkant van de site

HTH

[ACM]

Op vrijdag 22 februari 2002 09:23 schreef DiStance het volgende:
Geloof dat ik langzaam gek begin te worden van dat spelletje van je kan maar niet winnen van die verdomd 'slimme' computer

Ohhhh
Ik kan wel winnen van de computer hoor Maar dat zal komen omdat ik het algoritme heb bedacht (ow en omdat er een of andere supervage bug in zit waardoor ie een extreem stomme zet kan maken...)

ikzelf vond templates erg handig.... HTML en PHP volkomen gescheiden in aparte files..das toch wel makkelijk

Maar waar "vul" je de templates? Dat is dan de volgende afweging Laat je die binnen de classes zelf vullen (dus Reply.getFilledTemplate() oid) of laat je een aparte Template class oid dat doen (bijv topicViewPage.setReplies(Replies[])) oid.

Zelf vind ik die keuzes altijd erg lastig en ik betrap me erop dat hoe kleiner het projectje, hoe minder template based ik te werk ga. Ook al zou het dan ook handig zijn

[Verwijderd]

Op vrijdag 22 februari 2002 09:29 schreef ACM het volgende:

[..]

Ohhhh
Ik kan wel winnen van de computer hoor Maar dat zal komen omdat ik het algoritme heb bedacht (ow en omdat er een of andere supervage bug in zit waardoor ie een extreem stomme zet kan maken...)
[..]

Hmmz, dan zal het wel aan mij liggen dat ik het niet zo snel door heb


Maar waar "vul" je de templates? Dat is dan de volgende afweging Laat je die binnen de classes zelf vullen (dus Reply.getFilledTemplate() oid) of laat je een aparte Template class oid dat doen (bijv topicViewPage.setReplies(Replies[])) oid.

Ik maak gebruik van de template class van PHPLIB (terwijl ik weet dat hij langzaam is, maar gewoon de tijd nog niet hebt gehad om een ander te bekijken ) Dus het enige wat ik eigenlijk doe is in mijn PHP script opgeven dat ie bepaalde vars moet setten dus ik krijg een bepaalde waarde terug bijvoorbeeld de username bij het inloggen, als iemand dan ingelogd is dan gebruik ik een andere template waarin ik ergens neer kan zetten "Welkom DiStance, je bent ingelogd". De naam DiStance is dus een template variable.. Die ik set in me PHP script.

Zelf vind ik die keuzes altijd erg lastig en ik betrap me erop dat hoe kleiner het projectje, hoe minder template based ik te werk ga. Ook al zou het dan ook handig zijn

Ik heb hetzelfde probleem, ik probeer het altijd wel zo effiecient mogelijk uit te denken en op te zetten, maaruhh.... wij weten beter

[Glimi]

OOP zorgt voor uitbreidbaarheid, afscherming en nog een hoop :):

Uitbreidbaarheid:
Classes kan je overerven! Woei! Geen code 2x schrijven. Dus er is geen sprake van 'wat veranderen hier en het dan ook hier, hier en hier' te veranderen.

Afscherming:
Een class is verantwoordelijk voor zijn taak. Hij moet deze taak doen dmv de interface die hij aanbied. Mocht er iets fout gaan daar, dan is het de 'schuld' van die class.

Overigens ondersteund PHP typeafscherming niet geloof ik

[Glimi]

Op vrijdag 22 februari 2002 09:11 schreef DiStance het volgende:

[..]

Haha, ja ja me eerste java applet was zo ongeveer puur en alleen main method... geïntereseerden: http://www.zinn.nl/java/Postcode.html

rara, een postcodechecker

Kwel, Java Applets met een main

[Verwijderd]

Op vrijdag 22 februari 2002 09:46 schreef Glimi_ie het volgende:

[..]

Kwel, Java Applets met een main

I know

[drm]

OOP heeft imo niets te maken met een forum of wat voor project je uberhaupt mee bezig bent.

Het belangrijkste is dat je je programmatuur naar een bepaald abstractie-niveau brengt, wat het de programmeur een stuk makkelijker overzichtelijker maakt.

Ik kan er nog veel meer over zeggen, maar ik weet niet precies wat je vragen zijn

[Nielsz]

Op vrijdag 22 februari 2002 09:05 schreef ddc het volgende:
Nielsz heeft mij ook omgepraat om OOP te gaan gebruiken in mn forum, en het is hem dus gelukt. Ik heb eerst flink smeergeld betaald en toen heeft hij mij een cursus gegeven

[..]

Ook waar. Ik begon met 1 simpele class voor database connectivity, maar al snel kwam daar nog een class bij om de persoon die de pagina bezoekt als object weer te geven, daarna een object om de browserversie te detecteren en er eigenschappen aan toe te kennen, en ik ben nu bezig met een object die de output van de pagina's gaat regelen.
[..]


Ik werk knap ingewikkeld. Ik heb een object output, en die kent in principe drie vars, namelijk: top, page, footer en func. Top bevat de header van de pagina, die wordt on-the-fly samengesteld, zelfde geldt voor footer maar dan de onderkant. Page bevat alle code voor die ene pagina (de eigenlijke content) en func zit in alle functies, die het daarin uitpoepen. Aan het eind van elke functie wordt die func toegevoegd aan page.

Kijk en dat is imo juist weer niet goed
Je moet classes aanmaken op basis van functies, en niet op basis van output oid.

Dus imo moet je per class dus een outputfunctie bouwen ipv 1 outputclass.

[drm]

Nielsz:
Dus imo moet je per class dus een outputfunctie bouwen ipv 1 outputclass.

Imo moet je een baseclass OutputAble maken, met een virtuele functie, die wordt overgeerfd en overrided door de afstammelingen.

Hoe je dat doet in PHP?

Nou heel eenvoudig:

PHP:

<?
class Outputable
{

   function Outputable ()
   { 
      $this->_IS_OUTPUTABLE = true;
   }
   function output () { die ( "Virtual function 'output' not defined!" ); }
}

class Melpje extends Outputable
{
   function Melpje ()
   {
      Outputable::Outputable ();
   }
   
   function output ()
   {
      echo "melpje";
   }
}

foo ( $obj )
{
   if ( $obj->_IS_OUTPUTABLE )
      $obj->output ();
}
// ...
$t = new Melpje ();
foo ( $t );
?>

dit is _een_ manier om interfaces te "faken" in PHP, (vind het niet zo mooi, maar goed, dat krijg je als je geen typechecking hebt in PHP...)

Maar dat is OOP-wise imo de juiste oplossing

[Dennis]

Op vrijdag 22 februari 2002 12:48 schreef Nielsz het volgende:
Kijk en dat is imo juist weer niet goed
Je moet classes aanmaken op basis van functies, en niet op basis van output oid.

Dus imo moet je per class dus een outputfunctie bouwen ipv 1 outputclass.

Tssssk
En hoe heette dat bestandje ook alweer dat ik van jou kreeg

Was dat niet "output.class.php"

Enne, in die output class staan functies die de paginaopbouw doen, dat zijn in principe complete functies. Dus je hebt toch 1 soort functies allemaal bij elkaar

[Verwijderd]

Bedankt luitjes, het is al weer een stuk duidelijker, maar ben nog wel een beetje verward door al deze info... (en meningsverschillen over de juiste implementatie van object orientatie )
(ps. ik gebruik templates...)

Wat ik nog niet helemaal snap is waarvan ik objecten moet maken, want mijn oude forum was ook OO maar dat was technisch gezien volgens mij compleet fout.

Ik had toen voor elke page een class, dus zeg maar een class TTopicIndex, een class TEditProfile, enz. Die zijn allemaal afgeleid van TMotive (zo heet mn forum engine dinges) waarin functies staan om naar de database te connecten enzow. In elke class zit vervolgens een TClassName.display() om alles op het beeld te plurren.

Maar wat ik van jullie begrijp is dat het niet goed is om voor elke page een class te maken?

Dus ik moet zeg maar een viewtopic.php maken waarin ik een paar objectjes maak en die daar data uit trekt en daar vervolgens een pagina van breid?

Als ik dat goed snap, dan is het me wel aardig duidelijk, behalve; waar moet ik pcies classes van maken? En moet ik dan ook een hoofdclass maken waarvan ik elke class afleid, en zoja, welke functies moeten dan in die hoofdclass zitten?

Nogmaalz tnx alvast

[Nielsz]

Op vrijdag 22 februari 2002 13:43 schreef ddc het volgende:

[..]

Tssssk
En hoe heette dat bestandje ook alweer dat ik van jou kreeg

Was dat niet "output.class.php"

Enne, in die output class staan functies die de paginaopbouw doen, dat zijn in principe complete functies. Dus je hebt toch 1 soort functies allemaal bij elkaar

Daar staan layout technische dingen in, dus tables enzo.
functies om errors te creeren en te tonen moeten in de class error (imo dus)
En anders heb je een hele oude versie gekregen

[drm]

Kijk, zoals ik al zei, je moet proberen te abstraheren. Klinkt een beetje stom, maar het is in feite hetzelfde idee als normaliseren in een database. Alleen gaat het nu niet meer alleen om data, maar ook om methodes die specifiek met die data te maken hebben.

Stel nu dat er methodes betrekking hebben op een grote groep verschillende objecten, dan trek je die methode "omhoog" in de object-boom, zodat de objecten die methodes kunnen overerven.

Wanneer je van te voren niet weet wat de inhoud van een functie zou kunnen zijn, maar je weet wel zeker dat die functie moet bestaan voor dat object (zoals bijvoorbeeld de toString methode in Java (raad je aan die ook altijd in PHP te implementeren) spreek je over een virtuele of abstracte functie. Deze zou je bijvoorbeeld in je baseclass kunnen definieren:

code:

class Object
{
   function Object ()
   {
   }
   
   function toString () { die ( "virtual method undefined" ); }
}

Nu verplicht je elk object dat afgeleid wordt van "Object" om een methode "toString" te implementeren, want anders wordt namelijk de methode toString van Object aangeroepen, en dan "die"-t je script dus. (wees de compiler te slim af )

euhhh, zeg maar wanneer ik moet stoppen

/edit:
weet je wat ik ga gewoon verder.

Wanneer er in principe een inhoud bekend is van een method, maar je vindt dat een bepaald afgeleide object de method kan overriden dan gaat het als volgt:

code:

function Object
{
   function Object () {}
   function toString () { die ( "virtual method undefined" ); }
   function dump () { var_dump ( $this ); }
}

class Complex extends Object
{
   var  $real,
      $im;

   function Complex ( $real, $im )
   {
    $this->real = $real;
    $this->im   = $im;
   }

   function toString ()
   {
    return "Reeel deel: " 
         . $this->real 
         . "\nImaginair deel: "
         . $this->im . "\n";
   }

   function dump ()
   {
    echo "Dump van Complex:\n";
    Object::dump ();
   }
}

nu stop ik wel ff, want dan kan je nog wat dingen vragen, mocht je dat nodig vinden. (of ik zit natuurlijk voor niets te typen)

[Dennis]

Op vrijdag 22 februari 2002 16:01 schreef Nielsz het volgende:
En anders heb je een hele oude versie gekregen

Ik bedoelde toen mijn output.php, maar als ik het zo nalees geef ik gelijk dat het woordje die jouw class benadrukt. Mijn fout

[Verwijderd]

tnx drm!!!! erg nuttig

nog wel een probleempje, volgens mij kan ik niet zo goed abstract denken, want ik weet nog steeds niet zo goed wat voor objecten ik nou pcies moet maken voor een forum... maar ik ga er denk ik maar eens een dagje voor zitten

uitleg over dat abstraheren is nog wel altijd welkom trouwens mocht je (of iemand anders) tijd teveel hebben en bezigheidstherapie zoeken

[Janoz]

Op zaterdag 23 februari 2002 15:44 schreef Baz_ het volgende:
..
nog wel een probleempje, volgens mij kan ik niet zo goed abstract denken, want ik weet nog steeds niet zo goed wat voor objecten ik nou pcies moet maken voor een forum...

OO ligt eigenlijk veel dichter bij hoe mensen denken. Mensen die OO lastiger vinden dan imperatief denken meestal net wat te moeilijk . Eigenlijk is het heel simpel.

Hmm .. een forum.. Wat heeft een forum... Nou .. gebruikers.. en reacties.. en topics.. owh ja, er is ook nog een database..

Als je zo ff over je projectje nadenkt heb je 4 belangrijke objecten te pakken. Wat je vervolgens het beste kunt doen is deze objecten op een a4-tje tekenen en kijken hoe ze van elkaar afhangen. Een topic heeft bijvoorbeeld een lijst met reacties.

Zorg dat elk van de onderdelen een opzichzelf staand iets is. Hierdoor is het ontwikkelen ook een stuk makkelijker. Stel je veranderd iets in je class reactie, dan hoef je niet vervolgens je hele topic class te herschrijven.

[Verwijderd]

owkeej
zal eens even een paar papiertjes gaan bekladden.. i'll be back in a few hours

[DRvDijk]

Eeij baz.. Ik zat te gister bedenken in me icons-projectje een class users te maken bijvoorbeeld.. Daarin de functies inloggen, registreren, wijzigen.. Lekker overzichtelijk..

Stel ik wil dat users kunnen registreren, inloggen en hun pass kunnen wijzigen. Lijkt me redelijk duidelijk: class user, function register, login & changepass. Maarrrr...
Die gegevens moeten uit een database komen. Wat doe je dan? Doe je dan telkens een nieuwe link oproepen met de MySQL-server? Hoe pak je zoiets aan dan? Nieuwe class voor de link? Class link ofzo?

Ik snap classes wel, maar hoe je dat dan eventueel doet met MySQL-links?

edit:
Relees dit topic nogmaals.. Er wordt gesproken over een aparte class.. Maar levert dat niet erg veel extra overhead op? Telkens als je een nieuwe class maakt of een functie daaruit opvraagt die iets uit de DB nodig heeft een nieuwe link maken? Da's wel erg veel overhead of niet? Of maak je eerst een class met de link, $link = new db; en daarna $link->query en link->close bijv.. Dat zou kunnen werken..
Goed.. compleet ander vraagje.. $user = new user; $user->load_level, $user->changepass.. Kun je die hele $user opslaan in een session (of cookie)? En kun je zien of een $var al een object van een class is?
Hmm, di's even een brainstorm.. Stukkie nalezen.. is_object, get_class.. Controle-manier.. Of zijn er simpelere manieren?

[drm]

Janoz:
OO ligt eigenlijk veel dichter bij hoe mensen denken. Mensen die OO lastiger vinden dan imperatief denken meestal net wat te moeilijk . Eigenlijk is het heel simpel.
(...)

Inderdaad. Veel meer valt er niet over te zeggen. Tijd voor concrete vragen

elviver>
Het is voor een Session bijvoorbeeld heel handig om een session-object aan te maken, welke bijhoudt welke variabelen geregistreerd worden, en op wat voor manier dit moet gebeuren. Je zou dan in de methode "register" ofzo een check in kunnen bouwen of de variabele een "speciale behandeling nodig heeft". Zo kun je een object bijvoorbeeld eerst "serializen" (zie ook http://www.php.net/serialize) voordat je 'm registreert.

[Verwijderd]

Op vrijdag 22 februari 2002 09:29 schreef ACM het volgende:

[..]

Ohhhh
Ik kan wel winnen van de computer hoor Maar dat zal komen omdat ik het algoritme heb bedacht (ow en omdat er een of andere supervage bug in zit waardoor ie een extreem stomme zet kan maken...)

[..]

ik wil heel graag dat spel ook en de source eventueel

[Glimi]

Op zondag 24 februari 2002 01:38 schreef elviver het volgende:
Eeij baz.. Ik zat te gister bedenken in me icons-projectje een class users te maken bijvoorbeeld.. Daarin de functies inloggen, registreren, wijzigen.. Lekker overzichtelijk..

Stel ik wil dat users kunnen registreren, inloggen en hun pass kunnen wijzigen. Lijkt me redelijk duidelijk: class user, function register, login & changepass. Maarrrr...
Die gegevens moeten uit een database komen. Wat doe je dan? Doe je dan telkens een nieuwe link oproepen met de MySQL-server? Hoe pak je zoiets aan dan? Nieuwe class voor de link? Class link ofzo?

Jupz, dat lijkt me een goede oplossing. Een user is een user en een connectie is een connectie. Een user is geen user+connectie

Ik snap classes wel, maar hoe je dat dan eventueel doet met MySQL-links?

[edit]Relees dit topic nogmaals.. Er wordt gesproken over een aparte class.. Maar levert dat niet erg veel extra overhead op? Telkens als je een nieuwe class maakt of een functie daaruit opvraagt die iets uit de DB nodig heeft een nieuwe link maken? Da's wel erg veel overhead of niet? Of maak je eerst een class met de link, $link = new db; en daarna $link->query en link->close bijv.. Dat zou kunnen werken..

In een goede OO taal kun je dan of een object van de klasse connectie opnemen in je user class, of een object van de klasse connectie meegeven bij het maken van een user object.
Bij de laatste methode kun je dus dezelfde connectie voor elk user object gebruiken die je maakt.
Ik weet dus niet hoe dit zit bij PHP

Goed.. compleet ander vraagje.. $user = new user; $user->load_level, $user->changepass.. Kun je die hele $user opslaan in een session (of cookie)? En kun je zien of een $var al een object van een class is?
Hmm, di's even een brainstorm.. Stukkie nalezen.. is_object, get_class.. Controle-manier.. Of zijn er simpelere manieren?[/edit]

Uhm worden objecten niet opgeslagen zodat je ze overal kan gebruiken? Of moet je ze in de sessie kwakken? Ik weet in ieder geval dat ze makkelijk 'mee te nemen' zijn.

Maar die controle kan makkelijker (maar ook een stuk minder betrouwbaar). Je kan bijv. elke klasse die je maakt een toString() methode geven, die bijv de classname teruggeeft. Maar wat is er moeilijk aan get_class?