2009-05-13 04:10:37 -04:00
|
|
|
require 'active_support/core_ext/module'
|
2012-08-15 12:44:18 -04:00
|
|
|
require 'action_view/model_naming'
|
2009-05-13 04:10:37 -04:00
|
|
|
|
2012-06-09 08:20:31 -04:00
|
|
|
module ActionView
|
2014-12-19 15:49:50 -05:00
|
|
|
# RecordIdentifier encapsulates methods used by various ActionView helpers
|
|
|
|
# to associate records with DOM elements.
|
2007-04-29 21:17:56 -04:00
|
|
|
#
|
2015-12-21 19:46:33 -05:00
|
|
|
# Consider for example the following code that form of post:
|
2007-04-29 21:17:56 -04:00
|
|
|
#
|
2015-12-21 19:46:33 -05:00
|
|
|
# <%= form_for(post) do |f| %>
|
|
|
|
# <%= f.text_field :body %>
|
2014-12-19 15:49:50 -05:00
|
|
|
# <% end %>
|
2007-04-29 21:17:56 -04:00
|
|
|
#
|
2015-09-13 10:48:10 -04:00
|
|
|
# When +post+ is a new, unsaved ActiveRecord::Base instance, the resulting HTML
|
2014-12-19 15:49:50 -05:00
|
|
|
# is:
|
2007-04-29 21:17:56 -04:00
|
|
|
#
|
2015-12-21 19:46:33 -05:00
|
|
|
# <form class="new_post" id="new_post" action="/posts" accept-charset="UTF-8" method="post">
|
|
|
|
# <input type="text" name="post[body]" id="post_body" />
|
|
|
|
# </form>
|
2014-12-19 15:49:50 -05:00
|
|
|
#
|
|
|
|
# When +post+ is a persisted ActiveRecord::Base instance, the resulting HTML
|
|
|
|
# is:
|
|
|
|
#
|
2015-12-21 19:46:33 -05:00
|
|
|
# <form class="edit_post" id="edit_post_42" action="/posts/42" accept-charset="UTF-8" method="post">
|
|
|
|
# <input type="text" value="What a wonderful world!" name="post[body]" id="post_body" />
|
|
|
|
# </form>
|
2014-12-19 15:49:50 -05:00
|
|
|
#
|
|
|
|
# In both cases, the +id+ and +class+ of the wrapping DOM element are
|
|
|
|
# automatically generated, following naming conventions encapsulated by the
|
|
|
|
# RecordIdentifier methods #dom_id and #dom_class:
|
|
|
|
#
|
|
|
|
# dom_id(Post.new) # => "new_post"
|
|
|
|
# dom_class(Post.new) # => "post"
|
|
|
|
# dom_id(Post.find 42) # => "post_42"
|
|
|
|
# dom_class(Post.find 42) # => "post"
|
2007-04-29 21:17:56 -04:00
|
|
|
#
|
2014-12-19 15:49:50 -05:00
|
|
|
# Note that these methods do not strictly require +Post+ to be a subclass of
|
|
|
|
# ActiveRecord::Base.
|
2014-12-30 11:00:40 -05:00
|
|
|
# Any +Post+ class will work as long as its instances respond to +to_key+
|
|
|
|
# and +model_name+, given that +model_name+ responds to +param_key+.
|
|
|
|
# For instance:
|
2014-12-19 15:49:50 -05:00
|
|
|
#
|
|
|
|
# class Post
|
|
|
|
# attr_accessor :to_key
|
|
|
|
#
|
|
|
|
# def model_name
|
|
|
|
# OpenStruct.new param_key: 'post'
|
|
|
|
# end
|
|
|
|
#
|
|
|
|
# def self.find(id)
|
2014-12-30 11:00:40 -05:00
|
|
|
# new.tap { |post| post.to_key = [id] }
|
2014-12-19 15:49:50 -05:00
|
|
|
# end
|
|
|
|
# end
|
2007-04-29 21:17:56 -04:00
|
|
|
module RecordIdentifier
|
|
|
|
extend self
|
2012-08-25 07:34:52 -04:00
|
|
|
extend ModelNaming
|
2007-04-29 21:17:56 -04:00
|
|
|
|
2012-06-29 00:54:12 -04:00
|
|
|
include ModelNaming
|
|
|
|
|
2008-06-06 06:03:30 -04:00
|
|
|
JOIN = '_'.freeze
|
|
|
|
NEW = 'new'.freeze
|
|
|
|
|
2012-05-15 02:51:54 -04:00
|
|
|
# The DOM class convention is to use the singular form of an object or class.
|
2007-04-29 21:17:56 -04:00
|
|
|
#
|
|
|
|
# dom_class(post) # => "post"
|
|
|
|
# dom_class(Person) # => "person"
|
|
|
|
#
|
|
|
|
# If you need to address multiple instances of the same class in the same view, you can prefix the dom_class:
|
|
|
|
#
|
|
|
|
# dom_class(post, :edit) # => "edit_post"
|
|
|
|
# dom_class(Person, :edit) # => "edit_person"
|
|
|
|
def dom_class(record_or_class, prefix = nil)
|
2012-06-29 00:54:12 -04:00
|
|
|
singular = model_name_from_record_or_class(record_or_class).param_key
|
2008-06-06 06:03:30 -04:00
|
|
|
prefix ? "#{prefix}#{JOIN}#{singular}" : singular
|
2007-04-29 21:17:56 -04:00
|
|
|
end
|
|
|
|
|
2008-01-26 00:11:09 -05:00
|
|
|
# The DOM id convention is to use the singular form of an object or class with the id following an underscore.
|
2012-05-15 02:51:54 -04:00
|
|
|
# If no id is found, prefix with "new_" instead.
|
2007-04-29 21:17:56 -04:00
|
|
|
#
|
2008-06-17 02:24:58 -04:00
|
|
|
# dom_id(Post.find(45)) # => "post_45"
|
2008-01-26 00:11:09 -05:00
|
|
|
# dom_id(Post.new) # => "new_post"
|
2007-04-29 21:17:56 -04:00
|
|
|
#
|
|
|
|
# If you need to address multiple instances of the same class in the same view, you can prefix the dom_id:
|
|
|
|
#
|
2008-06-17 02:24:58 -04:00
|
|
|
# dom_id(Post.find(45), :edit) # => "edit_post_45"
|
2012-04-05 02:07:30 -04:00
|
|
|
# dom_id(Post.new, :custom) # => "custom_post"
|
2010-06-19 17:35:54 -04:00
|
|
|
def dom_id(record, prefix = 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 02:24:10 -05:00
|
|
|
if record_id = record_key_for_dom_id(record)
|
2008-06-06 06:03:30 -04:00
|
|
|
"#{dom_class(record, prefix)}#{JOIN}#{record_id}"
|
|
|
|
else
|
|
|
|
dom_class(record, prefix || NEW)
|
|
|
|
end
|
2007-04-29 21:17:56 -04:00
|
|
|
end
|
|
|
|
|
2010-07-21 05:46:38 -04:00
|
|
|
protected
|
|
|
|
|
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 02:24:10 -05:00
|
|
|
# Returns a string representation of the key attribute(s) that is suitable for use in an HTML DOM id.
|
|
|
|
# This can be overwritten to customize the default generated string representation if desired.
|
|
|
|
# If you need to read back a key from a dom_id in order to query for the underlying database record,
|
|
|
|
# you should write a helper like 'person_record_from_dom_id' that will extract the key either based
|
2011-09-07 00:26:56 -04:00
|
|
|
# on the default implementation (which just joins all key attributes with '_') or on your own
|
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 02:24:10 -05:00
|
|
|
# overwritten version of the method. By default, this implementation passes the key string through a
|
|
|
|
# method that replaces all characters that are invalid inside DOM ids, with valid ones. You need to
|
|
|
|
# make sure yourself that your dom ids are valid, in case you overwrite this method.
|
|
|
|
def record_key_for_dom_id(record)
|
2012-06-29 00:54:12 -04:00
|
|
|
key = convert_to_model(record).to_key
|
2015-01-18 02:36:42 -05:00
|
|
|
key ? key.join(JOIN) : key
|
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 02:24:10 -05:00
|
|
|
end
|
2007-04-29 21:17:56 -04:00
|
|
|
end
|
2008-06-06 06:03:30 -04:00
|
|
|
end
|