[typo] Question about app design choices for classes with HABTM
tobias.luetke at gmail.com
Thu Apr 28 01:00:13 EDT 2005
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
> 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.
> Typo-list mailing list
> Typo-list at rubyforge.org
http://www.snowdevil.ca - Snowboards that don't suck
http://www.hieraki.org - Open source book authoring
http://blog.leetsoft.com - Technical weblog
More information about the Typo-list