Code layout PHP site

[Thmz159]

Hallo,

Ik ben al een tijdje hobby-programmeur, en verdiep me er graag in. Nu wil ik een makkelijk onderhoudbare layout voor een site hebben. Ik werk met HTML, PHP, Javascript (met jquery). Nu zijn er heel veel mogelijkheden:
1: Elke pagina staat op zijn eigen: dus alles als head-tag, de content en de footer staat in hetzelfde bestand. Makkelijk om te volgen natuurlijk, ook makkelijk om aanpassingen te maken voor 1 bepaalde pagina.
Dan krijg je url's als: "localhost/index.php" of "localhost/registreer.php"

1b: Met frames werken: lijkt me al geen goede optie.

2: Een algemene index pagina maken en dan met "GET" zien welke pagina opgevraagd wordt en daar de content voor opvragen en tonen. Is moeilijker om dan bv een heel aparte "title" te maken, of bv iets in het menu te veranderen. Ook intensiever voor de server zou ik denken?
Krijg je urls als : "localhost/index.php?p=home" dus "localhost/?p=home" of "localhost/?p=registreer"

3: Hetzelfde als 2 maar dan met Mod Rewrite werken om mooiere urls te maken en "http://localhomst/home" of "http://localhost/registreer" te verkrijgen.

4: ?

Ik heb op google al zitten zoeken maar ben op niet veel uitgekomen. Methode 2 heb ik nu eens gebruikt maar ik vindt dat het echt rap rommelig begint te worden. Vol met if's om te checken op welke pagina je zit en om eventueel iets aan te passen aan de layout. Maar optie 1 zijn er weer veel herhalingen van algemene code.
Hoe wordt dit algemeen gedaan?

Groeten Thomas

[CodeCaster]

Mogelijkheid 2 en 3 in combinatie met een eenvoudige template engine kan ik aanbevelen.

[yade]

Is een MVC framework niet iets voor je?

http://www.mustap.com/php...top-10-php-mvc-frameworks

Anders kun je altijd zelfs iets maken wat hier op lijkt, maar waarom het wiel opnieuw uitvinden?

[Thmz159]

Is zo'n framework niet veel te groot voor kleinere projecten? Dat lijkt me al meer voor bv een echte bedrijfwebsite of iets. Ik ga me er nog eens in verdiepen.

Ook in template engine had ik me nog niet echt verdiept maar dit lijkt me wel makkelijk ,maar ook weer groot.

[Onbekend]

Thmz159 schreef op zondag 01 mei 2011 @ 12:51:
Methode 2 heb ik nu eens gebruikt maar ik vindt dat het echt rap rommelig begint te worden. Vol met if's om te checken op welke pagina je zit en om eventueel iets aan te passen aan de layout.

Je zou met je GET-waarde in een database kunnen kijken of die pagina echt beschikbaar is, en laat je hem de echte pagina-naam ophalen. Vervolgens include je gewoon de opgevraagde pagina.
Je zit dan altijd goed met relatieve verwijzingen naar css-files en afbeeldingen.

[Exception]

Thmz159 schreef op zondag 01 mei 2011 @ 13:59:
Is zo'n framework niet veel te groot voor kleinere projecten? Dat lijkt me al meer voor bv een echte bedrijfwebsite of iets. Ik ga me er nog eens in verdiepen.

Ook in template engine had ik me nog niet echt verdiept maar dit lijkt me wel makkelijk ,maar ook weer groot.

Dat ligt eraan... man-uren zijn duurder van hardware-kracht. Bij een framework is de helft al voor je gaan en hoef je hem alleen nog maar aan te passen aan jouw/de klant's wensen. Een licht framework is ook goed voor de wat simpelere websites hoor

[ Voor 10% gewijzigd door Exception op 01-05-2011 14:05 ]

[Thmz159]

Onbekend schreef op zondag 01 mei 2011 @ 14:03:
[...]

Je zou met je GET-waarde in een database kunnen kijken of die pagina echt beschikbaar is, en laat je hem de echte pagina-naam ophalen. Vervolgens include je gewoon de opgevraagde pagina.
Je zit dan altijd goed met relatieve verwijzingen naar css-files en afbeeldingen.

Ik had het zo gedaan:
die GET-waarde is altijd de naam van een file die gewoon in de root van de site staat.
en dan:

code:

$page = $_GET['p']
if(file_exists($page.'.php')){
    include_once($page.'.php');
}else{
    echo "Page not found";
}

Om een of andere reden heb ik altijd geprobeerd zo weinig mogelijk met een database te doen

Grote probleem van zo'n methode is wanneer je files in een subdir gaat zetten krijg je nogal rare constructies.
Met een database is dat allemaal wat flexibeler.

Exception schreef op zondag 01 mei 2011 @ 14:04:
[...]

Dat ligt eraan... man-uren zijn duurder van hardware-kracht. Bij een framework is de helft al voor je gaan en hoef je hem alleen nog maar aan te passen aan jouw/de klant's wensen. Een licht framework is ook goed voor de wat simpelere websites hoor

Ik ga eens kijken naar een basic framework en me erin proberen te verdiepen. (vindt persoonlijk wat functies uitwerken in PHP ook wel gemakkelijk , en dan weet ik precies wat er gebeurd). Voor javascript gebruik ik jquery, is dit dan iets framework achtig? (op de site staat library ) Want dat vindt ik allemaal wel heel gemakkelijk werken, dus zoiets voor PHP enzo kan dus ook makkelijk zijn.

Het lijkt me wel dat je voor frameworks vaak root access nodig hebt? Sites die ik maak zullen vaak op free hosts worden gezet, en dan heb je denk ik geen root access.

[ Voor 4% gewijzigd door Thmz159 op 01-05-2011 14:17 ]

[Onbekend]

Thmz159 schreef op zondag 01 mei 2011 @ 14:15:
[...]

Ik had het zo gedaan:
die GET-waarde is altijd de naam van een file die gewoon in de root van de site staat.
en dan:

code:

$page = $_GET['p']
if(file_exists($page.'.php')){
    include_once($page.'.php');
}else{
    echo "Page not found";
}

Om een of andere reden heb ik altijd geprobeerd zo weinig mogelijk met een database te doen

Grote probleem van zo'n methode is wanneer je files in een subdir gaat zetten krijg je nogal rare constructies.
Met een database is dat allemaal wat flexibeler.

Zelf gebruik ik ook geen database daarvoor, en doe ik dat in principe ook altijd zo, maar dan heb ik de bestanden die los opgevraagd mogen worden in een map staan. Regel 2 luidt dan:
if ( file_exists("SiteContent/".$Pagina.".htm"))
De variable $Pagina wordt daarvoor ook nog eens gecontroleerd op normale tekens, zodat '../' er netjes uit worden gehaald.

Alleen de process-pagina's (zoals een foto-album opbouwen en contactformulieren) worden bij mij apart afgehandeld.

[Gamebuster]

Om te controleren of een bestand in een bepaalde map zit, doe ik altijd:

PHP:

<?php
$folder = ".";
$file = $page.".php";

if(file_exists($file)
&& dirname(realpath($file)) == realpath($folder))
{
  // bestand bestaat en staat opgeslagen in $folder
}

?>

[ Voor 82% gewijzigd door Gamebuster op 01-05-2011 14:33 ]

[Cartman!]

Pas op met zulke includes voor de nullbyte injection.

