Kjapp og trygg hosting for Wordpress

Front-end og back-end

Dostojevskij

Dostojevskij

Medlem
1) I hvilken rekkefølge er det vanlig å gjøre dette? Hvis man skal utvikle en nettside med PHP, er det da vanlig å lage back-end i PHP og HTML først, og deretter legge på alt som har med design (F.eks. CSS og JavaScript) etterpå?

2) Hvis jeg skal lage back-end til en side og en annen skal ta seg av front-end, er det da naturlig at jeg gjør alt mitt først, og deretter overlater front-end til den andre personen? Og kan jeg forvente at som kan front-end (f.eks. CSS, JavaScript, JQuery osv) skal klare lage designet på et prosjekt jeg har utviklet i PHP/Laravel uten fokus på design?
 
H

Hashead

Member
Ideellt sett så er de helt uavhenige av hverandre. Med klassisk databasedrevet utvikling slik du gjør her, så er det hensiktsmessig å bruke en eller annen form for templating verktøy som fungerer som en bro mellom front og backend.

I Drupal, og Wordpress også regner jeg med, så er det fastsatt et format på dataen som leveres til frontenden, slik at personen som jobber med frontenden står fritt til å plassere ting der vedkommende ønsker.

I praksis så burde du og front end uvikleren din bestemme deg for et templating rammeverk, jeg synes Mustache ser bra ut, så kan dere begge i stor grad jobbe uavhengig av hverandre.

tl;dr
Backend burde levere rådata i json/xml, ikke html.
 
H

Hashead

Member
Mente ikke å si at du ikke burde bruke html, men at backenden's jobb slutter når den har produsert dataen som skal presenteres for sluttbruker. Hvordan den dataen struktureres som html og presenteres på skjermen er frontendens oppgave. Du leverer altså json, ikke html til frontenden.

Du gir frontenden en json objekt som inneholder dataen som skal vises, og han gjør resten. Det er i alle fall slik det er vanlig å skille mellom de to
 
Dostojevskij

Dostojevskij

Medlem
Hashead skrev:
Du gir frontenden en json objekt som inneholder dataen som skal vises, og han gjør resten.
Klikk for å utvide...

Hm, skjønner ikke helt poenget med det, hvorfor ikke bare hente det direkte fra databasen i stedet? Og synes det virker lettere at jeg også lager html, eventuelt etter front-end-utviklers ønske.
 
H

Hashead

Member
Hvis du bare skal hente data fra databasen så vil backenden følgelig være liten, og jobben også.

Fordelen med å skille de er at logikk og presentasjon skal være adskilt, slik at det er enkelt å endre den ene uten at det nødvendigvis påvirker den andre. Da kan du f.eks bytte ut hele frontenden ( f.eks for en mobil app eller rest api, eller bare et annet theme ) uten at du trenger å endre backenden. Hvis backenden din serverer html, så blir det en mye mer omfattende sak å bytte ut frontenden.

Man skal alltid arbeide mot et api/interface, ikke en implementasjon, slik at man oppnår gjenbrukbarhet.
 
Sist redigert:
xdex

xdex

Medlem
Her er det snakk om preferanser, samtidig som du er litt avhengig av hvilket språk du jobber i. Jeg har jobbet mye i Laravel de siste årene, og jeg liker best om HTML struktur er ferdig før jeg begynner å integrere noe som helst. Men, du kan fint sette opp databasen, migrations etc i laravel, før du har sett noe som helst. Så kan du evt. jobbe litt med sikkerhet, men det er litt preferanser også. Bruk f.eks github til å jobbe bedre sammen, slik at begge alltid får det som er oppdatert.

En front-end developer, skal kun ta seg av html/css/js (uten spørringer mot backend etc) og annet som vises visuelt. Det er likevel en fordel om frontend kan noe backend, men det blir ofte bare tullete uansett. Hvorfor? fordi alle har "sin måte" og utvikle på. Laravel bruker jo blade, og det tar ikke lang tid og sette seg inn i dette, samt enkele routes, men dog igjen, det kan fort bli litt tullete dersom backend utvikler har en god plan.

Docs,
http://laravel.com/docs/5.0/templates

MERK, endelig er Laravel 5 offentlig.
 
Dostojevskij

Dostojevskij

