[php] nieuw templateobject binnen class

[Verwijderd]

Op dit moment ben ik in opdracht van een bedrijf in de detailhandel bezig met het bouwen van een E-commerce-applicatie in PHP. Vanwege de integratie met het huidige kassasysteem, boekhouding en produktendatabase wordt het een nogal omvangrijk project. Om alles een beetje overzichterlijk te houden heb ik besloten om het een en ander in OO te programmeren. Ik heb voor Smarty als templateengine gekozen, smarty is een Class.

Nu loop ik echter tegen een probleem aan. In verschillende onderdelen (en dus ook Classes) van de webshop die voor één pagina aan moet roepen wil ik de Smarty class gebruiken. Is het nu verstandig om voor elke class die Smarty wil gebruiken een nieuwe instance ervan aan te maken? Of kan ik één soort "global" smarty object gebruiken voor alle modules? Wat is performance-technisch de beste keuze? En wat vinden jullie van Smarty als Template engine?

[wackmaniac]

Als ik het goed lees, moet je eens kijken naar singletons in php:
http://www.cmssysteem.nl/...en-zogenoemde-core-class/
Is wel een aardig artikel met wat links.

Heb verder geen ervaring met Smarty

[FlorisB]

Je kunt singleton gebruiken, zie hierboven. Of een global object aanmaken, http://www.php.net/global

[NMe]

Als je objectgeoriënteerd werkt is zo'n singleton toch een stuk netter dan een global.

[prototype]

Verwijderd schreef op maandag 07 augustus 2006 @ 12:39:
Nu loop ik echter tegen een probleem aan. In verschillende onderdelen (en dus ook Classes) van de webshop die voor één pagina aan moet roepen wil ik de Smarty class gebruiken.[/b]

Je bedoelt, smarty object?

Is het nu verstandig om voor elke class die Smarty wil gebruiken een nieuwe instance ervan aan te maken?

Smarty object dus. Je moet niet zozeer denken in de zin van nieuwe instanties ervan maken, maar denken aan je API de mogelijkheden geven tot aggregatie, i.e. gedeelde referenties naar je smarty object.

Of kan ik één soort "global" smarty object gebruiken voor alle modules?

Een dergelijke pool is een mogelijkheid. Singleton zoals eerder genoemd is een optie, mits je niet direct vanuit je klassen er aanspraak op probeert te maken. Dit benadeeld namelijk drastisch de flexibiliteit van je code, doordat je een hardcoded dependency creeert.

Wat is performance-technisch de beste keuze?

Als je voor object orientatie kiest, kies je eigenlijk niet zozeer voor performance temeer je kiest voor flexibiliteit. Vuistregel: software performance schaalt mee met een simpele hardware upgrade, waar software flexibiliteit veel meer kostbare manuren kost.

En wat vinden jullie van Smarty als Template engine?

Een zwaar loze 'template engine', daar ik het nut er niet van inzie tov het gebruik van normaal inline php + html. Daar doel ik dus mee op het feit dat smarty gewoon z'n eigen pseudo taaltje kent en er dus nog steeds logics verwoven zitten in je html. Dat is opzich niet zo'n ramp, maar het biedt in feite dus niet meer voordeel dan een view schrijven in PHP + html. Misschien wil je een optie overwegen waarbij html en PHP gewoon totaal gescheiden van elkaar zijn, i.e. geen logics binnen je html. Ik persoonlijk geef de voorkeur aan iets dat gewoon consistent is, en dan gaat mijn voorkeur toch uit naar XML + XSLT.

[DexterDee]

Ik wil geen zware Smarty discussie starten hier, maar ik ben software architect en senior developer en wij doen veel met PHP binnen ons bedrijf. We hebben het dan over enterprise PHP op basis van OO PHP5 met een aantal kenmerken van RUP in onze processen en met typische projectgroottes van 10k tot ver boven de 300k euro. Persoonlijk vind ik dat het niet echt op gaat om PHP een 'template taaltje' te noemen. Het mixen van PHP code en HTML is nu niet bepaald een fraaie combinatie. Het kan wel, maar de eigenschappen van een template engine zijn toch wat zwaarder dan wat PHP te bieden heeft.

Smarty een 'zwaar loze' template engine noemen komt op mij over als iemand die niet in detail weet wat Smarty allemaal kan en wat het precies is dat Smarty wil oplossen. Volgens het algemeen geaccepteerde Model-View-Controller pattern moet je je persistency laag, je acties en je user interface van elkaar scheiden. Nu is het zo dat je Model meestal in een database opgesloten zit. Je controller is de PHP code die hierop ligt en zonder template engine is PHP ook je view, omdat je ook je user interface vorm geeft met behulp van inline HTML.

Smarty is puur en alleen bedoeld om op een makkelijke manier het View gedeelde op te lossen. Het biedt juist veel voordeel om Smarty te gebruiken in plaats van inline PHP en HTML code. Smarty heeft inderdaad zijn eigen pseudo taaltje, maar dat is alleen bedoeld om op een correcte wijze de user interface vorm te geven, niet om de controller taak over te nemen. Het biedt een heel scala aan functies die niet in PHP aanwezig zijn om snel een gemakkelijk je user interface vorm te geven. Zo zijn er voor de meest voorkomende HTML form elementen standaard tags die uiterst makkelijk de vertaling maken van een associated array naar html checkboxes met values, labels en geselecteerde waarden. Tekst met \n linebreaks kun je heel gemakkelijk converteren naar <br/> tags en als je een data array hebt kun je heel gemakkelijk een loop schrijven, zonder een PHP foreach te mengen met <tr> en <td> tags. Ook het aanroepen van templates in templates is een uitkomst, omdat je dan niet op elke pagina opnieuw een header.php hoeft te includen. Parameters van de hoofdtemplate propageren automatisch naar de included templates. En met slimme if constructies kun je makkelijk bepaalde blokken verbergen of tonen, aan de hand van waarden van variabelen.

Waarom is dat pseudo taaltje dan makkelijker dan PHP en HTML in 1 bestand? Heel simpel, je scheidt de controller logica, de backend PHP code waarop je applicatie draait van de voorgrond PHP code, je view logica. Daarnaast is het taaltje veel minder uitgebreid en veel beter leesbaar dan PHP code tussen HTML. Je hoeft niet van PHP naar HTML te switchen door <?php en ?> tags te gebruiken.

Indien je een apart team hebt die het HTML ontwerp maakt, kun je deze mensen heel snel een aantal smarty tags en methodes leren. Ze kunnen dan met de templates aan de slag en de programmeurs maken vervolgens vrijwel simultaan de functionaliteit van de applicatie. Als PHP en HTML gemixt is dan moet je erg oppassen om designers te laten rommelen met de code. In mijn beleving gaat dat ook niet samen en zit de programmeur vervolgens ook de user interface aan te passen, omdat de designer de ballen snapt van PHP

Qua re-usability is het natuurlijk ook veel beter om templates te gebruiken. Doordat in een template alleen UI gerelateerde business logica zit, is dit veel beter te mappen op andere backend code. Zie maar eens een PHP + HTML pagina uit te kleden als deze helemaal vol zit met loopjes en echo's om alleen de user interface te hergebruiken op een andere applicatie. Dit wordt nog erger als je in je applicatie toestaat om meerdere 'skins' te gebruiken. Dan is een template engine als Smarty onombeerlijk. Niets is makkelijker dan om een andere template file te switchen met dezelfde placeholders om een radicaal andere webpagina tevoorschijn te toveren met dezelfde backend PHP.

Ik hoor ook wel eens geluiden dat Smarty langzamer werkt dan direct PHP en HTML. Dat is maar voor een klein gedeelte waar. Smarty werkt onderwater juist op dezelfde manier als het traditionele PHP en HTML model, door eenmalig de Smarty template en de bijbehorende PHP code te compilen naar een PHP bestand gecombineerd met HTML en deze uit te voeren. Bij verdere aanroepen gebruikt Smarty dit gecompilede bestand en is er praktisch geen verlies in snelheid.

Sinds wij binnen ons bedrijf Smarty gebruiken zien we een duidelijk merkbare verbetering in onderhoudbaarheid en gecombineerd met standaard bedrijfsassets een verkorting in de ontwikkeltijd van applicaties. Zelf ben ik inmiddels een paar jaar gewend om te werken met Smarty en ik ben er heel comfortabel mee. Voor hele simpele websites lijkt het misschien overkill, maar als je Smarty ervaring hebt kun je daar zelfs winst op halen. Voor grote websites met 50+ dynamische pagina's is het echt een grote aanrader, omdat de productiviteit en onderhoudbaarheid merkbaar omhoog gaat. Uiteraard moet je jezelf gaan verdiepen in Smarty en alles eruit halen wat het product je biedt, anders kan het misschien zelfs ingewikkelder worden in plaats van eenvoudiger.

Ik hoop dat ik ook eens een keer een andere kant heb kunnen laten zien van het gebruik van Smarty. Op dit forum lijkt toch de algehele consensus dat PHP al een template taaltje is en dat Smarty hieraan niks toevoegt, behalve een extra laag complexiteit. Dit is absoluut niet mijn mening.

/ONTOPIC:

In je classes definieer je je backend functionaliteit. Dit heeft niks te maken met hoe je het op het beeldscherm toont.
Stel je hebt een object 'bedrijf' en een object 'medewerker', dan kun je van het bedrijf object een array van medewerkers vragen. Dit komt dan terug in een PHP array. Je moet die data niet teruggeven als HTML tabel of iets dergelijks of rechtstreeks in Smarty proberen te stoppen. Je geeft in je 'hoofdbestand' (bijv. toonmedewerkers.php) aan Smarty de array van medewerkers met een $smarty->assign statement en in je template file loop je door alle mogelijke waarden en zet je je HTML eromheen.
In de classes zit geen enkele referentie naar Smarty, alleen op het hoofdniveau waar je de classes instantieert en aanroept. Overigens is het verstandig om een soort common.php constructie te maken waarbij je de Smarty initialisatie doet en andere overkoepelende activiteiten, zoals het starten van de sessie. Op die manier hoef je in je PHP bestanden slechts common.php te includen en dan kun je meteen met Smarty aan de slag. Meerdere instanties van Smarty is echt een no-go, dat gaat gruwelijk fout. Maar met een constructie dat je deze alleen op 1 plaats instantieert, in je classes geen Smarty variabelen toewijst en alleen met data schuift, zul je nooit de noodzaak hebben om Smarty meer dan 1 keer te instantieren.

Veel succes met je website

[Verwijderd]

zelf ben ik geen voorstander van Smarty.... ben wel voorstander van code/design scheiden. Ik gebruik www.phpxtemplate.org/. Niet zo bloated als Smarty, maar dat geef niks. Zolang ik maar blokken kan parsen en vars kan assignen .... zo'n template taal zoals Smarty hoeft van mij niet. Ik doe mijn loops wel in PHP en parse ze in mijn template engine

[prototype]

DexterDee schreef op dinsdag 08 augustus 2006 @ 13:09:
Ik wil geen zware Smarty discussie starten hier,

En toch begin je die, en krijg je die ook.

maar ik ben software architect en senior developer en wij doen veel met PHP binnen ons bedrijf. We hebben het dan over enterprise PHP op basis van OO PHP5 met een aantal kenmerken van RUP in onze processen en met typische projectgroottes van 10k tot ver boven de 300k euro. Persoonlijk vind ik dat het niet echt op gaat om PHP een 'template taaltje' te noemen. Het mixen van PHP code en HTML is nu niet bepaald een fraaie combinatie. Het kan wel, maar de eigenschappen van een template engine zijn toch wat zwaarder dan wat PHP te bieden heeft.

