Allowing behaviours to add associations to pages


#1

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…


#2

Daniel S. wrote:

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. :slight_smile:


John L.
http://wiseheartdesign.com


#3

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.


#4

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