[PHP 5.0.0] Final release!

[JSchut]

OlafvdSpek schreef op 14 juli 2004 @ 12:10:
Is Apache 2 support nog steeds experimental zoals in PHP 4 of is het eindelijk 'stable'?

Dat wil ik ook wel weten idd.....

[Olaf van der Spek]

Soultaker schreef op 14 juli 2004 @ 02:17:
Wat is er bekend over backward compatibility? Is het zinnig om PHP4 te vervangen door PHP5 zonder dat bestaande scripts kapot gaan?

Er is in ieder geval:

zend.ze1_compatibility_mode - Enable compatibility mode with Zend Engine 1 (PHP 4)

[drm]

Soultaker:
Wat is er bekend over backward compatibility? Is het zinnig om PHP4 te vervangen door PHP5 zonder dat bestaande scripts kapot gaan? Is het mogelijk om op PHP5 te ontwikkelen en de scripts (zonder PHP5-specifieke features, natuurlijk) vervolgens op een PHP4 server te draaien?

Absoluut zonder problemen gaat dat niet (heb het wel eens geprobeerd met de release candidates), maar e.e.a. hangt erg af van hoe je de scripts geschreven hebt. Ik heb hele stukken OO moeten herschrijven, omdat PHP4 nogal sloppy is met references e.d. Daar maakte ik gebruik van door hier en daar objecten te gewoon te hergebruiken voor output, bijvoorbeeld. Aangezien in PHP5 de references wel allemaal "echt" zijn, verlies je dus data.

Dus ga er maar niet vanuit dat backward compatibility echt je van het is

[Dutchmega]

Je kan trouwens niet de PHP5 singleton gebruiken als je 'zend.ze1_compatibility_mode' op On hebt staan.

Ik krijg trouwens mysqli niet aan de gang.... Als ik
extension=php_mysqli.dll
toevoeg aan php.ini krijg ik melding dat het aangegeven procedure niet kan vinden? Oplossing: (nieuwe) libmysql.dll en libmysqli.dll kopieren naar C:\Windows\system32 en zorg ook ervoor dat je minimaal MySQL 4.12 hebt (momenteel 4.13 beta uit)

Ik zie trouwens ook niet het grote voordeel van prepared statements in mysqli. Het is wel leuk dat je geen addslashes hoeft te doen (wat ik al niet deed dankzij magic_quotes_gpc) maar ik zie er verder niet veel in?

[ Voor 17% gewijzigd door Dutchmega op 14-07-2004 13:00 ]

[Verwijderd]

Is het mogelijk om versie 4 en 5 op hetzelfde systeem te draaien? Eventueel op poort 80 en 81 op een webserver ?
Of moet je dan IIS en Apache installeren en beide een andere php versie geven ?

[djc]

OlafvdSpek schreef op 14 juli 2004 @ 12:10:
Is Apache 2 support nog steeds experimental zoals in PHP 4 of is het eindelijk 'stable'?

Nee, en dat wordt het voorlopig ook niet. Zie hier en hier.

[alienfruit]

Ja, kan gebruik bijv. PHP4 via Apache Module en PHP5 koppel je dan bijv. aan de extensie .php5 en gebruik je de CGI modus van PHP5 (daz php-cgi.exe) werkt hier prima iig

[djc]

Verwijderd schreef op 14 juli 2004 @ 13:12:
Is het mogelijk om versie 4 en 5 op hetzelfde systeem te draaien? Eventueel op poort 80 en 81 op een webserver ?
Of moet je dan IIS en Apache installeren en beide een andere php versie geven ?

Als het goed is kun je met verschillende mime-types ervoor zorgen dat .php5 files door PHP 5 worden afgehandeld en de rest door PHP 4. Je kunt ook twee Apaches naast elkaar draaien, dat wordt hier uitgelegd.

[PrisonerOfPain]

Dutchmega schreef op 14 juli 2004 @ 12:56:
Ik zie trouwens ook niet het grote voordeel van prepared statements in mysqli. Het is wel leuk dat je geen addslashes hoeft te doen

addslashes moet je ook niet doen, je moest eigenlijk mysql_real_escape_string omdat addslashes alleen ' " \ en NULL escaped. Terwijl mysql_real_escape_string 0 ' " b n r t z en \ escaped..

gebruiken, (wat ik al niet deed dankzij magic_quotes_gpc) maar ik zie er verder niet veel in?

magic_quotes_gpc geeft een vals veiligheidsgevoel...

[Bbfreak]

Beetje n00b vraag maar weet iemand waar ik een bundel kan downloaden waar
de nieuwste PHP, Apache en MySQLi in zitten. Zo heb ik op mijn server een oude NuSphere gebruikt en dat werkte harstikke handig.
Als iemand een link heeft naar een duidelijk uitleg over hoe dit allemaal handmatig te installeren is het ook goed.

[Dutchmega]

PrisonerOfPain schreef op 14 juli 2004 @ 13:24:
[...]

addslashes moet je ook niet doen, je moest eigenlijk mysql_real_escape_string omdat addslashes alleen ' " \ en NULL escaped. Terwijl mysql_real_escape_string 0 ' " b n r t z en \ escaped..

[...]

magic_quotes_gpc geeft een vals veiligheidsgevoel...

Leg het maar eens uit aan mij Wat moet ik dan doen

Bbfreak schreef op 14 juli 2004 @ 13:27:
Beetje n00b vraag maar weet iemand waar ik een bundel kan downloaden waar
de nieuwste PHP, Apache en MySQLi in zitten. Zo heb ik op mijn server een oude NuSphere gebruikt en dat werkte harstikke handig.
Als iemand een link heeft naar een duidelijk uitleg over hoe dit allemaal handmatig te installeren is het ook goed.

Voor zo ver ik weet, zijn er nog geen bundels.. vooral als je nagaat dat PHP5 pas vanochtend is uitgekomen. Maar je kan zeer gemakkelijk gewoon PHP5 over PHP4 installeren

[Olaf van der Spek]

Manuzhai schreef op 14 juli 2004 @ 13:14:
Nee, en dat wordt het voorlopig ook niet. Zie hier en hier.

Ik snap niet dat die links niet bij dat statement (Apache 2 ^ PHP) staat.

Welke versie van MySQL heeft PHP 5 eigenlijk nodig? Ik heb 4.0 (libmySQL.dll net geupdate), maar PHP kan mysql_drop_db niet vinden.

[ Voor 17% gewijzigd door Olaf van der Spek op 14-07-2004 14:49 ]

[djc]

Voor de bundelliefhebbers: WAMP5.

[MatHack]

De MySQLi library heb je trouwens alleen nodig als je een MySQL versie vanaf 4.1 gebruikt.

OlafvdSpek schreef op 14 juli 2004 @ 14:10:
[...]



Ik snap niet dat die links niet bij dat statement (Apache 2 ^ PHP) staat.

Welke versie van MySQL heeft PHP 5 eigenlijk nodig? Ik heb 4.0 (libmySQL.dll net geupdate), maar PHP kan mysql_drop_db niet vinden.

Als ik kijk op http://nl.php.net/manual/en/function.mysql-drop-db.php dan zie ik onderaan staan:

This function will not be available if the MySQL extension was built against a MySQL 4.x client library

[ Voor 16% gewijzigd door MatHack op 14-07-2004 15:20 ]

[Frash]

Manuzhai schreef op 14 juli 2004 @ 15:13:
Voor de bundelliefhebbers: WAMP5.

Zoiets mogen ze van mij ook wel voor Linux maken

[LinuX-TUX]

Frash schreef op 14 juli 2004 @ 16:14:
[...]

Zoiets mogen ze van mij ook wel voor Linux maken

Dan heet het XAMPP (maar of 5 uit is, weet ik nog niet)

edit:
Zie het nog niet staan

edit:
@ hieronder: Ja, LAMPP / XAMPP. Worden allebei gebruikt, op de site zeggen ze nu weer XAMPP, dus houd ik het daar even bij .... apt-cache pkgnames | grep ampp