Smarty een 'zwaar loze' template engine noemen komt op mij over als iemand die niet in detail weet wat Smarty allemaal kan en wat het precies is dat Smarty wil oplossen.

Allereerst, als je een ‘maar’ binnen zo’n context gebruikt, dan dient er een tegenstelling op het voorgaande te volgen. Hoe kan het ‘ik ben een software architect...’-gebeuren een tegenstelling zijn op dat je geen zware Smarty discussie wil starten? Kan het misschien zijn dat software architecten en senior developers die veel met PHP doen over het algemeen de tegenstelling zijn op zware Smarty discussies? Diep... diep...
Dat terzijde, iemand die zichzelf zo introduceert komt op mij over als iemand die interessant probeer te doen, maar jammerlijk daarin faalt. Prototype's vuistregel: iemand z'n vaardigheid is omgekeerd evenredig aan het aantal buzzwords dat hij/zij gebruikt en zich mee tracht te profileren. Normaliter laat ik dan ook dergelijke reacties voor wat ze zijn, i.e. nutteloos, maar voor deze ene keer ben ik wel bereid te happen in het kader van de komedie. Daar moet ik mezelf natuurlijk wel eerst voor verlagen tot hetzelfde niveau.
Bij deze wil ik mezelf dan ook even misselijk introduceren. Zelf ben ik WO Technisch Informaticus EN Senior Developer, Software Architect (een Senior Developer weet namelijk zelf niets af van Software Architectuur en moet dus apart vermeld worden met gecapitaliseerde beginletters, ahum), Professioneel Indoor-Dammer op Hoog Niveau en de Ideale Schoonzoon volgens menig moeders. Dergelijke vaardigheden stellen me in staat om te werken aan projecten die in de miljoenen bedragen, waarbij 10-300k eigenlijk kleingeld is. Een heel ander verhaal zou het zijn als ik 100% van die inkomsten voor mezelf zou kunnen claimen, maar helaas, dat is niet het geval en schep ik er normaal ook niet over op omdat het eerder loserachtig overkomt. Baas boven baas? Misschien, maar irrelevante dingen dienen schijnbaar ook genoemd te worden. Overigens wordt daar nooit PHP voor gekozen vreemd genoeg, maar geniet een echte OO taal als Java daar de voorkeur. Ik zou niet weten waarom! PHP5 is immers de OO taal bij uitstek. Overigens, enterprise PHP, is dat een speciale editie van PHP die nog uit moet komen voor het normale volk? Ik hoop het!

Volgens het algemeen geaccepteerde Model-View-Controller pattern moet je je persistency laag, je acties en je user interface van elkaar scheiden. Nu is het zo dat je Model meestal in een database opgesloten zit.

Dat is gemeen zeg! Zomaar je model opsluiten in een database! Overigens is het persistence laag, geen dank overigens voor de buzzword 101. Als je overigens écht eens zou weten wat MVC inhield zou je nu schaterlachen om je uitleg zoals ik nu doe, maar dat laat ik aan jezelf over. Ik wil je pret immers niet bederven en zeker niet mijn eigen!

Je controller is de PHP code die hierop ligt en zonder template engine is PHP ook je view, omdat je ook je user interface vorm geeft met behulp van inline HTML.

Smarty is puur en alleen bedoeld om op een makkelijke manier het View gedeelde op te lossen. Het biedt juist veel voordeel om Smarty te gebruiken in plaats van inline PHP en HTML code. Smarty heeft inderdaad zijn eigen pseudo taaltje, maar dat is alleen bedoeld om op een correcte wijze de user interface vorm te geven, niet om de controller taak over te nemen.

Oh nu snap ik het! Dit is namelijk niet mogelijk binnen PHP zonder Smarty! Talloze mensen waaronder linksgetekenden hebben gewoon daarvoor de wetten der software engineering overtreden door hier wel in te slagen :o!

Het biedt een heel scala aan functies die niet in PHP aanwezig zijn om snel een gemakkelijk je user interface vorm te geven. Zo zijn er voor de meest voorkomende HTML form elementen standaard tags die uiterst makkelijk de vertaling maken van een associated array naar html checkboxes met values, labels en geselecteerde waarden.

*Moppelt iets van achterhaald en zwaar inferieur aan front-end/code-behind ala prado.*

Tekst met \n linebreaks kun je heel gemakkelijk converteren naar <br/> tags

Ja, nl2br is idd inferieur.

en als je een data array hebt kun je heel gemakkelijk een loop schrijven, zonder een PHP foreach te mengen met <tr> en <td> tags.

Nee idd, daar verkies je dan een smarty syntax boven die vermengd is met html. Veel beter idd, omdat PHP code wel gescheiden is, maar... hmmm, er zit nog wel code in, maar het is niet PHP code, dus het is beter idd!!!111oneoneeleven.
De enige twee reden waarom ik het plausibel zou achten om dergelijke een abstractie door te voeren binnen een template qua taal is ten eerste smaak en ten tweede om diezelfde templates in een andere taal onderhevig te laten zijn aan een andere interpreter. Probleem is echter dat er op andere platform een scala aan betere mogelijkheden zijn, wat het dus nutteloos maakt en smaak alleen staande blijft.

Ook het aanroepen van templates in templates is een uitkomst, omdat je dan niet op elke pagina opnieuw een header.php hoeft te includen.

OMFG gewoon. Als dit de best plausibele alternatief is die jij kent mag jij je OO badge inleveren meneer Software Architect én Senior Developer.

Parameters van de hoofdtemplate propageren automatisch naar de included templates. En met slimme if constructies kun je makkelijk bepaalde blokken verbergen of tonen, aan de hand van waarden van variabelen.

Onmogelijk inderdaad met PHP alleen!!!111oneoneeleven... NOT. Dit heeft overigens meer te maken met een slimme programmeur me dunkt. Neem overigens een kijkje naar hoe frameworks als prado dit hebben opgelost, en ga dan met name op zoek naar het TMultiView component. Veel asp.netters zal dit bekend zijn.

Waarom is dat pseudo taaltje dan makkelijker dan PHP en HTML in 1 bestand?

Wow, nu kan je ook gedachtenlezer toevoegen aan je rijtje aan titels.

Heel simpel, je scheidt de controller logica, de backend PHP code waarop je applicatie draait van de voorgrond PHP code, je view logica. Daarnaast is het taaltje veel minder uitgebreid en veel beter leesbaar dan PHP code tussen HTML. Je hoeft niet van PHP naar HTML te switchen door <?php en ?> tags te gebruiken.

Kijk, en dit bevestigt gewoon alles voor me. Alles wat je noemt is ook gewoon mogelijk binnen PHP. Je geeft als argument dat het taaltje minder uitgebreid is, en dan geef ik weer als tegenargument dat je niet alles hoeft te gebruiken binnen PHP, i.e. je maakt het zo moeilijk voor jezelf als je wil. Ik leg liever de beperking bij de programmeur dan bij een taal! Dat zou jij als senior blablabla ook moeten inzien.

Indien je een apart team hebt die het HTML ontwerp maakt, kun je deze mensen heel snel een aantal smarty tags en methodes leren.

Wat dacht je van een oplossing waarbij ze gewoon –niet- Smarty syntax hoeven te kennen, of hooguit iets moeten leren dat tot een standaard gerekend wordt voor de lange termijn? Zoiets als XSL, dáár heb je pas profijt aan als je ooit mocht kiezen om over te stappen van PHP naar een andere taal.

Ze kunnen dan met de templates aan de slag en de programmeurs maken vervolgens vrijwel simultaan de functionaliteit van de applicatie. Als PHP en HTML gemixt is dan moet je erg oppassen om designers te laten rommelen met de code. In mijn beleving gaat dat ook niet samen en zit de programmeur vervolgens ook de user interface aan te passen, omdat de designer de ballen snapt van PHP.

Ja, en nu moet je dus oppassen dat designers niet gaan zitten rommelen aan Smarty code; een designer nu in jouw situatie moet leren om te gaan met Smarty ipv PHP, waardoor het alsnog useless is. Een designer gaat logics eigenlijk gewoon compleet niets aan. Als je simultaan te werk wil gaan, dan kies je voor een oplossing waarbij kennis van ieder domein gewoon eigen is aan de mensen die eraan zitten, iets dat ik m’n eerste post binnen deze topic al gezegd heb en nu gedwongen wordt meerdere keren te herhalen voor mensen die niet goed kunnen danwel willen lezen.

Qua re-usability is het natuurlijk ook veel beter om templates te gebruiken. Doordat in een template alleen UI gerelateerde business logica zit, is dit veel beter te mappen op andere backend code. Zie maar eens een PHP + HTML pagina uit te kleden als deze helemaal vol zit met loopjes en echo's om alleen de user interface te hergebruiken op een andere applicatie. Dit wordt nog erger als je in je applicatie toestaat om meerdere 'skins' te gebruiken. Dan is een template engine als Smarty onombeerlijk. Niets is makkelijker dan om een andere template file te switchen met dezelfde placeholders om een radicaal andere webpagina tevoorschijn te toveren met dezelfde backend PHP.

Voor mij bevestig je maar weer dat jij geen idee hebt van wat business logics inhoudt en raad ik je aan eens op te gaan zoeken wat het nou echt inhoudt voordat je er weer mee gaat smijten en interessant mee probeert te doen. Dit aangezien je credibiliteit als senior blablabla hierdoor sterk in het geding komt. Dat terzijde, dezelfde analogie kan ik maken met het scheiden van een HTML + Smarty pagina. Nogmaals, Smarty weet me niet te overtuigen. De rest is nog veel meer bullshit waar ik geen zin meer heb om op in te gaan, maar toch wordt je poging gewaardeerd. Bedankt in ieder geval voor de komische verschijning en veel succes nog met je carriere!

