J'vois pas trop votre histoire de POO pour des logs en fait ^^' J'suis preneur d'un exemple

Typiquement, pour essayer de donner un exemple concret, j'ai développé récemment une API webservice en "full" objet. Je dis "full" avec des pincettes car avec PHP, on se retrouve souvent avec des comportements qui singent Java ou C++.

Cela étant, le principe est relativement simple :
- J'ai un contrôleur frontal qui reçoit toutes les requêtes clients et qui dispatche vers les diverses actions à effectuer
- L'action selectionnée va construire la réponse
- J'évite les branchements interminables de if/else pour gérer tous les cas de figure possibles : quand ça ne va pas, je throw et c'est le contrôleur qui catch tout et qui log

Le deuxième avantage réside dans l'héritage et l'abstraction de classe : toutes mes classes d'actions dérivent de la classe mère abstraite "Action", et je peux ainsi unifier le comportement des actions (et par la même des actions à implémenter dans le futur).

Donc pour conclure, si le projet de parayes tend à évoluer régulièrement dans l'avenir, l'objet peut très bien être un choix judicieux. Dans le cas contraire, la méthode habituelle suffira largement et l'objet pourra vite devenir une entrave plutôt qu'un atout  


Panday

Edit: Je rajouterai quand même pour appuyer the lsd que permettre des appels systèmes ou l'execution de shell est vraiment une très mauvaise idée, à moins d'y être contraint.

Je te confirme que PHP OO est laborieux et vraiment irritant à écrire.
En ce qui concerne l'utilisation de logs, il t'appartient de décider si tu en as besoin ou non.

Pour finir, je n'irai pas jusqu'à déconseiller complètement l'objet en PHP, mais réfléchis bien à ton objectif et vois si cela est vraiment nécessaire.

Si j'ai un dernier petit conseil à te donner, ça concerne les bases de données.
J'ignore si tu comptes utiliser une DB pour ton projet, mais je te conseille vivement d'utiliser PDO ou encore ADODB (de l'objet   ) afin de protéger efficacement tes requêtes contre les SQL injections (avec les requêtes préparées).


Panday

Bonjour,

Le tout n'est pas codé en Objet, c'est un chois personnel. Mais si vous avez des indications sur un réel besoin de l'utilisation d'Objet sur ce genre de projet. Je suis tout ouie

Je reprend ce point pour répondre à ta demande.

L'intérêt majeur de développer en objet pourrait être une gestion fine des exceptions plutôt que de simples booléens en retour de tes fonctions.
L'idée principale consiste à dériver la classe "Exception" pour en faire un certain nombre personnalisées, ce qui offre notamment la possibilité de se passer du "exit()" ou du "die()" et de préferer l'utilisation des try/catch.

Cela peut prendre tout son sens si tu envisages de mettre en place un système de logs (ou d'utiliser simplement la fonction "error_log()" de php).

Néanmoins, le php objet reste assez loin d'autres langages objets en terme de flexibilité et sa mise en place n'est pas "forcément" justifiée.


Panday

Le plus simple, c'est de factoriser par 42.

Bon courage

Si pour toi "changer d'IP" c'est passer au travers d'un proxy, il existe toujours un champs dans le protocole HTTP qui s'appelle "X-Forwarded-For" (standardisé à reculons par l'IETF sur demande des developpeurs de Squid). Ce champs contient ton IP d'origine.

Seul un VPN te guarantira de sortir avec une IP différente (celle du serveur VPN à priori).

D'autre part, je suppose que Facebook possède une belle grosse liste de proxy, il leur suffit donc de comparer.

Un DOS par ICMP ? J'attends de voir, mais j'ai quelques doutes sur l'efficacité.

Je te renvois à ce lien pour les détails, naturellement je suis d'accord avec toi, il faut un contexte LAN étant donné que sur internet on ne routera pas un broadcast.

Je disais simplement ça pour illustrer un exemple un peu grossi.

Heu, n'exagérons pas. C'est juste un truc qui permet de savoir si un serveur est joignable.

Encore une fois, c'est pour illustrer le fait que l'on tape sur un hôte distant afin d'en tirer une information (présence/absence).

[depuis]

Un scan, pour faire simple, est l'établissement successif et rapide de connexions tcp (ou l'envoi de trames udp) sur différents ports afin de voir de quelle manière le serveur distant répond, si toutefois il répond. Cela permet de connaitre les ports ouverts, les services qui tournent derrière, les versions des services en question, et tout un tas d'autres informations sur lesquelles je ne pourrais m'attarder sans pondre une espèce de roman imbuvable  .

Note au passage qu'un simple ping est déjà en lui-même un scan, strictement inoffensif certes, sauf à très haute échelle où là ça peut carrément devenir un DoS (déni de service, on bouche le tuyau  ). Et ce n'est pas interdit de ping le serveur de NC, ce qui devient gênant, c'est de le ping 100 fois par secondes pendant un certain temps.

Pour résumer, ce qui est entendu par scan dans ce contexte, c'est l'établissement successif d'un grand nombre de connexions depuis ton pc vers le serveur de NC, quelle qu'en soit la raison.

L'utilisation d'outils comme firebug est complètement autorisé et n'entre pas dans la catégorie d'un scan, à aucun moment, puisque tu exploites une ressource qui se trouve déjà chez toi.

Je me permettrai de citer Ruby comme alternative à PHP et PostgreSQL relativement à MySQL (si on désire rester dans du libre).
D'autre part, on peut très bien éviter de réinventer la roue et utiliser un framework : en l'occurrence si on reste sur l'idée de Ruby, on peut très bien utiliser Rails, son framework (mais ce n'est pas le seul évidemment).

Ruby on Rails est tout à fait indiqué pour un site de vente en ligne, avec une très bonne gestion du MVC (Model-View-Controller), relativement intuitif.

Ruby peut paraître un poil exotique à première vue mais on s'y fait rapidement.

Et pour répondre à Neroptik, oui ça m'a légèrement picoté les yeux, mais bon rien n'empêche un webmaster de générer du texte pur, sans structure HTML 

Je peux me tromper, mais un socket va effectivement "tirer une corde à linge" de niveau 4 (couche transport de la pile tcp/ip), et l'applicatif passera dessus dans un second temps. Et encore une fois en théorie, ça supporte indifférement tcp et udp. Donc j'aurai tendance à confirmer, Spaulding.

En effet, Java est un bon point de départ, ses packages étant assez bien foutus.
Renseigne toi sur les gestions de buffer, queues FIFO/LIFO et sur la création de protocoles personnels pour communiquer entre un client et un serveur (création d'un petit chat type IRC, l'idéal pour commencer).

Si tu as besoin d'un coup de main, tu peux toujours me contacter par mp.


Cdlt,

Panday.