[PHP] Smarty {if}{else} statement *

[DeluxZ]

Sinds een paar dagen ben ik bezig om Smarty onder de knie te krijgen. Ik had al een site in html/css gemaakt en deze omgezet naar een .tpl bestand (bv. index.tpl) en via index.php laten zien. Dit werkt allemaal goed.

Daarna begonnen met het "assignen" van variablen in de code d.m.v

PHP:

$smarty->assign("naam", "Foo")

en deze dan aan te roepen in index.tpl d.m.v

HTML:

{$naam}

Dit lukt allemaal aardig. Maar nu ben ik bezig met een login/registreer systeempje en loop ik tegen een probleem aan met het scheiden van content en code.

Ik kijk eerst of er gesubmit wordt in hier formulier, hierna voer ik een aantal checks uit of er velden zijn ingevuld en of deze wel geldig zijn. Als dit is wordt de user ge-insert in de database d.m.v een query. Als die query lukt wordt er een e-mail gestuur naar de gebruiker d.m.v de PHPMailer class. Daarvoor gebruik ik het volgende stukje code.

PHP:

// PHPMailer class
                require("include/class.phpmailer.php");  
                $mail = new PHPMailer();
                $mail->IsSMTP(); // telling the class to use SMTP
                $mail->Host = "mailserver.test.nl"; // SMTP server
                $mail->From = "[e-mail]";
                $mail->FromName = "Test.nl";
                $mail->AddAddress($_POST['email']);
                
                $mail->Subject  = "Registratie ".$sitename."";
                $message  = "Beste ".$_POST['username'].",\n\n";
                $message .= "Je hebt je geregistreerd op de site ".$sitename.", dit is de activatie e-mail van je registratie.\n";
                $message .= "Om je account te activeren, druk je op de link onderaan deze mail.\n\n ";
                $message .= "Registratie bevestigen: ".$siteurl."activate.php?userid=".$userid."&code=".$actcode."&registrate=true \n\n";
                $message .= "Zodra je op deze link geklikt hebt, kun je inloggen met:\n";
                $message .= "Username: ".$_POST['username']."\n";
                $message .= "Password: ".$_POST['pass1']."\n\n";
                $message .= "** Dit is een automatisch verzonden bericht **";
                $mail->Body = $message;
                
                if(!$mail->Send()) {
                        echo "Fout opgetreden tijdens verzenden van e-mail. Neem contact op met <a href=\"mailto:".$sitemail."\">".$sitemail."</a>.";
                    }else{
                        echo "Je bent succesvol geregistreerd! Zodra je de link in de mail hebt bezzocht kun je inloggen.<br/>\n<a href=\"login.php\">&raquo; Naar de inlogpagina</a>";
                    }

Dit lukt goed, maar het probleem is dat de tekst "Je bent succesvol......" op een blanke pagina komt te staan. Begrijpelijk omdat dit niet in de .tpl staat lijkt mij. Als ik nu de if-statement in smarty variabelen assign d.m.v de volgende code

PHP:

// Variables for error handling
                $tpl->assign("mail", $mail->Send());
                $tpl->assign("mailerror", "Fout opgetreden tijdens verzenden van e-mail. Neem contact op met <a href=\"mailto:$sitemail\">".$sitemail."</a>.");
                $tpl->assign("mailsuccess", "Je bent succesvol geregistreerd! Zodra je de link in de mail hebt bezocht kun je inloggen.<br/>\n<a href=\"login.php\">&raquo; Naar de inlogpagina</a>");

En in de .tpl het volgende neerzet:

HTML:

{if !$mail}
   {$mailerror}
{else}
   {$mailsuccess}
{/if}

Nadat ik dit heb gedaan geeft hij helemaal niets meer terug naar het browser en krijg ik een "mooie" blanco pagina De e-mails worden wel verstuurd en de user wordt ook gewoon aangemaakt. Maar het is niet netjes om de gebruiker niets te laten weten of het wel danwel niet is gelukt om een account aan te maken. Ik heb de hele documentatie doorgezocht van smarty maar ben niets tegengekomen wat het zou kunnen zijn (vind de voorbeelden niet echt lekker gemaakt voor een noobie met smarty).

Kortom: wat doe ik fout? Moet ik ipv de assign functie een andere functie gebruiken voor het assignen van:

PHP:

$mail->Send()

[mithras]

Heb je het al afzonderlijk gechecked? Dat zou ik eerst doen

code:

{if !$mail}
  bla
{else}
  boe
{/if}

code:

{$mailerror}

code:

{$mailsuccess}

Als alle drie werken, zou ik eens harder moeten nadenken

offtopic:
Verder haat ik Smart om dit soort redenen. Niet fatsoenlijk een error printen maar gewoon een witte pagina. En dan maar puzzelen. Of met een of andere obscure method de error tevoorschijn toveren

[ Voor 32% gewijzigd door mithras op 17-08-2008 21:52 ]

[rickmans]

Gebruik {debug}, dan weet je de waardes .

[DeluxZ]

mithras schreef op zondag 17 augustus 2008 @ 21:51:
Heb je het al afzonderlijk gechecked? Dat zou ik eerst doen

code:

{if !$mail}
  bla
{else}
  boe
{/if}

code:

{$mailerror}

code:

{$mailsuccess}

Als alle drie werken, zou ik eens harder moeten nadenken

offtopic:
Verder haat ik Smart om dit soort redenen. Niet fatsoenlijk een error printen maar gewoon een witte pagina. En dan maar puzzelen. Of met een of andere obscure method de error tevoorschijn toveren

toon volledige bericht

Als ik dit doe en dan ipv jou code

code:

{if !$mail}
fout
{else}
goed
{/if}

Krijg ik al bij het formulier fout voor mijn kiezen. Wat mij logisch is omdat de mail dan nog niet verzonden is.

rickmans schreef op zondag 17 augustus 2008 @ 21:55:
Gebruik {debug}, dan weet je de waardes .

Als ik {debug} boven

HTML:

{if !$mail}
                                    <tr>
                                        <td>{$error}</td>
                                    </tr>
                                    {else}
                                    <tr>
                                        <td>{$success}</td>
                                    </tr>
                                    {/if}