[ Voor 0% gewijzigd door prototype op 08-08-2006 21:59 . Reden: Typo's en minder sarcasme. ]

[DexterDee]

prototype schreef op dinsdag 08 augustus 2006 @ 21:45:
[...]

En toch begin je die, en krijg je die ook.

Wat een pleidooi, wat heb ik jou in godsnaam misdaan dat je dit ongezouten commentaar op mij afvuurt? Dit is niet een objectieve reactie maar komt op mij over als een regelrechte bashing. Ik huiver van de gedachte dat bij je edit message staat dat je nog wat sarcastische elementen hebt verwijderd. Ik moet wel echt precies de juiste knoppen hebben geraakt bij jou met mijn reply, of niet?

Allereerst, als je een ‘maar’ binnen zo’n context gebruikt, dan dient er een tegenstelling op het voorgaande te volgen. Hoe kan het ‘ik ben een software architect...’-gebeuren een tegenstelling zijn op dat je geen zware Smarty discussie wil starten? Kan het misschien zijn dat software architecten en senior developers die veel met PHP doen over het algemeen de tegenstelling zijn op zware Smarty discussies? Diep... diep...
Dat terzijde, iemand die zichzelf zo introduceert komt op mij over als iemand die interessant probeer te doen, maar jammerlijk daarin faalt. Prototype's vuistregel: iemand z'n vaardigheid is omgekeerd evenredig aan het aantal buzzwords dat hij/zij gebruikt en zich mee tracht te profileren. Normaliter laat ik dan ook dergelijke reacties voor wat ze zijn, i.e. nutteloos, maar voor deze ene keer ben ik wel bereid te happen in het kader van de komedie. Daar moet ik mezelf natuurlijk wel eerst voor verlagen tot hetzelfde niveau.

Sorry dat het op die manier is overgekomen. Ik wilde de lezers van deze thread alleen even een context geven van de werkzaamheden die ik in mijn bedrijf uitvoer. Als ik daarover wilde opscheppen dan zou ik iets in de trand hebben geschreven als: '...dus ik kan het weten'. Ik heb toen ik die reply schreef bewust nagedacht dat ik alleen mijn mening wilde geven en niet iets als voldongen feit wilde presenteren. Volgens mij is me dat wel gelukt, alhoewel jij me meerdere keren probeert te pakken op een mening alsof het een feit is door een felle tegenreactie te geven en mijn mening als ridicuul te verklaren.

Bij deze wil ik mezelf dan ook even misselijk introduceren. Zelf ben ik WO Technisch Informaticus EN Senior Developer, Software Architect (een Senior Developer weet namelijk zelf niets af van Software Architectuur en moet dus apart vermeld worden met gecapitaliseerde beginletters, ahum)

Hoezo sarcastisch? Ik impliceer niet dat senior developers (<- zo goed?) niks weten over software architectuur. Ik wilde slechts het verschil aanduiden met de applicatie architectuur van een senior developer en een meer macro gerichtte architectuur die overkoepelend en meer beleidsvormend werkt.

Professioneel Indoor-Dammer op Hoog Niveau en de Ideale Schoonzoon volgens menig moeders. Dergelijke vaardigheden stellen me in staat om te werken aan projecten die in de miljoenen bedragen, waarbij 10-300k eigenlijk kleingeld is. Een heel ander verhaal zou het zijn als ik 100% van die inkomsten voor mezelf zou kunnen claimen, maar helaas, dat is niet het geval en schep ik er normaal ook niet over op omdat het eerder loserachtig overkomt. Baas boven baas? Misschien, maar irrelevante dingen dienen schijnbaar ook genoemd te worden.

Zo irrelevant waren die feitjes van mij niet en puur ter beeldvorming, niet om indruk te wekken. Ik zou niet weten wat ik daarmee zou moeten bereiken. Ik ben ook maar werknemer en die projectbedragen geven uitsluitend een figuratief idee van de projecten. Dat jij een aantal feiten in het absurde trekt wekt in ieder geval hier niet op mijn lachspieren. Gezien de toon van je hele reply zie ik het als misplaatst sarcasme en niet relevant voor deze hele discussie.

Overigens wordt daar nooit PHP voor gekozen vreemd genoeg, maar geniet een echte OO taal als Java daar de voorkeur. Ik zou niet weten waarom! PHP5 is immers de OO taal bij uitstek. Overigens, enterprise PHP, is dat een speciale editie van PHP die nog uit moet komen voor het normale volk? Ik hoop het!

Ter informatie, ik doe ook J2EE projecten en (nu moet ik heel voorzichtig zijn) weet ook het een en ander van Java. Hoewel ik er nog steeds geen grote bankapplicatie mee zou schrijven, zit PHP wel in de lift doordat het op steeds grotere en belangrijkere applicaties wordt ingezet. En ik twijfel ook geen seconde aan het feit dat je niet weet wat ik bedoel met enterprise PHP. Voor de ander lezers van dit draadje dan: PHP ingezet in een corporate omgeving met grote aantallen gebruikers, waarbij de aandacht voor schaalbaarheid, onderhoudbaarheid en stabiliteit bovengemiddeld belangrijk is. Een omgeving met koppelingen naar o.a. RDBMS'en als Oracle en DB2 en corporate LDAP directories.

Dat is gemeen zeg! Zomaar je model opsluiten in een database! Overigens is het persistence laag, geen dank overigens voor de buzzword 101. Als je overigens écht eens zou weten wat MVC inhield zou je nu schaterlachen om je uitleg zoals ik nu doe, maar dat laat ik aan jezelf over. Ik wil je pret immers niet bederven en zeker niet mijn eigen!

Sorry dat ik niet elke letter heb omgekeerd, maar met een beetje moeite kun je uit de context van mijn verhaal wel een interpretatie halen die de waarheid omtrend MVC enigszins benadert. Je haalt me doelbewust omlaag door met je sarcastische ondertoon de suggestie te wekken dat ik werkelijk geen idee heb waar ik het over heb. Ik zal vast niet de wetenschappelijke uitleg van het MVC pattern exact en correct hebben uitgelegd, maar de gemiddelde lezer weet goed wat ik bedoel en is ook in staat om deze informatie op een makkelijke manier van internet af te halen. Keiharde feitelijke onjuistheden heb ik niet gegeven, alleen dingen die jij anders interpreteerd en die je afschildert als ver van de waarheid omdat het niet in jouw straatje past en je op een of andere manier niet kon vinden in mijn stijl van antwoorden.

Oh nu snap ik het! Dit is namelijk niet mogelijk binnen PHP zonder Smarty! Talloze mensen waaronder linksgetekenden hebben gewoon daarvoor de wetten der software engineering overtreden door hier wel in te slagen :o!

Alles is mogelijk zonder Smarty vanwege het simpele feit dat Smarty naar een php file compileert die volgens de oorspronkelijke notatie PHP code en HTML code doorelkaar bevat. Weer een sprekend voorbeeld waarbij je graag iets WIL lezen op een bepaalde manier om er dan denigrerend een opmerking over te kunnen maken.

*Moppelt iets van achterhaald en zwaar inferieur aan front-end/code-behind ala prado.*

Mijn vergelijking was gestaafd op Smarty versus geen framework. Ik ben bekend dat er genoeg frameworks zijn die dergelijke functionaliteit heel mooi kunnen oplossen. En event driven programmeren is mij ook niet vreemd als je daar soms op doelt.

Ja, nl2br is idd inferieur.

Hier heb je me, dat was inderdaad niet zo'n bijster slim voorbeeld. Even niet aan gedacht. Bedankt echter voor je sarcastische manier van verwoorden.

Nee idd, daar verkies je dan een smarty syntax boven die vermengd is met html. Veel beter idd, omdat PHP code wel gescheiden is, maar... hmmm, er zit nog wel code in, maar het is niet PHP code, dus het is beter idd!!!111oneoneeleven.
De enige twee reden waarom ik het plausibel zou achten om dergelijke een abstractie door te voeren binnen een template qua taal is ten eerste smaak en ten tweede om diezelfde templates in een andere taal onderhevig te laten zijn aan een andere interpreter. Probleem is echter dat er op andere platform een scala aan betere mogelijkheden zijn, wat het dus nutteloos maakt en smaak alleen staande blijft.

Een paar jaar in aanraking met J2EE drukt je wel met je neus op de feiten qua abstractielagen. Ik heb in Websphere en NetWeaver meer abstractielagen gezien dan ik in PHP ooit van plan was te maken. Wat ik wil duidelijk maken is inderdaad een kwestie van persoonlijke smaak, namelijk dat ik de syntax van het Smarty pseudotaaltje dermate laagdrempelig en makkelijk vind dat ik het praktisch in gebruik vind. Iets dat je zelf als praktisch ervaart, wil je graag als suggestie bij anderen neerleggen. Niks meer en niks minder dan dat.

OMFG gewoon. Als dit de best plausibele alternatief is die jij kent mag jij je OO badge inleveren meneer Software Architect én Senior Developer.

Dit is wel de ergste vorm van bashing in je hele reply. Hoe kun je een persoon NOG directer en op de man af naar beneden proberen te trappen? Het ging hier over templates in templates. Wil je nu de suggestie wekken dat ik te stom ben om te begrijpen dat je ook een page class kunt maken die de standaard header in de constructor afhandelt? Ik kan zo nog 10 manieren bedenken als alternatief voor templates in templates. Het feit dat ik het hier aanhaal heeft te maken met mijn voorkeur om dingen niet moeilijker te maken dan ze hoeven te zijn. In mijn beleving om dit na te leven probeer ik altijd een goede mix te vinden tussen procedureel programmeren en object georienteerd. Ik geloof namelijk niet in de mening dat OO in alle gevallen beter is. Soms acht ik iets leesbaarder en beter onderhoudbaar als ik het procedureel oplos. Ik moet voorzichtig zijn om hier iets aan te halen om het vervolgens weer keihard om mijn oren geklapperd te krijgen, maar ik heb de indruk dat deze werkwijze een mogelijk basisprincipe is van het java deratief Ruby.

Onmogelijk inderdaad met PHP alleen!!!111oneoneeleven... NOT. Dit heeft overigens meer te maken met een slimme programmeur me dunkt. Neem overigens een kijkje naar hoe frameworks als prado dit hebben opgelost, en ga dan met name op zoek naar het TMultiView component. Veel asp.netters zal dit bekend zijn.

Weer een mooi voorbeeld hoe je probeert de indruk te wekken dat ik heb gezegd dat iets in PHP onmogelijk is, terwijl het in Smarty heel makkelijk zou gaan. Ik zeg niet dat Smarty het enige framework is wat superieur is aan alle andere werkwijzen. Ik heb geprobeerd de verschillen uit te leggen tussen PHP zonder framework en PHP met het framework Smarty. Naast Smarty gebruiken wij nog een redelijk aantal andere frameworks.

Wow, nu kan je ook gedachtenlezer toevoegen aan je rijtje aan titels.

Ik stel hardop een vraag en als je de context van mijn bericht goed leest kom je ook tot die conclusie. Om wederom zo sarcastisch te reageren ontgaat mij de reden totaal.

Kijk, en dit bevestigt gewoon alles voor me. Alles wat je noemt is ook gewoon mogelijk binnen PHP. Je geeft als argument dat het taaltje minder uitgebreid is, en dan geef ik weer als tegenargument dat je niet alles hoeft te gebruiken binnen PHP, i.e. je maakt het zo moeilijk voor jezelf als je wil. Ik leg liever de beperking bij de programmeur dan bij een taal! Dat zou jij als senior blablabla ook moeten inzien.

Ik snap inmiddels dat je het niet met mij eens bent dat Smarty een waardevol framework kan zijn voor de argumenten die ik aandraag. Ik ben het met je eens dat je de beperking bij de programmeur moet leggen en niet bij een taal of zelfs een framework in een taal. Het is echter evengoed jouw mening als mijn mening. Ik heb getracht mijn mening echter te verwoorden als mijn EIGEN mening en de interpretatie aan anderen over te laten. Jij lijkt jouw waarheid boven die van mij te stellen door mij denigrerend toe te spreken, maar er is geen absolute waarheid.

Wat dacht je van een oplossing waarbij ze gewoon –niet- Smarty syntax hoeven te kennen, of hooguit iets moeten leren dat tot een standaard gerekend wordt voor de lange termijn? Zoiets als XSL, dáár heb je pas profijt aan als je ooit mocht kiezen om over te stappen van PHP naar een andere taal.

Kwestie van voorkeur, ik heb in het verleden veel met XSLT's gewerkt, maar zelfs met een degelijke editor als Dreamweaver vind ik het persoonlijk niet lekker werken. Ik zou het dus niet in PHP, Java, .NET of waar dan ook gebruiken. Als de Smarty notatie defacto standaard zou worden, dan zou dat een ander verhaal zijn. Natuurlijk gebeurt dat niet, maar wie weet welke standaarden de toekomst brengt. Ik ben helemaal voor standaarden, begrijp me niet verkeerd.

Ja, en nu moet je dus oppassen dat designers niet gaan zitten rommelen aan Smarty code; een designer nu in jouw situatie moet leren om te gaan met Smarty ipv PHP, waardoor het alsnog useless is. Een designer gaat logics eigenlijk gewoon compleet niets aan. Als je simultaan te werk wil gaan, dan kies je voor een oplossing waarbij kennis van ieder domein gewoon eigen is aan de mensen die eraan zitten, iets dat ik m’n eerste post binnen deze topic al gezegd heb en nu gedwongen wordt meerdere keren te herhalen voor mensen die niet goed kunnen danwel willen lezen.

Leren omgaan met Smarty is voor een designer een kwestie van hooguit een aantal uren. Ik ben nog steeds van mening dat de UI tier (waartoe mijns inziens een loopje door een array van data behoort, maar niet een query die afgevuurd wordt of een business object die geinstantieerd wordt) door een designer afgehandeld kan worden. In de praktijk gaat dit ook prima. Ik respecteer jouw mening dat designers niks van doen hebben met applicatie logica, zelfs geen UI logica. De programmeerpurist in mij is het met je eens. De praktijk ligt soms wat verder van de theorie dan wellicht gewenst en dat maakt wederom jouw waarheid niet tot de absolute waarheid. In mijn ervaring is het vaak een mix van skills die deze afgebakende terreinen niet altijd strikt kunnen scheiden.

Voor mij bevestig je maar weer dat jij geen idee hebt van wat business logics inhoudt en raad ik je aan eens op te gaan zoeken wat het nou echt inhoudt voordat je er weer mee gaat smijten en interessant mee probeert te doen. Dit aangezien je credibiliteit als senior blablabla hierdoor sterk in het geding komt. Dat terzijde, dezelfde analogie kan ik maken met het scheiden van een HTML + Smarty pagina. Nogmaals, Smarty weet me niet te overtuigen. De rest is nog veel meer bullshit waar ik geen zin meer heb om op in te gaan, maar toch wordt je poging gewaardeerd. Bedankt in ieder geval voor de komische verschijning en veel succes nog met je carriere!

Ik heb een totaal verkeerde toon aangeslagen bij jou. Als er namelijk iets is wat ik met mijn reply NIET probeer te bereiken is om mijn credibiliteit te boosten en de popi-jopi specialist uit te hangen. Het spijt me dat mijn inleiding jou de aanleiding gaf om op een behoorlijke grove manier naar mij uit te halen. Aan de ene kant snap ik je verhaal en je sarcastische ondertoon op elke tweede zin wel. Maar aan de andere kant voel ik me wel oprecht gekwetst door iemand die ik totaal niet ken en met wie ik geen enkele nare voorgeschiedenis heb. Ik snap niet wat jou heeft bezield om mij proberen "op mijn plaats" te zetten, door mijn antwoord wat in mijn optiek zuiver informatief bedoeld was. Als ik mijn best doe dan kan ik enigszins inzien dat het neerzetten van mijn functie en werkomstandigheden een dergelijke reactie zou kunnen oproepen, maar dat rechtvaardigt zeker niet de algehele toon die je aanslaat tegen mij in je antwoord.
Ik weet heel goed waar ik mee bezig ben en ik wens niet afgeschilderd te worden als een of andere achterlijke patser die even populair wil doen door een nietszeggend en misleidend antwoord neer te zetten. Ik ben in mijn werkomgeving gewaardeerd om wat ik doe en ik heb genoeg zelfreflectie om grotendeels te weten wat ik wel en niet weet en/of kan. Ik heb mijn best gedaan en ik heb mijn mening gegeven. Ik vraag je om op een fatsoenlijke manier ook mijn mening en kijk op de zaken te accepteren, ongeacht of je het hier helemaal mee eens of oneens bent. Aan je reactie te zien en je manier van communiceren acht ik je slim genoeg om te snappen dat ik absoluut niet gecharmeerd ben van je offensief.

Je kunt nu vol tegengas geven en mij een tweede salvo geven. Ik had eigenlijk al geen zin in een eerste discussie hierover, zoals ik al schreef. Wat mij betreft eindigt deze discussie dan ook hier met deze reply. Ik heb mijn zegje gedaan en ik ben benieuwd naar je reactie.

[prototype]

Mooie reactie die beduidend bescheidener is dan de eerste; de eerste alinea van je eerste reactie deed menig persoon (zwaait naar de #devschuur posse) waaronder mijzelf een beetje kokhalzen. Het kwam meer over op ons dat je interessant probeerde te doen. Als je eens kijkt naar de ratio aan tekst die je hebt geschreven die daadwerkelijk ontopic is, dan moet je het me niet kwalijk nemen dat ik in het begin zo reageerde; dat was meer een (overdreven) weerspiegeling van je eerste reply, zoals aangekondigd en de motivatie ervoor is nu bekend. De reden overigens waarom ik in het bijzonder reageerde is het gevolg van de volgende zin uit je eerste reactie die direct gericht was op mij:

Smarty een 'zwaar loze' template engine noemen komt op mij over als iemand die niet in detail weet wat Smarty allemaal kan en wat het precies is dat Smarty wil oplossen.

Ik hoop dat je zelf inziet dat dit nou ook niet bepaald respectvol is. Het kwam op mij ongeveer zo over:

Nagut, ik neem aan dat we weer vriendjes kunnen zijn?

[Verwijderd]

(Ik zal prototype niet gaan herhalen, die heeft zo'n beetje alles al gezegd wat ik wou zeggen, hoewel wellicht op een ietwat onsubtiele manier)

Als ik een beetje naar Smarty kijk zo kan ik eigenlijk maar een enkele toepassing bedenken, namelijk het in een keurslijf stoppen van incompetente programmeurs. Verder is het imo gewoon nutteloos, want je hebt nog steeds code-in-HTML. In dat opzicht is het een stuk brakker dan 'moderne' technieken als JSP taglibs en de hele ASP.NET view meuk. Bovendien is de verbetering bovenop standaard PHP uitermate marginaal (zoals door prototype uitgebreid aangegeven).

Ook de hierboven genoemde toepassing kan beter vervuld worden door technologieen als J2EE en ASP.NET en PHP libs als Prado, omdat die niet alleen de split tussen de model-controller en de view (proberen te) forceren, maar ook de split tussen de controller en het model. Dit is ook belangrijk als je bijvoorbeeld ooit je applicatie wil overzetten naar een ander medium.

Het model bestaat trouwens heel vaak (lees: altijd) uit meer dan alleen je database. Je model is _alle data_ gerepresenteerd door je applicatie, dus mogelijk ook session data en dergelijke. Eigenlijk ligt het nog iets ingewikkelder dan dat, maar ik heb geen zin om de formele definitie op te gaan dreunen, zie wikipedia.

Direct de database queryen/updaten vanuit je controller en view lijkt me ook een Uitzonderlijk Slecht Idee (USI), want daar wil je toch wel een Object-Database mapping library voor hebben. Anders vergeet iemand ergens een stel aanhalingstekens en je hebt een mogelijk probleem met SQL injectie. Remember kids: als iemand iets potentieels gevaarlijks wil doen moet je hem daarvoor door zoveel mogelijk hoepels als mogelijk laten springen, zodat hij er tenminste nog goed over nadenkt. Behalve deze problemen ga je met direct queryen ook heel erg steunen op vendor-specifieke database functionaliteit, zoals het smaakjes stored procedures, wat de portability van je applicatie niet ten goede komt.

Java, Ruby, Python en C# zijn zowieso veel betere talen als je wil voorkomen dat iemand domme dingen doet, omdat ze minder special cases hebben en beter zijn uitgedacht qua OO implementatie. Dit laatste maakt ze veel geschikter om OO design patterns als MVC mee te gebruiken.

Ik ben trouwens geen Senior Software Engineer of Architect, maar ben wel in het bezit van CommonSense[tm], een radicaal nieuwe technologie die me in staat stelt om te bepalen of iets wel of niet deugt.

[ Voor 9% gewijzigd door Verwijderd op 09-08-2006 03:08 ]

[prototype]

Verwijderd schreef op woensdag 09 augustus 2006 @ 02:45:
Ik ben trouwens geen Senior Software Engineer of Architect, maar ben wel in het bezit van CommonSense[tm], een radicaal nieuwe technologie die me in staat stelt om te bepalen of iets wel of niet deugt.

Heb je dan ook "UI gerelateerde business logica binnen je templates"?

[DexterDee]

prototype schreef op woensdag 09 augustus 2006 @ 01:05:
Mooie reactie die beduidend bescheidener is dan de eerste; de eerste alinea van je eerste reactie deed menig persoon (zwaait naar de #devschuur posse) waaronder mijzelf een beetje kokhalzen.
Het kwam meer over op ons dat je interessant probeerde te doen. Als je eens kijkt naar de ratio aan tekst die je hebt geschreven die daadwerkelijk ontopic is, dan moet je het me niet kwalijk nemen dat ik in het begin zo reageerde; dat was meer een (overdreven) weerspiegeling van je eerste reply, zoals aangekondigd en de motivatie ervoor is nu bekend.

Dat is dan toch een vreemde en ietwat heftige fysieke reactie voor een aantal woorden en zinnen achterelkaar geplakt door een volkomen vreemde op een internet forum. Hoewel ik het nu wel kan begrijpen was ik totaal niet op de hoogte van het feit dat er een algeheel dogma heerst omtrend het geven van dergelijke informatie

De reden overigens waarom ik in het bijzonder reageerde is het gevolg van de volgende zin uit je eerste reactie die direct gericht was op mij:
>>Smarty een 'zwaar loze' template engine noemen komt op mij over als iemand die niet in detail weet wat Smarty allemaal kan en wat het precies is dat Smarty wil oplossen.

Ik hoop dat je zelf inziet dat dit nou ook niet bepaald respectvol is.

Ik vind het nogal zwaar meevallen. Ik nuanceer mijn statement met de woorden 'komt op mij over'. Dat is iets heel anders dan te zeggen dat je er geen klap van weet, omdat je het een 'zwaar loze' template vindt. Het is mijn mening en niet een voldongen feit. Misschien was het niet zo respectvol, maar je reactie hierop getuigde van nog veel minder respect.

Ik snap wat Mauritsd en jij willen zeggen over het nut van abstractielagen en programmeertechnieken. Ik ben zelf bekend met een aantal technieken en patterns zoals event driven programming, service oriented architectures, producer/consumer, factory patterns en virtualisatie. Als je J2EE bezigt dan zul je verplicht kennis moeten maken met een aantal van deze methoden.

Het is de praktische toepassing van deze abstractielagen en programmeertechnieken waar ik mijn vraagtekens bij zet. Een sprekend voorbeeld hiervan zijn twee applicaties die nu al een aantal jaren in productie staan hier. Beide hebben ze rond de 100k gekost en zijn grofweg hetzelfde opgebouwd. De ene is in IBM Webshpere 5.0 gemaakt (J2EE 1.3) met een Oracle backend en de andere is opgebouwd in PHP4 en MySQL4. Direct na de systeemtest van beide applicaties werd er al een groot verschil duidelijk. De J2EE applicatie had een buglist van 200 defects waarvan er zo'n 50 major waren. De PHP applicatie had in totaal 6 defects waarvan er 1 major was. In het traject om de applicatie door de user acceptance test te krijgen en in productie is er aan de J2EE applicatie nog voor een additionele 40k gesleuteld. De PHP applicatie is 'live' gegaan met wat kleingeld. Nog steeds (tot op de dag van vandaag) zijn de kosten voor onderhoud aan de J2EE applicatie zo'n 6x zo hoog als de PHP applicatie.

Ik wil met dit voorbeeld niet zeggen dat PHP superieur is aan J2EE, integendeel. Wat ik wil zeggen is dat de J2EE applicatie met al zijn frameworks en regeltjes slecht is ontworpen en uitgevoerd. Hoewel alle tiers van elkaar werden gescheiden, EJB's werden geschreven en frameworks als Spring en Struts werden gebruikt, is het eindproduct geen programeertechnisch hoogstandje.
De PHP applicatie zit goed doortimmerd in elkaar, onderhoud is een makkie en behalve Smarty templates en een database abstractielaag is alles verder procedureel en met een aantal van de belangrijkste business objecten in OO uitgevoerd.

In dit specifieke geval is het zo dat dit type applicatie op een LAMP stack de betere oplossing bleek te zijn ten opzichte van een J2EE applicatie. Bovendien maakt het niet uit welk platform je nu kiest, je kunt er altijd een puinhoop van maken, ongeacht hoeveel regeltjes en frameworks je volgt. Goeide skills zijn onombeerlijk en zelf nadenken en een goede architectuur uitdenken voor je begint zijn nog steeds stappen die je zult moeten doen.

In relatie tot deze discussie vind ik dat in een aantal gevallen Smarty met een aantal andere goedgekozen frameworks in PHP wel degelijk kan bijdragen aan het maken van betere applicaties. Er werken hier een aantal programmeurs die Smarty dagelijks of bijna dagelijks gebruiken. Hoewel geen officiele standaard is het wel een afgesproken manier van werken en dat maakt onderhoud makkelijk, de kwaliteit beter voorspelbaar en het gebruik van standaard reusable assets makkelijker. Natuurlijk kan het fraaier en programmeertechnisch beter, maar dat is geen requirement voor het type applicaties die wij maken. Om het even in het extreme te trekken, een "hello world" webapplicatie in J2EE vereist een aantal bestanden en een tiental regels code (klassedefinitie, imports etc... meegerekend). In PHP is het gewoon 1 echo statement. Soms wil je gewoon die ene echo en heb je de flexibiliteit van een framework als J2EE niet nodig.

Mauritsd zegt dat het niet verstandig is om rechtstreeks vanuit je Controller de database te queryen. In de meeste gevallen ligt er bij ons wel een bepaalde database abstractie laag tussen, maar die voorkomt niet dat je queries transparant zijn bij een andere RDBMS. Veel applicaties draaien op een shared omgeving waarbij voor de lifecycle van die applicatie er geen radicale veranderingen in het IT landschap zullen plaatsvinden. En zo hebben we een andere meer business critical applicatie waarbij we dat niet kunnen garanderen. Om die reden hebben we dus een db abstractielaag op basis van PDO's gekozen. Het inzetten van frameworks en methodes ligt in mijn ogen dus helemaal aan de situatie.

Methodes als event driven programming vind ik overigens heel nuttig, maar dan moeten ze wel ondersteund worden door een goede IDE. In Visual Studio is dit vrij aardig gedaan, alhoewel ik soms wel eens vraagtekens zet bij de enorme puinhoop aan html code die automatisch gegenereerd wordt. Ik programmeer overigens al jaren win32 applicaties en daar is event driven gemeengoed in alle talen waar maar het woordje 'visual' in staat.

Nagut, ik neem aan dat we weer vriendjes kunnen zijn?

I won't hold grudges for very long, dus die aanname is correct

[YopY]

Voor diegenen die (op het moment) nog niet zodanig ver in PHP zijn, danwel niet de tijd willen investeren in het compleet overzetten van hun hele applicatie naar een volledig MVC-oké systeem is Smarty anders wel handig. Ik gebruik het sinds een paar weken in de applicatie waar ik mee bezig ben (soort CMSje, niet eens zo geavanceerd), en ik vind het persoonlijk een hele verbetering over HTML in PHP.

Voorbeeld;

PHP:

$sql = "SELECT band_id, bandname, add_date, user_id, username
        FROM bands
        LEFT JOIN users ON users.user_id = bands.owner
        ORDER BY $order_by $direction"; 

$result = $db->query($sql);

echo '<table border="1"><tr><td>ID</td><td>Band name</td><td>Added on</td><td>by</td><td>Edit</td></tr>';
while ($content = $db->get_array($result))
{
    echo '<tr><td>' . $content['band_id'] . '</td>' .
            '<td><a href="../index.php?page=bands&bandid=' . 
            $content['band_id'] . '">' . 
            $parse->RemoveSlashes($content['bandname']) . '</a></td>' .
            '<td>' . date("jS F Y @ H:i", $content['add_date']) . ' </td>' .
            '<td><a href="index.php?page=users&user=' . $content['user_id'] .'">' . $parse->RemoveSlashes($content['username']) . '</a></td>' .
            '<td><a href="index.php?page=bands&what='. 
            $content['band_id'] .'">[ Edit ]</a> </td></tr>';
}
echo '</table>';

Oud stukje, AARDSLELIJK, dank u wel.

Nieuwe versie (welke ik nog niet gemaakt heb btw, is een stukje uit het admin gedeelte, moet ik nog in templates zetten danwel een mooiere oplossing vinden):

PHP:

$sql = "SELECT band_id, bandname, add_date, user_id, username
        FROM bands
        LEFT JOIN users ON users.user_id = bands.owner
        ORDER BY $order_by $direction"; 

// Haalt de gegevens op en zet ze in een 2-dimensionale array
$result = $db->GetArrayQuery($sql);

$smarty->assign('data', $result);
$smarty->display('template.tpl');

PHP code word veel schoner, en de programmeur hoeft zich niet meer al te druk te maken over de daadwerkelijke layout. De ontwerper kan dan gelijk aan de slag, en hoeft eerst geen boeken over PHP ofzo in te lezen om erachter te komen hoe PHP ongeveer werkt. Smarty valt echt veel makkelijker te leren dan PHP, en daarmee hoef je niet eerst honderden regels code door te worstelen om op het punt te komen waar de gegevens daadwerkelijk naar de gebruiker gestuurd worden.

Mijn code word schoner, de layout aanpassen word veel toegankelijker voor de ontwerper, je word in staat gesteld om meerdere layouts aan te maken zonder ook maar iets in de code te veranderen (buiten het layout veranderen zelf), etcetera. Het is misschien niet het meest efficient, maar het is wel verdraaid handig.

Nu ga ik het advies in een van de eerdere posts opvolgen en een main-klasse maken (ofzo), zodat al die global $db etc er weer uit kunnen.

[XWB]

Nu ga ik het advies in een van de eerdere posts opvolgen en een main-klasse maken (ofzo), zodat al die global $db etc er weer uit kunnen.

Nu nog de variabelen buiten je strings houden

[Verwijderd]

YopY schreef op woensdag 09 augustus 2006 @ 10:51:
Voor diegenen die (op het moment) nog niet zodanig ver in PHP zijn, danwel niet de tijd willen investeren in het compleet overzetten van hun hele applicatie naar een volledig MVC-oké systeem is Smarty anders wel handig. Ik gebruik het sinds een paar weken in de applicatie waar ik mee bezig ben (soort CMSje, niet eens zo geavanceerd), en ik vind het persoonlijk een hele verbetering over HTML in PHP.

Voorbeeld;

PHP:

$sql = "SELECT band_id, bandname, add_date, user_id, username
        FROM bands
        LEFT JOIN users ON users.user_id = bands.owner
        ORDER BY $order_by $direction"; 

$result = $db->query($sql);

echo '<table border="1"><tr><td>ID</td><td>Band name</td><td>Added on</td><td>by</td><td>Edit</td></tr>';
while ($content = $db->get_array($result))
{
    echo '<tr><td>' . $content['band_id'] . '</td>' .
            '<td><a href="../index.php?page=bands&bandid=' . 
            $content['band_id'] . '">' . 
            $parse->RemoveSlashes($content['bandname']) . '</a></td>' .
            '<td>' . date("jS F Y @ H:i", $content['add_date']) . ' </td>' .
            '<td><a href="index.php?page=users&user=' . $content['user_id'] .'">' . $parse->RemoveSlashes($content['username']) . '</a></td>' .
            '<td><a href="index.php?page=bands&what='. 
            $content['band_id'] .'">[ Edit ]</a> </td></tr>';
}
echo '</table>';

Oud stukje, AARDSLELIJK, dank u wel.

Nieuwe versie (welke ik nog niet gemaakt heb btw, is een stukje uit het admin gedeelte, moet ik nog in templates zetten danwel een mooiere oplossing vinden):

PHP:

$sql = "SELECT band_id, bandname, add_date, user_id, username
        FROM bands
        LEFT JOIN users ON users.user_id = bands.owner
        ORDER BY $order_by $direction"; 

// Haalt de gegevens op en zet ze in een 2-dimensionale array
$result = $db->GetArrayQuery($sql);

$smarty->assign('data', $result);
$smarty->display('template.tpl');

PHP code word veel schoner, en de programmeur hoeft zich niet meer al te druk te maken over de daadwerkelijke layout. De ontwerper kan dan gelijk aan de slag, en hoeft eerst geen boeken over PHP ofzo in te lezen om erachter te komen hoe PHP ongeveer werkt. Smarty valt echt veel makkelijker te leren dan PHP, en daarmee hoef je niet eerst honderden regels code door te worstelen om op het punt te komen waar de gegevens daadwerkelijk naar de gebruiker gestuurd worden.

Mijn code word schoner, de layout aanpassen word veel toegankelijker voor de ontwerper, je word in staat gesteld om meerdere layouts aan te maken zonder ook maar iets in de code te veranderen (buiten het layout veranderen zelf), etcetera. Het is misschien niet het meest efficient, maar het is wel verdraaid handig.

Nu ga ik het advies in een van de eerdere posts opvolgen en een main-klasse maken (ofzo), zodat al die global $db etc er weer uit kunnen.

indeed ... dat is het mooiste van zo'n template systeem .... zo had ik project en gebruikte natuurlijk mijn template enginge (nee geen smarty). Ik maakte dan alvast de dummy layout, gaf deze aan de html'er. Het enige waar hij rekening moest houden zijn

1) niet aanpassen van de blokken (de definitie van de blokken)
2) welke vars er beschikbaar waren.

Hij kon dan gewoon designen ik kon gewoon coden. Toen hij klaar was, gaf hij mij det templates terug en het werkte gelijk. Alleen nadeel van Smarty is dat je dus in je template ook een for-loop kan doen met zo'n smarty taaltje. Dat vind ik dus weer onzin. Zo'n html'er ziet dan opeens een soort forloop commando. Als er een loop moet komen, dan doe ik dat wel in mijn php code en parse de betreffende blokken.

[Verwijderd]

Bij ons hebben de designers helemaal niks met code te maken. Geen HTML, geen PHP, geen smarty, niks. Designers moeten ontwerpen, verder niks.
Van iemand die van een design goede HTML moet maken mag je verwachten dat hij een enigszins technische achtergrond heeft. Het hoeft geen PHP expert te zijn, hij hoeft alleen maar de stukjes PHP te kunnen herkennen.

[Verwijderd]

Verwijderd schreef op woensdag 09 augustus 2006 @ 18:35:
Bij ons hebben de designers helemaal niks met code te maken. Geen HTML, geen PHP, geen smarty, niks. Designers moeten ontwerpen, verder niks.
Van iemand die van een design goede HTML moet maken mag je verwachten dat hij een enigszins technische achtergrond heeft. Het hoeft geen PHP expert te zijn, hij hoeft alleen maar de stukjes PHP te kunnen herkennen.

Meestal is er wel overlap tussen het kennen van HTML en het kunnen ontwerpen van websites. De meeste ontwerpers die ik ken zijn wel in staat om hun eigen layouts te slicen en HTMLen. Ik zou niet vaak gaan voor een ontwerper die alleen het grafisch ontwerp kan verzorgen, omdat hij zich dan ook niet bewust is van de technische limitaties die bijvoorbeeld CSS (support in browsers) aan hem stellen. Je kunt nog zulke mooie layouts ontwerpen in fotosoep, als je door 1000 hoepels moet springen om het werkend te krijgen in IE heb je er bar weinig aan.

Ik ben vooral bekend (voor de kleine tot middelgrote projecten) met de volgende indeling:
1. een backend-coder, de webapplicatie levert de data aan in een XML taaltje dat alleen de werkelijke inhoud van de pagina bevat.
2. een HTMLer/grafisch ontwerper, via XSLT wordt de XML code getransformeerd tot (X)HTML. Dit laatste kan zowel serverside als clientside gedaan worden, mits de browser het ondersteunt. IE 5.5, IE 6.0, Mozilla en KHTML ondersteunen XSLT allemaal, dus in de praktijk is het geen probleem (en offload je een beetje processing naar de clients).

Bij grotere projecten wil je meer backend coders, een aparte HTMLer en wellicht een klein team wat het grafisch design verzorgt. Maar de hoeveelheid coders die je nodig gaat veel sneller omhoog, omdat je vaak het grafisch ontwerp kunt hergebruiken voor elke functie in je webapplicatie.

Natuurlijk is wat ik hierboven beschrijf slechts een manier om het te doen, maar wel eentje waar ik persoonlijk succes mee heb gehad. Maar dit gaat rap offtopic...

[prototype]

DexterDee schreef op woensdag 09 augustus 2006 @ 10:31:
[...]
Dat is dan toch een vreemde en ietwat heftige fysieke reactie voor een aantal woorden en zinnen achterelkaar geplakt door een volkomen vreemde op een internet forum. Hoewel ik het nu wel kan begrijpen was ik totaal niet op de hoogte van het feit dat er een algeheel dogma heerst omtrend het geven van dergelijke informatie

Vind je? Ik had daar eerst ook twijfel bij en ben dan ook eerst nagegaan bij anderen of ik de enige was die er zo over dacht. Aangezien dit absoluut niet het geval was, besloot ik over te gaan op reageren. Als je m'n reacties uit het verleden bekijkt zul je zien dat je eigenlijk de eerste bent die zo'n reactie uit me heeft weten te ontlokken.

[...]
Ik vind het nogal zwaar meevallen. Ik nuanceer mijn statement met de woorden 'komt op mij over'. Dat is iets heel anders dan te zeggen dat je er geen klap van weet, omdat je het een 'zwaar loze' template vindt. Het is mijn mening en niet een voldongen feit. Misschien was het niet zo respectvol, maar je reactie hierop getuigde van nog veel minder respect.

Het is toch echt letterlijk zeggen dat iemand volgens jou Smarty niet goed genoeg kent om er een goede uitspraak over te kunnen doen, en dat is een onderschatting danwel belediging aan mijn adres. Het tegendeel moge nu ook blijken uit m'n eerste reactie, waarbij het niet alleen sarcasme is dat hout snijdt. Zo staat m’n standpunt nog steeds over dat je termen gebruikt die niet in de context passen. Je zegt zoiets als "UI gerelateerde business logics binnen je template". Dan moet je jezelf al eens even achter de oren gaan krabben als je de definitie van de term business logic voor de geest haalt icm tiered applications, hetgeen je context is. Dat gaat iig niet goed samen in zo'n zin. Zo zijn er meerdere dingen op je reactie aan te merken, maar die laat ik voor de vrede aan jou over. Het heeft iig ook bijgedragen aan het plaatsen van zo'n dergelijke reactie. Deze in het bijzonder kaart ik even aan omdat ik eigenlijk denk dat je je hier van geen kwaad bewust van bent, aangezien ik er in deze topic al twee maal (en nu driemaal) een verwijzing naar heb gemaakt. Gebruik buzzwords alleen als je ook weet wat ze inhouden, anders staan ze er alleen voor de sier (lees: dom) en dat werkt averechts bij mensen die wel weten wat ze inhouden. Die mensen maken al genoeg van dat soort praktijken mee van hun managers

Ik snap wat Mauritsd en jij willen zeggen over het nut van abstractielagen en programmeertechnieken. Ik ben zelf bekend met een aantal technieken en patterns zoals event driven programming, service oriented architectures, producer/consumer, factory patterns en virtualisatie. Als je J2EE bezigt dan zul je verplicht kennis moeten maken met een aantal van deze methoden.

De technieken die je noemt maken deel uit van patronen en technieken die je je gewoon over het algemeen eigen moet maken als developer...

Het is de praktische toepassing van deze abstractielagen en programmeertechnieken waar ik mijn vraagtekens bij zet. Een sprekend voorbeeld hiervan zijn twee applicaties die nu al een aantal jaren in productie staan hier. Beide hebben ze rond de 100k gekost en zijn grofweg hetzelfde opgebouwd. De ene is in IBM Webshpere 5.0 gemaakt (J2EE 1.3) met een Oracle backend en de andere is opgebouwd in PHP4 en MySQL4. Direct na de systeemtest van beide applicaties werd er al een groot verschil duidelijk. De J2EE applicatie had een buglist van 200 defects waarvan er zo'n 50 major waren. De PHP applicatie had in totaal 6 defects waarvan er 1 major was. In het traject om de applicatie door de user acceptance test te krijgen en in productie is er aan de J2EE applicatie nog voor een additionele 40k gesleuteld. De PHP applicatie is 'live' gegaan met wat kleingeld. Nog steeds (tot op de dag van vandaag) zijn de kosten voor onderhoud aan de J2EE applicatie zo'n 6x zo hoog als de PHP applicatie.

Ik hoop niet dat je je dit persoonlijk aantrekt, maar ik denk dat de reden voor die bugs niet alleen aan de gebruikte technologie ligt. Wat betreft het proces valt opzich al wat op aan te merken. Ik maak hier namelijk uit je tekst op dat de enige test die je doorvoert een systeemtest is, die vind je iig noemenswaardig. Ik ben daarentegen een voorstander van test driven programming, en schrijf dan ook eerst mijn unit tests (uiteraard voorafgegaan aan een design proces). Dan en alleen dan pas schrijf ik code en deze dient geheel in de lijn van test driven programming te voldoen aan de geschreven tests alvorens er nieuwe dingen bijkomen. Een systeemtest volgt pas op het laatst of tussendoor bij die componenten die niet zinnig geunittest kunnen worden, zoals UI's. Een dergelijke procedure doorvoeren zal denk ik bijdragen aan een vermindering in bugs in je development proces. Natuurlijk kan ik hier niet echt een uitspraak over doen in jouw situatie, maar 'k heb wel een vermoeden dat het toch flink bij zal dragen. Zelf heb ik door deze manier van onwikkelen eigenlijk zelden last van mogelijk geschreven software bugs, ook met J2EE.

Ik wil met dit voorbeeld niet zeggen dat PHP superieur is aan J2EE, integendeel. Wat ik wil zeggen is dat de J2EE applicatie met al zijn frameworks en regeltjes slecht is ontworpen en uitgevoerd. Hoewel alle tiers van elkaar werden gescheiden, EJB's werden geschreven en frameworks als Spring en Struts werden gebruikt, is het eindproduct geen programeertechnisch hoogstandje. De PHP applicatie zit goed doortimmerd in elkaar, onderhoud is een makkie en behalve Smarty templates en een database abstractielaag is alles verder procedureel en met een aantal van de belangrijkste business objecten in OO uitgevoerd.

Dit is misschien niet geheel ontopic en ik zal dan ook kort reageren hierop door te zeggen ik gewoon van mening ben dat er betere manieren van templating zijn voor PHP dan Smarty; dat moge nu wel duidelijk zijn. Prado in het bijzonder geniet daarbij mijn voorkeur evenals XML/XSLT. Bij eerstgenoemde is er gewoon sprake van een totale scheiding van code en html zoals je dat gewend bent in het ASP.net frontend/codebehind model en in J2EE in zekere zin het JSF gebeuren. Wat betreft database abstractie, het is al een tijdje geleden dat ik hier wat mee heb gedaan in PHP, maar ik kies over het algemeen voor een O/R-mapped oplossing. Propel voldoet hier opzich aardig in.

In dit specifieke geval is het zo dat dit type applicatie op een LAMP stack de betere oplossing bleek te zijn ten opzichte van een J2EE applicatie. Bovendien maakt het niet uit welk platform je nu kiest, je kunt er altijd een puinhoop van maken, ongeacht hoeveel regeltjes en frameworks je volgt. Goeide skills zijn onombeerlijk en zelf nadenken en een goede architectuur uitdenken voor je begint zijn nog steeds stappen die je zult moeten doen.

Eens, en tevens een van de redenen waarom ik zeg dat het niet bijster veel nut heeft om Smarty als template engine te gebruiken indien je je weg goed kan vinden binnen PHP+HTML. De manier om dit wel zo veel mogelijk te minimaliseren, i.e. fouten maken, is imho door een designer gewoon niet te confronteren met logics, en dat brengt me weer terug bij een raamwerk als Prado die hier een volledige scheiding in brengt. In zulke situaties heb ik dan gauw de neiging om te zeggen dat als je iets wil doen, dat je het gewoon geheel en niet half dient te doen.

In relatie tot deze discussie vind ik dat in een aantal gevallen Smarty met een aantal andere goedgekozen frameworks in PHP wel degelijk kan bijdragen aan het maken van betere applicaties. Er werken hier een aantal programmeurs die Smarty dagelijks of bijna dagelijks gebruiken. Hoewel geen officiele standaard is het wel een afgesproken manier van werken en dat maakt onderhoud makkelijk, de kwaliteit beter voorspelbaar en het gebruik van standaard reusable assets makkelijker.

Misschien zo, maar dan denk ik alsnog dat vooral smaak daarvoor de reden is. Wat betreft het technisch aspect kan dat niet echt doorslaggevend zijn daar het niet bijster veel scheelt; feit blijft dat je met code –ook al zijn het maar control structures– zit in je template. Mijn mening is dan nog steeds dat als je templating door wil voeren met de reden om code van design te scheiden, dat je dit dan in het geheel dient te doen. Zelfs een conditionele danwel lus constructie behoort dan imho eigenlijk niet in een template, aangezien het nog steeds een control structure is. Wederom prijs ik hiervoor weer Prado de hemel in, door het codebehind/frontend idee naar PHP te brengen.

Natuurlijk kan het fraaier en programmeertechnisch beter, maar dat is geen requirement voor het type applicaties die wij maken. Om het even in het extreme te trekken, een "hello world" webapplicatie in J2EE vereist een aantal bestanden en een tiental regels code (klassedefinitie, imports etc... meegerekend). In PHP is het gewoon 1 echo statement. Soms wil je gewoon die ene echo en heb je de flexibiliteit van een framework als J2EE niet nodig.

Ik heb helaas niet de luxe om zulke uitspraken te doen; de applicaties die hier gemaakt worden zijn van dermate magnitude dat ermee werken zonder frameworks ondenkbaar zou zijn. Dit is dan ook in het verlengde van mijn opvatting van the right tool for the right job. En daarmee moet ik ook om eerlijk te zijn zeggen dat als ik me in jouw situatie zou verkregen, ik liever naar Ruby+Rails zou grijpen dan PHP indien de situatie het toe zou staan.

Mauritsd zegt dat het niet verstandig is om rechtstreeks vanuit je Controller de database te queryen. In de meeste gevallen ligt er bij ons wel een bepaalde database abstractie laag tussen, maar die voorkomt niet dat je queries transparant zijn bij een andere RDBMS. Veel applicaties draaien op een shared omgeving waarbij voor de lifecycle van die applicatie er geen radicale veranderingen in het IT landschap zullen plaatsvinden. En zo hebben we een andere meer business critical applicatie waarbij we dat niet kunnen garanderen. Om die reden hebben we dus een db abstractielaag op basis van PDO's gekozen. Het inzetten van frameworks en methodes ligt in mijn ogen dus helemaal aan de situatie.

En juist in zulke situaties zou ik een O/R-mapped oplossing aanraden, iets wat Mauritsd ook probeert aan te kaarten volgens mij. Als je nog niet bekend was hiermee, zou ik je toch zeker aanraden hier een kijkje naar te nemen, daar het gewoon volledige abstractie met zich mee brengt zonder al teveel moeite.

Methodes als event driven programming vind ik overigens heel nuttig, maar dan moeten ze wel ondersteund worden door een goede IDE. In Visual Studio is dit vrij aardig gedaan, alhoewel ik soms wel eens vraagtekens zet bij de enorme puinhoop aan html code die automatisch gegenereerd wordt. Ik programmeer overigens al jaren win32 applicaties en daar is event driven gemeengoed in alle talen waar maar het woordje 'visual' in staat.

Zelfs zonder IDE vind ik het bijzonder nuttig en de kennis ervoor om het te kunnen zonder IDE is imho hoe dan ook onmisbaar voor het goed toepassen mét een IDE. Klinkt raar, maar ik denk wel dat je begrijpt wat ik bedoel.
Sinds ASP.net 2.0 valt dat toch imho echt reuze mee wat betreft het generated HTML gebeuren. Laat ik het zo zeggen, het is erger geweest. *Kucht iets van asp.net 1.1 generated HTML en een IDE die toen dacht alles beter te weten dan de programmeur*. Met ASP.net 2.0 kun je iig als je het er niet mee eens bent met de standaard generated HTML, gewoon je eigen HTML implementatie eraan toekennen door de default template te overriden. C’est tout. Om eerlijk te zijn ligt mijn voorkeur dan ook bij ASP.net 2.0 doordat de IDE, i.e. Visual Studio 2005, gewoon hier geweldig mee werkt. Dit vergroot mijn plezier in ontwikkelen en daarmee ook de productiviteit.

@YopY, ik vind beiden lelijk. En als je geen tijd wil investeren om zulke fundamentele kennis te vergaren, dan moet je niet straks komen huilen wanneer er problemen ontstaan die makkelijk verholpen konden worden door kennis te hebben van dergelijke zaken . De technieken zijn er voor een reden.

[Verwijderd]

DexterDee schreef op woensdag 09 augustus 2006 @ 10:31:
Ik snap wat Mauritsd en jij willen zeggen over het nut van abstractielagen en programmeertechnieken. Ik ben zelf bekend met een aantal technieken en patterns zoals event driven programming, service oriented architectures, producer/consumer, factory patterns en virtualisatie. Als je J2EE bezigt dan zul je verplicht kennis moeten maken met een aantal van deze methoden.

Dat klopt. Java development is vaak theoretischer en vraagt meer van programmeurs dan bijvoorbeeld PHP. Wat je daar imo voor terugkrijgt (bij een goed ontworpen en geschreven applicatie) is minder bugs, beter herbruikbare code en een snellere applicatie.

Het is de praktische toepassing van deze abstractielagen en programmeertechnieken waar ik mijn vraagtekens bij zet. Een sprekend voorbeeld hiervan zijn twee applicaties die nu al een aantal jaren in productie staan hier. Beide hebben ze rond de 100k gekost en zijn grofweg hetzelfde opgebouwd. De ene is in IBM Webshpere 5.0 gemaakt (J2EE 1.3) met een Oracle backend en de andere is opgebouwd in PHP4 en MySQL4. Direct na de systeemtest van beide applicaties werd er al een groot verschil duidelijk. De J2EE applicatie had een buglist van 200 defects waarvan er zo'n 50 major waren. De PHP applicatie had in totaal 6 defects waarvan er 1 major was. In het traject om de applicatie door de user acceptance test te krijgen en in productie is er aan de J2EE applicatie nog voor een additionele 40k gesleuteld. De PHP applicatie is 'live' gegaan met wat kleingeld. Nog steeds (tot op de dag van vandaag) zijn de kosten voor onderhoud aan de J2EE applicatie zo'n 6x zo hoog als de PHP applicatie.

Ik ken de situatie bij jullie niet, maar het klinkt alsof er bij het ontwikkelen van de J2EE applicatie toch iets grondig misging. Beiden zijn in-house ontwikkeld, neem ik aan? Kan ik ook aannemen dat jullie een LAMP-shop zijn en dat jullie eerste echte J2EE/Oracle app was? Daarbij zou ik de applicatie testen terwijl deze ontwikkeld wordt dmv het JUnit-framework, maar dat terzijde.

Ik wil met dit voorbeeld niet zeggen dat PHP superieur is aan J2EE, integendeel. Wat ik wil zeggen is dat de J2EE applicatie met al zijn frameworks en regeltjes slecht is ontworpen en uitgevoerd. Hoewel alle tiers van elkaar werden gescheiden, EJB's werden geschreven en frameworks als Spring en Struts werden gebruikt, is het eindproduct geen programeertechnisch hoogstandje.
De PHP applicatie zit goed doortimmerd in elkaar, onderhoud is een makkie en behalve Smarty templates en een database abstractielaag is alles verder procedureel en met een aantal van de belangrijkste business objecten in OO uitgevoerd.

Begrijp me niet verkeerd; ik probeer niet te zeggen dat J2EE een soort magische sterrenstof is die toepasbaar is voor alle projecten. Ik ben zelf van mening dat J2EE een beperkte rol heeft en prima tegelijk kan bestaan met producten als PHP, Ruby on Rails en andere zaken. Ik zie alleen de toegevoegde waarde van Smarty niet.

De beschrijving van de kwaliteit van de java code lijkt mijn aanname over jullie in-house J2EE kennis te bevestigen. Het is echter ook mogelijk dat PHP gewoon voor die specifieke applicatie een betere keuze was, dat komt zeker voor. In dat opzicht ben ik het ook wel met je eens.

In dit specifieke geval is het zo dat dit type applicatie op een LAMP stack de betere oplossing bleek te zijn ten opzichte van een J2EE applicatie. Bovendien maakt het niet uit welk platform je nu kiest, je kunt er altijd een puinhoop van maken, ongeacht hoeveel regeltjes en frameworks je volgt. Goeide skills zijn onombeerlijk en zelf nadenken en een goede architectuur uitdenken voor je begint zijn nog steeds stappen die je zult moeten doen.

Je kunt er inderdaad altijd een bende van maken, maar java maakt het gewoon (een stuk) moeilijker om dit te doen. Daarbij zijn mensen niet perfect: java's strong-typing vangt gewoon fouten en dodgy constructies.

In relatie tot deze discussie vind ik dat in een aantal gevallen Smarty met een aantal andere goedgekozen frameworks in PHP wel degelijk kan bijdragen aan het maken van betere applicaties. Er werken hier een aantal programmeurs die Smarty dagelijks of bijna dagelijks gebruiken. Hoewel geen officiele standaard is het wel een afgesproken manier van werken en dat maakt onderhoud makkelijk, de kwaliteit beter voorspelbaar en het gebruik van standaard reusable assets makkelijker. Natuurlijk kan het fraaier en programmeertechnisch beter, maar dat is geen requirement voor het type applicaties die wij maken. Om het even in het extreme te trekken, een "hello world" webapplicatie in J2EE vereist een aantal bestanden en een tiental regels code (klassedefinitie, imports etc... meegerekend). In PHP is het gewoon 1 echo statement. Soms wil je gewoon die ene echo en heb je de flexibiliteit van een framework als J2EE niet nodig.

Een enkele .jsp file met "<%= "Hello world!" %>"... Ik begin een beetje mijn twijfels te trekken over wat je je voorstelt bij J2EE?

Mauritsd zegt dat het niet verstandig is om rechtstreeks vanuit je Controller de database te queryen. In de meeste gevallen ligt er bij ons wel een bepaalde database abstractie laag tussen, maar die voorkomt niet dat je queries transparant zijn bij een andere RDBMS. Veel applicaties draaien op een shared omgeving waarbij voor de lifecycle van die applicatie er geen radicale veranderingen in het IT landschap zullen plaatsvinden. En zo hebben we een andere meer business critical applicatie waarbij we dat niet kunnen garanderen. Om die reden hebben we dus een db abstractielaag op basis van PDO's gekozen. Het inzetten van frameworks en methodes ligt in mijn ogen dus helemaal aan de situatie.

Is ook zo, maar het kost nauwelijks extra tijd en niemand kan de toekomst voorspellen. Ik denk dat een risk-cost analysis bijna altijd in het voordeel van een database abstraction layer uitkomt. Daarbij zijn er zoveel voordelen die ik niet opgenoemd heb, van programmeergemak tot snelheid.

Methodes als event driven programming vind ik overigens heel nuttig, maar dan moeten ze wel ondersteund worden door een goede IDE. In Visual Studio is dit vrij aardig gedaan, alhoewel ik soms wel eens vraagtekens zet bij de enorme puinhoop aan html code die automatisch gegenereerd wordt. Ik programmeer overigens al jaren win32 applicaties en daar is event driven gemeengoed in alle talen waar maar het woordje 'visual' in staat.

Ben ik met je eens.

Om af te sluiten: het lijkt het me dat jullie een hele hoop PHP/Smarty expertise in huis hebben. Het is dus niet zo heel vreemd dat een project die daarin ontwikkeld is betere resultaten geeft dan iets anders. Ik zou dan ook gewoon bij PHP en Smarty blijven, tenzij de meerwaarde van iets als J2EE heel duidelijk bewezen kan worden.

[Verwijderd]

somebody please close this topic .. hahaha .. .want wordt steeds meer offtopic ;-)

[DexterDee]

@prototype en Mauritsd:
Het betreffende J2EE project was inderdaad het eerste project J2EE project van onze afdeling. Ik heb zelf de benodigde cursussen bij IBM gevolgd en flink wat avonduren verbrand, maar het echte werk werd gedaan door een flink aantal ingehuurde J2EE "experts" die al meerdere jaren ervaring hadden met het bouwen van dergelijke applicaties. Het feit dat het mis ging met het bouwen van die applicatie, heeft waarschijnlijk te maken met onze way of working

Het wordt mij steeds meer duidelijk dat wij van twee totaal verschillende werelden afkomen waar de belangen compleet anders zijn. Mauritsd, jij nam aan dat wij oorspronkelijk een LAMP shop waren. Dat is niet zo, onze afdeling komt van Lotus Notes ontwikkeling. Dit is een sterk RAD gedreven platform. Om hierin volwassen te zijn hebben wij met succes RAD omgevormd door toch een laag van processen en tooling aan te brengen die gestructureerd programmeren met zich mee brengt, maar deze zo licht mogelijk te houden zodat we de 'R' van rapid konden behouden. Dat is namelijk onze competence. Wij opereren op dit moment op CMM level 2 met een aantal kenmerken van level 3 en 4. Andere kenmerken hebben wij doelbewust laten vallen omwille van de werkwijze. In traditionele software ontwikkeling werkt het grofweg zo: 1/3 requirements, 1/3 implementatie en 1/3 testen. Bij ons is de requirements en test fase een stuk korter. Wij maken bijvoorbeeld geen uitgebreide technische specificaties van het complete systeem, maar beschrijven alleen de niet triviale dingen. Functioneel beschrijven we wel alles, maar niet totop elke pixel en button.

Nu kunnen wij ons een andere werkwijze veroorloven als afdelingen die veel langere en zwaardere applicaties produceren en dit strikt volgens bijvoorbeeld RUP doen. Wij meten onze performance KPI's en wij blijven qua lead-time in 95% van al onze projecten (we doen er zo'n 50 op jaarbasis) binnen 5% over of undershoot, zowel budget als leadtime. We meten ook de klanttevredenheid die op een schaal van 5 zo rond de 4,1 zit. Onze applicaties zijn goed te supporten en er zijn weinig problemen mee. Met een dergelijke performance hoef je niet krampachtig iets in je development proces te verbeteren, omdat het extra rendement vrij laag zal zijn. Why change a winning team?

