[discussie] Gebruik van PHP5.x in grote applicaties

[jsiegmund]

Met de 5.x versies van PHP wordt met name het OO-gedeelte steeds uitgebreider (en interessanter). Je zou kunnen zeggen dat PHP meer volwassener wordt en dus toe is om gebruikt te worden in grote applicaties. Echter... vraag ik me af of de opzet van PHP daar wel zo geschikt voor is. Ik heb helaas geen ervaring met alternatieven als ASP(.NET) dus dat vergelijk kan ik niet maken. PHP begint steeds meer te lijken op een normale OO-programmeertaal, terwijl de structuur van een webbased applicatie o.a. door het gebruik van HTTP (-get en -post) helemaal afwijkt van een normale applicatie die je opstart en laat lopen totdat er eens op het kruisje gedrukt wordt. Wordt over dit verschil expres heen gekeken, of heeft er niemand ooit aan gedacht dat zo'n verschil misschien ook vraagt om een andere manier van programmeren?

Graag uw mening hierover. Mocht je interessant leesvoer hebben dan zie ik dat graag tegemoed!

[MTWZZ]

Tsja je kunt je dan gelijk afvragen wat een "applicatie" is. Voor web-based applicaties zeer zeker (joomla/mambo en consorten bijvoorbeeld)
Voor stand-alone kun je op zich best veel met PHP de vraag is alleen of je dat moet willen want andere programmeer talen/toolkits zijn daar gewoon beter in.
Wat web-based betreft is het eigenlijk afhankelijk van hoe goed je ontwerp is (geldt natuurlijk voor alle projecten) omdat je op die manier gestructureerder kunt werken (iets dat mij met PHP vaak niet echt lukt maar dat is een ander verhaal)

[MisterData]

Tsja... het is er steeds beter voor te gebruiken, maar het is mijnsinziens nog steeds niet *goed* bruikbaar voor grote applicaties aangezien het bijvoorbeeld iets heel basaals als namespaces of het kunnen maken van 'packages'/'modules' mist (Java, .NET kunnen dat allemaal). Daarnaast mist het ondersteuning voor bijvoorbeeld objecten die voor een applicatie globaal kunnen worden gedefinieerd (als je het voor een webapplicatie gebruikt) om bijvoorbeeld resources te delen en mist het nog wel meer van dat soort dingen...strong typed lijkt me overigens ook iets handiger in grotere applicaties...

[Verwijderd]

iCe01 schreef op dinsdag 17 januari 2006 @ 14:57:
Met de 5.x versies van PHP wordt met name het OO-gedeelte steeds uitgebreider (en interessanter). Je zou kunnen zeggen dat PHP meer volwassener wordt

Dat zou je inderdaad kunnen zeggen. Mijn persoonlijke probleem is een beetje dat PHP kwa ontwikkeling gewoon Java en ASP.NET achterna gaat. De reden om geen Java en ASP.NET te gaan gebruiken was altijd dat PHP makkelijker en simpelder was. Of dat echt zo is is weer een andere discussie eigenlijk (in een notendop, als je je beperkt tot JSPs met Java code erop zijn PHP en JSP bijna identiek).

Anyway, als PHP netzoals Java gaat worden, wat is dat het nut nog? Dan kun je direct meteen naar Java gaan. Vergelijk het een beetje met wat microsoft met Visual Basic heeft gedaan. Dit was een simpel taaltje voor je als je niet bijster veel wilde. Ondertussen heeft MS Visual Basic zo verbouwt dat het gewoon C# is met alleen nog maar een hint naar de oude VB syntax. Why bother denk ik dan. Gebruik dan gewoon meteen C#.

OO-programmeertaal, terwijl de structuur van een webbased applicatie o.a. door het gebruik van HTTP (-get en -post) helemaal afwijkt van een normale applicatie die je opstart en laat lopen totdat er eens op het kruisje gedrukt wordt. Wordt over dit verschil expres heen gekeken, of heeft er niemand ooit aan gedacht dat zo'n verschil misschien ook vraagt om een andere manier van programmeren?

Je moest eens weten hoeveel daar over gedacht is Java EE (de web variant dus) en ASP (nog zonder het .NET) zaten vroeger met hetzelfde probleem. Een vrij plat programmeer model waarbij je vooral met requests en response dingen aan de gang was. Kwa pure business logic kon je het OO gebeuren nog wel goed toepassen, maar voor de GUI en interactie eigenlijk een stuk minder.

Zowel ASP.NET en Java zitten echter alweer een volledige generatie verder. Je hebt volledige OO frameworks, met server side events, event-listeners, herbruikbare componenten, componten die je kinderen kunt laten zijn van andere componenten etc. Precies die werkwijze die je ook toegepast ziet worden in GUI desktop applicaties (bv Winforms, Win32/MFC (windows), AWT/Swing/SWT (Java), QT, GTK, Motif (oa Linux), etc etc).

In een typische JSF applicatie (zo heet het GUI model van Java) knoop je gewoon componenten aan elkaar en hangt er (action) listeners aan. Dit kun je zowel in XML doen, als in code. Als je het in code doet lijkt het echt net op desktop programmeren. Je hebt bijna niks meer te maken met requests, request parameters of responses. Jij ziet alleen classes en daar werk je mee.

Je kunt dus bijvoorbeeld dingen doen als:

code:

public String myAction() {
     if ( something == true ) {
        myWidget.setRendered(true);
        myWidget.setBorder(2);
     }
}

de functie myAction set je dan als action listener voor een widget wat je op je scherm ziet (een knop of link widget bijvoorbeeld). Als iemand dan op die knop drukt wordt automatisch die functie myAction aangeroepen. In deze functie kun je dan gewoon andere widgets aan of uit zetten, of hun eigenschappen veranderen. Java zelf genereerd er dan de HTML code voor en vangt ook de requests op die de user dan weer terug stuurt.

In PHP of puur JSP moet je zelf met de hand HTML op je pagina gaan zetten, daar dan zelf if constucties om heen zetten, dan de request parameters uitlezen op basis waarvan die if statements dan weer wel of niet waar zijn, etc. Dat is allemaal veel meer gedoe, plus dat je niet echtr OO bezig bent op de pagina's zelf.

[Bosmonster]

Ik snap je hele punt niet zo... het is bedoeld voor webbased applicaties, maar begint steeds meer te lijken op een 'normale' programmeertaal?

Ten eerste, PHP kan meer dan alleen webapplicaties. Ten tweede, defineer een 'normale' programmeertaal

Bij (web)applicaties boeit de taal niet zo, maar is het belangrijker hoe je ermee programmeert. OO is een goede stap en een veelgebruikt design pattern voor webapplicaties is MVC (Model View Controller) bijvoorbeeld.

[ Voor 4% gewijzigd door Bosmonster op 17-01-2006 22:27 ]

[Verwijderd]

Bosmonster schreef op dinsdag 17 januari 2006 @ 22:26:
Bij (web)applicaties boeit de taal niet zo, maar is het belangrijker hoe je ermee programmeert. OO is een goede stap en een veelgebruikt design pattern voor webapplicaties is MVC (Model View Controller) bijvoorbeeld.

Daarbij sluit OO van oudsher (zie smalltalk) uitstekend aan bij de patterns MVC en Composite.

Je zou dus met een zekere redelijkheid kunnen zeggen, dat OO programmeren en klassiek web programmeren lichtelijk botst. Juist om de reden die TS aangeeft: je bent voornamelijk met de get en post dingen bezig en je UI objecten (widgets) zijn helemaal geen objecten maar platte strings (namelijk, de HTML code die je tussen loops en conditionals zet).

Met andere woorden, voor echt OO programmeren kwa GUI is PHP op dit moment niet de eerste keuze. Je kunt in PHP wel OO voor de business logic gebruiken. MVC frameworks in PHP zijn nog lang niet van het niveau van ASP.NET.

Dat is dus wat TS mischien ook een beetje bedoelt, je hebt nu in PHP 5 wel meer objecten, maar nog geen GUI objecten.

[SchizoDuckie]

Verwijderd schreef op dinsdag 17 januari 2006 @ 23:03:
[...]
Dat is dus wat TS mischien ook een beetje bedoelt, je hebt nu in PHP 5 wel meer objecten, maar nog geen GUI objecten.

Eigenlijk is het ook de vraag of je wel GUI objecten wíl hebben.
De kracht van OO in PHP is imo júist dat je een object een lap html kan laten retourneren (wat jij een widget noemt) Een website bouwen vereist vaak een net iets andere gedachtengang dan een applicatie bouwen imo, maar dat met dat stukje OO wat je in php5 toch hebt wordt het allemaal wel erg makkelijk

Neem bijv een <form>, veel mensen hebben hun eigen form generators inmiddels die aan de hand van een aantal simpele opties een formulier generereren. ikzelf werk bijvoorbeeld zo:

PHP:

    function displayEditor($title='Plaag invoeren')
    {
        $editor = new formGenerator($this, $title, 'AjaxWrapper');
        $editor->Naam = new TextInput('Plaag naam');
        $editor->Latijns = new TextInput('Latijnse Benaming');
        $editor->Beschrijving = new FckInput('Beschrijving');
        
        $Relationeditor = new MultiRelationEditor('Gewas', $this, Array('EDIT', 'EDITCONNECTION', 'DELETE'));
        $output .= $Relationeditor->display('Gekoppelde Gewassen');
        
        $output = $editor->display($_GET['cat'], $_GET['action'], 'table').$output;
        return($output);
    }

Dit returnt voor mij in 1x een formulier op het scherm met daarin 2 text inputs, een FCK editor, en een gestandaardiseerde Ajax'ed interface om verschillende objecten / rijen in de db aan elkaar te knopen. het hoeft dus niet meer door een view controller heen, en stylen doe je met css

Door in een website elk type content blok als een apart object te definiërern, en deze zijn eigen standaard stukje html uit te laten poepen is dit net zo snel qua programmeren als de gestandaardiseerde zut van .net, misschien nog wel sneller doordat er minder overhead is


Om weer even terug ontopic te komen:
Naar mijn mening is PHP5 helemaal klaar om 'mainstream' te worden. het is alleen nog een kwestie van tijd tot alle hosters ook over durven, dat zal het voor het grote publiek ook interessanter maken.

Voor m'n werk werk ik sinds ~vorig jaar maart fulltime in PHP5 en ik heb inmiddels zoveel standaard objecten bij elkaar geprogrammeerd dat ik momenteel bezig ben aan een soort van 'ruby on rails' voor PHP, maar dan nog een stukje mooier Ik hoef alleen nog maar een database aan een script te voeren, en een volledige CRUD/connect relaties front & backend wordt automatisch gegenereerd, in een zip geplaatst, en voila daar is je op maat gemaakte front-en-backend.

Meer details daarover misschien over een paar weken

[ Voor 34% gewijzigd door SchizoDuckie op 18-01-2006 02:32 ]

