[JAVA] vs [PHP] wat is de meerwaarde?

[djc]

OlafvdSpek schreef op zaterdag 11 december 2004 @ 14:58:
Alleen als de code in Java langer is dan in PHP. Is dat ook (altijd/vaak) zo?

Uiteraard niet altijd, maar wel vaak ja. Zie voor een simpel voorbeeld de canonical "Hello, world!" voorbeelden.

[Alarmnummer]

Manuzhai schreef op zaterdag 11 december 2004 @ 15:19:
[...]
Uiteraard niet altijd, maar wel vaak ja. Zie voor een simpel voorbeeld de canonical "Hello, world!" voorbeelden.

Ik vind je opmerking wel een beetje typerend. Uiteraard zullen er talen zijn waarin het programmeren van de weblaag wat minder omslachtig is dan java of asp.net. Maar aan de andere kant... wat voor frameworks heb je allemaal bij php? Heb je een goed concurrency framework? Heb je een goed collection framework? En zo kan ik nog wel even doorgaan.

Voor echt serieuze applicaties waarbij er meer moet gebeuren dan alleen een webinterface op een database aansluiten, hoe praktisch is PHP dan?

En verder wil ik ook graag de opmerking dat php code per regel minder fouten bevat dan gecompileerde talen ook even met uitzonderlijk veel plezier onderuit halen. Ik haal tijdens het compilatie proces veel fouten eruit.. (vaak achterlijke.. tiep fouten.. en type fouten.. )

Als ik en een php`er allerbei een lap code zouden moeten implementeren dan is de kans groot dat we allebei evenveel fouten in de code hebben zitten (we zijn mensen). Maar op het moment mijn code wordt gecompileerd en ik de fouten er uit moet halen... bevat mijn code per regel minder fouten. En verder kan je wel hoog en laag gaan springen dat php gewoon minder code nodig heeft.. maar als je een goed framework te pakken hebt.. gaat je dat ook veel regels schelen.

[ Voor 37% gewijzigd door Alarmnummer op 11-12-2004 15:30 ]

[drm]

Alarmnummer:
Dat ligt eraan met welke/taal platform je werkt. Ik weet het niet zeker van c++ maar ik geloof dat je daar gerust een 'mis'cast kunt doen. Met java en .net is dit niet mogelijk.

In C++ word je ook verplicht om op te geven wat voor soort cast je wilt doen. (staat hier wel aardig uitgelegd). Dat betekent dus dat de taal ook van je vraagt om na te denken over hetgeen waar je mee bezig bent.

Dat is volgens mij ook de hele discussie: een taal als Java is vrij strict in vergelijking met veel andere talen, en verplicht je dus min of meer om heel erg netjes code te schrijven. Dat betekent (vaak) dat je dus gedwongen wordt goed na te denken over de programmatuur die je schrijft.

Talen als PHP en Perl zijn een beetje het andere uiterste, ze laten je heel erg vrij. De gevolgtrekking is niet per definitie dat er dus ondoordachte code uit de taal voortkomt. Als je goed nadenkt over een systeem is een OO concept (wat in java erg de nadruk heeft) heel erg interessant, maar kun je in PHP of zelfs C (wat ook een weinig stricte taal van zichzelf is) prima implementeren.

De discussie is dan niet zo zeer wat voor soort taal / platform je gebruikt, maar in hoeverre je goed nadenkt voordat je begint te bouwen. En dat is wat een HBO-niveau onderscheidt van de hobbyist.

[Verwijderd]

En weer ff een on-topic post:
--------------------------------------------

-FoX- schreef op vrijdag 10 december 2004 @ 12:20:

Prestige.. maar op welke manier zou je dit dan naar voren brengen? Aan de hand van voorbeelden of hoe zou jij dit doen?

Tsja, da's een goeie. Ik weet niet of je dit echt actief naar voren kunt brengen, maar als je inderdaad bedrijven als IBM en Sun kunt aanhalen dan zal je opdrachtgever ook een beter gevoel hebben bij Java. En ik heb ook vaker gesprekken gehad met opdrachtgevers zonder IT achtergrond die bij Java meteen aan hun GSM dachten. Op de een of andere manier werkt een dergelijke bekendheid van een platform op zo'n 'high-tech' gebied als GSM's gewoon vertrouwenswekkend (beide gaan natuurlijk ook op voor .NET).

vergeet je in dit lijstje het woord kosten beheersing niet?

Geloof het of niet, maar als ik om me heen kijk zie ik dat er nog steeds belachelijk hoge bedragen gevraagd en betaald worden voor IT oplossingen. Kostenbeheersing is theoretisch gezien misschien wel belangrijk maar in de praktijk komt er echt bitter weinig van terecht. Er wordt nauwelijks gelet op TCO of ROI, maar er wordt vaak gewoon wat gekocht waardoor alles automagisch beter zou moeten worden. Ik heb nog maar weinig bedrijven gezien die dit goed onder controle hebben.

Met een programmeer taal maak je geen indruk met je ideeen wel

No offence, maar de taal maakt dus wel degelijk wat uit. Als een bedrijf allerlei Microsoft producten gebruikt zullen ze zeker wel een voorkeur hebben voor .NET, al is het maar omdat dit ook van Microsoft is. Als ze een stapel Sunfire's hebben staan zullen ze zeker ook blijer zijn als je software in Java geschreven is. Tuurlijk, voor het programma maakt het niets uit, maar in de praktijk loop je hier toch echt vaker tegenaan.

[djc]

Alarmnummer schreef op zaterdag 11 december 2004 @ 15:23:
Ik vind je opmerking wel een beetje typerend. Uiteraard zullen er talen zijn waarin het programmeren van de weblaag wat minder omslachtig is dan java of asp.net. Maar aan de andere kant... wat voor frameworks heb je allemaal bij php? Heb je een goed concurrency framework? Heb je een goed collection framework? En zo kan ik nog wel even doorgaan.

Voor echt serieuze applicaties waarbij er meer moet gebeuren dan alleen een webinterface op een database aansluiten, hoe praktisch is PHP dan?

En verder wil ik ook graag de opmerking dat php code per regel minder fouten bevat dan gecompileerde talen ook even met uitzonderlijk veel plezier onderuit halen. Ik haal tijdens het compilatie proces veel fouten eruit.. (vaak achterlijke.. tiep fouten.. en type fouten.. )

Als ik en een php`er allerbei een lap code zouden moeten implementeren dan is de kans groot dat we allebei evenveel fouten in de code hebben zitten (we zijn mensen). Maar op het moment mijn code wordt gecompileerd en ik de fouten er uit moet halen... bevat mijn code per regel minder fouten. En verder kan je wel hoog en laag gaan springen dat php gewoon minder code nodig heeft.. maar als je een goed framework te pakken hebt.. gaat je dat ook veel regels schelen.

Jij gaat hierin alleen maar op PHP in, terwijl ik het probeer te hebben over dynamische talen in het algemeen. Ik heb het nooit gehad over het programmeren van een weblaag, dat maak jij ervan. Een wxPython-applicatie kan volgens mij ook erg serieus zijn.

En wat jouw frameworks betreft ga je wat mij betreft een beetje te ver de grens over tussen de taal en het platform (alle crap die je erbij krijgt; deze grens is vaak nogal schimmig). In PHP heb je ook frameworks, alleen worden die niet bij de taal geleverd. In Python heb je bijvoorbeeld Zope, als dat geen framework is? In Ruby heb je Ruby on Rails, wat een uitzonderlijk sterk platform schijnt te zijn voor met name webapplicaties. Volgens mij is het aantal meegeleverde frameworks dus niet echt een geschikte eigenschap om een taal op te beoordelen.

[PrisonerOfPain]

Manuzhai schreef op zaterdag 11 december 2004 @ 20:26:
En wat jouw frameworks betreft ga je wat mij betreft een beetje te ver de grens over tussen de taal en het platform (alle crap die je erbij krijgt; deze grens is vaak nogal schimmig). In PHP heb je ook frameworks, alleen worden die niet bij de taal geleverd.

PEAR word al een behoorlijke tijd meegeleverd, volgens mij

[Verwijderd]

offtopic : http://tca.gathering.tweakers.net:8080/ tweakers.net lijkt ook met java aan de slag zijn te gaan, ik vraag me af hoe dat bevalt vs de php applicatie's? want dat zullen straks veel bezoeker / gebruikers worden.

EDIT: Het is helaas down, crew is er mee bezig!

[ Voor 11% gewijzigd door Verwijderd op 12-12-2004 00:14 ]

[djc]

Verwijderd schreef op zaterdag 11 december 2004 @ 22:42:
offtopic : http://tca.gathering.tweakers.net:8080/ tweakers.net lijkt ook met java aan de slag zijn te gaan, ik vraag me af hoe dat bevalt vs de php applicatie's? want dat zullen straks veel bezoeker / gebruikers worden.

Wat staat daar? Bij mij doet het niets.

[Alarmnummer]

Manuzhai schreef op zaterdag 11 december 2004 @ 20:26:
Volgens mij is het aantal meegeleverde frameworks dus niet echt een geschikte eigenschap om een taal op te beoordelen.

Zeker wel..

Daarom durf ik bv delphi wel af te branden...

Een taal is niets zonder goeie frameworks.. en een een taal is niets zonder een goeie ide.