Dat wil overigens niet zeggen dat wij niet proberen te innoveren en te professionaliseren. Dat zal nooit ophouden. Mijn rol en die van een aantal anderen is om de grote lijnen uit te zetten qua techniek en werkwijze. Wij hebben een tijd LAMP projecten gedraaid met WinZip(tm) als versioning tool. Na een onsuccesvolle launch van Rational ClearCase hebben we besloten een subversion instantie in te richten en dit te gaan gebruiken. Deze is veel lichter dan ClearCase en sloot veel beter aan op onze behoeften.

Ik snap dus jullie behoeften wel voor de methodologieen die jullie beschrijven, maar veel van die methodes zijn overkill voor onze (relatief kleinschalige) projectjes. Het mom van doorgroeien gaat hierbij niet echt op, naar mijn mening. Een relatief onbelangrijke applicatie van 50k zal geen kritieke applicatie van 1M worden. Om dan te investeren in methodologieen die het programmeertechnisch beter maken levert te weinig rendement op voor de effort die we als afdeling er in moeten stoppen. En mocht een applicatie wel die kant op gaan, dan zijn er andere afdelingen binnen het bedrijf die het stokje zullen overnemen. Ons bedrijf is namelijk dermate groot dat we meerdere ontwikkelafdelingen hebben en wij zijn van de RAD tak.

