[PHP] values van andere frames

[koekiemonster]

Beste,

Van huis uit ben ik een domino ontwikkelaar, maar ik ben nu al enige tijd bezig met PHP.
Uiteraard met een CMS om het wiel wederom uit te vinden.
Nu heb ik een table met settings. Deze settings haal ik op (éénmalig, daar ik het topframe niet ververs) en plaats ik als hidden velden in mijn topframe van onderstaande frameset:

code:

<frameset rows="90,*" cols="*" frameborder="0" border="0" framespacing="0">
  <frame src="./cms_top.php" name="topFrame" scrolling="no" noresize>
  <frameset cols="180,*" frameborder="no" border="0" framespacing="0">
    <frame src="./cms_menu.php" name="leftFrame" scrolling="no" noresize>
    <frame src="./cms_start.php?map=notes&mode=read" name="mainFrame">
  </frameset>
</frameset>
<noframes>

Om deze velden op te halen kan ik gebruik maken van javascript, maar dat is frontend.
Dit kan bijvoorbeeld door:

code:

var number = parent.frames[0].document.forms[0].c_view.value;

Welke de waarde van het veld c_view ophaalt.

Nu wil ik eigenlijk met deze vars aan de gang met PHP (functies aanroepen etc). Ik haal dus frontend en server-side door elkaar...
Is er een oplossing, of doe ik het helemaal verkeerd?
Is het mogelijk om met PHP veldwaardes op te halen uit een andere frame en hiermee verder te gaan?

[NMe]

PHP kent geen andere frames, dus de enige manier om dingen door te geven is door, eventueel met Javascript, een nieuw request te sturen. Zoek eens op wat AJAX voor je kan betekenen.

[TeeDee]

Met XML_HTTP, of beter gezegd het hele hot 'n' new buzz word: AJAX.

[rrrandy]

Je haalt inderdaad de server- en clientside door elkaar.

Wanneer je met variabelen verder wilt op de server zul je de pagina (hier dus frame) met de variabelen moeten submitten. Het frame waarin je de variabelen / resultaat na berekening oid getoond wilt hebben zal ook ververst moeten worden.

Wat je kunt doen is je hele frameset submitten en dan de hele zooi opnieuw renderen op basis van die variabelen. Wanneer je variabelen in de sessie bewaard of in een object waar beide PHP files bij kunnen moet dit geen probleem zijn.

Zelf werk ik al heel lang niet meer met PHP en mijn kennis over de taal an sich is dan ook behoorlijk verwaterd en ik kan je zo 1-2-3 geen codevoorbeeld geven.

[koekiemonster]

Tja, ik wil eigenlijk geen nieuwe request, ik wil gewoonweg de gegevens uit het topframe halen en deze gebruiken in het gehele cms. DIt scheelt enorm qua load....

Iemand een ander idee, daar Ajax in prncipe dus gewoon elke keer weer een request is.

[rrrandy]

koekiemonster schreef op dinsdag 07 november 2006 @ 14:05:
Tja, ik wil eigenlijk geen nieuwe request, ik wil gewoonweg de gegevens uit het topframe halen en deze gebruiken in het gehele cms. DIt scheelt enorm qua load....

Iemand een ander idee, daar Ajax in prncipe dus gewoon elke keer weer een request is.

Dan zul je er toch niet aan ontkomen om met javascript aan de slag te gaan.

[TeeDee]

Ik gok erop dat het volgende voor jou van belang is?

code:

<frame src="./cms_start.php?map=notes&mode=read" name="mainFrame">

En dan voornamelijk 'map' en 'mode'?

Dan kan je die toch op cms_start in een Session oid gooien om er vervolgens mee verder te werken?

[deviltje]

Je kan de gegevens in je topframe bewaren en dan in de onload van je content frame een aantal hidden fields dmv javascript vullen met de gegevens uit het topframe.

deze hidden fields zullen mee gepost worden als je je formulier post.. en hoef je alleen je content frame opnieuw op te bouwen.

[Evilbee]

Als je dus een frame hebt met je settings, kan je dat frame submitten als je daar iets wijzigen. Dan heb je de waardes in PHP en kan je ze toevoegen aan je sessie. En dan kunnen je andere PHP scripts er ook bij.
Dus zo:

PHP:

session_start();
$_SESSION['settings'] = $_POST;

En dan het ophalen:

PHP:

session_start();
$value = $_SESSION['key'];

[koekiemonster]

deviltje schreef op dinsdag 07 november 2006 @ 14:08:
Je kan de gegevens in je topframe bewaren en dan in de onload van je content frame een aantal hidden fields dmv javascript vullen met de gegevens uit het topframe.

deze hidden fields zullen mee gepost worden als je je formulier post.. en hoef je alleen je content frame opnieuw op te bouwen.

ja, maar dan haal je weer js en php door elkaar. php is dan immers al afgehandeld.

