Design combineren met PHP

[SvMp]

Met bepaalde programma's kun je heel mooi WYSIWYG websites designen. Het kladblok werkt prima, maar als de layout wat gecompliceerder is gebruik ik toch liever wat hulp.

Nu wil ik een site bouwen met PHP. De site is vrijwel geheel dynamisch.
Hoe doen jullie dat in combinatie met zo'n webdesign programma, bijvoorkeur het Macromedia spul? Maak je eerst een mooie layout, en daarna paste je het in een PHP-script? Wat is de beste aanpak?

Een ander aspect waar ik jullie mening over wil horen: Grote delen kun je natuurlijk statisch maken, maar omdat zo'n website overal hetzelfde moet zijn, is het irri dat je bij een verandering in de layout steeds weer tientallen statische html-etjes moet aanpassen. Hoe pakken jullie dat aan: De hele site dynamisch, zodat de layout door 1 PHP-include gebeurt, of zijn er nog andere methodes?

[sdomburg]

Ik maak zelf eerst het HTML gedeelte, om vervolgens met Dreamweaver (4) de php erin te bakken, de variabele php gedeeltes worden dan mooi met een php icoontje weergegeven in het WYSIWYG gedeelte, en in de code kan je mooi met je php kutten

[Ramon]

volgens mij kan je beter éérst concentreren op de serverside coding, en daarna een mooi design eromheen maken.

[sdomburg]

Tampie2000 schreef op 17 augustus 2002 @ 21:55:
volgens mij kan je beter éérst concentreren op de serverside coding, en daarna een mooi design eromheen maken.

Depends met wat je met je site wil doen jah.

[Dark Blue]

Ik heb altijd nogal een vast stappenplan. Ik ga eerst een nachtje er diep over nadenken, wat is de content en hoe wil ik het presenteren. Je tekent op een klein kladblaadje een schets voor je website, met allemaal flashy dingetjes en een flexe layout die je wel denkt in html te kunnen uitwerken zonder dat je voor elke pixel een apart bestandje moet aanmaken.

De volgende ochtend word je wakker, je kijkt nog es naar het frommeltje papier en ziet opeens nog 10 andere mogelijkheden. Je werkt het uit, met zoveel mogelijk layers want dan kun je nog van alles ombouwen mocht je aan het einde van je design toch aan een hele andere uitwerking komen; dat is bij mij nml. meestal het geval Dan ga je kijken naar: hoe kan ik het sneller, simpeler maken. PHP is er juist voor om alles niet alleen dynamischer te maken, maar ook om het aantal bestanden en het telkens herhalen van vaste onderdelen van een html-pagina te kunnen vervangen door een simpele include, hoewel, headers en footers, daar begint het mee.

Ik streef er naar om een website zo compact mogelijk te maken. Eerder had ik daarvoor: hebben alle contentpagina's een standaard header en footer? Mooi, dan maak ik een bestandje header.inc.php en een footertje, en die include je. Tegenwoordig doe ik het andersom: je bouwt de html-pagina op, en je gaat eens kijken wat er 'statisch' aan is je je gaat kijken wat er bij elke vorm van content verandert, dus dynamisch mag zijn. Hoppa, dat knip je er tussenuit, en je zegt _{pseudo code} include 'content/ '.$naam'.php.
(ik heb de gewoonte om de $naam dan in het adres mee te sturen... )

Maar de meeste van mn php sites zijn eerst altijd opgebouwd uit puur html en css; pas als alles op de goede plek staat, ga ik alle style="blaat" wegslopen en die in een aparte css file dumpen, en ga ik kijken waar je handig gebruik kunt maken van 1 mal en daar wel vijftien templates met elk hun eigen content in kunt gieten.

_{ik mag niet spammen maar wel zeggen dat ik dit nu vertel met mijn persoonlijke homepage als voorbeeld...}

[Verwijderd]

Eerst design, dan scripting dan scripting in design verwerkebn

[Dark Blue]

Verwijderd schreef op 17 augustus 2002 @ 22:51:
Eerst design, dan scripting dan scripting in design verwerkebn

Voor iedereen die mijn geblaat hierboven niet wil lezen, dit is de samenvatting

[Copyman]

Zoals ik het doe:

Ik maak een grafische layout in PS, daarna maak ik er een compleet werkende HTML layout zonder content. Van tevoren wel een ontwerp maken van wat je er allemaal op wilt hebben, denk bijvoorbeeld aan grafische buttons.
Daarna begint je met PHP coden.