zet krijg ik het volgende in de Smarty Debug Console.


Blijkbaar kent die de waardes van {$error} en {$success} niet ?

[ Voor 39% gewijzigd door DeluxZ op 08-09-2008 15:52 ]

[Anoniem: 112308]

Weet je zeker dat je geen stomme fout maakt zoals het assignen van vars na display() uitgevoerd te hebben of zo? Op zich doe je het goed, als je alleen die 2 foutmeldingen wilt tonen kun je trouwens net zo goed de if else in php uitvoeren en gewoon 1 bericht maken die je in je template afdrukt.

[DeluxZ]

Anoniem: 112308 schreef op zondag 17 augustus 2008 @ 22:28:
Weet je zeker dat je geen stomme fout maakt zoals het assignen van vars na display() uitgevoerd te hebben of zo? Op zich doe je het goed, als je alleen die 2 foutmeldingen wilt tonen kun je trouwens net zo goed de if else in php uitvoeren en gewoon 1 bericht maken die je in je template afdrukt.

Ik heb nog veel meer foutmeldingen die weergegeven moeten worden. Bijvoorbeeld als een gebruikersnaam al bezet is / wachtwoorden niet overeen komen / e-mailadres niet goed is ([e-mail]) / of als ze een veld niet in hebben gevuld / en als ze proberen te registreren als ze al ingelogd zijn

Als deze dan lukken is de rest waarschijnlijk niet zo moeilijk

En over de vars assignen dit doe ik voordat ik een display() uitvoer.

[ Voor 4% gewijzigd door DeluxZ op 17-08-2008 22:43 ]

[DeluxZ]

Anoniem: 112308 schreef op zondag 17 augustus 2008 @ 22:28:
Weet je zeker dat je geen stomme fout maakt zoals het assignen van vars na display() uitgevoerd te hebben of zo? Op zich doe je het goed, als je alleen die 2 foutmeldingen wilt tonen kun je trouwens net zo goed de if else in php uitvoeren en gewoon 1 bericht maken die je in je template afdrukt.

Ik heb vandaag nog wat geprobeerd maar kom er echt niet uit.

Hoe zou ik het dan kunnen proberen op een nette manier, zodat ik code en html/css gescheiden kan houden.

offtopic:
Was hier heel vrolijk mee begonnen maar krijg er nu minder zin in als je 2 dagen zit te klooien om een foutmelding op het scherm te krijgen op de goede plek

[Anoniem: 112308]

DeluxZ schreef op maandag 18 augustus 2008 @ 18:20:
[...]
Ik heb vandaag nog wat geprobeerd maar kom er echt niet uit.

De code die je hier post is gewoon goed, ik heb dus het idee dat het ergens anders niet goed gaat. Ik neem aan dat $tpl een smarty object is, verder:
- zet php error-reporting even aan op alle errors tonen (E_ALL) en display_errors op On uiteraard
- nadat je assign() hebt uitgoeverd, en op het moment voordat je display() doet kun je nog even de smarty-functie get_template_vars() uitvoeren om te checken of alles goed geassigned is
- als je veel include, loop dan even langs of alle vars niet door elkaar lopen

Hoe zou ik het dan kunnen proberen op een nette manier, zodat ik code en html/css gescheiden kan houden.

Met je template heb je code en html eigenlijk al gescheiden, maar je bent nu een heel if-else gedoe in je template aan het inbouwen. Waar ik dan eigenlijk ook op doelde is dit if/else gebeuren in php te doen als het alleen een foutmelding is die je teruggeeft. Dan heb je dus maar 1 template-var nodig die je alleen hoeft af te drukken. Maar dit gaat niet altijd op, omdat je in je foutmelding wel eens html nodig hebt bijvoorbeeld, maar dat is een keuze die je zelf moet maken

[mithras]

Weet je zeker dat je assigned var "mail" true of false is. Wat geeft een var_dump() in php met zowel een succes mailing als een verkeerde?

[Anoniem: 112308]

mithras schreef op maandag 18 augustus 2008 @ 19:08:
Weet je zeker dat je assigned var "mail" true of false is. Wat geeft een var_dump() in php met zowel een succes mailing als een verkeerde?

Het is if-else dus dat maakt eigenlijk niet uit, er wordt er altijd wel 1 uitgevoerd

[robbert]

DeluxZ schreef op zondag 17 augustus 2008 @ 22:07:
[afbeelding]
Blijkbaar kent die de waardes van {$error} en {$success} niet ?

Als ik die debug console mag geloven heeft geen enkele template variable behalve 'title' een waarde. 'mailerror' en 'mailsucces' zijn beide leeg, dus niet heel erg verwonderlijk dat het resultaat leeg is.

mithras schreef op zondag 17 augustus 2008 @ 21:51:

offtopic:
Verder haat ik Smart om dit soort redenen. Niet fatsoenlijk een error printen maar gewoon een witte pagina. En dan maar puzzelen. Of met een of andere obscure method de error tevoorschijn toveren

Gewoon een kwestie van debug dingen aanzetten, dan krijg je prima errors.

Anoniem: 112308 schreef op maandag 18 augustus 2008 @ 19:00:
...nadat je assign() hebt uitgoeverd, en op het moment voordat je display() doet...

Doet de TS dit überhaupt wel in de goede volgorde?

[ Voor 12% gewijzigd door robbert op 18-08-2008 19:33 ]

[DeluxZ]

Anoniem: 112308 schreef op maandag 18 augustus 2008 @ 19:00:
[...]


De code die je hier post is gewoon goed, ik heb dus het idee dat het ergens anders niet goed gaat. Ik neem aan dat $tpl een smarty object is, verder:
- zet php error-reporting even aan op alle errors tonen (E_ALL) en display_errors op On uiteraard
- nadat je assign() hebt uitgoeverd, en op het moment voordat je display() doet kun je nog even de smarty-functie get_template_vars() uitvoeren om te checken of alles goed geassigned is
- als je veel include, loop dan even langs of alle vars niet door elkaar lopen


