[PHP] Titels in HTML

[chronoz]

Mijn website gebruikt overal een header.inc.php en een footer.inc.php voor het includen van de website lay-out. Hierin worden enkele functies gedeclareerd, de database verbinding opgezet en de bovenkant van de lay-out van de website meegegeven (header.tpl).

Echter nu zit ik met een probleem. Ik wil graag gebruik gaan maken van unieke pagina titels over de gehele website op basis van database informatie. Indien ik dit onderaan zou kunnen zetten, zou het erg makkelijk worden.

Ik vraag me af of ik nu overal in 50 php-pagina's ervoor moet zorgen dat de SQL query bovenaan komt? De unieke titels in dit voorbeeld moeten zijn. Je kunt nu zien op http://www.visilang.com/quiz.php?qid=1 dat ik in 1 van de includes de titel heb laten zetten op basis van $_SERVER[PHP_SELF], maar dat zal nooit een succes worden en op die manier kan ik geen data uit de database halen zoals taal-namen, chapter-namen, quiz-namen, e.d.

code:

Visilang.com - List of German chapters
Visilang.com - Quiz - Guess the Language

code:

<?php
include "includes/header.inc.php";

echo "<h2>List of chapters</h2><p><br><ul>";

$q_select = "SELECT DISTINCT(cid) FROM questions WHERE `iso`='$_GET[lang_id]' ORDER BY cid asc";
$q_query = mysql_query($q_select)or die(mysql_error());

while($q_toon = mysql_fetch_assoc($q_query)) {
  $cid = $q_toon[cid];
  $c_select = "SELECT * FROM chapters WHERE `cid`= '$cid' AND `iso`='$_GET[lang_id]' ";
  //echo $c_select;
  $c_query = mysql_query($c_select)or die(mysql_error());
  $c_toon = mysql_fetch_assoc($c_query);
  echo "<li><h3><a href=image_view.php?cid=".$c_toon['cid']."&lang=".$c_toon[iso]."&runtime=1>".$c_toon['native']."</a></h3></li>";
}

echo "</ul></p>";
?>
<?php
include "includes/footer.inc.php";
?>

Hoe zou ik dat hier het beste kunnen doen? Gewoon bovenaan elke header.inc.php een SQL-query in gebruik nemen die $titel zet? Die vervolgens in header.inc.php als titel gebruikt wordt?

Ik weet wel een manier om het te realiseren, dat is dus elke pagina aanpassen en indien mogelijk de SQL query omhoog plaatsen. En anders gewoon een extra query neerzetten en boven header.inc.php een titel programmeren. Het zou makkelijk zijn als $titel bepaald kon worden in het midden van het bestand, dus na header.inc.php.

Heb dit weekend best veel (3 uur) programmeerwerk overnieuw moeten doen vanwege inefficiënt design van de MySQL database, wil deze site gewoon goed aanpakken en wat bijleren tijdens het proces. Zit er bijvoorbeeld aan te denken om SmartyTemplate te gebruiken of een framework, al wordt het eerste me door veel PHP-fanatiekelingen afgeraden en het laatste heb ik weinig over gehoord. Wil ook niet te veel vast zitten aan een lastig opzetbare webserver installatie voor mijn site.

[Niemand_Anders]

Waarom maakt je niet een functie welke de head(er) genereert. Aan die functie zou je dan een $title argument kunnen meegeven. En zo kun je op elke pagina de titel zelf bepalen..

[HuHu]

Kun je in header.inc.php niet bepalen op welke pagina je zit en dan daar eenmaal de query uitschrijven?

[CH4OS]

SQL:

SELECT DISTINCT(cid) FROM questions WHERE `iso`='$_GET[lang_id]' ORDER BY cid asc;

$_ variabelen niet klakkeloos in je query zetten, maar eerst controleren of het is wat je verwacht. Dan voorkom je daar SQL Injection mee. Ik weet dat het niet met jouw topic te maken heeft, maar is zeker wel een belangrijk aandachtspuntje dacht ik zo.

[ Voor 3% gewijzigd door CH4OS op 12-11-2010 12:49 ]

[NMe]

HuHu schreef op vrijdag 12 november 2010 @ 12:48:
Kun je in header.inc.php niet bepalen op welke pagina je zit en dan daar eenmaal de query uitschrijven?