code:

include($_GET['p'].'.txt');

$h = fopen($_GET['p'].'.txt','r');
echo ';'.fread($h, 9).'";

Als je dan in $_GET['p'] "../../../../passwd" oid weet te zetten en je hebt rechten die file te lezen zal ie de inhoud netjes weergeven. Let dus goed op dat je de inhoud van $_GET (en elke andere input) goed escaped voordat je t gebruikt. Waar het in dit geval op neerkomt is dat de bullbyte de string afkapt en het stuk erna (.txt) negeert. Meer info hier: http://ha.ckers.org/blog/...e-to-null-byte-injection/

[ Voor 5% gewijzigd door Cartman! op 01-05-2011 14:35 ]

[Thmz159]

Dat van die nullbyte injection zal ik zeker in gedachten houden.

Nog een vraagje:
Stel ik doe optie 2, dan wil ik niet dat mensen de content kunnen opvragen zonder via de index te gaan. Dus dat ze "http://localhost/registreer.php" doen ipv "http://localhost/?p=registreer", want anders wordt de CSS file er niet ingebracht (deze staat namelijk in de index file). Dus ik dacht om bij elke contentfile een controlebestand bij te voegen met "require" in dit controlebestand dan:

code:

if(!isset($index)){
    echo "Er is iets fout gegaan."; // en dan doorsturen naar goede pagina
    exit;
}

De $index variable is gedefinieerd in het index.php bestand.

Maar is dit een goede manier?

[Ventieldopje]

Je zou dan eigenlijk moeten werken met een constante variable dus in je index.php

PHP:

<?php

define("INDEX_LOADED", true);

// includes hier enzo ;)

?>

Andere pagina's:

PHP:

<?php

if(!isset(INDEX_LOADED) || INDEX_LOADED != true)
{
    die("You cannnot enter this page directly");
}

?>

Zo iets

Bovendien raad ik je aan naar frameworks als CodeIgniter (vrij simpel en licht), Cake en Zend (zeer geavanceerd maar vrij lastig in te komen).

[ Voor 57% gewijzigd door Ventieldopje op 01-05-2011 15:19 ]

[FragFrog]

Ventieldopje schreef op zondag 01 mei 2011 @ 15:16:

PHP:

<?php

if(!isset(INDEX_LOADED) || INDEX_LOADED != true)
{
    die("You cannnot enter this page directly");
}

?>

Zo iets

Voor constants kun je beter defined gebruiken ipv isset:

PHP:

if (!defined(INDEX_LOADED))
    die("You cannnot enter this page directly");

Zie ook opmerking in de handleiding van isset:

quote: http://nl.php.net/manual/en/function.isset.php

Warning
isset() only works with variables as passing anything else will result in a parse error. For checking if constants are set use the defined() function.

TS: als je optie 3 gebruikt en domweg alles rewrite naar je index.php hoef je je ook geen zorgen te maken of mensen niet direct naar een andere pagina gaan. Je kan vervolgens vrij simpel met $_SERVER['REDIRECT_URL'] bekijken wat het URL was wat ze aanriepen. Mooiere URL's en minder moeite om je andere pagina's te beveiligen

[Cartman!]

$_SERVER['REQUEST_URI'] bedoel je?

[FragFrog]

Cartman! schreef op zondag 01 mei 2011 @ 18:00:
$_SERVER['REQUEST_URI'] bedoel je?

Nee, REDIRECT_URL bedoel ik (icm met een .htaccess rewrite), dan heb je geen 'last' van extra parameters Al kun je dat trouwens ook vrij eenvoudig omzeilen door parse_url te gebruiken. Zoals altijd zijn er meer wegen naar rome, wat je gebruikt maakt uiteindelijk weinig uit.

[ Voor 49% gewijzigd door FragFrog op 01-05-2011 18:21 ]

[ID-College]

Ik zit overwegen om ook eens naar frameworks te kijken. Ik gebruik het wisselend, afhankelijk van de grote van de site. Momenteel werk ik met een content class die de content genereert..

[ReenL]

http://www.slimframework.com/

PHP:

<?php
require 'Slim/Slim.php';
Slim::init();
Slim::get('/hello/:name', function ($name) {
    echo "Hello $name";
});
Slim::run();
?>

Simpel en klein, je kan je eigen urls verzinnen

Als je 3 doet gewoon alles naar index.php, die de url laten parsen, anders wordt je .htaccess zo onnodig groot en complex.

[Verwijderd]

Persoonlijk gebruik ik een (zelf geschreven) framework, omdat mijn websites vrijwel hetzelfde zijn, maar toch dynamisch. In sommige gevallen gebruik ik bestaande CMS-en of maak ik gewoonweg losse PHP pagina's waar ik een header en footer in include.

Het ligt dus vooral aan de website en/of project waar je aan werkt.

Voor een simpele website, zoals beschreven in TS, zou ik gaan voor de mod_rewrite oplossing. Dit omdat het er netjes uitziet (voor bezoekers en zoekmachines) en foutafhandeling makkelijker maakt.

De werking in de index.php kun je maken zoals je wilt, maar voor kleine sites zou ik geen gebruik maken van een database tenzij je een "echt" CMS wilt hebben. De oplossing met file_exists() is dan de gemakkelijkste en beste oplossing in mijn ogen.

P.S. luister nooit naar andere hobbyisten, want vaak zijn hun oplossingen ingewikkelder dan het probleem
Houd het lekker simpel voor jezelf, dan maak je ook minder snel fouten.

[johnkeates]

Je zou Zend Framework kunnen gebruiken. Dan kan je bijvoorbeeld alleen de Router laden, of alleen MVC, of gewoon alles bootstrappen, afhankelijk van wat je nodig hebt.

[CurlyMo]

Ik gebruik zelf een aangepaste versie van de volgende directory structuur:

http://anantgarg.com/2009...php-mvc-framework-part-1/

[Ventieldopje]

@FragFrog
*facepalm* ... defined ipv. isset inderdaad

Dus opties genoeg wat betreft frameworks Zend icm. Smarty heeft nog steeds mijn persoonlijke voorkeur

[CurlyMo]

Ventieldopje schreef op maandag 02 mei 2011 @ 01:46:
@FragFrog
*facepalm* ... defined ipv. isset inderdaad

Dus opties genoeg wat betreft frameworks Zend icm. Smarty heeft nog steeds mijn persoonlijke voorkeur

Ik vind Smarty nogal overrated en bloated. De conditionele commando's (zoals een loop) die in Smarty worden gebruikt zijn niet makkelijker dan dezelfde commandos van PHP zelf. Vrijwel hetzelfde effect van Smarty kan bereikt worden via de extract functie van PHP zelf. Daarnaast is de verbeterede snelheid een groot voordeel. Zie de volgende blog voor uitleg:

PHP Tip: Extract, Variable Variables and Templating

[kwaakvaak_v2]

ooh joepie... een template engine vs php is al een template engine discussie

[CurlyMo]

kwaakvaak_v2 schreef op maandag 02 mei 2011 @ 12:02:
ooh joepie... een template engine vs php is al een template engine discussie

De vraag die ontopic blijft is of iemand voldoende bewust is van de mogelijkheden die PHP zelf biedt aangezien men Smarty nogal snel adviseert (eerste hit op google onder "php template").

[kwaakvaak_v2]

Dingus die niet meer wil dat ie herkent wordt ofzo, schreef op maandag 02 mei 2011 @ 12:24:
[...]