[Grijze Vos]

De enige goede reden die ik zie om PHP niet te gebruiken voor grote applicaties is dat het stateless is. Voor zover ik weet (geen ervaring met JSP etc) kun Java/JSP wel met states aan de slag.
Er zijn wel oplossingen voor, maar die zijn nog niet echt super te noemen. Misschien is dit wel het grootste verschil tussen een scripttaal als PHP en een volwassen programmeertaal met al zn ditjes en datjes als Java.

[twiekert]

Elke web-applicatie ongeacht de programmeertaal is stateless en dat is inherent aan het HTTP protocol .

[Grijze Vos]

Fout. Alhoewel het HTTP protocol stateless is, kun je nog steeds een laag erbovenop bouwen die wel state heeft.

[Mithrandir]

Maar is dat echt een voordeel? Waarom zou je zo'n state willen maintainen? Alles wat je wilt opslaan kun je in je session opslaan, en bijna nooit is het werkelijk interessant om zo'n state te onderhouden.

'Volwassenner' omdat het states heeft? Tsja... Het ligt er net aan wat je wilt doen, maar over het algemeen is de state nergens voor nodig. Verder is het 'minderwaardigheidscomplex' wat je scripttalen aan probeert te praten imho helemaal onzin:

Misschien is dit wel het grootste verschil tussen een scripttaal als PHP en een volwassen programmeertaal met al zn ditjes en datjes als Java.

Ten eerste zal een scripttaal als PHP nooit 'volwassen' worden of een programmeertaal worden als Java, omdat dat het DOEL helemaal niet is van PHP. Verder is een state bijhouden iets wat waarschijnlijk alleen handig is voor verstokte programmeurs die desktop-programming gewend zijn; ik heb nog nooit een state hoeven bijhouden voor welk programmeerwerk in PHP dan ook. Misschien is het juist een verkeerde insteek om dat wel te proberen.

[ Voor 3% gewijzigd door Mithrandir op 18-01-2006 10:20 ]

[Verwijderd]

SchizoDuckie schreef op woensdag 18 januari 2006 @ 02:22:
Eigenlijk is het ook de vraag of je wel GUI objecten wíl hebben.
De kracht van OO in PHP is imo júist dat je een object een lap html kan laten retourneren (wat jij een widget noemt) Een website bouwen vereist vaak een net iets andere gedachtengang dan een applicatie bouwen imo, maar dat met dat stukje OO wat je in php5 toch hebt wordt het allemaal wel erg makkelijk

Dit heeft helemaal niets met OO te maken. Jij zoekt gewoon naar een methode om html uit te poepen. Of dat een functie is of een object doet er dan niet toe. Dit heet probleem verplaatsen, niet OO programmeren.

Dat php domweg geen serieuse speler is moge duidelijk zijn. Goede threading, missen van een request scope, slecht naamgegeven library werken dit allemaal in de hand.

[Grijze Vos]

Mithrandir schreef op woensdag 18 januari 2006 @ 10:19:
Maar is dat echt een voordeel? Waarom zou je zo'n state willen maintainen? Alles wat je wilt opslaan kun je in je session opslaan, en bijna nooit is het werkelijk interessant om zo'n state te onderhouden.

'Volwassenner' omdat het states heeft? Tsja... Het ligt er net aan wat je wilt doen, maar over het algemeen is de state nergens voor nodig. Verder is het 'minderwaardigheidscomplex' wat je scripttalen aan probeert te praten imho helemaal onzin:

Ik probeer geen minderwaardigheidscomplexen aan te praten hoor. Ikzelf ben een fervent gebruiker van PHP. Echter, ik kan me voorstellen dat ik bij een -echt grote- applicatie weleens een state willen hebben.

Ten eerste zal een scripttaal als PHP nooit 'volwassen' worden of een programmeertaal worden als Java, omdat dat het DOEL helemaal niet is van PHP.

Als ik de ontwikkelingen van PHP bekijk dan vind ik dat het er iig wel op lijkt dat ze dat wel willen waarmaken.

Verder is een state bijhouden iets wat waarschijnlijk alleen handig is voor verstokte programmeurs die desktop-programming gewend zijn; ik heb nog nooit een state hoeven bijhouden voor welk programmeerwerk in PHP dan ook. Misschien is het juist een verkeerde insteek om dat wel te proberen.

Dat is an sich een heel interessant onderwerp voor een discussie; zelf heb ik nog net te weinig ervaring met "heel grote projecten" om daar echt over mee te kunnen praten.

[Not Pingu]

iCe01 schreef op dinsdag 17 januari 2006 @ 14:57:
PHP begint steeds meer te lijken op een normale OO-programmeertaal, terwijl de structuur van een webbased applicatie o.a. door het gebruik van HTTP (-get en -post) helemaal afwijkt van een normale applicatie die je opstart en laat lopen totdat er eens op het kruisje gedrukt wordt. Wordt over dit verschil expres heen gekeken, of heeft er niemand ooit aan gedacht dat zo'n verschil misschien ook vraagt om een andere manier van programmeren?

Over dit verschil wordt expres heengekeken omdat het verschil niet zou moeten bestaan. Service Oriented Architecture wordt een steeds groter goed en daarin maakt het niet uit of je businesslogica uiteindelijk wordt gebruikt in een clientapplicatie of dmv. een website aan de gebruiker wordt gepresenteerd.

[Mithrandir]

Grijze Vos schreef op woensdag 18 januari 2006 @ 10:40:
[...]

Ik probeer geen minderwaardigheidscomplexen aan te praten hoor. Ikzelf ben een fervent gebruiker van PHP. Echter, ik kan me voorstellen dat ik bij een -echt grote- applicatie weleens een state willen hebben.

Ok, dan heb ik misschien wat te bot gereageerd. Maar, welke dingen wil je in je state bijhouden? En voldoet een session-'object' dan niet?

Als ik de ontwikkelingen van PHP bekijk dan vind ik dat het er iig wel op lijkt dat ze dat wel willen waarmaken.

De taal wordt steeds volwassener, tot zo ver ben ik het met je eens. Ze gaan natuurlijk hun OO implementatie verbeteren, anders raken ze mensen kwijt. Maar van de andere kant zullen ze nooit het interpreted- en loosely-typed gedeelte van hun taal wegdoen; dan raken ze nog meer gebruikers kwijt.

Dat is an sich een heel interessant onderwerp voor een discussie; zelf heb ik nog net te weinig ervaring met "heel grote projecten" om daar echt over mee te kunnen praten.

Ik heb zelf geen ervaring met 'heel grote projecten', maar dan nog kan ik me niet voorstellen wanneer je een state wilt bijhouden... Misschien dat ik iets over het hoofd kijk, dat is heel goed mogelijk.

[jsiegmund]

De discussie hier is precies wat ik verwacht had... dus wat dat betreft niet echt vernieuwend. Maar ik zal enigzins proberen uit te leggen wat ik bedoel.

Zoals ook hier blijkt zijn er mensen die vinden dat PHP nog niet helemaal klaar is. Waarom niet? Het mist packages, mist dit, mist dat... nou en? Wie bepaald dat een goede webbased applicatie per se uit packages moet bestaan? En wat draagt een goede package structuur nou toe aan een goede applicatie. Het is een handig hulpmiddeltje, meer niet toch? Tuurlijk snap ik het nut er zelf ook wel van, maar we moeten een beetje uitkijken met dat soort dingen, zaken waardoor PHP steeds meer richting allang bestaande dingen gaat (zoals hierboven ook al gemeld).

Wat ik graag zou zien zijn échte OO oplossingen bruikbaar binnen de gehele applicatie. Om even door te gaan op de formulier voorbeelden die hierboven staan. Je gebruikt een mooie structuur om een form op te bouwen. Fijn OO, een form-object waaraan je wat invoervelden hangt die je kunt afdrukken, helemaal handig natuurlijk. Maar nu... je print de pagina, die verschijnt op het scherm van de gebruiker welke het formuliertje invult. De gebruiker verstuurt jou formuliertje, en wat krijg je aangeleverd? Juist, een non-OO array met waarden. Wat zou het toch lekker zijn als je dat formulier gewoon weer in dezelfde vorm aan kunt spreken. Gewoon $editor->Naam->getValue(); aanroepen en de waarde hebben die je nodig hebt.

Daar ligt dus meteen het verschil tussen een, wat ik "normale" applicatie noem, en een PHP gebaseerde webapplicatie. De OO-structuur wordt opgehakt in stukjes waardoor 'ie ineens niet zo logisch meer is. Ik liep hier tegenaan in een project dat ik volledig OO heb opgezet. Een klassendiagram gemaakt, database diagrammen, noem 't maar op. Nu heb ik dat raamwerk ingevuld, en dat werkt inderdaad heel prettig binnen de verschillende stukjes code. Maar het resultaat is wel dat bij iedere aanvraag van de gebruiker mijn script heel de klassenstructuur weer loopt op te bouwen. Dat brengt weer de nodige database requests met zich mee. Het een en ander werd er niet sneller op waardoor ik genoodzaakt was om optimalisaties in te voeren, voornamelijk het weglaten van, voor die betreffende pagina niet relevante, gegevens. Je krijgt dus een hele hoop losse applicaties waartussen weinig samenhang is. Die samenhang stop je weg in een database en de structuur van je scripts, maar moet wel iedere keer opnieuw opgebouwd worden.

Wat geweldig zou zijn is een soort "globaal" object waar je in kunt werken. Maar dan wel eentje die niet steeds opnieuw gegenereerd hoeft te worden, maar gewoon constant beschikbaar is. Maar goed, zie dat maar eens werkend te krijgen met verschillende gebruikers die overal bewerkingen op je structuur lopen uit te voeren! Zoiets valt misschien per gebruiker wel te maken met de hierboven genoemde sessie objecten, maar dat blijft knullig in relatie tot zaken als formulieren.

Zo ben ik dus aan het denken gegaan en me steeds meer af gaan vragen of dit nou echt zo handig is. En iedereen die loopt te roepen om standaard dingen als package structuren duwt het systeem steeds meer richting conventionele talen, terwijl dat misschien wel een gemiste kans is?

[ Voor 8% gewijzigd door jsiegmund op 18-01-2006 11:08 ]

[Verwijderd]

iCe01 schreef op woensdag 18 januari 2006 @ 11:06:
Zoals ook hier blijkt zijn er mensen die vinden dat PHP nog niet helemaal klaar is. Waarom niet? Het mist packages, mist dit, mist dat... nou en? Wie bepaald dat een goede webbased applicatie per se uit packages moet bestaan? En wat draagt een goede package structuur nou toe aan een goede applicatie. Het is een handig hulpmiddeltje, meer niet toch?

Volgens jou argumentatie kunnen we het net zo goed in assembly schrijven.

[Not Pingu]