Kost in dit brakke ontwerp een extra query. Dit is nou precies de reden waarom je logica en presentatie gescheiden hoort te houden. Als je eerst data verzamelt en dan pas begint met uitvoer heb je ook in de header al alle data beschikbaar. In het huidige ontwerp kan de topicstarter maar beter zorgen dat hij genoeg duct tape heeft om het zaakje bij elkaar te houden.

edit:

Gezien het feit dat je $_SERVER[PHP_SELF] schrijft: zet tijdens het testen eens heel snel error_reporting(E_ALL); bovenaan in je script of in een include die je altijd gebruikt...

[ Voor 14% gewijzigd door NMe op 12-11-2010 12:58 ]

[chronoz]

Niemand_Anders schreef op vrijdag 12 november 2010 @ 12:32:
Waarom maakt je niet een functie welke de head(er) genereert. Aan die functie zou je dan een $title argument kunnen meegeven. En zo kun je op elke pagina de titel zelf bepalen..

Ja, maar dat heeft geen voordeel. Omdat ik dan alsnog mijn hele code moet omgooien. Daarbij werk ik al op die manier.

code:

<?php
$i = $_SERVER['PHP_SELF'];

switch ($i) {
    case "/quiz.php":
        echo "Visilang - Quiz";
        break;
    case "/aboutus.php":
        echo "Visilang - About us";
        break;
    case "/contact.php":
        echo "Visilang - Contact us";
        break;
    default:
        echo "Visilang - Where languages are learned";
}
?>

Maar op deze manier kan ik geen database informatie ophalen, tenzij ik de cases uitgebreid ga maken, maar het lijkt me verstandiger om dan de $titel om te bouwen boven de header.inc.php.

HuHu schreef op vrijdag 12 november 2010 @ 12:48:
Kun je in header.inc.php niet bepalen op welke pagina je zit en dan daar eenmaal de query uitschrijven?

Zie mijn post hierboven. Elke .php is gewoon een apart fysiek bestand, de templates worden ge-include. Het werkt niet zoals bij veel SEO-optimized pagina's met .htaccess die /quiz.html toont voor bijvoorbeeld ?page_id=32311 die zo via back-end als quiz is ingesteld.

CptChaos schreef op vrijdag 12 november 2010 @ 12:48:

SQL:

SELECT DISTINCT(cid) FROM questions WHERE `iso`='$_GET[lang_id]' ORDER BY cid asc;

$_ variabelen niet klakkeloos in je query zetten, maar eerst controleren of het is wat je verwacht. Dan voorkom je daar SQL Injection mee. Ik weet dat het niet met jouw topic te maken heeft, maar is zeker wel een belangrijk aandachtspuntje dacht ik zo.

Je hebt gelijk, ik moet eens uitzoeken wat voor checks belangrijk zijn. Door het gebruik maken van '' dacht ik sowieso de DROP database; te kunnen voorkomen?

Ik ga denk ik gewoon voor extra programmeerwerk los van de huidige programmeercode en gewoon boven include header.inc.php de titel maar bepalen via SQL queries op basis van de meegegeven parameters. Indien ik gebruik van een systeem als SmartyTemplate maakte, had ik nog op de laatste regel of boven of onder de while-lus makkelijk de titel kunnen instellen, omdat render(); pas aan einde gedaan wordt.

[NMe]

chronoz schreef op vrijdag 12 november 2010 @ 12:57:
[...]
Ja, maar dat heeft geen voordeel. Omdat ik dan alsnog mijn hele code moet omgooien.

met .htaccess die /quiz.html toont voor bijvoorbeeld ?page_id=32311 die zo via back-end als quiz is ingesteld.

Dat zul je toch moeten als je niet keer op keer weer dit soort problemen wil tegenkomen.

[ReenL]

1) HTML uit je header.inc.php halen;
2) Aan je header.inc.php ob_start(); toevoegen;
3) In je footer.inc.php begin je met:

PHP:

$content = ob_get_contents();
ob_end_clean();

4) De content wordt nu gebuffered in variable $content en dus niet uitgeprint;
5) Voeg de header html toe
6) print $content;
7) Voeg de footer html toe.

Nu kun je in je pagina zeggen $title = 'This is a test title.'; Of eventueel met een query.

Die variable kan je dan in footer.inc.php gebruiken.

Denk dat je op deze manier het minst hoeft te refactoren. Zou toch eens naar frameworks gaan kijken als ik jou was.

[Miyamoto]

NMe schreef op vrijdag 12 november 2010 @ 12:55:
Kost in dit brakke ontwerp een extra query.

