<?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) {}

} 

(19-09-2011, 04:42 PM)niahoo a écrit :

(19-09-2011, 04:07 PM)Argorate a écrit : $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

(19-09-2011, 07:26 PM)Hideaki a écrit : 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.

@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

(19-09-2011, 09:29 PM)Hideaki a écrit : 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

(19-09-2011, 09:29 PM)Hideaki a écrit : 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