De laatste die ik heb gemaakt bestaat bijvoorbeeld uit een header.php en een footer.php, dan maak je onder button/link bijv. news een link naar bestand news.php. Deze bevat dan de data voor news. In die news.php include je dan die header-en footer.php. Zo kan je het bij elke button/link weer toepassen, bijvoorbeels ook bij downloads (download.php).

Suc6

[ Voor 0% gewijzigd door Copyman op 17-08-2002 23:28 . Reden: typo ]

[Tim Schuhmacher]

Naast wat hierboven staat probeer ik zoweinig mogelijk phpcode in de pagina zelf te stoppen - zoveel mogelijk code in aparte bestanden. Wat ik hierbij vooral het lastigste vind is om een goed foutafhandeling te doen. Je kan wel een string met een foutmelding uitpoepen zodra een fout voorkomt, maar dan wordt de layout geheid verprutst.

Databaseverbinding leg ik altijd aan het begin van de pagina. Daar moet dan ook al een deel van de foutafhandeling komen en verderop 'tussen de htmlcode' allemaal controles of er wel of niet een fout geweest is, zodat je niet een functie aanroept die een dbconnectie nodigt heeft terwijl die er bv niet is. Dit levert dus alleen maar meer phpcode tussen de html door.

[Thijsmans]

Voor het probleem met 1000 en 1 pagina's veranderen: php+templates

[Verwijderd]

Ik schets een website eerst op papier.
Als ik dan precies weet hoe het erut komt te zien maak ik de php gedeelte.
Daarna maak ik alles om het php gedeelte erom dus de layout enzo klaar.
En dan heb je een dynamische website.

[Verwijderd]

Dark Blue schreef op 17 augustus 2002 @ 23:00:
[...]

Voor iedereen die mijn geblaat hierboven niet wil lezen, dit is de samenvatting

Zoals je wilt

[Bluestorm]

Als design en php (of andere taal natuurlijk) door verschillende personen gedaan wordt ontkom je eigenlijk niet aan eerst designen en daarna netjes in HTML uitwerken voordat er geprogrammeerd gaat worden.

Als ik alles zelf doe heb ik twee methodes:
Is er een klant bij betrokken? Dan willen die vaak snel resultaat zien: eerst virtueel screenshot in photoshop bouwen dan. Daarna maak ik alle functionaliteit (vacaturebank, forum, nieuws, wat dan ook) gewoon in simpele HTML tabellen en ga dat dan met PHP werkende maken. Ondertussen heeft de klant ook gezegd wat ie van het ontwerp vind en kun je daar af en toe ook nog aandacht aan besteden. Als het dan beide af is: Ontwerp verHTML'en en plakken in je php files / templates.

Nu vind ik dat voor hobby projecten nog te moeilijk, want ik wil snel resultaat... dus begin ik daar meteen met alles in simpele HTML voor te stellen... daarna te programeren en uiteindelijk er nog eens een design voor te bakken.

In iedergeval doe ik het liefst zoveel mogelijk verschillende dingen tegelijkertijd, ik kan niet eerst dagen lang ontwerpen en daarna dagenlang met php bezig zijn. Het moet zich een beetje afwisselen en zo kun je ook de klant ontwikkelingen van zowel design als functionaliteit laten zien.

[Verwijderd]

Wat ik het handigst vind wat al 100 x gezegt is. Eerst html-en dan php-en en evt html aanpassen. Dit geeft vaak als voorbeeld dat als je alle html af hebt. Dat je en goed overzicht hebt wat het script moet doen enzo. Als je eerst gaat php-en dan kan je daar nog wel eens de mist in gaan. (teminste. HEb ik wel eens.) . Meestal laat ik ook mijn html lay outs maken. En code ik ze daarna.

[Verwijderd]

Eerst op papier je idee schetsen, dan in Photoshop namaken (er komt altijd iets heel anders uit dan ik in eerste instantie in gedachten had) en deze in een tabel zetten in html, zonder php.

Vervolgens de statische / dynamische dingen eruit halen en deze in php met includes verwerken, vervolgens de content in een los bestand / database zetten en dan een mooie navigatie eraan vast zetten.

9 van de 10 keer dat ik zo werk.

_{Ivy is terug van vakantie.....}

[roelkw]

Ik ben het niet helemaal eens met iedereen hier.. maar goed, ieder zijn eigen manier!