Wat een onzin dat (bijv.) een MVC architectuur de heilige graal is. Voor een relatief klein project is dat een veel te grote overkill. Natuurlijk gebruik je dat als je er helemaal in thuis bent en dat dus peanuts is om ook te gebruiken voor een kleiner project, maar om dit nou aan te bevelen en daarmee alle andere opties af te doen als duct-tape oplossingen?

Is het haalbaar om de database verbinding in een apart bestand te gooien? Dan kun je de benodigde informatie voor de titels altijd ophalen. Wat je zelf ook voorstelt, dat je de query gewoon omhoog zet.

PHP:

<?php
require_once 'database-verbinding.php';
require_once 'functies-classes-en-andere-benodigdheden-voor-ophalen-info.php';

$_title = 'Maak hier de titel, al dan niet met informatie uit de database';
require_once 'header.php';

//content
//etc
?>

[DrFlash]

Zit er bijvoorbeeld aan te denken om SmartyTemplate te gebruiken of een framework, al wordt het eerste me door veel PHP-fanatiekelingen afgeraden en het laatste heb ik weinig over gehoord. Wil ook niet te veel vast zitten aan een lastig opzetbare webserver installatie voor mijn site.

Hebben ze ook een reden gegeven om smarty af te raden ? Ik vind het namelijk een nogal geweldig product, en zou het iedereen aanraden zoiets te gebruiken. (Kan natuurlijk elke template engine zijn waar je je goed bij voelt)

[ Voor 92% gewijzigd door DrFlash op 12-11-2010 15:18 ]

[Miyamoto]

DrFlash schreef op vrijdag 12 november 2010 @ 15:10:
Hebben ze ook een reden gegeven om smarty af te raden ?

http://nosmarty.net

Maar het hangt natuurlijk van je eisen, wensen, voorkeuren en project af.

[Cartman!]

Discussie over Smarty/template-engines die laatst gevoerd is hier: [PHP] Hoe templates maken?

[NMe]

Miyamoto schreef op vrijdag 12 november 2010 @ 15:05:
[...]

Wat een onzin dat (bijv.) een MVC architectuur de heilige graal is. Voor een relatief klein project is dat een veel te grote overkill. Natuurlijk gebruik je dat als je er helemaal in thuis bent en dat dus peanuts is om ook te gebruiken voor een kleiner project, maar om dit nou aan te bevelen en daarmee alle andere opties af te doen als duct-tape oplossingen?

Ik zeg nergens dat MVC een heilige graal is maar het is wel tientallen keren beter dan wat ik hier van de topicstarter zie. Vergeleken met een goede MVC-implementatie hangt dit ontwerp aantoonbaar met ducttape aan elkaar.

Maar goed, als je het met me oneens bent: hoe zou jij dan op een logische en doorzichtige manier zorgen dat de data die je pas na de header verzamelt beschikbaar wordt in de header? Output buffering is geen oplossing, IMO. Dat is een zwaktebod, geen fix.

Miyamoto schreef op vrijdag 12 november 2010 @ 15:19:
[...]

http://nosmarty.net

Daar lees ik eigenlijk vooral meningen en maar weinig feiten. De syntax van Smarty is soms wat vaag maar sommige dingen gaan er toch echt makkelijker in dan wanneer je PHP als templating engine gebruikt. Andersom geldt trouwens precies hetzelfde.

[ReenL]

NMe schreef op zaterdag 13 november 2010 @ 00:22:
[...]
Output buffering is geen oplossing, IMO. Dat is een zwaktebod, geen fix.
[...]

Wat is er mis met output bufferen? Enig idee hoe zend_layout werkt? Misschien niet met ob_* functies maar hij rendert eerst je view, die stopt hij in de content variable om vervolgens de layout te renderen.

Daarnaast is het de enige methode die ik kan bedenken zonder dat hij de totale (ducttape-)applicatie opnieuw moet schrijven. Een luxe die niet iedereen heeft.

[HuHu]

ReenL schreef op zaterdag 13 november 2010 @ 10:21:
[...]


Wat is er mis met output bufferen? Enig idee hoe zend_layout werkt? Misschien niet met ob_* functies maar hij rendert eerst je view, die stopt hij in de content variable om vervolgens de layout te renderen.

Daarnaast is het de enige methode die ik kan bedenken zonder dat hij de totale (ducttape-)applicatie opnieuw moet schrijven. Een luxe die niet iedereen heeft.

Zend_Layout gebruikt inderdaad de ob_* functies van PHP.

[NMe]