[rrrandy]

koekiemonster schreef op dinsdag 07 november 2006 @ 14:16:
[...]

ja, maar dan haal je weer js en php door elkaar. php is dan immers al afgehandeld.

De oplossing die hij aandraagt heeft niets met php te maken hoor. Hij schetst een oplossing waarin je alleen je content-frame hoeft te verversen. De variabelen die je via javascript bij het inladen van het nieuwe contentframe uit het andere frame haalt gebeurt allemaal clientside. Het andere frame heb je dus niet hoeven submitten en de inhoud van de variabelen die daar staan zijn nooit naar de server geweest tijdens het verversen van je content.

[Cartman!]

Misschien een stomme vraag, maar waarom wil je perse frames gebruiken?

[koekiemonster]

Cartman! schreef op dinsdag 07 november 2006 @ 14:33:
Misschien een stomme vraag, maar waarom wil je perse frames gebruiken?

omdat ik een cms ontwikkel, welke niet geindexeerd hoeft te worden door een zoekmachine.
Ik kan dus genieten van alle voordelen van frames en heb geen enkel nadeel.
1 keer menu inladen, 1 keer topframe, rest xhtml content....
snel, makkelijk onderhoudbaar en duidelijk. Ik zie geen enkel nadeel.... tenzij dit niet oplosbaar is

Ben nu inderdaad wat gaan doen met sessie variabelen.
Echter als ik het topframe: session.start() doe en dan
$_SESSION['c_view'] = $connector->show_safe($settings->c_view);

Als ik deze echo'ed in het topframe krijg ik netjes 15, zoals ik verwacht en wil.
Echo ik deze waarde echter in een ander frame dan krijg ik niets terug....(echo $_SESSION['c_view'];)

[TeeDee]

En als je dat frame een refresh geeft staat '15' er ook niet?

[Evilbee]

koekiemonster schreef op dinsdag 07 november 2006 @ 14:42:
[...]

omdat ik een cms ontwikkel, welke niet geindexeerd hoeft te worden door een zoekmachine.
Ik kan dus genieten van alle voordelen van frames en heb geen enkel nadeel.
1 keer menu inladen, 1 keer topframe, rest xhtml content....
snel, makkelijk onderhoudbaar en duidelijk. Ik zie geen enkel nadeel.... tenzij dit niet oplosbaar is

Ben nu inderdaad wat gaan doen met sessie variabelen.
Echter als ik het topframe: session.start() doe en dan
$_SESSION['c_view'] = $connector->show_safe($settings->c_view);

Als ik deze echo'ed in het topframe krijg ik netjes 15, zoals ik verwacht en wil.
Echo ik deze waarde echter in een ander frame dan krijg ik niets terug....(echo $_SESSION['c_view'];)

Wanneer wordt dat andere frame geladen? Dit moet namelijk na het topframe geladen worden.
En wordt de session wel gestart in het andere frame?

[koekiemonster]

Evilbee schreef op dinsdag 07 november 2006 @ 14:46:
[...]


Wanneer wordt dat andere frame geladen? Dit moet namelijk na het topframe geladen worden.
En wordt de session wel gestart in het andere frame?

Holy shit.. je moet gewoon weer een session_start() doen als je een php-file included in een andere waar session_start al heeft plaatsgevonden...
wow.

In ieder geval ik heb nu 15, waar ik heel blij mee ben.
Een sessie oplossing dus.

Kleine vraag nog: Hoeveel sessie vars mag je in totaal hebben?

[TeeDee]

koekiemonster schreef op dinsdag 07 november 2006 @ 14:58:
[...]

Holy shit.. je moet gewoon weer een session_start() doen als je een php-file included in een andere waar session_start al heeft plaatsgevonden...
wow.

Hmm, ik ben absoluut geen held met PHP, maar dat wordt imo in elke PHP Session tutorial aangehaald.

Kleine vraag nog: Hoeveel sessie vars mag je in totaal hebben?

Ik gok erop dat dat er meer zijn dan dat jij nodig hebt. En het is ook redelijk afhankelijk van de config van je webserver.

Je kan natuurlijk ook een test bouwen. Loop van 1 tot laten we zeggen 20000 en gooi deze stuk voor stuk in een session.

[Cartman!]

koekiemonster schreef op dinsdag 07 november 2006 @ 14:42:
[...]

omdat ik een cms ontwikkel, welke niet geindexeerd hoeft te worden door een zoekmachine.
Ik kan dus genieten van alle voordelen van frames en heb geen enkel nadeel.
1 keer menu inladen, 1 keer topframe, rest xhtml content....
snel, makkelijk onderhoudbaar en duidelijk. Ik zie geen enkel nadeel.... tenzij dit niet oplosbaar is

