PHP singleton op meerdere pagina's?

[RookieRooster]

In plaats van $_SESSION variabelen wil ik een class gebruiken om variabelen te delen op meerdere pagina's. Na wat zoekwerk op inet leek het singletonpattern de oplossing, maar..

PHP:

 
<?php // singleton.php
class singleton{

    private static $instance;

    private function __construct(){ 
        echo "new instance of singleton created<br />"; 
    }

    public static function getInstance(){
        if(!self::$instance){
            self::$instance = new singleton();
        }
        return self::$instance;
    }
}
?>

<?php // one.php
include_once('singleton.php');
$singleton = singleton::getInstance();

echo '<a href="two.php">two</a>';
?>

<?php // two.php
include_once('singleton.php');
$singleton = singleton::getInstance();
?>

Bij openen one.php en doorklikken naar two.php wordt er op beide pagina's een nieuwe instantie aangemaakt van singleton. Is het niet mogelijk deze constructie te gebruiken om binnen een class 'sessie' variabelen op te slaan en te gebruiken op verschillende pagina's?

[Frenck]

Wat je wilt kan wel.. moet je je object instance serialized opslaan in een sessie variabele.

En uit de sessie halen en deserializen als je hem weer opnieuw gebruikt.

[BtM909]

Waar hoort mijn topic?

oftwel: PHP -> Programming

[krvabo]

RookieRooster schreef op dinsdag 05 mei 2009 @ 20:20:
Is het niet mogelijk deze constructie te gebruiken om binnen een class 'sessie' variabelen op te slaan en te gebruiken op verschillende pagina's?

Welkom bij het grote pluspunt en minpunt van php.
Kort: Nee, maarrrrrr:
Langer: je kunt wel de waarden van een variabele / instantie meegeven:

Frenck schreef op dinsdag 05 mei 2009 @ 20:33:
Wat je wilt kan wel.. moet je je object instance serialized opslaan in een sessie variabele.

Even ingaand op het pluspunt;
Na het verwerken van een pagina geeft php alle resources weer vrij, wat dus erg handig is voor kleine applicatietjes.
Als nadeel heb je natuurlijk dat je niet over verschillende aanroepen dezelfde gegevens kunt behouden. Voor een groter project is jsp of asp veel beter geschikt omdat het dan juist WEL al die instanties over meerdere aanroepen kan vasthouden. Het vermindert de load enorm. Daarom zie je ook wel tussenlagen (zoals hier op t.net) met java die als een soort memory-cacher werkt.

[ Voor 30% gewijzigd door krvabo op 05-05-2009 20:43 ]

[Eddy Dean]

Je hoeft het niet eens te serializen en deserializen. Het volgende werkt ook:

PHP:

session_start();

class singleton{ 
    private function __construct(){  
        echo "new instance of singleton created<br />";  
    } 

    public static function getInstance(){ 
        if(!isset($_SESSION['singleton'])){ 
            $_SESSION['singleton'] = new singleton(); 
        } 
        return $_SESSION['singleton']; 
    }
}

$s = singleton::getInstance();

[Frenck]

Owja tuurlijk EddyDean! Stom

Doet PHP het wel voor je

[Verwijderd]

Wat wel tricky is in het geval van PHP is het gebruiken van een singleton in je sessie voor I/O resources. Omdat iedere page request een apart proces (?) is, zullen je handles naar bijv. een file of een databaseverbinding niet meer geldig zijn. Kan nare bugs opleveren die lastig te traceren zijn.

[RookieRooster]

Thnx voor de antwoorden zover, begrijp dus dat ik hoe dan ook gebruik moet maken van de $_SESSION optie(of 'global' variabelen moet gebruiken)

Jammer, dacht na het lezen van diverse topics op internet dat een singleton ervoor kon zorgen dat er maximaal één instance van een object werd aangemaakt ongeacht waar of hoe je die aanroept.

