ngollan
unread,Apr 7, 2011, 6:50:22 AM4/7/11Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to merb
With extlib's class_inheritable_accessor, the behaviour of filters is
a bit under-defined when using inheritance, owed to the fact that
those accessors are defined when the attributes are first referenced.
This is an issue when switching to ActiveSupport, and needs to be
specified properly.
The current situation with specs that will hit git master Soon™ is:
# File: spec/public/abstract_controller/filter_spec.rb
it "should not propagate filter changes to child classes" do
# Caveat!
dispatch_should_make_body("FilterChild3a", "Before
Index", :limited)
AbstractControllers::FilterChild3.before :postfact_filter
dispatch_should_make_body("FilterChild3", "Rewritten
Index", :limited)
dispatch_should_make_body("FilterChild3a", "Before
Index", :limited)
end
it "should not propagate filter changes to parent classes" do
AbstractControllers::FilterChild3a.before :inherited_postfact_filter
dispatch_should_make_body("FilterChild3", "Rewritten
Index", :limited)
dispatch_should_make_body("FilterChild3a", "Modified
Index", :limited)
end
Note the "precondition", i.e., the first dispatch_should_make_body in
the first spec. That initialises the accessor and "blocks" propagation
so the spec passes. Without that test, the chain will only be set up
after the base class gets the filter, and thus the child will inherit.
This situation is not quite good, and it's the same for the template
root.
So, the question is: how should inheritance be handled. Two
possibilities are:
(1) Inherit at class definition time, or
(2) Always walk "up" the class hierarchy's filter chains
So, assuming #filter_x appends "X" to the output:
class Base < Merb::AbstractController
before :filter_x
end
class A < Base
before :filter_a
end
class B < A
before :filter_b
end
A.before :filter_y
the result of a filtered action in B would be:
(1) "BAX"
(2) "BYAX"
Which one do you want? :-)