De vraag die ontopic blijft is of iemand voldoende bewust is van de mogelijkheden die PHP zelf biedt aangezien men Smarty nogal snel adviseert (eerste hit op google onder "php template").

PHP ontwikkelaars, zijn net als mensen, gewoonte dieren, dat is imho het enige correcte antwoord op je vraag. Vraag een php'er om een template engine, en als een pavlov reactie komt gelijk het woord Smarty boven borrelen. En ik denk zelf dat men wel bewust is van het antwoord op de mogelijkheden, maar om diverse redenen heel bewust kiezen voor een template engine. Maar goed.. zoals ik al zei "Joepie... weer een template engine discussie"

[ Voor 3% gewijzigd door kwaakvaak_v2 op 27-03-2013 10:32 ]

[Thmz159]

Ik twijfel toch over het nut bij mij met een template engine of een framework. Ik gebruik PHP hoofdzakelijk voor gewoon login en registreerpaginas en misschien een gastenboek en natuurlijk de basiswerking van de site.
Ik gebruik vaak javascript (icm wat ajax) om sommige dingen te bereiken.

Met Mod rewrite heb ik wel slechte ervaringen (waarschijnlijk door mijn beperkte kennis ), want op mijn XAMPP server werkte het dan wel maar op een gratis hosting kreeg ik heel de tijd errors dat hij mijn css files bv niet vondt, maar normaal raakt dit wel opgelost.
Nu had ik door die reactie van ReenL om misschien een eenvoudige oplossing te maken met mod rewrite door alles door te sturen naar de index.php en PHP te laten uitzoeken wat met de pagina gedaan moest worden.
Dus als iemand intypt: "http://localhost/registreer/123", gaat de "registreer/123" als een get naar PHP en dan opspliten op basis van slashes om PHP te laten bepalen dat de persoon naar de registreer pagina wilt en nog iets met 123 wilt
Weet niet of dit zou werken, en of dit wel voordelen heeft.

EDIT: Zie nu pas dat zo'n methode een deel is van de link van CurlyMo. Dat kan ik misschien wel toepassen.

[ Voor 5% gewijzigd door Thmz159 op 08-03-2013 21:15 ]

[Ventieldopje]

Je moet natuurlijk doen wat je zelf wil en wat jou het beste lijkt maar uit sprekend uit persoonlijke ervaring ga je tegen dingen aanlopen en ontwikkel/onderhoud je 10x sneller websites met een framework.

Het lijkt nu nog leuk van, oh even een url writer schrijven enzo, maar waarom het wiel opnieuw uitvinden als het al in de meeste frameworks zit? Van CodeIgniter weet ik dat het vrij flexibel is en je er uit kan plukken wat je nodig hebt

Deze code gebruik ik icm. zend framework (maar dat maakt weinig uit) om mooie urls te krijgen. Deze checkt ook of het pad dat je opvraagt een bestaand bestand / map is, zo nee stuurt hij de request naar index.php, zo is het dus nooit het geval dat je CSS niet gevonden kan worden

code:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]

offtopic:
@CurlyMo, wat snap je niet aan persoonlijke voorkeur? Hiermee doelde ik er dus op dat in dit topic geen ruimte is voor discussie over template engines en het nut er van. Dat doen we wel in een ander topic

[ Voor 26% gewijzigd door Ventieldopje op 08-03-2013 23:28 ]

[Onbekend]

Ventieldopje schreef op vrijdag 06 mei 2011 @ 19:34:
Je moet natuurlijk doen wat je zelf wil en wat jou het beste lijkt maar uit sprekend uit persoonlijke ervaring ga je tegen dingen aanlopen en ontwikkel/onderhoud je 10x sneller websites met een framework.

Mijn ervaring is juist dat een framework juist traag werkt.
Voor mijn hobby maak ik websites, en schrijf ik direct puur html.
Op mijn werk hebben ze nu besloten om ook een nieuwe eigen website te bouwen en een framework te gaan gebruiken. Zelf was ik niet bij dat project betrokken, maar vanwege mijn kennis hebben ze toch mijn hulp gevraagd. Ik ben nu al meer dan 40 uur bezig geweest om de website iets vorm te geven en ik ben nog steeds niet klaar, terwijl ik zonder zo'n framework zo'n website in geen 10 uur al kant en klaar heb.

Het is dus net hoeveel ervaring je hebt met html en het type framework. Je hoeft niet het wiel helemaal opnieuw uit te vinden, maar als je een beter wiel kan maken raad ik je dat wel aan.

[Precision]

Onbekend schreef op vrijdag 06 mei 2011 @ 19:57:
[...]

Mijn ervaring is juist dat een framework juist traag werkt.
Voor mijn hobby maak ik websites, en schrijf ik direct puur html.
Op mijn werk hebben ze nu besloten om ook een nieuwe eigen website te bouwen en een framework te gaan gebruiken. Zelf was ik niet bij dat project betrokken, maar vanwege mijn kennis hebben ze toch mijn hulp gevraagd. Ik ben nu al meer dan 40 uur bezig geweest om de website iets vorm te geven en ik ben nog steeds niet klaar, terwijl ik zonder zo'n framework zo'n website in geen 10 uur al kant en klaar heb.

Het is dus net hoeveel ervaring je hebt met html en het type framework. Je hoeft niet het wiel helemaal opnieuw uit te vinden, maar als je een beter wiel kan maken raad ik je dat wel aan.

Hmm dan doe je toch iets fout Het zou normaal sneller moeten gaan omdat je de header, footer etc hergebruikt en de gegevens dynamisch opvraagt ipv statisch. Ipv er 4 maal zo lang over te doen zou je er normaal 2 keer minder tijd over moeten doen.
Edit: Waarom gebruikten ze dan niet gewoon een cms: wordpress, drupal, expressionengine, ...

[ Voor 4% gewijzigd door Precision op 06-05-2011 20:02 ]

[YopY]

Onbekend schreef op vrijdag 06 mei 2011 @ 19:57:
[...]

Mijn ervaring is juist dat een framework juist traag werkt.
Voor mijn hobby maak ik websites, en schrijf ik direct puur html.
Op mijn werk hebben ze nu besloten om ook een nieuwe eigen website te bouwen en een framework te gaan gebruiken. Zelf was ik niet bij dat project betrokken, maar vanwege mijn kennis hebben ze toch mijn hulp gevraagd. Ik ben nu al meer dan 40 uur bezig geweest om de website iets vorm te geven en ik ben nog steeds niet klaar, terwijl ik zonder zo'n framework zo'n website in geen 10 uur al kant en klaar heb.

Het is dus net hoeveel ervaring je hebt met html en het type framework. Je hoeft niet het wiel helemaal opnieuw uit te vinden, maar als je een beter wiel kan maken raad ik je dat wel aan.

Maar komt dat omdat het framework zelf log is, of omdat je alles (mbt dat framework) nog moet leren? D'r zit verschil tussen, namelijk. Puur uit nieuwsgierigheid, neem eens een component of een pagina - wat moet je doen als je het 'zelf' doet, en wat als je het framework gebruikt? Ik begin namelijk te vermoeden dat je zelf ook een soort 'framework' geschreven hebt (ook al zie je het niet zo).

[Onbekend]