"Ensure a class has only one instance and provide a global point of access to it"
(http://www.developertutor...pattern-050729/page1.html)

"The Singleton Pattern is one of the GoF (Gang of Four) Patterns. This particular pattern provides a method for limiting the number of instances of an object to just one"
(http://www.talkphp.com/ad...leton-design-pattern.html)

"The singleton pattern is a design pattern that is used to restrict instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system"
(http://rkutti.wordpress.com/2008/01/29/php-singleton-object/)

Ga eens kijken of de optie van Eddy Dean in mijn geval werkt.

[ Voor 47% gewijzigd door RookieRooster op 06-05-2009 00:04 ]

[Patriot]

Waarom wil je geen gebruik maken van sessies? Denk je dat er iets mis mee is, want dat is niet zo hoor. Je zou zelf iets kunnen maken, maar het zal altijd een vergelijkbaar systeem zijn.

[mocean]

krvabo schreef op dinsdag 05 mei 2009 @ 20:41:
[...]
Voor een groter project is jsp of asp veel beter geschikt omdat het dan juist WEL al die instanties over meerdere aanroepen kan vasthouden. Het vermindert de load enorm. Daarom zie je ook wel tussenlagen (zoals hier op t.net) met java die als een soort memory-cacher werkt.

Dat vind ik wel weer erg kort door de bocht. In PHP (eventueel met een framework) kan je dat prima realiseren. PHP laat wel domme applicaties toe die veel load veroorzaken, maar dat kan in elke programmeertaal bij slecht gebruik. Dat jsp of asp om deze redenen geschikter is kan je niet zomaar stellen.

offtopic:
Wat voor tussenlaag wordt er volgens jou in Java gebruikt op Tweakers.net?

[H004]

mocean schreef op woensdag 06 mei 2009 @ 00:31:

offtopic:
Wat voor tussenlaag wordt er volgens jou in Java gebruikt op Tweakers.net?

offtopic:
plan: Tweakers.net introduceert snellere Pricewatch-engine

[Alain]

RookieRooster schreef op dinsdag 05 mei 2009 @ 23:55:
Jammer, dacht na het lezen van diverse topics op internet dat een singleton ervoor kon zorgen dat er maximaal één instance van een object werd aangemaakt ongeacht waar of hoe je die aanroept.

Singleton is de naam voor een klasse die slechts 1 keer aangemaakt kan worden. Singleton is niet een magisch woord dat er voor zorgt dat de klasse niet meer dan eens aangemaakt kan worden.

Als je binnen een applicatie een singleton gebruikt en je start de applicatie 10 keer op heb je 10 instanties van een singleton. De processen weten niks van elkaar.

[krvabo]

mocean schreef op woensdag 06 mei 2009 @ 00:31:
[...]

Dat vind ik wel weer erg kort door de bocht. In PHP (eventueel met een framework) kan je dat prima realiseren. PHP laat wel domme applicaties toe die veel load veroorzaken, maar dat kan in elke programmeertaal bij slecht gebruik. Dat jsp of asp om deze redenen geschikter is kan je niet zomaar stellen.

Het blijft simpel:
Ja, je kunt veel met php, maar inherent is het een taal die -niet- geschikt is voor het behouden van informatie over meerdere requests. Sessions zijn erg aardig, maar het blijft een omweg.
In jsp heb je een application scope. Zo kun je dus -wel- precies wat de TS wil (zijnde dat hij denkt dat het een magische oplossing voor alle problemen is).
JSP laat ook veel moeilijker domme code toe omdat het gewoon stricter is. Maargoed, deze discussie is al veel vaker gedaan op GoT. Begrijp me niet verkeerd, ik gebruik ook altijd php, maar dit is een tekortkoming die gewoon als een paal boven water staat.

Om nog even terug te komen op het singleton pattern, het is een goed pattern wat erg nuttig is mits je het correct gebruikt. Het is vooral handig als je 'globaal' een object wil aanspreken. Zo ben je er zeker van dat je altijd hetzelfde object aanspreekt.
Zou je echter zoiets doen met php dan loop je, omdat je geen application scope hebt, steeds nieuwe objecten te spawnen, waardoor je alsnog (op dat niveau) niets aan de objecten meer hebt.

[mithras]

AlainS schreef op woensdag 06 mei 2009 @ 00:55:
[...]


Singleton is de naam voor een klasse die slechts 1 keer aangemaakt kan worden. Singleton is niet een magisch woord dat er voor zorgt dat de klasse niet meer dan eens aangemaakt kan worden.

Als je binnen een applicatie een singleton gebruikt en je start de applicatie 10 keer op heb je 10 instanties van een singleton. De processen weten niks van elkaar.

Afaik is het singleton een pattern om binnen application runtime slechts een instantie van een object te verzekeren. Dat daarbij applicatie runtime === request runtime bij php, dus inherent aan het principe dat je objecten (singletons of niet) toch wel weggegooid worden.

Verder zou ik niet je global sessie gebruiken in je singleton, maar erbuiten. Je legt je daarmee allerlei restricties op die later echt niet handig kunnen zijn. Je kan altijd een init script maken wat alle objecten serialiseerd en in sessie variabelen stopt.

krvabo schreef op woensdag 06 mei 2009 @ 06:27:
[...]

Om nog even terug te komen op het singleton pattern, het is een goed pattern wat erg nuttig is mits je het correct gebruikt. Het is vooral handig als je 'globaal' een object wil aanspreken. Zo ben je er zeker van dat je altijd hetzelfde object aanspreekt.
Zou je echter zoiets doen met php dan loop je, omdat je geen application scope hebt, steeds nieuwe objecten te spawnen, waardoor je alsnog (op dat niveau) niets aan de objecten meer hebt.

Er is heus wel een application scope hoor Daarnaast zijn er ook altijd nog mogelijkheden als caching in heel veel verschillende vormen die ook het constructen van singletons kan verminderen (zeker als je in memcached gaat zitten oid).

[AtleX]

krvabo schreef op woensdag 06 mei 2009 @ 06:27:
JSP laat ook veel moeilijker domme code toe omdat het gewoon stricter is

En hoe beschermd een striktere taal (ik denk dat je op strong typing doelt?) je tegen 'domme' code? In Java kan ik net zo goed m'n performance om zeep helpen door bijvoorbeeld 1 miljoen queries in een loop uit te voeren. Of bedoel je met domme code slecht geschreven code? In één van mijn applicaties zit een methode van 500 regels, da's zo ongeveer de belangrijkste methode van die applicatie. Waarom ik die niet refactor? Omdat daar 2 jaar aan bugfixes inzitten. Ik weet dat het nu werkt, als ik het refactor/rewrite hoop ik dat het werkt. Ik geef meteen toe dat de code een zooitje is en wat rare dingen doet, maar het werkt wel. Is het dan slecht geschreven code? Leg eens uit wat domme code is en hoe een strictere taal (leg ook eens uit?) minder 'domme' code toelaat?

...
omdat je geen application scope hebt
...

Die heb je op zich wel, alleen wordt de scope na elke request gedestroyed.

[ Voor 6% gewijzigd door AtleX op 06-05-2009 09:14 ]

[Frenck]

Beetje jammere discussie aan het worden. Denk dat de persoon inmiddels wel antwoord heeft op zijn vraag en een discussie over welke taal dom en slim is een beetje buiten de scope van dit topic valt...

Beetje sneu ook... iedereen heeft zijn voorkeuren punt klaar.

[Janoz]

mithras schreef op woensdag 06 mei 2009 @ 09:03:
Er is heus wel een application scope hoor

Oh? Laat maar eens even zien dan! Voor zover ik weet heeft php niet eens een volwaardige session scope, laat staan een application scope.

[Frenck]

ff deze topic uit mijn lijst halen... dit soort discussies zijn nutteloos... als iedereen even zijn gelijkt probeerd te halen?! Alvast bedankt...

Nee PHP heeftgeen applicatie scope. Of PHP een volwaardige sessie scope heeft... is afhankelijk wat je daar onder verstaat (leuk discussie misschien voor zometeen?).

[mithras]

Janoz schreef op woensdag 06 mei 2009 @ 09:21:
[...]

Oh? Laat maar eens even zien dan! Voor zover ik weet heeft php niet eens een volwaardige session scope, laat staan een application scope.

Mm, ik heb altijd begrepen dat bij php request scope identiek is aan application scope. Het kan dan zo zijn dat die application scope niet gelijk is aan app scopes zoals andere talen kennen, maar als app scope = request scope, concludeer ik dat die dus wel bestaat .

Goed, mijn punt wat ik eigenlijk wilde maken is dat het niet handig is om die sessie direct in de singleton te stoppen, voor zowel performance als reusability.

[Grijze Vos]

Niks belet je natuurlijk om een kleine apache plugin te schrijven die application scope voor je regelt; of om het te emuleren middels een database, als dat eerste te moeilijk is. Ik heb al een tijd niet meer met PHP gewerkt, maar zou verwachten dat een van de grotere frameworks dat ondertussen wel heeft ingebakken.

[Janoz]

Frenck schreef op woensdag 06 mei 2009 @ 09:15:
Beetje sneu ook... iedereen heeft zijn voorkeuren punt klaar.

Daar gaat het helemaal niet om. Waar het om gaat is dat je je bewust bent van de beperkingen van hetgeen je gekozen hebt. Uiteraard is het niet terecht om zomaar dingen als slim of dom te gaan bestempelen, maar om alles maar onder 'persoonlijke voorkeuren' te schuiven is niet correct.

In dat opzicht kan ik me helemaal vinden in wat krvabo zegt. Het enkel hebben van request scope is niet slecht, maar anders. Het geeft php veel voordelen (Het beheren van een php server is een stuk simpeler waardoor het makkelijk te hosten is), maar je moet je wel bewust zijn van de beperkingen.

Frenck schreef op woensdag 06 mei 2009 @ 09:23:
ff deze topic uit mijn lijst halen... dit soort discussies zijn nutteloos... als iedereen even zijn gelijkt probeerd te halen?! Alvast bedankt...

Dit begrijp ik niet helemaal.. Wat is precies het probleem?

Nee PHP heeftgeen applicatie scope. Of PHP een volwaardige sessie scope heeft... is afhankelijk wat je daar onder verstaat (leuk discussie misschien voor zometeen?).

Waarom een discussie voor zometeen? Hij kan toch ook gewoon nu gevoerd worden. Mocht het teveel offtopic raken dan splitsen we de discussie wel af. Binnen de context van Programming is het een ontopic discussie dus ik zie geen reden om hem af te kappen.

[Janoz]

mithras schreef op woensdag 06 mei 2009 @ 09:39:
Mm, ik heb altijd begrepen dat bij php request scope identiek is aan application scope. Het kan dan zo zijn dat die application scope niet gelijk is aan app scopes zoals andere talen kennen, maar als app scope = request scope, concludeer ik dat die dus wel bestaat .

Lijkt me niet handig om de defenitie van een term iets ruimer te interpreteren om er vervolgens aan te voldoen. Het komt op mij iets over als 'Zolang mijn applicatie maar 1 keer opstart heb je geen raceproblemen'. Application scope is een scope waarin je variabelen opslaat die gelijktijdig door alle bezoekers van je site beschikbaar en wijzigbaar zijn. Daarnaast is een wijziging van deze gegevens direct doorgevoerd bij alle andere bezoekers. Dat is waar men het over heeft wanneer men het over application scope heeft. Dat is waar sommige oplossingen gebruik van maken.

[Mr_Light]

Goh en ik altijd maar denken dat deze beperkingen gevolgen iets te maken hebben met de manier hoe php word uitgevoerd. En dat het dus 'ligt' aan de runtime en niet aan de taal zelf. Nu is het gebruikelijk om de runtime environment en de taal op een hoop te gooien daarom zijn discussies hierover altijd zo... 'vrolijk'.

Gebruikelijk is dat de execution van een stukje php requests based is. Waarbij persistence van objecten tussen requests opgelost word door externe resources (disk, db.. elke andere vorm van gedeelde opslag dat bereikbaar is)

Nu doe ik weinig met PHP maar volgens mij zijn er wel runtime's die het ondersteunen volgens mij gaat php draaiend op een jvm binnen een servlet container prima de mogelijk geven om een applicatie scope te hebben.

Volgens mij interperteerd hij de definitie niet ruimer hoor - alleen is het niet echt zinnig om te gebruiken. En dus optimaliseren wij hem weg in onze gedachte

hmm alhoewel, jouw definitie wijkt wel een beetje af van de mijne - ik dacht altijd dat de applicatie scope, die scope is welke geldig is voor de lengte dat de applicatie leeft/geldig is. Deze werkt trouwens ook prima in non-webapplicaties. De applicatie scope van de servlet container is bij dan ook anders dan die van een servlet applicatie. Die van de container is altijd groter als die van de 'webapplicatie'.

Context, perspectief.. etc blabla.

[mithras]

Janoz schreef op woensdag 06 mei 2009 @ 10:11:
[...]

Lijkt me niet handig om de defenitie van een term iets ruimer te interpreteren om er vervolgens aan te voldoen. Het komt op mij iets over als 'Zolang mijn applicatie maar 1 keer opstart heb je geen raceproblemen'. Application scope is een scope waarin je variabelen opslaat die gelijktijdig door alle bezoekers van je site beschikbaar en wijzigbaar zijn. Daarnaast is een wijziging van deze gegevens direct doorgevoerd bij alle andere bezoekers. Dat is waar men het over heeft wanneer men het over application scope heeft. Dat is waar sommige oplossingen gebruik van maken.

Als je het zo bekijkt kan () je wel gelijk hebben. Ik heb eerder een definitie van Mr_Light in mijn hoofd

quote: http://gathering.tweakers...message/31903246#31903246

de application scope is die welke geldig is voor de lengte dat de applicatie leeft/geldig is

Wat betekent dat (door de opzet van php) de application scope inherent is aan de request scope. Maar daarmee nog niet verdwenen is!

Mr_Light schreef op woensdag 06 mei 2009 @ 11:34:
Volgens mij interperteerd hij de definitie niet ruimer hoor - alleen is het niet echt zinnig om te gebruiken. En dus optimaliseren wij hem weg in onze gedachte

Dat is waarschijnlijk de crux van de misvatting hier.

[Janoz]

Mr_Light schreef op woensdag 06 mei 2009 @ 11:34:
Goh en ik altijd maar denken dat deze beperkingen gevolgen iets te maken hebben met de manier hoe php word uitgevoerd. En dat het dus 'ligt' aan de runtime en niet aan de taal zelf. Nu is het gebruikelijk om de runtime environment en de taal op een hoop te gooien daarom zijn discussies hierover altijd zo... 'vrolijk'.

Gebruikelijk is dat de execution van een stukje php requests based is. Waarbij persistence van objecten tussen requests opgelost word door externe resources (disk, db.. elke andere vorm van gedeelde opslag dat bereikbaar is)

Nu doe ik weinig met PHP maar volgens mij zijn er wel runtime's die het ondersteunen volgens mij gaat php draaiend op een jvm binnen een servlet container prima de mogelijk geven om een applicatie scope te hebben.

Waar het hier over php gaat, gaat het over het 'php platfom'. Dat de taal ook als dsl in een jvm of in .NET te vinden is is wat anders.

Volgens mij interperteerd hij de definitie niet ruimer hoor - alleen is het niet echt zinnig om te gebruiken. En dus optimaliseren wij hem weg in onze gedachte

hmm alhoewel, jouw definitie wijkt wel een beetje af van de mijne - ik dacht altijd dat de applicatie scope, die scope is welke geldig is voor de lengte dat de applicatie leeft/geldig is. Deze werkt trouwens ook prima in non-webapplicaties. De applicatie scope van de servlet container is bij dan ook anders dan die van een servlet applicatie. Die van de container is altijd groter als die van de 'webapplicatie'.

Context, perspectief.. etc blabla.

Het enige verschil is wat je als applicatie definieerd. Zie je een enkel request als volledige applicatie? Of zie je joomla (bv) als applicatie? Mij lijkt de tweede voor de hand liggender.

[krvabo]

Mr_Light schreef op woensdag 06 mei 2009 @ 11:34:
hmm alhoewel, jouw definitie wijkt wel een beetje af van de mijne - ik dacht altijd dat de applicatie scope, die scope is welke geldig is voor de lengte dat de applicatie leeft/geldig is. Deze werkt trouwens ook prima in non-webapplicaties. De applicatie scope van de servlet container is bij dan ook anders dan die van een servlet applicatie. Die van de container is altijd groter als die van de 'webapplicatie'.

Ik kan het niet echt uit je tekst halen, maar je bedoelt dat servlets vanuit een 'gesharede root' werken? If so: inderdaad. Php dus niet aangezien voor elke request een nieuwe thread wordt gespawned.

Als je jouw definitie overneemt voor application scope krijg je dit:
Application scope = lengte dat de applicatie leeft
Session scope = lengte dat de user 'requests doet'
Request scope = lengte dat het script draait.

Aangezien php alles vrijgeeft na het verwerken van een script is de Request Scope gelijk aan jouw definitie van application scope (daarna wordt ie afgeschoten) en NIET session scope.
(Oh btw, php zelf wordt niet gestopt als de request klaar is, alleen de thread ervan iirc )

AtleX schreef op woensdag 06 mei 2009 @ 09:12:
[...]

En hoe beschermd een striktere taal (ik denk dat je op strong typing doelt?) je tegen 'domme' code? [..]
Of bedoel je met domme code slecht geschreven code?
[..]
Leg eens uit wat domme code is en hoe een strictere taal (leg ook eens uit?) minder 'domme' code toelaat?

Tja domme code.. er is zoveel. Vooral in vorige versies had je natuurlijk dingen als superglobals enzo, maar ik bedoelde meer dat een java/c#-programmeur veel meer zal nadenken over de code die hij gaat schrijven dan bij php. Ik merk het bij mezelf ook, als ik in php werk dan werk ik veel minder doordacht en maak ik wel een klasse als het me uitkomt..En dan niet te vergeten dat Goto in php komt
Afgezien van de incomplete OO in php en de irritante syntax..
Maargoed, dit gaat dan weer wel offtopic

Kijk, met memcached of een tussenlaag kun je in php ook een application scope bereiken (of althans, je emuleert het), maar dat blijft dus om de flaw heenwerken. Als je dit perse wilt, dan kun je overwegen om naar een taal te gaan die het WEL native ondersteunt.
Er zijn bijvoorbeeld heel wat klassen die ik singleton op application niveau zou willen maken op mijn sites. Niet bij allemaal zou het even nuttig zijn, maar het zou resources schelen en dan zouden mijn klassen beter doordacht in elkaar zitten. (Of althans, ik zou er meer hebben)
OO zonder een fatsoenlijke session scope of application scope ondersteuning is.. mwa.. onhandig? Elk request weer worden de objecten opnieuw gemaakt (ja, ook als je het in de $_SESSION gooit) waardoor je gewoon veel overhead hebt. Dat is ook de hoofdreden dat ik onder php nogsteeds geen volwaardig OO gebruik. Bij veel code in php is OO onzin en wordt het gebruikt als namespace.
Note: ik zeg veel, niet allemaal of het merendeel

[AtleX]

krvabo schreef op woensdag 06 mei 2009 @ 14:50:
maar ik bedoelde meer dat een java/c#-programmeur veel meer zal nadenken over de code die hij gaat schrijven dan bij php

Ja, maar dat ligt aan het hogere kennisniveau van de ontwikkelaar. Een goede programmeur denkt ook na voordat hij in PHP gaat zitten codekloppen. Ik denk niet dat dat een resultaat is van de taal die meer of minder strikt is maar meer van de kennis, ervaring, en liefde voor het vak van de programmeur.

[StM]

Grijze Vos schreef op woensdag 06 mei 2009 @ 09:44:
Niks belet je natuurlijk om een kleine apache plugin te schrijven die application scope voor je regelt; of om het te emuleren middels een database, als dat eerste te moeilijk is. Ik heb al een tijd niet meer met PHP gewerkt, maar zou verwachten dat een van de grotere frameworks dat ondertussen wel heeft ingebakken.

Je hebt tegenwoordig ZendServer. Die heeft een cachepool die gedeeld is tussen alle requests. Enkel IO connectie's gaan verloren vziw. Daarnaast had je al memcached.

[Janoz]

Ik weet niet hoe de cachepool werkt, maar memcache heeft dezelfde 'beperkingen' als php sessies. Je kunt er niet rechtstreeks bij. Je zult altijd een kopie maken naar request scope. Met memcache is het dus nog steeds niet mogelijk om een singleton oplossing te gebruiken waarbij gegarandeerd wordt dat er maar maximaal 1 object voorkomt.

[Grijze Vos]

krvabo schreef op woensdag 06 mei 2009 @ 14:50:
[...]

Sorry hoor, maar volgens mij mis jij een stuk van het verhaal. OO bestond al voordat concepten als application/session/request scope in de webapplications wereld opkwamen. Sterker nog, OO is een taal paradigma, die verschillende scopes zijn dat niet. Het doel van OO is overigens ook niet het maken van softawre die efficient geheugen gebruikt, het doel is om de complexiteit van software te beteugelen door het overzichtelijk te houden.

Verder vergelijk je de taal php met volledige platforms, dat is natuurlijk ook geen zinnige vergelijking. Geen enkele taal ondersteund 'native' application scopes, want het is geen taalconcept. Zoals ik al eerder aangaf kun je prima zelf je (apache/)php platform uitbreiden met application scope ondersteuning, wellicht heeft iemand dat al voor je gedaan. Het verschil met .NET/J2EE is dan dat het daar al voor je gedaan is. Dat staat verder los van C#/VB.Net/Java.

[ Voor 9% gewijzigd door Grijze Vos op 07-05-2009 12:09 ]

[.oisyn]

Grijze Vos schreef op donderdag 07 mei 2009 @ 11:29:
Geen enkele taal ondersteund 'native' application scopes, want het is [geen] taalconcept.

Ik neem aan dat je dat bedoelde? (waarbij "het" refereert naar application scopes)

[ Voor 9% gewijzigd door .oisyn op 07-05-2009 11:36 ]

[StM]

Janoz schreef op donderdag 07 mei 2009 @ 09:56:
Ik weet niet hoe de cachepool werkt, maar memcache heeft dezelfde 'beperkingen' als php sessies. Je kunt er niet rechtstreeks bij. Je zult altijd een kopie maken naar request scope. Met memcache is het dus nog steeds niet mogelijk om een singleton oplossing te gebruiken waarbij gegarandeerd wordt dat er maar maximaal 1 object voorkomt.

Klopt. Je hebt niet de garantie. Voordeel is wel dat dit clusterwise werkt. Ik weet niet of je bij ASP ook je application scope over je cluster kan verspreiden, of dat iedere node zn eigen versie van de singleton heeft, echter zal je dan net als in PHP die garantie verliezen. Je kan dat eventueel voorkomen door een bootstrap script die de objecten laad, voor je nodes connectie's accepteren.

PHP vereist nu eenmaal dat je net wat meer zelf doet. Wil je dat niet zijn er redelijk wat frameworks die je heel wat ellende uit handen halen, zoals het Zend Framework.

[Grijze Vos]

.oisyn schreef op donderdag 07 mei 2009 @ 11:35:
[...]

Ik neem aan dat je dat bedoelde? (waarbij "het" refereert naar application scopes)

inderdaad, typo fixed.

PHP vereist nu eenmaal dat je net wat meer zelf doet. Wil je dat niet zijn er redelijk wat frameworks die je heel wat ellende uit handen halen, zoals het Zend Framework.

Dit is met Java en bijv. C# niet anders. Het enige verschil is dat Sun en Microsoft al een framework voor je hebben neergezet, wat je desgewenst ook prima kan negeren hoor. (Zelf gebruiken wij hier bijv. de hele database ondersteuning van .NET niet, in plaats daarvan genereren we DAL's met een commerciale ORM tool.)

[ Voor 53% gewijzigd door Grijze Vos op 07-05-2009 12:12 ]

[Mr_Light]

Janoz schreef op woensdag 06 mei 2009 @ 14:42:
Het enige verschil is wat je als applicatie definieerd. Zie je een enkel request als volledige applicatie? Of zie je joomla (bv) als applicatie? Mij lijkt de tweede voor de hand liggender.

Dat hangt van de persoon af en waar hij mee bezig is.

Zie je een enkel request als volledige applicatie?

Afhankelijk van wat er uitgevoerd word - ja. De applicatie scope is net zo hard verbonden met de runtime. Als de session scope is met een user(uitgaande van een http-sessie, van die hebben we ook nog mooie andere varianten).

Voor dat we gaan lopen touwtrekken - hoe het labeltje geplakt word maar me niet uit. (ok het is af en toe een leuke bezigheid) Het gaat er omdat je weet wat de ander er mee bedoeld en wat er effectief kan. Uiteindelijk is dus de implementatie zo als gebruikt leidend en hoe lang die de gegevens beschikbaar stelt, uiteindelijk is het een service die het platform/runtime je bied.(en of je nu dus bij php stelt dat er geen is of dat het even lang als het request is -> dus nutteloos, effectief is het resultaat het zelfde).

Btw als je joombla pakt en het daarom afschrijft weet ik niet of java onder die zelfde mindset wel een applicatie scope heeft - er zijn volgens mij ook wel applicaties die ook doormiddel van samenwerkende java processes/jvm werken. (mischien is dat ook wel de reden dat je dacht ik alleen servletcontext tegen komt in de spec.)

krvabo schreef op woensdag 06 mei 2009 @ 14:50:
Ik kan het niet echt uit je tekst halen, maar je bedoelt dat servlets vanuit een 'gesharede root' werken? If so: inderdaad. Php dus niet aangezien voor elke request een nieuwe thread wordt gespawned.

Ik weet niet wat jouw notie van 'geshare root' is. kan ik lastig beantwoorden - makkelijkste mannier is even de servlet specificatie door te lezen, nu snap ik dat niet iedereen dit ziet zitten.. kan je je vraag ook anders stellen?

ik volg niet helemaal wat er nu 'inderdaad' is, mischien dat ik er overheen blijf lezen. Als dat over de applicatie scope gaat - dat was de notie van Janoz. (who was poking phun at Mithras). En ik gaf daar bijval bij.

[ Voor 21% gewijzigd door Mr_Light op 08-05-2009 04:10 ]

[krvabo]

Grijze Vos schreef op donderdag 07 mei 2009 @ 11:29:
[...]
Sorry hoor, maar volgens mij mis jij een stuk van het verhaal. OO bestond al voordat concepten als application/session/request scope in de webapplications wereld opkwamen. Sterker nog, OO is een taal paradigma, die verschillende scopes zijn dat niet. Het doel van OO is overigens ook niet het maken van softawre die efficient geheugen gebruikt, het doel is om de complexiteit van software te beteugelen door het overzichtelijk te houden.

Wellicht had ik het anders kunnen formuleren, maar om dan op zo'n ondertoon te beginnen..
Ik bedoelde:
Het gebruikmaken van objecten (een kenmerk van OO) die over meerdere requests gebruikt kunnen worden is onhandig in PHP omdat je geen application scope hebt en je een grote overhead krijgt door steeds de gegevens opnieuw te moeten verwerken, MITS je geen gebruik maakt van omwegen zoals memcached. Jezus wat een zin.
Uiteraard kun je OO gebruiken om de complexiteit van je applicaties te verminderen, het is een van de grootste, zo niet de grootste, voordelen van OO. Echter, de handigheid van OO zit voor mij ook in het feit dat objecten een langere levensduur hebben en dat je deze steeds opnieuw kunt opvragen zonder bijvoorbeeld opnieuw een zware query op de database uit te moeten voeren.
Ik zeg nergens dat je geen OO fatsoenlijk kunt gebruiken zonder application scope, ik zeg dat ik het onhandig vind. En daar blijf ik ook gewoon bij.

Verder vergelijk je de taal php met volledige platforms, dat is natuurlijk ook geen zinnige vergelijking.

Voor mij wel. Beiden talen/platforms/oplossingen of hoe je het ook wilt noemen zijn er om een doel te bereiken: dynamische pagina's. Aan de ene kant kan ik php installeren, en aan de andere kant tomcat. Wat zou mij het uitmaken dat het ene een platform is/levert en de ander een taal? In essentie maakt het vrij weinig uit voor de vergelijking. Dan maken ze van php maar een volledig platform.

Geen enkele taal ondersteund 'native' application scopes, want het is geen taalconcept.

Granted, maar ik vind dit een beetje nitpicking

Zoals ik al eerder aangaf kun je prima zelf je (apache/)php platform

Oh nou ga je er wel een platform van maken, enkel door het toevoegen van een externe applicatie? Dan is php +95% van de tijd onderdeel van een platform daar het merendeels gebruikt wordt in samenwerking met apache (en een database)

uitbreiden met application scope ondersteuning, wellicht heeft iemand dat al voor je gedaan. Het verschil met .NET/J2EE is dan dat het daar al voor je gedaan is. Dat staat verder los van C#/VB.Net/Java.

Dan doen ze dat toch lekker voor php ook? Bundel het samen en bied het als download aan, mits ik het allemaal vanuit php kan aanspreken, zonder externe calls te moeten gaan doen.

Mr_Light schreef op vrijdag 08 mei 2009 @ 02:59:
[...]


[...]

Ik weet niet wat jouw notie van 'geshare root' is. kan ik lastig beantwoorden - makkelijkste mannier is even de servlet specificatie door te lezen, nu snap ik dat niet iedereen dit ziet zitten.. kan je je vraag ook anders stellen?

ik volg niet helemaal wat er nu 'inderdaad' is, mischien dat ik er overheen blijf lezen. Als dat over de applicatie scope gaat - dat was de notie van Janoz. (who was poking phun at Mithras). En ik gaf daar bijval bij.

Ik ging even in op je gedachte (beetje raar woord zo) dat de application scope ging over de lengte dat de applicatie leefde. Zo kun je het uiteraard ook opvatten, daar php gewoon wordt afgesloten als de opgevraagde pagina klaar is. Ik denk dat ik hier wat onduidelijk (of wellicht fout) was. Dingen als Coldfusion, jsp en asp (iirc) hebben dan weer wel een gezamenlijke 'applicatie' of root, waaruit dingen voortkomen. Ik dacht dat je dat ook bedoelde met je servlet container.

[.oisyn]

krvabo schreef op vrijdag 08 mei 2009 @ 04:09:
Oh nou ga je er wel een platform van maken, enkel door het toevoegen van een externe applicatie?

Waar deze discussie volgens mij de mist in gaat is dat jij lijkt te denken dat taal en platform mutual exclusive zijn, maar je hebt natuurlijk de taal PHP en het platform PHP. Het woordje "PHP" impliceert niet een van de twee. Maar een statement als "PHP heeft geen application scope" impliceert natuurlijk wel PHP als platform, omdat een taal in die zin geen plaats heeft. En sowieso gaat het natuurlijk in 95% van de gevallen (en ook in deze topic) om PHP als platform.