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, 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…