Dat klopt.
Voor mijzelf heb ik inderdaad een soort framework geschreven, die uiteraard erg flexibel is.
In het begin dacht ik dat ik nog allerlei functionaliteiten van dat andere framework nog niet kende, maar sommige dingen kan je zelf niet veranderen. Uiteraard zat er een editor in waarmee je direct CSS en PHP-files kon aanpassen, maar aangezien er nauwelijks commentaar in staat is dat vrij ondoorzichtig. HTML + PHP codes door elkaar, en inline styles die externe styles overrulen en classes die uit soms uit 8 verschillende externe declaraties bestaan. Ook vijf <div>jes in elkaar om een footer te plaatsen, en dan blijft het zoeken totdat je de juiste declaratie hebt gevonden die een layoutprobleem veroorzaakt.

[Cartman!]

Onbekend schreef op vrijdag 06 mei 2011 @ 19:57:
[...]
Het is dus net hoeveel ervaring je hebt met html en het type framework. Je hoeft niet het wiel helemaal opnieuw uit te vinden, maar als je een beter wiel kan maken raad ik je dat wel aan.

Het probleem is meer dat veel hobbyisten denken dat ze een beter wiel kunnen maken, in praktijk moet ik de eerste keer nog meemaken.

[YopY]

Onbekend schreef op vrijdag 06 mei 2011 @ 23:22:
Dat klopt.
Voor mijzelf heb ik inderdaad een soort framework geschreven, die uiteraard erg flexibel is.
In het begin dacht ik dat ik nog allerlei functionaliteiten van dat andere framework nog niet kende, maar sommige dingen kan je zelf niet veranderen. Uiteraard zat er een editor in waarmee je direct CSS en PHP-files kon aanpassen, maar aangezien er nauwelijks commentaar in staat is dat vrij ondoorzichtig. HTML + PHP codes door elkaar, en inline styles die externe styles overrulen en classes die uit soms uit 8 verschillende externe declaraties bestaan. Ook vijf <div>jes in elkaar om een footer te plaatsen, en dan blijft het zoeken totdat je de juiste declaratie hebt gevonden die een layoutprobleem veroorzaakt.

Een framework met een editor erin is ranzig, tenminste als het wel echt een framework is - als ik het zo lees is het eerder een volledig CMS dat (imo) nutteloze features probeert aan te bieden. Puur uit nieuwsgierigheid, welk framework / CMS is dat? Als ik dat zo lees is het ranzig, en kan ik begrijpen dat het qua productiviteit niks toevoegt.

Templates, CSS en PHP bewerken doe je niet in een webinterface.

[Ventieldopje]

Mijn ervaring is juist dat een framework juist traag werkt.
Voor mijn hobby maak ik websites, en schrijf ik direct puur html.

Leuk, lekker blijven doen voor je hobby, je hebt nog een hoop te leren Mag je mij vertellen hoe je efficient een CMS (om iets simpels te noemen) wil gaan schrijven als je alleen html gebruikt of je eigen framework gerbruikt zonder weken bezig te zijn met caching, authenticatie, ajax (het oog wil ook wat), database (voor beetje business website zit je al aan aan Doctrine), ACL, etc.

Blijft toch leuk dat mensen er zo makkelijk over denken en proberen het wiel opnieuw uit te vinden om er mee te kunnen pochen dat ze het helemaal zelf geschreven hebben, leuk voor hobby maar niet als het straks ook moet gaan werken bij een bedrijf of als je snel en efficient een website wil maken

Ok nou zijn we zo ver off topic dat ik niet eens meer weet waar het topic nou over ging ...

[martin149]

Ik heb een zeer simpel systeem hier, wat ik zo zou kunnen plaatsen, maar dan moet je het zeggen. Ik heb het gemaakt voor deze site gemaakt. Veel variaties heb ik al gebruikt, maar het is en blijft erg simpel. Als je een systeem wilt kun je het beste er zelf een opbouwen van begins af aan en soms ergens wat stukken overnemen. Zo krijg je geen stukken code van over je niveau.
Maar als je het wilt, reageer hier dan ff op, of DM. Overigens ben ik de DB gegevens wel kwijt maar die kun je makkelijk uit de code halen

[NMe]

martin149 schreef op zondag 08 mei 2011 @ 19:08:
Ik heb een zeer simpel systeem hier, wat ik zo zou kunnen plaatsen, maar dan moet je het zeggen. Ik heb het gemaakt voor deze site gemaakt.

Mooie SEO-vriendelijke urls.

[martin149]

Ik weet het, maar ik wilde het simpel houden. Een andere variatie erop (naja niet heel veel meer) stond online op seziez.co.cc en had wel mod rewrite en dergelijke, ook daar heb ik nog alle broncodes van bewaart gelukkig.

[Staatslot]