[...]

Met je template heb je code en html eigenlijk al gescheiden, maar je bent nu een heel if-else gedoe in je template aan het inbouwen. Waar ik dan eigenlijk ook op doelde is dit if/else gebeuren in php te doen als het alleen een foutmelding is die je teruggeeft. Dan heb je dus maar 1 template-var nodig die je alleen hoeft af te drukken. Maar dit gaat niet altijd op, omdat je in je foutmelding wel eens html nodig hebt bijvoorbeeld, maar dat is een keuze die je zelf moet maken

toon volledige bericht

- Ik heb error_reporting(E_ALL) bovenin onder mijn includes gezet (smarty include en config voor db connectie)
- Ik heb na het assignen van de variabelen het volgende:

PHP:

// Variables for error handling
                $tpl->assign("mail", $mail->Send());
                $tpl->assign("error", "Fout opgetreden tijdens verzenden van e-mail.");
                $tpl->assign("success", "Je bent succesvol geregistreerd! Zodra je de link in de mail hebt bezocht kun je inloggen.<br/>\n<a href=\"login.php\">&raquo; Naar de inlogpagina</a>");
                
                // Get all assigned vars and echo them              
                $allvars = $tpl->get_template_vars();
                echo $allvars;

- Veel includen is het niet zoals hierboven staat maar 2 bestanden. In config staat niets anders dan een connectie naar server en database (standaard procedure) en een include voor Smarty.

$tpl is inderdaad een Smarty object

PHP:

// Make new object called "Smarty"
$tpl = new Smarty();

Als ik nu het formulier submit krijg ik een lege pagina met Array en verder niets.

robbert schreef op maandag 18 augustus 2008 @ 19:27:
[...]

Als ik die debug console mag geloven heeft geen enkele template variable behalve 'title' een waarde. 'mailerror' en 'mailsucces' zijn beide leeg, dus niet heel erg verwonderlijk dat het resultaat leeg is.

PHP:

$tpl->assign("error", "FOUT");
                $tpl->assign("success", "GOED");

Als die zelfs dit niet doet, lijkt het me raar? Hij geeft zelfs dan niets weer. Misschien dat het komt omdat hij de volgende code niet goed pakt en daarna op tilt slaat ofzo ?

PHP:

$tpl->assign("mail", $mail->Send());

[ Voor 14% gewijzigd door DeluxZ op 18-08-2008 19:33 ]

[robbert]

DeluxZ schreef op maandag 18 augustus 2008 @ 19:28:

PHP:

// Get all assigned vars and echo them              
$allvars = $tpl->get_template_vars();
echo $allvars;

Gezien get_template_vars een array terug geeft zal dit altijd "Array" afdrukken, gebruik daarom print_r.

[DeluxZ]

robbert schreef op maandag 18 augustus 2008 @ 19:32:
[...]

Gezien get_template_vars een array terug geeft zal dit altijd "Array" afdrukken, gebruik daarom print_r.

My bad nu krijg ik wel een resultaat

code:

Array ( [SCRIPT_NAME] => /Blogs4U.nl/register.php [title] => Register [mail] => 1 [error] => FOUT [success] => GOED )

[Anoniem: 112308]

DeluxZ schreef op maandag 18 augustus 2008 @ 19:35:
[...]


My bad nu krijg ik wel een resultaat

code:

Array ( [SCRIPT_NAME] => /Blogs4U.nl/register.php [title] => Register [mail] => 1 [error] => FOUT [success] => GOED )

Krijg je dit nog steeds terug op het moment net voordat je display() doet?

[DeluxZ]

Nee, dan krijg ik weer een blance pagina. Misschien dat het komt omdat ik in een else waar normaal het formulier moet komen als $_SESSION['userID'] nog niet gemaakt is de $tpl->display() heb staan?

Misschien even die $tpl->display helemaal onderaan zetten en ipv waar ik het nu heb staan gewoon een formulier neerzetten ?

Maar dan zit je weer met html/css & php gescheiden houden. Het is toch niet zo makkelijk als het lijkt

[ Voor 37% gewijzigd door DeluxZ op 18-08-2008 19:49 ]

[Anoniem: 112308]

DeluxZ schreef op maandag 18 augustus 2008 @ 19:42:
Nee, dan krijg ik weer een blance pagina. Misschien dat het komt omdat ik in een else waar normaal het formulier moet komen als $_SESSION['userID'] nog niet gemaakt is de $tpl->display() heb staan?

Zonder je hele code te zien kunnen we hier weinig mee, maar er zal daar ergens dan toch iets niet goed gaan. Lijkt me iig wat standaard debug werk met de tips die iedereen je in dit topic heeft gegeven.

[DeluxZ]

Het is niet de bedoeling maar mijn code is hier te bekijken: register.php en hier de register.tpl

Het lijkt erop dat die ergens de vars $tpl->assign verliest. Hij geeft ze overal goed weer behalve direct voor $tpl->display(register.tpl);

[ Voor 27% gewijzigd door DeluxZ op 18-08-2008 20:03 ]

[Anoniem: 112308]

Kom je uberhaupt wel bij display() terecht met al die if-else dingen? Zet er anders gewoon even een echo() boven, dan weet je zeker waar je wel en niet komt.

[DeluxZ]

Anders laat die toch zowiezo een lege pagina zien ? De display() staat op de plek waar "normaal" als je zonder smarty zou doen het formulier zou komen te staan met de input velden.

[BartV]

Na het registreren en mailtje versturen voer je nooit meer een $tpl->display uit, dus zul je ook geen ouput meer krijgen in je browser.

[DeluxZ]

DikkieDik schreef op maandag 18 augustus 2008 @ 20:51:
Na het registreren en mailtje versturen voer je nooit meer een $tpl->display uit, dus zul je ook geen ouput meer krijgen in je browser.

Als ik het onderaan nog een keer doe komt de layout er twee keer te staan. Ik denk dat ik het formulier niet zo moet laten zien met een $tpl->display() maar ik zou niet weten hoe.

- formulier in .php zetten ?
- formulier in een var zetten en die assignen?

