[typo] Question about app design choices for classes with HABTM

Matt Pelletier pelletierm at eastmedia.net
Thu Apr 28 00:43:18 EDT 2005


I noticed that in Admin you can only add/remove Categories to/from an 
Article once the Article has already been created. I wanted to know if 
that was a deliberate design choice made to avoid an issue I happen to 
be running into in my own app (which for these purposes uses the same 
simple HABTM relationship as Article/Categories).

I have tried to allow one or more Categories to be added to an Article 
in the 'create' method of the Article controller. Using a single or 
multiple select control I can display existing categories in the 
_form.rhtml partial without a problem, but when submitting the form 
(with no modification to the scaffold-generated 'create' method), I 
receive the error:

----------------
AssociationTypeMismatch in Admin/articles#create

Category expected, got String
----------------

This is getting thrown by the first line in the 'create' method:
@article = Article.new(@params["article"])

Both the Category and Article models have HABTM declarations referencing 
one another, and the db tables are properly named (articles, categories, 
articles_categories). I already have at least two Categories.

I have set this up so that the IDs of the Categories are either sent as 
an array, which appears in the Request parameters, or as just a single 
ID ("categories" => "2") which is the result when I use just a single 
select in the form. All techniques result in the same problem.

Now, before I solicit tips, is there something basic I am missing (i.e. 
You can't create a new class if HABTM relationship names have form 
elements?). Where/how is a new instance of an Article supposed to know 
that if it has a reflexive HABTM relationship to another class whose 
name is a form field then that field's value(s) are existing IDs of that 
other class?

I was going to ask this last week, but figured I'd wait until Typo 2.0 
came out to see if it was addressed. Since it has been addressed, and 
since the chosen approach implies a common underlying issue, I now ask: 
what gives? I think it's fair to assume it is a better app design choice 
to be able to add Categories to an Article on create, not just once an 
Article exists.

Thanks,
Matt


More information about the Typo-list mailing list