ReenL schreef op zaterdag 13 november 2010 @ 10:21:
[...]


Wat is er mis met output bufferen? Enig idee hoe zend_layout werkt? Misschien niet met ob_* functies maar hij rendert eerst je view, die stopt hij in de content variable om vervolgens de layout te renderen.

En dat is overzichtelijk wou je zeggen? Zend heeft wel meer gekke dingen gedaan, de huidige Zend Studio als paradepaardje bovenaan op de lijst van hoe het niet moet. Als je afhankelijk wordt van output buffering nodigt dat alleen maar uit om letterlijk alles door elkaar te zetten.

Bovendien lost het niet zomaar het probleem hier op. Ook als je OB aan zet is alles als je het in deze volgorde laat staan nog steeds niet goed, dus de code-volgorde moet hoe dan ook aangepast worden.

Daarnaast is het de enige methode die ik kan bedenken zonder dat hij de totale (ducttape-)applicatie opnieuw moet schrijven. Een luxe die niet iedereen heeft.

Nee, een luxe die niet iedereen wíl hebben. Meestal kan het wel maar heeft de programmeur er geen zin in.

[ReenL]

En dat is overzichtelijk wou je zeggen? Zend heeft wel meer gekke dingen gedaan, de huidige Zend Studio als paradepaardje bovenaan op de lijst van hoe het niet moet. Als je afhankelijk wordt van output buffering nodigt dat alleen maar uit om letterlijk alles door elkaar te zetten.

Of het overzichtelijk is blijft een mening, maar als een gerespecteerd framework als Zend het gebruikt, betekent het in elk geval dat het niet een onbeargumenteerd "zwaktebod" is.

Ik ben ook van mening dat Eclipse (en dus Zend Studio) de verkeerde kant op is gegaan, echter hebben de developers van het framework daar weinig mee te maken.

Bovendien lost het niet zomaar het probleem hier op. Ook als je OB aan zet is alles als je het in deze volgorde laat staan nog steeds niet goed, dus de code-volgorde moet hoe dan ook aangepast worden.

Alle pagina's kunnen met mijn voorbeeld blijven bestaan in hun huidige vorm alleen de header en de footer moeten inderdaad aangepast worden. Dit is aanzienlijk minder werk bij 5+ pagina's dan de hele structuur aanpassen.

Als dit niet duidelijk is/was dan wil ik graag een uitgebreider voorbeeld posten.

Nee, een luxe die niet iedereen wíl hebben. Meestal kan het wel maar heeft de programmeur er geen zin in.

Dat is niet mijn ervaring.

[SvMp]

De beste manier is m.i. de output pas helemaal aan het eind doen. Dan kun je de titel ophalen wanneer dit het meest handig is en ergens opslaan.

Sterk vereenvoudigd voorbeeld:

PHP:

         $strTitel='Mijn website';
         if (!empty($this->strTitel)) $strTitel.=' - ' . $this->strTitel;

         echo <<<EOT
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>{$strTitel}</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <link rel="stylesheet" href="stylesheet.css" type="text/css" />
  </head>
  <body>
    <div id="header">
      <div id="titelkader">Titel</div>
    </div>
    <div id="minHeight"></div>
    <div id="outer">
      <div id="inner">
        <div id="menu">
{$strMenubalk}        </div>
        <div id="inhoud">
{$strInhoud}        </div>
      </div> <!-- end inner div -->
      <div id="clearfooter"></div> <!-- to clear footer -->
    </div> <!-- end outer div -->
    <div id="footer">{$strFooter}
    </div>
  </body>
</html>
EOT;

[kwaakvaak_v2]

Ik zou eerst eens op papier je applicatie uitwerken, beschrijven wat je nu precies waar verwacht qua functionaliteit en dan pas gaan bouwen. Dit is en blijft on-doorzichtelijke spaghetti code als je op deze manier dingen er aan blijft plakken..


Oh @rooot, MVC betekend niet dat je automagisch hele zware dingen gaat krijgen, of dat je gelijk cake/zendframe/symfony of wat dan ook moet installeren. Je kunt ook zelf heel makkelijk in 20 regels een controller schrijven die wat dingen voor je regelt. Voorkomt ook dat als je nieuwe functie wilt maken, je dezelfde php code keer op keer herhaalt. Never repeat yourself principe.

