Rails - Feb 2006 - ROR Recipes Beta: Why use taggings instead of tags_contacts? NoMethodError tag_with?

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
  
  
		
---------------------------------
Brings words and photos together (easily) with
 PhotoMail  - it''s free and works with Yahoo! Mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060212/14c85af6/attachment.html

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.

On 2/12/06, softwareengineer 99 <softwareengineer99@yahoo.com>
wrote:
> 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.

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.


		
---------------------------------
Brings words and photos together (easily) with
 PhotoMail  - it''s free and works with Yahoo! Mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060213/3508c055/attachment-0001.html

> 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

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.

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

> 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

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
_______________________________________________
Rails mailing list
Rails@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails


		
---------------------------------
 Yahoo! Mail
 Use Photomail to share photos without annoying attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060213/4c141be7/attachment-0001.html