Ik heb al naar voorbeelden gezocht van een login/register systeem met smarty zie www.php-editors.com/contest/1/34-read.html

Zoals in het voorbeeld zal ik het is proberen. Als de user ge-insert is success op 1 zetten. De mail stuurt die wel (nou al vaak getest) dus zal die waarschijnlijk wel blijven werken. Behalve als iemand zijn e-mail adres niet goed invult (maar dit wordt weer afgevangen)

[ Voor 17% gewijzigd door DeluxZ op 18-08-2008 21:09 ]

[BartV]

Je zou bijvoorbeeld een andere .tpl kunnen laten zien zodra het registreren gelukt is. Dus na $mail->send() een $tpl->dispay('register_success.tpl') ofzo. Wel zorgen dat je php script niet daarna nog meer output wil generen.

[DeluxZ]

Zou kunnen. Ik zal mijn script is aanpassen zoals ik zei in mijn vorige post (net ge-edit)

[BartV]

Een van de (beginners) gevaren met smarty (eigenlijk elke scheiding van code/opmaak) is dat je toch teveel logica in je template stopt. Eigenlijk wil je helemaal geen melding in hetzelfde registratie formulier als iets gelukt is, hooguit de foutmeldingen.
Smarty templates kun je weer includen in andere templates, dus dubbele templates hoeft dit niet op te leveren.

[Yeroon1986]

PHP:

$message .= "Password: ".$_POST['pass1']."\n\n";

bovendien wil je dit ook niet, maar goed dat is weer een heel ander verhaal he...

[Peedy]

Je weet dat je ook gewoon in Smarty.class.php van

code:

var $error_reporting  =  null;

dit kan maken:

code:

var $error_reporting  =  E_ALL;

om errors te zien?

[robbert]

Peedy schreef op dinsdag 19 augustus 2008 @ 17:33:
Je weet dat je ook gewoon in Smarty.class.php van

code:

var $error_reporting  =  null;

dit kan maken:

code:

var $error_reporting  =  E_ALL;

om errors te zien?

Smarty.class.php aanpassen is nogal smerig en niet onderhoudbaar, doe dan gewoon:

PHP:

$template->error_reporting = E_ALL;

[Anoniem: 26306]

robbert schreef op dinsdag 19 augustus 2008 @ 19:13:

Smarty.class.php aanpassen is nogal smerig en niet onderhoudbaar, doe dan gewoon:

PHP:

$template->error_reporting = E_ALL;

Nee. Extend gewoon de Smarty class, en doe daarin je eigen settings. Wel zo handig.

[BartV]

Anoniem: 26306 schreef op dinsdag 19 augustus 2008 @ 19:16:
[...]
Nee. Extend gewoon de Smarty class, en doe daarin je eigen settings. Wel zo handig.

Waarom de hele Smarty class extenden om wat eigen settings te doen? Lijkt me wat overkill. Of je ze nou in je Smarty object zet, of in je eigen extended Smarty object, weinig verschil.

[Anoniem: 26306]

DikkieDik schreef op dinsdag 19 augustus 2008 @ 23:04:

Waarom de hele Smarty class extenden om wat eigen settings te doen? Lijkt me wat overkill. Of je ze nou in je Smarty object zet, of in je eigen extended Smarty object, weinig verschil.

Welke overkill? Of je nou fatsoenlijk wilt programmeren of niet.

[robbert]

Anoniem: 26306 schreef op dinsdag 19 augustus 2008 @ 23:20:
[...]

Welke overkill? Of je nou fatsoenlijk wilt programmeren of niet.

Die klasse overerven enkel om een paar settings aan te passen vind ik nou ook niet echt nodig, zou het pas spannender vinden als je ook nog wat eigen methodes toe wil voegen. Maar ja, ieder zijn smaak zal ik maar zeggen...

[Gomez12]

Gokje, maar imho geef je je eigen antwoord zelf al...

Als je het later wilt uitbreiden met methodes / andere dingen dan moet je het weer ombouwen, als je het later in een ander project wilt gebruiken is een extended class ook iets makkelijker dan deze methode.

Het gaat niet zozeer om die paar settings, als het een niet eigen class is dan zou ik hem ook gewoon extenden. Heeft imho te maken met geen waarzegger te zijn en gewoon een standaard luie programmeur die 90% van zijn code wil hergebruiken zonder copy/paste fouten etc.

[Anoniem: 26306]

robbert schreef op woensdag 20 augustus 2008 @ 01:44:

Die klasse overerven enkel om een paar settings aan te passen vind ik nou ook niet echt nodig,

Wat zijn dat nou voor termen? Niet nodig! Overkill! Jullie doen net alsof het meer dan een paar tellen kost. Of een shitload aan geheugen.
Als je net leert programmeren is het misschien heel spannend, maar op een gegeven moment is het gewoon routine en denk je daar niet meer over na. Je begint nota bene zelf over "niet onderhoudbaar". Op hoeveel plekken ben je van plan de Smarty class te instantiëren?

[robbert]

Anoniem: 26306 schreef op woensdag 20 augustus 2008 @ 07:33:
Op hoeveel plekken ben je van plan de Smarty class te instantiëren?

één, en dat is juist de rede dat ik het overerven van die klasse overbodig vind.

[ Voor 18% gewijzigd door robbert op 20-08-2008 10:55 ]

[Patriot]

Anoniem: 26306 schreef op woensdag 20 augustus 2008 @ 07:33:
[...]

Wat zijn dat nou voor termen? Niet nodig! Overkill! Jullie doen net alsof het meer dan een paar tellen kost. Of een shitload aan geheugen.
Als je net leert programmeren is het misschien heel spannend, maar op een gegeven moment is het gewoon routine en denk je daar niet meer over na. Je begint nota bene zelf over "niet onderhoudbaar". Op hoeveel plekken ben je van plan de Smarty class te instantiëren?

In dit geval, en dan voornamelijk in PHP, is het totaal oninteressant om hier een eigen klasse voor te maken. Over het algemeen heb je één enkele instantie van Smarty, die je instantiëerd in het configuratiebestand. Het is dan, voor de meeste mensen, makkelijker te onderhouden als je gewoon wat properties verandert nadat je het object hebt aangemaakt.

