[typo] Question about app design choices for classes with HABTM
pelletierm at eastmedia.net
Thu Apr 28 01:21:38 EDT 2005
Ah. I hadn't thought of altering the @params. The multi-select and
checkboxes I have tried, but the common problem is the fact that the
'categories' param values are seen as strings instead of IDs that map to
existing categories. I thought with HABTM relationships setup this would
be automatic. Is there a standard way of dealing with this problem? I
feel like with all the intuitive aspects of CRUD this should be a
cakewalk. It is likely my newbie-ness causing the confusion.
Thanks. Typo is a cool app and has been quite instructive as I've been
learning the ropes.
Tobias Luetke wrote:
> Well, I basically just coded it the way it is because I didn't want to
> spend a lot of time on it. The current way only took 5 mins to
> implement and works fairly well.
> It should be pretty easy to implement it in other ways as well. You
> can use a multi select form field or a list with checkboxes on your
> form. Just delete the categories array from the @params, get the
> proper object with find and push or << it into the habm
> On 4/27/05, Matt Pelletier <pelletierm at eastmedia.net> wrote:
>>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
>>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
>>Typo-list mailing list
>>Typo-list at rubyforge.org
More information about the Typo-list