19-09-2011, 09:10 PM
(Modification du message : 19-09-2011, 09:20 PM par 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 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.
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.
(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.
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.