[PHP]Gegevens meegeven naar nieuwe pagina na redirect *

[ultimatia]

Hallo mensen,

Via een header kun je de gebruiker gemakkelijk terug laten sturen naar bijvoorbeeld de pagina waar ze eerder wegkwamen.

Nu heb ik de volgende vraag: Stel dat een administartor een wijzing uitvoerd in bijvoorbeeld een product. Wanneer de gebruiker op verstuur update is het geen probleem om deze terug te sturen naar het overzicht waarin de geupdate gegevens staan,

PHP:

header('Location beheer.php'); // of iets degelijks

is het echter ook op een gemakkelijke manier mogelijk dat de gebruiker naar deze pagina gestuurd wordt, inclusief een nieuw regel met bijvoorbeeld "het product $product_naam is correct gewijzigd!"

Ik heb even zitten zoeken, maar kon hier niet direct iets vinden hierover terwijl ik er wel in geintreseerd in ben.

Mvg, Ult

[zwippie]

Je kan zo'n boodschap opslaan in de sessie. Bij elke pagina aanvraag kijk je dan of er nog een boodschap in de sessie staat, zo ja, dan laat je die zien.

[gorgi_19]

Of je kan het ook meegeven in de querystring en deze dan uitlezen.

[CodeCaster]

Je zal moeten beslissen hoe je in je code wil bepalen of het product gewijzigd is. Je kunt, zoals zwippie hierboven vertelt, iets opslaan in je sessie. Dat heeft zo z'n voor- en nadelen. Een andere optie zou kunnen zijn om het in een GET-variabele te stoppen (?changed=true), of in de URL (wat dan door rewriting ook weer in de GET terechtkomt)... net wat je voorkeur heeft, en welke voor- of nadelen je het zwaarst vindt wegen.

En ik moet sneller tikken. gorgi

[ Voor 5% gewijzigd door CodeCaster op 21-06-2009 16:59 ]

[jeroenikke]

Je kan ook met meta-tags je gebruiker eerst naar een pagina sturen met de boodschap: Er is iets gewijzigd, en dat die pagina dan na x seconden de gebruiker terug door stuurt naar de beginpagina.

http://webdesign.about.co...libraries/a/aa080300a.htm

[mithras]

Ik denk dat je twee opties hebt: na het opslaan dezelfde pagina tonen. Als je een formulier verstuurt naar de url die je op dat moment bezoekt is dat geen probleem.
De tweede optie die ik soms ook hanteer is het doen van een Refresh header in plaats van een Location header. Deze zorgt voor een redirect na bepaalde tijd:

PHP:

header('Refresh: 5; http://domein.nl');

Je kan ook de melding meegeven in je GET bijvoorbeeld, maar dat kan soms rare resultaten opleveren (gebruikers kunnen deze tekst dus ook zelf veranderen in de url). Een sessie is ook mogelijk, maar persoonlijk vind ik dat meer gedoe

[ultimatia]

Hartelijk dank allemaal, ik heb weer heel wat om te proberen, er zijn dus meer dan genoeg mogelijkheden.

Ik vindt de refresch manier van Mithras heel mooi, de gebruiker heeft dan echt door dat er iets gebeurt.
Ga zowieso ook met de sessies en de metatags aan de slag.

[ Voor 10% gewijzigd door ultimatia op 21-06-2009 17:17 ]

[CodeCaster]

Je kunt ook gewoon zorgen dat je e.e.a. wat slimmer ontwerpt zodat zulke kunstgrepen niet nodig zijn.

Als je nou eens het volgende stukje psuedocode neemt:

PHP:

$somePage = new PageWithAForm();

if ($somePage->isPosted()) {
  $somePage->processForm();

  if ($somePage->formValid()) {
    $this->template->assign("success", true);
  } else {
    $somePage->printForm();
  }
} else {
  $somePage->printForm();
}

Daar kom je een stuk verder mee

[Gomez12]

Houd aub wel in de gaten dat je enkel een indicatie kan meesturen dat iets gewijzigd zou moeten zijn, er is over het algemeen geen garantie tijdens het opslaan dat het ook echt gebeurd is.