Dat gezegd hebbende ga ik wel een gedeelte van jullie pleidooi proberen te gebruiken in onze toekomstige proces en kwaliteit verbeteractiviteiten. Ik zal Prado en Propel eens op de agenda zetten bij ons en kijken wat we daar uit kunnen halen. Maar het blijven twee totaal verschillende werelden waarbij de belangen radicaal anders zijn en dit heeft zijn uitwerking op de manier van werken.

[alienfruit]

Het gooien met KPIs heeft dus helemaal geen nut omdat (1) het onduidelijk is hoe jullie meten (2) hoe de resultaten onderling worden gecombineerd (3) welke vorm van BSCs jullie gebruiken. Verder valt dit mijn inziens totaal buiten het onderwerp van dit topic. Ik kan ook wel KPIs bepalen zodat de afdeling er goed uitkomt.

[prototype]

DexterDee schreef op donderdag 10 augustus 2006 @ 09:54:
@prototype en Mauritsd:
Het betreffende J2EE project was inderdaad het eerste project J2EE project van onze afdeling. Ik heb zelf de benodigde cursussen bij IBM gevolgd en flink wat avonduren verbrand, maar het echte werk werd gedaan door een flink aantal ingehuurde J2EE "experts" die al meerdere jaren ervaring hadden met het bouwen van dergelijke applicaties. Het feit dat het mis ging met het bouwen van die applicatie, heeft waarschijnlijk te maken met onze way of working