Medlem
Hashead skrev:
Da kan du f.eks bytte ut hele frontenden ( f.eks for en mobil app eller rest api, eller bare et annet theme ) uten at du trenger å endre backenden. Hvis backenden din serverer html, så blir det en mye mer omfattende sak å bytte ut frontenden.
Klikk for å utvide...

Ja, dette høres faktisk ganske nødvendig ut for min del, da jeg jobber med et prosjekt som noen andre trolig skal gjøre front-end på og som vi har planer om å lage app av. Bør jeg bruke json eller xml? Er det vanskelig å lære seg og blir det mye ekstra jobb? Og ikke minst, er det enkelt å gjøre dette gjennom Laravel (Som jeg har blitt veldig glad i)?

Takk for gode svar forresten!
 
Dostojevskij

Dostojevskij

Medlem
xdex skrev:
Her er det snakk om preferanser, samtidig som du er litt avhengig av hvilket språk du jobber i. Jeg har jobbet mye i Laravel de siste årene, og jeg liker best om HTML struktur er ferdig før jeg begynner å integrere noe som helst.
Klikk for å utvide...

Så du begynner med å lage alle views?
 
Dostojevskij

Dostojevskij

Medlem
xdex skrev:
Det kan være en fordel å sette opp routes i starten ja, for å "planlegge" litt utover, slik at du slipper kræsj. Gjelder spesielt hvis du f.eks bruker domene.com/brukernavn og andre fancy navn / wildcards.
Klikk for å utvide...

Hvorfor bruker du ikke json eller xml, som Hashead foreslår?
 
H

Hashead

Member
Dostojevskij skrev:
Ja, dette høres faktisk ganske nødvendig ut for min del, da jeg jobber med et prosjekt som noen andre trolig skal gjøre front-end på og som vi har planer om å lage app av. Bør jeg bruke json eller xml? Er det vanskelig å lære seg og blir det mye ekstra jobb? Og ikke minst, er det enkelt å gjøre dette gjennom Laravel (Som jeg har blitt veldig glad i)?

Takk for gode svar forresten!
Klikk for å utvide...
Bruk json. Ingen bruker xml lengre. Vær dog obs på php sine json gotchas mtp array/objekt konvertering.

Hvis du har planlagt å lage en app ut av det, så er du tjent med å bygge backenden din som et rest api som både en web klient og app klient vil kunne snakke med. Et interface til flere grensesnitt.

Hvis laravel har funksjonalitet for rest apier, så kan du abstrahere "høyere" ved at api kallene kaller samme funksjon som form submissions gjør. Da gjør backenden en del av frontendens jobb, så det bryter med regelen, men det er lov å jukse litt for å få ting på plass kjappere. Da blir det en nettside med et rest api, i stedet for at frontenden implementerer backends rest api, som hadde vært det mest ryddige.

Jeg har gjort dette før i andre rammeverk, og det funker fint. Det er dog noe som kan bite deg i ræva senere, og er bare ikke så sexy :)
 
Sist redigert:
H

Hashead

Member
Må være litt uenig med meg selv her :) Hvis frontendutvikleren din kan eller er villig til å lære seg et frontend javascript rammeverk, så er det den absolutt beste løsningen i min mening. Da lager du backenden din med Laravel som et rest api som frontendutvikleren implementerer.

Jeg kan anbefale AngularJS på det varmeste, men er mange å velge mellom
https://github.com/showcases/front-end-javascript-frameworks

Da oppnår du:
Et skille mellom presentasjon og logikk
Når nettsiden er ferdig har du et api som en app kan implementere.
En "stateless" frontend, som hjelper enormt med skalering
 
Sist redigert:
xdex

xdex

Medlem
Dostojevskij skrev:
Hvorfor bruker du ikke json eller xml, som Hashead foreslår?
Klikk for å utvide...

Skjønner ikke helt hva du mener med å si det der. Hvis du ikke helt skjønte hva jeg mente, kan du se på: http://code.tutsplus.com/tutorials/laravel-4-a-start-at-a-restful-api-updated--net-29785 selv om denne nå er udatatert.

Dersom dette er en "live-app" som skal kjøre endel live updates, på samme måte som facebook f.eks. ville jeg aldri brukt laravel, da hadde jeg heller gått for node. Men regner ikke med dette er noe slikt, siden det fra start av har vært snakk om php. Kan jo selvfølgelig samkjøres, men kan ikke skjønne hvorfor man skal gjøre det.
 
Du må logge inn eller registrere deg for å svare her.
Topp