iCe01 schreef op woensdag 18 januari 2006 @ 11:06:

Wat ik graag zou zien zijn échte OO oplossingen bruikbaar binnen de gehele applicatie. Om even door te gaan op de formulier voorbeelden die hierboven staan. Je gebruikt een mooie structuur om een form op te bouwen. Fijn OO, een form-object waaraan je wat invoervelden hangt die je kunt afdrukken, helemaal handig natuurlijk. Maar nu... je print de pagina, die verschijnt op het scherm van de gebruiker welke het formuliertje invult. De gebruiker verstuurt jou formuliertje, en wat krijg je aangeleverd? Juist, een non-OO array met waarden. Wat zou het toch lekker zijn als je dat formulier gewoon weer in dezelfde vorm aan kunt spreken. Gewoon $editor->Naam->getValue(); aanroepen en de waarde hebben die je nodig hebt.

Dat is precies het model wat ASP.NET gebruikt. Je definieert je controls/widgets in XML-vorm tussen je HTML en die worden dan beschikbaar als objecten. Knoppen zorgen er altijd voor dat de pagina wordt gepost naar zichzelf, en daar wordt het formulier opnieuw opgebouwd met de ingevulde gegevens.
Vervolgens kun je in de event handler van die knop al je textboxen etc. uitlezen.

[frickY]

Als je het mij vraagt waren voorgangers van PHP ook al prima geschikt om grote applicaties mee te bouwen. Ik liep hierbij echter wel altijd tegen beperkingen van MySQL aan. Omdat je geen relationele integriteit kon afdwingen (in 5.0 kan dit volgens mij wel) kon het wel eens gebeuren dat je ergens een controlle vergat als er eens een relatie bij kwam.

Grijze Vos schreef op woensdag 18 januari 2006 @ 06:27:
De enige goede reden die ik zie om PHP niet te gebruiken voor grote applicaties is dat het stateless is..

Err... HTTP is stateless.. dus logisch dat PHP het ook is

Na 6 jaari n PHP gewerkt te hebben werk ik nu sinds 1 januari bij een nieuwe werkgever in ASP. En ik moet zeggen.. ik mis PHP.Ik vind al die 'packages/objecten' in ASP bijzonder irritant. Voor de meest gebruikte functionaliteiten bij een beetje web-applicatie, heb je al direct externe componenten nodig. PHP heeft alle vanzelfsprekende functies ingebakken zitten.
Daarbij vind ik het zoeken in MSDN naar de werking van een object op zijn minst gezegd een crimè.
Ik weet niet hoe het met ASP.Net zit, maar ik vind PHP een stuk geschikter voor webontwikkeling dan ASP.

[ Voor 61% gewijzigd door frickY op 18-01-2006 11:23 ]

[Verwijderd]

Als dat de enige beperking was: Hoe pas je bijvoorbeeld op een nette manier een Decorator pattern toe in php? (templating is immers een achterhaalde techniek, het is een anti pattern)

[jsiegmund]

Verwijderd schreef op woensdag 18 januari 2006 @ 11:11:
[...]
Volgens jou argumentatie kunnen we het net zo goed in assembly schrijven.

Als je niks redelijks bij te dragen hebt... Ik geef toch al duidelijk aan dat ik graag fatsoenlijk OO wil werken? Onzin over assembly dus.

Ik maak alleen een opmerking over het duwen van de ontwikkeling van PHP. Als het gros van de gebruikers vraagt om een package structuur, zullen ze eerder geneigd zijn om dat te gaan maken. Dat terwijl een model zoals dat blijkbaar in ASP.NET zit misschien wel een stuk handiger is. Meningen verschillen uiteraard?

Naar mijn mening hoeft de HTTP request-structuur van een website niet meteen te betekenen dat we gaan werken op de manier zoals we dat nu doen. Ik zie het liever als een noodzakelijke pauze waarin gewacht wordt op nieuwe invoer van de gebruiker, maar waarin de applicatie haar content niet verliest.

[ Voor 23% gewijzigd door jsiegmund op 18-01-2006 11:26 ]

[Verwijderd]

iCe01 schreef op woensdag 18 januari 2006 @ 11:22:
Als je niks redelijks bij te dragen hebt, zeg dan niks. Ik geef toch al duidelijk aan dat ik graag fatsoenlijk OO wil werken? Ik maak alleen een opmerking over het duwen van de ontwikkeling van PHP. Als het gros van de gebruikers vraagt om een package structuur, zullen ze eerder geneigd zijn om dat te gaan maken. Dat terwijl een model zoals dat blijkbaar in ASP zit misschien wel een stuk handiger is. Meningen verschillen uiteraard.

Aangedragen missers af doen als "niet nodig" kent geen grenzen. Dus is het terecht om op te merken dat volgens jou argumentatie assembly geschikt zou zijn.

In php kun je nou eenmaal niet fatsoenlijk met OO werken aangezien de architectuur teveel mist. Zodoende zijn vele patterns zonder workarounds niet mogelijk. Pattenrs als MVC (missen van een request scope) en decorator (missen van request chaining) zijn dus niet zonder workarounds mogelijk.

[Not Pingu]

iCe01 schreef op woensdag 18 januari 2006 @ 11:22:

Naar mijn mening hoeft de HTTP request-structuur van een website niet meteen te betekenen dat we gaan werken op de manier zoals we dat nu doen. Ik zie het liever als een noodzakelijke pauze waarin gewacht wordt op nieuwe invoer van de gebruiker, maar waarin de applicatie haar content niet verliest.

Je bedoelt eigenlijk: "..waarin de interface haar content niet verliest.", want je applicatie aan serverzijde heeft weldegelijk state in de vorm van sessions of data-persistence in een database, bestandssysteem of whatever.

ASP.NET heeft dat als een soort workaround opgelost (je post nog steeds naar de server, maar je blijft binnen dezelfde paginacontext en je data blijft behouden). Om echt statefulness aan clientzijde te hebben, moet je naar iets als AJAX of Flash kijken. En daarbij komt het Service oriented architecture verhaal weer kijken: je PHP/ASP.NET/Java/whatever applicatie levert dus niet meer de interface aan, maar alleen de data en verzorgt de businesslogica.

[Bosmonster]

Verwijderd schreef op woensdag 18 januari 2006 @ 11:17:
Als dat de enige beperking was: Hoe pas je bijvoorbeeld op een nette manier een Decorator pattern toe in php? (templating is immers een achterhaalde techniek, het is een anti pattern)

Templating past anders prima in MVC (de views).

[Verwijderd]

Bosmonster schreef op woensdag 18 januari 2006 @ 11:57:
Templating past anders prima in MVC (de views).

Absoluut niet!
Met templating moet je de view bekend maken aan het model. Terwijl MVC juist dicteert dat enkel je view notie heeft met welk (concreet) model het te maken heeft. Dus nee, templating past absoluut niet binnen MVC.

[Janoz]

IMHO hebben mensen die met droge ogen beweren dat php niet minder geschikt is voor het bouwen van grote applicaties dan J2ee of .net hebben waarschijnlijk nog nooit fatsoenlijk met die omgevingen gewerkt. Het afwezig zijn van namespaces, het missen van een application en request scope, een beperkte implementatie van de session scope, het feit dat een relatief pad altijd geldt tov het eerst aangeroepen bestand ipv het huidige bestand, het niet aanroepen van een parent constructor in een derived class, ongedefinieerd gedrag bij pass by referenc versus pass by value, enz enz zijn nog maar een begin. Dit is een lijstje wat ik nu even snel uit mijn hoofd opdreun. En daartussen zitten al enkele punten die gewoon onoplosbaar zijn zonder compleet te breken met backward compatability (wat trouwens ook al niet eens onwaarschijnlijk is in php land, wat tegelijkertijd weer een groot nadeel is. Wie zegt dat bij php 6.0 of 5.3 je enteprise app nog steeds werkt?)

php is een hobby project en zal dat altijd blijven.

[Brakkie]

Verwijderd schreef op woensdag 18 januari 2006 @ 10:24:
[...]
Dat php domweg geen serieuse speler is moge duidelijk zijn. Goede threading, missen van een request scope, slecht naamgegeven library werken dit allemaal in de hand.

Door aan te geven wat er niet kan en wat er mis is met php heb je nog geen goede argumentatie gegeven waarom php geen serieuze speler is op de webapplicatie markt. Er zijn volgens mij heel wat serieuze applicaties gebouwd in php.