Muah, ik kan natuurlijk hier niet echt veel over zeggen aangezien ik jullie situatie niet goed genoeg ervoor ken, maar misschien wil je eerder kijken naar je manier van job interviewing Iemand die zichzelf namelijk profileert als J2EE "expert" vraagt er naar mijn mening om stevig aan de tand gevoeld te worden, en daar zou diegene geen problemen mee moeten hebben... daar is diegene immers "expert" voor Gewoon zelf bij gaan zitten dus om zodoende ook de "expert" volledig tot z'n recht te laten komen, want alleen de HRM meneer staat niet bepaald garant voor succes; die vallen uit mijn ervaring nogal snel voor het buzzword charme offensief. Hier kun je vaak in ieder geval al gauw het "all show, no go" bij iemand vaststellen.

Het wordt mij steeds meer duidelijk dat wij van twee totaal verschillende werelden afkomen waar de belangen compleet anders zijn. Mauritsd, jij nam aan dat wij oorspronkelijk een LAMP shop waren. Dat is niet zo, onze afdeling komt van Lotus Notes ontwikkeling. Dit is een sterk RAD gedreven platform. Om hierin volwassen te zijn hebben wij met succes RAD omgevormd door toch een laag van processen en tooling aan te brengen die gestructureerd programmeren met zich mee brengt, maar deze zo licht mogelijk te houden zodat we de 'R' van rapid konden behouden. Dat is namelijk onze competence. Wij opereren op dit moment op CMM level 2 met een aantal kenmerken van level 3 en 4. Andere kenmerken hebben wij doelbewust laten vallen omwille van de werkwijze. In traditionele software ontwikkeling werkt het grofweg zo: 1/3 requirements, 1/3 implementatie en 1/3 testen. Bij ons is de requirements en test fase een stuk korter. Wij maken bijvoorbeeld geen uitgebreide technische specificaties van het complete systeem, maar beschrijven alleen de niet triviale dingen. Functioneel beschrijven we wel alles, maar niet totop elke pixel en button.

