[php/mysql/framework] Eigen code of Framework?

[kramer65]

Hallo,

Via RentaCoder(.com) wil ik een project uitbesteden wat voor mij gewoon te veel werk (en ook wat te moeilijk) is. Ikzelf schrijf de php/andere code altijd volledig zelf. Dus geen frameworks of dingen als dreamweaver die dingen "voor je schrijft". Dit is meer uit een soort angst om controle te verliezen.

Nu heb ik dus iets op RentaCoder gezet en 1 coder zegt dat ie het gaat maken met phpOpenBiz. Ik had er zelf nog nooit van gehoord maar heb het eens bekeken (http://www.phpopenbiz.org/jim/). Verder had ik altijd het idee dat je altijd van "achter" moet beginnen met een database en dan de php en dan de interface. Deze vent zegt echter het volgende:

We prefer to start from User Interface because its easier to understand and agree on functionality when you are actually seen something.
At early stages data structure will be developed thru XML documents, than are more flexible that relational databases. At later stages we will transform those XMLs into databases or combination of databases and XML.

Snijdt dit hout? Is het te vertrouwen? Of krijg je dan een grote rotzooi die misschien zozo werkt en moeilijk is aan te passen?

Ook wil hij met OpenLaszlo werken. Ik weet dat pandora daarmee gemaakt is wat mij wat meer vertrouwen geeft. probleem is alleen dat ik dan bang ben dat ik het later moeilijk aan kan passen omdat ik zelf openlaszlo niet beheers en ik bang ben dat er niet heel veel mensen da beheersen.

Wat zijn jullie meningen?

[FragFrog]

kramer65 schreef op maandag 18 februari 2008 @ 11:51:
Nu heb ik dus iets op RentaCoder gezet en 1 coder zegt dat ie het gaat maken met phpOpenBiz. Ik had er zelf nog nooit van gehoord maar heb het eens bekeken (http://www.phpopenbiz.org/jim/). Verder had ik altijd het idee dat je altijd van "achter" moet beginnen met een database en dan de php en dan de interface.

Het is soms nuttig eerst je design te maken, inclusief forms etcetera, zodat je aan de hand daarvan je data model kan opstellen. Veel klanten hebben geen idee wat voor relaties ze tussen data willen totdat je ze een daadwerkelijk form geeft en ze met wijzigingen komen. Het is erg vervelend om een 1:1 relatie halverwege je project om te moeten zetten naar een 1:N relatie, om maar iets te noemen. In zoverre is dat wel te vertrouwen, er natuurlijk van uit gaande dat ze eerst de forms etc maken, dan een goed datamodel opzetten en dan pas gaan coden.

Zelf heb ik nog nooit met phpOpenBiz gewerkt, in mijn opinie is het gebruiken van een tool om je applicatie te maken garantie voor niet te onderhouden bloatware, maar zonder er meer over te weten is dit uiteraard niet met zekerheid te zeggen. Ik krijg er een beetje frontpage associaties bij, maar dat ben ik

Als je duidelijke eisen stelt aan hoe zwaar het mag zijn, hoe onderhoudbaar het moet zijn en wat het precies moet kunnen lijkt me dat je wel een aardig eind komt. Alternatief is een "echt" webdesignbureau inschakelen, maar ik ga er vanuit dat dit boven je budget valt. De eventuele risico's van rentacoder zul je dan voor lief moeten nemen vrees ik

[Niemand_Anders]

Deze manier van programmeren is op zich wel populair. Veel websites zijn 'beperkt' tot hetgeen wat de webpages aan functionaliteit bieden. Als er alleen een web frontend is voor de data store wordt regelmatig andersom (database wordt gevormd naar website ) gewerkt. Op deze manier kun je voorkomen dat je functionaliteit ontwerpt welke je nooit zal gebruiken.

Het gebruik van XML ipv een Database zal gebruikt worden om iteratief een data model op te zetten. XML is veel gemakkelijker te wijzigen dan een database. Het zal namelijk niet de eerste keer zijn dat requirements van een klant wijzigen tijdens de development fase.

Omdat deze manier van programmeren als snel een zichtbaar resultaat oplevert is dit een populaire manier van werken bij kleine projecten of bij klanten die eigenlijk niet precies weten wat ze willen. Omdat uitbereidingen meestal lastiger zijn toe te voegen is dit geen goede methode als de uiteindelijke website weer zelf als framework gebruikt gaat worden.

Over de frameworks zelf zal ik geen uitspraak doen omdat ik deze niet ken. Echter de meestal frameworks hebben meestal wel tutorials op hun websites waarmee het niet al te lastig moet zijn deze onder de knie te krijgen.

[kramer65]

Een "echt" webdesign bureau is idd ver boven mijn budget...

Bloatware is inderdaad ook mijn angst. Ik weet nog dat ik idd 1 keer frontpage code zag die een aantal enters als volgt hadden gedaan:

<P ALIGN="CENTER"> </P>
<P ALIGN="CENTER"> </P>
<P ALIGN="CENTER"> </P>


Daar komt idd ook mijn angst voor dit soort troep vandaan. Hierbij komt ook nog dat het mijn plan is om deze website (die hij zal gaan maken) redelijk groot te maken. Ik weet het, dat wil iedereen, maar dit doe ik met anderen en inclusief een marketing budget en een (kleine) investeerder. Als het dan begint te groeien wil ik natuurlijk niet al ons budget kwijt zijn aan servers. (Het is namelijk een muziek project = flinke server space & bandwijdte).

Maar xml documenten die daarna worden omgezet in databases.. Ik wist niet eens dat dat kon? Ik moet zeggen dat ik zelf ook nauwelijks gewerkt heb met xml, alhoewel het geloof ik wel de toekomst is.

"een populaire manier van werken bij kleine projecten"
Maar het is een vrij groot project. Ik heb alle front-end designs gemaakt in psd's/jpgs' en elke jpg beschreven in een tekstdocument. Dit heb ik gedaan om eens niet ervanuit te gaan wat ik (technisch gezien) kan, maar wat de bezoeker wil. Dat zij vanuit dit perspectief door zouden werken had ik even niet aan gedacht. Ik nam aan dat ze vervolgens eerst een DB design zouden maken..
Dat dit een populaire manier is voor kleine projecten, betekent dat dat het niet goed/efficiënt is voor grote projecten?

"niet al te lastig moet zijn deze onder de knie te krijgen".
Dat klinkt top. Maar wil dat dan zeggen dat hij als hij doorontwikkelt zal moeten worden ook in phpopenbiz MOET doorontwikkelt worden? Dat is een beetje mijn angst.

[Megamind]

phpopenbiz is een framework, en ja in princiepe moet je daar wel in doorontwikkelen, maar een beetje PHP coder kan zich gewoon daarin uitleven, dat moet geen probleem zijn.

Bij mijn vorige werkgever werd ik ook geacht in 1 dag Joomla () templates en plugins te schrijven.

[kramer65]

Haha. Mooi dat subtiele kots-icoontje.. :-)

Ik neem aan dat dat voor Joomla bedoelt was en niet voor je ex-werkgever. Waarom haat je joomla zo? Ik heb zelf nog een andere site met zo'n 100k dagelijkse pageviews (volgens analytics). Aangezien ik die zelf gecode heb tussen 2002-2004 is hij echt zo brak als ik weet niet wat. Ik heb er nu over na zitten denken om dat gewoon in Joomla te gooien (en code natuurlijk ook te updaten). Dan kan ik gewoon makkelijk een forum installeren, nieuwsposts doen, etc. etc. inplaats van weer zelf alles te gaan bouwen.

Iets mis mee? Denk je dat mijn site dan beduidend langzamer zou worden?

[Megamind]

Joomla is leuk zeker voor beginners, en het framework is erg uitgebreid. En daar houd ik niet van. Er zijn veel te veel rare kleine functies waar je rekening mee moet houden, en het is erg bloated allemaal. En als je iets leuks wilt dan moet je allemaal plugins installeren. Er zijn kleinere frameworks die hetzelfde of beter doen. Daar zijn genoeg topics over hier op got

[FragFrog]

Je zal ergens je DB ontwerp op moeten baseren. Veel, heel veel klanten hebben geen idee wat voor data ze precies krijgen en hoe dat aan elkaar linkt, of in ieder geval een incompleet beeld. Het baseren op de functionaliteit die de klant eist is dan een redelijk compromis in mijn opinie, zeker als je rekening houdt met uitbreidingsopties die de klant niet eist maar waarvan je uit ervaring weet dat erom gevraagd gaat worden. Vergaderingen met klanten zijn voor mij doorgaans 75% van de tijd proberen uit te vogelen wat hij nu eigenlijk wil en hoe dit toegepast moet worden

Zelfs dan nog zul je merken dat, zodra ze eenmaal zien hoe het werkt zoals ze omschreven hebben, ze vaak het toch weer anders willen. Vaak zie je dit aankomen (omdat ze het dom omschrijven ), soms niet, in zo'n geval zijn wat 'snelle' voorbeeld forms ideaal. Je besteed niet heel veel tijd aan iets coden wat uiteindelijk toch compleet anders moet werken.

Als je echt een grote commerciele site wilt hebben moet je in mijn opinie toch echt op zoek naar ofwel een inhouse codeteam, ofwel een professioneel bureau inhuren. Een dermate groot project heeft zoveel haken en ogen dat het uitbesteden aan iemand 'over internet' al snel verkeerd gaat. Jezelf limiteren tot een bepaald framework blijf ik riskant vinden, zeker als die kennis niet al in-house aanwezig is, ookal zijn ze vaak snel onder de knie te krijgen. Bijna elk framework komt met beperkingen, als je dan meer wilt dan de standaard zul je doorgaans veel moeite kwijt zijn aan het schrijven van plugins / hacks die je beter kan besteden aan de daadwerkelijke functionaliteit.

@ Megamind: een van mijn vorige werkgevers verwachtte dat ik in een uurtje of twee smarty kon, such is life Was voor mij een erg mooie gelegenheid om het te leren trouwens

[ Voor 12% gewijzigd door FragFrog op 18-02-2008 13:46 ]

[Johnny]

Of phpOpenBiz geschikt is ligt aan de aard van je project. Wat ik wel vreemd vind is de combinatie van OpenLaszlo, ik heb er ook een tijdje meegewerkt een paar jaar terug en ben er niet echt razend enthousiast over. Het is wel 'open' en relatief makkelijk aan te passen en in dat opzicht beter dan Flex maar het blijft een slecht toegankelijke en snel irriterende Flash-animatie.

Het is wel stand-alone te gebruiken maar als je een beetje serieus er mee aan de slag wilt heb je een OpenLaszlo (Java) server nodig. Laszlo kan ook geen directe verbinding maken met de database en kan alleen XML-bestanden uitlezen, daarom is die XML-laag ook nodig.

Ik zou eens een kijkje nemen in de portfolio van deze coder, en uiteraard moet je zelf ook goed beschrijven wat je nu precies wil, want je laat hier wat HTML-code zien terwijl ik denk dat je een back-end krijgt dat gebaseerd is op phpOpenBiz en als front-end een Flash-animatie die is gemaakt met OpenLaszlo.

[Niemand_Anders]

kramer65 schreef op maandag 18 februari 2008 @ 13:09:
Maar xml documenten die daarna worden omgezet in databases.. Ik wist niet eens dat dat kon? Ik moet zeggen dat ik zelf ook nauwelijks gewerkt heb met xml, alhoewel het geloof ik wel de toekomst is.

XML en SQL zijn beide data sources. Als niet direct duidelijk welke velden in een tabel nodig zijn, dan werkt XML soms wel fijn. Je kunt immers vrij gemakkelijk een extra xml element toevoegen of juist weglaten. Afhankelijk van de gekozen data layer kan vrij gemakkelijk worden geschakeld tussen XML en MySQL (of een andere database).

"een populaire manier van werken bij kleine projecten"
Maar het is een vrij groot project. Ik heb alle front-end designs gemaakt in psd's/jpgs' en elke jpg beschreven in een tekstdocument. Dit heb ik gedaan om eens niet ervanuit te gaan wat ik (technisch gezien) kan, maar wat de bezoeker wil. Dat zij vanuit dit perspectief door zouden werken had ik even niet aan gedacht. Ik nam aan dat ze vervolgens eerst een DB design zouden maken..
Dat dit een populaire manier is voor kleine projecten, betekent dat dat het niet goed/efficiënt is voor grote projecten?

Meestal inderdaad niet. Omdat je uitgaat van de schermen zal de database meestal weinig meer bevatten dan hetgeen welke de website ingegeven kan worden. De wijzigingen zelf zullen niet zo moeilijk zijn, maar meestal kosten ze dan wel meer tijd omdat meestal grotere delen van de applicatie aangepast moet worden. Voor een website module zoals een gastenboek is deze methode zeer geschikt. Als basis van een winkelmandje weer minder, omdat je dan met veelal niet zichtbare velden zult werken.

Maar je kunt ze toch ook vragen eerst een draft te maken van het database design. Deze kun je eventueel vergelijken met een model welke je zelf in gedachten had en daarover eventueel discusieren.

Soms 'verzin' ik af en toe wat kleine projecten zodat ik niet vergeet dat er soms ook simpele oplossingen bestaan. Onze applicaties worden dagelijks door meer dan 1000 (financiele) bedrijven intensief gebruikt. Wij hebben zowel web als (windows) desktop interfaces naar de applicaties. Alle data en business logica wordt bij ons door webservices afgehandeld. Deze webservices maken vaak weer gebruik van windows services. Alles redundant uitgevoerd en transaction c.q. atom based. Als gevolg daarvan kun je op een gegeven moment alleen nog maar groot en ingewikkeld denken.

"niet al te lastig moet zijn deze onder de knie te krijgen".
Dat klinkt top. Maar wil dat dan zeggen dat hij als hij doorontwikkelt zal moeten worden ook in phpopenbiz MOET doorontwikkelt worden? Dat is een beetje mijn angst.

Ik neem aan dat de website juist 'bovenop' phpopenbiz geschreven zal worden. Upgraden naar een nieuwere versie van phpopenbiz zal niet altijd even eenvoudig zijn, vergelijkbaar met het upgraden naar een nieuwere PHP versie zelf.

Meestal is het niet zo lastig om een dergelijk framework te begrijpen. Omdat phpopenbiz als framework geschreven is, zal deze code wel netjes eruitzien en vergezeld gaan van unit- en regression tests. De custom code is een heel ander verhaal. Afhankelijk van het object model en commentaar aanwezig in code maakt het soms lastig de gedachten van de programmeur te achterhalen.

Wel is het raadzaam regelmatig om een nightly build te vragen. Je kunt op die manier goed de vorderingen in de gaten houden, maar ze eventueel ook wijzen op bepaalde coding standaards die jij normaal aanhoud of andere 'rare' oplossingen.

[kramer65]

Pfoe. Das een hele lap tekst. Ik ben een hele stap verder zo met julie hulp.

@ Niemand_Anders. Volgens mij weet jij echt waarover je het hebt. Ik kan redelijk coden maar dingen als unit- en regression tests gaan mij net wat te ver..

Als ik nou kan kiezen tussen een aantal coders:

Argentijn, met phpOpenBiz/OpenLaszlo.
Indier, werkt met eerder gemaakte dingen
Roemeen. Code alles zelf

Ze hebben alledrie een prima track record op RentaCoder en mooie eerdere projecten die ze kunnen laten zien. Welke zou je dan voor gaan?
(Nationaliteiten zijn niet gegeven om te discrimineren, gewoon om er een herkenning aan te geven..)

[Verwijderd]

Persoonlijk zou ik toch gaan voor een implementatie in een voor PHP (of wat dan ook) gemaakt framework (waarbij ik geen uitspraak doe over phpOpenBiz, want deze ken ik niet). Een framework (zoals CodeIgniter of CakePHP die ik wel ken) biedt bepaalde gestandaardiseerde methodes om bepaalde operaties op een "min of meer" vaste manier uit te voeren (bijv. $this->Model->save($data) in CakePHP). Dit zou kunnen betekenen dat het eindresultaat over het algemeen genomen makkelijker leesbaar moet zijn (voor iemand die hetzelfde framework beheerst). Ik weet namelijk vrij zeker dat ik, doordat ik mn weg ken in CakePHP, projecten van anderen in dit framework vrij eenvoudig kan doorgronden.

Framework --> je hebt nog enigszins houvast, of de coder nou wel/niet documenteerd
Zelf gemaakt "framework" --> Als het al framework is... is het maar de vraag in hoeverre je dit framework begrijpt met de al dan niet aanwezige documentatie
Zelf gecode... tja dat hangt puur af van de documentatie en de Object georienteerde mate waarin wordt geprogrammeerd, puur procedureel gaat dan op zeker een zooitje worden!

[kramer65]

Super. Dan ga ik toch denk ik maar voor zo iemand die zoiets gebruikt. Maar dan is het natuurlijk wel makkelijk als ze een framework gebruiken wat veel gebruikt is. Dan kan ik het namelijk eventueel verder laten ontwikkelen door anderen.

Niemand schijnt phpOpenBiz te kennen. Ik vraag me af waarom hij het heeft gekozen dan..

Ik lees eigenlijk het meeste over CodeIgniter of CakePHP. Welke zijn volgens jullie zo'n beetje het meest populair?

Als je met 1 van die frameworks kan werken. Is het dan ook makkelijk om met een andere te werken?

En over zo'n nightly build. Dat is toch gewoon hoe ver iemand is gekomen die dag? Alles wat ie nu heeft?

Bedankt!

[Coju]

Voor CodeIgniter zou ik niet gaan. Ik heb het project een tijdje gevolgd en de ontwikkeling ligt eigenlijk zo goed als stil. CakePHP is wat dat betreft een betere keuze, zeker als php4-compabiliteit een issue is. Voor CodeIgniter is er ook een fork die wel volop in ontwikkeling is maar php5 als requirement heeft.

Je kan natuurlijk altijd kijken naar de andere usual suspects; symphony (php), ruby on rails of django (python)

Nightlies zijn zeg maar de code van een project zoals het er in die nacht was. Houdt in dat je de nieuwste features maar ook de laatste bugs erbij krijgt Nightlies zijn dus niet klaar om uitgebracht te worden als zijnde stable oid.

[ Voor 20% gewijzigd door Coju op 19-02-2008 17:51 ]

[orf]

vergeet dan ook Zend niet

[zwippie]

Coju schreef op dinsdag 19 februari 2008 @ 17:48:
Voor CodeIgniter zou ik niet gaan. Ik heb het project een tijdje gevolgd en de ontwikkeling ligt eigenlijk zo goed als stil.

Klopt ook niet helemaal, aangezien er net weer een nieuwe versie uit is.
Ik vind CodeIgniter nog steeds lekker werken, minder dwingend dan Cake bijvoorbeeld. Maar een silver bullet is er niet, een framework moet je aanstaan.

[lammert]

Ik vind CodeIgniter ook echt een aanrader: erg lichtgewicht en prima gedocumenteerd. Ter illustratie: de hele download is 2 MB, waarvan de userguide 1MB inneemt.

[Y0ur1]

orf schreef op dinsdag 19 februari 2008 @ 17:52:
vergeet dan ook Zend niet

Is Zend al een volledige framework? Ik heb het eens bestudeerd en het komt op mij over als meer losse componenten dan echt een framework, dus niet echt een web appliction framework. Ik ga een nieuwe project in symfony doen, cakePHP ook zwaar overwogen maar vond symfony toch net iets meer een profi uitstraling hebben en betere features hebben.

[Coju]

zwippie schreef op dinsdag 19 februari 2008 @ 19:50:
[...]

Klopt ook niet helemaal, aangezien er net weer een nieuwe versie uit is.
Ik vind CodeIgniter nog steeds lekker werken, minder dwingend dan Cake bijvoorbeeld. Maar een silver bullet is er niet, een framework moet je aanstaan.

Ik weet van de nieuwe versie maar ik vind de veranderingen niet erg indrukwekkend en bovendien heeft het te lang geduurt, komt bij de communicatie tussen developers en community niet erg denderend en veel bekende bugs niet worden gerepareerd. Ik zet m'n geld op Kohana.

Zend vind ik erg indrukwekkend, zeker de 1.5 pre-release met Zend_Layout en Zend_Form vind ik erg leuk. Stijle leercurve is een beetje een bezwaar voor velen. Heeft zeker toekomst, zeker voor wat grotere applicaties.

[Chip.]

Even een opmerking ik heb net dat openbiz gedownload en openbiz maakt gebruik van o.a. phpmailer, zendframework en smarty...

[Niemand_Anders]

Wouser schreef op dinsdag 19 februari 2008 @ 22:33:
Even een opmerking ik heb net dat openbiz gedownload en openbiz maakt gebruik van o.a. phpmailer, zendframework en smarty...

Dus een framework welke gebruik maakt van algemeen geaccepteerde frameworks en ze als een wrapper samenvoegt.

Lijkt mij geen slechte keuze om je website mee te bouwen.

[Hydra]

kramer65 schreef op maandag 18 februari 2008 @ 11:51:
Verder had ik altijd het idee dat je altijd van "achter" moet beginnen met een database en dan de php en dan de interface. Deze vent zegt echter het volgende:

Waarom zou je van 'achter' moeten beginnen? Je begint bij een ontwerp met use-cases. Een bekend gezegde is "If you dont know where youre going youll probably end up someplace else.". Je moet eerst weten wat je applicatie gaat doen, daarna ga je pas bedenken hoe je het gaat doen.

We prefer to start from User Interface because its easier to understand and agree on functionality when you are actually seen something.
At early stages data structure will be developed thru XML documents, than are more flexible that relational databases. At later stages we will transform those XMLs into databases or combination of databases and XML.

Juist als je met de database begint zit je aan het eind waarschijnlijk met een user interface die gericht is op de taken van de gebruiker, maar gericht is op het ontsluiten van de functionaliteit van de applicatie. Als je dan daarmee naar een gebruiker gaat, krijg je waarschijnlijk een hele hoop changerequests omdat ze de applicatie zelf anders voor ogen zien.

Wij maken eigenlijk altijd een prototype / proof of concept, en vaak in meerdere iteraties. De eerste zijn gewoon tekeningen op whiteboards, daarna statische HTML (in het geval van webapps) en daarna pas functionaliteit. Als je eenmaal vastgelegd hebt wat de applicatie gaat doen heb je ook veel minder kans op feature creep.

[Bosmonster]

Hydra schreef op woensdag 20 februari 2008 @ 13:59:
[...]

Wij maken eigenlijk altijd een prototype / proof of concept, en vaak in meerdere iteraties. De eerste zijn gewoon tekeningen op whiteboards, daarna statische HTML (in het geval van webapps) en daarna pas functionaliteit. Als je eenmaal vastgelegd hebt wat de applicatie gaat doen heb je ook veel minder kans op feature creep.

Je kan natuurlijk ook eerst gewoon een functioneel ontwerp maken.

[Bosmonster]

kramer65 schreef op maandag 18 februari 2008 @ 11:51:
Hallo,

Via RentaCoder(.com) wil ik een project uitbesteden ...

[...]

Ook wil hij met OpenLaszlo werken. Ik weet dat pandora daarmee gemaakt is wat mij wat meer vertrouwen geeft. probleem is alleen dat ik dan bang ben dat ik het later moeilijk aan kan passen omdat ik zelf openlaszlo niet beheers en ik bang ben dat er niet heel veel mensen da beheersen.

Wat zijn jullie meningen?

Pandora? Welke pandora bedoel je precies?

[Hydra]

Bosmonster schreef op woensdag 20 februari 2008 @ 15:58:
Je kan natuurlijk ook eerst gewoon een functioneel ontwerp maken.

Je kunt pas een FO maken als je weet welke functionaliteit de klant wil, helaas weten ze dat zelf vaak ook niet goed Als je een mockup maakt van jouw interpretatie van wat ze willen kunnen ze daar eerst gaten in schieten, uiteindelijk levert dat naar mijn mening iets op wat beter bij de wens van de klant aansluit (want tekst laat veel ruimte open wat betreft interpretatie, en uiteindelijk scheelt het tijd omdat je naderhand geen "ja maar die button moet links" gezeur krijgt.

Ik ken bedrijven die via een erg rigide watervalstructuur werken, iets opleveren waar 100% van de gedefinieerde functionaliteit in zit, maar als de klant dan dingen graag iets anders wil de klant laten wachten op een volgende 'release'.

[kokx]

Coju schreef op dinsdag 19 februari 2008 @ 21:21:
[...]

Ik weet van de nieuwe versie maar ik vind de veranderingen niet erg indrukwekkend en bovendien heeft het te lang geduurt, komt bij de communicatie tussen developers en community niet erg denderend en veel bekende bugs niet worden gerepareerd. Ik zet m'n geld op Kohana.

Zend vind ik erg indrukwekkend, zeker de 1.5 pre-release met Zend_Layout en Zend_Form vind ik erg leuk. Stijle leercurve is een beetje een bezwaar voor velen. Heeft zeker toekomst, zeker voor wat grotere applicaties.

Zend is loosly-coupled, waarmee bedoeld wordt dat je gedeelten van Zend kunt gebruiken zonder dat je gedwongen wordt om andere componenten te gebruiken. Vandaar dat het ook mogelijk is om bridges tussen frameworks mogelijk te maken (kijk bijvoorbeeld naar Symfony). Maar nog steeds is het mogelijk om mvc op een echte web framework manier te gebruiken (kijk naar Zend_Controller).

Al vind ik niet dat er een enorm stijle leercurve is. Vooral omdat je eerst een component kan gebruiken, en als je jezelf een beetje thuis voelt in de Zend stijl, het heel gemakkelijk is om verder te gaan met die stijl. Daardoor wordt het gemakkelijker om andere componenten van Zend te gebruiken. Ook werkt Zend meestal moeiteloos samen met andere code libraries.

[Bosmonster]

Hydra schreef op woensdag 20 februari 2008 @ 16:16:
[...]


Je kunt pas een FO maken als je weet welke functionaliteit de klant wil, helaas weten ze dat zelf vaak ook niet goed Als je een mockup maakt van jouw interpretatie van wat ze willen kunnen ze daar eerst gaten in schieten, uiteindelijk levert dat naar mijn mening iets op wat beter bij de wens van de klant aansluit (want tekst laat veel ruimte open wat betreft interpretatie, en uiteindelijk scheelt het tijd omdat je naderhand geen "ja maar die button moet links" gezeur krijgt.

Ik ken bedrijven die via een erg rigide watervalstructuur werken, iets opleveren waar 100% van de gedefinieerde functionaliteit in zit, maar als de klant dan dingen graag iets anders wil de klant laten wachten op een volgende 'release'.

Dat is wel waar in complexe projecten waar de klant het inderdaad misschien ook niet zo goed weet. Moet je wel heel voorzichtig zijn met de begroting, want voor je het weet zit je 3 jaar lang te prototypen voor fixed price

[Hydra]

Bosmonster schreef op woensdag 20 februari 2008 @ 16:57:
Dat is wel waar in complexe projecten waar de klant het inderdaad misschien ook niet zo goed weet. Moet je wel heel voorzichtig zijn met de begroting, want voor je het weet zit je 3 jaar lang te prototypen voor fixed price

Oh, tuurlijk, wij werken sowieso meer op een uurtje-factuurtje basis, in dat soort gevallen doe je een beperkt aantal iteraties en dan ligt de functionaliteit gewoon vast. Ik ben nu met een proof of concept bezig waarbij we dus gewoon met HTML schermen onze interpretatie van de wensen van de 'klant' (we krijgen er niet voor betaald in dit geval) toetsen. Zo'n dialoog geeft een klant uiteindelijk een beter gevoel dan een "ja maar dit is echt wat je gevraagd hebt" project heb ik het idee.

[Niemand_Anders]

[Antwoord op thread 'Kan combinatie eis zijn voor coders?' welke gesloten is en gerefereerd wordt naar deze thread]

Jij bent opdrachtgever en bepaald dus altijd waarmee geprogrammeerd zal gaan worden. Dergelijke bedrijven/programmeurs zullen je wel proberen te adviseren, maar het blijft altijd jouw beslissing.

Hou er wel rekening mee dat als programmeurs gewend zijn om met framework X te werken en jij wilt dat ze framework Y gebruiken, development tijd wel iets omhoog kan gaan. Smarty is geen programmeer taal. Via PHP kun je aan aantal objecten (strings, integers, arrays, objecten, etc) doorgeven aan Smarty en in smarty kun je deze vervolgens gebruiken. Hoewel Smarty enige support voor inline coding heeft, wordt het niet vaak gebruikt (scheiding code en presentatie).

Smarty (en dat geldt voor de meeste template engines) werkt met PHP. Wel kan het zijn dan een framework de voorkeur geeft aan een andere template engine, en zal de programmeur iets meer moeite moeten doen om Smarty te gebruiken.

Template engines worden voornamelijk gebruikt in MVC (Model View Controller) websites, waarbij de (frontend) controller alle informatie verzamelt en daarna de template engine aanroept. Bij de meeste MVC frameworks is het niet lastig om van template engine te switchen.

Het is jouw goed recht om aan te geven dat het project geschreven moet worden met CodeIgniter en Smarty. Jij betaald er immers voor..

[kramer65]

Jullie hebben gelijk... :-)

Nou zegt een coder Smarty als template engine te gaan gebruiken. Daar ben ik op zich tevreden over, wat voornamelijk is gebaseerd op deze post

Het is mij nu eigenlijk duidelijk dat het gebruik maken van een framework eigenlijk beter is gezien het voor op zich goede code zorgt waar bovendien makkelijker aan door kan worden gewerkt door anderen nadat het eenmaal ontwikkeld is.

Nou begreep ik dat die phpframeworks vaak al een (simpele) template engine hebben. Door die smarty post hierboven wil ik echter wel graag Smarty gebruiken, en bovendien zeggen die coders dat ze graag Smarty gebruiken. Ze zeiden echter: "we are using 'Smarty' and we can do the core programming as well".

Wordt er bij het gebruik van Smarty meestal alle code zelf geschreven?
Belangrijker; Is het een vreemde eis om te zeggen dat ze het met bijvoorbeeld CodeIgniter in combinatie met Smarty moeten ontwikkelen? (zou moeten kunnen volgens dit artikel)

Ik ga straks met ze in een chat en wil daarom even goed voorbereid zijn.. Alle hulp is welkom!

[kramer65]

Nu zegt hij dat ze nu cakephp aan het onderzoeken zijn maar dat hij zou aanraden om het hun in hun eigen code te laten doen.

Zou dit heel erg afbreuk doen aan de mate waarin andere coders aan dit project door kunnen werken?

Ik heb ook nog de keuze om het door iemand anders te laten doen. Zou dit een dealbreaker kunnen zijn voor jullie?

[FragFrog]

Het probleem is dat je niet zelf een ontwikkelaar in huis hebt danwel een onderhoudscontract hebt. In wat voor framework het ook gemaakt gaat worden, zodra degene die het moet onderhouden het niet kent heb je een leerperiode nodig.

De kans dat iemand die het gaat onderhouden bekend is met CakePHP en of Smarty is best aardig maar evengoed zegt dat niet alles. Als ze goede, nette code afleveren in hun eigen framework kan dat prima beter te onderhouden zijn dan iets gemaakt in CakePHP. Zodra je mensen forceert met iets nieuws te werken kun je er vanuit gaan dat de code die daarmee geproduceert wordt in het begin van mindere kwaliteit zal zijn. Immers, hoe beter je iets kent des te meer middelen je hebt om een doel te bereiken, goed programmeren is vooral het juiste middel voor het juiste doel gebruiken. Ik zou het persoonlijk dan ook niet vereisen, noch het reden vinden om een ander op te zoeken.

Maargoed, uiteindelijk kan enkel degene die het gaat onderhouden een oordeel vellen over de code, voor ons blijft het speculeren.

[kramer65]

Hallo,

Na lang wikken en wegen zegt die coder nu dat hij het in phpopenbiz en oplaszlo ontwikkeld, en het daarna omzet naar een volledige flash website.

Ik heb echter gezegd dat ik daar absoluut niet mee akkoord kan gaan. Volgens mij laadt het langzamer, is het onmodelijk om te lezen voor spiders/bots, en is het bovendien moeilijker aan te passen. Daar komt bij dat ik het zelf ook vaak irritant vind omdat je bijvoorbeeld text niet kan copieren, de url onbruikbaar is, en de backbutton niet werkt.

Hij zegt dat SEO geen probleem is omdat de website in xml wordt gepresenteerd aan bots en dat het door het gebruik van flash ook browser/platform independent is. Dat laatste geloof ik wel, maar dat eerste niet echt.

Wat vinden jullie hiervan?

[orf]

Niet doen, volledige Flash websites zijn leuk voor popartiesten, kunstenaars en portfolio's. Sites met voornamelijk tekst als content zijn veel beter af zonder Flash (wellicht hier en daar een Flash element). SEO is zeker een probleem met Flash (ook al is er een alternatief).

Vergeet ook toegankelijkheid niet. Tekstgrootte, screenreaders, etc werken allemaal niet in Flash.

[kramer65]

hij zegt nu dat hij het ook in Dhtml kan doen (OpenLaszlo kan dat omzetten).

Wat vinden jullie daarvan dan?

[orf]

Wat verstaat hij onder DHTML?
Een pagina opgeleukt met JavaScript handigheden of bijna volledig JavaScript gegenereerde content? Dat laatste wil je ook niet.

Waarom kan hij niet gewoon HTML en CSS als output (daar is Smarty juist handig mee!).
Het klinkt als een coder die geen 'gewone' HTML kan/wil gebruiken.

Edit: Gegenereerde code (html) is altijd fout. HTML zet je met de hand op naar templates, die vul je vervolgens dynamisch.

[ Voor 16% gewijzigd door orf op 28-02-2008 20:16 ]

[Bosmonster]

Eerlijk gezegd zou ik het vertrouwen al een beetje kwijt zijn nu die begint over een volledige Flash website en dan weer dat ie het kan 'omzetten' naar DHTML...

Welk PHP framework die gebruikt zou mij eerlijk gezegd een worst zijn, zolang hij maar bekend is ermee. Ik vind het belangrijker dat de developer er bekend mee is en er iets goeds in kan maken dan dat je de developer het laat maken in een voor hem onbekend framework, alleen maar om een toekomstige developer die het moet onderhouden daar wel bekend mee is. Laat dan de developer die het moet onderhouden dat andere framework leren.

[Duroth]

Ik zou gewoon kiezen voor de kerel die besluit de website volledig in Flash uit te voeren. Dan kan je er nog iets mee
</sarcasme>