If you’ve been watching the change logs lately, you might
have noticed a
new branch in the repository–the “mental” branch:
It’s basically a place for the core team to play around with a few
architectural changes. The most significant change to date is that we
are experimenting with the idea of axing behaviors and moving to an
inheritance hierarchy for pages:
I was just about to get into radiant work again (well, once I manage to
unpack enough stuff to actually be able to do anything - moving house
sucks), and it’s nice to see that I can throw away the majority of my
‘on crack’ changes and just take this branch to start off again.
The big reason that I was trying to push for this change was to be able
to introduce activerecord associations to the subclassed behaviors and
then modify the admin display for those behaviors.
To do this you’d need the following hooks into the admin interface to:
- modify the rendering of the page editing (mainly add new
fields, but maybe hide away/rearrange the existing fields?)
- intercept the saving process (to convert fields to
associations and verify those associations)
Looking over the plugin proposals, I’m not quite sure what the best way
to go about this is. The second part can probably be done just with
activerecord validations and extra methods on the behavior, though that
might be mixing the model with the view a bit. The modification of the
page editing might be achieved by something like:
routes.my_route “my/route”, :controller => “my_controller”, :action
admin.pageviews.add “My Handy Dandy Page”, “_my_page_view_partial”
page_classes.activate “My Handy Dandy Page”
Also, if behaviour pages have possibly different validations/fields,
then the PageController will need to make sure that it’s got an instance
of the correct class before it does an update.
I’ll hopefully be able to dive back in and explore this myself in a
couple of weeks, but I thought I’d get it out now before it slips my
mind. How do you see these ideas fitting in with the plugin model?