(19-02-2010, 06:33 PM)Sephi-Chan a écrit : 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, 06:33 PM)Sephi-Chan a écrit : 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) ?
  

• Même si c'est NewsManager, oui, à peu près. En fait, j'ai trois classes par module, en général (ça peut varier si j'ai besoin d'un design pattern spécifique ou non) : une classe qui instancie les données de la bdd, en l'occurence, News, une classe pour manipuler ces objets, et une classe "template", qui parse l'objet au format demandé. Un petit exemple :
  
  

  
  
  class NewsManager
  
  {
  
      public function getFromId($id)
  
      {
  
          $sql = "req sql";
  
          $qry = Con::getInstance()->prepare($sql);
  
          $data = $qry->execute($id)->fetch();
  
          $n = new News;
  
          // assignation des données via accesseurs de $n
  
          // puis
  
          return $n;
  
      }
  
  }
  
  

  
  
• En gros, oui, même s'il y a une différence au switch, puisque les conditions peuvent ne pas s'appliquer à une seule et même variable.
  
• En l'occurence, ici, j'ai enlevé l'affichage, j'ai réduit au strict minimum. En vérité, on affiche juste un message comme quoi la news a bien été supprimée, avec une vue spéciale.
  
• Une classe vue par module, en gros.
  
• Ici, c'est le fichier d'index qui gère ça. Je peux demander un parsage html, xml, voire textuelle en fonction d'une simple variable get ^^
  

(19-02-2010, 06:33 PM)Sephi-Chan a écrit : 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 :

[quote=Pascal Obispo]
[...]

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, 06:33 PM)Sephi-Chan a écrit : 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, 06:33 PM)Sephi-Chan a écrit : Tiens c'est marrant, je suis pas sur de la façon dont je dois le prendre... iffle:

(19-02-2010, 07:27 PM)Tho a écrit : Effectivement, même si je comprends pas tout, n'ayant jamais vu de ruby auparavant, c'est plutôt intéressant comme solution. Mais lorsque tu as plusieurs niveaux d'accès pour un client (par exemple, quelqu'un qui aurait acheté un compte "plus" qui lui permet d'accéder à des prix plus avantageux), tu gères ça comment ?

• Si je suis un gros bourrin, je mets mon filtre check_authorization directement en before_filter sur mon ApplicationController. Note que ça risque de bloquer tout l'application puisque ça empêche d'accéder aux pages d'authentification, la solution est alors d'enlever le filtrer pour les actions new (le formulaire) et create (la page d'action du formulaire) dans le contrôleur qui gère l'authentification (UserSessionsController).
  
• Moins bourrin : spécifier le filtre pour certains contrôleurs.
  

(19-02-2010, 07:27 PM)Tho a écrit : Exécuter des actions du contrôleur dans le modèle, ou faire des vérifications dans la vue, ce genre de choses... Enfin, je crois que je n'aime pas MVC parce qu'il m'avait fait peur à première vue (c'était y'a quasiment un an). Mais si ce que je fais y ressemble, j'irais y rejeter un oeil, ça doit pas être si compliqué que ça...