Mam kontroler (skopiowany bezpośrednio z dokumentacji Rails)
[code]# dictionaries_controller.rb
class DictionariesController < ApplicationController
GET messages_url
def index
end
GET new_message_url
def new
end
POST messages_url
def create
end
GET message_url(:id => 1)
def show
end
GET edit_message_url(:id => 1)
def edit
end
PUT message_url(:id => 1)
def update
end
DELETE message_url(:id => 1)
def destroy
end
end[/code]
W routes.rb mam
[code]ActionController::Routing::Routes.draw do |map|
map.resources :dictionaries
komentarze usunąłem
map.connect ‘:controller/:action/:id’
map.connect ‘:controller/:action/:id.:format’
end[/code]
A wynik w przeglądarce:
[code]ArgumentError
wrong number of arguments (4 for 3)
RAILS_ROOT: C:/Users/leszek/Desktop/rails_root/dkt_test
Application Trace | Framework Trace | Full Trace
c:/ruby/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/option_merger.rb:14:in named_route' c:/ruby/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/option_merger.rb:14:insend!’
c:/ruby/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/option_merger.rb:14:in method_missing' c:/ruby/lib/ruby/gems/1.8/gems/actionpack-2.1.0/lib/action_controller/resources.rb:494:inmap_default_collection_actions’
c:/ruby/lib/ruby/gems/1.8/gems/actionpack-2.1.0/lib/action_controller/resources.rb:434:in map_resource' c:/ruby/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/core_ext/object/misc.rb:48:inwith_options’
c:/ruby/lib/ruby/gems/1.8/gems/actionpack-2.1.0/lib/action_controller/resources.rb:432:in map_resource' c:/ruby/lib/ruby/gems/1.8/gems/actionpack-2.1.0/lib/action_controller/resources.rb:351:inresources’
c:/ruby/lib/ruby/gems/1.8/gems/actionpack-2.1.0/lib/action_controller/resources.rb:351:in each' c:/ruby/lib/ruby/gems/1.8/gems/actionpack-2.1.0/lib/action_controller/resources.rb:351:inresources’
config/routes.rb:3
config/routes.rb:1
This error occurred while loading the following files:
C:/Users/leszek/Desktop/rails_root/dkt_test/config/routes.rb[/code]
Naprawdę nie wiem co robię źle. Wszystko skopiowane z dokumentacji Rails. W routes.rb odkomentowałem tylko linię i zmieniłem symbol.
Ruby: 1.8.6 Rails: 2.1.0
C:\Users\leszek\Desktop\rails_root\dkt_test>rake routes
(in C:/Users/leszek/Desktop/rails_root/dkt_test)
/:controller/:action/:id
/:controller/:action/:id.:format
A z map.resource się wywala
C:\Users\leszek\Desktop\rails_root\dkt_test>rake routes
(in C:/Users/leszek/Desktop/rails_root/dkt_test)
rake aborted!
wrong number of arguments (4 for 3)
Się śmiej, ale jeszcze nie spotkałem się z monkeypatchem, który by czegoś nie rozwalał. Z reguły po cichu i w sposób, który wyłazi dopiero po kilku kwadransach debugowania.
Na przykład plugin validates_date_time - nadpisuje railsowe parsery dat i oczywiście robi to tak nieudolnie, że lepiej o tym pluginie zapomnieć.
[code=ruby]module XMLRPC
module ParseContentType
def parse_content_type(str)
if str.nil? or str == ‘text/plain’
str = ‘text/xml; charset=utf-8’
end
a, *b = str.split(";")
return a.strip, *b
end
end
end[/code]
Monkeypatch, który niczego nie rozwala, a rozwiązuje problem zbyt dumnych, żeby poprawić swój kod, developerów J2EE.
Konkretnie - XMLRPC w odpowiedziach nie wstawiało Content-Type albo wstawiało text/plain.
Dramatyzujecie i tyle MP pozwala na wieksza swobode grzebania w cudzym kodzie w “runtime”. Na tej samej zasadzie przeciez dziala caly DataMapper, np include DataMapper:Resource w klasie, mixiny, RAILS!. Budowana jest np podstawowa klasa ActiveRecord:Base ktora potem jest rozszerzania np przez named_scope. Prawie kazdy plugin do Rails to MP. Wiec moje pytanie… dlaczego uwazacie to za cos zlego jesli na okraglo z tego korzystacie ;]
Jesli spojrzec na definicje MP to w zasadzie kazdy plugin do oprogramowania nawet pisane w c podchodzi pod definicje. MP to po prostu rzecz z ktora trzeba sie umiec obchodzic. Stwierdzenia typu “Rails jest be bo ma syf w pluginach i nigdy nie dzialaja po updejcie rails” swiadczy o tym ze wiele osob nadal chyba nie rozumie jakie sa podstawowe wady pisania pluginow Zwlaszcza w Rails ktore nie ma api(abi?) ktore moglo by zamrazac i okreslac kiedy kompatybilnosc pluginow bedzie zapewniona, a kiedy nie. Ale ja sie z tego ciesze, jesli by takie api posiadalo… i je zamrazalo co poltora roku to dzis pewnie 60 % funkcjonalnosci czekalo by na rails 3.0 a nie siedzialo by juz w rails 2.3. Cos za cos
+1
Domiksowywanie to nie MP, zwłaszcza że metody dołączone z zaincludowanego modułu nie przesłaniają (są przysłonięte przez) metod zaimplementowanych w danej klasie.
Chociażby ostatnio do wrzucenia obsługi rodzaju, do tłumaczeń w rails i18n. Jakby odpowiednio ponaciskać na developerów, to bardzo możliwe, że wrzucą takie coś, ale do tej pory trzeba sobie jakoś radzić.
Można zrobić plugin, który używając alias_method_chain dorzuci do generowania komunikatów o błędach jedną kilka linijek, albo zforkować sobie railsy tam zmienić kod i trzymać cały czas swoją unikalną wersję w vendor rails. Tylko ciężko wtedy to ogarnąć, szczególnie, że takich “pluginów” możemy potrzebować kilka i to nie tylko pisanych przez siebie.
Oczywiście, na dłuższą metę MP jest takim rozwiązaniem na supełek i zgadzam się z tym co mówicie, ale świat nie jest różowy i dopóki dany kawałek kodu w railsach nie będzie na tyle elastyczny, żeby można było sobie podpiąć swój własny kod, wrzucić alternatywny backend, czy coś w tym stylu, to trzeba to jakoś rozwiązać. Grunt, żeby nie przesadzić.
Swoją drogą developerzy railsów mogliby się dużo nauczyć od javascriptowców. Większość pluginów do jquery czy script.aculo.us ma zdefiniowane duże ilości callbacków i opcji konfiguracyjnych przez co rzadko trzeba się uciekać do modyfikowania kodu pluginu.
Nie
To robią nagminnie Railsy i nikt od tego nie ucierpiał - patrz na rozszerzenia klas String, Integer (15.minutes), Date/Time i ogólnie cały ActionPack.
Póki nie przesłania się oryginalnych metod, to można roszerzać do woli
Nie
To robią nagminnie Railsy i nikt od tego nie ucierpiał - patrz na rozszerzenia klas String, Integer (15.minutes), Date/Time i ogólnie cały ActionPack.[/quote]
To, że railsy robią to nie znaczy, że robią to dobrze.
A skąd wiadomo, że nie przesłaniają? Wystarczy, że dołączysz inną bibliotekę, która robi coś podobnego i może być niefajnie. Poza tym nigdy nie można być pewnym, zmieniając cudze klasy, że w przyszłości ona nie zdefiniuje takie same metody, jakie my dodajemy.
Nie
To robią nagminnie Railsy i nikt od tego nie ucierpiał - patrz na rozszerzenia klas String, Integer (15.minutes), Date/Time i ogólnie cały ActionPack.[/quote]
To, że railsy robią to nie znaczy, że robią to dobrze.[/quote]
To juz raczej kwestia opinii ;] jesli z tego korzystasz, to zgadzasz sie na taki MP i raczej nie uznal bys tego za cos zlego, bo zaprzeczal bys wtedy sam sobie (korzystasz z rails?)
Zwlaszcza w Rails ktore nie ma api(abi?) ktore moglo by zamrazac i okreslac kiedy kompatybilnosc pluginow bedzie zapewniona, a kiedy nie. Ale ja sie z tego ciesze, jesli by takie api posiadalo… i je zamrazalo co poltora roku to dzis pewnie 60 % funkcjonalnosci czekalo by na rails 3.0 a nie siedzialo by juz w rails 2.3. Cos za cos 
(korzystasz z rails?)