[PHP] PRG pattern en statusberichten

[Matis]

Beste PRGers,

Ik ben momenteel bezig met een stukje inhouse tooling in PHP. Wat deze software moet doen is vrij eenvoudig. De gebruiker uploadt een binary (u-boot file in Blackfin Loader format) en ik zet die binary om in een statisch array dat dan weer in een c-applicatie embed kan worden.

Ik heb hiervoor momenteel een PRG-template geïmplementeerd:

• Post: Upload het bestand naar de server.
• Redirect: Converteer de LDR naar een C- en H-bestand en genereer statusmeldingen.
• Get: Presenteer de statusmeldingen en de downloadlink naar de C- en H-bestanden.

Ik kan geen nette manier vinden om statusmeldingen door te kunnen geven aan het Get-gedeelte van dit tooltje.
In eerste instantie dacht in aan een SESSION-variabele, maar toen ik op zoek ging naar programmeervoorbeelden, kreeg ik al snel de indruk dat dat niet de manier was om berichten door te geven.

Wat voor methodes gebruiken jullie hiervoor?
Let wel, ik wil het gebruik van databases zien te voorkomen

Alvast bedankt
Matis

[MikeN]

Je zal het toch ergens op moeten slaan. Dat is dus of in de sessie (maar dan heb je sowieso niet zoveel aan je PRG verhaal gezien die get dan niet te herhalen is), of in en database (met een id of iets dergelijks in de URL), of gewoon in een textfile (misschien handig, gezien je toch ook al C en H files genereert).

[iH8]

Misschien kun je iets met Wildfire. Daarmee kun je custom headers genereren en daarin je meldingen meegeven.

[Soultaker]

De vraag is of je de meldingen permanent wil bewaren of slechts eenmaal wil weergeven. In het eerste geval ontkom je er niet aan ze ergens op te slaan (in een database of een text file naast de andere gegenereerde bestanden). In het tweede geval is een PHP session een goede plek, hoewel je korte berichten/statuscodes natuurlijk ook in de query-string van de URL waarna je redirect kunt coderen.

[Matis]

MikeN schreef op zaterdag 21 april 2012 @ 12:17:
Je zal het toch ergens op moeten slaan. Dat is dus of in de sessie (maar dan heb je sowieso niet zoveel aan je PRG verhaal gezien die get dan niet te herhalen is), of in en database (met een id of iets dergelijks in de URL), of gewoon in een textfile (misschien handig, gezien je toch ook al C en H files genereert).

Natuurlijk moet ik de data ergens opslaan, daar ben ik me van bewust. Wat ik nu doe is in de get een id meegeven met de bestandsnaam van de zojuist gegenereerde bestanden. Textfile is eigenlijk nog niet zo'n gek idee. Als ik de bestandsnaam.log aanhoud met daarin de logging, dan kan ik die leeglepelen als de get-pagina wordt gerendered.

iH8 schreef op zaterdag 21 april 2012 @ 12:48:
Misschien kun je iets met Wildfire. Daarmee kun je custom headers genereren en daarin je meldingen meegeven.

Bedankt voor de tip. Om headers te modificeren had ik nog niet gedacht

Soultaker schreef op zaterdag 21 april 2012 @ 12:49:
De vraag is of je de meldingen permanent wil bewaren of slechts eenmaal wil weergeven. In het eerste geval ontkom je er niet aan ze ergens op te slaan (in een database of een text file naast de andere gegenereerde bestanden). In het tweede geval is een PHP session een goede plek, hoewel je korte berichten/statuscodes natuurlijk ook in de query-string van de URL waarna je redirect kunt coderen.

Permanent is zeker niet nodig, sterker nog. Na een refresh van de get-pagina, mag wat mij betreft zelfs de statusmededelingen verdwenen zijn. Aangezien ze de conversie-fase verslaan en bij het opnieuw opvragen van de get-pagina, de conversie-slag niet eens meer uitgevoerd wordt.
De statuscodes in de query-string meegeven wordt nu (bij wijze van workaround) gedaan. Maar vaak zijn de berichten vrij lang en kunnen de URL behoorlijk vervuilen.
Daarnaast adviseert IE9 een maximale URI-lengte van 2083 karakters. Niet dat ik me daardoor zou weerhouden overigens

[iH8]

Matis schreef op zaterdag 21 april 2012 @ 13:49:

Permanent is zeker niet nodig, sterker nog. Na een refresh van de get-pagina, mag wat mij betreft zelfs de statusmededelingen verdwenen zijn. Aangezien ze de conversie-fase verslaan en bij het opnieuw opvragen van de get-pagina, de conversie-slag niet eens meer uitgevoerd wordt.
De statuscodes in de query-string meegeven wordt nu (bij wijze van workaround) gedaan. Maar vaak zijn de berichten vrij lang en kunnen de URL behoorlijk vervuilen.
Daarnaast adviseert IE9 een maximale URI-lengte van 2083 karakters. Niet dat ik me daardoor zou weerhouden overigens

In zou dan idd even naar Wildfire kijken of zelf iets via de headers proberen. Je vervuilt er je responsebody niet mee en komt niet in de knoei met url-length. Je krijgt ook nog eens mooi JSON terug. Zoiets bijvoorbeeld:

