+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Général (https://jeuweb.org/forumdisplay.php?fid=36)
+--- Forum : Blabla (https://jeuweb.org/forumdisplay.php?fid=42)
+--- Sujet : Un tuto en plus (/showthread.php?tid=4593)
Pages :
1
2
Un tuto en plus - Tho - 17-02-2010
Bonsoir
J'ai créé un tuto sur le wiki, j'aimerais savoir ce que vous en pensez. A vos critiques !
(lien)
RE: Un tuto en plus - php_addict - 17-02-2010
salut
merci pour le tuto
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+
RE: Un tuto en plus - Tho - 17-02-2010
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é
RE: Un tuto en plus - My Hotel - 17-02-2010
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'
RE: Un tuto en plus - Tho - 17-02-2010
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 ^^
RE: Un tuto en plus - Sephi-Chan - 18-02-2010
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
RE: Un tuto en plus - Tho - 19-02-2010
(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é
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.
(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.
RE: Un tuto en plus - Sephi-Chan - 19-02-2010
(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é
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
RE: Un tuto en plus - Tho - 19-02-2010
(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..
(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 (...)
...
(19-02-2010, 01:13 PM)Sephi-Chan a écrit : 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) ?
On ne va pas partir en troll "mvc caybien/caypasbien" ^^ Je sais bien que cette architecture convient à un tas de gens, seulement moi, je n'arrive pas à m'y retrouver. Je n'aime pas du tout la structure, c'est trop bien organisé pour moi
Je préfère avoir ma bonne vieille page qui appelle une action du manager en fonction d'une variable get (ou post). (19-02-2010, 01:13 PM)Sephi-Chan a écrit :(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 ?
Comme chaque outil, on peut mal s'en servir.. Comme je l'ai dit, on va pas faire un troll là-dessus
(19-02-2010, 01:13 PM)Sephi-Chan a écrit : 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
Logique, je cherche juste à progresser
Ca veut dire que j'vais devenir aussi doué que toi dans quelques années ? Bon présage, j'espère x')
RE: Un tuto en plus - Sephi-Chan - 19-02-2010
(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 (...)
...
Je ne suis pas sûr de comprendre... Quelques questions pour cerner le fonctionnement de ton architecture.
- UsersManager peut s'apparenter à un modèle ?
- Tu as un contrôleur comme ça par "module" (ici le module "news") puis tu fais un genre de switch sur l'action demandée ?
- Que se passe-t-il après la suppression de la news ? Quelle page est rendue (ou redirigée) ?
- Comment sont gérées les vues dans ton système ? Que contiennent-elles ?
- Comment fais-tu pour la partie "cadre" (les blocs html et head, par exemple) ?
(19-02-2010, 05:51 PM)Tho a écrit : On ne va pas partir en troll "mvc caybien/caypasbien" ^^ Je sais bien que cette architecture convient à un tas de gens, seulement moi, je n'arrive pas à m'y retrouver. Je n'aime pas du tout la structure, c'est trop bien organisé pour moi
Tu es quelqu'un d'intelligent, tu dois savoir qu'un code bien rangé c'est facile à maintenir (cela dit, je suis d'accord pour dire que ça fait beaucoup de fichiers
).Un poète (en 1996) a dit :
Pascal Obispo a écrit :[...]
Toujours regarder devant soi
Sans jamais baisser les bras, je sais...
C'est pas le remède à tout,
Mais faut s'forcer parfois...
[...]
Bon, je déconne, mais quitte à faire un genre de MVC, autant en faire un sérieux, non ? Ou mieux : en utiliser une implémentation sérieuse.
(19-02-2010, 01:13 PM)Sephi-Chan a écrit : Comme chaque outil, on peut mal s'en servir.. Comme je l'ai dit, on va pas faire un troll là-dessus
Un exemple de mauvais usage de MVC ? Le risque quand on veut utiliser un design pattern, c'est de se gourer de design pattern. Mais là, tu sais déjà lequel utiliser et il y a des exemples d'implémentation à la pelle (d'ailleurs, le tiens semble en être un).
(19-02-2010, 05:51 PM)Tho a écrit : Logique, je cherche juste à progresser
Ca veut dire que j'vais devenir aussi doué que toi dans quelques années ? Bon présage, j'espère x')
Tiens c'est marrant, je suis pas sur de la façon dont je dois le prendre...
iffle:Sephi-Chan