Er is gewoon geen voordeel om een aparte klasse te maken als je gewend bent de properties te zetten. Dat betekend niet dat het slecht is om het toch te doen hoor, maar het biedt gewoon geen voordelen.

[BartV]

Patriot schreef op woensdag 20 augustus 2008 @ 10:46:
[...]
Er is gewoon geen voordeel om een aparte klasse te maken als je gewend bent de properties te zetten. Dat betekend niet dat het slecht is om het toch te doen hoor, maar het biedt gewoon geen voordelen.

En dat was nou ook exact mijn punt...

[XWB]

robbert schreef op woensdag 20 augustus 2008 @ 01:44:
[...]

Die klasse overerven enkel om een paar settings aan te passen vind ik nou ook niet echt nodig, zou het pas spannender vinden als je ook nog wat eigen methodes toe wil voegen. Maar ja, ieder zijn smaak zal ik maar zeggen...

Met OOP willen we juist de variabelen niet van buitenaf kunnen aanpassen. Instantiëren doe je met een class die Smarty overerft.

één, en dat is juist de rede dat ik het overerven van die klasse overbodig vind.

Juist, laten we OOP concept maar in de prullenbak gooien

Er is gewoon geen voordeel om een aparte klasse te maken als je gewend bent de properties te zetten. Dat betekend niet dat het slecht is om het toch te doen hoor, maar het biedt gewoon geen voordelen.

Het is gewoon het principe (OOP). Omdat het in php niet verplicht is wil je het niet doen? Ik hoop dat ik jouw code niet moet onderhouden.

[ Voor 21% gewijzigd door XWB op 20-08-2008 12:34 ]

[Anoniem: 140111]

Die klasse overerven enkel om een paar settings aan te passen vind ik nou ook niet echt nodig, zou het pas spannender vinden als je ook nog wat eigen methodes toe wil voegen. Maar ja, ieder zijn smaak zal ik maar zeggen...

Je doet toch niets vreemds? Je creert helemaal geen overhead, maar je past gewoon OO-principes toe.

[robbert]

Hacku schreef op woensdag 20 augustus 2008 @ 12:33:
Met OOP willen we juist de variabelen niet van buitenaf kunnen aanpassen. Instantiëren doe je met een class die Smarty overerft.

Dan had Smarty die velden maar private of protected moeten maken en get en set methodes aan moeten bieden...

Hacku schreef op woensdag 20 augustus 2008 @ 12:33:
Juist, laten we OOP concept maar in de prullenbak gooien

Er is echt niks mis met geparameteriseerde klassen in het OOP concept.

Laten we voortaan voor elke instantie van een klasse die we willen maken, deze klassen overerven en daar alle parameters instellen....

[ Voor 34% gewijzigd door robbert op 20-08-2008 13:22 ]

[XWB]

Laten we voortaan voor elke instantie van een klasse die we willen maken, deze klassen overerven en daar alle parameters instellen....

Ja, hoe wil je het anders doen? Ofwel erf je de klasse over, ofwel werk je moet setters. Variabelen van buitenaf wijzigen vind ik not done. Dat het in php allemaal kan wil niet zeggen dat je het zo moet doen.

[robbert]

Hacku schreef op woensdag 20 augustus 2008 @ 13:37:
[...]


Ja, hoe wil je het anders doen? Ofwel erf je de klasse over, ofwel werk je moet setters. Variabelen van buitenaf wijzigen vind ik not done. Dat het in php allemaal kan wil niet zeggen dat je het zo moet doen.

Dit heeft helemaal niks te maken met "dat het allemaal kan in PHP", in Java of C++ kan ik velden ook public maken. Het is dan gewoon de fout van Smarty dan zei kiezen voor publieke velden in plaats van getters en setters.

[Gomez12]

@robbert, als je het zelf al een fout van Smarty vind, waarom vind je het dan niet fout om die werkwijze te hanteren die Smarty mogelijk maakt...

Imho kan Smarty een inschattingsfout maken maar ik kan nog steeds netjes werken...

[Janoz]

robbert schreef op woensdag 20 augustus 2008 @ 10:38:
[...]

één, en dat is juist de rede dat ik het overerven van die klasse overbodig vind.

Ik zie niet waarom de eerste een reden voor de tweede moet zijn. Het eerste is eerder een reden dat het extenden alleen nog maar nog makkelijker wordt. Mij bekruipt dan ook het gevoel dat jou niet helemaal duidelijk is wat de impact en het gevolg van extenden is. Ik zal ze daarom voor je opnoemen:

impact:
1 aanpassing bij je instantiatie (new mySmarty ipv new smarty)
1 extra class bestaande uit:
- alle settings gecentraliseerd die je anders op minder logische plaatsen had staan
- Het aanroepen van de constructor van Smarty omdat php een brakke oop implementatie heeft

gevolgen:
- gecentraliseerde en logische plek waar eigen uitbreidingen van smarty staan
- Templates en andere code worden niet vervuild met je smarty uitbreidingen

[Patriot]

Janoz schreef op woensdag 20 augustus 2008 @ 14:32:
[...]

Ik zie niet waarom de eerste een reden voor de tweede moet zijn. Het eerste is eerder een reden dat het extenden alleen nog maar nog makkelijker wordt. Mij bekruipt dan ook het gevoel dat jou niet helemaal duidelijk is wat de impact en het gevolg van extenden is. Ik zal ze daarom voor je opnoemen:

impact:
1 aanpassing bij je instantiatie (new mySmarty ipv new smarty)
1 extra class bestaande uit:
- alle settings gecentraliseerd die je anders op minder logische plaatsen had staan
- Het aanroepen van de constructor van Smarty omdat php een brakke oop implementatie heeft

gevolgen:
- gecentraliseerde en logische plek waar eigen uitbreidingen van smarty staan
- Templates en andere code worden niet vervuild met je smarty uitbreidingen

toon volledige bericht