En smarty.. tja daar kun je hele topics over vol lullen, persoonlijk ben ik van mening dat smarty een mooie lib was in de php4 tijd. Maar nu zie ik zelf veel meer in een systeem als twig en gebruik deze ook zelf in verschillende omgevingen waaronder ook drupal, maar ook voor lichtgewicht simpele MVC dingetjes. Gewoon omdat het een stukje leesbaarheid en onderhoudbaarheid introduceert in mijn code, zonder gelijk een hele caching laag van smarty erbij te krijgen.

[ameesters]

De syntax van Smarty is soms wat vaag maar sommige dingen gaan er toch echt makkelijker in dan wanneer je PHP als templating engine gebruikt.

Smarty gebruikt php om templates te renderen. Ik zie dit als een on-nodige abstractie laag, aangezien php in de basis al uitermate geschikt is om met html bestanden te werken.

PHP Hypertext Preprocessor <- de afkorting zegt het al, het voor bewerken van Hypertext(html = HyperText Markup Language).

Veel mensen denken dat het meer is dan dat, maar dat is het niet.

Ontopic:

code:

<?php
require("database_connect.php");

$title = 'taart';
$meta_keywords = 'taart, slagroom, deeg';
$meta_desc = 'Ik ben een lekkere taart aan het bakken';

include("header.php");

// meer code hier:

include("footer.php");

?>

is een opzet die naar wens zal werken en prima volstaat voor wat jij er mee wilt bereiken. Een framwork en/of templating engine zou ikzelf niet zo snel naar grijpen. met de tijd heb ik wel een flinke verzameling classes geschreven die ik in mijn projecten hergebruik, zo hoefde ik het wiel maar 1 keer opnieuw uit te vinden

[SvMp]

Ter aanvulling op de bovenstaande twee replies:

Uit ervaring weet ik hoe belangrijk het is om te beginnen met het ontwerpen van een "skelet", of framework, zoals je het noemen wil. Maak heldere keuzes waar je applicatie de beslissingen, waar de output wordt geregeld, welke soort objecten er zijn, waar ze staan, etc..

Pas de laatste jaren ben ik object georienteerd gaan programmeren. Een hobbyproject waar ik al jaren mee bezig ben heb ik helemaal moeten herschrijven. Het ontwerp is geheel gericht op functioneel programmeren, met veel globals en includes. Een puinzooi. In eerste instantie verder gegaan, objectgeoriënteerd, maar met een fout ontwerp lukt dat simpelweg niet. Dit geldt zelfs voor eenvoudige websites.

Een framework gebruiken hoeft niet, kan wel. Je inlezen in MVC kan interessant zijn, is wel lastig icm. PHP. Mocht je nog beginner zijn, hou het dan vooral simpel maar wel effectief.

Voorbeeld van aanpak:
.htaccess zet 'mooie' URL's om naar index.php?page=...

index.php:
1. Objecten aanmaken van algemeen gebruikte classes bijvoorbeeld toegang tot database
2. Page laden:

PHP:

         if (empty($_GET['page'])) $page=''; else $page=$_GET['page'];
         switch($page) {

         case 'members':
            $objMain=new cMembers();
            break;

         case 'support':
            $objMain=new cSupport();
            break;

         case 'admin':
            $objMain=new cAdmin();
            break;

         default:
            $objMain=new cHome();
            break;

         } // End switch($page)

3. Uitvoer $uitvoerMain=$objMain->start(), zie verder mijn vorige reply.

Heel simpel voorbeeld, het gaat er om dat je structureert. Wat in de startpost gebeurt, lijkt daar niet op. Het gebruik van includes zoals daar plaatsvindt, vind ik not-done, maar daar kan verschillend over gedacht worden. Ik hanteer de regel dat ik uitsluitend include (require) gebruik om classes in te lezen. Structureer je niet, dan krijg je dat keihard terug. Ik doe het zelfs met de kleinste projectjes.

[ Voor 10% gewijzigd door SvMp op 16-11-2010 11:42 ]

[Woy]

leipepo schreef op dinsdag 16 november 2010 @ 11:30:
[...]

code:

<?php
require("database_connect.php");

$title = 'taart';
$meta_keywords = 'taart, slagroom, deeg';
$meta_desc = 'Ik ben een lekkere taart aan het bakken';

include("header.php");

// meer code hier:

include("footer.php");

?>

is een opzet die naar wens zal werken en prima volstaat voor wat jij er mee wilt bereiken. Een framwork en/of templating engine zou ikzelf niet zo snel naar grijpen. met de tijd heb ik wel een flinke verzameling classes geschreven die ik in mijn projecten hergebruik, zo hoefde ik het wiel maar 1 keer opnieuw uit te vinden