Ik durf trouwens nog wel een stap verder te gaan door te zeggen dat goeie frameworks en goeie ide`s nog een orde van grote belangrijker zijn dan de taal zelf.

[ Voor 18% gewijzigd door Alarmnummer op 12-12-2004 00:32 ]

[Verwijderd]

Alarmnummer schreef op zondag 12 december 2004 @ 00:27:
[...]
Zeker wel..

Daarom durf ik bv delphi wel af te branden...

Een taal is niets zonder goeie frameworks.. en een een taal is niets zonder een goeie ide.

Manuzhai heeft het over bijgeleverde frameworks, niet of ze überhaupt bestaan. Natuurlijk, aan een taal op zich heb je niks, het platform is vitaal. Maar jij schrijft Java toch ook niet af omdat er in de J2SE SDK geen unit testing frameworks, Ant en weet-ik-niet-wat zit standaard?

[Verwijderd]

Alarmnummer schreef op zondag 12 december 2004 @ 00:27:
[...]

Zeker wel..

Daarom durf ik bv delphi wel af te branden...

Dit is natuurlijk onzin. Delphi bestaat al jaren en is gewoon heel succesvol. Er bestaan genoeg goede frameworks voor Delphi. Dat jij ze niet kent is geheel jou eigen probleem..... Ook is Delphi tegenwoordig een .NET taal. Ga jij beweren dat er geen goede frameworks bestaan voor .NET?

Maar goed, dit topic is al verzandt in een discussie over hoe goed dynamische talen in theorie zijn. Het heeft geen zin om ook nog een non discussie te beginnen over het nut van het programmeren in Delphi vs Java vs C++.

[Killemov]

Okee ... ik heb al behoorlijk wat gemiep in dit topic gelezen, niet zo zinnig. Dit hele topic gaat zowiezo over appels met peren vergelijken, zoals de TS al aangaf. Java is een generieke programmeertaal en PHP een taal specifiek ontworpen voor het produceren van webpagina's. "[JSP] vs [PHP] vs [ASP] ..." of "[Java] vs [C++] vs [Delphi] ..." als topic zou dus al een stuk zinniger zijn geweest. Binnen de bovengenoemde rijtjes is het wat mij betreft lood om oud ijzer. De algemene opvattingen "PHP => kleine site, snel gebouwd" en "J2EE => grote webapplicaties, lange ontwikkeltijd" gaan ook steeds minder op. Performance is ook nauwelijks meer een issue, evenals security. Ik zie dus eigenlijk meer de overeenkomsten dan de verschillen.

[flowerp]

n

Killemov schreef op zondag 12 december 2004 @ 15:00:
Binnen de bovengenoemde rijtjes is het wat mij betreft lood om oud ijzer.

Behalve natuurlijk de reputatie:

Manager van bedrijf X:
Wij hebben onze web applicatie in PHP laten maken.

Manager van bedrijf Y:
Zo, hebben jullie meegedaan aan een project om jongeren van straat te halen of hebben jullie stiekum de resultaten gebruikt van de cursus in het plaatselijke buurt huis "Hoe bouw ik mijn eigen homepage" ?

Zet dit nou af tegen de volgende situatie:


Manager van bedrijf X:
Wij hebben onze web applicatie in J2EE laten maken.

Manager van bedrijf Y:
Zo, dus jullie hebben zeker goed geschoold personeel ingezet he? Kwamen de meeste van het HBO of van de Universiteit?

[Verwijderd]

flowerp schreef op zondag 12 december 2004 @ 15:56:
Behalve natuurlijk de reputatie:

Manager van bedrijf X:
Wij hebben onze web applicatie in PHP laten maken.

Manager van bedrijf Y:
Zo, hebben jullie meegedaan aan een project om jongeren van straat te halen of hebben jullie stiekum de resultaten gebruikt van de cursus in het plaatselijke buurt huis "Hoe bouw ik mijn eigen homepage" ?

Zet dit nou af tegen de volgende situatie:


Manager van bedrijf X:
Wij hebben onze web applicatie in J2EE laten maken.

Manager van bedrijf Y:
Zo, dus jullie hebben zeker goed geschoold personeel ingezet he? Kwamen de meeste van het HBO of van de Universiteit?

Ach, uiteindelijk is het enige wat er toe doet hoe goed het werkt. Als het een kut-website in Java is sta je als manager zwaar voor lul. In PHP idem dito.

Ik heb teveel buzzword-heavy, major-vendor-supported applicaties roemloos ten onder zien gaan om me daar als manager door te laten belazeren. Het enige dat mij interesseert is de reputatie van de ontwikkelaars. Die reputatie berust op succesvolle afgeronde projecten en nergens anders op.

[Alarmnummer]

Verwijderd schreef op zondag 12 december 2004 @ 14:00:
[...]

Dit is natuurlijk onzin. Delphi bestaat al jaren en is gewoon heel succesvol. Er bestaan genoeg goede frameworks voor Delphi. Dat jij ze niet kent is geheel jou eigen probleem..... Ook is Delphi tegenwoordig een .NET taal. Ga jij beweren dat er geen goede frameworks bestaan voor .NET?

Delphi 8 is idd een .net taal (en kan daarom ook gebruiken maken van alle tools van het .net platform.. ). maar delphi 7 en voorgangers niet. Standaard zit er bv geen collection framework bij. Wat al aangeeft wat voor soort apps er met delphi gemaakt worden.

Ik heb nog het een en ander met delphi (helaas) moeten doen (t/m 7) en vind Java/.NET qua platform/tools toch lichtelijk geavanceerder.

xenna
Ik heb teveel buzzword-heavy, major-vendor-supported applicaties roemloos ten onder zien gaan om me daar als manager door te laten belazeren. Het enige dat mij interesseert is de reputatie van de ontwikkelaars. Die reputatie berust op succesvolle afgeronde projecten en nergens anders op.

Nou als er geen echte stukjes XML en Webservices in zitten dan is het uiteraard helemaal niets he

[ Voor 38% gewijzigd door Alarmnummer op 12-12-2004 20:16 ]

[Verwijderd]

Delphi 8 is idd een .net taal.. maar delphi 7 en voorgangers niet. Standaard zit er bv geen collection framework bij. Wat al aangeeft wat voor soort apps er met delphi gemaakt worden.

Ik heb nog het een en ander met delphi (helaas) moeten doen (t/m 7) en vind Java/.NET qua platform/tools toch lichtelijk geavanceerder.

Dus Delphi als onderdeel van het net platform vindt je wel geavanceerd? Maar ook het vergelijken van (zeg) Delphi 5 met .NET is een beetje onzinnig. .NET bestond simpelweg niet toen Delphi5 op de markt was. Dan moet je wel vergelijken met wat er indertijd op de markt was. En zelfs vergeleken met .NET is Delphi 5 nog zeer geschikt voor RAD werk.

Delphi 7 had inderdaad weinig vernieuwends maar met Delphi 8 heeft Borland aansluiting gevonden bij 1 van de twee belangrijkste ontwikkelplatformen van dit moment (.NET) zonder dat de kracht van Delphi er erg onder geleden heeft

En dat er standaard geen collection framework bijzit? Weet je hoeveel frameworks er standaard niet bij .NET of Java worden meegeleverd? Niet standaard in de doos is iets totaal anders dan niet beschikbaar.

Kies het platform wat het handigste is voor een bepaalde toepassing. Of dat nu Java, C++, Delphi, PHP of zelfs VB is. Het is onzinnig om platformen uit te sluiten voor een project omdat ze voor totaal andere toepassingen niet echt geschikt zijn. Met PHP ga je geen windows applicatie maken, met Delphi 2 t/m 7 geen webapplicatie. Maar voor een database client onder windows zou ik toch echt Delphi serieus overwegen.

[Alarmnummer]

Verwijderd schreef op zondag 12 december 2004 @ 20:26:
[...]
En dat er standaard geen collection framework bijzit? Weet je hoeveel frameworks er standaard niet bij .NET of Java worden meegeleverd? Niet standaard in de doos is iets totaal anders dan niet beschikbaar.

Yep.. maar als er ook geen degelijk framework beschikbaar is dan tja... en verder als zoiets iets elementairs mist dan zit ik wel ff zo van.. uhh.. wat is dit voor geklungel? Vinden alle programmeurs die met delphi werken dit soms normaal? Weten ze niet beter?

Maar voor een database client onder windows zou ik toch echt Delphi serieus overwegen.

In ieder geval geen java

[Creepy]

Om een taal nou compleet af te schrijven op het feit dat er geen echt collection framework bij zit, en het dan maar geklungel te noemen vindt ik nou weer iets te (dat is in mijn ogen bijna hetzelfde als roepen dat alle PHP proggers allemaal kneusjes zijn, waar in deze thread ook al lichtelijk naar gehint is.) Wat mij betreft stoppen we in deze thread met het roepen van dit soort zaken voordat het echt uit de hand gaat lopen

[nog meer offtopic]
Daarnaast valt met de TObjectList en de TCollection (!) in Delphi ook een hoop te doen . Nee, het is (helaas) niet precies hetzelfde zoals een Vector<> in C++.
[/nog meer offtopic]

[ Voor 4% gewijzigd door Creepy op 12-12-2004 21:05 ]

[djc]

Alarmnummer schreef op zondag 12 december 2004 @ 19:19:
Wat al aangeeft wat voor soort apps er met delphi gemaakt worden.

Ik moet hier toch even opmerken dat een paar van mijn favoriete dev-apps voor Windows in Delphi geschreven zijn. Zoals daar zijn Homesite en TopStyle. Verder gebruik ik (van dezelfde auteur) FeedDemon, wat ook een nogal aarsch-schoppende applicatie is (en dat met footprint van nog geen 2,5 MB, kom daar met .NET maar eens om).

[flowerp]

Verwijderd schreef op zondag 12 december 2004 @ 20:26:
[...]
t

En dat er standaard geen collection framework bijzit? Weet je hoeveel frameworks er standaard niet bij .NET of Java worden meegeleverd? Niet standaard in de doos is iets totaal anders dan niet beschikbaar.

Mwhoah... in het algemeen heb je wel gelijk, maar in geval van elementaire zaken (als collections) is het toch wel belangrijk dat zoiets in de standaard library zit. Je hebt dat vroeger gehad met C++ die pas erg laat de complete library kreeg (in '98). Heel veel alternatieve libs / frameworks (zoals MFC) implementeerde hun eigen versies van collections en strings. Het gevolg is dat dergelijke voor die alternatieve frameworks geschreven code niet makkelijk samenwerkt met standaard code.

[kasper_vk]

-FoX- schreef op donderdag 09 december 2004 @ 13:20:
Java en php zijn eigenlijk niet te vergelijken met elkaar. Java heeft zoveel meer te bieden, maar php is ruimschoots voldoende voor de gemiddelde website. Maar wat nu indien er meer nodig is dan een gemiddelde website?

Beter nog... wat indien een vragende partij een webapplicatie wil laten ontwikkelen, laten we zeggen op nationaal niveau waarbij het uiterst belangrijk is dat er geen gegevens verloren gaan, privacy van de gegevens gerespecteerd dient te worden en er verschillende (tss 500 & 1000-tal) gelijktijdige gebruikers op het systeem zullen werken? Het systeem zal vooral dienen om gegevens bij te houden en statistieken te trekken.. maar ook enkele administratieve zaken.
Is een php applicatie hier dan wel op zijn plaats

Mijns inziens is een java webapplicatie hier wel op zijn plaats. Ik zeg niet dat het niet mogelijk is met een php applicatie, maar biedt een java webapplicatie niet zoveel meer (transacties, multithreading, db-onafhankelijkheid, platform onafhankelijkheid, server (tomcat, jboss, websphere, weblogic, orion, ...) onafhankelijk, uitbreidbaarheid, separation of concerns, ....) ?

Waarom zou jij een java/php webapplicatie verkiezen boven het andere?? En met welke argumenten zou je de vragende partij kunnen overhalen?
_{Er is hier geen sprake van een bestaande infrastructuur, dus op dat gebied is eigenlijk alles nog wel mogelijk}

Ik ben benieuwd of de TS inmiddels iets wijzer is geworden. Hoewel veel replies een hoog wellus-nietus gehalte hadden (maar niet per se oninteressant waren), zijn er denk ik ook wat voor de TS interessante opmerkingen tussendoor gekomen.

offtopic:
En daarmee bedoel ik dat ik aan de TS duidelijk merkte dat men Java en PHP op een voor hem oninteressante manier aan het 'vergelijken' was.

Wat zou je nu adviseren / besluiten? J2EE, PHP of misschien wel .NET ? En waarom?

[Grijze Vos]

kasper_vk schreef op maandag 13 december 2004 @ 11:37:
Wat zou je nu adviseren / besluiten? J2EE, PHP of misschien wel .NET ? En waarom?

Afhankelijk van het beschikbaar budget en de huidige know-how van je mensen. Als er ernstig veel business logic achter schuilt zou ik eerder J2EE gebruiken, is de business logic redelijk eenvoudig, dan kun je voor PHP gaan: snellere time-to-market, o.a. (vaak, niet altijd. Alarmnummer)

[Alarmnummer]

Grijze Vos schreef op maandag 13 december 2004 @ 11:53:
[...]

Afhankelijk van het beschikbaar budget en de huidige know-how van je mensen. Als er ernstig veel business logic achter schuilt zou ik eerder J2EE gebruiken, is de business logic redelijk eenvoudig, dan kun je voor PHP gaan: snellere time-to-market, o.a. (vaak, niet altijd. Alarmnummer)

De opdrachtgever heeft zelf geen know how. Hij heeft de keuze uit een aantal it bedrijven.. de een heeft J2EE kennis en de ander PHP. Het gaat er dus om hoe de opdrachtgever (die zelf geen it kennis heeft) geadviseerd kan worden om een goeie keuze te maken uit de bestaande platformen/talen.

Daarbij moet ook duidelijk gemaakt kunnen worden waarom sommige platformen niet/minder geschikt zijn. De J2EE club moet de zwakke punten van PHP aanwijzen.. maar de PHP club moet ook de zwakke punten van J2EE aanwijzen.

En het is dan wel de bedoeling dat alles in jip en janneke taal uitgelegd kan worden...

[ Voor 21% gewijzigd door Alarmnummer op 13-12-2004 12:05 ]

[-FoX-]

kasper_vk schreef op maandag 13 december 2004 @ 11:37:
Ik ben benieuwd of de TS inmiddels iets wijzer is geworden. Hoewel veel replies een hoog wellus-nietus gehalte hadden (maar niet per se oninteressant waren), zijn er denk ik ook wat voor de TS interessante opmerkingen tussendoor gekomen.

offtopic:
En daarmee bedoel ik dat ik aan de TS duidelijk merkte dat men Java en PHP op een voor hem oninteressante manier aan het 'vergelijken' was.

Wat zou je nu adviseren / besluiten? J2EE, PHP of misschien wel .NET ? En waarom?

Ik ga voor de volle 100% voor J2EE, daar is bij mij geen twijfel mogelijk!! Maar het ging mij niet zozeer om voor mezelf een keuze te maken, maar eerder op welke manier ik een niet-technisch persoon kan laten inzien waarom j2ee nu juist beter is voor zijn project dan php.

Als ik php met jsp zou vergelijken, dan zou dit nog haalbaar zijn en heeft ieder zijn eigen argumenten. Maar dit heb ik dus (bewust) niet gedaan, want J2EE is veel meer dan dat. PHP is enkel een presentatietaal, waar er wel in beperkte mate gebruik kan gemaakt worden van business logic classes e.d. maar kan onmogelijk een échte business-logic tier bevatten.

Ik heb dit hele topic op de voet gevolgd en heb dikwijls bewust gekozen om niet te reageren.. sommigen sloegen de bal echtwel mis!

Dat betekent dus dat jij in hetzelfde stukje formaliteit in je "pro taal" Java veel meer fouten maakt dan als je dat stukje in PHP schrijft...

Wat een onzin! Op het laagste niveau heeft hij misschien wel gelijk, maar het gaat veel verder dan dat. Van mijn "pro taal"-code ben ik namelijk veel zekerder (transactions, security, unit-tests, regression-tests, logging, ... er is compilatie!!). Het duurt misschien wel wat langer om "dezelfde" functionaliteit te schrijven, maar ik wil/ben absoluut zeker dat de functionaliteit er IS en dat deze functionaliteit er altijd zal zijn.

Een serieuze webapplicatie is gewoon not done in php. Of kent er iemand ondertussen al een bank-applicatie volledig op php gebaseerd? _{en waarom zou dit zo zijn??}

Voor mij zijn testen héél belangrijk, heel je code valt/staat hiermee.. + je bent altijd zeker van je code. Bij php zie ik bvb het unit-testen nog niet echt terugkomen. Al bestaat het wel, toch wordt het zelfden door php'ers gedaan.
Voor mij is software-architectuur ook een belangrijk iets. Separation of Concerns.. iedere laag doet waarvoor hij ontworpen is. Achteraf kan perfect een bepaalde laag worden aangepast, zonder hiervan invloed te hebben op andere tiers.

En zo kan ik nog wel even doorgaan. Maar wat maakt de opdrachtgever het nou uit om te kiezen voor php, als hij de functionaliteiten maar kan terugvinden toch?? Of zijn er andere dingen waarop hij gefocused moet worden voordat dit duidelijk wordt voor hem?

[Grijze Vos]

-FoX- schreef op maandag 13 december 2004 @ 12:08:
[...]

Een serieuze webapplicatie is gewoon not done in php. Of kent er iemand ondertussen al een bank-applicatie volledig op php gebaseerd? _{en waarom zou dit zo zijn??}

Bank applicaties hebben echt top notch security nodig, valt wat mij betreft niet te vergelijken met een "reguliere" serieuze applicatie.

Voor mij zijn testen héél belangrijk, heel je code valt/staat hiermee.. + je bent altijd zeker van je code. Bij php zie ik bvb het unit-testen nog niet echt terugkomen. Al bestaat het wel, toch wordt het zelfden door php'ers gedaan.

Is dat de schuld van PHP? Nee, eerder van het feit dat er teveel 'prutsers' zich met PHP bezig houden. Sites als phpfreakz wakkeren slecht scripten alleen maar aan, overigens.

Voor mij is software-architectuur ook een belangrijk iets. Separation of Concerns.. iedere laag doet waarvoor hij ontworpen is. Achteraf kan perfect een bepaalde laag worden aangepast, zonder hiervan invloed te hebben op andere tiers.

Dit staat 100% los van je taal. Als je vindt dat je dit niet kan realiseren in PHP dan heb je of PHP nooit serieus geprobeerd, of je bent een slechte programmeur. nofi.

En zo kan ik nog wel even doorgaan. Maar wat maakt de opdrachtgever het nou uit om te kiezen voor php, als hij de functionaliteiten maar kan terugvinden toch?? Of zijn er andere dingen waarop hij gefocused moet worden voordat dit duidelijk wordt voor hem?

Dat is jouw taak dan he, om hem te overtuigen. Kheb genoeg argumenten gezien hier.

[Olaf van der Spek]

Manuzhai schreef op zaterdag 11 december 2004 @ 15:19:
Uiteraard niet altijd, maar wel vaak ja. Zie voor een simpel voorbeeld de canonical "Hello, world!" voorbeelden.

In welke taal kost het printen van een zin meer dan een regel?
Veel constructies zijn in veel talen gewoon hetzelfde.

Ok, aangezien PHP gespecialiseerd is in IO en alle 'headers' standaard geinclude zijn heb je iets minder bagage, maar in die bagage zitten toch (bijna) geen bugs.

[Verwijderd]

-FoX- schreef op maandag 13 december 2004 @ 12:08:
Een serieuze webapplicatie is gewoon not done in php. Of kent er iemand ondertussen al een bank-applicatie volledig op php gebaseerd? _{en waarom zou dit zo zijn??}

Het zal wel, maar ondanks dat serieuze imago van die banken en de bullet-proof technieken die ze zogenaamd gebruiken maken ze nog steeds de meest elementaire fouten:

Web search features are a common source of cross-site scripting flaws, especially those that echo back the requested search word or phrase to users, Greenhalgh says.

Greenhalgh's Web site notes similar flaws in seven other sites, including attacks on search features at reuters.com, Internet payment service WorldPay, and NatWest, part of The Royal Bank of Scotland. NatWest did not immediately respond to a request for comment.

"In effect what I am doing is using something that is designed to trust user input too much," he says.

Among other things, developers should design Web forms like ATM locators and search engines to validate the data that users enter into the fields and "sanitize" it, removing characters such as brackets that are used to render HTML and other computer code.

http://www.pcworld.com/news/article/0,aid,116949,00.asp

En zo kan ik nog wel even doorgaan. Maar wat maakt de opdrachtgever het nou uit om te kiezen voor php, als hij de functionaliteiten maar kan terugvinden toch?? Of zijn er andere dingen waarop hij gefocused moet worden voordat dit duidelijk wordt voor hem?

Een factor die wel een rol kan spelen is dat het voor een opdrachtgever gunstig is om bij reeds in de organisatie gebruikte technieken aan te sluiten. De meeste serieuze websites worden geloof ik nog steeds in Cobol geschreven

[-FoX-]

Grijze Vos schreef op maandag 13 december 2004 @ 12:28:
Bank applicaties hebben echt top notch security nodig, valt wat mij betreft niet te vergelijken met een "reguliere" serieuze applicatie.

Wie had het hier over een reguliere applicatie? Ik verduidelijk gewoon het feit dat php in z'n geheel niet opgewassen is tegen de mature oplossingen.

Is dat de schuld van PHP? Nee, eerder van het feit dat er teveel 'prutsers' zich met PHP bezig houden. Sites als phpfreakz wakkeren slecht scripten alleen maar aan, overigens.

Neen, heb ik dat gezegd dan? Ik zei dat dit over het algemeen niet geïmplementeerd wordt in de php webapplicaties... al dan niet afhangende van de 'prutsers'

Dit staat 100% los van je taal. Als je vindt dat je dit niet kan realiseren in PHP dan heb je of PHP nooit serieus geprobeerd, of je bent een slechte programmeur. nofi.

Yeah right! Dit is te realiseren in php.. evenals in de ScrotchPer taal die nog uitgevonden moet worden. Op welke manier implementeer je in php een message driven bean die adhv een jms-server bepaalde transacties doorvoert in bijvoorbeeld de aankoop van aandelen op de beurs? Ik bedoel gewoon.. voor dit soort dingen is php gewoon niet ontworpen. Of het kan laat ik even in het midden..

[Verwijderd]

OlafvdSpek schreef op maandag 13 december 2004 @ 12:49:
In welke taal kost het printen van een zin meer dan een regel?
Veel constructies zijn in veel talen gewoon hetzelfde.

PHP wint het altijd met hello.php!

code:

Hello world!

Vergelijk dat eens met bloated talen als Perl:

code:

print "Hello world!\n";

;-)

[Olaf van der Spek]

> PHP wint het altijd met hello.php!

1 line vs 1 line?

[Verwijderd]

OlafvdSpek schreef op maandag 13 december 2004 @ 13:10:
> PHP wint het altijd met hello.php!

1 line vs 1 line?

12 karakters vs 23 karakters natuurlijk!

[Erkens]

Verwijderd schreef op maandag 13 december 2004 @ 13:05:
[...]

PHP wint het altijd met hello.php!

code:

Hello world!

daar is geen regel PHP te zien

Perl:

print "Hello World!\n";

PHP:

<?php echo "Hello World!\n"; ?>

[Verwijderd]

Erkens schreef op maandag 13 december 2004 @ 13:12:
[...]

daar is geen regel PHP te zien

Ah, je snapte 'm! Goed!

[Erkens]

Verwijderd schreef op maandag 13 december 2004 @ 13:13:
[...]


Ah, je snapte 'm! Goed!

nee jij zegt dat dat PHP was, maar dat was het niet, verder is het nogal dom om talen te vergelijken op de hoeveelheid typwerk imo.
Als je gewoon goed bezig bent hoef je steeds minder te typen omdat je alle functionele gedeeltes al eens gebouwd hebt of gebruik kan maken van andere lib's.

[Verwijderd]

Erkens schreef op maandag 13 december 2004 @ 13:17:
nee jij zegt dat dat PHP was, maar dat was het niet, verder is het nogal dom om talen te vergelijken op de hoeveelheid typwerk imo.
Als je gewoon goed bezig bent hoef je steeds minder te typen omdat je alle functionele gedeeltes al eens gebouwd hebt of gebruik kan maken van andere lib's.

Jij zou de semantische betekenis van smilies eens nader moeten bekijken.

Het was een geintje!!!

[Erkens]

Verwijderd schreef op maandag 13 december 2004 @ 13:33:
[...]

Jij zou de semantische betekenis van smilies eens nader moeten bekijken.

Het was een geintje!!!

offtopic:
waar heb jij dan die smilies geplaatst

OlafvdSpek schreef op maandag 13 december 2004 @ 13:43:
[rml]Xenna in "[ JAVA] vs [ PHP] wat is de meerwaarde?"[/rml]

Laatste regel.

ah, mja, text smilies gebruiken op een forum waar er plaatjes voor zijn is niet erg handig, en daarnaast vind ik een, knipoog meer zoiets van zie je wel dat het beter is zo oid, niet als een geintje, daar is meer voor imo of

[ Voor 46% gewijzigd door Erkens op 13-12-2004 13:48 ]

[Olaf van der Spek]

[rml]Xenna in "[ JAVA] vs [ PHP] wat is de meerwaarde?"[/rml]

Laatste regel.

[SPee]

Je moet ook kijken waar hij moet draaien.

Als het op een goedkope hoster moet komen, heb je in de meeste gevallen geen beschikking over Java ondersteuning. Zelfs bij de meeste cheap-hosters, heb je wel PHP ondersteuning.

Wordt de server echter beheerd door het bedrijf zelf, dan zou ik eerder voor Java gaan. Zeker als er veel gebruikers gebruik van gaan maken.

[Verwijderd]

Ik zou erg uitkijken met PHP. De ontwikkelingen gaan niet perse in de richting die voor grote webapplicaties wenselijk is. Zelf heb ik het gevoel alsof de sturing bij het PHP team een beetje de weg kwijt is.

De focus die de laatste tijd gelegd wordt op het OO model en de command-line omgeving zijn daar een goed voorbeeld van: OO in PHP is eigenlijk niet zo heel erg nuttig, in vergelijking met de functionaliteit die het wel mist. Eigenschappen als OO, namespaces, bescherming van data tegen andere functies, foutafhandeling, je klassen al geladen hebben (en niet bij elke pagina aanroep opnieuw), een programma flow die paginas kan uitpoepen en POSTs kan opvangen en verder gaan (ipv bij elke interactie weer bovenin het script staan), etc, zouden structureel in te taal en diens standaardfuncties moeten zitten. Nu is het erbij gepropt, of zit het er niet in.

Dat de taal een stapel hacks is, regelmatig downwards compatibility breekt in subversies, en stiekum totaal niet platform-onafhankelijk is voegt ook niet toe aan de professionaliteit.

Ondanks deze gebreken voldoet PHP prima voor kleine webapplicaties, of webapplicaties die meer van Javascript/DHTML eisen dan van de server. Voor niet-kleine webapplicaties zou ik daarom al gauw voor de oplossingen gaan die zich daar wel, en professioneel, op toespitsen. In jouw geval dus J2EE.

Van Sun, dat de zakelijke markt (ondere andere) als doelgroep heeft, kan je ook in de toekomst meer verwachten dan van een PHP team, dat uiteindelijk doet waar het zin in heeft.

[ Voor 6% gewijzigd door Verwijderd op 13-12-2004 14:02 ]

[Verwijderd]

SPee schreef op maandag 13 december 2004 @ 13:44:
Je moet ook kijken waar hij moet draaien.

Als het op een goedkope hoster moet komen, heb je in de meeste gevallen geen beschikking over Java ondersteuning. Zelfs bij de meeste cheap-hosters, heb je wel PHP ondersteuning.

Wordt de server echter beheerd door het bedrijf zelf, dan zou ik eerder voor Java gaan. Zeker als er veel gebruikers gebruik van gaan maken.

Aan zijn probleem omschrijving wil hij een erg grote en betrouwbare applicatie draaien. Dan een cheap hosting provider kiezen is redelijk stom.

[Grijze Vos]

-FoX- schreef op maandag 13 december 2004 @ 13:01:
Yeah right! Dit is te realiseren in php.. evenals in de ScrotchPer taal die nog uitgevonden moet worden. Op welke manier implementeer je in php een message driven bean die adhv een jms-server bepaalde transacties doorvoert in bijvoorbeeld de aankoop van aandelen op de beurs? Ik bedoel gewoon.. voor dit soort dingen is php gewoon niet ontworpen. Of het kan laat ik even in het midden..

Als je over architectuur begint, en dan meteen java-specifieke termen gaat smijten om aan te tonen dat een andere taal dat al da niet kan, twijfel ik aan de sterkte van je argument. Taal-specifieke eigenschappen wegen mee in een ontwerp, maar dat een taal geen 'beans' heeft, wil niet zeggen dat hij niet message driven transacties kan doorvoeren.

Daarbij komt natuurlijk dat je front end zaken in PHP zou kunnen doen, en bepaalde back end transacties in een andere taal. Verder lijkt HTTP verdacht veel op een message driven protocol, dus lijkt me dat PHP ook message driven werkt, niet?

[kasper_vk]

Grijze Vos schreef op maandag 13 december 2004 @ 15:44:
[...]
[...]
.... Verder lijkt HTTP verdacht veel op een message driven protocol, dus lijkt me dat PHP ook message driven werkt, niet?

Ik neem aan dat men die smiley moet opvatten als het signaal dat je zelf ook doorhebt dat deze opmerking van geen kanten deugt.

[Verwijderd]

Erkens schreef op maandag 13 december 2004 @ 13:38:
ah, mja, text smilies gebruiken op een forum waar er plaatjes voor zijn is niet erg handig, en daarnaast vind ik een, knipoog meer zoiets van zie je wel dat het beter is zo oid, niet als een geintje, daar is meer voor imo of

OK, ok, maar het was echt een geintje en kan ik het helpen als GOT mijn smilies niet snapt?

[Verwijderd]

Manuzhai schreef op zaterdag 11 december 2004 @ 15:19:
[...]
Uiteraard niet altijd, maar wel vaak ja. Zie voor een simpel voorbeeld de canonical "Hello, world!" voorbeelden.

Als je snel Hello world! wilt uitprinten, moet je HQ9++ gaan programmeren

[Grijze Vos]

kasper_vk schreef op maandag 13 december 2004 @ 15:49:
[...]


Ik neem aan dat men die smiley moet opvatten als het signaal dat je zelf ook doorhebt dat deze opmerking van geen kanten deugt.

(multifunctioneel, zo'n knipoog smily)

[drm]

Kunnen we een beetje ontopic blijven hier, ajb?

edit:
*kuch* ik had geen rood kleurtje meer. Tijd voor de

Ik meen 't overigens wel

[ Voor 52% gewijzigd door drm op 13-12-2004 18:29 ]

[Verwijderd]

Verwijderd schreef op maandag 13 december 2004 @ 16:44:
[...]


Als je snel Hello world! wilt uitprinten, moet je HQ9++ gaan programmeren

Mijn voorkeur gaat uit naar white space: http://compsoc.dur.ac.uk/whitespace/

Voor een hello world voorbeeld:

http://compsoc.dur.ac.uk/whitespace/hworld.ws

[Verwijderd]

SPee schreef op maandag 13 december 2004 @ 13:44:
Je moet ook kijken waar hij moet draaien.

Als het op een goedkope hoster moet komen, heb je in de meeste gevallen geen beschikking over Java ondersteuning. Zelfs bij de meeste cheap-hosters, heb je wel PHP ondersteuning.

Wordt de server echter beheerd door het bedrijf zelf, dan zou ik eerder voor Java gaan. Zeker als er veel gebruikers gebruik van gaan maken.

Je zegt het zelf al. Bedrijven spelen in op de wensen van de klant. Cheap hosting providers mikken op de amateurs en die willen PHP (omdat dat lekker makkelijk is, en de geavanceerde concepten, daar hebben de Ome Piets en Ome Ali's van Nederland toch geen kaas van gegeten). Serieuze bedrijven hebben hun eigen server in een rack staan en die zullen dus, inderdaad, vaker voor Java of ASP.NET kiezen.

[djc]

Ik moet zeggen dat ik het toch wel erg met Grijze Vos eens ben. Het is natuurlijk makkelijk om te zeggen dat PHP geen beans heeft om te communiceren met een JMS, maar daarmee zeg je niets over echte functionaliteit die al dan niet beschikbaar zou zijn in PHP.

[Erkens]

Verwijderd schreef op maandag 13 december 2004 @ 23:02:
Je zegt het zelf al. Bedrijven spelen in op de wensen van de klant. Cheap hosting providers mikken op de amateurs en die willen PHP (omdat dat lekker makkelijk is, en de geavanceerde concepten, daar hebben de Ome Piets en Ome Ali's van Nederland toch geen kaas van gegeten). Serieuze bedrijven hebben hun eigen server in een rack staan en die zullen dus, inderdaad, vaker voor Java of ASP.NET kiezen.

maw bedrijven die geld verdienen met PHP applicaties zijn ameteurs? Ook al hebben ze eigen servers in een rack hangen? En daar dan bewust PHP op draaien?
PHP is een vrij volwassen platvorm om voor te ontwikkelen, en gelukkig zien veel bedrijven dat ook is mijn ervaring ook al ben ik maar een studentje die via projecten en stages in aanraking is gekomen met dit soort bedrijven. Handig dan om je studiepunten te verdienen bij amateurs

[Verwijderd]

Erkens schreef op maandag 13 december 2004 @ 23:08:
[...]

maw bedrijven die geld verdienen met PHP applicaties zijn ameteurs? Ook al hebben ze eigen servers in een rack hangen? En daar dan bewust PHP op draaien?

Als een serieus bedrijf weloverwegen voor PHP kiest, goed voor hun, er zal dan wel iets moois uit komen. Waar ik echter bang voor ben is dat mensen die geen verstand hebben van IT een willekeurig PHP team een opdracht geven. Wat ik, en velen anderen, proberen aan te geven is de kans dat je met een PHP team een stelletje prutsers treft groter is dan met een Java team. Er zijn goede PHP programmeurs, slechte Java programmeurs, bla bla bla... daar gaat het helemaal niet om.

Toch vraag ik me af of het lekker is om in mixed languages te coden. Aan de ene kant is het wel te doen voor totaal verschillende dingen (bijna elke iteratieve taal mengt wel met SQL voor DB toegang), maar welke taal willen jullie dan gebruiken icm PHP? (PHP is alleen voor de presentatie laag, net zoals JSP in J2EE). Toch weer gewoon Java, of C++, of nog wat anders?

[Erkens]

Verwijderd schreef op dinsdag 14 december 2004 @ 00:21:
Wat ik, en velen anderen, proberen aan te geven is de kans dat je met een PHP team een stelletje prutsers treft groter is dan met een Java team. Er zijn goede PHP programmeurs, slechte Java programmeurs, bla bla bla... daar gaat het helemaal niet om.

maar hoe groot is die kans, je kan wel leuk van alles beweren en ik wil dat best wel geloven hoor, maar zonder bewijs is dat argument niks waard
Overigens kwam ik zojuist op mijn zoek tocht ook een complete PHP certification tegen, wat mij opzich al voldoende zegt dat PHP echt volwassen is

Toch vraag ik me af of het lekker is om in mixed languages te coden. Aan de ene kant is het wel te doen voor totaal verschillende dingen (bijna elke iteratieve taal mengt wel met SQL voor DB toegang), maar welke taal willen jullie dan gebruiken icm PHP? (PHP is alleen voor de presentatie laag, net zoals JSP in J2EE). Toch weer gewoon Java, of C++, of nog wat anders?

Waarom is PHP alleen voor de presentatie laag? PHP is tegenwoordig ook prima in te zetten op de andere lagen, het enige nadeel wat er is is het feit dat de applicatie enkel "draait" op het moment dat er een request is. Wat overigens ook wel op te lossen is als je dat perse nodig hebt. Maar alleen als je dat echt nodig hebt (wat in 9 van de 10x niet hoeft imo) dan zou ik gaan kijken naar J2EE of .NET oid)

[Verwijderd]

Goed, aangezien we schijnbaar toch de thread misbruiken voor deze pro/anti PHP discussie wil ik ook nog wel een duit in het zakje doen.

offtopic:
LET OP: Schaamteloze zelfverheerlijking
--------------------------------------------------------------------------------------------------------
Bij mijn huidige project heb ik bewust gekozen voor PHP terwijl ik eigenlijk meer thuis ben in Java. Reden hiervoor is de eenvoudige integratie met onze IIS server, die tegelijk dienst doet als Lotus Notes web engine, waarmee de PHP applicatie samenwerkt om alle gegevens in een uniforme web frontend beschikbaar te maken.

Bijkomend voordeel is dat de geintegreerde Windows authenticatie zonder problemen kan worden toegepast op dit PHP systeem voor een transparante login. Na deze authenticatie haal ik met de PHP LDAP extensie informatie over de gebruiker op uit onze Active Directory, waardoor rechten- en gebruikersbeheer centraal op 1 plek gemanaged kan worden.

Verder ondersteunt de applicatie zo'n beetje alle functies die ik kon bedenken, zip handling, content replicatie naar mirrors, automatische redirect naar de dichtbijzijnde mirror, front end template systeem etc. etc. etc.

En dan gaan jullie me vertellen dat PHP een taal is voor prutsers?
--------------------------------------------------------------------------------------------------------

maar welke taal willen jullie dan gebruiken icm PHP? (PHP is alleen voor de presentatie laag, net zoals JSP in J2EE).

Neen. PHP is geschikt voor zowel de frontend (presentatielaag) als de backend van een webapplicatie. JSP kun je vergelijken met inline PHP, maar PHP is zeer zeker ook geschikt voor de backend.

Wat ik, en velen anderen, proberen aan te geven is de kans dat je met een PHP team een stelletje prutsers treft groter is dan met een Java team.

Kijk, en hier geloof ik niet zo in. Voor PHP heb je niet al die flashy visual tools die je hebt voor zowel Java als .NET. Misschien dat er wel wat meer prutsers bij zitten door het lage instapniveau van PHP en de populariteit onder hobbyisten, maar in ieder geval proberen ze je dan niet af te zetten om hun Visual Studio/JBuilder terug te verdienen... toch?

Waar ik echter bang voor ben is dat mensen die geen verstand hebben van IT een willekeurig PHP team een opdracht geven.

Bij een weloverwogen IT investering zal er heus wel iemand zijn bij de opdrachtgever die de professionaliteit van een team kan inschatten. Het probleem ligt er IMO in dat deze investeringen niet weloverwogen worden gedaan. Als je hier als opdrachtgever zelf te weinig aandacht aan besteed, dan vraag je gewoon om problemen. En dan maakt het dus niks uit of je een PHP of een Java team de opdracht geeft.

[Verwijderd]

Overigens kwam ik zojuist op mijn zoek tocht ook een complete PHP certification tegen, wat mij opzich al voldoende zegt dat PHP echt volwassen is

Je hebt certificatie en certificatie. Klinkt allemaal heel leuk hoor maar het is zeer de vraag wat je eraan hebt. Bij sommige bedrijven worden de certificaten ongeveer weggegeven als je de naam van het product goed kan spellen. Bij andere bedrijven ligt het niveau trouwens weer erg hoog.

[Verwijderd]

Verwijderd schreef op dinsdag 14 december 2004 @ 00:21:
Toch vraag ik me af of het lekker is om in mixed languages te coden. Aan de ene kant is het wel te doen voor totaal verschillende dingen (bijna elke iteratieve taal mengt wel met SQL voor DB toegang), maar welke taal willen jullie dan gebruiken icm PHP? (PHP is alleen voor de presentatie laag, net zoals JSP in J2EE). Toch weer gewoon Java, of C++, of nog wat anders?

Ik combineer een PHP frontend vaak met een Perl backend. Bevalt me goed, Perl en PHP lijken redelijk op elkaar (Perl was een inspiratie voor PHP), maar helaas ook weer zoveel niet dat ik nogal eens geneigd ben syntax foutjes te maken. (waar ik dan overigens gewoon op gewezen wordt door de compiler/interpreter). Ik gebruik bijvoorbeeld een single-signon authenticatie server geschreven in Perl, met simpele client classes in PHP en (mod) Perl.

Mijn PHP applicaties draaien trouwens allemaal op speciaal daarvoor aangeschafte (rack)servers in ons data center en een paar op co-locaties.

[Eelke Spaak]

Verwijderd schreef op dinsdag 14 december 2004 @ 00:49:

offtopic:
LET OP: Schaamteloze zelfverheerlijking
--------------------------------------------------------------------------------------------------------
Bij mijn huidige project heb ik bewust gekozen voor PHP terwijl ik eigenlijk meer thuis ben in Java. Reden hiervoor is de eenvoudige integratie met onze IIS server, die tegelijk dienst doet als Lotus Notes web engine, waarmee de PHP applicatie samenwerkt om alle gegevens in een uniforme web frontend beschikbaar te maken.

Bijkomend voordeel is dat de geintegreerde Windows authenticatie zonder problemen kan worden toegepast op dit PHP systeem voor een transparante login. Na deze authenticatie haal ik met de PHP LDAP extensie informatie over de gebruiker op uit onze Active Directory, waardoor rechten- en gebruikersbeheer centraal op 1 plek gemanaged kan worden.

offtopic:
Als je de JBoss AS voor Java gebruikt kan je door simpelweg een LDAPLoginModule (o.i.d.) te kiezen geheel transparant een J2EE (web)-app beveiligen met LDAP.

[Verwijderd]

Eelke Spaak schreef op dinsdag 14 december 2004 @ 11:23:
[...]

offtopic:
Als je de JBoss AS voor Java gebruikt kan je door simpelweg een LDAPLoginModule (o.i.d.) te kiezen geheel transparant een J2EE (web)-app beveiligen met LDAP.

Ik wou dan ook alleen laten zien dat PHP meer dan genoeg mogelijkheden biedt om voor serieuze, volwassen taal door te gaan, niet dat PHP beter is dan Java.

offtopic:
Ik gebruik met veel plezier Java voor stand-alone applicaties en applets. maar ik _PERSOONLIJK_ vind dat je met PHP webapps sneller zichtbare resultaten krijgt, wat weer vertrouwenswekkend werkt bij opdrachtgevers. Maar in ieder geval bedankt voor de tip

[ Voor 3% gewijzigd door Verwijderd op 14-12-2004 13:38 ]

[-FoX-]

Verwijderd schreef op dinsdag 14 december 2004 @ 13:38:
[...]

Ik wou dan ook alleen laten zien dat PHP meer dan genoeg mogelijkheden biedt om voor serieuze, volwassen taal door te gaan, niet dat PHP beter is dan Java.

offtopic:
Ik gebruik met veel plezier Java voor stand-alone applicaties en applets. maar ik _PERSOONLIJK_ vind dat je met PHP webapps sneller zichtbare resultaten krijgt, wat weer vertrouwenswekkend werkt bij opdrachtgevers. Maar in ieder geval bedankt voor de tip

Niemand neemt in twijfel dat er met php webapplicaties gebouwd kunnen worden. Maar ook niemand, dan bedoel ik de grote (top500) bedrijven, draait hun kritieke webapplicaties zoals e-banking e.d. in php.

Aan de hand van php kunnen zéker snelle, goede, betrouwbare webapplicaties gebouwd worden en voor simpele webapps is de ontwikkeling best wel sneller.
Maar ik blijf bij mijn punt dat voor sommige, kritieke processen php apps gewoon niet voldoen! nofi

[Verwijderd]

Waarom ik Java boven PHP zou verkiezen (bij de grotere/gestructureerdere projecten)?

Simpel; Java heeft een application/session/request/page scope, php mist de request scope. Lastiger dus om MVC toe te passen in php, natuurlijk nooit onmogelijk.

[Verwijderd]

Eelke Spaak schreef op dinsdag 14 december 2004 @ 11:23:

offtopic:
Als je de JBoss AS voor Java gebruikt kan je door simpelweg een LDAPLoginModule (o.i.d.) te kiezen geheel transparant een J2EE (web)-app beveiligen met LDAP.

zelfs tomcat/jetty bieden dat, dus je hoeft geen full blown J2EE stack voor een LDAP realm. De userprincipal wordt opgebouwd adhv de rollen/rechten in je LDAP server...

(go java, om de compilatieredenen, meer frameworks en dus minder zelf doen en, laat ik maar toegeven, een ferme voorliefde).

offtopic:
/me heeft zijn eindwerk in PHP gemaakt en wil niet meer terug naar die dagen... (en ik was wel geslaagd).

[Erkens]

-FoX- schreef op dinsdag 14 december 2004 @ 13:55:
Maar ik blijf bij mijn punt dat voor sommige, kritieke processen php apps gewoon niet voldoen! nofi

voor welke kritieke processen voldoet PHP niet is mijn vraag dan?

[drm]

-FoX-:
Niemand neemt in twijfel dat er met php webapplicaties gebouwd kunnen worden. Maar ook niemand, dan bedoel ik de grote (top500) bedrijven, draait hun kritieke webapplicaties zoals e-banking e.d. in php.

Dat is niet interessant. Wat interessant is:

Waarom doen die "top500 bedrijven" dat dan niet in PHP?

Als je die vraag kan beantwoorden heb je een punt Anders is het alleen maar nietes/welles roepen en je eigen voorkeur verdedigen omdat het je eigen voorkeur is. Kom maar met stevige argumenten.

[Verwijderd]

Nu http://tca.gathering.tweakers.net/ weer werkt zou ik graag van de devver's @ t.net willen weten waarom er dit keer java is gebruikt ipv PHP? en hoe werkt dat in jullie omgeving? welke voor en nadelen ervaren jullie als T.net?

[Verwijderd]

drm schreef op dinsdag 14 december 2004 @ 16:07:Kom maar met stevige argumenten.

Verwijderd schreef op dinsdag 14 december 2004 @ 14:09:Simpel; Java heeft een application/session/request/page scope, php mist de request scope. Lastiger dus om MVC toe te passen in php...

[drm]

Is MVC dan een vereiste voor een kritiek (e-banking) systeem?

edit:
brakke formulering, maar je snapt wat ik bedoel ...

[ Voor 35% gewijzigd door drm op 14-12-2004 20:22 ]

[Creepy]

Verwijderd schreef op dinsdag 14 december 2004 @ 14:09:
Waarom ik Java boven PHP zou verkiezen (bij de grotere/gestructureerdere projecten)?

Simpel; Java heeft een application/session/request/page scope, php mist de request scope. Lastiger dus om MVC toe te passen in php, natuurlijk nooit onmogelijk.

Er is meer dan MVC alleen

[Verwijderd]

drm schreef op dinsdag 14 december 2004 @ 20:22:
Is MVC dan een vereiste voor een kritiek (e-banking) systeem?

Het gaat er niet om wat vereist is, iedere programmeur weet immers dat er meerdere wegen naar Rome zijn. Sommige zijn goed begaanbaar, andere slingeren een beetje mal in de rondte. Waar het wel om gaat, bij grotere bedrijfskritische projecten, is een transparant en bovenal gestructureerd product. Een product waarbij het dus duidelijk is welk onderdeel waarvoor verantwoordelijk is. Het moge duidelijk zijn dat MVC daar relaas biedt, iets wat dus in php lastig te realiseren is door het ontbreken van een request scope. Daardoor krijgt voor mij java duidelijk de voorkeur..

[Olaf van der Spek]

Verwijderd schreef op dinsdag 14 december 2004 @ 20:13:
Nu http://tca.gathering.tweakers.net/ weer werkt zou ik graag van de devver's @ t.net willen weten waarom er dit keer java is gebruikt ipv PHP? en hoe werkt dat in jullie omgeving? welke voor en nadelen ervaren jullie als T.net?

Ik gok op performance.
Ik heb geen ervaring met Java, maar volgens mij overleeft (een deel) van het script een request. Je kunt dus veel slimmer cachen.

[Verwijderd]

OlafvdSpek schreef op dinsdag 14 december 2004 @ 20:56:
[...]

Ik gok op performance.
Ik heb geen ervaring met Java, maar volgens mij overleeft (een deel) van het script een request. Je kunt dus veel slimmer cachen.

Nja, je hebt 2 soorten overleven:

1a. Een JSP wordt geconverteerd naar een servlet. Dat is opzich een eenvoudig process, waarbij eigenlijk je code en tags precies worden omgedraaid; wat eerst tussen <% %> stond staat nu direct als code, en alles daarbuiten staat als een out.print( ... );
1b. De servlet wordt gecompileerd door (meestal) de gewone Java compiler naar een .class file. Natuurlijk wordt deze bewaart en niet steeds overnieuw gecompileert. Compilen is eenmalig voor de eerste request of van te voren.

2. Je kunt per class in je JSP pagina aangeven wat de scope is, bv page of session. Bij session overleeft ie de request. Je kunt ook handmatig dingen in en uit de session stoppen dmv een soort hashtable interface.

Ik ken PHP niet zo goed, maar ik neem aan dat PHP beide dingen ook gewoon heeft. -zo- slecht zal de taal en het platform nou ook weer niet zijn.

[maartenba]

PHP en Java/J2EE vergelijken is een beetje zoals appelen en peren...
Ben momenteel ook aan een grotere applicatie bezig, in PHP, omdat de server van de klant geen Java ondersteunt en er ook geen budget is voor een Java (of .net) platform...

Dingen die ik mis in PHP, die er wel zijn in .net en Java:
- Het blijven hangen van pagina's in de sessie, zodat deze de request overleven
- Enkele simpele dingen als ArrayLists
- Een persistency framework als Hibernate... Tuurlijk kan je zelf je O/R klassen maken, maar daar kruipt zoveel energie in...
- MVC en het werken in lagen is in PHP sowieso moeilijker te realiseren, het is mogelijk, maar daar kruipt ook weer meer moeite in
- Geen echte variabeletypes... Type hinting is niet mijn ding, geef maar lekker echte int's, Strings, ...

Dingen die ik dan weer wel leuk vind aan PHP zijn de snelle manier van werken (ten nadele van structuur, dikwijls), en de geschiktheid van de taal voor kleine(re) dingen...
Java en .net zijn een beetje bloated voor bepaalde zaken als een contactformulier bv., maar als je echt denk aan een webAPPLICATIE en niet een webSITE, dan kies ik liever voor Java of .net...

My 2 cents, niet geheel objectief waarschijnlijk, maar ik vermoed dat er velen deze logica wel kunnen volgen

[Creepy]

maartenba schreef op dinsdag 14 december 2004 @ 22:02:
PHP en Java/J2EE vergelijken is een beetje zoals appelen en peren...
Ben momenteel ook aan een grotere applicatie bezig, in PHP, omdat de server van de klant geen Java ondersteunt en er ook geen budget is voor een Java (of .net) platform...

Zowel PHP als Java zijn qua software aan prijs gelijk (lees: gratis). Of heb je het hier over de kosten van een externe ontwikkelaar?

[maartenba]

Kosten van externe ontwikkelaar + het feit dat de Tomcat server niet mee op de PHP servermachine mag...
Stom, maar ja

[ Voor 12% gewijzigd door maartenba op 14-12-2004 22:44 ]

[Erkens]

Verwijderd schreef op dinsdag 14 december 2004 @ 20:31:
Waar het wel om gaat, bij grotere bedrijfskritische projecten, is een transparant en bovenal gestructureerd product. Een product waarbij het dus duidelijk is welk onderdeel waarvoor verantwoordelijk is. Het moge duidelijk zijn dat MVC daar relaas biedt, iets wat dus in php lastig te realiseren is door het ontbreken van een request scope. Daardoor krijgt voor mij java duidelijk de voorkeur..

Met PHP kan je prima MVC toepassen en transparant en tevens gestructreerd werken
Waarom zou dat lastig zijn doordat er een request scope ontbreekt
Waar ik momenteel mee bezig ben (is dan wel niet een groot bedrijfskritisch project maargoed) is een PHP project waarbij ik ook alles gescheiden houdt, en er een duidelijk gestructureerde manier van werken is. Wat ik denk is dat veel mensen die hier gereageerd hebben nog nooit serieus met PHP gewerkt hebben, en ja dan is het lastig om echt met argumenten te komen

[Verwijderd]

Erkens schreef op dinsdag 14 december 2004 @ 23:27:
[...]
Wat ik denk is dat veel mensen die hier gereageerd hebben nog nooit serieus met PHP gewerkt hebben, en ja dan is het lastig om echt met argumenten te komen

Dat is absoluut waar. Ik zie wat dingetjes van PHP die me slecht lijken en ik heb er meteen een oordeel over, zonder dat ik me echt verdiept heb ik de dingen die mischien wel goed zijn. Als er ook een aantal serieuze developpers het gebruiken zullen die er natuurlijk zeker in zitten.

Maar wat al eerder gezegd is door een deel van de mensen die kritiek hebben op PHP: het is niet zozeer de taal opzich als wel het soort mensen dat het momenteel aantrekt. De vergelijking met australians of lonsdale vond ik wel sterk, het is daar ook niet het merk zelf maar een bepaalde groep mensen die het een slechte reputatie geeft.

[Olaf van der Spek]

Verwijderd schreef op dinsdag 14 december 2004 @ 21:43:
2. Je kunt per class in je JSP pagina aangeven wat de scope is, bv page of session. Bij session overleeft ie de request. Je kunt ook handmatig dingen in en uit de session stoppen dmv een soort hashtable interface.

Ik ken PHP niet zo goed, maar ik neem aan dat PHP beide dingen ook gewoon heeft. -zo- slecht zal de taal en het platform nou ook weer niet zijn.

PHP heeft ook sessions ja.
Maar ik doelde meer op globale variabelen die in alle sessies beschikbaar zijn.

[Verwijderd]

OlafvdSpek schreef op woensdag 15 december 2004 @ 00:24:
[...]

PHP heeft ook sessions ja.
Maar ik doelde meer op globale variabelen die in alle sessies beschikbaar zijn.

Globale variablen zijn evil (beetje beter moeten opletten bij PM! ) en bestaan zowieso niet in Java. Maar je doelt op de variablen die je standaard in je JSP page ter beschikking hebt zoals request, out, exception, etc?

[Olaf van der Spek]

Verwijderd schreef op woensdag 15 december 2004 @ 21:22:
Globale variablen zijn evil (beetje beter moeten opletten bij PM! ) en bestaan zowieso niet in Java. Maar je doelt op de variablen die je standaard in je JSP page ter beschikking hebt zoals request, out, exception, etc?

Ik weet het, maar ze bestaan wel.
Nee, ik doel op variabelen die leven zolang de server leeft en in alle requests beschikbaar zijn.

[Erkens]

OlafvdSpek schreef op woensdag 15 december 2004 @ 23:18:
[...]

Ik weet het, maar ze bestaan wel.
Nee, ik doel op variabelen die leven zolang de server leeft en in alle requests beschikbaar zijn.

in wat voor serieuze toepassing zou je die willen gebruiken Van die variabelen weet je _nooit_ zeker wat en of er wat in staat

[Onno]

Erkens schreef op woensdag 15 december 2004 @ 23:25:
Van die variabelen weet je _nooit_ zeker wat en of er wat in staat

Want?

[Erkens]

Onno schreef op woensdag 15 december 2004 @ 23:37:
[...]

Want?

omdat "iedereen" ze kan aanpassen

[Weng]

Erkens schreef op woensdag 15 december 2004 @ 23:25:
[...]

in wat voor serieuze toepassing zou je die willen gebruiken

Bijna elke toepassing waarbij je moet inloggen zou ik bijna zeggen.

Van die variabelen weet je _nooit_ zeker wat en of er wat in staat

Wat bedoel je met _nooit_ zeker weten? Je weet toch wat je erin stopt?

omdat "iedereen" ze kan aanpassen

Hoe?

[ Voor 7% gewijzigd door Weng op 15-12-2004 23:43 ]

[Erkens]

Weng schreef op woensdag 15 december 2004 @ 23:41:
[...]
Bijna elke toepassing waarbij je moet inloggen zou ik bijna zeggen.

[...]
Wat bedoel je met _nooit_ zeker weten? Je weet toch wat je erin stopt?

nee dat weet je niet, want als andere mensen ook ingelogt zijn kunnen die het ook aanpassen

[Onno]

Erkens schreef op woensdag 15 december 2004 @ 23:41:
nee dat weet je niet, want als andere mensen ook ingelogt zijn kunnen die het ook aanpassen

Euhh.. ik gok dat ie doelt op variabelen binnen bijvoorbeeld een Java servlet context. En die kan echt niet iedereen zomaar aanpassen, en je kunt ze zelf netjes initialiseren in je startup code.

_{(en dus geen sessie-variabelen, Weng)}

[ Voor 8% gewijzigd door Onno op 15-12-2004 23:51 ]

[Weng]

Erkens schreef op woensdag 15 december 2004 @ 23:41:
[...]

nee dat weet je niet, want als andere mensen ook ingelogt zijn kunnen die het ook aanpassen

OlafvdSpek brengt een beetje verwarring met z'n een-na-laatste post door te zeggen dat een var in alle sessies beschikbaar is. In de laatste post zegt ie wat ie echt bedoelt denk ik . De var is gewoon voor 1 sessie beschikbaar, waar alle requests (van de sessie) gewoon bij kunnen.

En anders heb je wat mij betreft gelijk

[ Voor 9% gewijzigd door Weng op 15-12-2004 23:51 ]

[Grijze Vos]

Weng schreef op woensdag 15 december 2004 @ 23:48:
[...]
OlafvdSpek brengt een beetje verwarring met z'n een-na-laatste post door te zeggen dat een var in alle sessies beschikbaar is. In de laatste post zegt ie wat ie echt bedoelt denk ik . De var is gewoon voor 1 sessie beschikbaar, waar alle requests (van de sessie) gewoon bij kunnen.

En dat kan PHP dus ook gewoon.

[Janoz]

Erkens schreef op woensdag 15 december 2004 @ 23:41:
[...]

nee dat weet je niet, want als andere mensen ook ingelogt zijn kunnen die het ook aanpassen

Je hebt variabelen per sessie, maar ook per applicatie als het ware. Soms wil je ook dat iedereen ze aan kan passen. Wat dacht je bijvoorbeeld van een tellertje voor het aantal mensen op je site? Elke keer als een sessie start hoog je die 1tje op en elke keer als een sessie beeindigd verlaag je hem weer. Ben heel benieuwd hoe dit simpel in php opgelost kan worden .

[ Voor 7% gewijzigd door Janoz op 15-12-2004 23:55 ]

[Erkens]

Janoz schreef op woensdag 15 december 2004 @ 23:54:
[...]

Je hebt variabelen per sessie, maar ook per applicatie als het ware. Soms wil je ook dat iedereen ze aan kan passen. Wat dacht je bijvoorbeeld van een tellertje voor het aantal mensen op je site? Elke keer als een sessie start hoog je die 1tje op en elke keer als een sessie beeindigd verlaag je hem weer. Ben heel benieuwd hoe dit simpel in php opgelost kan worden .

mja, dat doe ik of met een file of een update in de database, maar ik vind dat niet echt iets wat een bedrijfskritisch proces is
Tenzij je wellicht een applicatie bouwt voor bijvoorbeeld nedstat die veel tellers heeft. Maar ook daar zal je moeten zorgen dat je het zeer regelmatig opslaat ergens, immers een server crashed altijd op een ongewenst moment

[Onno]

Erkens schreef op woensdag 15 december 2004 @ 23:58:
[...]

mja, dat doe ik of met een file of een update in de database, maar ik vind dat niet echt iets wat een bedrijfskritisch proces is

Dan denk je maar aan iets als een netwerkverbinding voor het een of ander. Dat soort dingen is in PHP niet echt te doen geloof ik. Sommige types verbindingen (db's) hebben dan wel speciale functies die een cache aanleggen, maar dat komt niet in de buurt bij het gewoon kunnen behouden van elk gewenst object.

[Verwijderd]

en toen begon met met Grooooooooooooovy java proggen : )

http://groovy.codehaus.org/

Groovy is a new agile dynamic language for the JVM combining lots of great features from languages like Python, Ruby and Smalltalk and making them available to the Java developers using a Java-like syntax.

[Janoz]

Erkens schreef op woensdag 15 december 2004 @ 23:58:
[...]

mja, dat doe ik of met een file of een update in de database, maar ik vind dat niet echt iets wat een bedrijfskritisch proces is
Tenzij je wellicht een applicatie bouwt voor bijvoorbeeld nedstat die veel tellers heeft. Maar ook daar zal je moeten zorgen dat je het zeer regelmatig opslaat ergens, immers een server crashed altijd op een ongewenst moment

Die teller is maar een voorbeeld. Er zijn legio andere voorbeelden van applicatie scope variabelen te bedenken. Denk bijvoorbeeld aan configuratie onderdelen. Bij php zul je altijd een workaround via de schijf of een db oid moeten doen, maar dat is niet tot lastig thread save te maken. Bijkomend nadeel daarvan is dat php alleen leeft tussen het moment dat het request binnen komt en het moment dat het opmaken van die pagina klaar is. Meer dan enkel een waarde kun je zo niet van de ene naar de andere pagina of session brengen (irc of ftp verbinding bijvoorbeeld).

[Verwijderd]

Janoz schreef op woensdag 15 december 2004 @ 23:54:
Je hebt variabelen per sessie, maar ook per applicatie als het ware. Soms wil je ook dat iedereen ze aan kan passen. Wat dacht je bijvoorbeeld van een tellertje voor het aantal mensen op je site? Elke keer als een sessie start hoog je die 1tje op en elke keer als een sessie beeindigd verlaag je hem weer. Ben heel benieuwd hoe dit simpel in php opgelost kan worden .

Met een veldje in een database?

Ik log zelf meestal uitgebreid alle page accesses naar een database en gebruik een Perl script dat iedere 5 minuten die raw entries naar een tabel omzet die beter geschikt is voor het genereren van grafiekjes. Die gebruik ik dan ook om het aantal ingelogde gebruikers (semi-live, per periode van 5 minuten) uit te halen. Maar het kan natuurlijk veel simpeler met een los tellertje in een database.

[Erkens]

Janoz schreef op donderdag 16 december 2004 @ 01:20:
[...]

Die teller is maar een voorbeeld. Er zijn legio andere voorbeelden van applicatie scope variabelen te bedenken. Denk bijvoorbeeld aan configuratie onderdelen. Bij php zul je altijd een workaround via de schijf of een db oid moeten doen, maar dat is niet tot lastig thread save te maken. Bijkomend nadeel daarvan is dat php alleen leeft tussen het moment dat het request binnen komt en het moment dat het opmaken van die pagina klaar is. Meer dan enkel een waarde kun je zo niet van de ene naar de andere pagina of session brengen (irc of ftp verbinding bijvoorbeeld).

maar sinds wanneer veranderen configuratie onderdelen die van toepassing zijn op _alle_ requests? afaik horen configuratie parameters constanten te zijn toch
Nu ben ik sowieso geen voorstander van globale variabelen, je weet met die dingen nooit wanneer ze veranderen.

Het enige wat niet eenvoudig te implementeren is in php is idd die irc verbinding die open blijft, maar daar zijn dan wel weer andere oplossingen voor. Nu is IRC of FTP niet echt een goed voorbeeld natuurlijk, want in wat voor applicatie heb je die verbindingen nodig (en dat ze open blijven) want IRC is natuurlijk leuk, maar als je afhankelijk bent van een FTP server klopt er iets imo niet

[Onno]

Erkens schreef op donderdag 16 december 2004 @ 09:43:
maar sinds wanneer veranderen configuratie onderdelen die van toepassing zijn op _alle_ requests? afaik horen configuratie parameters constanten te zijn toch

Voorbeeldje: je gebruikt LDAP in je webapplicatie en gebruikt daarvoor een pool van LDAP servers, waarvan sommige wel eens down kunnen zijn. Het hele idee van een pool is dat je daar geen last van hebt, maar als je stomweg een statische configuratie gebruikt en elke keer een random server blijft proberen zul je toch lange delays/fouten krijgen als je per ongeluk een foute pakt. Je wilt dus performance data bijhouden over elk van die geconfigureerde servers, om altijd de snelste te kunnen gebruiken. 100 keer per seconde een configuratiebestandje updaten is dan niet echt praktisch, en hetzelfde geldt van in een database zetten. (en als je s/LDAP/database/ doet in dit voorbeeld zou dat sowieso afvallen)

Nu ben ik sowieso geen voorstander van globale variabelen, je weet met die dingen nooit wanneer ze veranderen.

Want?

Het enige wat niet eenvoudig te implementeren is in php is idd die irc verbinding die open blijft, maar daar zijn dan wel weer andere oplossingen voor.

Nou.. het enige.. misschien het enige van de een of twee voorbeeldjes die hij noemde.

Je kunt zo nog 1414 dingen bedenken die niet kunnen. Denk ook eens aan caching van veelgebruikte gegevens bijvoorbeeld. Dat kan veel efficienter als je dingen kunt bewaren. Background processing van gegevens, ook onmogelijk binnen je webapp. Dan zul je een apart script ergens moeten hebben draaien, maar dan is het weer niet of lastig te synchroniseren met je webapp. Enz enz enz.

[ Voor 34% gewijzigd door Onno op 16-12-2004 10:16 ]

[Erkens]

Onno schreef op donderdag 16 december 2004 @ 10:09:
[...]

Voorbeeldje: je gebruikt LDAP in je webapplicatie en gebruikt daarvoor een pool van LDAP servers, waarvan sommige wel eens down kunnen zijn. Het hele idee van een pool is dat je daar geen last van hebt, maar als je stomweg een statische configuratie gebruikt en elke keer een random server blijft proberen zul je toch lange delays/fouten krijgen als je per ongeluk een foute pakt. Je wilt dus performance data bijhouden over elk van die geconfigureerde servers, om altijd de snelste te kunnen gebruiken. 100 keer per seconde een configuratiebestandje updaten is dan niet echt praktisch, en hetzelfde geldt van in een database zetten. (en als je s/LDAP/database/ doet in dit voorbeeld zou dat sowieso afvallen)

als je zo'n pool afhandeld in je applicatie ben je fout bezig, dat moet je op een ander niveau doen imo.

Want?

Je snapt zeker niet dat er een groot risico zit aan het gebruik van dergelijke variabelen?

Je kunt zo nog 1414 dingen bedenken die niet kunnen. Denk ook eens aan caching van veelgebruikte gegevens bijvoorbeeld. Dat kan veel efficienter als je dingen kunt bewaren. Background processing van gegevens, ook onmogelijk binnen je webapp. Dan zul je een apart script ergens moeten hebben draaien, maar dan is het weer niet of lastig te synchroniseren met je webapp. Enz enz enz.

precies wat je zegt background processing hoort niet binnen een webapp te draaien

[drm]

Erkens:
maar sinds wanneer veranderen configuratie onderdelen die van toepassing zijn op _alle_ requests?

Erkens:
Nu ben ik sowieso geen voorstander van globale variabelen, je weet met die dingen nooit wanneer ze veranderen.

Erkens:
... maar als je afhankelijk bent van een FTP server klopt er iets imo niet

Echt allemaal non-argumenten.

Het gaat er om dat het een conceptueel gemis is in PHP, en daar kan je gewoon niet omheen. Het is wel zo dat je er allerlei lapmiddeltjes voor kan verzinnen, maar dat betekent in de praktijk dat je dan meer bezig bent met de implementatie van die lapmiddeltjes dan dat je direct gebruik kunt maken van het concept. Het feit dat servlets in 1 applicatiescope draaien heeft gewoon absoluut zijn voordelen, en als je dat niet ziet begrijp je volgens mij gewoon het idee niet. Ik zeg niet dat dat PHP onzinnig maakt, of dat de oplossingen in PHP nooit werkbaar zijn, maar het is wel een gemis.

Erkens:
als je zo'n pool afhandeld in je applicatie ben je fout bezig, dat moet je op een ander niveau doen imo.

Dat lijkt mij nou echt een typisch geval van dikke vette onzin. Op welk "niveau" moet je dat doen dan Snap je het idee van een pool wel

Je snapt zeker niet dat er een groot risico zit aan het gebruik van dergelijke variabelen?

Even voor de duidelijkheid: applicatie-scope variabelen zijn wat anders dan globale variabelen.

precies wat je zegt background processing hoort niet binnen een webapp te draaien

Dat is het punt helemaal niet. Het punt is dat je er in je webapp gebruik van kunt maken. En als het niet in je webapp hoort, waar hoort het dan wel (als je het nodig hebt) Precies hetzelfde als met de connectionpool...

[Olaf van der Spek]

Erkens schreef op donderdag 16 december 2004 @ 11:03:
Je snapt zeker niet dat er een groot risico zit aan het gebruik van dergelijke variabelen?

Nee. Dat risico is sterk 'implementatie-afhankelijk'. Bij voorbaat zeggen dat het onveilig is, is niet 'handig'.
Een voorbeeld van een redelijk veilige 'globale' (per-app) variable in C++ is een static class variable. Je weet zeker dat alleen de class die variabele kan veranderen (als die private is).

Vooral voor caching zijn dit soort zaken handig. Veel web scripts zijn moeilijk vooruit te branden (makkelijk /. effect), IMO vooral omdat alles elke keer weer uit de DB moet komen.
Als de queries complexer worden wordt dit issue belangrijk.

[ Voor 5% gewijzigd door Olaf van der Spek op 16-12-2004 11:53 ]

[Olaf van der Spek]

Erkens schreef op donderdag 16 december 2004 @ 11:03:
precies wat je zegt background processing hoort niet binnen een webapp te draaien

Het hoort niet in de web request processor, maar wel in de web app.

[Onno]

Erkens schreef op donderdag 16 december 2004 @ 11:03:
*snip*

Dat al die zaken in PHP in feite niet mogelijk zijn en dat het daarin dus niet wenselijk is ze daar zo op te lossen betekent niet meteen dat dat in het algemeen ook geldt. Een connectiepool kan op weinig andere plaatsen geimplementeerd worden, caching is bedoeld om het geheel sneller te maken en daar wil je dus niet al te veel andere laagjes voor nodig hebben, background processing kan erg nuttig zijn voor bijvoorbeeld het pre-fetchen van data die je verwacht nodig te hebben in een volgende request.

[Verwijderd]

Voor een connectionpool is het inderdaad onmisbaar dat je code hebt draaien die ook tussen de requests blijft leven. De code die dat regelt zit natuurlijk niet in je JSP laag, maar op servlet niveau.

Wat een connectionpool bijvoorbeeld ook doet, is na een timeout (die geheel los staat van de request scope time) een connection weer vrij geven. Dat zorgt ervoor dat als je code hebt draaien die vergeet een connection (eigenlijk resource in het algemeen) vrij te geven, deze niet al je connecties opslokt.

In JSP -kun- je echter ook gewoon variablen declareren die na het omzetten in de servlet dan als class instance variablen gemaakt worden. Je gebruikt daarvoor de <%! %> syntax. Bijvoorbeeld:

Java Server Page:

<%! private int bar = 4; %>

Je moet er hier wel rekening mee houden dat voor elke page maar 1 servlet instance wordt gemaakt, waar dan meerdere threads (1 per request) door heen gaan. Je toegang tot bar hier -moet- dus gesynchronized zijn.

De uitzondering is als je singleThreadModel voor je page declareerd. Dan hoeft de access voor een gewone member variable niet gesynchronzied te zijn (er is altijd maar 1 thread actief in je object dan). Je kunt zelfs dan nog data delen, maar dan moet je je variable static maken:

Java Server Page:

<%! private static int bar = 4; %>

Deze manier van application wide data is mogelijk, maar ik vermijd haar zelf zo veel als kan en gebruik in mijn web layer alleen objecten met sessie scope. Het feit dat je met je servlets wel gewoon een continu draaiende applicatie hebt (in de diepere lagen) is echter onmisbaar. Ik wist niet dat PHP zoiets niet had en vind dat toch wel een extra gemis.

Hier is nog een quote uit core servelts and jsps over PHP vs JSP:

PHP is a free, open-source HTML-embedded scripting language that is somewhat
similar to both ASP and JSP. The advantage of JSP is that the dynamic
part is written in Java, which you probably already know, which already has an extensive API for networking, database access, distributed objects, and the like,
whereas PHP requires learning an entirely new language.

Deze quote is dus overduidelijk gericht op 'gewone' programmeurs die ook al andere applicaties schrijven behalve web apps. Het voordeel dat hier genoemd wordt is dat dezelfde API die je ook voor andere projecten gebruikt, gewoon her-gebruikt kan worden.

[Erkens]

Verwijderd schreef op donderdag 16 december 2004 @ 15:02:
Hier is nog een quote uit core servelts and jsps over PHP vs JSP:


[...]


Deze quote is dus overduidelijk gericht op 'gewone' programmeurs die ook al andere applicaties schrijven behalve web apps. Het voordeel dat hier genoemd wordt is dat dezelfde API die je ook voor andere projecten gebruikt, gewoon her-gebruikt kan worden.

Die quote is van iemand die (net als heel veel hier) een negatief beeld van PHP wilt geven