Forum: Ruby on Rails ROR Recipes Beta: Why use taggings instead of tags_contacts?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
F68e4842b0a5487678e26046fdb2fdf3?d=identicon&s=25 softwareengineer 99 (Guest)
on 2006-02-12 23:49
(Received via mailing list)
I have gotten acts_as_taggable to work for a test application as
documented on taggable.rubyforge.org

  I am following Chad's excellent examples in ROR Recipes Beta book.

  I have a few questions and hope that Chad or some other expert can
help clarify them.

  1. Why is the book suggesting to use taggings table instead of
tags_contacts, as mentioned on taggable.rubyforge.org?
  2. How can I use this taggings table instead of my tags_contacts?
  3. How can I store additional fields such as member_id in the
tags_contacts table or taggings table?
  4. When I follow Chad's example on my Favorite class, (with
tags_favorites and taggings table created) I keep getting the
NoMethodError for "tag_with"? At first I thought this may be because I
am using taggings table but then when I created tags_favorites table
the error persisted.
  5. I finally used the tag method as described on rubyforge.org and it
works. So my question is, is tag_with a typo in the book or am I
missing something?
  6. Why does the following output say @new_record=false even when the
record was created? Is it to prevent further entry of the same record?

  Loading development environment.
  ./script/../config/../config/../lib/localization.rb:5: warning:
already initialized constant LOCALIZED_STRINGS
  >> f=Favorite.create(:url=>'http://home.com', :title=>'Home  Pages
title', :desc=>'My note about this favorite',  :created_at=>Time.now)
  => #<Favorite:0xb6f5d594 @new_record=false,
@errors=#<ActiveRecord::Errors:0xb6f54bb0  @base=#<Favorite:0xb6f5d594
...>, @errors={}>,  @new_record_before_save=false,
@attributes={"updated_at"=>Sun Feb 12  15:30:38 CST 2006, "title"=>"Home
Pages title", "portal_id"=>0,  "member_id"=>0, "id"=>12,
"url"=>"http://home.com",  "desc"=>"My note about this favorite",
"created_at"=>Sun Feb 12  15:30:38 CST 2006}>
  >> f.tag_with("home tag1 tag2")
  NoMethodError: undefined method `tag_with' for #<Favorite:0xb6f5d594>
          from
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/base.rb:1501:in
`method_missing'
          from (irb):2
  >> f.tag("home tag1 tag2")
  => ["home", "tag1", "tag2"]


  Thank you very much for your assistance.

  Frank
D2eaa0f268843d5d3f5d92823cf1308a?d=identicon&s=25 Michael Yacavone (Guest)
on 2006-02-13 03:00
(Received via mailing list)
The acts_as_taggable in the ROR Recipes book uses the _plugin_ written
by DHH, not the _gem_ on rubyforge. Unfortunately, the plugin is not
documented outside the ROR Recipes book right now.

Until DHH documents the plugin we're going to have dozens or hundreds
of messages of confusion like this. Even then, the namespace collision
will provide months of amusement.
F68e4842b0a5487678e26046fdb2fdf3?d=identicon&s=25 softwareengineer 99 (Guest)
on 2006-02-13 04:12
(Received via mailing list)
Thanks for the clarification.

Michael Yacavone <michael.yacavone@gmail.com> wrote:  The
acts_as_taggable in the ROR Recipes book uses the _plugin_ written
by DHH, not the _gem_ on rubyforge. Unfortunately, the plugin is not
documented outside the ROR Recipes book right now.

Until DHH documents the plugin we're going to have dozens or hundreds
of messages of confusion like this. Even then, the namespace collision
will provide months of amusement.
6edd67c92a1dab5eb23fed79f3c18564?d=identicon&s=25 David Heinemeier Hansson (Guest)
on 2006-02-13 08:10
(Received via mailing list)
> Until DHH documents the plugin we're going to have dozens or hundreds
> of messages of confusion like this. Even then, the namespace collision
> will provide months of amusement.

Now here's the truly wonderful part of open source: Creator,
maintainer, and documentor needs not all be caps on the same schmoe.
Thus, if you find something useful, say a plugin like acts_as_taggable
with the creator stamp DHH, you can choose to express your gratitude
through one of the other caps.

That may be a patch to extend or it may be a tutorial about its usage
or even READMEs and RDocs for the source. So try not to assume that
creator equals sole maintainer or documentor. Only try to understand
the truth: There is no vendor.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework
D2eaa0f268843d5d3f5d92823cf1308a?d=identicon&s=25 Michael Yacavone (Guest)
on 2006-02-13 12:22
(Received via mailing list)
On 2/13/06, David Heinemeier Hansson <david.heinemeier@gmail.com> wrote:
> That may be a patch to extend or it may be a tutorial about its usage
> or even READMEs and RDocs for the source. So try not to assume that
> creator equals sole maintainer or documentor. Only try to understand
> the truth: There is no vendor.

I am actually trying to get a grip on this to help, which happens to
be challenging for my skill level.

But when the top dog of Rails creates a namespace clash with a
well-known gem, it sure would be nice to have some leadership and not
defer to the magic of open-source community to sort it out eventually.
Better to just say, "We're up against a new product release, and will
get to this someday soon," or somesuch, which is probably pretty close
to the truth.

Thought experiment: If someone else had released a plugin with the
same name as a well-known gem, would the community have accepted it,
or would they encourage the creator to change the name to avoid
confusion? I assert that 1) the creator would have been encouraged to
change the name, and 2) it is because DHH is the creator this didn't
happen.