Juist die verschil in werelden weet mij te boeien in deze topic, ook al begint het zwaar offtopic te gaan. Ergens is het voor mij een bevestiging dat ik dingen doe zoals ik die doe, en ik kan me voorstellen dat dat voor jou ook zo is.
Het blijft in ieder geval jammer dat de nood van de R in RAD vaak zodanig aanwezig is, dat het met de AD wel eens wat minder serieus wordt genomen. Dit is misschien over het algemeen realiteit, de concurrentie is immers moordend en het gaat aan het einde van de dag erom dat je betaald wordt, maar er zijn imho een overvloed aan manieren om hiermee overweg te gaan. Het lijkt in ieder geval steeds vaker een excuus te worden om good practice te laten voor wat het is.
Mijn docent programmeren zei ooit eens in al zijn wijsheid: de tijd die je verliest tijdens het ontwerpproces verdien je dubbel en dwars terug tijdens het implementeren (en bij het testen), en de beste man heeft naar mijn beleving gelijk. Samen met de opvatting dat de makkelijkste code om aan te passen, die code is die niet geschreven is, vormt dit iig een belangrijk deel van mijn filosofie op gebied van software ontwikkeling. Een dergelijke top-down approach is juist tijds- en kostenbesparend in situaties, waarbij enige complexiteit om de hoek komt kijken, en dat is toch zeker bijna altijd het geval... nou ja, in mijn situatie in ieder geval. Zeker in teamverband schept dit iets heel belangrijks, namelijk duidelijkheid. Eventuele bottlenecks worden zo vroeg in het ontwikkelingsproces bespeurd en kunnen ook goedkoper verholpen worden.
Problemen oplossen gedurende compile-time is daarbij ook goedkoper dan ze proberen op te lossen tijdens run-time, en juist daar heb je dus test-driven development voor. Hier zul je weer tijd mee winnen tijdens je systeemtest. Het is dus maar net hoe je ervoor kiest om je tijd in te delen, want de ene investering bespaart de andere. Bij mij beslaat het ontwerp- en testproces in ieder geval de meeste tijd, maar dit win ik in veelvouden terug tijdens de implementatie. Daarbij hanteer ik ook methodieken als Design by Contract om complexiteit zoveel mogelijk tegen te gaan. Good practice hoeft dus in ieder geval echt niet duurder te zijn en is vaak zelfs goedkoper, hoe onrealistisch dit misschien mag klinken. Een belangrijke bijdrage hierbij is dan in ieder geval de programmeur, i.e. de mate van ervaring/vaardigheid die zo iemand aangerekend kan worden.