Daar ben ik het niet mee eens. Sommige instellingen wil je bijvoorbeeld alleen tijdens het testen van de applicatie op een bepaalde waarde hebben. Het is inderdaad handig om de settings gecentraliseerd te hebben, maar je hebt toch wel een configuratiebestand? Daarin zet je dat soort instellingen, en dat is m.i. overzichtelijker dan de settings voor Smarty in de ene map, de settings voor de SQL-verbinding in de andere map, etc.

Verder heeft dit ook niet zo heel veel te maken met de uitbreidingen van Smarty. Ik neem aan dat je custom functies e.d. bedoelt, maar daar heeft Smarty gewoon een eigen API voor die de templates en andere code niet vervuild.

Dat het niet de lijnen van OOP volgt, dat is iets wat ik gerust geloof. Ik weet niet wat de OOP richtlijn zegt over het gebruiken van publieke properties. Maar ik weet wel dat het in PHP algemeen geaccepteerd is, en niet als iets "slechts" gezien wordt. Ik vind het dus ook belachelijk dat het gebruiken van publieke properties door sommige mensen afgedaan wordt als onfatsoenlijk.

EDIT:

Het is gewoon het principe (OOP). Omdat het in php niet verplicht is wil je het niet doen? Ik hoop dat ik jouw code niet moet onderhouden.

Lekker ongenuanceerd conclusies trekken? Het gebruiken van de publieke properties hoeft helemaal niet lastiger te onderhouden zijn. Ik vind het zelfs overzichtelijker om de properties in mijn configuratiebestand te veranderen, dan dat ik een apart bestand met daarin een extra klasse moet maken omwille een paar instellingen.

[ Voor 12% gewijzigd door Patriot op 20-08-2008 15:52 . Reden: nuance, reactie op Hacku ]

[Janoz]

Patriot schreef op woensdag 20 augustus 2008 @ 15:49:
[...]


Daar ben ik het niet mee eens. Sommige instellingen wil je bijvoorbeeld alleen tijdens het testen van de applicatie op een bepaalde waarde hebben. Het is inderdaad handig om de settings gecentraliseerd te hebben, maar je hebt toch wel een configuratiebestand? Daarin zet je dat soort instellingen, en dat is m.i. overzichtelijker dan de settings voor Smarty in de ene map, de settings voor de SQL-verbinding in de andere map, etc.

En waar implementeer je het stukje 'settings inladen'?

Verder heeft dit ook niet zo heel veel te maken met de uitbreidingen van Smarty. Ik neem aan dat je custom functies e.d. bedoelt, maar daar heeft Smarty gewoon een eigen API voor die de templates en andere code niet vervuild.

Assumptions are the mother of all fuckups. Je neemt aan dat ik iets bedoel en gaat vervolgens dat onderuit halen.

Ik reageer puur op de opmerking van Robert.

Dat het niet de lijnen van OOP volgt, dat is iets wat ik gerust geloof. Ik weet niet wat de OOP richtlijn zegt over het gebruiken van publieke properties. Maar ik weet wel dat het in PHP algemeen geaccepteerd is, en niet als iets "slechts" gezien wordt. Ik vind het dus ook belachelijk dat het gebruiken van publieke properties door sommige mensen afgedaan wordt als onfatsoenlijk.

Ik heb het niet over publieke properties gehad. Daarnaast is OOP niet 1 of ander wetmatig iets waar je je verplicht aan zou moeten houden. OOP is een paradigma wat erg handig schijnt te werken. Dat jij dat naast je neer wilt leggen is fine with me.


Tot slot wil ik opmerken dat ik zelf 0,0 ervaring met Smarty heb en wil ik nogmaals aangeven dat ik puur reageerde op de opmerking van Robert.

[Patriot]

Janoz schreef op woensdag 20 augustus 2008 @ 15:56:
En waar implementeer je het stukje 'settings inladen'?

Dat implementeer je in feite niet. Over het algemeen gebruik je één instantie van Smarty. Ook gebruik je vaak maar één set van settings. Mocht je van één van de twee nou meerdere gebruiken, dan zijn er zeker betere opties dan het instellen, maar in dat geval komt er al meer logica bij te kijken, en dan is het logisch om een nieuwe klasse te maken.

Assumptions are the mother of all fuckups. Je neemt aan dat ik iets bedoel en gaat vervolgens dat onderuit halen.

Ik reageer puur op de opmerking van Robert.

Als je dat niet bedoelt, foutje van mij dan I guess.

Ik heb het niet over publieke properties gehad. Daarnaast is OOP niet 1 of ander wetmatig iets waar je je verplicht aan zou moeten houden. OOP is een paradigma wat erg handig schijnt te werken. Dat jij dat naast je neer wilt leggen is fine with me.

Ik heb het niet over naast me neer leggen, ik kan me alleen niet voorstellen dat dit zo vreselijk tegen het gebruik van OOP indruist. Again, ik weet de exacte richtlijnen van OOP niet wat dat betreft, maar is het zo vreselijk om dergelijke instellingen direct op de property te wijzigen? Ik zou het enigszins vreemd vinden als de richtlijn extra werk zou veroorzaken zonder aanwijsbaar voordeel (buiten gewenning aan de richtlijn).

Er wordt gesproken over onfatsoenlijk programmeren maar ik vind dat onterecht, ik zie niet in waarom het in dit geval onfatsoenlijk zou zijn.

[robbert]

Even om terug te komen, we hebben een template klasse welke we eenmalig willen initialiseren. Het is niet een of andere ding wat we op meerdere plekken gaan initialiseren. Waarom zou je voor zo'n geval je die klasse gaan overerven en properties (dan wel door publieke velden te veranderen, danwel met setters) in gaan stellen? Dit biedt echt totaal geen meerwaarde en maakt je code echt totaal niet netter nog beter onderhoudbaar. Het is een andere mogelijkheid.

Het wordt echter totaal anders als je de klasse op meerdere verschillende plaatsen wil gebruiken, dan is het natuurlijk wel handiger ivm met hergebruik.

[ Voor 8% gewijzigd door robbert op 20-08-2008 17:09 ]

[Gomez12]