code:

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection: close
Content-Length: 1314
Content-Type: text/html
Date: Sat, 21 Apr 2012 11:04:05 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Server: Apache
X-Powered-By: iH8
X-Wf-1-1-1-1: 282|[{"Type":"TABLE","Label":"Zend_Db_Profiler_Firebug (3 @ 0.00152 sec)"},[["Time","Event","Parameters"],["0.00045","connect",null],["0.0008","DESCRIBE `sessions`",null],["0.00028","SELECT `sessions`.* FROM `sessions` WHERE (((`sessions`.`id` = 'xxxxxxxxxxxxxxxxxxxxxx')))",null]]]|
X-Wf-1-Plugin-1: http://meta.firephp.org/Wildfire/Plugin/ZendFramework/FirePHP/1.6.2
X-Wf-1-Structure-1: http://meta.firephp.org/Wildfire/Structure/FirePHP/FirebugConsole/0.1
X-Wf-Protocol-1: http://meta.wildfirehq.org/Protocol/JsonStream/0.2

[Matis]

iH8 schreef op zaterdag 21 april 2012 @ 15:28:
In zou dan idd even naar Wildfire kijken of zelf iets via de headers proberen. Je vervuilt er je responsebody niet mee en komt niet in de knoei met url-length. Je krijgt ook nog eens mooi JSON terug. Zoiets bijvoorbeeld:

code:

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection: close
Content-Length: 1314
Content-Type: text/html
Date: Sat, 21 Apr 2012 11:04:05 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Server: Apache
X-Powered-By: iH8
X-Wf-1-1-1-1: 282|[{"Type":"TABLE","Label":"Zend_Db_Profiler_Firebug (3 @ 0.00152 sec)"},[["Time","Event","Parameters"],["0.00045","connect",null],["0.0008","DESCRIBE `sessions`",null],["0.00028","SELECT `sessions`.* FROM `sessions` WHERE (((`sessions`.`id` = 'xxxxxxxxxxxxxxxxxxxxxx')))",null]]]|
X-Wf-1-Plugin-1: http://meta.firephp.org/Wildfire/Plugin/ZendFramework/FirePHP/1.6.2
X-Wf-1-Structure-1: http://meta.firephp.org/Wildfire/Structure/FirePHP/FirebugConsole/0.1
X-Wf-Protocol-1: http://meta.wildfirehq.org/Protocol/JsonStream/0.2

Misschien dat ik het verkeerd begrijp, maar ik wil graag de mededelingen op het scherm toveren, niet als firebug-logging. (Al is dat sowieso wel erg prettig om te doen).
Ik krijg de indruk dat Wildfire zich meer richt op debugging dan op het doorgeven van data voor het weergeven op het scherm.

[ Voor 4% gewijzigd door Matis op 21-04-2012 15:33 ]

[iH8]

Matis schreef op zaterdag 21 april 2012 @ 15:32:
[...]

Misschien dat ik het verkeerd begrijp, maar ik wil graag de mededelingen op het scherm toveren, niet als firebug-logging. (Al is dat sowieso wel erg prettig om te doen).

Je kunt die headers gewoon zelf opvissen met een stukje clientside scripting. Daar zijn ook bestaande libs voor. Bijvoorbeeld: https://github.com/cadorn...ee/master/packages/lib-js

JavaScript:

var WILDFIRE = require("wildfire", "wildfire");

var receiver = WILDFIRE.Receiver();
receiver.setId("<Receiver URI which is typically a URL>");
receiver.addListener({
    onMessageReceived: function(context, message) {
        var meta = message.getMeta();
        var data = message.getData();
    }
});

var channel = WILDFIRE.HttpHeaderChannel();
channel.addReceiver(receiver);

// Run received headers through:
channel.parseReceived([
    { "name": "x-wf-...", "value": "..."},
    { "name": "...", "value": "..."}
], context);

[MikeN]

Ik zie niet echt hoe custom headers hierbij iets gaan helpen. De client's browser doet uiteindelijk het request, en zolang je aan standaard post, redirect, get vasthoudt kun je niet met de headers info door gaan geven. Sowieso kun je in dat geval net zo goed de sessie gebruiken.

[naam]

Zo moeilijk is het niet om hiervoor de sessie te gebruiken toch? Ik weet dat o.a het symfony framework het op deze manier doet.

Dit zou bijvoorbeeld een manier kunnen zijn:

post_verwerk.php:

PHP:

session_start();
$_SESSION['messages'] = array();
$_SESSION['messages'][] = "Er ging iets goed!";

get.php:

PHP:

session_start();
foreach($message in $_SESSION['messages'])
{
  echo $message . '<br />';
}
$_SESSION['messages'] = array();

Op deze manier laat je de messages 1 keer zien, en daarna gooi je de sessie array weer leeg. In symfony wordt deze functionaliteit overigens een 'flash' genoemd, mogelijk dat je daar nog wat mee kunt.
setflash() en getflash()

[Matis]

Ja, in Code Igniter worden het ook flash messages genoemd.

Ikzelf heb nu practisch dezelfde code als jij. Alleen doe ik ipv regel 6 in jouw get.php een session_destroy().

PHP:

<?php
session_start();
ini_set('display_errors', 1);
ini_set('error_reporting', -1);
date_default_timezone_set("Europe/Amsterdam");
$messages = (key_exists('messages', $_SESSION) ? $_SESSION['messages'] : null);
?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Get Page</title>
</head>
<body>
<?php
if($messages !== null)
{
    echo '<ul>';
    foreach($messages as $message)
    {
        echo '<li>'.$message.'</li>';
    }
    echo '<ul>';
    session_destroy();
}
?>
</body>
</html>

Werkt praktisch hetzelfde als jouw script.

Bedankt allemaal voor het meedenken, ik ben er uit