rails--rails/activemodel/lib/active_model/lint.rb

110 lines
4.7 KiB
Ruby
Raw Normal View History

2009-08-29 06:49:18 +00:00
module ActiveModel
module Lint
# == Active Model Lint Tests
#
# You can test whether an object is compliant with the Active Model API by
# including <tt>ActiveModel::Lint::Tests</tt> in your TestCase. It will
# include tests that tell you whether your object is fully compliant,
# or if not, which aspects of the API are not implemented.
#
# Note an object is not required to implement all APIs in order to work
# with Action Pack. This module only intends to provide guidance in case
# you want all features out of the box.
#
# These tests do not attempt to determine the semantic correctness of the
# returned values. For instance, you could implement valid? to always
# return true, and the tests would pass. It is up to you to ensure that
# the values are semantically meaningful.
#
# Objects you pass in are expected to return a compliant object from a
# call to to_model. It is perfectly fine for to_model to return self.
module Tests
Adds #key and #to_param to the AMo interface This commit introduces two new methods that every AMo compliant object must implement. Below are the default implementations along with the implied interface contract. # Returns an Enumerable of all (primary) key # attributes or nil if new_record? is true def key new_record? ? nil : [1] end # Returns a string representing the object's key # suitable for use in URLs, or nil if new_record? # is true def to_param key ? key.first.to_s : nil end 1) The #key method Previously rails' record_identifier code, which is used in the #dom_id helper, relied on calling #id on the record to provide a reasonable DOM id. Now with rails3 being all ORM agnostic, it's not safe anymore to assume that every record ever will have an #id as its primary key attribute. Having a #key method available on every AMo object means that #dom_id can be implemented using record.to_model.key # instead of record.id Using this we're able to take composite primary keys into account (e.g. available in datamapper) by implementing #dom_id using a newly added record_key_for_dom_id(record) method. The user can overwrite this method to provide customized versions of the object's key used in #dom_id. Also, dealing with more complex keys that can contain arbitrary strings, means that we need to make sure that we only provide DOM ids that are valid according to the spec. For this reason, this patch sends the key provided through a newly added sanitize_dom_id(candidate_id) method, that makes sure we only produce valid HTML The reason to not just add #dom_id to the AMo interface was that it feels like providing a DOM id should not be a model concern. Adding #dom_id to the AMo interface would force these concern on the model, while it's better left to be implemented in a helper. Now one could say the same is true for #to_param, and actually I think that it doesn't really fit into the model either, but it's used in AR and it's a main part of integrating into the rails router. This is different from #dom_id which is only used in view helpers and can be implemented on top of a semantically more meaningful method like #key. 2) The #to_param method Since the rails router relies on #to_param to be present, AR::Base implements it and returns the id by default, allowing the user to overwrite the method if desired. Now with different ORMs integrating into rails, every ORM railtie needs to implement it's own #to_param implementation while already providing code to be AMo compliant. Since the whole point of AMo compliance seems to be to integrate any ORM seamlessly into rails, it seems fair that all we really need to do as another ORM, is to be AMo compliant. By including #to_param into the official interface, we can make sure that this code can be centralized in the various AMo compliance layers, and not be added separately by every ORM railtie. 3) All specs pass
2010-02-20 07:24:10 +00:00
AMo #key is now #to_key and CI is probably happy Obviously #key is a too common name to be included in the AMo interface, #to_key fits better and also relates nicely to #to_param. Thx wycats, koz and josevalim for the suggestion. AR's #to_key implementation now takes customized primary keys into account and there's a testcase for that too. The #to_param AMo lint makes no assumptions on how the method behaves in the presence of composite primary keys. It leaves the decision wether to provide a default, or to raise and thus signal to the user that implementing this method will need his special attention, up to the implementers. All AMo cares about is that #to_param is implemented and returns nil in case of a new_record?. The default CompliantObject used in lint_test provides a naive default implementation that just joins all key attributes with '-'. The #to_key default implementation in lint_test's CompliantObject now returns [id] instead of [1]. This was previously causing the (wrong) tests I added for AR's #to_key implementation to pass. The #to_key tests added with this patch should be better. The CI failure was caused by my lack of knowledge about the test:isolated task. The tests for the record_identifier code in action_controller are using fake non AR models and I forgot to stub the #to_key method over there. This issue didn't come up when running the test task, only test:isolated revealed it. This patch fixes that. All tests pass isolated or not, well, apart from one previously unpended test in action_controller that is unrelated to my patch.
2010-02-21 02:05:28 +00:00
# == Responds to <tt>to_key</tt>
Adds #key and #to_param to the AMo interface This commit introduces two new methods that every AMo compliant object must implement. Below are the default implementations along with the implied interface contract. # Returns an Enumerable of all (primary) key # attributes or nil if new_record? is true def key new_record? ? nil : [1] end # Returns a string representing the object's key # suitable for use in URLs, or nil if new_record? # is true def to_param key ? key.first.to_s : nil end 1) The #key method Previously rails' record_identifier code, which is used in the #dom_id helper, relied on calling #id on the record to provide a reasonable DOM id. Now with rails3 being all ORM agnostic, it's not safe anymore to assume that every record ever will have an #id as its primary key attribute. Having a #key method available on every AMo object means that #dom_id can be implemented using record.to_model.key # instead of record.id Using this we're able to take composite primary keys into account (e.g. available in datamapper) by implementing #dom_id using a newly added record_key_for_dom_id(record) method. The user can overwrite this method to provide customized versions of the object's key used in #dom_id. Also, dealing with more complex keys that can contain arbitrary strings, means that we need to make sure that we only provide DOM ids that are valid according to the spec. For this reason, this patch sends the key provided through a newly added sanitize_dom_id(candidate_id) method, that makes sure we only produce valid HTML The reason to not just add #dom_id to the AMo interface was that it feels like providing a DOM id should not be a model concern. Adding #dom_id to the AMo interface would force these concern on the model, while it's better left to be implemented in a helper. Now one could say the same is true for #to_param, and actually I think that it doesn't really fit into the model either, but it's used in AR and it's a main part of integrating into the rails router. This is different from #dom_id which is only used in view helpers and can be implemented on top of a semantically more meaningful method like #key. 2) The #to_param method Since the rails router relies on #to_param to be present, AR::Base implements it and returns the id by default, allowing the user to overwrite the method if desired. Now with different ORMs integrating into rails, every ORM railtie needs to implement it's own #to_param implementation while already providing code to be AMo compliant. Since the whole point of AMo compliance seems to be to integrate any ORM seamlessly into rails, it seems fair that all we really need to do as another ORM, is to be AMo compliant. By including #to_param into the official interface, we can make sure that this code can be centralized in the various AMo compliance layers, and not be added separately by every ORM railtie. 3) All specs pass
2010-02-20 07:24:10 +00:00
#
# Returns an Enumerable of all (primary) key attributes
# or nil if model.persisted? is false. This is used by
# dom_id to generate unique ids for the object.
AMo #key is now #to_key and CI is probably happy Obviously #key is a too common name to be included in the AMo interface, #to_key fits better and also relates nicely to #to_param. Thx wycats, koz and josevalim for the suggestion. AR's #to_key implementation now takes customized primary keys into account and there's a testcase for that too. The #to_param AMo lint makes no assumptions on how the method behaves in the presence of composite primary keys. It leaves the decision wether to provide a default, or to raise and thus signal to the user that implementing this method will need his special attention, up to the implementers. All AMo cares about is that #to_param is implemented and returns nil in case of a new_record?. The default CompliantObject used in lint_test provides a naive default implementation that just joins all key attributes with '-'. The #to_key default implementation in lint_test's CompliantObject now returns [id] instead of [1]. This was previously causing the (wrong) tests I added for AR's #to_key implementation to pass. The #to_key tests added with this patch should be better. The CI failure was caused by my lack of knowledge about the test:isolated task. The tests for the record_identifier code in action_controller are using fake non AR models and I forgot to stub the #to_key method over there. This issue didn't come up when running the test task, only test:isolated revealed it. This patch fixes that. All tests pass isolated or not, well, apart from one previously unpended test in action_controller that is unrelated to my patch.
2010-02-21 02:05:28 +00:00
def test_to_key
assert model.respond_to?(:to_key), "The model should respond to to_key"
def model.persisted?() false end
assert model.to_key.nil?, "to_key should return nil when `persisted?` returns false"
Adds #key and #to_param to the AMo interface This commit introduces two new methods that every AMo compliant object must implement. Below are the default implementations along with the implied interface contract. # Returns an Enumerable of all (primary) key # attributes or nil if new_record? is true def key new_record? ? nil : [1] end # Returns a string representing the object's key # suitable for use in URLs, or nil if new_record? # is true def to_param key ? key.first.to_s : nil end 1) The #key method Previously rails' record_identifier code, which is used in the #dom_id helper, relied on calling #id on the record to provide a reasonable DOM id. Now with rails3 being all ORM agnostic, it's not safe anymore to assume that every record ever will have an #id as its primary key attribute. Having a #key method available on every AMo object means that #dom_id can be implemented using record.to_model.key # instead of record.id Using this we're able to take composite primary keys into account (e.g. available in datamapper) by implementing #dom_id using a newly added record_key_for_dom_id(record) method. The user can overwrite this method to provide customized versions of the object's key used in #dom_id. Also, dealing with more complex keys that can contain arbitrary strings, means that we need to make sure that we only provide DOM ids that are valid according to the spec. For this reason, this patch sends the key provided through a newly added sanitize_dom_id(candidate_id) method, that makes sure we only produce valid HTML The reason to not just add #dom_id to the AMo interface was that it feels like providing a DOM id should not be a model concern. Adding #dom_id to the AMo interface would force these concern on the model, while it's better left to be implemented in a helper. Now one could say the same is true for #to_param, and actually I think that it doesn't really fit into the model either, but it's used in AR and it's a main part of integrating into the rails router. This is different from #dom_id which is only used in view helpers and can be implemented on top of a semantically more meaningful method like #key. 2) The #to_param method Since the rails router relies on #to_param to be present, AR::Base implements it and returns the id by default, allowing the user to overwrite the method if desired. Now with different ORMs integrating into rails, every ORM railtie needs to implement it's own #to_param implementation while already providing code to be AMo compliant. Since the whole point of AMo compliance seems to be to integrate any ORM seamlessly into rails, it seems fair that all we really need to do as another ORM, is to be AMo compliant. By including #to_param into the official interface, we can make sure that this code can be centralized in the various AMo compliance layers, and not be added separately by every ORM railtie. 3) All specs pass
2010-02-20 07:24:10 +00:00
end
# == Responds to <tt>to_param</tt>
#
# Returns a string representing the object's key suitable for use in URLs
# or nil if model.persisted? is false.
AMo #key is now #to_key and CI is probably happy Obviously #key is a too common name to be included in the AMo interface, #to_key fits better and also relates nicely to #to_param. Thx wycats, koz and josevalim for the suggestion. AR's #to_key implementation now takes customized primary keys into account and there's a testcase for that too. The #to_param AMo lint makes no assumptions on how the method behaves in the presence of composite primary keys. It leaves the decision wether to provide a default, or to raise and thus signal to the user that implementing this method will need his special attention, up to the implementers. All AMo cares about is that #to_param is implemented and returns nil in case of a new_record?. The default CompliantObject used in lint_test provides a naive default implementation that just joins all key attributes with '-'. The #to_key default implementation in lint_test's CompliantObject now returns [id] instead of [1]. This was previously causing the (wrong) tests I added for AR's #to_key implementation to pass. The #to_key tests added with this patch should be better. The CI failure was caused by my lack of knowledge about the test:isolated task. The tests for the record_identifier code in action_controller are using fake non AR models and I forgot to stub the #to_key method over there. This issue didn't come up when running the test task, only test:isolated revealed it. This patch fixes that. All tests pass isolated or not, well, apart from one previously unpended test in action_controller that is unrelated to my patch.
2010-02-21 02:05:28 +00:00
#
# Implementers can decide to either raise an exception or provide a default
# in case the record uses a composite primary key. There are no tests for this
# behavior in lint because it doesn't make sense to force any of the possible
# implementation strategies on the implementer. However, if the resource is
# not persisted?, then to_param should always return nil.
Adds #key and #to_param to the AMo interface This commit introduces two new methods that every AMo compliant object must implement. Below are the default implementations along with the implied interface contract. # Returns an Enumerable of all (primary) key # attributes or nil if new_record? is true def key new_record? ? nil : [1] end # Returns a string representing the object's key # suitable for use in URLs, or nil if new_record? # is true def to_param key ? key.first.to_s : nil end 1) The #key method Previously rails' record_identifier code, which is used in the #dom_id helper, relied on calling #id on the record to provide a reasonable DOM id. Now with rails3 being all ORM agnostic, it's not safe anymore to assume that every record ever will have an #id as its primary key attribute. Having a #key method available on every AMo object means that #dom_id can be implemented using record.to_model.key # instead of record.id Using this we're able to take composite primary keys into account (e.g. available in datamapper) by implementing #dom_id using a newly added record_key_for_dom_id(record) method. The user can overwrite this method to provide customized versions of the object's key used in #dom_id. Also, dealing with more complex keys that can contain arbitrary strings, means that we need to make sure that we only provide DOM ids that are valid according to the spec. For this reason, this patch sends the key provided through a newly added sanitize_dom_id(candidate_id) method, that makes sure we only produce valid HTML The reason to not just add #dom_id to the AMo interface was that it feels like providing a DOM id should not be a model concern. Adding #dom_id to the AMo interface would force these concern on the model, while it's better left to be implemented in a helper. Now one could say the same is true for #to_param, and actually I think that it doesn't really fit into the model either, but it's used in AR and it's a main part of integrating into the rails router. This is different from #dom_id which is only used in view helpers and can be implemented on top of a semantically more meaningful method like #key. 2) The #to_param method Since the rails router relies on #to_param to be present, AR::Base implements it and returns the id by default, allowing the user to overwrite the method if desired. Now with different ORMs integrating into rails, every ORM railtie needs to implement it's own #to_param implementation while already providing code to be AMo compliant. Since the whole point of AMo compliance seems to be to integrate any ORM seamlessly into rails, it seems fair that all we really need to do as another ORM, is to be AMo compliant. By including #to_param into the official interface, we can make sure that this code can be centralized in the various AMo compliance layers, and not be added separately by every ORM railtie. 3) All specs pass
2010-02-20 07:24:10 +00:00
def test_to_param
assert model.respond_to?(:to_param), "The model should respond to to_param"
def model.to_key() [1] end
def model.persisted?() false end
2011-03-16 10:28:40 +00:00
assert model.to_param.nil?, "to_param should return nil when `persisted?` returns false"
Adds #key and #to_param to the AMo interface This commit introduces two new methods that every AMo compliant object must implement. Below are the default implementations along with the implied interface contract. # Returns an Enumerable of all (primary) key # attributes or nil if new_record? is true def key new_record? ? nil : [1] end # Returns a string representing the object's key # suitable for use in URLs, or nil if new_record? # is true def to_param key ? key.first.to_s : nil end 1) The #key method Previously rails' record_identifier code, which is used in the #dom_id helper, relied on calling #id on the record to provide a reasonable DOM id. Now with rails3 being all ORM agnostic, it's not safe anymore to assume that every record ever will have an #id as its primary key attribute. Having a #key method available on every AMo object means that #dom_id can be implemented using record.to_model.key # instead of record.id Using this we're able to take composite primary keys into account (e.g. available in datamapper) by implementing #dom_id using a newly added record_key_for_dom_id(record) method. The user can overwrite this method to provide customized versions of the object's key used in #dom_id. Also, dealing with more complex keys that can contain arbitrary strings, means that we need to make sure that we only provide DOM ids that are valid according to the spec. For this reason, this patch sends the key provided through a newly added sanitize_dom_id(candidate_id) method, that makes sure we only produce valid HTML The reason to not just add #dom_id to the AMo interface was that it feels like providing a DOM id should not be a model concern. Adding #dom_id to the AMo interface would force these concern on the model, while it's better left to be implemented in a helper. Now one could say the same is true for #to_param, and actually I think that it doesn't really fit into the model either, but it's used in AR and it's a main part of integrating into the rails router. This is different from #dom_id which is only used in view helpers and can be implemented on top of a semantically more meaningful method like #key. 2) The #to_param method Since the rails router relies on #to_param to be present, AR::Base implements it and returns the id by default, allowing the user to overwrite the method if desired. Now with different ORMs integrating into rails, every ORM railtie needs to implement it's own #to_param implementation while already providing code to be AMo compliant. Since the whole point of AMo compliance seems to be to integrate any ORM seamlessly into rails, it seems fair that all we really need to do as another ORM, is to be AMo compliant. By including #to_param into the official interface, we can make sure that this code can be centralized in the various AMo compliance layers, and not be added separately by every ORM railtie. 3) All specs pass
2010-02-20 07:24:10 +00:00
end
# == Responds to <tt>to_partial_path</tt>
#
# Returns a string giving a relative path. This is used for looking up
# partials. For example, a BlogPost model might return "blog_posts/blog_post"
#
def test_to_partial_path
assert model.respond_to?(:to_partial_path), "The model should respond to to_partial_path"
assert_kind_of String, model.to_partial_path
end
# == Responds to <tt>persisted?</tt>
2009-08-29 06:49:18 +00:00
#
# Returns a boolean that specifies whether the object has been persisted yet.
# This is used when calculating the URL for an object. If the object is
# not persisted, a form for that object, for instance, will route to the
# create action. If it is persisted, a form for the object will routes to
# the update action.
def test_persisted?
assert model.respond_to?(:persisted?), "The model should respond to persisted?"
assert_boolean model.persisted?, "persisted?"
2009-08-29 06:49:18 +00:00
end
# == Naming
2009-12-31 13:19:30 +00:00
#
# Model.model_name must return a string with some convenience methods:
# :human, :singular, and :plural. Check ActiveModel::Naming for more information.
2009-12-31 13:19:30 +00:00
#
def test_model_naming
assert model.class.respond_to?(:model_name), "The model should respond to model_name"
model_name = model.class.model_name
2012-03-28 16:25:06 +00:00
assert model_name.respond_to?(:to_str)
assert model_name.human.respond_to?(:to_str)
assert model_name.singular.respond_to?(:to_str)
assert model_name.plural.respond_to?(:to_str)
2009-12-31 13:19:30 +00:00
end
# == Errors Testing
#
# Returns an object that implements [](attribute) defined which returns an
# Array of Strings that are the errors for the attribute in question.
# If localization is used, the Strings should be localized for the current
# locale. If no error is present, this method should return an empty Array.
def test_errors_aref
assert model.respond_to?(:errors), "The model should respond to errors"
assert model.errors[:hello].is_a?(Array), "errors#[] should return an Array"
2009-08-29 06:49:18 +00:00
end
private
def model
assert @model.respond_to?(:to_model), "The object should respond_to to_model"
@model.to_model
2009-08-29 06:49:18 +00:00
end
def assert_boolean(result, name)
assert result == true || result == false, "#{name} should be a boolean"
end
2009-08-29 06:49:18 +00:00
end
end
end