JeuWeb Créez votre jeu par navigateur !

Tho · 17-02-2010, 07:16 PM

Bonsoir

J'ai créé un tuto sur le wiki, j'aimerais savoir ce que vous en pensez. A vos critiques !

(lien)

php_addict · 17-02-2010, 08:35 PM

salut

merci pour le tuto Wink

une toute toute toute toute petite remarque: pour ceux qui ne connaisse pas bien l'url rewriting le code du .htaccess de ton exemple peut paraitre tres obscure...j'avoue que j'ai du mal avec la syntaxe des fichiers .htaccess .

Etant donné que ton tuto porte principalement sur le .htaccess n'est il pas une bonne idée que de détailler d'avantage le paragraphe "Empêcher l'accès à la partie privée" ?

en tout cas merci pour ce tuto, faut que j'en fasse moi aussi ;-)

a+

Tho · 17-02-2010, 08:55 PM

Les règles de rewrite se basent sur les regex, donc niveau syntaxe, c'est sur ça qu'il faut se renseigner.
Après, le .htaccess peut servir à des tas de choses, mais comme je le dis dans le tuto, je ne suis pas là pour faire un cours sur le code apache. Mais je penserais à ajouter quelques explications néanmoins, il est vrai que cette partie, c'est un peu du travail prémâché Smile

My Hotel · (Modification du message : 17-02-2010, 08:59 PM par My Hotel.)

C'est pas mal pour les débutants qui pensent rarement à faire ça. Bon, ça reste assez simple mais c'est un bon début, mais ton dossier "web" en gros c'est l'équivalent de public_html, non? Tu devrais le préciser...

Voilà bye, et merci de la contrib' Wink

Tho · 17-02-2010, 09:04 PM

Chez certains hébergeurs, tu n'as pas de dossier public_html. Mais ça reste facilement compréhensible, puisque j'utilise également le nom "public" pour ce dossier ^^

**Sephi-Chan** · (Modification du message : 18-02-2010, 07:34 PM par Sephi-Chan.)

Merci pour la contribution. Ce genre de structures est bien pratique quand on commence à développer.

Maintenant, cette architecture a un point faible capital : le système de rendu est extrêmement pauvre. Je m'explique.

Déjà, on voit que le rendu des erreurs est sommaire : si l'on veut afficher un message qui indique que la page demandée n'existe pas ou que l'accès y est interdit, c'est mort.

Pour résoudre ça, il faudrait plutôt regarder du côté des exceptions. Le code inclus alors devra lancer une exception (ForbiddenAccessError, par exemple) que le simili-contrôleur que tu proposes gérera (en rendant une vue appropriée).

Ensuite, si l'on utilise la technique d'inclusions des parties hautes et basses, on a aucune flexibilité.

Le jour où l'on veut rendre autre chose que du HTML, c'est mort. Ce genre de cas arrive très vite : si on utilise un peu d'Ajax, rendre du XML, du JSON ou même du Javascript brut est impossible (sans même parler de rendre le MimeType qui convient).

