PHP, vos astuces pour palier à ses défauts ?

[Hideaki]

La méthode est ici, est pour la récupération de données issus d'un get soit un simple lien url. Je n'ai pas voulu changer le corps de la méthode outre mesure car sinon j'aurais fait une page jsp différente, tu peux aussi récupérer directement un objet ...
Maintenant l'avantage, cela rejoins le sujet c'est la possibilité de surcharger la méthode et même en fonction du contenu des paramètres.

Il existe plusieurs manière de transmettre les informations à ta vue, l'avantage de cette méthode est la possibilité de dissocié complétement le nom du paramètre et le nom de l'objet que tu utilises en interne.

D'après ton ancien tuto sur ruby, la récupération d'un objet issu d'un formulaire est @user = User.new(params[:user]) ce qui n'est pas mieux que la méthode proposée par spring, bien au contraire et la sélection de la vue via redirect_to root_url ou render 'new' ... comme je l'ai dit plus haut @nomDeLAttribut relit fortement ta classe à ta page mais qui à l'avantage d'aller plus vite mais pas énormément dans le codage si ta variable est optionnelle sur la vue choisi, tu ajoutes un paramètre pour rien et le cas échéant tu dois faire attention ou déclarer ta variable @variable

Pour répondre à ta question dans la mesure où je n'ai pas voulu retoucher le corps de la méthode et que je n'ai agit que sur la méthode, je te répondrais oui, il est clair qu'il y a d'autre mode d'implémentation de la technologie proposé, laissant un code avec plus ou moins d'annotation ou de code supplémentaire car la cas fournit en exemple, il faut le dire est mauvais.

[Pinguin]

Une solution sympa pour gérer la surcharge de fonction, serait de recoder un système de name mangling.

Code PHP :

<?php

class myClass

{

    public function __call($method, $args)

    {

        $name = $method;

        foreach ($args as $arg)

            $name .= '_'.gettype($arg);

        

        if (method_exists($this, $name))

            call_user_func_array(array($this, $name), $args);

        else if (method_exists($this, $method))

            call_user_func_array(array($this, $method.'_'), $args);

        else

            throw new Exception('Unable to call '.$method);

    }

    

    public function Attack_Type1($type1) {}

    public function Attack_Type2($type2) {}

    public function Attack_($all) {}

} 

[Argorate]

$toto->getTiti()['tata'] est une syntaxe incorrecte, et c'est très chian de ne pas pouvoir accédez au liste (array) que l'on peut avoir dans un objet, pas de solution j'imagine a part une variable intermédiaire?

C'est prévu pour php 5.4 il me semble

Une 5.4 est prévu? Quand? elle inclue quoi d'autre d'intéressant?

[Sephi-Chan]

Je me permets de dériver maintenant que le sujet est traité. Et j'en profite pour rappeler que c'est seulement du débat, pas une baston.

La méthode est ici, est pour la récupération de données issus d'un get soit un simple lien url. Je n'ai pas voulu changer le corps de la méthode outre mesure car sinon j'aurais fait une page jsp différente, tu peux aussi récupérer directement un objet ...
Maintenant l'avantage, cela rejoins le sujet c'est la possibilité de surcharger la méthode et même en fonction du contenu des paramètres.

Il existe plusieurs manière de transmettre les informations à ta vue, l'avantage de cette méthode est la possibilité de dissocié complétement le nom du paramètre et le nom de l'objet que tu utilises en interne.

D'après ton ancien tuto sur ruby, la récupération d'un objet issu d'un formulaire est @user = User.new(params[:user]) ce qui n'est pas mieux que la méthode proposée par spring, bien au contraire et la sélection de la vue via redirect_to root_url ou render 'new' ... comme je l'ai dit plus haut @nomDeLAttribut relit fortement ta classe à ta page mais qui à l'avantage d'aller plus vite mais pas énormément dans le codage si ta variable est optionnelle sur la vue choisi, tu ajoutes un paramètre pour rien et le cas échéant tu dois faire attention ou déclarer ta variable @variable

Pour répondre à ta question dans la mesure où je n'ai pas voulu retoucher le corps de la méthode et que je n'ai agit que sur la méthode, je te répondrais oui, il est clair qu'il y a d'autre mode d'implémentation de la technologie proposé, laissant un code avec plus ou moins d'annotation ou de code supplémentaire car la cas fournit en exemple, il faut le dire est mauvais.

La surcharge d'une action de contrôleur ? Pourquoi ? Avoir une route (une méthode HTTP et un motif) par action me paraît plus simple, et c'est d'ailleurs cette approche que semble préconiser l'équipe de Spring en favorisant REST.

@Controller

public class BookingsController {

  @RequestMapping(value="/hotels/{hotel}/bookings/{booking}", method=RequestMethod.GET)