Persoonlijk zou ik dan ook bij het tonen van de pagina controleren of wat de gebruiker geprobeerd heeft te wijzigen ook echt gewijzigd is.

Het staat een beetje stom om blind een bericht te sturen dat iets gewijzigd is, terwijl het vanwege een dbase fout niet gewijzigd is...

[Borizz]

De beste oplossing is naar mijn mening om de gebruiker te redirecten (eventueel met een GET parameter, zodat je een melding kan tonen) nadat de data succesvol is opgeslagen. Dit is een van de makkelijkste oplossingen en voorkomt ook dat het formulier nogmaals gepost wordt indien de gebruiker de pagina refreshed.

@mithras:
De Refresh header is geen onderdeel van de officiële HTTP standaard. Het wordt i.v.m. accessability ook afgeraden om deze header te gebruiken door het W3C.

@ultimatia:
De HTTP Location header hoort een absolute URI mee moet sturen (dus incl. http://... etc). Zie RFC 2616 14.30 Location.

Jou methode werkt in de meeste browsers (voor windows), maar in het verleden hebben Safari en Konqueror in ieder geval problemen gehad met relatieve URLs in een Location header (wellicht dat dat nu nog zo is aangezien het in de specificatie zo beschreven staat).

[Woy]

Ik heb het topic een iets duidelijker titel geven, let daar in het vervolg A.U.B. een beetje op, want Header vraag is natuurlijk niet echt beschrijvend voor je probleem

[mithras]

CodeCaster schreef op zondag 21 juni 2009 @ 17:22:
Je kunt ook gewoon zorgen dat je e.e.a. wat slimmer ontwerpt zodat zulke kunstgrepen niet nodig zijn.

Daar kom je een stuk verder mee

Al ben ik meer voorstander om je notifications uit je view laag te halen.

Borizz schreef op maandag 22 juni 2009 @ 00:38:
De beste oplossing is naar mijn mening om de gebruiker te redirecten (eventueel met een GET parameter, zodat je een melding kan tonen) nadat de data succesvol is opgeslagen. Dit is een van de makkelijkste oplossingen en voorkomt ook dat het formulier nogmaals gepost wordt indien de gebruiker de pagina refreshed.

Bedenk wel dat een gebruiker dus zelf áltijd de GET zelf kan toevoegen en daarbij ongewenst het bericht kan tonen. Iets wat mij niet wenselijk lijkt. Dit kan je opvangen dmv extra checks, maar dan heb je in principe die hele GET parameter niet meer nodig

@mithras:
De Refresh header is geen onderdeel van de officiële HTTP standaard. Het wordt i.v.m. accessability ook afgeraden om deze header te gebruiken door het W3C.

Je haalt afaik de refresh header en het meta element door de war

Je hebt gelijk dat het niet onderdeel van de officiele http standaard is, maar toch blijf ik hem gerbuiken. Qua usability is het voor de gebruiker erg fijn imho om een bericht te krijgen en daarna doorgestuurd te worden (in sommige gevallen! Niet altijd natuurlijk). Daarnaast kunnen zoekmachines tegenwoordig ook al redelijk met Refresh headers omgaan (al zullen ze dat bij mij nooit tegenkomen, de Refresh header krijgen bezoekers in slechts enkele gevallen te zien).

[Borizz]

mithras schreef op maandag 22 juni 2009 @ 09:32:
[...]
Bedenk wel dat een gebruiker dus zelf áltijd de GET zelf kan toevoegen en daarbij ongewenst het bericht kan tonen. Iets wat mij niet wenselijk lijkt. Dit kan je opvangen dmv extra checks, maar dan heb je in principe die hele GET parameter niet meer nodig

Dat kan inderdaad, maar je geeft zelf al aan dat de gebruiker de parameter dan zelf aan moet passen. Als de gebruiker een andere url intikt komt hij toch ook op een andere pagina? Je kan idd in de sessie opslaan dat het opslaan gelukt is en aan de hand daarvan een melding tonen, maar het voordeel van het meegeven van een parameter aan de url is dat je geen sessie nodig hebt.

[...]
Je haalt afaik de refresh header en het meta element door de war

Ik haal ze niet door elkaar, het attribuut 'http-equiv' bevat namelijk een "HTTP response header name" wat dus aangeeft dat je in die meta tag een HTTP header nabootst. Dus ook daar is de HTTP standaard op van toepassing .

Je hebt gelijk dat het niet onderdeel van de officiele http standaard is, maar toch blijf ik hem gerbuiken. Qua usability is het voor de gebruiker erg fijn imho om een bericht te krijgen en daarna doorgestuurd te worden (in sommige gevallen! Niet altijd natuurlijk). Daarnaast kunnen zoekmachines tegenwoordig ook al redelijk met Refresh headers omgaan (al zullen ze dat bij mij nooit tegenkomen, de Refresh header krijgen bezoekers in slechts enkele gevallen te zien).

Het wordt vrij goed ondersteund dus in die zin geef ik je gelijk dat je het ook gebruikt. Maar dat neemt niet weg dat de redirect ook met javascript prima te realiseren is.

[MuddyMagical]

Wat ik doe is in mijn sessie een statusmsg variabele maken. Op elke pagina word een functie aangeroepen die kijkt of die statusmsg iets bevat. Zo ja dan wordt deze in een div getoond en leeggehaald.

PHP:

if (!empty($_SESSION['statusmsg'])) { 
?>
    <div id="statusmsg">
        <span id="statusmsg_header">Statusmessage:</span>
        <span><?php echo($_SESSION['statusmsg']); ?></span>  
    </div>
<?php 
} 
unset($_SESSION['statusmsg']);
?>

Werkt super handig en ik kan er geen nadelen aan ontdekken bij de dingen die ik bouw.

[CodeCaster]

mithras schreef op maandag 22 juni 2009 @ 09:32:
[...]
Al ben ik meer voorstander om je notifications uit je view laag te halen.

Notifications horen toch in je view? Een methode "showNotLoggedIn()" zou een melding in je template moeten laten maken (TemplatePower->newBlock("notLoggedIn") of Smarty->assign("notLoggedIn", true)).

Zo kun je de meldingen in je template een stijl, positie en taal meegeven terwijl er in je code niets verandert.

[mithras]

CodeCaster schreef op woensdag 24 juni 2009 @ 13:42:
[...]

Notifications horen toch in je view? Een methode "showNotLoggedIn()" zou een melding in je template moeten laten maken (TemplatePower->newBlock("notLoggedIn") of Smarty->assign("notLoggedIn", true)).

Zo kun je de meldingen in je template een stijl, positie en taal meegeven terwijl er in je code niets verandert.

Ik vind het gewoon lelijk om een view te hebben als zoiets:

PHP:

<?php if($this->languageError): ?>
  <p class="error">De taal kon niet gevonden worden!</p>
<?php endif?>
<?php if($this->reactionPostError): ?>
  <p class="error">Er ging iets mis bij het plaatsen van een reactie!</p>
<?php endif?>
<?php if($this->reactionPostSuccess): ?>
  <p class="success">Je hebt succesvol een reactie geplaatst!</p>
<?php endif?>

<h1><?= $this->article->getTitle()?></h1>
<div class="lead"><?= $this->article->geLead()?></div>
<div class="body"><?= $this->article->getBody()?></div>

<h2>Reacties</h2>
<?php if($this->reactionsNotFound):?>
  <p class="warning">Er zijn nog geen reacties!</p>
<? else:?>
  <?php foreach ($this->reactions as $reaction): ?>
    <!-- do something with reactions -->
  <?php endforeach?>
<?php endif;?>

<h2>Reageren</h2>
<?php if($this->reactionNotAllowed):?>
  <p class="warning">Het is niet toegestaan te reageren!</p>
<?php else:?>
  <?= $this->form->render() ?>
<?php endif;?>

Het lijkt me ook niet dat al deze controles eerst plaatsvinden in je controller en vervolgens check je nog een keer in je view of je het moet laten zien. Dat verhoogt de kansen op bugs. Ik stuur elke keer zo'n notification eruit, dan blijft je view gewoon schoon (zoals het hoort imho).

De blog post die ik maakte kan je wel degelijk aan een view koppelen. In Zend heb ik nu een front controller plugin die de notifications opvangt. Dat zou je naar een view door kunnen spelen (is wel netter), maar ik render ze even onderhands en stop ze in de body van mijn layout. Het kan wat netter wat dat betreft, maar het principe (en de uitwerking) is er.

Een bijkomend voordeel is dat je ook de berichten kan afvangen naar meerdere subjects. Je kan het mislukken van een post doorgeven aan de gebruiker, een log en weet ik veel wat meer. Het is daarmee een stuk flexibeler

[CodeCaster]

De code die jij post is ook niet netjes, maar ik noemde twee gangbare templatesystemen waarin je dergelijke code grotendeels afwezig kunt laten.

Ik vind een syntax zoals Smarty die gebruikt persoonlijk best prettig:

HTML:

{if $name_exists}
<p class="error">* Er bestaat al een project met deze naam.</p>
{/if}
  <label for="name">Naam:</label> <input id="name" type="text" name="name" value="{$data.name}" maxlength="32" /> (maximaal 32 tekens lang)<br />

Of anders TemplatePower:

HTML:

<!--  START BLOCK : name_exists -->
<p class="error">* Er bestaat al een project met deze naam.</p>
<!--  END BLOCK : name_exists -->
  <label for="name">Naam:</label> <input id="name" type="text" name="name" value="{$data.name}" maxlength="32" /> (maximaal 32 tekens lang)<br />

Jij houdt je bezig met het in HTML stoppen van je bericht, en dat doe je in je controller... dat lijkt me minder wenselijk dan een eenvoudige $tpl->assign("name_exists", true);.

Het voordeel van mijn werkwijze waarbij ik gebruik maak van templates is dat ik de positie, opmaak én inhoud van berichten in mijn view kan bepalen.

Een bijkomend voordeel is dat je ook de berichten kan afvangen naar meerdere subjects. Je kan het mislukken van een post doorgeven aan de gebruiker, een log en weet ik veel wat meer. Het is daarmee een stuk flexibeler

Ik hoef niet te weten dat een post is mislukt, maar waaróm. Bijvoorbeeld welke query is uitgevoerd, en wat hiervan het resultaat was. De gebruiker heeft daar niet alleen niets aan, maar ook nog eens helemaal niets mee te maken. En wat als ik bij het tonen van een message met jouw systeem een afbeelding, bijvoorbeeld een mooi uitroepteken, mee wil geven? Moet ik dat dan in de message zelf zetten?

[ Voor 29% gewijzigd door CodeCaster op 24-06-2009 14:25 ]

[mithras]

CodeCaster schreef op woensdag 24 juni 2009 @ 14:15:
De code die jij post is ook niet netjes, maar ik noemde twee gangbare templatesystemen waarin je dergelijke code grotendeels afwezig kunt laten.

Ik vind een syntax zoals Smarty die gebruikt persoonlijk best prettig:

HTML:

{if $name_exists}
<p class="error">* Er bestaat al een project met deze naam.</p>
{/if}
  <label for="name">Naam:</label> <input id="name" type="text" name="name" value="{$data.name}" maxlength="32" /> (maximaal 32 tekens lang)<br />

Of anders TemplatePower:

HTML:

<!--  START BLOCK : name_exists -->
<p class="error">* Er bestaat al een project met deze naam.</p>
<!--  END BLOCK : name_exists -->
  <label for="name">Naam:</label> <input id="name" type="text" name="name" value="{$data.name}" maxlength="32" /> (maximaal 32 tekens lang)<br />

Nu was mijn voorbeeld ook expres wat cluttered, om te laten zien dat je bij een extra mogelijkheid voor een melding een heel bups aan code nodig hebt in diezelfde view. Of het nu met php gaat, Smarty of TemplatePower maakt in die zin niet heel veel uit natuurlijk. Waar jij nu meer op doelt is syntax, maar dat is voor mij eigenlijk minder belangrijk

Jij houdt je bezig met het in HTML stoppen van je bericht, en dat doe je in je controller... dat lijkt me minder wenselijk dan een eenvoudige $tpl->assign("name_exists", true);.

Wat ik belangrijker vind is dit punt. Je kan namelijk zowel in je controller als in je view een bug introduceren. Je kan een typefout maken of een fout in de omliggende if/else. En dat dus twee keer. Een notification oproepen beperkt zich eigenlijk enkel tot in de controller. Dus kan je daar minder fouten in maken.

offtopic:
Ja, ik wel eens gewerkt met systemen die een $isNotRight achtige variabele hebben. Je wil dat het wel goed is, dus moet de $isNotRight false zijn om met dubbele ontkenning je waarheid te krijgen. Imho grote bron van bugs

Daarnaast wil ik graag de verantwoordelijkheid van mijn 'blog-artikel-view' beperken tot het weergeven van een artikel. En liefst niet alle meuk eromheen die wel van belang is, maar niet per definitie tot de verantwoordelijkheid behoort om het blog artikel te laten zien.

Het voordeel van mijn werkwijze waarbij ik gebruik maak van templates is dat ik de positie, opmaak én inhoud van berichten in mijn view kan bepalen.

Dat is nu het fijne van het Zend Framework waarin ik werk. Voor je eerste punt: wat ik al eerder zei, het is geen probleem om de opmaak van het berichtje via een view te laten verlopen. Dat is voor mij luiheid dat ik het niet doe, maar maakt niet uit voor dit principe.

Verder denk ik niet dat je view bedoeld is om inhoud van bericht te bepalen. Dat doe ik in mijn controller. Of beter gezegd, ik roep in mijn controller een string aan die door Zend_Translate vertaald wordt naar de juiste taal. Die staat in een apart bestand en is dus onafhankelijk van view of controller.

Het derde ding (positie): het handige is dat ik de notificatie in de body van de layout dump, voordat de view erin komt te staan (in de controller gooi je eerst de notificatie, daarna wordt aan het einde van de actie de view gerendered). Dat betekent als ik een pagina heb met drie blokken:

A
B
C

Waarbij A en C tekst zijn en B een contact formulier, de notificatie altijd tussen A en B in komt te staan: zo dicht mogelijk bij het betreffende blok en altijd erboven. Voor mij dus de optimale situatie: het gebeurt goed en ik hoef er niet meer over na te denken.

[...]
Ik hoef niet te weten dat een post is mislukt, maar waaróm. Bijvoorbeeld welke query is uitgevoerd, en wat hiervan het resultaat was. De gebruiker heeft daar niet alleen niets aan, maar ook nog eens helemaal niets mee te maken. En wat als ik bij het tonen van een message met jouw systeem een afbeelding, bijvoorbeeld een mooi uitroepteken, mee wil geven? Moet ik dat dan in de message zelf zetten?

Waar je nu op doelt is waarschijnlijk meer een berichtgeving bij een input field dat er iets niet goed is gegaan (te kort, te lang, leeg, geen email adres etc). Dat zijn zaken die in Zend via validators gaan. Die geven bepaalde meldingen (bijv. "Value is required and can't be empty"). Deze teksten zijn weer te vertalen. De positie van deze meldingen zijn weer te bepalen via decorators.

De eigenlijke foutmeldingen bij een formulier staan dus los van andere meldingen die ik geef (taal niet gevonden, bericht met succes geplaatst, login correct etc).

Maar eigenlijk denk ik dat beide methoden niet slecht zijn. Er leiden meer wegen naar Rome. Ik denk wel dat "mijn manier" wat meer voordelen zal bieden als je systeem groter wordt. "Jouw manier" zal eenvoudiger zijn om in begin op te zetten en daarom makkelijker voor kleinere applicaties