Of course, let a thousand flowers bloom, just don't expect this
question to go away anytime soon.
D2eaa0f268843d5d3f5d92823cf1308a?d=identicon&s=25 Michael Yacavone (Guest)
on 2006-02-13 15:34
(Received via mailing list)
I have written a weblog entry which hopefully clarifies the situation
as I understand it, and will eventually hit the Google index for
future queries.

http://www.notio.com/2006/02/rails_acts_as_t.html
6edd67c92a1dab5eb23fed79f3c18564?d=identicon&s=25 David Heinemeier Hansson (Guest)
on 2006-02-13 16:31
(Received via mailing list)
> But when the top dog of Rails creates a namespace clash with a
> well-known gem, it sure would be nice to have some leadership and not
> defer to the magic of open-source community to sort it out eventually.

Namespace clashes are problematic for packages that wants to be used
concurrently, not for alternatives. How would the situation have
improved if I had called it acts_as_polymorphically_taggable (except
for making jokes about such a terrible, terrible name)? Would we not
have had the same questions as to what does what and why? Of course we
would.

In any case, let me summarize the difference quickly. The main
difference is not plugin vs gem, but rather that my version of
acts_as_taggable is designed to work with multiple classes. So a
single tag can be used in the tagging of multiple classes. This
requires polymorphic associations and join models, which is why it
only works Edge Rails (and will work in the forthcoming 1.1).

So if you need that feature, tagging of multiple classes with the same
tags, then use my version. Otherwise, the old version is probably
better. It's certainly more feature-rich and better documented.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework
F68e4842b0a5487678e26046fdb2fdf3?d=identicon&s=25 softwareengineer 99 (Guest)
on 2006-02-13 19:27
(Received via mailing list)
Wow, it feels great to receive a reply from David himself.

  Thanks a lot man for the clarification.

  You are doing a great job and like other ROR developers, I greatly
appreciate your efforts.

  Frank

David Heinemeier Hansson <david.heinemeier@gmail.com> wrote:  > But when
the top dog of Rails creates a namespace clash with a
> well-known gem, it sure would be nice to have some leadership and not
> defer to the magic of open-source community to sort it out eventually.

Namespace clashes are problematic for packages that wants to be used
concurrently, not for alternatives. How would the situation have
improved if I had called it acts_as_polymorphically_taggable (except
for making jokes about such a terrible, terrible name)? Would we not
have had the same questions as to what does what and why? Of course we
would.

In any case, let me summarize the difference quickly. The main
difference is not plugin vs gem, but rather that my version of
acts_as_taggable is designed to work with multiple classes. So a
single tag can be used in the tagging of multiple classes. This
requires polymorphic associations and join models, which is why it
only works Edge Rails (and will work in the forthcoming 1.1).

So if you need that feature, tagging of multiple classes with the same
tags, then use my version. Otherwise, the old version is probably
better. It's certainly more feature-rich and better documented.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework
This topic is locked and can not be replied to.