  public String getBooking(@PathVariable("hotel") long hotelId, @PathVariable("booking") long bookingId, Model model) {

      Hotel hotel = hotelService.getHotel(hotelId);

      Booking booking = hotel.getBooking(bookingId);

      model.addAttribute("booking", booking);

      return "booking";

  }

}

# Dans le fichier /config/routes.rb.

get "/hotels/:hotel_id/bookings/:id", to: "bookings#show"





# Dans le fichier /apps/controllers/bookings_controller.rb.

class BookingsController < ApplicationController

  def show

    hotel    = Hotel.find(params[:hotel_id])    # La variable locale ne sera pas accessible dans la vue.

    @booking = hotel.bookings.find(params[:id]) # La variable d'instance le sera.

  end

end

Comme tu peux le voir, le code est simple, efficace et sans fioriture. La lisibilité est optimale.

Implicitement, la vue apps/views/bookings/show.fr.html.haml sera rendue (seul le nom de l'action est obligatoire, les autres parties (la locale, le format et le moteur de rendu) sont optionnelles.

Et il n'y a pas d'ajout de paramètre pour rien, si j'avais défini @hotel au lieu de hotel, ça ne m'aurait pas coûté plus cher.

Par définition, notre vue est fortement couplée à son action : si la vue requiert une variable @booking pour fonctionner, son action doit lui exposer cette variable. Si la présence de cette variable est optionnel, la vue doit être capable de gérer son absence (un simple if @booking suffit). Si une autre action veut rendre cette vue, elle devra définir cette variable. C'est le cas dans l'exemple que tu cites : l'action de traitement du formulaire cherche à rendre le formulaire à nouveau quand la validation échoue, afin d'y afficher les messages d'erreur. Quoi de plus normal ? L'approche est simple, pragmatique et efficace.

Selon moi, les outils proposés par Java poussent les développeurs à compliquer inutilement les choses. Et c'est justement cette incitation à la simplicité qui m'a séduit dans Rails.

[Hideaki]

le @hotel ne t'aurais pas couté plus cher quelque part si puisque cela est fait implicitement, mis dans une map dans la requête

L'intérêt de la surcharge de l'action est la suivante :
Dans le cas où ton formulaire est dynamique c'est à dire que certain choix entraine l'activation/désactivation ou faire apparaître/disparaitre certaines parties d'un formulaire, cela t'évite par exemple de faire un test pour savoir dans quel cas où tu te trouves, pour généraliser cela permet d'éviter de faire des if else ou switch case pour définir le cas où tu te situes

[Sephi-Chan]

le @hotel ne t'aurais pas couté plus cher quelque part si puisque cela est fait implicitement, mis dans une map dans la requête

Je ne comprends pas.

L'intérêt de la surcharge de l'action est la suivante :
Dans le cas où ton formulaire est dynamique c'est à dire que certain choix entraine l'activation/désactivation ou faire apparaître/disparaitre certaines parties d'un formulaire, cela t'évite par exemple de faire un test pour savoir dans quel cas où tu te trouves, pour généraliser cela permet d'éviter de faire des if else ou switch case pour définir le cas où tu te situes

D'accord, je vois mieux l'utilisation dans le cadre d'une action de contrôleur. C'est pertinent.

Discuter ainsi permet de voir comment les gens traitent les problèmes selon les outils proposés par leur langage favori.

[srm]

Je pense mon code pour ne pas avoir ce besoin tout simplement

[Hideaki]

@Sephi : désolé à force de restructurer ma phrase, j'oublie de relire :/
Lorsque tu dis : "ça ne m'aurait pas coûté plus cher" ce n'est pas tout à fait vrai car implicitement ton attribut est mis dans la map contenant les attributs de ta requête, cela à un coût certes négligeable mais cela à un coût
Il est vrai que je ne connais les optimisations du compilateur et/ou de la machine virtuelle ( suivant les cas ) mais je doute qu'ils vérifient aussi profondément dans le code.


J'espère oxman que l'on ne t'a pas fait trop peur avec Sephi =)

[Sephi-Chan]

Je ne comprends toujours pas de quoi tu parles : la map contenant les attributs ? Il n'y a pas de map, seulement un objet, qu'on définisse une variable locale ou une variable d'instance ne change rien. La vue peut accéder à ces variables d'instance.

Je ne pense pas que Oxman puisse avoir peur de ce qu'on dit mais qu'il pointait du doigt cette manière de faire des formulaires à tiroir. Moi non plus je ne ferais pas forcément comme ça.

[srm]

Ah j'ai fait encore plus cours que ça hein, j'ai lu le premier post et j'y ai répondu, j'ai lu aucun des autres :')
Après si des personnes me répondent que par moment il dommageable de devoir penser son code autrement pour pouvoir se passer de se besoin, ou encore que parfois on a vraiment ce besoin, je demanderais des exemples et verrais ainsi si je me trompe ou non