Zelf werk ik veel in projecten, samen met anderen. Meestal gaat het dan om twee programmeurs en één designer. De designer in mijn team hoef je niet eens te proberen PHP uit te leggen; dat lukt gewoon niet.
Zelf zijn we ook erg lang bezig geweest om een werkbaar plan te maken. Dit resulteerde uiteindelijk in een eigen XSL/XML-parser voor PHP. De content, bijvoorbeeld uit een database, wordt in een XML-bestand opgeslagen (of gewoon direct dynamisch aangeleverd, maar voor statische data kun je ook vaak opslaan, dan hoef je de database niet te benaderen --> snelheid!).
Het design bestaat gewoon uit HTML-pagina's, maar met een aantal XSL-attributen erin, zoals:

code:

<xsl:value-of select="data/name"/>

Maar de parser kan eigenlijk alle XSL aan, dus ook de <xsl:if>'s en dergelijke. Onze designer kan hier wel mee omgaan. Van tevoren bepaal je met z'n drieën hoe je de site opzet, wie wat doet. Daarbij komt bij ons ook: welke gegevens wil je op de pagina weergeven? Natuurlijk is dat ook heel makkelijk veranderen later. Op deze manier kun je ook verschillende templates maken; de PHP-pagina's veranderen nooit!

1 tip: houdt HTML en PHP altijd gescheiden. Later zul je daar heel blij mee zijn. XSL/XML/PHP werkt voor ons prima, en dat kun je in principe voor elke site gebruiken. Het vergt even een klein beetje meer opzet, maar zo kun je de boel echt dynamisch houden en ook prima met meerdere mensen in een team werken.


Misschien was dit een beetje vaag verhaal; als iemand iets niet snapt of een voorbeeldje wil, moet je 't maar ff melden!

[supersook]

ik weet niet hoor, maar zijn voor hetgeen de topicstarter bedoelt templates niet hartstikke handig?

[drm]

Ik denk dat de meest eenvoudige manier is om templates te ontwikkelen in PHP.

Denk daar bij aan dit soort dingetjes:

PHP:

<html>
   <head>
       <title><?=$output [ 'title' ]?></title>
       <link rel="stylesheet" type="text/css" href="./css/style.css" />
   </head>
   ...

Deze pagina's kun je include, waar je output wenst

PHP:

include ( './tpl/main.tpl' );

vervolgens kun je daar allerlei ingewikkelde en minder ingewikkelde dingen mee gaan maken, maar basis blijft dat je logica en layout redelijk gescheiden houdt.

Bedenk daarbij wel, dat je bij je layout ook wel eens logica nodig hebt. Stop die dan in je template, niet in de rest van je php code.

Wat is dan "de rest van je php code?". De rest van je PHP code is de code die de data uit je database trekt, rechten checkt, etcetera.

Kortom, templates zijn de "presentation layer". En voor die templates heb je echt geen 1337 template engines nodig, met PHP kom je een heel eind (meestal zelfs verder dan "gewone" template engines).

