# Allowing behaviours to add associations to pages **URL:** \ **Category:** Radiant CMS\ **Created:** [June 13, 2006, 9:46am UTC](https://www.ruby-forum.com/t/allowing-behaviours-to-add-associations-to-pages/63220 "2006-06-13T09:46:19Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 13, 2006, 9:46am UTC](https://www.ruby-forum.com/t/allowing-behaviours-to-add-associations-to-pages/63220/1 "2006-06-13T09:46:19Z")
[http://dev.radiantcms.org/radiant/ticket/40](http://dev.radiantcms.org/radiant/ticket/40) The ticket above includes an implementation of what I’m wanting to do here, but I thought I’d explain it in full here as I’d really like some feedback and suggestions on how this fits in with what radiant is trying to do. I operate a website, The Groggy Squirrel [http://www.thegroggysquirrel.com](http://www.thegroggysquirrel.com), that consists primarily of articles about comedy and a comedian database (there’s also a gig guide, but I’ll probably leave the management of that non-radiant for now). It’s backed by a hand-rolled rails cms that does the job, but isn’t user-friendly by any stretch of the imagination which is becoming a problem now that I’m thinking about opening up the admin to more than just myself and the editor - so I’m looking at using radiant instead. In my comedian database pages, I maintain links from comedians to articles about them. This is done while you’re entering the articles - you select the comedians that you’d like the article to be associated with. I could probably do this in radiant by storing the list of comedians in a page-part, but I’d rather pull that onto the main screen and present a better interface to comedian selection, using autocompletion to prevent spelling errors etc. Also, for the comedians, I’d like the data entry to be a bit more structured, with separate fields for their contact details and other things, d/o/b, etc. Other sites would make use of this for such structured data as a product catalogue or “blah out of blah” style reviews. Basically, what I’m looking for is for the behaviour to dictate the structure of the page data. The implementation that I’ve gone for is to allow behaviours to modify the metaclass of the pages that their assigned to - allowing association with other tables - and also to dictate how this is exposed on the editing screen for the page. I’m not crazy about the implementation, but it seems to work, and I don’t think it’s broken things too much. I think this would probably be cleaner if the page table stored their implementation (ComicPage, ArticlePage) in the database and specific subclasses of page were instatiated when a Page.find method is called. I’ll have a poke around rails’ polymorphic stuff to see what I can see in that regard. It might also be cleaner implementation-wise if the behaviour admin templates where just rhtml templates (probably of the \_xxxx\_behavior\_admin.rhtml type) and not actually stored in the behaviour itself. Another totally unrelated nicety would by the ability to specify the default behaviour of the child page (so that it could be set on the ‘archive’ parent page and new children get an ‘blog entry’ behaviour by default). Sorry for spamming everybody with my half-finished implementations - I’m trying to get a gap-analysis going here to make sure that moving to radiant isn’t a silly idea and would also like to get some feedback on what I’m doing so that I don’t go running off down a path that is going to make keeping my changes in sync with the core development a nightmare. P.S. Damn you Americans - behaviour has a ‘U’ - so many spelling mistake errors… ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 13, 2006, 4:36pm UTC](https://www.ruby-forum.com/t/allowing-behaviours-to-add-associations-to-pages/63220/2 "2006-06-13T16:36:52Z")
Daniel S. wrote: > [http://dev.radiantcms.org/radiant/ticket/40](http://dev.radiantcms.org/radiant/ticket/40) > > The ticket above includes an implementation of what I’m wanting to do > here, but I thought I’d explain it in full here as I’d really like some > feedback and suggestions on how this fits in with what radiant is trying > to do. Interesting stuff Daniel. I’d say in general I wasn’t planning on getting this fancy on the 1.0 release, but I find what you are doing very informative. I would encourage you to keep your patch updated, but be aware that it probably won’t be included in 1.0. There has been some talk of doing something like this in 2.0. Oh, you will need unit tests if you will ever have a shot at getting this into the core. 🙂 – John L. [http://wiseheartdesign.com](http://wiseheartdesign.com) ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 15, 2006, 9:48am UTC](https://www.ruby-forum.com/t/allowing-behaviours-to-add-associations-to-pages/63220/3 "2006-06-15T09:48:37Z")
> Interesting stuff Daniel. I’d say in general I wasn’t planning on > getting this fancy on the 1.0 release, but I find what you are doing > very informative. I would encourage you to keep your patch > updated, but > be aware that it probably won’t be included in 1.0. There has > been some > talk of doing something like this in 2.0. As long as my ideas don’t conflict too much with the other users, I’m happy to be operating outside of the trunk, just want to get feedback to make sure that changes to the trunk keep this sort of thing in mind and also so I don’t do stupid things. Speaking of stupid things, the way I have the behaviour dictate the data model of the page might not be the smartest thing. Behaviours are about adding tags to the page - Page data models are about the data in the page. There seems to be a lot of interdependency there, but I’m not sure it’s complete as of yet. I’m planning on using single table inheritance and having a bunch of page subclasses to add connectivity with other tables so that I can just leverage the single-table-inheritance behaviour of rails to do most of the magic. If it turns out that a unification of data model and behaviour IS a good idea, it’s probably something that should push the page and behaviour classes together so that you’d have: Page + Behaviour becomes just Page class ArchiveBehavior \< Page class EnvBehaviour \< Page class ProductBehaviour \< Page (links the page to a product table and introduces appropriate tags) … etc. Now that I’ve played with single table inheritance, it’s suprising to me that this isn’t the way the classes are laid out, but I’m not pushing for togetherness until I’ve had more of a play. ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 15, 2006, 5:36pm UTC](https://www.ruby-forum.com/t/allowing-behaviours-to-add-associations-to-pages/63220/4 "2006-06-15T17:36:41Z")
Daniel S. wrote: > As long as my ideas don’t conflict too much with the other users, I’m > happy to be operating outside of the trunk, just want to get feedback to > make sure that changes to the trunk keep this sort of thing in mind and > also so I don’t do stupid things. > > Speaking of stupid things, the way I have the behaviour dictate the data > model of the page might not be the smartest thing. Behaviours are about > adding tags to the page - Page data models are about the data in the > page. There seems to be a lot of interdependency there, but I’m not sure > it’s complete as of yet. Behaviors are due for a rewrite soon. Pages are intended to be a dumb data model. Behaviors are supposed to be where the real functionality lives. And you are right, currently there is a lot of interdependency there. > for togetherness until I’ve had more of a play. > I actually haven’t played much with single table inheritance. I’ll be > interested in what you discover. Perhaps a more unified model is in > order. – John L. [http://wiseheartdesign.com](http://wiseheartdesign.com)