De plus, si on souhaite changer la partie haute ou basse selon la page, le code se complique et perd en souplesse. De même si on veut ne pas les rendre du tout (cf. exemple d'Ajax si tu mets le bazar <html><head>... dans ces parties).

Pour ce dernier problème, je pense que le système est à revoir en profondeur (en s'inspirant d'un modèle MVC fiable ?).

En somme, c'est très bien pour faire un petit site comme ça, mais inadapté à un site de qualité.

Sephi-Chan

Tho · 19-02-2010, 12:34 PM

(18-02-2010, 07:33 PM)Sephi-Chan a écrit : Déjà, on voit que le rendu des erreurs est sommaire : si l'on veut afficher un message qui indique que la page demandée n'existe pas ou que l'accès y est interdit, c'est mort.

Pour résoudre ça, il faudrait plutôt regarder du côté des exceptions. Le code inclus alors devra lancer une exception (ForbiddenAccessError, par exemple) que le simili-contrôleur que tu proposes gérera (en rendant une vue appropriée).

Dans le cas d'une erreur http, un petit header('HTTP 1.0 500 Forbidden'); et le tour est joué Smile

Bien sûr, dans le cas d'une erreur 404, il faudrait gérer ça via le .htaccess, mais ce n'est pas forcément compliqué à gérer.
Pour les erreurs perso, on peut toujours gérer avec les exceptions, il n'y a aucun problème avec ça...

Je ne vois vraiment pas en quoi "le rendu des erreurs est sommaire", dans les deux méthodes montrées, il est possible d'afficher n'importe quelle erreur, de la personnaliser comme il convient.

(18-02-2010, 07:33 PM)Sephi-Chan a écrit : Ensuite, si l'on utilise la technique d'inclusions des parties hautes et basses, on a aucune flexibilité.

Le jour où l'on veut rendre autre chose que du HTML, c'est mort. Ce genre de cas arrive très vite : si on utilise un peu d'Ajax, rendre du XML, du JSON ou même du Javascript brut est impossible (sans même parler de rendre le MimeType qui convient).

De plus, si on souhaite changer la partie haute ou basse selon la page, le code se complique et perd en souplesse. De même si on veut ne pas les rendre du tout (cf. exemple d'Ajax si tu mets le bazar <html><head>... dans ces parties).

Je suis parfaitement d'accord que la technique d'inclusion des parties hautes et basses est très faible, mais je l'ai présentée car beaucoup de débutants l'utilisent. Tu as parfaitement raison sur ce point, cependant. Smile

(18-02-2010, 07:33 PM)Sephi-Chan a écrit : Pour ce dernier problème, je pense que le système est à revoir en profondeur (en s'inspirant d'un modèle MVC fiable ?).

Si je n'ai pas parlé de MVC, c'est parce que je déteste cette structure. C'est d'ailleurs l'une des raisons pour laquelle je n'aime pas trop les frameworks, ils utilisent presque tous cette structure (bien que certains permettent d'utiliser leurs composants indépendamment, cf Zend). MVC n'est pas forcément la solution fiable, car mal utilisée, elle peut se révéler très faible elle aussi.

**Sephi-Chan** · 19-02-2010, 01:13 PM

(19-02-2010, 12:34 PM)Tho a écrit : Dans le cas d'une erreur http, un petit header('HTTP 1.0 500 Forbidden'); et le tour est joué Bien sûr, dans le cas d'une erreur 404, il faudrait gérer ça via le .htaccess, mais ce n'est pas forcément compliqué à gérer.
Pour les erreurs perso, on peut toujours gérer avec les exceptions, il n'y a aucun problème avec ça...

Je ne vois vraiment pas en quoi "le rendu des erreurs est sommaire", dans les deux méthodes montrées, il est possible d'afficher n'importe quelle erreur, de la personnaliser comme il convient.

C'est sommaire car c'est au développeur de s'arranger pour que ça marche à différents endroits de l'application : dans le .htaccess, le script d'inclusion et dans les page incluses. Aucune uniformité, il faut vérifier à plusieurs endroits, impossible de faire des tests d'intégrations fiables, donc difficulté de maintenance.

(19-02-2010, 12:34 PM)Tho a écrit : Je suis parfaitement d'accord que la technique d'inclusion des parties hautes et basses est très faible, mais je l'ai présentée car beaucoup de débutants l'utilisent. Tu as parfaitement raison sur ce point, cependant.

C'est honnête de le reconnaître. Mais en fait l'autre technique est à peine mieux. Je te montrerai en quoi si tu me montre une portion de vrai code qui l'emploie.

(19-02-2010, 12:34 PM)Tho a écrit :
(18-02-2010, 07:33 PM)Sephi-Chan a écrit : Pour ce dernier problème, je pense que le système est à revoir en profondeur (en s'inspirant d'un modèle MVC fiable ?).

Si je n'ai pas parlé de MVC, c'est parce que je déteste cette structure. C'est d'ailleurs l'une des raisons pour laquelle je n'aime pas trop les frameworks, ils utilisent presque tous cette structure (bien que certains permettent d'utiliser leurs composants indépendamment, cf Zend). MVC n'est pas forcément la solution fiable, car mal utilisée, elle peut se révéler très faible elle aussi.

Ne penses-tu pas que si la majorité des frameworks l'implémentent, c'est que cette architecture a très largement fait ses preuves (c'est d'ailleurs le propre des design pattern) ?

(19-02-2010, 12:34 PM)Tho a écrit : MVC n'est pas forcément la solution fiable, car mal utilisée, elle peut se révéler très faible elle aussi.

Développe ?

En tout cas, je suis content que tu restes ouvert à la discussion. Ton discours me fait beaucoup penser au miens il y a quelques années, jusqu'à ce que je me rende compte que j'étais dans l'erreur à vouloir réinventer des roues (carrées)... Puis un tour en entreprise a fini de me transformer (Power Rangers, transformation !!).

Sephi-Chan

Tho · 19-02-2010, 05:51 PM

(19-02-2010, 01:13 PM)Sephi-Chan a écrit : C'est sommaire car c'est au développeur de s'arranger pour que ça marche à différents endroits de l'application : dans le .htaccess, le script d'inclusion et dans les page incluses. Aucune uniformité, il faut vérifier à plusieurs endroits, impossible de faire des tests d'intégrations fiables, donc difficulté de maintenance.

Je dois dire que je vois mal comment le développeur peut ne pas vérifier à plusieurs endroits de son appli s'il n'y a pas des erreurs d'accès, et autres petites choses à vérifier un peu partout. Les erreurs d'application sont gérées en dev, mais en production, elles sont généralement tronquées (si mes infos sont bonnes). Pour la maintenance, ça ne m'a jamais vraiment posé de problème, si le log de l'erreur a enregistré toutes les traces.. Smile

(19-02-2010, 01:13 PM)Sephi-Chan a écrit : C'est honnête de le reconnaître. Mais en fait l'autre technique est à peine mieux. Je te montrerai en quoi si tu me montre une portion de vrai code qui l'emploie.

Genre un petit système de news ? (archi simplifié, et je ne met pas les structures des classes)

Code PHP :
<?php

if ($_GET["action"] == NewsManager::ACTION_DELETE)

  if (isset($_SESSION["user"]) && $_SESSION["user"] instanceof User && $_SESSION["user"]["rang"] == User::ADMIN && NewsManager::exists($_GET["news_id"]))

    NewsManager::delete($_GET["news_id"]);

  else

    header("Location: erreur-500.html");

else if (...)

...

**Sephi-Chan** · 19-02-2010, 06:33 PM

(19-02-2010, 05:51 PM)Tho a écrit : Je dois dire que je vois mal comment le développeur peut ne pas vérifier à plusieurs endroits de son appli s'il n'y a pas des erreurs d'accès, et autres petites choses à vérifier un peu partout. Les erreurs d'application sont gérées en dev, mais en production, elles sont généralement tronquées (si mes infos sont bonnes). Pour la maintenance, ça ne m'a jamais vraiment posé de problème, si le log de l'erreur a enregistré toutes les traces..

Regarde l'exemple qui suit. C'est bidon à lire et ça te permettra probablement de cerner les intérêts d'une gestion robuste des erreurs.



## application_controller.rb

class ApplicationController < ActionController::Base

  rescue_from User::NotAuthorized, :with => :user_not_authorized

    

  private

  def user_not_authorized

    flash[:error] = "You don't have access to this section."

    redirect_to :back

  end

end



## clients_controller.rb

class ClientsController < ApplicationController

  # Check that the user has the right authorization to access clients.

  before_filter :check_authorization

  

  # Note how the actions don't have to worry about all the auth stuff.

  def edit

    @client = Client.find(params[:id])

  end

  

  private

  # If the user is not authorized, just throw the exception.

  def check_authorization

    raise User::NotAuthorized unless current_user.admin?

  end

end

(19-02-2010, 05:51 PM)Tho a écrit : Genre un petit système de news ? (archi simplifié, et je ne met pas les structures des classes)

Code PHP :
<?php

if ($_GET["action"] == NewsManager::ACTION_DELETE)

  if (isset($_SESSION["user"]) && $_SESSION["user"] instanceof User && $_SESSION["user"]["rang"] == User::ADMIN && NewsManager::exists($_GET["news_id"]))

    NewsManager::delete($_GET["news_id"]);

  else

    header("Location: erreur-500.html");

else if (...)

...