Why change a winning team?

Omdat het winnende team van vandaag, morgen de verliezende team kan zijn. Niets zo veranderlijk c.q. onvoorspelbaar als de IT wereld. Innoveren is dan onombeerlijk, maar dat zeg je ook te doen.

Ik snap dus jullie behoeften wel voor de methodologieen die jullie beschrijven, maar veel van die methodes zijn overkill voor onze (relatief kleinschalige) projectjes. Het mom van doorgroeien gaat hierbij niet echt op, naar mijn mening. Een relatief onbelangrijke applicatie van 50k zal geen kritieke applicatie van 1M worden. Om dan te investeren in methodologieen die het programmeertechnisch beter maken levert te weinig rendement op voor de effort die we als afdeling er in moeten stoppen. En mocht een applicatie wel die kant op gaan, dan zijn er andere afdelingen binnen het bedrijf die het stokje zullen overnemen. Ons bedrijf is namelijk dermate groot dat we meerdere ontwikkelafdelingen hebben en wij zijn van de RAD tak.

Nogmaals, good practice hoeft niet duurder te zijn. Natuurlijk is het wel even investeren afhankelijk van wat je al in huis hebt qua developers, hmmm nahjah, ik kan hier natuurlijk wel weer een betoog gaan houden van waarom je het wel zou willen overwegen, maar als ik mijn reactie(s) zo nalees heb ik dat toch echt wel zo'n beetje al gedaan en daar heb ik dan vrede mee

[.oisyn]

YopY schreef op woensdag 09 augustus 2006 @ 10:51:
Voor diegenen die (op het moment) nog niet zodanig ver in PHP zijn, danwel niet de tijd willen investeren in het compleet overzetten van hun hele applicatie naar een volledig MVC-oké systeem is Smarty anders wel handig. Ik gebruik het sinds een paar weken in de applicatie waar ik mee bezig ben (soort CMSje, niet eens zo geavanceerd), en ik vind het persoonlijk een hele verbetering over HTML in PHP.

Sorry, maar dan heb je nog geen zak begrepen van de hele discussie die hier (aanvankelijk) gevoerd werd . HTML in PHP staat los van scheiding tussen logic en view. PHP is namelijk een template processor. Jouw smarty code kan namelijk zonder smarty in puur PHP op exact dezelfde manier:

PHP:

$sql = "SELECT band_id, bandname, add_date, user_id, username
        FROM bands
        LEFT JOIN users ON users.user_id = bands.owner
        ORDER BY $order_by $direction"; 

// Haalt de gegevens op en zet ze in een 2-dimensionale array
$result = $db->GetArrayQuery($sql);

include("template.php");

Heej, de code is vrijwel identiek, alleen zijn je tempaltes nu gewoon php files die de data fatsoenlijk tonen, ipv dat je het overrated Smarty gebruikt