Inderdaad, alle frameworks zijn leuk en handig, maar voor simpele dingen misschien wat overkill.

Het belangrijkste is gewoon dat je eerst al je data ophaalt, en daarna pas begint met renderen van je pagina. Dat maakt het een stuk overzichtelijker, en dwingt je ook om goed na te denken over wat je nou precies op je pagina wil laten zien.

[kwaakvaak_v2]

switch kan ook, al vind ik het persoonlijk fraaier om het in één keer met methods te doen

Als voorbeeld, dit zou je index.php kunnen zijn, met de .htaccess zoals die in de code staat. Alles wat geen fysieke file in de root is, of niet niet in /css /images of /javascript staat wordt naar de index.php gestuurd.

Nieuwe pagina aanmaken? Geen probleem, gewoon nieuwe functie maken. En aangezien het in een class staat kun je het vrij makkelijk uitbreiden door de class te extenden mocht dat nodig zijn.

PHP:

<?php
/* very very very basic controller */

/* .htaccess 

    RewriteEngine On
    RewriteCond %{REQUEST_URI} !/(css|images|javascript)
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d

    RewriteRule ^(.*)$ index.php?action=$1 [L]

*/

$controller = new verySimpleController();

class verySimpleController {
    private static $action;
    private static $params;  

 public function __construct(){
      $urlChunks = explode("/",$_GET['action']);
      $this->action = 'action_'.$urlChunks[0];
      unset($urlChunks[0]);
      $this->params = $urlChunks;
        if (method_exists($this, $this->action)) {
            call_user_func(array($this,$this->action));
        } else {
            // toon 404 of doe iets anders spannends ;)
        }
   }

    private function action_members(){
       // Member pagina logica  
    }

    private function action_support(){
       // support pagina logica 
    }
}
?>

Disclaimer, ik weet dat het direct gebruik van $_GET niet verstandig is, maar het ging mij hier om het voorbeeld. Uiteraard moet je netjes je input controleren

[NMe]

Niet lullig bedoeld richting de topicstarter, maar hoe realistisch en handig is het om naar relatief complexe OO-oplossingen te verwijzen bij een topicstarter die logica en lay-out niet gescheiden houdt en die bijvoorbeeld nog nooit van SQL-injection en HTML entities gehoord heeft? Laat hem eerste even leren lopen voordat je hem inschrijft voor de marathon.

[chronoz]

In de eerste instantie had ik besloten om me te verdiepen in Smarty en CakePHP. Na goed nadenken zat ik ook aan Django en Ruby-on-Rails te denken, maar ben hier op terug gekomen, omdat deze leercurve (nieuwe programmeertaal, MVC framework) misschien iets te stijl zou zijn. Verder zal ik op korte termijn (< 1maand) Visilang nog niet omzetten, hierna zal ik alles herbouwen op basis van CakePHP.

Het klopt inderdaad dat het gebruik maken van Smarty en CakePHP me niet dit probleem zou leveren, gezien de voordelen van scheiden code & design. Echter heb ik in mijn ogen enorm veel geprogrammeerd in korte tijd. Het is me te veel werk om alle SQL-data van de <body> naar bovenaan te halen, mijn design is daar inderdaad ook te inefficient voor. Heb verder over het algemeen nog weinig te klagen gehad en sites gemaakt met 10.000 bezoekers per dag die goed en succesvol draaiden. Ik zal proberen om met ob_start() en ob_end(); alsnog gebruik te kunnen maken van custom titels en niet meteen totaal willen overstappen. SQL-Injectie ken ik ook heus, script al sinds 1999. Heb alleen afgelopen drie jaar weinig meer aan webdevelopment gedaan. Dat de site met 'ductape' in elkaar zit ben ik het ook niet mee eens. De site schiet al enorm op, bestaat nog maar 1 week en is al enorm uitgebreid. Heb verder ook jaar programmeerervaring in C++ en Java, dus er moeten echt niet te veel conclusies getrokken worden over mij als programmeer op dit korte stuk code. Heb dit weekend gespeeld met Smarty, werkt goed en merk duidelijk de voordelen, maar wil direct naar CakePHP.