Patriot schreef op woensdag 20 augustus 2008 @ 16:15:
[...]
Over het algemeen gebruik je één instantie van Smarty. Ook gebruik je vaak maar één set van settings. Mocht je van één van de twee nou meerdere gebruiken, dan zijn er zeker betere opties dan het instellen, maar in dat geval komt er al meer logica bij te kijken, en dan is het logisch om een nieuwe klasse te maken.

Ja, als jij het leuk vindt om als er 1 extra feature bij moet komen een gedeelte van je bestaande app te moeten rewriten en opnieuw te testen be my guest.
Persoonlijk werk ik liever vooruitdenkend, als er een redelijke kans is dat het in de toekomst logisch is om een nieuwe klasse te maken dan kan ik er beter vanuit het begin mee gaan werken, dan hoef ik later het minste te rewriten...

[...]
Er wordt gesproken over onfatsoenlijk programmeren maar ik vind dat onterecht, ik zie niet in waarom het in dit geval onfatsoenlijk zou zijn.

Omdat je om in 1e instantie 1/2 uur minder te proggen later het risico hebt om 4 uur extra te moeten proggen / debuggen, daarom is het onfatsoenlijk.
Hoeveel extra tijd kost het nou daadwerkelijk om het in 1x in een extended klasse te gooien?
En hoeveel tijd kost het om later een config bestand inclusief alle referenties etc om te bouwen naar een klasse?

robbert schreef op woensdag 20 augustus 2008 @ 17:07:
Even om terug te komen, we hebben een template klasse welke we eenmalig willen initialiseren. Het is niet een of andere ding wat we op meerdere plekken gaan initialiseren.

Waar haal jij dit uit als ik vragen mag? En als het nu al zo is, waar haal jij vandaan dat dit niet over 2 maanden gaat veranderen?

[ Voor 13% gewijzigd door Gomez12 op 20-08-2008 17:09 ]

[BartV]

Gomez12 schreef op woensdag 20 augustus 2008 @ 17:08:
[...]
Waar haal jij dit uit als ik vragen mag? En als het nu al zo is, waar haal jij vandaan dat dit niet over 2 maanden gaat veranderen?

Waarom zou je in een webapplicatie je Smarty template klasse vaker dan 1 keer willen instantiëren? Ooit, dus nu, of in de toekomst? Ik kan geen situatie bedenken.

[Gomez12]

Misschien omdat je bijv voor de rss-feed wel even de caching aan wilt zetten. Of je wilt voor een xml-output je stripwhitelines even uitzetten.
Imho initialiseer je je smarty inclusief je settings, andere settings andere initialisatie.

En soms kan het met een trage db-server makkelijker zijn om 1 db-aanroep te doen en dit te parsen naar 2 templates ( 1 voor de gebruiker, en 1 update voor de rss-feed template )

[robbert]

Gomez12 schreef op woensdag 20 augustus 2008 @ 18:27:
Misschien omdat je bijv voor de rss-feed wel even de caching aan wilt zetten. Of je wilt voor een xml-output je stripwhitelines even uitzetten.
Imho initialiseer je je smarty inclusief je settings, andere settings andere initialisatie.

En soms kan het met een trage db-server makkelijker zijn om 1 db-aanroep te doen en dit te parsen naar 2 templates ( 1 voor de gebruiker, en 1 update voor de rss-feed template )

Wil je hiermee zeggen dat je voor elke initialisatie een subklasse aan moet maken waarin je die andere settings instelt, of dat je gewoon per initialisatie de publieke velden aanpast (dan wel, waardes met behulp van setters aanpast in het geval dat zo zou gaan bij Smarty)?

[Gomez12]

Per settings-groep zou ik of een extended class maken of via get / setters de waardes veranderen inderdaad.
Mijn Smarty installs hebben niet per pagina andere instellingen, ik heb 3 of 4 standaard soorten settings en die gooi ik in klasses... Puur vanwege het feit dat bij die 3 of 4 settings ook de methodes in de toekomst kunnen gaan verschillen...

[DeluxZ]

Ik heb inmiddels mijn code omgegooid en niet alles met else gedaan maar gewoon per controle een aparte if en dan in een error-variable gezet. Als iemand de code wilt zien moet je het even zeggen

[Patriot]

Gomez12 schreef op woensdag 20 augustus 2008 @ 18:41:
Per settings-groep zou ik of een extended class maken of via get / setters de waardes veranderen inderdaad.

Mag je mij vertellen hoe dit verschilt van het aanpassen van de properties.

Verder zit er tussen het instellen op de properties en het maken van een nieuwe subklasse helemaal geen half uur extra werk, als je met één van de twee langer dan 10 minuten bezig bent doe je al iets fout. Ik vind het ook prima als jullie een subklasse aan willen maken voor dit soort dingen, maar doe alsjeblieft niet alsof het zo bespottelijk is als iemand anders daar niet voor kiest.

Zodra iemand de richtlijnen van OOP niet op het detail naleeft is het één en al ellende, de programmeur is een prutser die zich niet aan richtlijnen houdt, zijn code is onfatsoenlijk en vreselijk slecht onderhoudbaar. Gewoon een vreselijk arrogante houding en dat mag best wat minder.

[ Voor 0% gewijzigd door Patriot op 26-08-2008 01:31 . Reden: Woeps! PHP = OOP ]

[Gomez12]

Patriot schreef op dinsdag 26 augustus 2008 @ 00:44:
[...]
Mag je mij vertellen hoe dit verschilt van het aanpassen van de properties.

In 1e instantie niets, maar als smarty die property namen ( bijv ) veranderd dan merk je het verschil wel tussen enkele classes aanpassen of alle properties die je in al je bestanden gebruikt...

Zodra iemand de richtlijnen van PHP niet op het detail naleeft is het één en al ellende, de programmeur is een prutser die zich niet aan richtlijnen houdt, zijn code is onfatsoenlijk en vreselijk slecht onderhoudbaar. Gewoon een vreselijk arrogante houding en dat mag best wat minder.

