Soap (hardnekkig)probleempje
beste,
Ik zit met een klein probleempje.
Als ik een soap-fault terug krijg. word mijn pagina niet meer getoond maar ter download aangeboden ( download idex.php .. ). Dit klinkt als een headers probleem, maar headers zijn gewoon goed...
Gekke is dat als ik gewoon soap-data terug krijg. Er niets aan de hand is.
Structuur van web-applicatie ziet er ongeveer als volgt uit:
index.php -> called : content.php -> called: module.php
uiteindlijk word $content geprint in index.php, en data wordt dus vanuit de includes steeds returned.
Ik zit met een klein probleempje.
Als ik een soap-fault terug krijg. word mijn pagina niet meer getoond maar ter download aangeboden ( download idex.php .. ). Dit klinkt als een headers probleem, maar headers zijn gewoon goed...
Gekke is dat als ik gewoon soap-data terug krijg. Er niets aan de hand is.
Structuur van web-applicatie ziet er ongeveer als volgt uit:
index.php -> called : content.php -> called: module.php
uiteindlijk word $content geprint in index.php, en data wordt dus vanuit de includes steeds returned.
Oke ik ben alweer een stappie verder, echter word het nu nog waziger....
Ik werk met templates.
De returning content word als volgd in de template gezet:
$tpl->set ( 'content', include_once ( $scriptpath . 'bla.php' ) );
print $tpl->getPage ();
bovenstaand bied de pagina ter download aan....
Echter doe ik :
$content = include_once ( $scriptpath . 'bla.php' ) );
$tpl->set ( 'content', $content );
print $tpl->getPage ();
gaat het goed.
Zover ik weet zijn bovenstaande voorbeeldjes qua werking echt exact hetzelfde, desondanks gaat php er toch anders mee om ....
Ik werk met templates.
De returning content word als volgd in de template gezet:
$tpl->set ( 'content', include_once ( $scriptpath . 'bla.php' ) );
print $tpl->getPage ();
bovenstaand bied de pagina ter download aan....
Echter doe ik :
$content = include_once ( $scriptpath . 'bla.php' ) );
$tpl->set ( 'content', $content );
print $tpl->getPage ();
gaat het goed.
Zover ik weet zijn bovenstaande voorbeeldjes qua werking echt exact hetzelfde, desondanks gaat php er toch anders mee om ....
include & require zijn statements, geen functies. Ze geven dan ook geen waarden terug. $content bevat dus ook zeker niet de inhoud van bla.php.
Middels ob_start() en ob_get_clean() kan je wel een pagina die je 'include' opslaan in de output buffer en vervolgens de output buffer in een string dumpen. Dan zit het resultaat van bla.php wel in een string, zoals jij het nu probeert.
Middels ob_start() en ob_get_clean() kan je wel een pagina die je 'include' opslaan in de output buffer en vervolgens de output buffer in een string dumpen. Dan zit het resultaat van bla.php wel in een string, zoals jij het nu probeert.
Als je de waarde in je included bestand returned.. komt dat wel degelijk terug in bv. $content;
hmm, maf, nooit geweten dat dat serieus werkte.
Probeer het eens met een extra paar () om include. Het blijft geen functie, dus misschien liggen de prioriteiten van uitvoeren wat anders dan je zou verwachten.
Probeer het eens met een extra paar () om include. Het blijft geen functie, dus misschien liggen de prioriteiten van uitvoeren wat anders dan je zou verwachten.
Code (php)
1
2
3
4
2
3
4
<?php
$tpl->set ( 'content', (include_once $scriptpath . 'bla.php') );
print $tpl->getPage ();
?>
$tpl->set ( 'content', (include_once $scriptpath . 'bla.php') );
print $tpl->getPage ();
?>
@Sebas
Ik zou ook verwachten dat bij de stukjes code dezelfde output zou moeten verschijnen. Raar dat de PHP Parser er zo mee om gaat... Als het niet kan zoals het moet dan moet het zoals het kan.. 'k zou dan dus maar gewoon die tweede methode blijven gebruiken.. maar het blijft inderdaad erg raar!
@Jelmer
include() en require() kunnen data terug geven als in het geinclude bestand een RETURN wordt gegeven.
Als er geen return wordt gegeven in het geïnclude bestand, wordt de waarde 1 (true) terug gegeven.
OB functies (output buffering) dient in mijn ogen alleen als maskeren van slecht geprogrammeerde software.. en is dus ook niet echt een oplossing.
Ik zou ook verwachten dat bij de stukjes code dezelfde output zou moeten verschijnen. Raar dat de PHP Parser er zo mee om gaat... Als het niet kan zoals het moet dan moet het zoals het kan.. 'k zou dan dus maar gewoon die tweede methode blijven gebruiken.. maar het blijft inderdaad erg raar!
@Jelmer
include() en require() kunnen data terug geven als in het geinclude bestand een RETURN wordt gegeven.
Als er geen return wordt gegeven in het geïnclude bestand, wordt de waarde 1 (true) terug gegeven.
OB functies (output buffering) dient in mijn ogen alleen als maskeren van slecht geprogrammeerde software.. en is dus ook niet echt een oplossing.
I know... maar doe het al jaren op dezelfde manier :) En nu in 1x door weird soap server / client ding werkt het niet :)
2e probleem is dat apache config vermoed ik ook moeilijk zit te doen :)
En we hebben er ook ondertussen weer leuke error bij.
Leek mij begin van de week verstandig de applicatie maar eens soap-based te gaan maken. Maar begin er ondertussen bijna spijt van te krijgen :)
2e probleem is dat apache config vermoed ik ook moeilijk zit te doen :)
En we hebben er ook ondertussen weer leuke error bij.
Leek mij begin van de week verstandig de applicatie maar eens soap-based te gaan maken. Maar begin er ondertussen bijna spijt van te krijgen :)
Nah zo in eens draait het weer... ik moet jullie enkel verschuldigd blijven wat het was.. dat eerste probleem is nog steeds niet verholpen helaas. Blijft vreemd gebeuren dit nog nooit meegemaakt...




