PHP EVENTS - COMMENT RENDRE PHP ÉVENEMENTIEL COTE SERVER
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
-
5 oct. 2005 à 09:32
Zzarbi974 Messages postés 8 Date d'inscription lundi 7 juillet 2003 Statut Membre Dernière intervention 21 novembre 2006 - 16 oct. 2006 à 12:23
Zzarbi974 Messages postés 8 Date d'inscription lundi 7 juillet 2003 Statut Membre Dernière intervention 21 novembre 2006 - 16 oct. 2006 à 12:23
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/34089-php-events-comment-rendre-php-evenementiel-cote-server
https://codes-sources.commentcamarche.net/source/34089-php-events-comment-rendre-php-evenementiel-cote-server
16 oct. 2006 à 12:23
Sinon oui le code est très clair, mais je ne vois pas l'utilisé d'un tel code, je le trouve beaucoup trop lourd à implémenter.
Moi je pense qu'il vaut mieux laisser la structure ".net" pour du ".net" (On va pas faire du vin avec des pommes !).
Ensuite pour le reste du débat je suis plustôt d'accord avec MALALAM, je pense que PHP n'est plus depuis longtemps un langage amateur... C'est une image que je déteste. Encore aujourd'hui dans les écoles d'ingénieur (j'y suis encore ^^) on nous le dit souvent que PHP n'arrive pas à la cheville de .Net. Je ne dit pas que PHP est plus puissant que .Net je dit juste que c'est différent, mais équivalent, chacun est meilleur dans un domaine. Personnelment je pense que .Net est beaucoup adapté pour les solutions Intranet...
Cependant j'aimerais bien voir les résultats de ces benchs si ça ce fait :)
15 oct. 2005 à 02:20
Pure théorie, admettons les benchmarks, certe c'est un résultat concret. Encore faut-il comparer ce qui est comparable et de la bonne manière. Comparer un compilé à de l'interprété ou a du semi interprété, on connait déjà l'ordre des gagnants même en prenant le meilleur d'un côté et le plus mauvais de l'autre. Revenons à des choses comparables et comparons les de la bonne façon.
Admettons X et Y deux langages de la même catégorie et deux programmes identique dans chaque langage.
X s'exécute en trois secondes et Y en 6 secondes. VERDICT ?
Continuons, X consomme 20 Mega de RAM, Y consomme 2 Mega de RAM.
Maintenant admettons que chaque programme soit lancé 100 fois simultanément sur une machine qui a 256 Mo de RAM.
X fait tomber sa machine alors que Y s'éxécute sans soucis.
X est il le plus rapide dans ce cas ? (ce qui revient à ton calcul de charge coucou747)
Dans le cadre du WEB notamment, ce type d'exemple est bel et bien concret. Et un minimum, je crois, a prendre en considération au moins dans les benchmark si ça doit faire fois du meilleur langage pour le web, qu'on donne des résultats réels basés sur des applications concrètes.
Je serai de la partie Coucou747 pour te filé un de mes serveurs et qu'on test tout ça ensemble. Franchement ça me tripperais bien de connaitre les performances de chaque langage dans cet exemple et je pense qu'il pourrait même y avoir des surprises. Mais j'ai que deux bi-xeon sous la main et il ne sont pas optimisé pour ce genre de choses.
Mais je pense qu'au de là encore de ceci, chaque chose à son application, son mode de travail etc. On peut préféré maniabilité à performance, joué la carte de l'adaptabilité plutot qu'une autre etc. on peut préféré du php parce qu'on le met tous les jours à jour plutot que de compiler du C en cgi a chaque fois et ainsi de suite.
Chaque langage qui vit aujourd'hui vit parce qu'il a des atouts. A mediter.
Pour relancé d'une meilleur manière le débat, J'ai pas entendu parler de Python ou de Ruby avec Ruby On Rails très bon framework web pour ceux qui adore l'objet à découvrir absolument.
14 oct. 2005 à 23:33
14 oct. 2005 à 14:28
14 oct. 2005 à 12:01
Un bench C contre php, par contre, est totalement stupide, à mon avis. Je ne vois pas quel rôle il joue?
Et il est logique, en plus. La compilation joue sans doute un tout petit rôle dans cette différence...hmm?
Bref, comparer C et PHP...pourquoi ne pas comparer un basic et un asm aussi.
13 oct. 2005 à 18:41
php = 300 * plus lent que le C
mais j'ai fais ces benchs uniquement pour tester la vitesse de calculs, j'ai jamais testé la charge d'un CGI en C et d'un php sur un serveur... ça serait interessant...
Pour ceux qui ont des benchs à me proposer, ou qui programment en ASP, VB ou C#, et qui veulent me proposer de faire des benchs, je suis prenneur... mais à l'adresse suivante : coucou747@hotmail.com
Je n'ai posté ce bench uniquement dans le but de voir moins de conneries ! On est ici pour juger de cette source, pas du php ! Si on n'est la, c'est pour en faire, pas pour en défaire ! sens constructif !
On pourrait pas arréter les trols géants ?
13 oct. 2005 à 12:24
Il faut être sérieux et avoir un peut de jujote chez microsoft. SI MSN par exemple que je connait assez bien puisque je travail de temps en temps avec eux, peux s'offrir ASP, les serveurs SQL, 2003 etc. OK, parce que MSN draine des millions derrière lui.
Je demande à tout le monde aujourd'hui de me cité de quelle manière une société qui ouvre ses portes et créer un site qui n'a encore aucun impacte, comment peut elle s'offrir la techologie microsoft !
PHP pour moi c'est plus qu'un code presque parfait et qui ses défaut comme tous les code, mais ça met du pain dans mon assiette ce qui ne serait possible avec ASP
je crois que ya rien à ajouter la dessus
13 oct. 2005 à 11:19
Je ne dis pas que php est LA solution parfaitement solide...mais c'est faux que de dire qu'on ne peut pas développer un site à haut trafic en php. J'ai travaillé l'année dernière sur un portail distribué (chaque portail hebérgé, qui plus est, par nos soins...sur bien peu de serveurs...) à de gros clients, comme Chrysler, Quelle (La Redoute version Allemande), Playboy, Siemens, Adidas...et j'en passe. Ce sont des portails non pas de consultation, mais de création de produits personnalisés, avec php donc, une petite interface en flash, une en php, et remplacées à terme par une solution java plus puissante question possibilités graphiques (une applet en fait, en standalone), et par un module en standalone développé en C# (toujours pour l'éditeur graphique). PHP gère toute la base de données, donc les produits, et les utilisateurs, les fichiers xml templates pour les produits, les dialogues entre les différents serveurs via SOAP en général, et avec les différentes applications (le java, le C#, le Flash, quoi). Et ADServer, développé à l'extérieur (si vous connaissez) et modifié largement en interne (bah oui, il y a pas mal d'incohérence sur cette solution), pour le côté traces divers.
Quant aux charges...elles étaient parfois énormes, pour certains sites (moins pour d'autres évidemment, il y avait aussi de petits clients).
Eh bien ça tenait parfaitement le coup. C'était plutôt rapide, même en manipulant plusieurs dizaines de Mo d'images pour plusieurs clients différents( beaucoup de clients) au même moment, sur le même serveur (là je parle par exemple de l'éditeur php).
Bref, ce que j'en pense moi : si on code bien, proprement, de façon structuré, que tout a été bien pensé dès le départ, php s'en sort à merveille. Que les pro .net le veuillent ou non ;-)
Quant à penser que php ne sera jamais une solution professionnelle (voire même n'en est pas déjà une)...je t'invite à lire la presse spécialisée, à ce sujet, tu verras que les choses ont largement changé ces derniers temps, largement évolué, en faveur de solutions pro entièrement (enfin entièrement...ça reste des frameworks) php.
13 oct. 2005 à 10:53
Maintenant que Zend propose sa solution d'optimisation, c'est un peu faible car le PHP n'est pas Zend Optimizer. DotNET ou Java ne vont pas fournir une version lite et une version core de leur modéle d'execution. Ils communiquent sur la performance. C'est donc pénalisant pour le language PHP, car même si côté solutions il permet de faire de grandes choses, il restera une solution non professionnelle.
13 oct. 2005 à 10:27
Que php puisse être plus optimisé, sans doute...comme tout :-)
Q'il y ait une histoire de sous, sans doute aussi; monde libre ne veut pas dire que tous ceux qui y vivent doivent crever la dalle. Faut bien vivre, justement, si on veut être libre. Et puis omment jeter la pierre à Zend, quand ils nous offre un langage puissant, qui s'améliore vite, qui est en perpétuelle évolution, et le tout entièrement gratuitement? Ils ont fait un bon boulot côté db aussi, en plus. Bref, ils ont mit à la portée de tous un outil puissant, simple, et qui peut-être utilisé entièrement gratuitement.
Alors se plaindre d'un Zend optimizer payant, je trouve ça franchement poussé...;-)
Zend met juste à disposition de quoi concurrencer les autres plateformes de développement traditionnellement plus utilisées que php. Php a longtemps été vu comme un langage de script pour petits jeunes, pas très sérieux.
Php a énormément évolué. Et réellement, un gros site créé en php (bien codé...) est souvent bien plus rapide que l'équivalent sous .net (je parle d'expérience). Quant à J2EE...disons que je trouve ça un peu complexe et lourd.
La rapidité...bah comme je le dis, je n'ai jamais eu vraiment à me plaindre de php, si on le compare à d'autres outils, dans le cadre d'un gros développement web. Maintenant, il y a des progrès à faire, c'est clair.
Mais il y en a pas mal chez .net aussi...après tout :-)
13 oct. 2005 à 10:03
Ce qui me fait penser que c'est un peu mort niveau technologie le PHP sature trop vite, malgré sa simplicité de programmation. Héhé, si on se lance dans un débat, je vous demanderais une chose :
Pk Zend qui publie PHP (le monde libre et tout la tralala) publie un optimizer du PHP permettant de le compiler et de plus necessiter de parser les scripts ? En gros, c une histoire d'argent, mais le PHP pourrais être beaucoup plus optimisé. C'est juste une question de sous.
Bizare d'entendre ça dans le monde libre ?!?
Sur ce, qu'en pensez-vous ?
12 oct. 2005 à 13:58
sous php4 avec plein de libs de chargées...
bon, java et dotnet seraient seulement trois fois plus lent que le C ??? java est pseudo-compilé, mais de la à être si rapide... dotnet, j'en sais rien...
12 oct. 2005 à 11:14
Le php est un language de prog comme tout un autre avec des avantages et des inconvénients. Il faut bien prendre en compte tout cela avant de se lancer dans un projet.
Comme tout language de programmation, ses points forts se trouvent au niveau algorithmique. Je pense qu'il ne faut pas dénigrer l'objet sous prétexte que le PHP est lent. Pour moi c'est deux choses diférentes.
Le temps de la programmation linéaire est révolu, on voit aujourd'hui une multitude d'os sous PHP, comme Zend, Mambo, des ERP ou CRM, ainsi que surement d'autres systémes. Le nombre de lignes de codes varie entre 50 000 et 100 000 lignes, dépassant dans certains cas les 200 000 lignes.
On ne peut pas dans ce cas apréhender ce genre de systéme en linéaire, et encore moins le maintenir. Si le PHP s'avére trop lent faut se tourner vers des solutions plus rapides Java/DotNet. Au passage que vous le vouliez ou pas, le DotNET est 100 fois plus rapide en execution que le PHP4 (ce n'est pas moi qui le dit, c'est les benchmark).
Ainsi, dans le cadre d'interfaces d'administration à bas trafic, si vous choisisez le PHP, utilisez l'objet. Si le PHP s'avére lent, changez de technologie ou utilisez un optimisateur. L'objet de nos jour n'est plus un choix (à méditer).
Maintenant concernant ma source, j'ai trouvé des éléments semblables sur www.blueshoes.org. A vous de voir, mais la surcharge evenementielle n'est prise en compte que sur mes classes. Souhaitez-vous des mises à jour des classes en fonction de la progression que je fais ou pas ? J'aimerais seulement savoir si c'est utile et utilisé par d'autres ...
12 oct. 2005 à 00:30
Il fut un temps ou j'avais appris le basic, j'imagine que ca a changé depuis ;)
11 oct. 2005 à 09:11
Pour tes problèmes existentiels, je compatis. De là est née mon idée, il y a quelques temps, que ce serait pas mal que quelqu'un se mette au développement d'un framework utilisant php, une bdd et du code cgi. Je n'en connais pas encore, mais je pense que ce serait une bonne dée. Si tant est qu'on ne tombe pas dans les lourdeurs habituelles à beaucoup de framework...(en ce moment, je bosse avec xmlrad, et bon...c'est rigolo, mais j'ai de sérieux doutes pour une utilisation online chargée!).
Pour ce qui est du source ici présent, je ne pense pas que le but était de l'implémenter sur de gros sites. Ca ressemble plus à un tuto, et il est joliment fait. Maintenant, il est clair que le tout objet dans un environnement ou les performances sont importantes parce que les charges sont énormes...ça ne se joue pas. Ou peu. Ou en faisant très très attention...(ou en étant très très bon sans doute). Php est un langage très puissant...il le evient peu à peu sur son modèle objet, mais il est aussi par sa puissance "fonctionnelle". Et c'est très bien comme ça! Sur le web, pour le moment, il ne faut pas développer objet pour le plaisir de développer objet, en tous cas pas quand on a ce soucis de performances.
Quant au côté retard de php sur .net...je n'avais pas relevé parce que la dernière fois qu'on a eu le malheur de dire ce que l'on pensait (gentiment), sur .net, on s'est fait censurer ;-) Mais il est clair que je ne suis pas d'accord, pour avoir moi aussi vu ce que donnait php et .net dans un environnement web professionnel. Et à mon sens, il n'y a pas photo. .net c'est bien, c'est rigolo, c'est simple, c'est puissant, mais c'est lent et couteux. Et je ne trouve pas ça joli comme code mais ça, c'est une autre histoire ;-)
10 oct. 2005 à 21:15
Ce problème je pense nécessite un changement de structure en langage et en machine. Pour en revenir à ton commentaire et à d'autres plus haut, code compiler me semble plus qu'obligatoire.
10 oct. 2005 à 21:05
10 oct. 2005 à 20:54
Ceci me laisse pas mal dubitatif.
Je reprends, qu'est ce que je lit, tu sembles vouloir rattraper le sois disant retard de php par rapport à dotnet donc entre autre séparer le html du code php. 3 lignes plus loin je vois :
function OnPost() { echo ' * FORM 1 POSTED !<hr />'; }
Aïe ! C'est déjà le contraire de ce que tu dis.
Deuxièmement pour travaillé sur un très gros site, une chose importante à prendre en considération est la capacité du code à s'exécuter en un minimum de temps et en prenant un minimum de charge sur le serveur. Ce qui est dans la vue d'une société, recherché la meilleur rentabilité et c'est ici que l'on va trouvé des codes qui offriront des avancé technologique importante.
Il y aurait très long à dire sur ce sujet, alors pour rattraper le retard de php face à dotnet en quelques mots. Je ne connais aucun site asp équivalent à php capable de tourner sur le même type de serveur et au même coût !
Je côtoies des société qui travaille avec asp (sans rentrer dans le débat des licences payante etc.) de telles sociétés pour fournir disons 100 000 visites jours en asp ont besoin d'une soixantaine de serveur en load balancing. Ceci représente un coût de fonctionnement non négligeable. Je fourni actuellement 200 000 visiteurs jour et j'ai seulement 2 serveurs en load balancing. Là on touche un point sensible. De même qu'asp est tout objet, faire devenir php tout objet a l'heure actuelle c'est surchargé considérablement ses coût de mise en production sans parlé de pertes direct
(Afficher 40 produits dans une boutique si cela prend deux minutes le client s'en va, google référence pas les pages qui mettent du temps à répondre etc?).
Admettons que chaque objet php est sa connexion SGBD partagée, que chaque élément de l'objet génère sa propre requête pour ses besoins. J'ai fait l'erreur. Arriver à des page qui génère 130 000 requêtes SQL pour générer une page (de stat en BackOffice) en cassant ma structure objet dont j'étais réellement fier j'ai réduit ce nombre de requête à ... 800 avec un temps d'exécution divisé par deux.
Savoir marié puissance de fonctionnement, maniabilité (en mise à jour et évolution), propreté et rapidité n'est pas un art facile. Je pense que tout code sur ce site devrait tendre vers cette optique. Alors déjà bravo pour l'effort d'écriture de codage et de lisibilité de ta source. Maintenant je ne verrai jamais un tel code passé en application sur un de mes sites. Je répondrais simplement trop lourd.
Pour en revenir à l'événementielle et à dissocier php et html. Je pense que supprimer le html du php c'est supprimé le côté dynamique qu'offre le php. J'entends par là par exemple généré un tableau html avec un nombre de cellules variable ne se feras jamais sans mélangé du php et du html. Néanmoins je pense qu'il ai très important de séparer le php du html du moins je dirais de séparateur le code qui va générer les données du code qui va les mettre en forme.
Ensuite pour l'événementielle, php s'exécutant serveur sans liaison avec un autre langage quel qu'il soit c'est tout simplement impossible. Néanmoins j'imagine une optique différente de l'événementiel dans un dialogue serveur / serveur. Prenons un serveur applicatif en back et un serveur frontal qui formate les données, le serveur formatant les données selon le type de données rencontrer génère des événement sur lui-même ou sur le serveur applicatif? à méditer. (Et à savoir ce que vaudrais une telle architecture en terme de fonctionnement)
Aujourd'hui je bute sur des problèmes bien plus existentiel, mon back office n'est plus capable de fournir aucune stat, les calculs saturent la ram du serveur etc.? comment faire quand le code est déjà optimiser à son maximum, les bases déjà éclater, le SQL déjà exporter etc. ?
C'est là qu'on se dit j'arrive au limite du php, même si aujourd'hui je ne m?en passerai pas, il va falloir que j'oublie le BackOffice web et monter un back en Delphi par exemple. Alors pour en revenir à ma première phrase, je trouve ton code chouette mais bien utopique. Voilà.
(En m?excusant de mes énormes fautes d'orthographe (on perd des clients avec ça))
10 oct. 2005 à 08:57
D'ailleurs j'aime beaucoup Perl aussi :-)
8 oct. 2005 à 11:31
Et GTK est postable, et s'utilises en C, en ADA, en C++, en PHP, en PERL, et en d'autres langages... ce n'est pas une librairie propre au php...
Je pensais aussi trouver ici des xmlhttprequest, mais raprocher un langage d'un autre par le style de programmation est une assez bonne idée...
Personellement, je trouves qu'on manque de POO ici, surtout coté javascript.
Les class présentées ici sont pas mal à la fois coté programmation et coté choix de quelle fonctionalitée serait une classe...
Je n'utilises pas PHP5, pour des raisons pratiques (debian n'en a pas fait un pakage sur sa distribution, et comme je possède deux machines debian : un hébergeur et une personelle, je devrais installer un .tar.gz sur les deux, et c'est à la fois long et difficile pour les dépendances...) mais aparement, ici, il faut vraiment avoir php5 pour profiter de tes classes, mais je crois que ça reste un très bon tutorial !
sinon, la seule grosse différence entre compilé et interprété, c'est la vitesse, perl l'a bien montré !
perl vs php : c'est vrai qu'il est plus facile à première vue de programmer en php, mais il existe tellement de modules perl qu'on peut faire ce que l'on veut dans ce langage... alors que le php se limite (généralement) au web (et parfois aux petits scripts mode console qui permettent une coloration des logs ou autres choses dans le genre ^^, et rarement du gtk), le perl, lui, peut aller partout ! Le web sous forme de cgi ou de .pl, mais aussi des applications, des jeux, des robots, des plugins (sous linux, les plugins se font généralement en perl ou en tcl), et évidement, on trouve aussi des "petits" scripts mode console (comme ogg=>mp3 ou mp3=>ogg)...
Enfin voila, il faut arréter de critiquer des langages pour leurs défauts, et plutôt programmer pour leurs fonctionalitées !
raprocher deux langages (comme le fait cette source) par la façon de programmer, est très pratique pour les migrations, et ça mérite d'être applaudit!
7 oct. 2005 à 09:21
Certes, comme toujours. Les requêtes xmlhttp ne changent pas grandchose. la seule "nouveauté" (entre guillemet, parce que c'est une vieille technologie en fait...j'ai trouvé un article remontant à 98 ou 97 je ne sais plus trop), c'est que cela rend les traitements côté serveur plus "dynamiques". On clique sur un bouton et hop, le traitement s'effectue tout de suite sous nos yeux, sans le raffraichissement habituel. C'est ça le dynamisme :-) Après, le côté évènementiel, en effet, ça reste l'affaire d'un langage de script côté client. Normal.
Quant à GTK, voui, c'est très bien, mais ça n'est pas destiné au web. C'est un autre monde. Mais j'aime bien GTK, parce que j'aime bien le php. Et j'aime bien le php parce que c'est un langage réellement puissant, avec plein de fonctionnalités...bien plus que pas mal d'anciens langages compilés (ma référence est les fonctions sur les tableaux...c'est incroyable tout ce que php propose en natif!! Alors que dans nombre -la plupart- d'autres langages, on doit coder soi-même les fonctions offertes par php), même si il reste en général toujours un avantage pour ces derniers quant à la POO. Mais ça vient, ça vient...:-)
Voilà, c'était ma petite ode à php ;-)
6 oct. 2005 à 22:01
PHP ouvre une fenetre comme n'importe qu'elle application. Mais c'est réservé au local.
Euh, je ne m'y connais pas trop en termes techniques, donc reprenez moi si j'utilise mal librairies, événement, ou autre chose... Je ne tend qu'à apprendre.
6 oct. 2005 à 19:27
Mais PHP tant que PHP restera coté serveur, ca limitera pas mal de fonctionnalité, ca c'est sur !
6 oct. 2005 à 18:36
Ce n'est pas le PHP qui gérera lui meme l'événement, mais le javascript, coté client...
6 oct. 2005 à 08:42
FhX => très bien écrit ;-) C'est facile : les requêtes XMLHTTP.
6 oct. 2005 à 01:39
J'entendais par ça : On crée des composants HTML qui une fois validés générent des evenements. Tout cela pour avoir une architecture de programmation proche de celle DOTNET.
Je vais changer le titre.
6 oct. 2005 à 00:18
Mais j'en suis même pas sur...
5 oct. 2005 à 12:48
Je suis d'accord pour les évènements. Je disais juste que lorsqu'on est dans le développement web, on réagit généralement à un titre comme le tien de cette manière : html2phpevents ? Wow, on va pouvoir gérer des évènements comme en js, avec du php? Les onclick, onchange, onselect, onfocus, onblur...? Or, c'est à la limite de la pub mensongère pour moi ;-) On reste côté serveur, et on ne sait que ce qui se passe côté serveur. Donc pas de onfocus, onchange sur des listes...etc. On reste à du traitement de formulaire habituel en php.
N'empêche, je répête au cas où, j'aime beaucoup ton source. Il est joliment codé, bien structuré, plein de bonnes idées, et très simple, en plus. Et fonctionne à merveille :-) C'est presque un début de framework pour créer des sites en formulaires html ;-)
5 oct. 2005 à 10:23
* c'est un tutorial, il permet d'expliquer aux débutants ou autres des techniques de programmation permettant de bien structurer ses codes. J'y ait inséré la notion evenementielle, mais je t'assure ayant fais de l'objet sous d'autres languages, un événement est forcément lancé aprés vérifications, c'est exactement le même principe que sur mon script.
Je tiens à rajoutter que le script est juste un exemple et ce n'est pas un systéme complet. Il à des failles, et vous devrez redevelopper casiment la totalité. C'est juste un exemple pratique.
5 oct. 2005 à 09:32
je commence par les critiques... ;-)
Tu fais de la pub mensongère! Quand j'entends évènementiel, moi, je pense plutôt à js. De l'évènementiel dynamique, quoi. Là, finalement, tu mets juste en forme, avec de la jolie programmation, en tout assistanat (assistannat? heu...) de l'utilisateur de tes classes, ce que tout le monde, ou presque, fait déjà quand il manipule des formulaires en php. Récupérer une valeur, la vérifier, la traiter...(ta partie évènementielle est bien là : on récupère une valeur postée (ou getée ;-) ), on la vérifie (est-elle identique à la précédente), on la traite (oui, ou non, si oui, par quel biais, etc...).
Les compliments : c'est TRES bien commenté, c'est TRES bien codé, et c'es TRES simple d'utilisation. Bref, tes classes sont très jolies, pour ce qui me concerne (je n'ai regardé que la partie php5, mais je n'ai aucun doute sur la partie php4). Et je suis certain que cela va être très utile à beaucoup. Que ce soit pratiquement, ou théoriquement. Formulaire + poo + sessions, tu vas en inspirer plus d'un je pense.
Au passage, en php5, il y a une fonction très pratique : __autoload (), pour éviter les require_once () multiples. Mais il faut modifier un peu les noms de tes fichiers classes.