Ik werk altijd met een sitemap in mysql, die bepaalt of een pagina mag worden ge-include en je weet dan bovendien adhv zijn parent bij welk gedeelte van de website de pagina hoort (dat gebruik ik dan voor de kleuren, de menu's en het kruimelpad). Dit kun je dus ook gebruiken als mod-rewrite het niet doet of je dat niet beheerst.

Als ik een site maak zonder mysql maak ik altijd een array in php met toegestane pagina's, zit de gevraagde pagina niet in de lijst (via de functie in_array) dan include ik home..

[ Voor 8% gewijzigd door Staatslot op 08-05-2011 19:18 ]

[martin149]

dat ken ik ergens van... Ik ging zo te werk±

PHP:

<?php
$pages = array(
"s" => array("includes/search.inc.php","Zoeken"),
"series" => array("includes/series.inc.php","Alle Series"),
"activate" => array("includes/activate.inc.php","Activeren"),
"login" => array("includes/login.inc.php","Log in"),
"register" => array("includes/registreer.inc.php","Registeren"),
"serietoev" => array("includes/serietoev.inc.php","Serie Toevoegen"),
'software' => array("includes/software.inc.php","Software"),
"user" => array("includes/user.inc.php","User"),
"cat" => array("includes/cat.inc.php","Categoeie&euml;n"),
"serietv" => array("includes/serietv.inc.php","Serie Toevoegen"),
"muziek" => array("includes/muziek.inc.php","Muziek"),
"vertaal" => array("includes/vertaal.inc.php","Vertaal")
                   );
if(isset($_GET['id']) && is_numeric($_GET['id'])){
  /* Submenu's */
  if($_GET['s'] == "afleveringen"){
  $page = "includes/afleveringen.inc.php";
  $titel = "Afleveringen";
  }elseif($_GET['s'] == "video"){
  $page = "includes/video.inc.php";
  $titel = "Video's";
  }elseif($_GET['s'] == "personages"){
  $page = "includes/personages.inc.php";
  $titel = "Personages";
  }else{
  $page = "includes/serieinfo.inc.php";
  $titel = "Informatie";
  }
  /* ------- */
}elseif(!empty($pages[$_GET['id']])){
$page = $pages[$_GET['id']][0];
$titel = $pages[$_GET['id']][1];
}else{
$page = "includes/home.inc.php";
$titel = "Home";
} ?>

[Staatslot]

martin149 schreef op zondag 08 mei 2011 @ 19:21:
dat ken ik ergens van... Ik ging zo te werk±

PHP:

<?php
$pages = array(
"s" => array("includes/search.inc.php","Zoeken"),
"series" => array("includes/series.inc.php","Alle Series"),
"activate" => array("includes/activate.inc.php","Activeren"),
"login" => array("includes/login.inc.php","Log in"),
"register" => array("includes/registreer.inc.php","Registeren"),
"serietoev" => array("includes/serietoev.inc.php","Serie Toevoegen"),
'software' => array("includes/software.inc.php","Software"),
"user" => array("includes/user.inc.php","User"),
"cat" => array("includes/cat.inc.php","Categoeie&euml;n"),
"serietv" => array("includes/serietv.inc.php","Serie Toevoegen"),
"muziek" => array("includes/muziek.inc.php","Muziek"),
"vertaal" => array("includes/vertaal.inc.php","Vertaal")
                   );
if(isset($_GET['id']) && is_numeric($_GET['id'])){
  /* Submenu's */
  if($_GET['s'] == "afleveringen"){
  $page = "includes/afleveringen.inc.php";
  $titel = "Afleveringen";
  }elseif($_GET['s'] == "video"){
  $page = "includes/video.inc.php";
  $titel = "Video's";
  }elseif($_GET['s'] == "personages"){
  $page = "includes/personages.inc.php";
  $titel = "Personages";
  }else{
  $page = "includes/serieinfo.inc.php";
  $titel = "Informatie";
  }
  /* ------- */
}elseif(!empty($pages[$_GET['id']])){
$page = $pages[$_GET['id']][0];
$titel = $pages[$_GET['id']][1];
}else{
$page = "includes/home.inc.php";
$titel = "Home";
} ?>

Het idee is enigszins hetzelfde, alleen iets te moeilijk uitgewerkt misschien...
Heb niet de hele topic doorgelezen, sorry, maar ik zou aanraden mysql te gebruiken als je dat kunt.
Dan heb je alles opgelost, een sitemap, vriendelijke urls, kruimelpaden, eventueel afwisselende css voor diverse secties, pagina titels etc. Maar zoals met veel dingen, ieder zo zn voorkeur natuurlijk er zijn zoals genoemd nog zat andere oplossingen.. Succes!

[Verwijderd]

Voor mijn blog (die nog niet online staat) heb ik gewoon 3 verschillende pagina's aangemaakt:

• index.php
• category.php
• about.php

De 5 laatst geposte artikels komen op de index-pagina te staan en met de knop "older entries" kan je door de andere artikels bladeren. Op de indexpagina staat een balk met allemaal categorieën, wanneer je daar op klikt wordt je doorverwezen naar de categorie.php waar alle artikels binnen een bepaalde categorie worden getoond.
Op about.php staat gewoon een tekst over mezelf.

De artikels worden op de blog geplaatst door een heel simpel zelfgeschreven csmje. Ik zeg niet dat mijn cms beter of vollediger is als de anderen, maar ik weet wel hoe alles in elkaar zit en weet dus ook waar ik iets moet aanpassen wanneer er iets misloopt.

Maar als je meer dan 3 pagina's wilt gaan gebruiken wordt dit misschien wat omslachtig...

[kwaakvaak_v2]

martin149 schreef op zondag 08 mei 2011 @ 19:21:
dat ken ik ergens van... Ik ging zo te werk±

PHP:

<?php

if(isset($_GET['id']) && is_numeric($_GET['id'])){
  /* Submenu's */
  if($_GET['s'] == "afleveringen"){
  $page = "includes/afleveringen.inc.php";
  $titel = "Afleveringen";
  }elseif($_GET['s'] == "video"){
  $page = "includes/video.inc.php";
  $titel = "Video's";
  }elseif($_GET['s'] == "personages"){
  $page = "includes/personages.inc.php";
  $titel = "Personages";
  }else{
  $page = "includes/serieinfo.inc.php";
  $titel = "Informatie";
  }
  /* ------- */
}elseif(!empty($pages[$_GET['id']])){
$page = $pages[$_GET['id']][0];
$titel = $pages[$_GET['id']][1];
}else{
$page = "includes/home.inc.php";
$titel = "Home";
} ?>

Zo dan... die kan ook wel gelijk door naar het slechte voorbeelden topic. Wat een ranzige bak spaghetti if zeg Doe dan een switch case constructie, is het in ieder geval nog leesbaar. Maar beter leer je dan toch eens werken met een router of iets dergelijks in je code want dit gaat vrij vlot echt een ononderhoudbare bak ellende worden als er nog 5 paginas met elk 2 subpaginas bij komen.

[Staatslot]

kwaakvaak_v2 schreef op zondag 08 mei 2011 @ 19:41:
[...]


Zo dan... die kan ook wel gelijk door naar het slechte voorbeelden topic. Wat een ranzige bak spaghetti if zeg Doe dan een switch case constructie, is het in ieder geval nog leesbaar. Maar beter leer je dan toch eens werken met een router of iets dergelijks in je code want dit gaat vrij vlot echt een ononderhoudbare bak ellende worden als er nog 5 paginas met elk 2 subpaginas bij komen.

Wat een lullige reactie, Een heel stuk vriendelijker mag ook wel..

Edit, iets te snel gereageerd was niet de TS waar het over ging..

[ Voor 16% gewijzigd door Staatslot op 08-05-2011 19:49 ]

[CodeCaster]

Staatslot schreef op zondag 08 mei 2011 @ 19:43:
[...]


Wat een ontzettend lullige reactie, onnodig ook.
Ts geeft zelf aan dat hij hier mee zit, vraagt om oplossingen zoekt zelf dingen uit en vraagt naar verbeteringen.. En dan is dit jouw reactie? Een heel stuk vriendelijker mag ook wel...

Het is niet TS die die lap code aandraagt, en hij geeft aan dat het een ononderhoudbaar brok code is, en dat ben ik met hem eens.

[Staatslot]

CodeCaster schreef op zondag 08 mei 2011 @ 19:45:
[...]

Het is niet TS die die lap code aandraagt, en hij geeft aan dat het een ononderhoudbaar brok code is, en dat ben ik met hem eens.

Ok niet de TS, excuus. Maar blijft onnodig kwetsend, vriendelijkheid blijft toch wel belangrijk op tweakers...

[martin149]

Naar mijn inzien is een (else)if reeks al heel erg overzichtelijk, waarom dan met een moeilijke constructie werken met minder mogelijkheden?

[Manuel]

kwaakvaak_v2 schreef op zondag 08 mei 2011 @ 19:41:
Doe dan een switch case constructie, is het in ieder geval nog leesbaar.

Dat is helemaal van een persoon zelf afhankelijk, je kunt niet zeggen dat een switch / case / default-statement in dit geval het beste eruit zou zijn. Gelukkig zijn er meerdere wegen die naar Rome leiden.

offtopic:
Was een if / else if / else statement niet iets sneller als een switch / case / default statement als je het goed veel keren achter elkaar uitvoert? (Al hebben we het dan over micro-optimalisaties. )

[cpt.skydiver]

Ja volgens mij was het zo dat een switch eerst naar een if else constructie wordt geparsed. Aangezien php elke keer dat je het uitvoert gecompileerd wordt..... micro optimalisaties is wel het goede woord ja

[kwaakvaak_v2]

micro optimalisatie is ongeveer net zo nuttig als proberen een dam te maken van wattenbolletjes Zeker voor het soort sites waar dit voor gebruikt is, maar ook grotere projecten ala facebook wordt er niet echt naar optimalisatie op dit nivo gekeken.

@staatsloot, jij mag mij best onbeschoft noemen in mijn reactie, ik zelf zou eerder opteren voor direct en realistisch. Ik dacht dat tweakers een pro community probeerde te zijn, en daar mag je vind ik, best kritisch reageren op iemands codewerk.

@martin, een if,elseif,elseif,elseif kan best overzichtelijk zijn, maar in dit geval is het imho gewoon plak werk, wat met een klein beetje router werk veel netter en net zo makkelijk had gekund. Desnoods op een manier met closures zoals dat in Silex of gewoon in een eigen minirouter class waar je met een __ magic method, of in je __construct kijkt of je class de methode van je call implementeerd en vervolgens uitvoerd. Voordeel is dat het toevoegen van een onderdeel kwestie is van method of functie maken en klaar, plus leesbaar voor iemand anders de niet eerst een stuk spaghetti mag gaan ontvlechten

[martin149]

@kwaakvaak v2:
Ach het is altijd nog beter dan wordpress. Dat dat soort dingen zelfs geen nette opbouw hebben, en die thema's al helemaal niet, alles wordt weggestopt in onvindbare bestanden. Om me maar ff bij het onderwerp te houden zou ik veel verschillede stukken maken in verschillende bestanden. Geef ze ook een goede naam, zodat je ze terug kan vinden. Ik gebruik altijd dingen als "ptv" voor pagina toevoegen, en dat soort dingen. 1 ding dat ik wel kan adviseren is om je gastenboek, als je dat ooit aanmaakt (is een beetje uit), noem het dan nooit zo, ik heb eens een gb gehad met 3Gb aan spam, in meer dan 1m sql regels. Geef dat een cryptische naam.
Nog iets handigs, wat er bij wordpress is in de codex is om een lijst met functies te maken en hum locatie als je uitgebreid gaat werken
Veel plezier met dit veel te vele leesvoer

[ Voor 0% gewijzigd door martin149 op 08-05-2011 20:37 . Reden: leesvoer, niet leervoer ]

[krvabo]

Ik doe het zelf op de volgende manier, wat voor mij erg handig werkt. Het is gestructureerd en nergens zijn switches of databaseconnecties nodig:



Dat is mijn bestandsopbouw. 1 public dir met daarin een .htaccess, een index.php en verder alleen images/js/css. In mijn non-www dir is een model/view/control-structuur.

Model:
Dit bevat, afhankelijk van hoe groot de site is, een 'handler'-dir welke bepaalde handelingen uitvoert voor de models. De models zijn dan simpele get/set/save/delete/exists-classes. Bij een kleinere site ontbreekt de handler-dir en zijn de models meteen de handlers. Daar staan dan verschillende functies in die kunnen worden hergebruikt door de site.

View:
Bevat smarty-templates en een directory voor de templates van ingelogde gebruikers. Deze 'ingelogde gebruikers'-templates extenden en overriden de templates uit de niet-ingelogd.

Control:
Hierin zitten classes voor elke hoofdcategorie. In deze klassen zitten public (en wellicht non-public) methods die de pagina 'maken' en doorsturen via een templatemanager. In de klassen zit een constructor en een __default() method. De constructor kan uiteraard globaal gebruikte models inladen, en de __default() method wordt aangeroepen als er geen 'actie'-method wordt gegeven.
Zo kan ik /user/new/ aanroepen waarbij dan de klasse 'userControl' wordt gepakt en de method new() wordt aangeroepen. Ik kan /user/ aanroepen waarbij de __default() method wordt gebruikt om view() aan te roepen.

index.php
Hierin zit het 'slimme' gedeelte. Wat hier is te vinden bevat onder andere een hoop controles op valide klassen en methods. Dit gebeurt met een aantal regexen, file_exists, method_exists en wat andere controles. De $_GET wordt gefilterd doorgegeven en alles wordt op de volgende manier aangeroepen:

PHP:

    // Create a new instance
    $oClass = new $sClassName;

    /*
     * Execute requested action
     */
    $oClass->{$sRequestedAction}($aParameters);

$sRequestedAction is de method die wordt aangeroepen en $aParameters is de gefilterde $_GET-array.


Op deze manier werkt het heel makkelijk, ik maak een nieuwe class en het werkt meteen, zonder ook maar ergens iets te moeten toevoegen of wijzigen. Het heeft ook nadelen: Omdat er ook overerving in de control zit voor ingelogde gebruikers moet ik altijd een 'base' klasse maken voor niet ingelogde gebruikers, ook al mogen niet-ingelogde gebruikers er niets uitvoeren. Hierin staat dan een header('Location: ') in de constructor.

Verder is het best een hoop werk voor een kleine site, maar als je een grotere site krijgt werkt het voor mij perfect. De code is zo heerlijk gestructureerd en bovenal in een IDE snel vindbaar (Methods komen in de 'explorer' te staan in de class). Je start met een redelijk aantal bestanden om alles werkbaar en gestructureerd te krijgen, maar als die er eenmaal zijn krijg je geen wildgroei aan bestanden. Je moet je wel heel strikt houden aan naamgevingsconventies omdat bestanden altijd direct aangeroepen worden en er uit wordt gegaan van een bepaald formaat: <naam>Control.php en <naam>ControlBase.php bijvoorbeeld.

Soms zit je ook wel met methods waarbij je een ongefilterde $_GET nodig hebt, bijvoorbeeld bij een zoekfunctie. Hierin kun je dan gewoon ook $_GET gebruiken in plaats van $aParameters, maar het breekt de conventie om het niet te gebruiken.

Anyway, dit is voor mij een goede manier.

[YopY]

Ik doe het nog eenvoudiger.

Java:

@RequestMapping(value = "/dinges/{param}", method = RequestMethod.GET)
public String doeIets() {
    return "site content!";
}

nul htaccess, nul if/else dingen prutsen, 1 of 2 regels configuratie in een xml-bestand, en je hebt je instant RESTful webservice.

Het kan nog eenvoudiger, overigens.

Scala:

class ScalatraExample extends ScalatraServlet {
get("/") {
    <h1>Hello, world!</h1>
 }

get("/guess/*") {
  "You missed!"
}

get("/guess/:who") {
  params("who") match {
    case "Frank" => pass()
    case _ => "You got me!"
  }
}
}

Eenvoudiger iig als je Scala kent, en ik ken het nog niet .

[Ventieldopje]

krvabo schreef op zondag 08 mei 2011 @ 21:03:
Ik doe het zelf op de volgende manier, wat voor mij erg handig werkt. Het is gestructureerd en nergens zijn switches of databaseconnecties nodig:

[afbeelding]

Dat is mijn bestandsopbouw. 1 public dir met daarin een .htaccess, een index.php en verder alleen images/js/css. In mijn non-www dir is een model/view/control-structuur.

Model:
Dit bevat, afhankelijk van hoe groot de site is, een 'handler'-dir welke bepaalde handelingen uitvoert voor de models. De models zijn dan simpele get/set/save/delete/exists-classes. Bij een kleinere site ontbreekt de handler-dir en zijn de models meteen de handlers. Daar staan dan verschillende functies in die kunnen worden hergebruikt door de site.

View:
Bevat smarty-templates en een directory voor de templates van ingelogde gebruikers. Deze 'ingelogde gebruikers'-templates extenden en overriden de templates uit de niet-ingelogd.

Control:
Hierin zitten classes voor elke hoofdcategorie. In deze klassen zitten public (en wellicht non-public) methods die de pagina 'maken' en doorsturen via een templatemanager. In de klassen zit een constructor en een __default() method. De constructor kan uiteraard globaal gebruikte models inladen, en de __default() method wordt aangeroepen als er geen 'actie'-method wordt gegeven.
Zo kan ik /user/new/ aanroepen waarbij dan de klasse 'userControl' wordt gepakt en de method new() wordt aangeroepen. Ik kan /user/ aanroepen waarbij de __default() method wordt gebruikt om view() aan te roepen.

index.php
Hierin zit het 'slimme' gedeelte. Wat hier is te vinden bevat onder andere een hoop controles op valide klassen en methods. Dit gebeurt met een aantal regexen, file_exists, method_exists en wat andere controles. De $_GET wordt gefilterd doorgegeven en alles wordt op de volgende manier aangeroepen:

PHP:

    // Create a new instance
    $oClass = new $sClassName;

    /*
     * Execute requested action
     */
    $oClass->{$sRequestedAction}($aParameters);

$sRequestedAction is de method die wordt aangeroepen en $aParameters is de gefilterde $_GET-array.


Op deze manier werkt het heel makkelijk, ik maak een nieuwe class en het werkt meteen, zonder ook maar ergens iets te moeten toevoegen of wijzigen. Het heeft ook nadelen: Omdat er ook overerving in de control zit voor ingelogde gebruikers moet ik altijd een 'base' klasse maken voor niet ingelogde gebruikers, ook al mogen niet-ingelogde gebruikers er niets uitvoeren. Hierin staat dan een header('Location: ') in de constructor.

Verder is het best een hoop werk voor een kleine site, maar als je een grotere site krijgt werkt het voor mij perfect. De code is zo heerlijk gestructureerd en bovenal in een IDE snel vindbaar (Methods komen in de 'explorer' te staan in de class). Je start met een redelijk aantal bestanden om alles werkbaar en gestructureerd te krijgen, maar als die er eenmaal zijn krijg je geen wildgroei aan bestanden. Je moet je wel heel strikt houden aan naamgevingsconventies omdat bestanden altijd direct aangeroepen worden en er uit wordt gegaan van een bepaald formaat: <naam>Control.php en <naam>ControlBase.php bijvoorbeeld.

Soms zit je ook wel met methods waarbij je een ongefilterde $_GET nodig hebt, bijvoorbeeld bij een zoekfunctie. Hierin kun je dan gewoon ook $_GET gebruiken in plaats van $aParameters, maar het breekt de conventie om het niet te gebruiken.

Anyway, dit is voor mij een goede manier.

Je kunt het zelf schrijven of gewoon een MVC framework als Zend pakken, zf create project uitvoeren op de commandline en klaar

[krvabo]

Raar genoeg maak ik het liefst zo min mogelijk gebruik van 'andere' frameworks.
Ik weet dat het mvc-framework van Zend zeer geprezen is, maar dit werkt voor mij prima en het bevat geen dingen die ik niet nodig heb. Plus het werkt altijd en overal, op elke server, zonder iets te installeren. Ik geloof dat je voor Zend moest installeren?

Ik zie mijn methode ook niet echt als een framework, meer een gestructureerde vorm van het aanroepen van functies. Als je echt gaat kijken naar efficiëntie is het ook niet geweldig. Ook voor pagina's waar je in principe niet alle includes nodig hebt (zoals een databaseconnectie) wordt het nu gedaan. Maar dat is ook zo bij (bijna) elk cms / framework.

[HuHu]

Het Zend Framework is 100% PHP en daar hoef je dus niets voor te installeren.

[Melodic Metal]

Ik zou toch echt kijken naar frameworks zoals CodeIgniter of Kohana.

[Ventieldopje]

Dus je geeft toe dat jou methode niet efficient is maar weigert eens een framework te proberen (op een test machine bijv.). Bij ZendFramework net zoals ieder ander PHP framework (zie hier boven) hoef je niks server side te installeren, het is allemaal php.

Ik zou het gewoon eens gaan proberen, ze zijn er niet voor niks

[YopY]

krvabo schreef op maandag 09 mei 2011 @ 01:14:
Ik weet dat het mvc-framework van Zend zeer geprezen is, maar dit werkt voor mij prima en het bevat geen dingen die ik niet nodig heb.

Een framework als Zend is volledig modulair, je kunt modules die je niet gebruikt gewoon euh. niet gebruiken, .

Maar dat is ook zo bij (bijna) elk cms / framework.

Niet in de regel - als je geen gegevens uit de database plukt, maakt hij ook geen verbinding. Is niet nodig, immers.

[kwaakvaak_v2]

En dan nog... Als je systeem goed opgezet is met lazyloading, kun je 1.000.000 files hebben, maar worden enkel de includes geladen die nodig zijn voor dat request.

[Ventieldopje]

Precies, en zo zijn er nog honderden dingen waar je zo snel niet bij na denkt normaal en die zitten mede door jaren van ontwikkeling dus wel in frameworks

[FragFrog]

krvabo schreef op maandag 09 mei 2011 @ 01:14:
Maar dat is ook zo bij (bijna) elk cms / framework.

Daar heb je de autoload voor Koppel je die aan een stukje code wat een class kan includen en je laadt alleen die files en classes die je ook daadwerkelijk gebruikt. Nog een stapje verder kun je vooraf proberen te voorspellen welke classes geladen moeten worden adhv bijvoorbeeld het URL en die uit een enkel gegenereerd bestand plukken voordat je verder gaat, of APC gebruiken met eenzelfde effect

Ventieldopje schreef op maandag 09 mei 2011 @ 10:41:
Precies, en zo zijn er nog honderden dingen waar je zo snel niet bij na denkt normaal en die zitten mede door jaren van ontwikkeling dus wel in frameworks

Langer ontwikkelen != beter heh In mijn ervaring is het in elk geval qua code netheid vaker juist andersom

[ Voor 24% gewijzigd door FragFrog op 09-05-2011 11:55 ]

[krvabo]

Jullie lijken een verkeerd idee te hebben..

HuHu schreef op maandag 09 mei 2011 @ 08:45:
Het Zend Framework is 100% PHP en daar hoef je dus niets voor te installeren.

Ok, dat wist ik niet. Aangezien er overal downloads staan op de webpagina/ dacht ik dat je iets moest installeren of activeren.

Ventieldopje schreef op maandag 09 mei 2011 @ 09:18:
Dus je geeft toe dat jou methode niet efficient is maar weigert eens een framework te proberen (op een test machine bijv.).

Ik zeg niet dat mijn methode niet efficiënt is, ik zeg dat er enkele kleine 'nadelen' zitten aan mijn manier van werken. Dat is een groot verschil. Als ik zou moeten werken met Zend kom ik ook nadelen tegen, geen enkel pakket is 100% geweldig.

Ik zou het gewoon eens gaan proberen, ze zijn er niet voor niks

Voor mij wel, aangezien ik niet graag werk met andermans 'standaarden' of werkmethodes als ik er niet helemaal van overtuigd ben.

YopY schreef op maandag 09 mei 2011 @ 09:30:
[...]


Een framework als Zend is volledig modulair, je kunt modules die je niet gebruikt gewoon euh. niet gebruiken, .

Dat neemt niet weg dat er allerlei extra code inzit om dat te checken. Iets wat voor mij niet nodig is en dus puur overhead. (Voor mij!)

Niet in de regel - als je geen gegevens uit de database plukt, maakt hij ook geen verbinding. Is niet nodig, immers.

Ik zeg ook niet dat er een verbinding wordt gemaakt, ik zeg dat het bestand wordt ingeladen en dus zorgt voor (wellicht onnodige) I/O. Op een grote site met veel bezoekers kan dit echt gaan schelen.

kwaakvaak_v2 schreef op maandag 09 mei 2011 @ 10:07:
En dan nog... Als je systeem goed opgezet is met lazyloading, kun je 1.000.000 files hebben, maar worden enkel de includes geladen die nodig zijn voor dat request.

FragFrog schreef op maandag 09 mei 2011 @ 11:54:
[...]

Daar heb je de autoload voor Koppel je die aan een stukje code wat een class kan includen en je laadt alleen die files en classes die je ook daadwerkelijk gebruikt.

En dat is dan ook precies hoe mijn 'framework' werkt. Control-klassen worden ingeladen bij de request, de models met spl_autoload, maar er zijn nou eenmaal bestanden die je gewoon ingeladen wil hebben zoals een config-bestand, de exceptionhandler-klasse en het bestand wat de interfaces bevat bijvoorbeeld. Dit zijn allemaal bestanden die bij een pure tekstpagina niet nodig zijn, maar door het framework wel. Daar ging het over, niet over gezeik dat ik m'n hele docroot include.

Nog een stapje verder kun je vooraf proberen te voorspellen welke classes geladen moeten worden adhv bijvoorbeeld het URL en die uit een enkel gegenereerd bestand plukken voordat je verder gaat, of APC gebruiken met eenzelfde effect

Alleen de juist controlklasse (en zijn Base, welke wordt extend) wordt ingeladen.
Ik ken APC, ik ken HipHop, ik ken nog wel meer van dat soort pakketten, maar dat is echt pas van belang bij een groot aantal bezoekers tegelijk, je op eigen vps/servers draait en makkelijk nog even wat performance uit je servers wil halen. Het heeft zeker z'n voordelen, maar voor een normale site met enkele duizenden bezoekers per dag is het flinke overkill.

In mijn ervaring is het in elk geval qua code netheid vaker juist andersom

Hier valt het wel mee. Juist door je te houden aan opgestelde conventies, zoals naamgeving, bestandsnamen, etc, kun je een hoop afdwingen.

Ventieldopje schreef op maandag 09 mei 2011 @ 10:41:
Precies, en zo zijn er nog honderden dingen waar je zo snel niet bij na denkt normaal en die zitten mede door jaren van ontwikkeling dus wel in frameworks

Mijn "framework" (ik wil het eigenlijk niet eens zo noemen) is voldoende ontwikkeld. Natuurlijk zitten er bij Zend heel slimme mensen die het goed uitdenken, maken en testen, maar voor mijn doel is mijn eigen methode perfect. Er zitten goede controles in, het is vrij efficiënt, het is overzichtelijk, en het meest belangrijke: het gebruikt mijn manier van werken. De naamgeving is zoals ik het wil, de bestanden staan waar ik het wil, het is aanpasbaar zoveel ik het wil, en omdat het speciaal voor z'n doel is geschreven zit er nauwelijks overhead in.


Toch knap, laat ik mijn manier van werken zien, juist om te laten zien dat je ook zonder if's en rare frameworks prima kunt werken op een overzichtelijke gestructureerde manier, springen er meteen allerlei Zend-evangelisten in mijn nek om proberen te laten zien dat ik een incompetent programmeur ben. Dat iets er niet staat betekend niet het er niet inzit. Ik wilde van mijn post geen compleet verslag maken, maar een overview laten zien van hoe mijn codelayout is voor de TS.

[ZpAz]

het gebruikt mijn manier van werken.

Leuk als je doelstelling is om een 'lone cowboy coder' te worden. Maar als je in een groep er aan gaat werken wil je toch een 'bepaalde mate van standaardisatie' er in stoppen.

Je hebt het de hele tijd over 'maar het past niet in mijn manier' maar hoe ben je er zo van overtuigd van geraakt dat die van jou duidelijk de betere oplossing is dan wat door vele slimme mensen in open-source projecten wordt toegepast.

Ik was 'vroeger' precies hetzelfde, ik deed alles zelf.... totdat ik Zend's Framework ging gebruiken...

[krvabo]

ZpAz schreef op maandag 09 mei 2011 @ 14:17:
[...]


Leuk als je doelstelling is om een 'lone cowboy coder' te worden. Maar als je in een groep er aan gaat werken wil je toch een 'bepaalde mate van standaardisatie' er in stoppen.

Uiteraard, en Zend is daar een van de manieren voor. Een andere manier is, zoals bij veel bedrijven, gebruikmaken van een eigen CMS of Drupal.
Het betekend niet dat als ik voor mezelf (of alleen) werk aan een project ik me moet houden aan groepswerk.

Je hebt het de hele tijd over 'maar het past niet in mijn manier' maar hoe ben je er zo van overtuigd van geraakt dat die van jou duidelijk de betere oplossing is dan wat door vele slimme mensen in open-source projecten wordt toegepast.

Hoe? Dat heb ik volgens mij al uitgelegd. Daarnaast, en het klinkt heerlijk pompeus, ben ik een goede programmeur met veel ervaring en ben slim genoeg om mee te kunnen doen met de 'vele slimme mensen' die je noemt. Ik maak zeker wel gebruik van andere soorten frameworks, ik maak gebruik van Smarty en JQuery, welke me beiden veel tijd schelen en heerlijk werken. Hiervan zie ik het nut in. Mijn eigen "framework" om mijn code overzichtelijk te houden werkt uitstekend en ik zie niet in hoe dit beter kan worden van een extern framework. Voor mij biedt het geen enkele meerwaarde, en _daarom_ gebruik ik geen Zend.
Wellicht is het voor andere mensen wél nuttig en als je het alsnog zelf gaat schrijven heb je er wellicht baat bij, maar aangezien dit stuk code al lang is geschreven heeft het dat voor mij niet.

[kwaakvaak_v2]

En dat is dan ook precies hoe mijn 'framework' werkt. Control-klassen worden ingeladen bij de request, de models met spl_autoload, maar er zijn nou eenmaal bestanden die je gewoon ingeladen wil hebben zoals een config-bestand, de exceptionhandler-klasse en het bestand wat de interfaces bevat bijvoorbeeld. Dit zijn allemaal bestanden die bij een pure tekstpagina niet nodig zijn, maar door het framework wel. Daar ging het over, niet over gezeik dat ik m'n hele docroot include.

Vooropgesteld, dat ik geen zend evangelist bent, sterker ik zou mijzelf eerder de anti-zend-christ willen bestempelen, omdat ik het geen prettig framework vind om mee te werken. En ja dat is persoonlijk, ik geloof niet in frameworks die alles en een keukenblok willen zijn in de basis. Eerder in een goede core met optionele modules/bundles of hoe je ze ook wil noemen.

En heb ook nergens gezegd dat je incompentent bent. Maar daar gaat het niet om. Als je een pure textpagina wil serveren vanuit je app, hoeft je toch niet je interfaces te laden als je de interfaces per stuk in hun eigen baseclass stopt? Dan heb je voor dat request enkel je router/execute script nodig en eventueel je config mocht je daar paden etc in gedefineerd hebben.