Dan nog. Ik vind dat er aan frames geen enkel voordeel zit persoonlijk, zeker niet als je nu allemaal methodes moet gebruiken om de ene var in het andere frame te krijgen. Serieus, volgens mij zit je het jezelf onnodig moeilijk te maken. En waarom is iets met frames makkelijker onderhoudbaar? Denk er nog eens overna anders...?

[Evilbee]

koekiemonster schreef op dinsdag 07 november 2006 @ 14:58:
[...]

Holy shit.. je moet gewoon weer een session_start() doen als je een php-file included in een andere waar session_start al heeft plaatsgevonden...
wow.

In ieder geval ik heb nu 15, waar ik heel blij mee ben.
Een sessie oplossing dus.

Kleine vraag nog: Hoeveel sessie vars mag je in totaal hebben?

Als je slim bent, include je in ieder bestand een configuratie bestand waar je die session_start in zet. Daar kan je dan ook eventuele database connecties inzetten.

[koekiemonster]

Evilbee schreef op dinsdag 07 november 2006 @ 15:16:
[...]

Als je slim bent, include je in ieder bestand een configuratie bestand waar je die session_start in zet. Daar kan je dan ook eventuele database connecties inzetten.

Dat heb ik dus (op elke pagina een include die toegang controleert, sessies zet of breekt en erugstuurt naar loginscherm indien sessies over zijn), maar toch moest er weer een session_start van tepas komen...

pagina
<?php
include(''start.php'); <-- hier alle sessies en session_start();
include('connector.php'); <-- db verwerkingen;
include('header.php'); <-- opbouw start pagina
include('overview.php') <-- overzichtspagina en hier MOEST ik dus een nieuwe session_start doen, wat ik vreemd vind.
include('footer'); <-- afsluiting page
?>

het werkt nu en ik ben redelijk gelukkig met de session oplossing.

[Cartman!]

Als je in die pagina ook ook je meteen menu include dan was je direct klaar geweest...

[koekiemonster]

Cartman! schreef op dinsdag 07 november 2006 @ 15:49:
Als je in die pagina ook ook je meteen menu include dan was je direct klaar geweest...

guess what nu blijft de state van het menu direct behouden, anders moet ik weer scripts uitvoeren. Niets is sneller dan frames op dat gebied.

[Cartman!]

koekiemonster schreef op dinsdag 07 november 2006 @ 15:51:
[...]

guess what nu blijft de state van het menu direct behouden, anders moet ik weer scripts uitvoeren. Niets is sneller dan frames op dat gebied.

Heb je zo'n slome server of client dan? Daar heb ik echt nog nooit problemen mee gehad.

Als je gewoon een simpele functie maakt met een switch erin die het menu voor je bouwt, wel of niet selected class van je item dan is t al gefixt.

Maar als je eigenwijs 'lekker' met frames wilt rommelen be my guest, ik wil je alleen maar helpen.

[Evilbee]

koekiemonster schreef op dinsdag 07 november 2006 @ 15:33:
[...]

Dat heb ik dus (op elke pagina een include die toegang controleert, sessies zet of breekt en erugstuurt naar loginscherm indien sessies over zijn), maar toch moest er weer een session_start van tepas komen...

pagina
<?php
include(''start.php'); <-- hier alle sessies en session_start();
include('connector.php'); <-- db verwerkingen;
include('header.php'); <-- opbouw start pagina
include('overview.php') <-- overzichtspagina en hier MOEST ik dus een nieuwe session_start doen, wat ik vreemd vind.
include('footer'); <-- afsluiting page
?>

het werkt nu en ik ben redelijk gelukkig met de session oplossing.

In overview.php hoeft in principe geen session_start. Als ie eenmaal is gestart, dan is dat voldoende. Werken je sessies überhaupt wel?

[koekiemonster]

Cartman! schreef op dinsdag 07 november 2006 @ 16:15:
[...]

Heb je zo'n slome server of client dan? Daar heb ik echt nog nooit problemen mee gehad.

Als je gewoon een simpele functie maakt met een switch erin die het menu voor je bouwt, wel of niet selected class van je item dan is t al gefixt.

Maar als je eigenwijs 'lekker' met frames wilt rommelen be my guest, ik wil je alleen maar helpen.

het is niet eigenwijs, maar per definitie denken dat een div-oplossing altijd de beste is, hoeft niet.
Het kan anders en het werkt prima zo.

Mijn server is niet sloom, maar die van een klant mogelijk wel.

In overview.php hoeft in principe geen session_start. Als ie eenmaal is gestart, dan is dat voldoende. Werken je sessies überhaupt wel?

Tja, ik begin daar nu ook aan te twijfelen

EDIT: ach.. na een harde refresh bleek dat session_start inderdaad niet nodig is.. vond het al zo bijzonder

Allemaal bedankt!

[ Voor 7% gewijzigd door koekiemonster op 07-11-2006 21:32 ]