[ Voor 0% gewijzigd door drm op 19-08-2002 14:21 . Reden: React == brak :D &#039 = natuurlijk ' (enkele quote) ]

[Genoil]

wat doe je daar nou met die '?

[Verwijderd]

mijn stappenplan:
1 maak een heftig design
2 ga er je PHP meuk omheen bouwen
3 herschrijf de boel omdat het onoverzichtelijk is en niet efficient werkt.

[Rickets]

Genoil schreef op 19 augustus 2002 @ 15:18:
wat doe je daar nou met die '?

Dat is gewoon "

[drm]

Genoil:
wat doe je daar nou met die '?

*wijst naar react

Hij! Hij!!!!!

[SillyJW]

roelkw schreef op 19 augustus 2002 @ 12:34: [..] Misschien was dit een beetje vaag verhaal; als iemand iets niet snapt of een voorbeeldje wil, moet je 't maar ff melden!

Ja! voorbeeldje
Ik ben namelijk zelf ook aan t neuzelen met xml/xsl, maar ben na al dat geneuzel ben ik eigenlijk een beetje de draad kwijt. Daarmee bedoel ik dat na al de intake van info over xml/xls wil ik wel eens zien hoe het nu in de praktijk gebruikt kan worden.

[Verwijderd]

Ik gebruik persoonlijk het liefst een goede template engine, zodat je juist de abstractie verder kunt doorvoeren. Gewoon plain html met hier en daar voor de content [tags] en mocht die content ook weer moeten worden voorgegeven gebruik ik daar ook weer diezelfde template engine voor.

Ik geef toe, best lastig voor de gemiddelde beginner maar als je eenmaal gewent bent aan template based php wil je echt niet meer terug naar echo $var based php.

[roelkw]

SillyJW schreef op 19 augustus 2002 @ 21:45:
[...]

Ja! voorbeeldje
Ik ben namelijk zelf ook aan t neuzelen met xml/xsl, maar ben na al dat geneuzel ben ik eigenlijk een beetje de draad kwijt. Daarmee bedoel ik dat na al de intake van info over xml/xls wil ik wel eens zien hoe het nu in de praktijk gebruikt kan worden.

You've got mail..
als er nog meer mensen geïnteresseerd zijn, moeten ze 't maar ff zeggen.

[Verwijderd]

roelkw schreef op 19 augustus 2002 @ 23:32:
[...]


You've got mail..
als er nog meer mensen geïnteresseerd zijn, moeten ze 't maar ff zeggen.

doe mij er ook maar eentje

wat jij doet klinkt erg handig, en is ook n stukkie makkelijker dan mijn 3-stappenplan gok ik

[Ericston]

Dark Blue schreef op 17 augustus 2002 @ 22:42:
(ik heb de gewoonte om de $naam dan in het adres mee te sturen... )

[...]

_{ik mag niet spammen maar wel zeggen dat ik dit nu vertel met mijn persoonlijke homepage als voorbeeld...}

m.a.w. je homepage is lekker vulnerable voor mensen die gaan prutsen met GET vars...

[The Source]

bekijk dreamweaver ultradev of dreamweaver mx eens. Daarmee is het mogelijk om gebruik te maken van php en te werken in een wysiwyg omgeving. Door de live data preview optie van dreamweaver mx kun je alle data uit een database tijdens het ontwikkelprocess bekijken in het design en daardoor hoef je niet steeds te switschen tussen verschillende ontwikkelomgevingen.

[Verwijderd]

Ericston schreef op 20 augustus 2002 @ 00:35:
[...]


m.a.w. je homepage is lekker vulnerable voor mensen die gaan prutsen met GET vars...

Ik neem aan dat het werkt met $_GET['varnaam'] en dat ze de waardes van $_GET checkt voordat ze wat doet...

[Expecho]

roelkw schreef op 19 augustus 2002 @ 23:32:
[...]


You've got mail..
als er nog meer mensen geïnteresseerd zijn, moeten ze 't maar ff zeggen.

Nou eerlijk gezegd ben ik ook wel nieuwsgierig

[drm]

roelkw:
Ik kan nou wel zeggen dat ik ook nieuwsgierig ben, maar waarom zet je niet even een voorbeeldje incl. source online?

[ Voor 0% gewijzigd door drm op 20-08-2002 13:16 . Reden: addressee added :z ]

[Verwijderd]

Verwijderd schreef op 20 augustus 2002 @ 12:41:
[...]

Ik neem aan dat het werkt met $_GET['varnaam'] en dat ze de waardes van $_GET checkt voordat ze wat doet...

Niet dus Server was theoretisch geroot door deze "bug". We hebben de security flaw in een mailtje uitgelegd en het is inmiddels opgelost (zo blijkt).

[prototype]

Verwijderd schreef op 20 augustus 2002 @ 13:50:
[...]

Niet dus Server was theoretisch geroot door deze "bug". We hebben de security flaw in een mailtje uitgelegd en het is inmiddels opgelost (zo blijkt).

Hopelijk heeft men hiervan geleerd

[Ericston]

Verwijderd schreef op 20 augustus 2002 @ 13:50:
[...]

Niet dus Server was theoretisch geroot door deze "bug". We hebben de security flaw in een mailtje uitgelegd en het is inmiddels opgelost (zo blijkt).

nobody.#-1 rechten is nog niet geroot.

[roelkw]

Owkeej, zoveel reacties ondertussen, ik zal wel even wat online gooien. Momentje hoor, dan zal ik er ook wat uitleg bij zetten enzo!

[update]
Uitleg
Helaas nog geen praktijkvoorbeeldje beschikbaar, maar alvast wel een uitleg over hoe het in elkaar zit, een stukje duidelijker dan mijn verhaal hierboven.

[ Voor 0% gewijzigd door roelkw op 20-08-2002 22:38 . Reden: uitleg klaar ]

[WouterG]

Verwijderd schreef op 20 augustus 2002 @ 13:50:
[...]

Niet dus Server was theoretisch geroot door deze "bug". We hebben de security flaw in een mailtje uitgelegd en het is inmiddels opgelost (zo blijkt).

Mag ik dat mailtje ook? Ik gebruik volgens mij dezelfde manier maar wil meer weten over veiligheid.