[PHP] OOP Vraagje

[Verwijderd]

Hallo iedereen,

Ik zit met een vreemd probleempje... Ik ontwikkel een PHP-applicatie, maar ben nog niet zo ervaren in PHP (C++/Java achtergrond)

Ik wil de volgende code uitvoeren:


Pagina 1 ::

PHP:

<?php
require 'DomeinController.php';
session_start();
$domeinController = new DomeinController();
$_SESSION['domeinController'] = serialize($domeinController);
?>

Pagina 2 ::

PHP:

<?php
require 'DomeinController.php';
session_start();
$domeinController = unserialize($_SESSION['domeinController']);
$domeinController->getVar();
session_destroy();
?>

Maar als ik dit doe krijg ik volgende foutmelding

code:

Fatal error: Call to a member function getVar() on a non-object

Kunnen jullie me helpen?

Dank bij voorbaat !!!

[Kwastie]

Waarom zou je überhaupt een controller in de sessie willen zetten?

Voor een goede serialize moet je (dacht ik) __sleep en __wakeup method implementeren (zie http://php.net/manual/en/language.oop5.magic.php)

[ Voor 56% gewijzigd door Kwastie op 23-08-2010 22:36 ]

[Verwijderd]

De naam controller is wat slecht gekozen... Maar ik heb het object doorheen de sessie nodig... (Voor een multipage formulier)

[dev10]

Verwijderd schreef op maandag 23 augustus 2010 @ 22:32:
De naam controller is wat slecht gekozen... Maar ik heb het object doorheen de sessie nodig... (Voor een multipage formulier)

Is het dan niet handiger om een id op te slaan in de $_SESSION array en op een bepaalde manier gegevens op te slaan en dat terug te halen met die waarde in je $_SESSION?

[Verwijderd]

Hmmm, zou een oplossing kunnen zijn... Maar ik zoek echter een mogelijkheid om een object te gebruiken over heel men applicatie... Bovenstaande is het resultaat van wat opzoekingswerk, zit volgens mij compleet logisch in elkaar maar blijkt dus niet te werken

[ReenL]

PHP:

<?php
// Page 1:
require 'path/to/domeinController';
$var = new DomeinController();
$_SESSION['domeinController'] = $var;

// Page 2:
require 'path/to/domeinController';
$var = $_SESSION['domeinController'];
?>

(un)serialize doet je session handler automatisch

Het werkt waarschijnlijk alleen niet omdat de DomainController class op page 2 nog niet beschikbaar is.

Wat geeft print_r($_SESSION) op page 2?

[ Voor 5% gewijzigd door ReenL op 23-08-2010 23:06 . Reden: niet goed gelezen ]

[Cartman!]

Verwijderd schreef op maandag 23 augustus 2010 @ 22:38:
Hmmm, zou een oplossing kunnen zijn... Maar ik zoek echter een mogelijkheid om een object te gebruiken over heel men applicatie...

Dat klinkt wel als het denken in Java/C++

Ik zou toch eerder je aanraden om te programmeren met het idee dat je app stateless is. Je moet nu nog rekening houden dat sommige users geen cookies hebben en dan moeten je sessies via je url verlopen etc. wat weer de nodige problemen opzichzelf kan opleveren.

[NMe]

Cartman! schreef op dinsdag 24 augustus 2010 @ 10:57:
[...]

Dat klinkt wel als het denken in Java/C++

Ik zou toch eerder je aanraden om te programmeren met het idee dat je app stateless is. Je moet nu nog rekening houden dat sommige users geen cookies hebben en dan moeten je sessies via je url verlopen etc. wat weer de nodige problemen opzichzelf kan opleveren.

Wat dan precies? Als je geen cookies gebruikt gaat PHP uit zichzelf over op een PHPSESSID meegeven in de url en zorgt het op basis daarvan dat netjes je session-array gevuld wordt. Sowieso is het niet zo heel erg gek om je objecten te serializen in een sessie hoor.

Ik denk zelf dat het in de session_destroy en/of dubbel aangeroepen session_start zit, als ik deze code zo zie. Ik zet session_start doorgaans maar op een enkele plek in mijn code, namelijk in een include die op elke pagina wordt gebruikt.

[creator1988]

Ja, bovendien is je platform veel beter in sessies dan jij, en dat is wat je gewoon aan het doen bent als je zelf op basis van je Session_ID zaken in de database opslaat.

[ Voor 48% gewijzigd door creator1988 op 24-08-2010 11:48 ]

[Cartman!]

Dan heb je ineens weer meer rekening te houden met session hijacking/fixation en niks is sowieso gezegd dat hij HTML gebruikt als frontend, misschien is de frontend wel flash en dan kun je niet ineens terugvallen op je session id via een url, die is er immers niet.

In principe werk ik altijd zonder state, ook omdat ik steeds meer werk met schaalbaarheid en dan fokt je request ineens op omdat een user op een andere node zit omdat de ander te druk is en dan kan ie je sessie niet meer vinden bijv. Zulk soort fratsen

Ja, bovendien is je platform veel beter in sessies dan jij.

Voor leken misschien ja.

[ Voor 9% gewijzigd door Cartman! op 24-08-2010 11:48 ]

[creator1988]

Cartman! schreef op dinsdag 24 augustus 2010 @ 11:47:
Voor leken misschien ja.

Argh! Nee, er zitten bij de makers van PHP, bij Microsoft, bij Sun, mensen die veel slimmer zijn dan jij. Écht waar.

[Cartman!]

Dus jij denkt dat de grote sites een ingebouwd halfbakken systeem gebruiken? Ieder geval is PHP z'n sessiemanagement knap waardeloos, voor .NET wil ik niet spreken want dat ken ik niet. Ons eigen GoT/T.net gebruikt een eigen systeem daarvoor.

[creator1988]

Cartman! schreef op dinsdag 24 augustus 2010 @ 12:00:
Dus jij denkt dat de grote sites een ingebouwd halfbakken systeem gebruiken?

We hebben het hier niet over grote websites.
Sowieso gaan sessions en grote websites niet zomaar samen, en het hangt zeer sterk af van de eisen die je aan je session management stelt of je uberhaupt sessions gebruikt.

Verder vind ik het knap als je een compleet stateless webwinkel kan bouwen zonder cookies of session id's in je url.

[LuCarD]

Cartman! schreef op dinsdag 24 augustus 2010 @ 12:00:
Dus jij denkt dat de grote sites een ingebouwd halfbakken systeem gebruiken? Ieder geval is PHP z'n sessiemanagement knap waardeloos, voor .NET wil ik niet spreken want dat ken ik niet. Ons eigen GoT/T.net gebruikt een eigen systeem daarvoor.

Wat is er zo mis met de sessiemanagement van PHP?

Het is toch redelijk goed te aan te passen aan je eigen wensen. Welk systeem gebruikt GOT dan? Ik ging er vanuit dat ze gebruik maakte van de sessiemanagement van PHP, ze hebben alleen een custom id generator, custom save handler en een custom sessionname. ( hier ben ik eigenlijk blind vanuit gegaan, dus het kan compleet fout zijn )

[Cartman!]

creator1988 schreef op dinsdag 24 augustus 2010 @ 12:13:
[...]
We hebben het hier niet over grote websites.
Sowieso gaan sessions en grote websites niet zomaar samen, en het hangt zeer sterk af van de eisen die je aan je session management stelt of je uberhaupt sessions gebruikt.

Precies, ik geef aan dat voor wat ik bouw ik vrijwel nooit iets heb aan PHP's eigen session handler. Ook vanwege schaling.

Verder vind ik het knap als je een compleet stateless webwinkel kan bouwen zonder cookies of session id's in je url.

Dat is ook vrij lastig ja. Het kan wel maar dat kost inderdaad meer tijd.

LuCarD schreef op dinsdag 24 augustus 2010 @ 12:22:
[...]
Wat is er zo mis met de sessiemanagement van PHP?

Het is niet flexibel, per server zijn settings verschillend (waaronder de timeouts) en je kunt ze bijv. niet aan een IP hangen.

Het is toch redelijk goed te aan te passen aan je eigen wensen. Welk systeem gebruikt GOT dan? Ik ging er vanuit dat ze gebruik maakte van de sessiemanagement van PHP, ze hebben alleen een custom id generator, custom save handler en een custom sessionname. ( hier ben ik eigenlijk blind vanuit gegaan, dus het kan compleet fout zijn )

Dat is behoorlijk kort door de bocht bekeken dan. Ik heb een soortgelijk systeem gemaakt als GoT en ik heb de session_start() van PHP er ieder geval niet voor nodig.

edit: als er interesse is mag iemand hier misschien los een topic over openen. Ik denk dat mijn opmerking naar de TS een beetje afdwaalt van het topic nu...

[ Voor 5% gewijzigd door Cartman! op 24-08-2010 13:07 ]

[Verwijderd]

creator1988 schreef op dinsdag 24 augustus 2010 @ 11:54:
[...]


Argh! Nee, er zitten bij de makers van PHP {...} mensen die veel slimmer zijn dan jij. Écht waar.

Het spreekt voor zich inderdaad. Achter PHP zit een idee, er is planning bij betrokken geweest. Het heeft een zen waar je van kan zeggen, ja, hierover is nagedacht. Het is zeker geen procedurele scripting taal waar halverwege een brakke OO implementatie bij is toegevoegd. Wat een developers, wereldklasse zeg ik je.

Ja, niet dus.

[Voutloos]

Blijkbaar gaat de unserialize() fout, en blijkbaar heb je je error_reporting niet (voldoende) aantaan tijdens het devven. Ontwikkel aub met error_reporting(-1) en display_errors aan en je zal de notice van unserialize() zien.

offtopic:
En de standaard php sessies zijn verre van perfect. Als leek moet je het niet ff beter doen, maar voor grotere projecten heb je al gauw je eigen sessies nodig. Bijv. ivm meerdere frontends, uitloggen van alle sessie van 1 gebruiker, meer controle over het opruimen etc etc

[ Voor 38% gewijzigd door Voutloos op 24-08-2010 13:34 ]

[Grijze Vos]

Cartman! schreef op dinsdag 24 augustus 2010 @ 12:00:
Dus jij denkt dat de grote sites een ingebouwd halfbakken systeem gebruiken? Ieder geval is PHP z'n sessiemanagement knap waardeloos, voor .NET wil ik niet spreken want dat ken ik niet. Ons eigen GoT/T.net gebruikt een eigen systeem daarvoor.

Bij .NET kun je redelijk eenvoudig het sessiemanagement omleiden een SQL Server DB in oid.

[creator1988]

Grijze Vos schreef op dinsdag 24 augustus 2010 @ 14:18:
[...]

Bij .NET kun je redelijk eenvoudig het sessiemanagement omleiden een SQL Server DB in oid.

Dat is een van de ingebakken session providers, je kunt echter ook je eigen session provider bakken en pluggen, waarbij enkel het saven / ophalen, etc. overridden hoeft te worden; en volgens mij kan dat ook in php.

[Verwijderd]

Cartman! schreef op dinsdag 24 augustus 2010 @ 10:57:
[...]

Dat klinkt wel als het denken in Java/C++

Ik zou toch eerder je aanraden om te programmeren met het idee dat je app stateless is.

...

En hoe begin ik daar aan... Heb eigenlijk weinig/geen ervaring met webscript talen...

Het probleem is dat ik het object over mijn hele app wil gebruiken... Want het bevat alle data uit het formulier.

[Cartman!]

Opslaan in je db en dan alleen het id (+random bijhorende token) binnen je pagina laten sturen bijv. of opslaan als cookie. Zo kun je met het id/token je record weer terugvinden serverside en de data uitlezen/updaten etc.

[Voutloos]

Eigenlijk is het onthouden van enkel de data dan voldoende. En dat zou op zich ook via hidden inputs kunnen.

Maar goed, volg aub eerst mijn tip mbt error reporting want je veegt nu minstens 1 error onder het tapijt.

[ Voor 3% gewijzigd door Voutloos op 24-08-2010 19:09 ]

[Verwijderd]

Cartman! schreef op dinsdag 24 augustus 2010 @ 19:07:
Opslaan in je db en dan alleen het id (+random bijhorende token) binnen je pagina laten sturen bijv. of opslaan als cookie. Zo kun je met het id/token je record weer terugvinden serverside en de data uitlezen/updaten etc.

Als dan het formulier maar voor de helft ingevuld word en de gebruiker breekt de procedure na pagina 1 af zit ik met gegevens die niet meer consistent zijn


En als PHP als taal het niet aankan om een globale variabele te hebben die echt werkt, is het maar een klotetaal om OO in te programmeren

[ Voor 12% gewijzigd door Verwijderd op 24-08-2010 19:13 ]

[NMe]

Verwijderd schreef op dinsdag 24 augustus 2010 @ 19:12:
[...]

En als PHP als taal het niet aankan om een globale variabele te hebben die echt werkt, is het maar een klotetaal om OO in te programmeren

Met die opmerking laat je merken dat je niet weet wat het verschil is tussen PHP (een scriptingtaal gebouwd op een framework) en iets als ASP.NET (een compleet framework). PHP is er niet op gebouwd om complete websites als "application" te zien, dus logischerwijs kun je ook niet objecten "onthouden". Vandaar ook de opmerking dat het een stateless app moet zijn. De eenvoudige oplossing daarvoor is de magic methods __sleep en __wakeup implementeren en dan inderdaad serialize en unserialize gebruiken om de objecten in de database, in sessies, in cookies of waar dan ook op te slaan. Dat maakt PHP niet direct een "klotetaal", dat maakt jouw denkwijze anders dan die van de makers van PHP.

[hellfighter87]

OO is juist helemaal niet globaal ?

en als de helft maar ingevuld is controleer je toch ff of alle data ingevuld is. zodra je dan het eerste formulier weer tegen komt van die user zet je de al ingevulde data weer terug. probleem opgelost .

als je ook een timestamp nijhoudt zou je eventueele oude incomplete data ook nog uit je database verwijderen.

zoals hierboven al gezecht is. pak een id sla die op in een cookie en je db en hang daarachter de data in je db.

[.oisyn]

Maar die denkwijze van de makers maakt het dan weer wel een klotetaal

Heeft Zend niet vergelijkbare frameworks?

[Voutloos]

Hier kan je wel implementaties voor vinden, en er zijn eerder teveel frameworks voor PHP.

Maar (laatste poging): je moet gewoon kunnen debuggen wat nu fout gaat. Zelfs al zou je het uiteindelijk anders op willen lossen, deze debug en session kennis kan nooit kwaad.

[NMe]

.oisyn schreef op dinsdag 24 augustus 2010 @ 19:35:
Heeft Zend niet vergelijkbare frameworks?

Volgens mij niet in het detail dat je in .NET hebt waarbij een application-object beschikbaar is in al je code, maar dat kan ik mis hebben. Ik zit niet zo in de frameworks, ik gebruik mijn eigen framework voor hobbyprojectjes en op kantoor hebben we ook een eigen framework.

[roy-t]

creator1988 schreef op dinsdag 24 augustus 2010 @ 11:54:
[...]


Argh! Nee, er zitten bij de makers van PHP, bij Microsoft, bij Sun, mensen die veel slimmer zijn dan jij. Écht waar.

offtopic:
Normaal zou ik je gelijk geven, maar bij de makers van PHP begin ik af en toe te twijfelen!

[FragFrog]

NMe schreef op dinsdag 24 augustus 2010 @ 19:24:
De eenvoudige oplossing daarvoor is de magic methods __sleep en __wakeup implementeren en dan inderdaad serialize en unserialize gebruiken om de objecten in de database, in sessies, in cookies of waar dan ook op te slaan.

Sterker nog, dit is normaliter niet eens nodig - je kan prima een object in een sessie gooien, ook zonder te serializen of magic methods te implementeren _{tenminste, net even getest met 5.2.6 hier en dat werkt prima, zowel met als zonder handmatig extra te serializen.}

Dat het niet werkt ligt dan ook met aan zekerheid grenzende waarschijnlijkheid niet aan PHP, althans, niet direct. Probeer eens een simpel datatype op te slaan in je sessie en controleer of dat werkt. Als dat wel goed gaat kun je met var_dump vrij eenvoudig zien wat er dan precies met je object gebeurt

[ Voor 3% gewijzigd door FragFrog op 24-08-2010 20:50 ]

[Cartman!]

Als je zo graag een application scope wilt hebben dan ga je t toch in Java maken? PHP heeft dat niet en opzich hoeft dat helemaal niet erg te zijn. Door dan meteen de hele taal af te schrijven vind ik eerder een gebrek van jezelf dan.

Incomplete data kan overigens ook interessant zijn, je weet dan toch nog wat gegevens ondanks dat iemand je proces niet heeft afgemaakt, je kunt tevens nog terugzien op welk punt de meeste mensen afhaken.

verder heeft stateless imo niks met OO te maken...

[ Voor 5% gewijzigd door Cartman! op 24-08-2010 21:32 ]

[Verwijderd]

FragFrog schreef op dinsdag 24 augustus 2010 @ 20:48:
[...]

Sterker nog, dit is normaliter niet eens nodig - je kan prima een object in een sessie gooien, ook zonder te serializen of magic methods te implementeren _{tenminste, net even getest met 5.2.6 hier en dat werkt prima, zowel met als zonder handmatig extra te serializen.}

Dat het niet werkt ligt dan ook met aan zekerheid grenzende waarschijnlijkheid niet aan PHP, althans, niet direct. Probeer eens een simpel datatype op te slaan in je sessie en controleer of dat werkt. Als dat wel goed gaat kun je met var_dump vrij eenvoudig zien wat er dan precies met je object gebeurt

Eventjes alles gecheckt... Webserver opnieuw opgestart, bleek naar alle waarschijnlijkheid daar aan te liggen

[Grijze Vos]

Je zou prima een application scope kunnen bakken in PHP, moet je wel een apache plugin schrijven. Zal vast wel iemand al gedaan hebben ooit.

[.oisyn]

Met alle memory-leaks van dien.

[YopY]

NMe schreef op dinsdag 24 augustus 2010 @ 19:57:
[...]

Volgens mij niet in het detail dat je in .NET hebt waarbij een application-object beschikbaar is in al je code, maar dat kan ik mis hebben.

Ze hebben (als ik het me goed herinner) een soort van Service Locator, een object die je door kunt geven aan je controllers waar je gedeelde zooi in kunt zetten. Die wordt geinitialiseerd in je bootstrap (zeg maar de 'startup code' die bij elk request uitgevoerd wordt).

Natuurlijk wil je zoiets eigenlijk niet in PHP - je wilt per request precies kunnen bepalen welke services je nodig hebt, zodat je niks overbodigs initialiseert. Misschien dat je service objecten kunt persisteren dmv Memcache of iets dergelijks, mits ze geen aparte request state hebben (= variabelen die per gebruiker anders kunnen zijn).

Als je zo graag een application scope wilt hebben dan ga je t toch in Java maken? PHP heeft dat niet en opzich hoeft dat helemaal niet erg te zijn. Door dan meteen de hele taal af te schrijven vind ik eerder een gebrek van jezelf dan.

Eigenljik moet je, als je een webapplicatie wilt schrijven, eerst je requirements opschrijven en aan de hand daarvan een framework zoeken (en dat framework is geschreven in een bepaalde taal). Als het een groot project is kun je er beter wat onderzoek aan vooraf laten gaan. Veel mensen (mijzelf incluis) kiezen voor taal / framework X omdat ze er ervaring mee hebben, ook al hoeft het niet beslist de beste keuze te zijn.

[ Voor 5% gewijzigd door YopY op 25-08-2010 09:31 ]

[Verwijderd]

Cartman! schreef op dinsdag 24 augustus 2010 @ 11:47:
misschien is de frontend wel flash en dan kun je niet ineens terugvallen op je session id via een url, die is er immers niet.

http://www.asual.com/swfaddress/