Maar het wordt inderdaad tijd om de volgende stap te nemen naar succesvol programmeren in combinatie met CakePHP. De keuze om over te gaan om CakePHP is ook vooral gebaseerd op het feit dat ik me verder wil ontwikkelen en betere code wil schrijven en ook zoveel mogelijk code van design wil gaan scheiden. Ik zie al zeker de voordelen van CakePHP en Smarty. Smarty lijkt alleen zijn zijn eigen PHP-code te hebben, waar ik mijn twijfels over heb. CakePHP moet ik nog goed leren kennen, ben benieuwd of het ook voor kleine sites een pagina's met eenvoudige functies makkelijker is.

Zal nog maandje door gaan op deze manier en extra functies blijven inbouwen. Na maand programmeerervaring met CakePHP zal ik de stap zetten om alles over te zetten. Ben wel bang gelimiteerd te zijn door beperkte CakePHP ervaring dan nog en gefrustreerd te zijn als ik bepaalde dingen regelmatig niet in CakePHP weet voor elkaar te krijgen i.t.t. met pure PHP. Heb inmiddels al een hoop documentatie-links in mijn bookmarks.

[NMe]

Ik zou juist niet nog een maand doorgaan met op deze manier spul bouwen en dan overstappen naar CakePHP of whatever. Het is belangrijker dat je de grove fouten die je maakt uit je gewoontes gaat hameren en dat kun je eigenlijk alleen doen door een goed boek erbij te pakken. Pas als je de basis onder de knie hebt kun je echt gaan kijken naar andermans frameworks en daarmee goed wegkomen.

[kwaakvaak_v2]

bij het excuus dat je er nu geen zin en tijd meer in hebt haak ik af.. Als jij te bedonderd bent om je code fatsoenlijk te maken, vind ik dat je ook niet mag verwachten dat andere serieus wat tijd in jouw leerproces gaan stoppen.

En dat je sites 10.000 bezoekers per maand hebben, zegt helemaal niks! Ja dat je blijkbaar iets leuks bedacht hebt, maar het zegt niets over de onderhoudbaarheid, schaalbaarheid etc van je code. (en 10K bezoekers is echt niet zo heel spannend als je het hier doet overkomen.)

Wat ik alleen niet snap is, dat je opschept over dat je ook dingen met java gedaan hebt, maar dan nog zo'n rammelend stukje code wegzet en je dan omgeeft met allerlei tut-smoesjes..

Succes met je projecten, maar je gaat op mijn negeer-lijst..

[chronoz]

De SQL betreft een privé gedeelte van de site, dus het risico op SQL injectie is hier niet zo groot. Verder zie ik niet waarom ik de development van een website zou pauseren, omdat het design ineffectief is. Mijn code is inderdaad minder makkelijker te begrijpen zijn voor anderen, maar ik begrijp het zelf perfect, dus ik zie meer nadeel in een haastige overstap naar CakePHP, waar ik nauwelijks mee bekend ben en lijkt me dat juist nadelig voor de programmeertijd.

Vind de houding van sommige reageerders ook vrij aggressief en vol met conclusies op basis van korte code. Ik vind dat er best goede punten zijn gemaakt, maar vind het wat makkelijker om alles af te keuren dat niet gebruik maakt van totale scheiding tussen design & code of dat geen gebruik maakt van MVC.

Wilde ook totaal niet opscheppen, maar de insinituaties corrigeren dat ik geen OOP ervaring zou hebben en design slechts rechtzetten. Ik zie dat mensen mijn houding totaal niet waarderen, dus wil bij deze alle mensen die hebben gereageerd bedanken. Jullie zijn mede verantwoordelijk voor mijn keuze om de overstap te maken naar programmeren in het MVC-model.

[NMe]

chronoz schreef op dinsdag 16 november 2010 @ 14:10:
De SQL betreft een privé gedeelte van de site, dus het risico op SQL injectie is hier niet zo groot.

Dat argument krijg ik elke keer weer te horen van mensen die SQL-injectielekken in hun site hebben zitten maar het is een non-argument. Als je het hier zonder nadenken doet, dan kan dat zomaar ook gebeuren in een niet afgeschermd deel van de site. En dan heb ik het nog niet over mensen die je vertrouwt en dat vertrouwen beschaden...of zelfs mensen die het per ongeluk doen. SQL-inject moet niet mogelijk zijn, klaar.

Verder zie ik niet waarom ik de development van een website zou pauseren, omdat het design ineffectief is. Mijn code is inderdaad minder makkelijker te begrijpen zijn voor anderen, maar ik begrijp het zelf perfect, dus ik zie meer nadeel in een haastige overstap naar CakePHP, waar ik nauwelijks mee bekend ben en lijkt me dat juist nadelig voor de programmeertijd.