Schitterende uitspraak.
Ik vind PHP juist een rotzooi taal omdat het juist geen richtlijnen heeft, het heeft geen structuur, het heeft amper logische documentatie. Zie maar eens een gemiddelde php-tutorial site, complete chaos scripts.
Die zogenaamde PHP-richtlijnen van jou zijn over het algemeen overgenomen van andere talen waar mensen door ervaring geleerd hebben dat dit handig werkt, ja ze veroorzaken overhead, ja ze vereisen meer progwerk maar je bent er over het algemeen maar wat blij mee als jij code van iemand anders krijgt of je eigen code na 6 maanden opeens opnieuw moet bekijken...

Kijk voor een 200-regelig php-script wat 2 weken moet werken maakt het geen barst uit ( maar waarom gebruik je dan een template engine en gooi je je php-code niet gewoon tussen je html ).
Maar wil jij iets serieus gaan bouwen waar je over langere tijd nog eens naar wilt kijken met meerdere mensen dan zijn die richtlijnen over het algemeen handig...

[Patriot]

Gomez12 schreef op dinsdag 26 augustus 2008 @ 01:06:
Schitterende uitspraak.
Ik vind PHP juist een rotzooi taal omdat het juist geen richtlijnen heeft, het heeft geen structuur, het heeft amper logische documentatie. Zie maar eens een gemiddelde php-tutorial site, complete chaos scripts.
Die zogenaamde PHP-richtlijnen van jou zijn over het algemeen overgenomen van andere talen waar mensen door ervaring geleerd hebben dat dit handig werkt, ja ze veroorzaken overhead, ja ze vereisen meer progwerk maar je bent er over het algemeen maar wat blij mee als jij code van iemand anders krijgt of je eigen code na 6 maanden opeens opnieuw moet bekijken...

Kijk voor een 200-regelig php-script wat 2 weken moet werken maakt het geen barst uit ( maar waarom gebruik je dan een template engine en gooi je je php-code niet gewoon tussen je html ).
Maar wil jij iets serieus gaan bouwen waar je over langere tijd nog eens naar wilt kijken met meerdere mensen dan zijn die richtlijnen over het algemeen handig...

In plaats van PHP moest daar OOP staan, even voor de duidelijkheid. Waar die richtlijnen voor zijn snap ik zelf ook wel hoor, maar het kan heel goed een bewuste keuze zijn om zo af en toe van de richtlijnen af te wijken. Als dit duidelijk is dan moeten hier geen problemen door ontstaan. Op dit moment vind ik het handiger om die instellingen in het globale configuratiebestand te zetten, zo is dat in mijn opzet gewoon het makkelijkst. Zo heb ik het ook gedocumenteerd, dus als iemand die instellingen wil wijzigen weet hij/zij waar het gevonden kan worden. Mocht er ooit een moment komen waarop ik op grote schaal verschillende configuraties van Smarty nodig heb dan is het een triviaal werkje om de enkele instellingen die in het configuratiebestand staan over te zetten naar een eigen subklasse.

Hier is het onmiddelijk onfatsoenlijk en slecht onderhoudbaar, dat betwijfel ik en ik vind het vreemd dat deze conclusies zo snel worden getrokken.

[Anoniem: 26306]

En toen ging je ineens een andere template engine gebruiken...

Sowieso kun je meerdere template engines hebben, namelijk Smarty en gewoon PHP code. In zo'n geval kun je een interface schrijven die beide klassen implementeren, en op die manier weet je al zeker dat je niet al te veel hoeft te wijzigen zolang je interface niet verandert.

Nu mag je natuurlijk gaan roepen dat het schrijven van een interface al helemáál overbodig is, maar dat kenmerkt nou het verschil tussen iemand met ervaring en inzicht, en iemand die denkt dat een paar minuten verspilde tijd is.

Patriot schreef op dinsdag 26 augustus 2008 @ 00:44:

Zodra iemand de richtlijnen van OOP niet op het detail naleeft is het één en al ellende, de programmeur is een prutser die zich niet aan richtlijnen houdt, zijn code is onfatsoenlijk en vreselijk slecht onderhoudbaar. Gewoon een vreselijk arrogante houding en dat mag best wat minder.

Beter dan de vreselijk naïeve houding om niet naar die arrogante mensen met ervaring te luisteren. Dit zou echt een goede vraagstelling voor een sollicitatiegesprek zijn.

[Patriot]

Anoniem: 26306 schreef op dinsdag 26 augustus 2008 @ 19:23:
En toen ging je ineens een andere template engine gebruiken...

Dergelijke veranderingen brengen altijd werk met zich mee, dat is bij jouw oplossing niet anders dan bij de mijne.

Sowieso kun je meerdere template engines hebben, namelijk Smarty en gewoon PHP code. In zo'n geval kun je een interface schrijven die beide klassen implementeren, en op die manier weet je al zeker dat je niet al te veel hoeft te wijzigen zolang je interface niet verandert.

Klopt

Nu mag je natuurlijk gaan roepen dat het schrijven van een interface al helemáál overbodig is, maar dat kenmerkt nou het verschil tussen iemand met ervaring en inzicht, en iemand die denkt dat een paar minuten verspilde tijd is.

Lekker bezig.

[...]

Beter dan de vreselijk naïeve houding om niet naar die arrogante mensen met ervaring te luisteren. Dit zou echt een goede vraagstelling voor een sollicitatiegesprek zijn.

Niet luisteren . Ik weet echt werkelijk waar niet waar je het vandaan haalt. Ik ben het gewoon niet met je eens dat het in dit specifieke geval zo vreselijk is om het te doen op de manier die volgens jou zo vreselijk slecht is.

Ik vind het gewoon geen probleem om iets af te wijken van de richtlijn als dat resulteert in een voor mij makkelijker onderhoudbare code. Als zo'n afwijking gewoon goed gedocumenteerd wordt (wat zo is in mijn geval) voor mijzelf en collega's, wat is daar dan mis mee? Zo'n richtlijn is ook alleen maar ontwikkeld om samenwerking en overname van code makkelijker te maken, en tegelijkertijd een aantal good practices aan de man te brengen. Geef me eens een goede reden om het anders te doen?