Daniel Sheppard wrote: > 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.
Yup, this is a huge benefit the new model. > 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?) I would like to eventually support this, but it's probably not going to be part of the initial plugin system. > - intercept the saving process (to convert fields to > associations and verify those associations) This shouldn't be difficult to support. > 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: > > def activate > routes.my_route "my/route", :controller => "my_controller", :action > => "my_action" > admin.pageviews.add "My Handy Dandy Page", "_my_page_view_partial" > page_classes.activate "My Handy Dandy Page" > end That looks useful. I was thinking to leverage partials for this as well. > 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. True enough. It does open up a whole other level of complexity. -- John Long http://wiseheartdesign.com _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