- flickr. worden ook andere talen in gebruikt , perl, java, maar blijkbaar hebben ze voor ieder deel van de applicatie de taal gekozen waarin die taal het beste is. ( http://www.niallkennedy.com/blog/uploads/flickr_php.pdf)
- react. Naar mijn mening een zeer degelijke web applicatie.
- yahoo heeft ook gekozen voor php bij het bouwen van webaaplicaties.

Natuurlijk heeft php nadelen maar stellen dat php geen serieuze speler is op basis van gebreken en tekort komingen gaat niet op. Een design pattern is volgens mijn bescheiden OO kennis min of meer een soort best-practice om een structureel probleem aan te pakken. Wanneer dit ook op een andere manier kan is dit niet perse slechter.

[Bosmonster]

Verwijderd schreef op woensdag 18 januari 2006 @ 12:01:
[...]
Absoluut niet!
Met templating moet je de view bekend maken aan het model. Terwijl MVC juist dicteert dat enkel je view notie heeft met welk (concreet) model het te maken heeft. Dus nee, templating past absoluut niet binnen MVC.

Misschien moet je je eens wat minder stug vasthouden aan regeltjes en iets flexibeler omgaan met concepten als design patterns (en alternatieve programmeertalen wat dat betreft). Ze zijn er niet om je een werkwijze te 'dicteren', zoals je dat zo mooi zegt, maar om je een hulpmiddel te bieden bij het bereiken van je doel.

Er zijn meer wegen die naar Rome leiden...

[ Voor 9% gewijzigd door Bosmonster op 18-01-2006 12:12 ]

[Verwijderd]

Brakkie schreef op woensdag 18 januari 2006 @ 12:05:
Door aan te geven wat er niet kan en wat er mis is met php heb je nog geen goede argumentatie gegeven waarom php geen serieuze speler is op de webapplicatie markt. Er zijn volgens mij heel wat serieuze applicaties gebouwd in php.

Een opsomming van een paar toepassingen doet dat net zo min. Overigens zijn je van de "serieuse markt" vrij weinig. Het betreft hier vaak interne maatwerk applicaties. Niet een of ander forumpje waar amper (veranderlijke) businesslogic aan te pas komt. OP het moment dat je daar mee te maken hebt wil je een omgeving hebben die hierin voorziet.

Een pattern niet kunnen toepassen betekend feitelijk dat je een workaround moet toepassen.

Bosmonster schreef op woensdag 18 januari 2006 @ 12:12:
Misschien moet je je eens wat minder stug vasthouden aan regeltjes en iets flexibeler omgaan met concepten als design patterns (en alternatieve programmeertalen wat dat betreft). Ze zijn er niet om je een werkwijze te 'dicteren', zoals je dat zo mooi zegt, maar om je een hulpmiddel te bieden bij het bereiken van je doel.

Jij stelt dat templating prima past binnen het MVC paradigm wat dus niet het geval is. Door te stellen dat je hier wat flexibiler moet omgaan met mvc betekend dat je compleet de kracht uit mvc haalt: Namelijk de manier van presenteren loskoppelen van je model. Door het gebruik van templating koppel je dit juist weer.

Het doel is dus loskoppelen van data en presentatie (opdat je makkelijk een andere presentatie laag kunt toepassen). Het mvc pattern voorziet hierin, templating ontkracht dit. Dus je argument slaat als een tang op een varken.

[ Voor 40% gewijzigd door Verwijderd op 18-01-2006 12:19 ]

[Brakkie]

Verwijderd schreef op woensdag 18 januari 2006 @ 12:12:
[...]
Een opsomming van een paar toepassingen doet dat net zo min. Overigens zijn je van de "serieuse markt" vrij weinig. Het betreft hier vaak interne maatwerk applicaties. Niet een of ander forumpje waar amper (veranderlijke) businesslogic aan te pas komt. OP het moment dat je daar mee te maken hebt wil je een omgeving hebben die hierin voorziet.

Een pattern niet kunnen toepassen betekend feitelijk dat je een workaround moet toepassen.

De applicaties die ik in mijn vorige post noemde vind ik behoorlijk groot en serieus, dit topic gaat dan ook over het bouwen van grote applicaties in php.

Het zou weleens leuk zijn als een topic als dit eens zou gaan over hoe je wel grote web applicaties kan bouwen met php en waar je dan rekening me moet houden. Het loopt altijd maar uit op discussies over welke design patterns je niet kan toepassen en wat er allemaal nog meer fout is aan php. Kom dan op z'n minst met workarounds om deze tekort komingen zoveel mogelijk te elimineren.

[ Voor 4% gewijzigd door Brakkie op 18-01-2006 12:25 ]

[Bosmonster]

Verwijderd schreef op woensdag 18 januari 2006 @ 12:12:
[...]

Het doel is dus loskoppelen van data en presentatie (opdat je makkelijk een andere presentatie laag kunt toepassen). Het mvc pattern voorziet hierin, templating ontkracht dit. Dus je argument slaat als een tang op een varken.

Door templates kan ik kiezen of ik er een html pagina, xml, pdf, of wat voor view dan ook van wil maken. In welk opzicht is data en presentatie dan gekoppeld?

[kenneth]

Brakkie schreef op woensdag 18 januari 2006 @ 12:25:
Het zou weleens leuk zijn als een topic als dit eens zou gaan over hoe je wel grote web applicaties kan bouwen met php en waar je dan rekening me moet houden. Het loopt altijd maar uit op discussies over welke design patterns je niet kan toepassen en wat er allemaal nog meer fout is aan php. Kom dan op z'n minst met workarounds om deze tekort komingen zoveel mogelijk te elimineren.

Als de opties zijn:
• Workarounds (het woord alleen al ) verzinnen om in PHP te kunnen ontwikkelen;
• Een platform gebruiken wat wél de mogelijkheid biedt DP's en best practices ten volle te gebruiken.

Dan weet ik wel dat ik niet voor PHP kies. En dat nog los van het feit dat PHP slechts een taal is, met een grote onoverzichtelijke bibliotheek (namespaces? helloooo 1980!), en geen fatsoenlijk framework biedt.

[Verwijderd]

Bosmonster schreef op woensdag 18 januari 2006 @ 12:25:
Door templates kan ik kiezen of ik er een html pagina, xml, pdf, of wat voor view dan ook van wil maken. In welk opzicht is data en presentatie dan gekoppeld?

Je kunt je model(template defenition) aanpassen om een andere view (template) te laten zien. maar ik wil mijn model intact houden. Tevens is het geen informatie die aan een model toebehoort wat je applicatie minder overzichtelijk maakt.

Brakkie schreef op woensdag 18 januari 2006 @ 12:25:
Het zou weleens leuk zijn als een topic als dit eens zou gaan over hoe je wel grote web applicaties kan bouwen met php en waar je dan rekening me moet houden. Het loopt altijd maar uit op discussies over welke design patterns je niet kan toepassen en wat er allemaal nog meer fout is aan php. Kom dan op z'n minst met workarounds om deze tekort komingen zoveel mogelijk te elimineren.

Waarom? De vraag is toch of php geschikt is. Nou nee dus.

[.oisyn]

Verwijderd schreef op woensdag 18 januari 2006 @ 12:12:
Het doel is dus loskoppelen van data en presentatie (opdat je makkelijk een andere presentatie laag kunt toepassen). Het mvc pattern voorziet hierin, templating ontkracht dit. Dus je argument slaat als een tang op een varken.

Je zegt steeds dat templating dat ontkracht, maar waarom dan? Ik vind van niet, met een goed template systeem is je template de code (en dus niet een simpel html filetje met wat tags erin die aangeven welke data waar moet komen) die de presentatie levert. Hij loopt door de data en transformeert dat in een bepaalde output. En die output kan alles zijn. Een typische view dus.

[Verwijderd]

.oisyn schreef op woensdag 18 januari 2006 @ 12:34:
Je zegt steeds dat templating dat ontkracht, maar waarom dan? Ik vind van niet, met een goed template systeem is je template de code (en dus niet een simpel html filetje met wat tags erin die aangeven welke data waar moet komen) die de presentatie levert. Hij loopt door de data en transformeert dat in een bepaalde output. En die output kan alles zijn. Een typische view dus.

Aan de template zelf is ook niet veel mis. Maar met de flow wel. Met templating moet je het model in een template injecteren. Zodoende koppel je model dus aan je view.

Als je naar een decorator kijkt dan wordt je mdel gewoon mooi versiert. Het model heeft geen enkele notie daarvan.

[.oisyn]

Tja, dan gebruik je simpelweg de verkeerde template systemen. In mijn forum wordt de data niet geinjecteert in de template, maar gaat het andersom (wat ik in mijn vorige post dus duidelijk probeerde te maken)

[ Voor 18% gewijzigd door .oisyn op 18-01-2006 12:45 ]

[Verwijderd]

.oisyn schreef op woensdag 18 januari 2006 @ 12:44:
Tja, dan gebruik je simpelweg de verkeerde template systemen. In mijn forum wordt de data niet geinjecteert in de template, maar gaat het andersom (wat ik in mijn vorige post dus duidelijk probeerde te maken)

Dus je hebt feitelijk een decorator gemaakt?

[.oisyn]

En reageer nou eens even op datgene waar het over ging.

[Verwijderd]

.oisyn schreef op woensdag 18 januari 2006 @ 12:50:
En reageer nou eens even op datgene waar het over ging.

[.oisyn]

jij zegt dat je je model aan moet passen als je een andere view wilt mbv templates, ik zeg dat dat niet het geval is met een goed template systeem. En dan begin je ineens over decorators, hoe past dat in het verhaal? Maar om je vraag te beantwoorden: nee ik heb geen decorator gemaakt, ik heb verschillende views voor m'n model. En de controller bepaalt welke data van m'n model nodig is en in welke view dat gerepresenteert moet worden.

.edit: @ reactie hieronder: http://www.exciton.cs.ric...erns/DecoratorPattern.htm
Ik zie mijn flow echt niet als een decorator hoor. Maar goed, dit gaat inmiddels nergens meer over, als jij het als decorator wil zien moet je dat vooral doen, ik wilde alleen maar aantonen dat PHP niet per definitie ongeschikt is voor MVC patterns (of decorators for that matter).

.edit2: MVC er ook bij voor de volledigheid.

.edit3: natuurlijk is dat ook een template engine, aangezien de verschillende views gedefinieerd worden door templates.

[ Voor 84% gewijzigd door .oisyn op 18-01-2006 13:47 ]

[Verwijderd]

Wat jij dus beschrijft heeft helemaal niets te maken met een template engine. Maar inderdaad gewoon met een mvc pattern.

edit:
Ik merk, uit je verscheidene edits, dat je moeite hebt patroon herkenning van hetgeen je geschreven hebt. Misschien is het raadzaam hier wat meer in te verdiepen want het maakt eventuele toekomstige discussie wat makkelijker.

[ Voor 100% gewijzigd door Verwijderd op 18-01-2006 14:08 ]

[jsiegmund]

Gunp01nt schreef op woensdag 18 januari 2006 @ 11:49:
[...]

Je bedoelt eigenlijk: "..waarin de interface haar content niet verliest.", want je applicatie aan serverzijde heeft weldegelijk state in de vorm van sessions of data-persistence in een database, bestandssysteem of whatever.

ASP.NET heeft dat als een soort workaround opgelost (je post nog steeds naar de server, maar je blijft binnen dezelfde paginacontext en je data blijft behouden). Om echt statefulness aan clientzijde te hebben, moet je naar iets als AJAX of Flash kijken. En daarbij komt het Service oriented architecture verhaal weer kijken: je PHP/ASP.NET/Java/whatever applicatie levert dus niet meer de interface aan, maar alleen de data en verzorgt de businesslogica.

Klopt, en het valt uiteraard ook best voor elkaar te krijgen. Maar dan krijg je binnen "het PHP wereldje" een verzameling van modules of klassenverzamelingen die dit soort dingen afhandelen. Verre van een standaard oplossing dus, wat met dit soort dingen wel wenselijk is. Zelfde als de rommelige invoer van het DOM model wat nu uiteindelijk een fatsoenlijke implementatie lijkt te hebben.

Zelfde geld voor AJAX... enorm veel (verschillende) uitwerkingen die geen van allen écht handig werken (vind ik). Dat soort oplossingen wordt geschreven met een specifiek doel in het achterhoofd, terwijl een echt generieke oplossing veel handiger zou zijn. Overigens heeft AJAX in pure vorm weinig tot niks met PHP van doen natuurlijk, dat PHP toevallig een HTTP request beantwoord is in principe bijzaak (offtopic).

Brakkie schreef op woensdag 18 januari 2006 @ 12:25:
[...]
Het zou weleens leuk zijn als een topic als dit eens zou gaan over hoe je wel grote web applicaties kan bouwen met php en waar je dan rekening me moet houden. Het loopt altijd maar uit op discussies over welke design patterns je niet kan toepassen en wat er allemaal nog meer fout is aan php. Kom dan op z'n minst met workarounds om deze tekort komingen zoveel mogelijk te elimineren.

Daar heb ik ook aan gedacht, maar zoals je zelf al zegt: vele wegen naar Rome, zo'n topic zou alleen maar nog meer discussie met zich meebrengen denk ik. Is het nog niet fout om er eens over na te denken natuurlijk.

Verwijderd schreef op woensdag 18 januari 2006 @ 12:41:
[...]
Aan de template zelf is ook niet veel mis. Maar met de flow wel. Met templating moet je het model in een template injecteren. Zodoende koppel je model dus aan je view.

Als je naar een decorator kijkt dan wordt je mdel gewoon mooi versiert. Het model heeft geen enkele notie daarvan.

Als ik jou reacties bij elkaar op tel vind je dus een willekeurige taal die niet jou design patterns ondersteund sowieso al niks? Beetje kortzichtig aangezien patterns maar suggesties zijn naar mogelijke oplossingen. Niemand die beweert dat het de beste oplossing is, of dat er geen andere oplossingen zijn. Het ligt juist aan de creativiteit van de ontwerper om een oplossing te zoeken voor praktische problemen, ondersteuning (of het gebrek daaraan) hoort daar ook bij. Het afkeuren van een taal omdat de scripts uit een boek er niet in draaien is wel redelijk makkelijk wanneer die taal misschien andere oplossingen wel prima ondersteund.

Dan kom je weer uit op mijn eerdere argument. Ook design patterns zijn volledig gericht op de OO manier van werken zoals we dat doen in bijvoorbeeld Java. Maar mijn vraag was al: is die manier wel geschikt om webapplicaties in te ontwerpen? Wanneer al blijkt dat daar misschien wel betere oplossingen voor zijn, dan kun je al die patterns ook in de prullenbak schuiven om nieuwe te maken voor "de nieuwe manier van programmeren". Vooruitgang boek je door even langs je oogkleppen te kijken, probeer even langs die weg te redeneren.

[Verwijderd]

iCe01 schreef op woensdag 18 januari 2006 @ 13:31:
Als ik jou reacties bij elkaar op tel vind je dus een willekeurige taal die niet jou design patterns ondersteund sowieso al niks?

Nee. Ik doel hier op webapplicaties waarbij het gebruik van een aantal patterns bijdragen aan overzichtelijke makkelijk te onderhouden code. Het doel maakt de patterns onmisbaar.

iCe01 schreef op woensdag 18 januari 2006 @ 13:31:
Beetje kortzichtig aangezien patterns maar suggesties zijn naar mogelijke oplossingen. Niemand die beweert dat het de beste oplossing is, of dat er geen andere oplossingen zijn.

ik ook iet, maar ik wil makkelijk te onderhouden code, die ook begrijpelijk is voor collega's. Een daar dragen de patterns wel degelijk aan bij aangezien het algemeen geacepteerde concepten zijn.

iCe01 schreef op woensdag 18 januari 2006 @ 13:31:Het ligt juist aan de creativiteit van de ontwerper om een oplossing te zoeken voor praktische problemen, ondersteuning (of het gebrek daaraan) hoort daar ook bij. Het afkeuren van een taal omdat de scripts uit een boek er niet in draaien is wel redelijk makkelijk wanneer die taal misschien andere oplossingen wel prima ondersteund.

Dit is waar, ware het niet dat je nu genoodzaakt bent workarounds te introduceren. Die zijn natuurlijk ten alle tijde onwenselijk en maakt je collega niet een blijer persoon.

iCe01 schreef op woensdag 18 januari 2006 @ 13:31:Dan kom je weer uit op mijn eerdere argument. Ook design patterns zijn volledig gericht op de OO manier van werken zoals we dat doen in bijvoorbeeld Java.

Incorrect, design patterns beperken zich absoluut niet tot OO talen (het eerste foutje op de voorkant van het boek van GoF )

iCe01 schreef op woensdag 18 januari 2006 @ 13:31:Maar mijn vraag was al: is die manier wel geschikt om webapplicaties in te ontwerpen? Wanneer al blijkt dat daar misschien wel betere oplossingen voor zijn, dan kun je al die patterns ook in de prullenbak schuiven om nieuwe te maken voor "de nieuwe manier van programmeren". Vooruitgang boek je door even langs je oogkleppen te kijken, probeer even langs die weg te redeneren.

Ik vind dit een mooi filosofisch stukje van je betoog maar jij stelt nu voor om een stapje terug te doen en noemt dat vooruitgang

[Verwijderd]

.oisyn schreef op woensdag 18 januari 2006 @ 13:08: Maar goed, dit gaat inmiddels nergens meer over, als jij het als decorator wil zien moet je dat vooral doen, ik wilde alleen maar aantonen dat PHP niet per definitie ongeschikt is voor MVC patterns (of decorators for that matter).

Dat aantonen is je niet gelukt. Php is per definitie ongeschikt voor het decorator pattern (zonder workarounds). Dit komt door het simpele feit dat php niet aan request chaining doet hetgeen noodzakelijk is voor een dergelijke implementatie.

[Janoz]

De requests en de gegenereerde html is maar een kleine schil om je applicatie. Wat er binnenin gebeurt is daadwerkelijk je buisness logic. Het maakt niet uit of een actie hierop uitgevoerd wordt doordat er een request binnenkomt of omdat er op een knop op een applicatie gedrukt is. Dat het om een webapplicatie gaat is maar een minimale impact op het hele systeem en de eventuele problemen die dit oproepen kun je in die schil al aanpakken zonder dat het consequenties heeft voor je gehele buisness logic.

Ik vind de opmerking van jou over oogkleppen wel grappig. Uit je opmerkingen maak ik op dat je zelf nog geen webapplicaties geschreven heb in iets anders dan php. De betere oplossing is er al, en het is niet php. Ik raad je aan eens daadwerkelijk te kijken naar .net of j2ee. Er zal waarschijnlijk een wereld voor je open gaan.

[.oisyn]

Verwijderd schreef op woensdag 18 januari 2006 @ 13:50:
[...]
Dat aantonen is je niet gelukt. Php is per definitie ongeschikt voor het decorator pattern (zonder workarounds). Dit komt door het simpele feit dat php niet aan request chaining doet hetgeen noodzakelijk is voor een dergelijke implementatie.

Wat is een decorator pattern volgens jou, want volgens mij klopt dat helemaal niet met de definitie zoals ik die ken (linkje1, linkje2, linkje3, google search link). Het heeft niets met het wel- of niet aanwezig zijn van request chaining te maken. Het heeft te maken dat je een interface kunt implementeren (wat kan in PHP) en de calls door kunt routen naar een andere implementatie van diezelfde interface (wat uiteraard ook gewoon kan in PHP)

[ Voor 11% gewijzigd door .oisyn op 18-01-2006 14:05 ]

[Burat]

Janoz schreef op woensdag 18 januari 2006 @ 13:50:Uit je opmerkingen maak ik op dat je zelf nog geen webapplicaties geschreven heb in iets anders dan php. De betere oplossing is er al, en het is niet php. Ik raad je aan eens daadwerkelijk te kijken naar .net of j2ee. Er zal waarschijnlijk een wereld voor je open gaan.

Mwa, dit is ook behoorlijk subjectief. Ik heb webapplicaties ontwikkeld in vrijwel alle talen, van J2EE/.Net tot Python, Perl en PHP. En zo zwart-wit als jij het stelt, is het imo niet.

De laatste paar jaar ben ik sterk betrokken bij een aantal behoorlijk grote en ingewikkelde web-applicaties in PHP. Hierbij zijn we tegen veel grenzen aangelopen en hebben bekende problemen op een nieuwe manier opgelost. En alles bij elkaar ben ik bijzonder gelukkig met de keuze voor PHP.

Ik ben met iedereen eens dat de traditionele OO-modelleertechnieken niet zonder meer toe te passen zijn en dat het simplisme van PHP bepaalde nadelen heeft. Maar het maakt ook veel mogelijk .

[Verwijderd]

.oisyn schreef op woensdag 18 januari 2006 @ 14:04:
Wat is een decorator pattern volgens jou, want volgens mij klopt dat helemaal niet met de definitie zoals ik die ken Het heeft niets met het wel- of niet aanwezig zijn van request chaining te maken. Het heeft te maken dat je een interface kunt implementeren (wat kan in PHP) en de calls door kunt routen naar een andere implementatie van diezelfde interface (wat uiteraard ook gewoon kan in PHP)

Wat ik een stukje terug al als edit opschreef wordt met dit stukje bevestigd. Oftewel lees je even in in patronen want dat maakt de discussie een stuk aangenamer. In je zelf opgezochte linkjes staat het veelal goed beschreven. Tevens zul je dan begrijpen wat het chainen van request hier mee van doen heeft.

[jsiegmund]

@Janoz: Daar heb je gelijk in, ik heb nog geen ervaring met andere systemen. Vandaar dat ik nu tegen deze vragen aan loop en ook zeker open sta voor alternatieven. Ware het niet dat het onder de knie krijgen van .NET wel even iets anders is als een tutorial doorlezen. Ben aan deze systemen bezig naast m'n normale bezigheden, dus loop niet over van de tijd om me daar eens even diep in te storten.

In principe moet het inderdaad niet uitmaken hoe de input in je applicatie verschijnt. Daaruit zou je concluderen dat het programmeren feitelijk ook niet teveel verschilt, maar daar ben ik het toch niet mee eens. Daaruit lijdt ik dan van af dat jou manier van werken blijkbaar beter geschikt is als de mijne... kleine insight misschien?

@Mark: een goede ontwerper weet ook hoe hij zijn ontwerp documenteert, zonder constant te verwijzen naar design patterns. Lang niet al jou collega's zullen alle designpatterns uit het hoofd kennen lijkt me, dus moet er toch gezocht en gelezen worden. Of er dan "standaard" documentatie tevoorschijn komt, of documentatie die je hebt geschreven over je eigen stukje code maakt dan weinig uit lijkt me. Kwestie van duidelijk beschrijven wat je hoe en waarom hebt gedaan en ook je collega's begrijpen prima wat er aan de hand is, ook zonder patterns. Ik begrijp je standpunt wel, maar hou niet zo van hypes, waar designpatterns naar mijn mening wel onder vallen. Het idee erachter is prachtig en wanneer je ze kunt gebruiken moet je dat ook zeker doen. Maar staar je er niet op blind alsof het "the only way to go" is geworden.

Burat schreef op woensdag 18 januari 2006 @ 14:04:
[...]
De laatste paar jaar ben ik sterk betrokken bij een aantal behoorlijk grote en ingewikkelde web-applicaties in PHP. Hierbij zijn we tegen veel grenzen aangelopen en hebben bekende problemen op een nieuwe manier opgelost. En alles bij elkaar ben ik bijzonder gelukkig met de keuze voor PHP.

Misschien een voorbeeldje? Vooral dat "bekende problemen oplossen op een nieuwe manier" klinkt interesting.

[ Voor 16% gewijzigd door jsiegmund op 18-01-2006 14:17 ]

[.oisyn]

@ mark: In plaats van maar gewoon kinderachtig aan te nemen dat ik niet weet waar ik het over heb kun je ook gewoon even je eigen definitie (die net zo goed niet kan kloppen) even geven zodat we de discrepantie kunnen vinden. Wellicht heb je het over een bepaalde toepassing van het decorator pattern in een webapplicatie, maar dat is me dan niet helemaal duidelijk omdat je het hebt over het feit dat een decorator pattern per definitie niet geschikt is voor PHP. Het moge duidelijk zijn dat het laatste deel van de voorlaatste zin niet hetzelfde is als het eerste deel.

Hier een goed voorbeeld van het decorator pattern in PHP, hoewel ik niet zal beweren dat dit design in weze ook een goed design is, maar daar gaat het dan ook niet om (hetzelfde voor de syntax):

PHP:

interface Database
{
    public function RunQuery($sqlstring);
}

class MySQLDatabase implements Database
{
    public function RunQuery($sqlstring) { }
}

abstract class DBDecorator implements Database
{
    protected var $dbInstance;

    public function RunQuery($sqlstring) { return $dbInstance->RunQuery($sqlstring); }
}

class MySQLDBDecorator extends DBDecorator
{
    public __construct()
    {
        $dbInstance = new MySQLDatabase();
    }

    public function RunQuery($sqlstring)
    {
        // parse the query and rewrite it so that MySQL supports it
        return $dbInstance->RunQuery($mysqlCompatibleQuery);
    }
}

[ Voor 90% gewijzigd door .oisyn op 18-01-2006 14:36 ]

[Verwijderd]

iCe01 schreef op woensdag 18 januari 2006 @ 14:16:
Ik begrijp je standpunt wel, maar hou niet zo van hypes, waar designpatterns naar mijn mening wel onder vallen.

Ja na deze opmerking ben ik klaar. Ik sluit me aan bij Janoz dat je je eerst maar eens moet verdiepen in de stof.

[Verwijderd]

.oisyn schreef op woensdag 18 januari 2006 @ 14:16:
@ mark: In plaats van maar gewoon kinderachtig aan te nemen dat ik niet weet waar ik het over heb kun je ook gewoon even je eigen definitie (die net zo goed niet kan kloppen) even geven zodat we de discrepantie kunnen vinden.

Niets met kinderachtig te maken. Ik kan het opmaken uit je reactie.
kijk bijvoorbeeld naar sitemesh

[Janoz]

iCe01 schreef op woensdag 18 januari 2006 @ 14:16:
In principe moet het inderdaad niet uitmaken hoe de input in je applicatie verschijnt. Daaruit zou je concluderen dat het programmeren feitelijk ook niet teveel verschilt, maar daar ben ik het toch niet mee eens.

Waarom ben je het daar niet mee eens? Natuurlijk mag je het er oneens mee zijn, maar kun je ook vertellen waarom? Als je je buisness logic geschreven hebt dan maakt het toch niet uit of de insertSomeObject(someObjectDTO) wordt aangeroepen vanuit een actie die de gegevens uit het request haalt of door een event dat de gegevens uit een applicatie formulier haalt?

Ik begrijp je standpunt wel, maar hou niet zo van hypes, waar designpatterns naar mijn mening wel onder vallen. Het idee erachter is prachtig en wanneer je ze kunt gebruiken moet je dat ook zeker doen. Maar staar je er niet op blind alsof het "the only way to go" is geworden.

Design patterns "een hype" noemen vind ik een beetje kort door de bocht. Specifieke design patters zou je het label hype kunnen geven, maar het geheel niet. Ik durf te wedden dat je op dit moment ook al gewoon patterns gebruikt, alleen weet je toevallig neit welk naampje erbij hoort.

[.oisyn]

Verwijderd schreef op woensdag 18 januari 2006 @ 14:28:
[...]
Niets met kinderachtig te maken. Ik kan het opmaken uit je reactie.
kijk bijvoorbeeld naar sitemesh

Dat is dus een decorator framework, wat een globale implementatie is van het decorator pattern. Oftewel een implementatie van het decorator pattern zoals ik al zei, en niet het decorator pattern wat in PHP niet mogelijk zou zijn (en dat is wat jij zei, zie overigens ook mijn vorige edit).

.edit: Die context is een beetje door jezelf gecreëerd imho, en niet echt naar buiten gebracht (neem nou een van je eerste reacties: [rml]mark platvoet in "[ discussie] Gebruik van PHP5.x in grote ..."[/rml]. "In php kun je nou eenmaal niet fatsoenlijk met OO werken aangezien de architectuur teveel mist. Zodoende zijn vele patterns zonder workarounds niet mogelijk". Je request chaining e.d. hebben dan weer weinig met OO te maken. Dus of je implementeert een pattern in OO zoals ie oorspronkelijk bedoelt is, of je implementeert een pattern op een presentatie-niveau alwaar het niets meer met OO te maken heeft. Al met al een beetje onduidelijk zonder de juiste nuancering . Maar goed, daardoor raakte ik denk ik in de war, excuses daarvoor.

[ Voor 44% gewijzigd door .oisyn op 18-01-2006 14:55 ]

[Verwijderd]

Tuurlijk doelde ik op een dergelijk framework, daar ging het immers over. Nu begrijp ik het, je was buiten de context van de discussie aan het praten. Ik vond je antwoorden al zo vreemd

[ Voor 45% gewijzigd door Verwijderd op 18-01-2006 14:46 ]

[jsiegmund]

Ik gebruik patterns, en weet ook de namen nog, moet je nagaan. Maar ik vind de ophef erover een beetje overdreven. Zoals je zelf al aangeeft gebruik je snel patterns, misschien zelfs zonder het te weten. Het enige wat er nu veranderd is, is dat deze stukjes code een naam en een verhaaltje gekregen hebben en vervolgens in een boek gedrukt worden.

Handig hoor, daar niet van, maar het eigen denkvermogen van een ontwerper moet niet om zeep geholpen worden op deze manier. Heb het al een paar keer meegemaakt dat iemand een URL intikt om het design pattern te gaan zoeken wat bij de situatie hoort. Binnen diezelfde tijd had ik het diagram al uitgetikt in m'n applicatie zitten. Ik vind ze dus niet zo heilig, zeker niet wanneer er nu ineens voor elk klein dingetje maar meteen een heel pattern ingeschoven wordt. Dat is niet de fout van de gang of four, maar wel een vervelende ontwikkeling.


Qua ontwikkelen: wat er bij mij nog steeds gebeurd is het opknippen van de applicatie in de verschillende delen (pagina's, secties). Daardoor raak je samenhang kwijt die je normaal in een lopende applicatie wel hebt. Je gaat rekening houden met de informatie die per scherm tevoorschijn moet komen, en overbodige informatie laat je weg om efficient te blijven werken. Meestal ga ik als volgt te werk:
- specifieke informatie opvragen adhv het request (database)
- informatie structureren in programmastructuur (klassendiagram)
- informatie gestructureerd doorgeven aan interface (scheiding data-interface)
- de interface drukt de boel af

Dit doe je elke keer opnieuw, voor iedere pagina. Dat is toch wel degelijk anders als een applicatie die draait en de input van de gebruiker afhandeld in de al beschikbare omgeving (waarin gewoon alle informatie beschikbaar is). Get where I'm going?

[Janoz]

iCe01 schreef op woensdag 18 januari 2006 @ 14:49:
Ik gebruik patterns, en weet ook de namen nog, moet je nagaan. Maar ik vind de ophef erover een beetje overdreven. Zoals je zelf al aangeeft gebruik je snel patterns, misschien zelfs zonder het te weten. Het enige wat er nu veranderd is, is dat deze stukjes code een naam en een verhaaltje gekregen hebben en vervolgens in een boek gedrukt worden.

Het voordeel van bestaande patterns is dat er al uitvoerig onderzoek gedaan is naar de voor- en nadelen, maar vooral ook de pitfalls. Dat is dus net ietsje meer dan het benoemen en in een boekje drukken. Juist daarin ligt het voordeel van het gebruik van patterns.

Handig hoor, daar niet van, maar het eigen denkvermogen van een ontwerper moet niet om zeep geholpen worden op deze manier. Heb het al een paar keer meegemaakt dat iemand een URL intikt om het design pattern te gaan zoeken wat bij de situatie hoort. Binnen diezelfde tijd had ik het diagram al uitgetikt in m'n applicatie zitten. Ik vind ze dus niet zo heilig, zeker niet wanneer er nu ineens voor elk klein dingetje maar meteen een heel pattern ingeschoven wordt. Dat is niet de fout van de gang of four, maar wel een vervelende ontwikkeling.

Dat sommigen er niet mee om weten te gaan betekend nog niet dat het hele idee niet goed is. Sowieso klopt er al iets niet wanneer iemand gaat googelen naar een pattern dat bij zijn probleem past. Zoals ik eerder aangaf zijn patterns de onderdelen van je toolbox die je toepast waar je ze nodig hebt. Ze zijn een hulpmiddel, niet een doel op zich. Php afkraken omdat er legio mensen zijn die drie scriptjes van phpfreakzz af knippen en door elkaar plakken is immers ook onzin.

Qua ontwikkelen: wat er bij mij nog steeds gebeurd is het opknippen van de applicatie in de verschillende delen (pagina's, secties). Daardoor raak je samenhang kwijt die je normaal in een lopende applicatie wel hebt. Je gaat rekening houden met de informatie die per scherm tevoorschijn moet komen, en overbodige informatie laat je weg om efficient te blijven werken. Meestal ga ik als volgt te werk:
- specifieke informatie opvragen adhv het request (database)
- informatie structureren in programmastructuur (klassendiagram)
- informatie gestructureerd doorgeven aan interface (scheiding data-interface)
- de interface drukt de boel af

Dit doe je elke keer opnieuw, voor iedere pagina. Dat is toch wel degelijk anders als een applicatie die draait en de input van de gebruiker afhandeld in de al beschikbare omgeving (waarin gewoon alle informatie beschikbaar is). Get where I'm going?

Wat ik daarin zie is dat je 'vertikaal' ontwikkeld. Je implementeerd een stuk functionaliteit van gebruiker naar database en weer terug. Elke request aan de voorkant heeft 1 actie op de database.

In principe is dit inherent aan php aangezien php enkel een page scope heeft. Je zult dus je complete doorloop in tijdens die actie geparsde bestanden moeten implementeren.

Ik kan niet een compleet verhaal op gaan hangen over mijn huidige applicatie (ik moet immers vandaag ook nog werken), maar in principe komt het er op neer dat er een applicatie draait met hierin verschillende service interfaces. De implementaties hiervan maken verbinding met een database (via data access objects) of met een document server via een soort van webservice. Kijk je echter van de buitenkant tegen de service interfaces aan dan zie je helemaal niet waar de data vandaan komt of weggestuurd wordt. Je hebt gewoon je interfaces en daar praat je tegenaan.

Het uiteindelijke webgedeelte bestaat uit een berg jsp pagina's, formbeans en acties. De jsp's bevatten de html aangevuld met enkele tags. Pagina's worden opgeroepen via de acties en de acties voeren methoden van de services uit met de gegevens uit de formbeans. Het resultaat wordt via een jsp pagina in een mooie website gegoten.

Misschien zie je weinig verschil met je eigen implementatie, maar dat is er wel. Een jsp pagina bij mij heeft geen enkele notie van het feit dat de gegevens die hij krijgt van een database af komen of uit een tekst bestandje. Zolang hij een lijst met objecten van een specifiek type terugkrijgt maakt hij er een mooi overzicht van.

[jsiegmund]

Je hebt gelijk over de design patterns, misschien een beetje kortzichtig. Ik ben ermee bezig geweest, maar dat was meer omdat het moest als dat ik het echt daadwerkelijk kon gebruiken. Dan is je oordeel natuurlijk sowieso al een beetje scheef.

Over de rest van je verhaal ga ik eens nadenken!

Begin er na wat lezen hier en daar toch van overtuigd te raken dat er inderdaad alternatieven zijn die waarschijnlijk wat handiger werken wanneer het echt groot moet. Ben echter ook overtuigd van het potentieel dat PHP hierin kan hebben, er moet een gat dichtgelopen worden en ik ben benieuwd of en hoe ze dat dan gaan doen.

[ Voor 37% gewijzigd door jsiegmund op 18-01-2006 17:44 ]

[Verwijderd]

SchizoDuckie schreef op woensdag 18 januari 2006 @ 02:22:
[...]
Eigenlijk is het ook de vraag of je wel GUI objecten wíl hebben.
De kracht van OO in PHP is imo júist dat je een object een lap html kan laten retourneren (wat jij een widget noemt)

Ik snap dat jij dit natuurlijk niet kunt weten vanuit mijn sumiere uitleg, maar dat kan dus juist WEL in Java. De web-componenten / widgets kun je OOK zelf bouwen, en dan heb je gewoon HTML generatie tools tot je beschikking. Wat jij nu zelf heb gedaan in je form generator, heb je in Java een complete API voor. Dingen als out.startTag(tagName); heb je dan gewoon tot je beschikking, maar je kunt ook gewoon out.write( "<br/>" ) doen als jij dat wilt.

De kracht zit hem in het feit dat deze HTML output helemaal geabstraheerd is. Op je pagina plaats je alleen een component. Stel jij schrijft een stukje HTML dat twee knoppen en een label voorstelt. In Java kun je deze HTML code dan in een component stoppen en helemaal standaard op een pagina zetten met iets als:

XML:

<mycomponents:confirm ok="doen!" cancel="no way!" message="Wil je doorgaan?" />

Dit component genereerd dan de HTML voor je. Tot dusver niet veel verschillend met wat jij feitelijk doet, behalve dat je hier een mooie tag neerzet ipv een function call. De kracht kom past kijken als je ziet hoe dit intergreerd met het object model. Zo kun je makkelijke meerdere van deze dingen op een pagina zetten, en via de Java API krijgt elk component een eigen ID mocht dat nodig zijn. Ook kun je er heel makkelijk listeners aan koppelen.

Stel dat ik wil dat er 1 functie wordt aangeroepen voor elk van de knoppen. In jouw aanpak is het gewoon een string die je genereerd en is er geen notie van een echt component. In Java/.NET hang je er gewoon een listener aan:

XML:

<mycomponents:confirm ok="doen!" cancel="no way!" message="Wil je doorgaan?" 
   okCommand="#{mybean.ok}" cancelCommand="#{mybean.cancel}"
/>

Je hoeft nu niet meer los van je HTML generatie ergens anders de get of post parameters op te vangen. Jij zou nu waarschijnlijk iets doen als:

Java:

<% if ( request.getParameter( "ok" ) != null ) { 
    mybean.ok();
}
else if ( request.getParameter( "cancel" ) != null ) {
   mybean.cancel();
}
%>

... andere code gemixed met html

<%=dialoggen.getHtmlForDialog(...)%>

Dit is al een hoop meer gedoe en je bent al lang niet meer object oriented bezig. Het opvangen van de parameters staat compleet los van de HTML generatie. Maar nu de volgende stap. Je wilt 2 van deze web componenen op je pagina. In Java is dit weer mooi geabstraheerd:

XML:

<mycomponents:confirm ok="doen!" cancel="no way!" message="Wil je doorgaan?" 
   okCommand="#{mybean.ok}" cancelCommand="#{mybean.cancel}"
/>

... andere componenten

<mycomponents:confirm ok="ja" cancel="nee" message="Opslaan?" 
   okCommand="#{barbean.ok}" cancelCommand="#{barbean.cancel}"
/>

Hoe ga je dit nu op jou manier doen?

Java:

<% if ( request.getParameter( "ok" ) != null ) { 
    mybean.ok();
}
else if ( request.getParameter( "cancel" ) != null ) {
   mybean.cancel();
}
if ( request.getParameter( "ok_1" ) != null ) { 
    barbean.ok();
}
else if ( request.getParameter( "cancel_1" ) != null ) {
   barbean.cancel();
}
%>

... andere code gemixed met html

<%=dialoggen.getHtmlForDialog(...)%>

... andere code gemixed met html

<%=dialoggen.getHtmlForDialog(...)%>

Dit wordt al een stuk ranziger. Je ziet nu niet meer welke parameter bij welk stukje HTML hoorde eigenlijk. Wederom, je bent niet OO bezig. Bedenk nu de situatie dat je een onbekend aantal van deze componenten op je scherm hebt, gemixed met andere componenten en dat mensen geregeld componenten verwijderen, herschikken etc. Op jouw manier wordt het al snel heel onoverzichtelijk wat bij wat hoort.

Nu kun je zelf wel weer classes gaan schrijven die bijvoorbeeld hun parameters afhandelen en die je bij de generatie van HTML een unieke ID mee geeft, etc etc. Maar voor je het weet ben je je eigen framework aan het nabouwen op deze manier, terwijl al deze dingen (en meer!) al gewoon standaard in Java en ASP.NET zitten.

Wat Java en .NET bieden is naast een set van standaard componenten een interface en een API om universeel en generiek nieuwe componenten te maken die dan weer heel makkelijk gecombineerd kunnen worden tot weer andere componenten. Voor mensen die alleen maar PHP of klassieke JSP en ASP ervaring hebben is het moeilijk in te zien waarom dit nu zo mooi is. Een ieder die echter ooit wel eens een desktop GUI app heeft gebouwd zal meteen de enorme voordelen erkennen.

[Verwijderd]

iCe01 schreef op woensdag 18 januari 2006 @ 11:06:
Wat zou het toch lekker zijn als je dat formulier gewoon weer in dezelfde vorm aan kunt spreken. Gewoon $editor->Naam->getValue(); aanroepen en de waarde hebben die je nodig hebt.

En dat is dus precies wat Java en .NET automatisch doen.

[jsiegmund]

Dat verhaaltje wat je daar tikt ziet eruit als de manier waarop ik het graag zou hebben

[Janoz]

Dat is nog maar het begin. Gooi je het jakarta validator framework er ook nog bij, dan kun je met enkele kleine aanpassingen in je form en het toevoegen van een configuratie bestandje alle input clientside en serverside valideren.

In je web.xml kun je vervolgens nog wat security restricties opgeven, of je maakt gebruik van Acegi waarbij je enkel een filter en extra configuratie toe hoeft te voegen en je hele (of gedeeltes van) je website is afgeschermt achter een inlog.

En dan heb ik het alleen nog over java. Bij .net zal het waarschijnlijk vergelijkbaar zijn.

[orf]

Wat zou het toch lekker zijn als je dat formulier gewoon weer in dezelfde vorm aan kunt spreken. Gewoon $editor->Naam->getValue(); aanroepen en de waarde hebben die je nodig hebt.

En met het juiste framework kan in PHP toch precies hetzelfde?
Bijvoorbeeld formhandler (www.formhandler.net) biedt precies de functionalieit die ik hier quote.

[Verwijderd]

Janoz schreef op woensdag 18 januari 2006 @ 21:07:
Dat is nog maar het begin.

Dit is inderdaad nog maar een heel klein begin. Zoals boven al gezegd wordt kun je ook validators en convertors aan je componenten hangen. Deze zitten ook alweer standaard in Java en kun je ook alweer gewoon zelf maken.

Wat deze doen is simpelweg automatisch controleren of de input die de user geeft klopt. Een heel makkelijk voorbeeld is bijvoorbeeld een range validator. Hang deze aan een input en java controleert automatisch of de waarde die de gebruiker opgeeft uberhaupt een getal is en binnen een bepaald bereikt ligt. Jouw object krijgt dan altijd gegarandeerd een goede waarde binnen.

Nog een ander voorbeeld van het feit dat Java voor web components echt OO is, is het feit dat je een concrete parent-child relationship tussen componenten hebt. Via eventhandling kan een parent web component events van kinderen opvangen, manipuleren en weer verder sturen. Hier zijn erg krachtige dingen mee mogelijk.

In het volgende voorbeeld laat ik even zien wat je hier mee kunt:

XML:

<h:dataTable var="row" value="#{mybean.model}" > 
    <h:column>
        <h:commandLink action="#{mybean.doName}" >
            <h:outputText value="#{row.name}" />
        </h:commandLink>                                
    </h:column>     
</h:dataTable>

Deze code zet een tabel op het scherm met hyperlinks. Als de user op een link klicked wordt automatisch door Java de functie doName aangeroepen. Binnen die functie staat de cursor van het model object (wat de data voor de tabel levert) precies op die rij waarop geclicked werd! Je hoeft dus niet moeizaam zelf voor elke rij een ID te genereren en die dan weer moeizaam uit te lezen etc.

Dit kan in Java werken omdat commandlink hier een kind is van dataTable. Bij een click vuurt commandlink een click event. Deze kan worden opgevangen door dataTable. Die weet welk van z'n eigen kinderen het was die vuurde (omdat de commando om te gaan vuren vanaf de root van de tree wordt gegegeven en naar beneden propageert), en kan de bijbehorende row index dan in een custom event wrappen.

Op het moment dat het event wordt afgehandeld, kan de parent dit weer afvangen, en vlak voordat de action listener wordt aangeroepen, zet de parent de cursor van het model op de goede rij. De handler code hoeft dus helemaal niks te doen, en weet meteen welke rij er geclicked had:

Java:

public String doName() {

    User user = (User)myModel.getRowData();
    System.out.println( "Er is op user: " + user.getName() +  " geclicked!" );

    return "success";
}

Je ziet hier dat de handler doName helemaal niks met HTML of row ID's te maken heb. Het haalt gewoon de huidige row op uit het model, en dit is meteen een object en meteen het juiste object.

[Verwijderd]

Btw, in bovenstaande voorbeeld noemde ik voornamelijk Java, maar voor ASP.NET geldt het zelfde voorhaal. Daar heb je het vergelijkbare DataGrid, die zeker in .Net 2.0 nog een heleboel meer kan. Wat ook nog handig is in .Net is dat je voor veel web componenten dingen kunt sharen met classes voor je desktop omgeving.

In Java heb je dit natuurlijk ook met alle basis classen (collections, utils, etc), maar voor de web gui layer worden toch weer wat andere interfaces gebruikt (zoals DataModel die je niet voor de Swing JTable kunt gebruiken). In .NET zijn de datasources wel te sharen voor desktop en web presentatie.

Maar goed, behoudens deze details hangen dus zowel Java als .Net het OO principe aan voor de web GUI, terwijl PHP alleen platte HTML kent.

[Michali]

@henk_DE_man:

Wat moet ik allemaal leren wil ik dat kunnen? Ik ben er wel erg in geinteresseerd namelijk. En dan doel ik vooral op Java.

[Verwijderd]

Michali schreef op donderdag 19 januari 2006 @ 20:16:
@henk_DE_man:

Wat moet ik allemaal leren wil ik dat kunnen? Ik ben er wel erg in geinteresseerd namelijk. En dan doel ik vooral op Java.

Tsja, eigenlijk een beetje de standaard manieren denk ik. Boek in boeken winkel kopen of bestellen over met name het GUI gedeelte van Java (JSF). Mastering JavaServer Faces van Wiley geeft wel een goed overzicht, hoewel het wat vaak herhaalt wat de life-cycle nu precies is. (ook te vinden via de electronische ezel, als je alvast wilt doorneuzen of het wat is voor je).

Dan moet je natuurlijk Java zelf downloaden.
Losse JDK/VM (heb je mischien al): http://java.sun.com/j2se/1.5.0/download.jsp

Een redelijk eenvoudige introductie is:
http://www.coreservlets.com/JSF-Tutorial/#Section1

Op die link vind je ook een minimale start configuratie.

Eventueel kun je ook nog kijken op:
http://myfaces.apache.org/gettingstarted.html

Extra is een IDE te gebruiken:
Java basis: http://www.eclipse.org/downloads/
Java web: http://www.myeclipseide.c...Downloads&file=dl_options

een andere mogelijkheid is de Sun implementatie. Die gebruik ik zelf niet, dus weet even niet hoe makkelijk het is om daar mee te beginnen.

De oude versie kun je makkelijk downloaden van:

http://java.sun.com/j2ee/1.4/download.html#sdk
en een ide ervoor: http://www.netbeans.org/

Vaak is vanaf een basis hello world applicatie beginnen het makkelijkste. Als je die een beetje aanpast en mee speelt leer je snel de beginselen. Het moeilijkste gedeelte is mischien nog wel de installatie van de server. Ook te vinden via de bovenstaande link, maar een tutorial daarvoor staat op: http://www.coreservlets.c...utorial/#Configure-Tomcat

[ Voor 5% gewijzigd door Verwijderd op 19-01-2006 21:23 ]

[.oisyn]

Verwijderd schreef op donderdag 19 januari 2006 @ 21:13:
(ook te vinden via de electronische ezel)

Subtiel

[aex351]

Waarom zou je PHP5 niet willen gebruiken in grote web applicaties ? . Je kan er praktisch alles mee (maken) voorzover ik zie dat nodig is. Plus het is open source, wat echte desktop programmeurs wel fijn vinden. Vind je het niet goed genoeg, dan verbouw je het gewoon

[kenneth]

aex351 schreef op donderdag 19 januari 2006 @ 23:01:
Waarom zou je PHP5 niet willen gebruiken in grote web applicaties ?

Uh, zie dit topic .

Plus het is open source, wat echte desktop programmeurs wel fijn vinden. Vind je het niet goed genoeg, dan verbouw je het gewoon

Dan is het geen PHP meer

[Verwijderd]

aex351 schreef op donderdag 19 januari 2006 @ 23:01:
Plus het is open source, wat echte desktop programmeurs wel fijn vinden. Vind je het niet goed genoeg, dan verbouw je het gewoon

Java is ook grotendeels open source. Het mooie (maar soms weer het verwarrende) is dat "Java" eigenlijk niet een produkt is maar een grote serie van specs. Vergelijk het een beetje met C/C++. Een standaard comittee stelt een spec op en vendors (ook open source partijen dus) mogen daar een implementatie van maken.

Voor het web heb je dus de Java EE spec, die weer uit sub-specs bestaat. JSP, Servlet, Gui componenten, persistance, etc etc zijn allemaal aparte specs die allemaal apart of tegelijk geimplementeerd mogen worden door verschillende of een enkele partij.

Draai je de combinatie Tomcat + MyFaces + Hibernate dan heb je:

Tomcat: Java compiler (JDT van Eclipse), JSP compiler (Jasper), Servlet container (Catalina)
MyFaces: JSF implementatie + standaard componenten + extra componenten
Hibernate: EJB3-Persistence API implementatie

Deze zijn allemaal open source. In je debugger kun je dus gewoon door de source heen steppen, en als je wilt kun je de source veranderen. Tomcat en MyFaces zijn allebei van Apache en komen dus met de Apache license. JDT komt onder de common public license.

Let op dat bv MyFaces geen apart framework is, maar -een- implementatie van het componenten gedeelte van Java. Je kunt deze ook door een closed source variant vervangen (mocht die er komen) en al je code blijft gewoon hetzelfde. Net zoals GCC -een- implementatie is van een C++ compiler, en je je source code net zo goed door een closed source C++ compiler kunt laten compilen zonder veranderingen. (natuurlijk zelf opletten dat je geen vendor specifics gebruikt natuurlijk)

Zelfs voor de JVM heb je alternatieven, zoals de IBM JVM en die van Bea (JRockit). Je zit dus eigenlijk nooit vast aan een vendor, en voor bijna elk gedeelte van Java bestaat wel een open source implementatie.

Persoonlijk denk ik dat veranderingen willen aanbrengen in je platform zelf voor 99% van de gebruikers dikke onzin is. Je kunt altijd dingen bereiken door platform classen te extenden en zo default functionaliteit te overriden. Mischien dat je nog niet zo thuis bent in de OO wereld in dit principe (nog) niet kent?

[Verwijderd]

aex351 schreef op donderdag 19 januari 2006 @ 23:01:
[..]. Plus het is open source, wat echte desktop programmeurs wel fijn vinden. Vind je het niet goed genoeg, dan verbouw je het gewoon

Als je ooit zo'n programmeur tegenkomt mag je m naar mn broertje (psycholoog) doorsturen.

[twiekert]

Verwijderd schreef op woensdag 18 januari 2006 @ 20:28:
[...]


Ik snap dat jij dit natuurlijk niet kunt weten vanuit mijn sumiere uitleg, maar dat kan dus juist WEL in Java. De web-componenten / widgets kun je OOK zelf bouwen, en dan heb je gewoon HTML generatie tools tot je beschikking. Wat jij nu zelf heb gedaan in je form generator, heb je in Java een complete API voor. Dingen als out.startTag(tagName); heb je dan gewoon tot je beschikking, maar je kunt ook gewoon out.write( "<br/>" ) doen als jij dat wilt.

De kracht zit hem in het feit dat deze HTML output helemaal geabstraheerd is. Op je pagina plaats je alleen een component. Stel jij schrijft een stukje HTML dat twee knoppen en een label voorstelt. In Java kun je deze HTML code dan in een component stoppen en helemaal standaard op een pagina zetten met iets als:

XML:

<mycomponents:confirm ok="doen!" cancel="no way!" message="Wil je doorgaan?" />

....

.

Dit lijkt heel erg op het PRADO framework ( http://www.xisc.com/ ) wat ook met componenten werkt en event gebaseerd is. Het is geinspireerd door Jakarta Tapestry (mij onbekend).
PRADO v3 is in iedergeval een mogelijke kandidaat voor m'n huidige project (als tie in maart maar stable is ).

Dit soort frameworks waar de html tags abstract zijn gemaakt in classes zijn er dus wel, helaas is het alleen geen standaard. Mischien dat daar met het Zend PHP framework verandering in gaat komen.

[Verwijderd]

twiekert schreef op vrijdag 20 januari 2006 @ 15:25:
[...]
Dit lijkt heel erg op het PRADO framework ( http://www.xisc.com/ ) wat ook met componenten werkt en event gebaseerd is.

Deze aanpak (componenten/events/MFC) is ook duidelijk niet bijzonder of revolutionair. Het is gewoon de volgende stap in volwassenheid van een platform. Zowel Java als ASP hadden dit eerst ook niet, en dat was behoorlijk behelpen. ASP kreeg het pas met ASP.NET, maar dat werd wel meteen de de-facto standaard. Met ASP.NET 2.0 is het behoorlijk volwassen geworden en zijn er enorm veel componenten beschikbaar.

In Java heb je eerst een lange tijd een wildgroei aan home-grown oplossingen gehad en wat later grote open source projecten die dit concept oppikte. Je moet dan denken aan projecten als Tapestry, WebWorks, Spring MVC en Struts. Op een gegeven moment heeft Sun de project leider van het meest gebruikte project (Struts) ingehuurd en samen met afgevaardigden van verschillende bedrijven en organisaties een standaard voor dit concept opgesteld. Zo'n standaard neerzetten kost enorm veel meer tijd dan een implementatie maken en die tot standaard verklaren. Java ligt dus wat dat betreft wat achter op ASP.NET dat al in z'n 2de generatie zit. Wel lijken de 2 echt enorm veel op elkaar.

PHP zit nu pas in de fase dat er een beetje een wildgroei aan home-grown dingen aan het ontstaan is en dat wat open source projectjes het concept oppakken. Waarschijnlijk zal er over een jaar of 2 een of ander componenten framework echt een critical mass krijgen en dan nog een paar jaar later zal er waarschijnlijk wel zoiets in PHP standaard komen.

De vraag is echter waarom je daar op zou willen wachten als het vandaag de dag al met zowel Java als ASP.NET kan. Mischien dat ASP.NET technisch 'iets' sterker is, zowel kwa hoofd programmeertaal (C#) als platform, maar Java heeft weer het voordeel van open source en gratis servers + IDE's.

PRADO v3 is in iedergeval een mogelijke kandidaat voor m'n huidige project (als tie in maart maar stable is ).

Kijk dat bedoel ik nou

Dit soort frameworks waar de html tags abstract zijn gemaakt in classes zijn er dus wel, helaas is het alleen geen standaard. Mischien dat daar met het Zend PHP framework verandering in gaat komen.

In ASP.NET is het nu al een standaard. In Java is de standaard gezet, hoewel de andere (vroegere) projecten ook nog wel gebruikt worden.