Het gaat er niet om dat het niet effectief is of dat anderen het niet kunnen lezen, al speelt dat wel mee (over 6 maanden weet jij ook niet meer hoe je code in elkaar zat...) Waar het wél om gaat is dat je gewoon lekken in je code hebt en dus enkele basale dingen blijkbaar niet weet. In plaats van gewoon stug vol te houden en door te gaan met je site lekprikken moet je dus eigenlijk gewoon wat tijd stoppen in het leren wat je fout doet en zorgen dat je dat niet meer doet bij de rest van wat je maakt, en vervolgens je oude code fixen. Van het probleem negeren gaat het niet weg.

[.oisyn]

ReenL schreef op zaterdag 13 november 2010 @ 10:21:
[...]


Wat is er mis met output bufferen? Enig idee hoe zend_layout werkt? Misschien niet met ob_* functies maar hij rendert eerst je view, die stopt hij in de content variable om vervolgens de layout te renderen.

Welk punt wil je hier eigenlijk mee maken? Zend gebruikt het, dús het is goed? Gezien de tendens van de lui achter Zend zou ik het eerder als counter-argument gebruiken eigenlijk

"Wat is er mis met je parameters van functies op een onlogische en incosistente manier ordenen? Enig idee hoe PHP werkt?"

Zie je, die redenatie werkt niet

Het gebruik van output buffering in deze situatie is imho een lapmiddel voor code waarbij de verantwoordelijkheden niet goed zijn ontworpen. Iets dat data uit je database trekt bijv. is niet verantwoordelijk voor het formatten van die data. Er komt een moment dat je die formatting aan wilt passen, dat wordt een ramp als dat soort formatting op tal van verschillende plekken wordt toegepast.

Dit betekent uiteraard niet dat output buffering nooit gewenst is. Wel dat het in dit specifieke geval imho geen goede keuze is. Beter pas je de code nú goed aan, dan dat je aan blijft modderen met een slecht design waarbij de onderhoudbaarheid steeds verder en verder degradeerd.

[ Voor 49% gewijzigd door .oisyn op 16-11-2010 14:35 ]

[SvMp]

Grote aantallen bezoekers staat geheel los van technische kwaliteit. Zo zijn er genoeg zeer succesvolle sites (zowel in bezoekers als keiharde euro's) waar ik technisch de nodige vraagtekens bij heb. Daar staat tegenover dat een technisch goed design geen enkele garantie biedt voor succes van een website. Als programmeur moet je echter imho geen rommel willen maken, ook niet als het slechts 'privé' is.

TS laat blijken wel ervaring in OOP te hebben. Dan is het een relatief kleine stap om je te verdiepen in het maken van een goed ontwerp.

chronoz schreef op dinsdag 16 november 2010 @ 14:10:
De SQL betreft een privé gedeelte van de site, dus het risico op SQL injectie is hier niet zo groot. Verder zie ik niet waarom ik de development van een website zou pauseren, omdat het design ineffectief is. Mijn code is inderdaad minder makkelijker te begrijpen zijn voor anderen, maar ik begrijp het zelf perfect, dus ik zie meer nadeel in een haastige overstap naar CakePHP, waar ik nauwelijks mee bekend ben en lijkt me dat juist nadelig voor de programmeertijd.

Begrijp je het over een jaar nog steeds? (als je de code er weer eens bijpakt om iets te veranderen)

Het gaat niet zozeer om de vraag hoeveel mensen er aan werken, maar om de mogelijkheid om code in de toekomst te wijzigen, uit te breiden of hergebruiken.

Ik heb dit zelf ervaren. Ik ben zelf vele avonden kwijt geweest om mijn project om te gooien, maar het betaalt zich uit in tijdbesparing in de toekomstige ontwikkeling.

Vind de houding van sommige reageerders ook vrij aggressief en vol met conclusies op basis van korte code. Ik vind dat er best goede punten zijn gemaakt, maar vind het wat makkelijker om alles af te keuren dat niet gebruik maakt van totale scheiding tussen design & code of dat geen gebruik maakt van MVC.

Ik heb nergens afkeurende reacties relezen over het niet gebruik maken van MVC. MVC is geen verplichting, maar een van de vele mogelijkheden. Design en code mixen is vragen om ellende, een klein stukje code is genoeg om dat te constateren.

[ Voor 60% gewijzigd door SvMp op 16-11-2010 14:37 ]