[ Voor 44% gewijzigd door LinuX-TUX op 14-07-2004 16:30 . Reden: Typo + URL ]

[Olaf van der Spek]

MatHack schreef op 14 juli 2004 @ 15:20:
De MySQLi library heb je trouwens alleen nodig als je een MySQL versie vanaf 4.1 gebruikt.


[...]


Als ik kijk op http://nl.php.net/manual/en/function.mysql-drop-db.php dan zie ik onderaan staan:


[...]

Ja, maar momenteel wordt de hele extensie niet geladen.

[Olaf van der Spek]

LinuX-TUX schreef op 14 juli 2004 @ 16:26:
Dan heet het XAMPP (maar of 5 uit is, weet ik nog niet)

Waar staat die X voor?
Ik dacht dat het LAMP(P) was?

[Verwijderd]

Heb alvast PHP5 op een testbak (SuSE Server 8 ) geinstalleerd.

De oude .spec file blijft behoorlijk goed werken. Wel moet ik even libxml upgraden. Dan hebben we ook nu al een probleem met pdflib, deze is sinds PHP5rc3 ofzo in pecl gestopt. Heel fijn, alleen waarom ze dan de open_basedir beveiliging er uit halen....

Maar ziet er verder goed uit. Gaat denk ik niet lang duren voor ik die versie draai.

[aphx]

OlafvdSpek schreef op 14 juli 2004 @ 16:28:
[...]

Waar staat die X voor?
Ik dacht dat het LAMP(P) was?

Allebei goed!!!

http://www.apachefriends.org/en/xampp-linux.html

[Rhapsody]

Heb het net hier geinstalleerd, en geconfigureerd.

PHP 5 final op Windows XP met IIS als webserver.

Nu krijg ik alleen onderaan elke pagina

'PHP has encountered an Access Violation at 00B473CD'

hebben meer mensen hier last van?
En nog belangrijker hoe los ik dit op?

[Verwijderd]

Ik heb hem vanochtend zelf gecompiled op FreeBSD (er is nog geen port beschikbaar) met de volgende opties:

'./configure' '--enable-versioning' '--enable-memory-limit' '--with-layout=GNU' '--with-zlib-dir=/usr' '--with-regex=php' '--with-pear' '--with-bz2=/usr' '--enable-calendar' '--enable-ctype' '--with-curl=/usr/local' '--with-dom=/usr/local' '--with-dom-xslt=/usr/local' '--with-dom-exslt=/usr/local' '--enable-exif' '--enable-ftp' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/local' '--with-t1lib=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-xpm-dir=/usr/X11R6' '--with-gettext=/usr/local' '--enable-mbstring' '--with-mcal=/usr/local' '--with-mcrypt=/usr/local' '--with-mhash=/usr/local' '--with-mime-magic=/usr/share/misc/magic.mime' '--with-ming=/usr/local' '--with-mysql=/usr/local' '--with-openssl-dir=/usr' '--enable-overload' '--with-pcre-regex=yes' '--enable-posix' '--with-pgsql=/usr/local' '--enable-session' '--enable-sockets' '--enable-tokenizer' '--with-expat-dir=/usr/local' '--enable-xml' '--with-zip=/usr/local' '--with-zlib=yes' '--with-apxs=/usr/local/sbin/apxs' '--with-imap=/usr/local' '--with-imap-ssl=/usr/local' '--with-snmp=/usr/local' '--enable-ucd-snmp-hack' '--x-libraries=/usr/X11R6/lib' '--x-includes=/usr/X11R6/include' '--prefix=/usr/local' '--enable-simplexml'

(Gewoon hetzelfde als met PHP4 maar dan met '--enable-simplexml' erbij)

Alleen ik krijg phpMyAdmin niet werkend ik heb de laatste final en de laatste beta al geprobeerd maar het werkt niet... ik gebruik MySQL 4.0.20 dus MySQLi heeft dan volgens mij geen zin om erbij zetten...

Iemand enig idee hoe ik dit kan oplossen? Mijn zelfgemaakte PHP pagina's werken wel gewoon met MySQL...

(Bij de RC1 werkte hij ookal niet, toen had ik het geprobeerd met Apache onder Win32)

[Verwijderd]

Verwijderd schreef op 14 juli 2004 @ 17:18:
Alleen ik krijg phpMyAdmin niet werkend ik heb de laatste final en de laatste beta al geprobeerd maar het werkt niet... ik gebruik MySQL 4.0.20 dus MySQLi heeft dan volgens mij geen zin om erbij zetten...

kan je IETSIE duidelijker zijn?
WAT doet het niet aan pMA? Foutmeldingen? Ook maar iets aan informatie? Hier kan ik natuurlijk weinig mee...

[Verwijderd]

Verwijderd schreef op 14 juli 2004 @ 17:20:
[...]


kan je IETSIE duidelijker zijn?
WAT doet het niet aan pMA? Foutmeldingen? Ook maar iets aan informatie? Hier kan ik natuurlijk weinig mee...

Oeps vergeten erbij te zetten... ik kan niet inloggen op MySQL met phpMyAdmin met mijn oude gebruikersnaam/wachtwoord (kan wel gewoon via mysql -u root -p(password) )

[Xander]

Hmm, hij geeft hier een beetje wazige foutmeldingen?


Terwijl alles imo goed geconfigureerd is??

[Sybr_E-N]

Heb je 'libmysql.dll' al in je %SYSTEMROOT%, zoals 'c:\windows\', geplaatst?

[ Voor 17% gewijzigd door Sybr_E-N op 14-07-2004 17:42 ]

[Xander]

Sybr_E-N schreef op 14 juli 2004 @ 17:42:
Heb je 'libmysql.dll' al in je %SYSTEMROOT%, zoals 'c:\windows\', geplaatst?

ja

overigens heb ik dit ook met gd2....

O, trouwens, behalve de foutmelding hier boven geeft hij ook per module de foutmelding "This module could not be found"

[ Voor 26% gewijzigd door Xander op 14-07-2004 17:47 ]

[GX]

XanderH schreef op 14 juli 2004 @ 17:40:
Hmm, hij geeft hier een beetje wazige foutmeldingen?
[afbeelding]

Terwijl alles imo goed geconfigureerd is??

[afbeelding]

[afbeelding]

zoals al meerdere malen vermeld in dit topic, kopieer de mysql libs (niet php_mysql.dll) naar je system(32) directory, ze zitten als het goed is gewoon bij je dist.

_{iets met spuiten}

nog meer edit:
Alle modules die een dll nodig hebben in je system dir, maar die niet kunnen vinden, kunnen niet geinitialiseerd worden. Dan is het dus een kwestie van de .dll's goed zetten, en opnieuw de webserver starten.

[ Voor 20% gewijzigd door GX op 14-07-2004 17:49 ]

[Xander]

GX schreef op 14 juli 2004 @ 17:47:
[...]


zoals al meerdere malen vermeld in dit topic, kopieer de mysql libs (niet php_mysql.dll) naar je system(32) directory, ze zitten als het goed is gewoon bij je dist.

Zoals ik net al vermeld heb, ik heb de mysql libs al gekopieerd

Ik kan ook lezen


Die krijg ik dus ook...

[vargo]

Verwijderd schreef op 14 juli 2004 @ 17:23:
[...]


Oeps vergeten erbij te zetten... ik kan niet inloggen op MySQL met phpMyAdmin met mijn oude gebruikersnaam/wachtwoord (kan wel gewoon via mysql -u root -p(password) )

Looks as if the bug reports are coming in. Here's a serious one: HTTP authentication is broken. Expect a PHP 5.0.1 or 5.0.0 patch level 1 real soon now.

Bron: http://www.phpdeveloper.org/index/2281

Uit de config.inc.php van PhpMyAdmin:

PHP:

$cfg['Servers'][$i]['auth_type']     = 'config';    // Authentication method (config, http or cookie based)?

Misschien dat je gebruik maakt van de http authentication?

[Verwijderd]

Toevallig niemand zin om een OpenBSD 3.5 package te maken? Ben beetje lui vandaag .

[GX]

Verwijderd schreef op 14 juli 2004 @ 17:52:
Toevallig niemand zin om een OpenBSD 3.5 package te maken? Ben beetje lui vandaag .

pluk gewoon de config uit je huidige phpinfo(); en maak een paar kleine aanpassingen

[Xander]

GX schreef op 14 juli 2004 @ 17:47:
Alle modules die een dll nodig hebben in je system dir, maar die niet kunnen vinden, kunnen niet geinitialiseerd worden. Dan is het dus een kwestie van de .dll's goed zetten, en opnieuw de webserver starten.

Jaja, weet ik, en ik had de lib's goed staan... (overigens niet in system32, maar in windows-dir (ja dat is %SYSTEMROOT%)).

Anyway, vraag me niet wat het nu was, net PHP ff opnieuw installed (nouja, "uitgepakt) en het werkt gewoon (met zelfde configfile).

Alleen PHPMyStats doet het niet, maja, ff uitzoeken welke extensions die nodig heeft

[edit]
Ok, loopt nu draadje over op het PHPMyStats forum, hoeven we hier niet over verder te gaan

PHP5 draait hier nu dus goed, met Apache 2.0.48 en MySQL 4.0.17

[ Voor 13% gewijzigd door Xander op 14-07-2004 18:09 ]

[Verwijderd]

vargo schreef op 14 juli 2004 @ 17:52:
[...]


[...]

Bron: http://www.phpdeveloper.org/index/2281

Uit de config.inc.php van PhpMyAdmin:

PHP:

$cfg['Servers'][$i]['auth_type']     = 'config';    // Authentication method (config, http or cookie based)?

Misschien dat je gebruik maakt van de http authentication?

Jep dat is m, bedankt (en nou maar hopen dat die fix / update snel komt )

[Verwijderd]

Rhapsody schreef op 14 juli 2004 @ 17:04:
Nu krijg ik alleen onderaan elke pagina

'PHP has encountered an Access Violation at 00B473CD'

hebben meer mensen hier last van?
En nog belangrijker hoe los ik dit op?

Ik heb dit probleem ook en heb dit al als bug (#28929) gemeld. Kun je een vote uitbrengen, zodat de bug belangrijker wordt?

-Rémy

[Rhapsody]

Ik heb gestemd en ff een comment toegevoegd.

[Verwijderd]

GX schreef op 14 juli 2004 @ 17:57:
[...]

pluk gewoon de config uit je huidige phpinfo(); en maak een paar kleine aanpassingen

Was het maar waar, die config is gewoon "Built from the OpenBSD Ports Tree" .
En de ports configure syntax is dan weer net iets minder eenvoudig, want ik ben lui .

[djc]

Verwijderd schreef op 14 juli 2004 @ 16:37:
Dan hebben we ook nu al een probleem met pdflib, deze is sinds PHP5rc3 ofzo in pecl gestopt.

Dat een module in PECL betekent niet dat ie niet standaard wordt meegeleverd, alleen dat de module er een eigen release cycle er op na kan houden.

[krvabo]

Ik heb netzoiets als XanderH heeft;
maar ik krijg bij het starten van PHP de volgende error:

code:

PHP Warning:  PHP Startup: ¿I{☺░↕s☺: Unable to initialize module
Module compiled with module API=20020429, debug=0, thread-safety=1
PHP    compiled with module API=20040412, debug=0, thread-safety=1
These options need to match
 in Unknown on line 0

Deze krijg ik zo'n 5x per minuut op mijn beeldscherm
Ik verwacht dat het iets te maken heeft met een verouderde module. Alleen weet ik dus niet welke dit is.
Als ik de zip opnieuw uitpak krijg ik dat een aantal files met een wachtwoord zijn beveiligd

[ Voor 10% gewijzigd door krvabo op 14-07-2004 22:07 ]

[Verwijderd]

Verwijderd schreef op 14 juli 2004 @ 20:55:
[...]


Was het maar waar, die config is gewoon "Built from the OpenBSD Ports Tree" .
En de ports configure syntax is dan weer net iets minder eenvoudig, want ik ben lui .

Dit werkte onder FreeBSD , gewoon copy & paste:

'./configure' '--enable-versioning' '--enable-memory-limit' '--with-layout=GNU' '--with-zlib-dir=/usr' '--with-regex=php' '--with-pear' '--with-bz2=/usr' '--enable-calendar' '--enable-ctype' '--with-curl=/usr/local' '--with-dom=/usr/local' '--with-dom-xslt=/usr/local' '--with-dom-exslt=/usr/local' '--enable-exif' '--enable-ftp' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/local' '--with-t1lib=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-xpm-dir=/usr/X11R6' '--with-gettext=/usr/local' '--enable-mbstring' '--with-mcal=/usr/local' '--with-mcrypt=/usr/local' '--with-mhash=/usr/local' '--with-mime-magic=/usr/share/misc/magic.mime' '--with-ming=/usr/local' '--with-mysql=/usr/local' '--with-openssl-dir=/usr' '--enable-overload' '--with-pcre-regex=yes' '--enable-posix' '--with-pgsql=/usr/local' '--enable-session' '--enable-sockets' '--enable-tokenizer' '--with-expat-dir=/usr/local' '--enable-xml' '--with-zip=/usr/local' '--with-zlib=yes' '--with-apxs=/usr/local/sbin/apxs' '--with-imap=/usr/local' '--with-imap-ssl=/usr/local' '--with-snmp=/usr/local' '--enable-ucd-snmp-hack' '--x-libraries=/usr/X11R6/lib' '--x-includes=/usr/X11R6/include' '--prefix=/usr/local' '--enable-simplexml'

en dan make, en dan make install (btw, zo moeilijk is configure syntax toch niet )

[Verwijderd]

Tuurlijk niet, maar OpenBSD zit met een chrooted apache in /var/www, en sommige php libs (zoals PEAR) zitten daaronder dan in een dir terwijl andere php libs dan weer in /usr/local zitten.

[seweso]

*schopje zodat meer mensen (als mij) doorkrijgen dat php5 gereleased is *

En ik had eigenlijk verwacht dat PHP5 in augustus een keer gereleased werd... ik ga meteen kijken of het huidige systeem waar ik aan werk ook onder PHP5 werkt (test server inrichten). En ik verwacht dat dit de ontwikkel snelheid zeer ten goede gaat komen. Ik zat zelf namelijk met smart te wachten op SimpleXml

* seweso is heeel blij

[ Voor 1% gewijzigd door seweso op 15-07-2004 12:24 . Reden: oops php4 > php5 ]

[TwoR]

seweso schreef op 15 juli 2004 @ 12:21:
*schopje zodat meer mensen (als mij) doorkrijgen dat php4 gereleased is *

Volgens mij bedoel je daar php5

Maar inderdaad tis fijn dat ie uit is zodat we in de vakantie nog even lekker kunnen prutsen

[PrisonerOfPain]

TwoR schreef op 15 juli 2004 @ 12:23:
Maar inderdaad tis fijn dat ie uit is zodat we in de vakantie nog even lekker kunnen prutsen

De RC's zijn ook al tijden uit, dus dat was opzich het probleem niet (en ze waren erg stable)

[vargo]

Misschien dat dit een eigen topic verdient, maar voorlopig plaats ik het maar even onder deze thread.

Met de release van php5 is 1 van de belangrijkste veranderingen de nieuwe OO opzet. Wat vinden jullie ervan: wat ga je veel gebruiken / wat ontbreekt er / wat is verkeerd geimplementeerd?

Ik ga (zodra ik het rustiger met mijn werk heb) eens kijken hoe ik de nieuwe OO opzet kan gebruiken voor mijn code generatie project. Ik ga ondermeer kijken naar UML, XMI...

Nog wat interessante resources:

XMI2PHP

XMI2PHP is a php code generator which take an XMI (XMI is an XML based file format used to describe UML diagrams.) file and transform it into a file collection of php code.

http://www.waterproof.fr/products/xmi2php/
Dit is interessant omdat je hiermee in principe iedere UML modeler kan gebruiken die XMI ondersteund. Ik heb xmi2php nog niet kunnen testen.

OGM XMI specification
http://www.omg.org/technology/documents/formal/xmi.htm
Bij OGM kan je trouwens ook de UML specs vinden; ik vind echter persoonlijk de OGM documenten - zoals bijna elke officiele specificatie - niet erg praktisch om mee te beginnen.

Working XML: UML, XMI, and code generation, Part 2
http://www-106.ibm.com/developerworks/library/x-wxxm24/

Harry Fuecks over PHP and UML Class Diagrams
http://www.phppatterns.com/index.php/article/articleview/15/
(weliswaar meer op php4 gericht, maar toch interessant)

Sitepoint thread over UML & Php5
http://www.sitepoint.com/...ent.php?attachmentid=6742

Zend: php5 - goed startpunt om meer over php5 te weten te komen.
http://www.zend.com/php5/

Poseidon UML modeller - geen idee of je daarmee ook php kan genereren.
http://www.gentleware.com/products/

ArgoUML

ArgoUML now supports PHP5 code generation and does phpDocumentor compatible comments. This release is not rock-stable, but it's still interesting

http://argouml.tigris.org/download/release0156.html

/Edit: bijna vergeten
Metastorage

What is Metastorage?

Metastorage is a persistence layer generator application based on the persistence module of the MetaL compiler engine. Metastorage is capable of generating the necessary software components to implement a persistence layer API from a description in a format based on XML named Component Persistence Markup Language (CPML). The generated code is self-contained and does not depend on MetaL or any libraries of code that are not supplied.

What is MetaL?
MetaL is a meta-programming language compiler engine. Meta-programming is a method to develop programs in high-level language that can be translated into one or more programming languages.

MetaL compiler is able to process source code in XML and generate code in virtually any target language: PHP, Java, Perl, etc..

http://www.meta-language....tation.html#install-files

uml2php5
http://uml2php5.zpmag.com/en/

[ Voor 22% gewijzigd door vargo op 15-07-2004 14:01 ]

[Kees]

De nieuwe OOP was even wennen, zijn nogal wat dingen anders geworden waardoor mijn script niet meer werkte.
Dat was redelijk snel opgelost, en ik kreeg meteen de schrik van mijn leven

PHP5 was op het gebied van image creation, berekeningen etc ruim 10x sneller dan php4...
Een grafiek waar hij eerst 0,6 tot 0,7 seconden over deed doet hij nu in 0,06 0,07 seconden.. behoorlijke verbetering in mijn geval

[Verwijderd]

Verwijderd schreef op 14 juli 2004 @ 18:17:
[...]


Jep dat is m, bedankt (en nou maar hopen dat die fix / update snel komt )

Voor degenen niet niet kunnen wachten op die fix/update (zoals ik ), kunnen alvast de snapshot downloaden van 15 juni 22:30, toen hadden ze de bug al gefixed :):

http://snaps.php.net/php5-200407152230.tar.gz

Alles werkt nu prima bij mij
http://server.djuri.nl/phpinfo.php

[Glashelder]

curry684 schreef op 14 juli 2004 @ 02:05:
* curry684 gaat toevallig een dezer dagen Apache de deur uitknikkeren en terug naar IIS6... iemand ervaring met hoe PHP5 integreert met IIS6?

Ja mee bezig sinds gisteren, maar ik krijg - zelfs in lege scripts - allemaal access violations

[.oisyn]

Gebruik je de IIS extension? Die kreeg ik bij 4 ook al nooit aan de praat, altijd access violations. Ik draai hier PHP4 gewoon als CGI onder IIS6

[Glashelder]

Ik gebruik de ISAPI ja (php5isapi.dll). Ik ga CGI nu maar even proberen dan.

edit: ik heb de ISAPI filter werkend gekregen door gewoon vanaf 0 te beginnen. ISAPI filter toegevoegd, allowed gemaakt, executie rechten gegeven en als laatste als web server extensie toegevoegd. Hij werkt iig nu

[ Voor 61% gewijzigd door Glashelder op 20-07-2004 14:58 ]

[Rhapsody]

Glashelder schreef op 20 juli 2004 @ 14:51:
Ik gebruik de ISAPI ja (php5isapi.dll). Ik ga CGI nu maar even proberen dan.

edit: ik heb de ISAPI filter werkend gekregen door gewoon vanaf 0 te beginnen. ISAPI filter toegevoegd, allowed gemaakt, executie rechten gegeven en als laatste als web server extensie toegevoegd. Hij werkt iig nu

Kun je dat even toelichten?

Dan ga ik dat ook eens proberen

[Glashelder]

Uiteraard.

code:

IIS Manager -> {server} -> Web Sites -> rechtermuisknop: {website} -> properties

Tabblad: ISAPI filters -> Add -> Filtername: .php; Executable: *\php5isapi.dll
Tabblad: Home Directory -> Configration (Deze kan grijs zijn, druk op Remove) -> Add 

              Executable: *\php5isapi.dll
              Verbs: all verbs
              Script Engine: aangevinkt
              Check that file exists: uitgevinkt

Tabblad: Home Directory -> Execute Permissons: Scripts and Exacutables
Alles wegklikken behalve de IIS Manager.

Links klikken op Web Service Extensions. Add a new web server extension -> 

              Extension name: PHP
              Required Files: *\php5isapi.dll

IIS admin afsluiten. Start, uitvoeren: IISRESET..

Het kan zijn dat de ISAPI extension niet geladen wordt (er staat een rood pijltje naar beneden voor ipv een groene omhoog). Dan staan niet alle DLL's in de Windows map. Kopieer gewoon alle DLL's uit de PHP map naar je SystemRoot (zoeken in je PHP map naar "*.dll" en alles kopieren (ik gedaan iig)).

Dit zijn de precieze stappen die ik gevolgd heb...

[ Voor 11% gewijzigd door Glashelder op 20-07-2004 16:08 ]

[AirX]

PHP5 draait hier onder Linux (2.4 kernel) perfecto .

PHP Versie: 5.0.0
Apache Versie: Apache 2.0.50 (Unix)

Alleen wil op één of andere manier phpsysinfo niet meer draaien . Er komt gewoon nix in beeld. Heb nu maar ffe mijn eigen stats site gemaakt .

[Xander]

AirX schreef op 20 juli 2004 @ 15:49:
PHP5 draait hier onder Linux (2.4 kernel) perfecto .

PHP Versie: 5.0.0
Apache Versie: Apache 2.0.50 (Unix)

Alleen wil op één of andere manier phpsysinfo niet meer draaien . Er komt gewoon nix in beeld. Heb nu maar ffe mijn eigen stats site gemaakt .

Strange, PHPMyStats onder windows doet het ook al niet meer...

[Glashelder]

Naja wat er nu gebeurt slaat helemaal nergens op.

PHP:

phpinfo();

Levert geen error op

PHP:

echo "bl44t";

levert op:

code:

PHP has encountered an Access Violation at 016E73CDbl44t

[Rhapsody]

Glashelder schreef op 20 juli 2004 @ 15:42:
Uiteraard.

code:

Links klikken op Web Server Extensions. Add a new web server extension -> 

              Extension name: PHP
              Required Files: *\php5isapi.dll

IIS admin afsluiten. Start, uitvoeren: IISRESET..

Het kan zijn dat de ISAPI extension niet geladen wordt (er staat een rood pijltje naar beneden voor ipv een groene omhoog). Dan staan niet alle DLL's in de Windows map. Kopieer gewoon alle DLL's uit de PHP map naar je SystemRoot (zoeken in je PHP map naar "*.dll" en alles kopieren (ik gedaan iig)).

Dit zijn de precieze stappen die ik gevolgd heb...

Die 'web server extensions' zie ik nergens staan.
Moet dat in het menu staan?

[Glashelder]

Web Server Service Extensions staat in de treeview in het linkse menu van de IIS Manager.

[Rhapsody]

Glashelder schreef op 20 juli 2004 @ 15:58:
Naja wat er nu gebeurt slaat helemaal nergens op.

PHP:

phpinfo();

Levert geen error op

PHP:

echo "bl44t";

levert op:

code:

PHP has encountered an Access Violation at 016E73CDbl44t

Dat heb ik dus ook, maar ik krijg ook nog zo'n error bij phpinfo();

[DR]

AirX schreef op 20 juli 2004 @ 15:49:
Alleen wil op één of andere manier phpsysinfo niet meer draaien .

phpsysinfo 2.2 and earlier DOES NOT WORK on PHP5
phpsysinfo 2.3-cvs SHOULD WORKS on PHP5

_{http://phpsysinfo.sourceforge.net/}

[ Voor 9% gewijzigd door DR op 20-07-2004 16:10 ]

[JayVee]

vargo schreef op 15 juli 2004 @ 13:48:
Misschien dat dit een eigen topic verdient, maar voorlopig plaats ik het maar even onder deze thread.

Met de release van php5 is 1 van de belangrijkste veranderingen de nieuwe OO opzet. Wat vinden jullie ervan: wat ga je veel gebruiken / wat ontbreekt er / wat is verkeerd geimplementeerd?

Mij lijkt een apart topic ook wel leuk.

Ik heb een super artikel gevonden over OO PHP(5):
Zend in the clowns (lees vooral vanaf "i. The Backdrop").

Ik zie nu eindelijk het nut in van OO en classes in PHP (ben het gewoon eens met de auteur). En het nut ligt niet in het schrijven van scripts voor websites. Lees het artikel maar eens voor redenatie.

Ik ben zelf fan van OO (Java), maar zie het nut van objecten niet in in een niet-persistent omgeving. Per request wordt toch een bepaalde pagina ogevraagd (user management, nieuwsberichten, etc). Waarom zou je dat niet mooi scheiden in aparte scripts (of modules die in een setup/layout script ingeladen worden)?

[Bbfreak]

JayVee schreef op 22 juli 2004 @ 17:07:

Ik heb een super artikel gevonden over OO PHP(5):
Zend in the clowns (lees vooral vanaf "i. The Backdrop").

Idd erg leuk artikel. Interessant om te lezen wat andere er van denken.
En hij heeft er goede punten tussen zitten.

[SchizoDuckie]

Cerberus schreef op 14 juli 2004 @ 03:51:
[...]


Ik zou verwachten dat (eigenlijk net als PHP3 -> PHP4) het allemaal wel backwards compatible is. Ik krijg PHP5 zelf nog niet echt aan de praat alleen...Overal waar ik database verbindingen gebruik of output buffering geeft ie gewoon helemaal geen output.

Ik heb nog niet echt intensief getest en uitgeprobeerd maar volgens mij zou hij het toch moeten doen

Wat ik deed was:
php.ini-recommended renamen naar php.ini en replacen in m'n Windows map met de oude php4 php.ini, in Apache conf alle PHP4 naar PHP5 renamen (en een path aanpassen). Daarna Apache weer starten, geen errors oid.

misschien handige info: ik heb mezelf hier ook het schompes naar gezocht, ik kreeg idd helemaal geen output waar je normaal een error verwacht...
de oplossing is: in de php.ini-dist staat eeen standaard output-buffer van 2000 ofzow.
pleur die terug naar 0 en problemen zijn over

[Rhapsody]

Op www.php.net is de installer te downloaden voor PHP 5 en daar is de fout (access violation error) gefixed!!

Het werkt nu prima bij mij.

[Trinsec]

Ik snap dit niet. PHP5 werkt prima met IIS6, en als ik MySQL 4.1.3b (de laatste versie in ieder geval) wil toevoegen en die regel in php.ini uncomment voor MySQL, dan krijg ik steeds 'Unable to load dynamic library 'c:\php\php_mysql.dll' - The specified module could not be found.'.
Heb de thread doorgelezen, de libmysql.dll naar c:\windows\system32 gedaan, de php_mysql.dll is in c:\php... En nog steeds blijft hij dat error genereren.

[SchizoDuckie]

Trinsec schreef op 02 augustus 2004 @ 12:22:
Ik snap dit niet. PHP5 werkt prima met IIS6, en als ik MySQL 4.1.3b (de laatste versie in ieder geval) wil toevoegen en die regel in php.ini uncomment voor MySQL, dan krijg ik steeds 'Unable to load dynamic library 'c:\php\php_mysql.dll' - The specified module could not be found.'.
Heb de thread doorgelezen, de libmysql.dll naar c:\windows\system32 gedaan, de php_mysql.dll is in c:\php... En nog steeds blijft hij dat error genereren.

tip 1: LEES je foutmeldingen...
wat is je php plugins dir??? (probably c:\php\ext\)
wat is de dir waar ie je lib vandaan wil halen???

juist

[Trinsec]

Ik heb de php_mysql.dll al naar c:\php gemoved, en de foutmelding blijft. Lees mijn verhaal ook.

[Verwijderd]

Is altijd een gepruts, probeer de backslashes door slashes te vervangen en probeer het nog nog eens.

[Trinsec]

Ik bemerk door't lezen van verscheidene andere fora/support sites dat ik niet de enige ben met dit probleem. De oplossingen die zij aandragen is net als hier wordt gegeven: libmysql.dll naar de system32 directory, checken of path van php_mysql.dll goed is, etc. Dat heb ik allemaal al gedaan, gewoon volgens het boekje voor zover ik het kan zien. Ik krijg echter gewoon errors. Backslashes, slashes, no difference. Ik krijg sterk het gevoel dat de 'final' van dit PHP5 gewoon nog erg buggy is, ik ga binnenkort de laatste PHP van 4.x gebruiken, want deze errors slaan echt gewoon nergens op. Wel jammer, PHP zelf werkt perfect, alleen kan ik geen extensies toevoegen en dat is onhandig aangezien ik MySQL wil gaan gebruiken.

[Trinsec]

Update: Ik heb PHP5 geuninstalled en daarna manueel weer geinstalleerd. Had namelijk eerst de Windows Installer versie gebruikt.

Dus nadat ik alles manueel had gedaan, de extensions gemoved, de libmysql.dll van PHP5 zelf (zat niet bij de installer meegeleverd) enzovoorts... werkt alles nu. Volgens mij is die installer fubar, maar nu heb ik dus PHP5+MySQL4.1 running hier. Dus voor degenen die ook die rare foutmeldingen krijgt terwijl ze alles toch prima in orde hebben: Probeer de manuele versie te downloaden en dat te installeren. Eigenlijk heb je de installer niet nodig, is nogal simpel te instellen.

Hope this helped!

[creative8500]

Trinsec schreef op 02 augustus 2004 @ 20:47:
Update: Ik heb PHP5 geuninstalled en daarna manueel weer geinstalleerd. Had namelijk eerst de Windows Installer versie gebruikt.

Ik denk dat je dit wel wat eerder had mogen vermelden, volgens mij is hier nog niemand op het idee gekomen dat jij de installer had gebruikt, want die doet dat nu weer?! Maar je zult het wel begrijpen: altijd gewoon de binaries downloaden, waar 't Windows betreft.

[Trinsec]

creative8500 schreef op 03 augustus 2004 @ 00:00:
[...]

Ik denk dat je dit wel wat eerder had mogen vermelden, volgens mij is hier nog niemand op het idee gekomen dat jij de installer had gebruikt, want die doet dat nu weer?! Maar je zult het wel begrijpen: altijd gewoon de binaries downloaden, waar 't Windows betreft.

!!! Hey, ik vond het nogal logisch een installer te gebruiken bij IIS6. Kon ik't weten. Nahja, in ieder geval dat gedoe opgelost.

Nog een bijkomstigheid: Hou het bij MySQL 4.0.20 of eerder, niet 4.1.x, want die gebruikt een soort nieuwe authenticatie protocol waar PHP nog niet goed mee kan werken. PHP5, that is, PHP4 zal dat waarschijnlijk nooit gaan ondersteunen. Met MySQL 4.1.x kon ik niets beginnen.

_{Amazing hoeveel ik hiervan leer door alleen maar problemen te hebben met de software. Ik zou het liever overgeslagen hebben.}

[ Voor 9% gewijzigd door Trinsec op 03-08-2004 00:11 ]

[MatHack]

Voor MySQL 4.1.x moet je mysqli hebben in plaats van mysql

[Trinsec]

MatHack schreef op 03 augustus 2004 @ 08:41:
Voor MySQL 4.1.x moet je mysqli hebben in plaats van mysql

Daar weet ik dus niets vanaf. Hoe dat te enablen? Kweenie, zit niet in php.ini alhoewel er een kopje [mysqli] is. En als ik die zo even vluchtig doorlees zijn de functies ook anders, wat niet helpt met PHP scripts dat gewoon mysql functies gebruikt.

[Verwijderd]

MatHack schreef op 03 augustus 2004 @ 08:41:
Voor MySQL 4.1.x moet je mysqli hebben in plaats van mysql

Hoeft niet onder Unix (FreeBSD) iig niet. Ik kan gewoon MySQL 4.1.3-beta gebruiken met de "oude" mysql extensie.
Heb er net wel die " nieuwe" MySQLi bij gecompiled, maar die 2 kunnen gewoon naast elkaar dus je hoeft je oude PHP scripts niet "up-te-daten" om ze werkend te houden

[Reigner_Mortem]

JayVee schreef op 22 juli 2004 @ 17:07:
[...]

...
Ik ben zelf fan van OO (Java), maar zie het nut van objecten niet in in een niet-persistent omgeving. Per request wordt toch een bepaalde pagina opgevraagd (user management, nieuwsberichten, etc).

Ik weet niet zeker of ik het helemaal goed begrijp, maar nu ik ook een beetje bezig ben met php5 (sinds gisteren) kwam ik erachter dat alle objecten weer verwijderd worden nadat de pagina geladen is. Neem aan dat je dat bedoelt met "niet persistent".

Ik heb dat op deze manier opgelost
één aanspreekpunt de SiteManager
(die weer daarbinnen Content, User, DatabaseManager, Objecten… aanmaakt)

PHP:

<?php  
/* index.php */
    include_once ("SiteManager.php");   
    session_register('SiteManager');
    if(!isset($_SESSION['SiteManager']))
    {
        $_SESSION['SiteManager'] = SiteManager::GetInstance();
    }
    $_SESSION['SiteManager']->HandlePage();
?>

Dit schijnt te werken, echter is het wel vreemd dat nadat de pagina is geladen, alsnog objecten opgeruimd worden (de destructor word aangeroepen). Ondanks dat blijft de informatie(de objecten) behouden zolang de sessie niet verbroken word.
Worden er dus aan het begin kopieën gemaakt ?

Tevens kwam ik “PHP Bananas” tegen, kent iemand zich daarmee uit ?
Moet vergelijkbaar zijn met Java beans.
Keine krummen Dinger: PHP Bananas
PHP goes to the enterprise level

[BoomSmurf]

Rhapsody schreef op 31 juli 2004 @ 20:43:
Op www.php.net is de installer te downloaden voor PHP 5 en daar is de fout (access violation error) gefixed!!

Het werkt nu prima bij mij.

De installer installeert toch de CGI versie? De AV komt volgens mij alleen bij de ISAPI versie. (ik heb er ook last van - maar de CGI versie krijg ik niet aan de praat, krijg telkens een timeout). Nogal wiedes dan dat de installer versie het wel doet

[BoomSmurf]

In de laatse CVS versie (5.1 dev) van snaps.php.net is de AV opgelost.

Ik heb deze gebruikt: http://snaps.php.net/win32/php5-win32-200408041430.zip

[ Voor 36% gewijzigd door BoomSmurf op 04-08-2004 17:58 ]

[Verwijderd]

Helaas vind ik deze versie van PHP niet wat ik er van verwacht had, zoals al vermeld door andere gebruikers gaat het installatie proces met andere modules zoals GD, MYSQL, etc niet echt lekker rap ook het plaatsen van extra bestanden in de system32 dir vind ik niet echt een uitkomst.

Zouden ze de volgende keer niet gewoon DOMWEG een installer er bij kunnen maken voor windows gebruikers!? die hoeven het a. niet te compileren en b. kun je dan sneller componenten laten toevoegen.

Ach ik wacht wel af tot PHP6 mischien dat die wat meer installatie vriendelijk is

[Soultaker]

Tja, PHP is nu eenmaal niet primair voor Windows gemaakt. Ik vind het wel leuk dat Windows-gebruikers nu eens kunnen voelen hoe het is om ze zélf kennis van zaken te moeten hebben en moeite te moeten doen om software die niet specifiek voor hun besturingssysteem is ontwikkeld werkend te krijgen. Denk daar eens aan, de volgende keer dat je alternatieve besturingssystemen afschrijft als nodeloos complex!

Overigens is het maar een kwestie van tijd: Zend gaat wel een PHP5 installer maken en er zijn nu community alternatieven beschikbaar, zoals de Uniform Server die een kant-en-klare installatie van Apache 2, PHP 5, MySQL 4 en Perl 5 biedt.

[Robinski]

Verwijderd schreef op 04 augustus 2004 @ 18:12:
Helaas vind ik deze versie van PHP niet wat ik er van verwacht had, zoals al vermeld door andere gebruikers gaat het installatie proces met andere modules zoals GD, MYSQL, etc niet echt lekker rap ook het plaatsen van extra bestanden in de system32 dir vind ik niet echt een uitkomst.

Zouden ze de volgende keer niet gewoon DOMWEG een installer er bij kunnen maken voor windows gebruikers!? die hoeven het a. niet te compileren en b. kun je dan sneller componenten laten toevoegen.

Ach ik wacht wel af tot PHP6 mischien dat die wat meer installatie vriendelijk is

je kan ook gewoon je PHP map in je Path zetten... hoef je niks te kopieren

edit:
Het schijnt dat PHP 5.0.1 die eind deze week uit komt een installer bevat voor windows
zie ook: http://www.zend.com/zend/week/week195.php

edit2:
PHP4 had trouwens vroeger al een installer en ik zag net op PHP.Net dat de installer zelfs al online staat voor PHP 5.0.0

[ Voor 17% gewijzigd door Robinski op 04-08-2004 20:58 ]

[Verwijderd]

Ik krijg de volgende error:

Time-out van CGI
De opgegeven CGI-toepassing heeft de toegestane tijdsduur overschreden. De server heeft het proces verwijderd.

Dit bij het oproepen van een simpele php pagina...


Ik heb PHP5 geinstalleerd, de php.ini juist geconfigureerd zoals is aangegeven, de verschillende extensies ge-enabled en ook de .php extensie in IIS aan php-cgi.exe gekoppeld...

Wat doe ik fout?

[Verwijderd]

Soultaker schreef op 14 juli 2004 @ 02:17:
Mooie nieuwe features, als ik het zo zie. Het object oriented gebeuren vind ik niet heel interessant (op de bugfixes t.o.v. PHP4 na), maar XML integratie en bundeling met SOAP lijken me allebei sterke punten.

OO was misschien nodig, *ooit*. Ze hadden beter andere dingen kunnen ontwikkelen zodat ze daadwerkelijk hun marktaandeel behouden. Dingen als XML integratie/SOAP zijn leuk, maar *heel erg mager* voor een major update.

Je toespitsen op zaken als PHP aanroepbaar maken vanaf de commandline: hallo waar gaat dat nog om?

OO boeit nauwelijks; je gaat toch eigenlijk geen uitgebreide OO structuur opbouwen en objecten inlezen bij elke pagina aanroep. Het moest verbeterd worden, maar het is niet de Grote Update waar de webdev-wereld op zat te wachten.

Ze hadden er veel meer dingen in moeten stoppen zodat de development van webapps naar een nieuw niveau wordt getilt: dingen als interactie met het DOM model, abstractie van het pagina's opbouwen (een windowing toolkit iemand? waar blijven die libs in standaard PHP?) abstractie over de page generation/page request cyclus zijn zoveel meer waard als een gerepareerd OO model.

Als ze zo blijven steken als nu, gaan ze verliezen van bijvoorbeeld ASP en ASP.NET. Ze zitten zo dicht op hun eigen produkt dat ze de grote lijnen niet meer zien.

Wat is er bekend over backward compatibility? Is het zinnig om PHP4 te vervangen door PHP5 zonder dat bestaande scripts kapot gaan? Is het mogelijk om op PHP5 te ontwikkelen en de scripts (zonder PHP5-specifieke features, natuurlijk) vervolgens op een PHP4 server te draaien?

PHP weet in minor versions upgrade ook al backward compatibility te breken (is nu al meerdere malen gebeurd), dus ik vrees het ergste in de praktijk.

[Verwijderd]

Verwijderd schreef op 29 september 2004 @ 15:57:
[...]

OO was misschien nodig, *ooit*. Ze hadden beter andere dingen kunnen ontwikkelen zodat ze daadwerkelijk hun marktaandeel behouden. Dingen als XML integratie/SOAP zijn leuk, maar *heel erg mager* voor een major update.

Je toespitsen op zaken als PHP aanroepbaar maken vanaf de commandline: hallo waar gaat dat nog om?

OO boeit nauwelijks; je gaat toch eigenlijk geen uitgebreide OO structuur opbouwen en objecten inlezen bij elke pagina aanroep. Het moest verbeterd worden, maar het is niet de Grote Update waar de webdev-wereld op zat te wachten.

Ze hadden er veel meer dingen in moeten stoppen zodat de development van webapps naar een nieuw niveau wordt getilt: dingen als interactie met het DOM model, abstractie van het pagina's opbouwen (een windowing toolkit iemand? waar blijven die libs in standaard PHP?) abstractie over de page generation/page request cyclus zijn zoveel meer waard als een gerepareerd OO model.

Als ze zo blijven steken als nu, gaan ze verliezen van bijvoorbeeld ASP en ASP.NET. Ze zitten zo dicht op hun eigen produkt dat ze de grote lijnen niet meer zien.


[...]

PHP weet in minor versions upgrade ook al backward compatibility te breken (is nu al meerdere malen gebeurd), dus ik vrees het ergste in de praktijk.

Als je het allemaal zo goed weet, dan ga jij toch lekker die extensies voor php schrijven.
't zijn verdorie een heleboel vrijwilligers die een mooi product op de markt zetten. Gratis! Kritiek kan geen kwaad, maar dit slaat werkelijk waar nergens op.
Je interactie met het DOM verhaal volg ik ook niet helemaal. Voor zover ik weet kan je in php5 gewoon domxml gebruiken en dus het DOM bewerken.

[Verwijderd]

Als je het allemaal zo goed weet, dan ga jij toch lekker die extensies voor php schrijven.

De eeuwige kutsmoes: het is Open Source dus moet je er zelf maar induiken en niemand is verantwoordelijk van de hack-op-hack structuur. Misschien moeten ze zelf eens een roadmap opstellen van hoe ze websoftware ontwikkeld willen zien over een paar jaar, ipv ad-hoc features erin te hacken.

't zijn verdorie een heleboel vrijwilligers die een mooi product op de markt zetten. Gratis! Kritiek kan geen kwaad, maar dit slaat werkelijk waar nergens op.

Een hoop vrijwilligers dus je zou willen dat PHP sterker wordt op de markt om hun werk niet langzaam in het niets te zien verdwijnen. Ze releasen na jaren eindelijk een PHP5, zit er nauwelijks iets boeiends in. Terwijl ze bijvoorbeeld hopeloos willen proberen de CLI markt te penetreren, worden ze links en rechts ingehaald op webdevelopment.

Juist omdat er zoveel mensen aan werken is het jammer dat het core team het niet weet te sturen naar een fundamenteel betere taal maar blijft steken in het toevoegen van toeters en bellen. Dat OO bijvoorbeeld had er vanaf het begin al goed in moeten zitten. Nu is het gewoon te laat: OO is een extratje in de taal, niet een van de basissen.

Natuurlijk is het allemaal gratis en alles; maar er werken enorm veel mensen mee. Als je dan als open source project geen visie meer hebt, stappen mensen over op commerciele oplossingen die dat gewoonweg wel hebben. Ook zie ik heus wel dat kennelijk mijn visie voor de toekomst van PHP niet die van hun is. Ik denk gewoonweg dat ze op deze manier gewoon marktaandeel gaan verliezen, en dat vind ik jammer: het laatste wat ik wil is dat Microsoft een monopolie weet te krijgen met ASP/ASP.NET. Misschien is het gewoon tijd voor een nieuwe taal, maar ook dat zou jammer zijn voor al die PHP vrijwilligers.

Je interactie met het DOM verhaal volg ik ook niet helemaal. Voor zover ik weet kan je in php5 gewoon domxml gebruiken en dus het DOM bewerken.

In een extensie ja; en nog erg sterk in de experimenteerfase.

Ook maken al die extensies de boel niet bepaald platform-onafhankelijk. Ook kan een gebruiker geen extensie toevoegen zonder hulp van de admin: leuk bij machines zoals ISPs. Fundamentele dingen moeten gewoon standaard in de taal zitten. Als ze dat DOM gedoe goed krijgen, is dat er eentje.

[.oisyn]

Verwijderd schreef op 29 september 2004 @ 15:57:
OO boeit nauwelijks; je gaat toch eigenlijk geen uitgebreide OO structuur opbouwen en objecten inlezen bij elke pagina aanroep. Het moest verbeterd worden, maar het is niet de Grote Update waar de webdev-wereld op zat te wachten.

Ze hadden er veel meer dingen in moeten stoppen zodat de development van webapps naar een nieuw niveau wordt getilt: dingen als interactie met het DOM model, abstractie van het pagina's opbouwen (een windowing toolkit iemand? waar blijven die libs in standaard PHP?) abstractie over de page generation/page request cyclus zijn zoveel meer waard als een gerepareerd OO model.

Daarnaast, de features die ze wel hebben geimplementeerd gaan helemaal nergens over. Namespaces zou er in komen maar is uiteindelijk toch weggelaten (uit de changelog van PHP 5.0.0 beta 2, 30 okt 2003: Removed the not so working namespaces support. Euh ja, wat een stel dorks). Exceptions zonder finally block, exception-safe code anyone? Het ultra-lelijke __construct en __destruct, alsmede de compleet nutteloze __get, __set en __call die alleen maar zorgen voor bad coding practices ipv goed ontworpen programma's. En dat laatste noemen ze dan "overloading", right . Daarnaast blijft de variable scope nog altijd bagger, en aan het ranzige type juggling moeten ze ook eens werken. Vertel mij eens, waarom is "blaat" hetzelfde als 0?

[ Voor 5% gewijzigd door .oisyn op 29-09-2004 19:00 ]

[.oisyn]

Verwijderd schreef op 29 september 2004 @ 16:31:
Als je het allemaal zo goed weet, dan ga jij toch lekker die extensies voor php schrijven. 't zijn verdorie een heleboel vrijwilligers die een mooi product op de markt zetten.

Jij zeurt zeker ook niet over politiek omdat je er zelf niet in zit?

[ Voor 16% gewijzigd door .oisyn op 29-09-2004 18:59 ]

[-Lars-]

.oisyn schreef op 29 september 2004 @ 18:59:
[...]
Jij zeurt zeker ook niet over politiek omdat je er zelf niet in zit?

Aan de ontwikkelingen in de politiek kun je zelf elke 4 jaar een sturing geven. Verder kun je je kritiek op de politiek via allerlei wegen laten doorluiden in Den Haag.
(En voordat iedereen gaat zeuren dat de politiek toch niet luistert naar jou alleen: je bent niet alleen en de politiek moet ook rekening houden met anderen.)

NoFI, maar als je echt wilt bijdragen aan het verbeteren dan moet je feedback geven aan de ontiwkkelaars en niet gaan mokken op GoT (= Nederlandstalig, dus als je hier klaagt zullen ontwikkelaars er waarschijnlijk nooit achterkomen).

Verder zullen julie vast wel gelijk hebben dat PHP5 niet alle voor de hand liggende nieuwe features heeft geimplementeerd , ben nog maar net met PHP begonnen en kan daar niet over oordelen.

[.oisyn]

-Larz- schreef op 29 september 2004 @ 19:24:
Aan de ontwikkelingen in de politiek kun je zelf elke 4 jaar een sturing geven. Verder kun je je kritiek op de politiek via allerlei wegen laten doorluiden in Den Haag.
(En voordat iedereen gaat zeuren dat de politiek toch niet luistert naar jou alleen: je bent niet alleen en de politiek moet ook rekening houden met anderen.)

Net als dat je je stem kunt laten horen aan de PHP devvers. Of ze er wat mee doen is een tweede, net als in de politiek. Fijn dat je even de argumentatie van mijn analogie geeft

NoFI, maar als je echt wilt bijdragen aan het verbeteren dan moet je feedback geven aan de ontiwkkelaars en niet gaan mokken op GoT (= Nederlandstalig, dus als je hier klaagt zullen ontwikkelaars er waarschijnlijk nooit achterkomen).

Ten eerste weet jij helemaal niet wat er verder door ons aan feedback wordt gegeven aan het PHP team, ten tweede betekent dat nog niet dat je hier vervolgens niet mag ranten op PHP. Het "je mag niet zeuren want die mensen werken er in hun vrije tijd aan en anders ga je maar meehelpen" slaat gewoon nergens op. Ik ben het niet eens met de manier waarop de taal PHP in elkaar zit, en aangezien we nog altijd de vrijheid van meningsuiting hebben hier in nederland mag ik (of wie dan ook) dat ook uiten waar ik dat gepast vind. Op dit moment is dat GoT.

[Olaf van der Spek]

.oisyn schreef op 29 september 2004 @ 18:58:
Daarnaast blijft de variable scope nog altijd bagger, en aan het ranzige type juggling moeten ze ook eens werken. Vertel mij eens, waarom is "blaat" hetzelfde als 0?

Ik dacht er laatst nog aan. Ik ben C++ gewend, maar is het type systeem van PHP nu echt eenvoudiger/makkelijker dan C++?
De meeste code die ik zie staat nu vol met type-checks, terwijl die normaal eenvoudig en simpel door de compiler worden afgehandeld.

[.oisyn]

Het is makkelijker in de zin dat getallen in integers automatisch geconverteert worden, en zo kun je dus user input (wat altijd een string is) bewerken als getallen. Het is echter krom dat een string dat geen getal is probleemloos naar een (int)0 wordt omgezet, waardoor de volgende code "FOUT!" output:

PHP:

if ("blaat" == 0)
    echo "FOUT!";

Imho zou je bij zo'n statement niet alleen een domme automatische conversie moeten doen, maar eerst kijken of "blaat" wel daadwerkelijk naar een int te converteren is. Als dat niet zo is dan zou ie gewoon false moeten geven.

[elevator]

Dat is vergelijkbaar met dat:

PHP:

if( NULL == 0) { echo "Fout!"; }

ook Fout! oplevert, maar volgens mij kan je beide oplossen door:

PHP:

if( NULL === 0) { echo "Fout"; }
if( "blaat" === 0) { echo "Fout"; }

te gebruiken?

[.oisyn]

Duh, maar dat werkt dan niet meer als "blaat" de string "0" was geweest, terwijl je wil dat dat wel true oplevert. Met constante waarden is het een beetje loos, maar stel dat je een variabele $blaat had gehad, en een andere variabele $melp, die je met elkaar wilt vergelijken. Als $blaat een niet-numerieke string is, en $melp een int of float gelijk aan 0, dan geeft dat dus mooi true, terwijl ze geenszins gelijk aan elkaar zijn.

[ Voor 3% gewijzigd door .oisyn op 29-09-2004 21:44 ]

[elevator]

Het zou alleen een 'true' geven als $melp dan 0 is, in andere gevallen niet lijkt me?

Ik vind het overigens ook geen mooi systeem maar het is toch enigszins verbonden aan het loosetyped zijn van php wat ook weer het gemakkelijke eraan is

[.oisyn]

Jaha, het is ook handig dat je een string met een int kunt vergelijken, maar het is gewoon dom dat een string dat geen int is vergeleken met een int die 0 is true oplevert. Of vind je dat normaal gedrag?

[elevator]

Een conversie van een string naar een int levert altijd 0 op - als je er van uit gaat dat PHP 'onderhuids' die conversie van int->string doet levert het een 0 op en is het dus aanvaardbaar.

[.oisyn]

En die hele filosofie klopt dus niet! Een niet-numerieke string converteren naar int is niet 0, het is een niet-gedefinieerde waarde. Waarom zou het 0 moeten zijn? En waarom dan geen -1 (ik zeg maar wat). De meeste talen gooien een exception of zetten een error bit als je een string naar int probeert te converteren terwijl dat niet kan. "0" of "000" of iets in die trant kan naar 0 omgezet worden, "blaat" niet. En nee, ik vind het dus niet aanvaardbaar, je vergelijkt een string met een int, dan moet er gekeken worden of die string wel geconverteerd kan worden naar een int ipv domweg maar 0 te gebruiken als het niet converteerbaar is.

[elevator]

Ik ben het met je eens dat het geven van een exceptie mooier zou zijn hoor, echter bij een taal die geen excepties kent is dat niet mogelijk

Bij impliciete conversie kan je dus ook niet een error-code teruggeven, en als je dan naar de standaard functies van bv. Delphi of C kijkt (Val() of atoi() ) dan zie je dat die ook een 0 terug geven bij een mislukt conversie - het is dan ook wel degelijk standaard gedrag en dus ook anvaardbaar.

[.oisyn]

Nee, nu heb je het over een expliciete cast. Als ik (int)$blaat doe vind ik het niet erg dat ie 0 terug geeft, ik cast expliciet dus ik kan ook expliciet controleren met bijvoorbeeld is_numeric. De == operator werkt echter op een string en op een int. Het is de operator die cast, en het kan dus ook de operator zijn die de controle doet.

in pseudocode:

C++:

bool operator == (string s, int i)
{
    if (!is_numeric (s))
        return false;
    return (int)s == i;
}

Dat is prima te implementeren, en dát is wat ik aanvaardbaar vindt. Javascript kan het toch ook, om maar een voorbeeld te noemen?

[elevator]

Daar zit wat in inderdaad

[ Voor 6% gewijzigd door elevator op 29-09-2004 22:24 ]

[Olaf van der Spek]

.oisyn schreef op 29 september 2004 @ 21:31:
Het is makkelijker in de zin dat getallen in integers automatisch geconverteert worden, en zo kun je dus user input (wat altijd een string is) bewerken als getallen.

Maar wordt voor die eenvoud niet erg veel opgeofferd?
En de input moet toch gechecked worden, hoe moeilijk is het om het daar gelijk te converteren?