> Could this be introduced for new pages? For some behaviors > you need to > create multiple parts. Having these present upfront gives one > less thing > to explain to the users. The default content could be provided by the > behavior. > > Erik.
My preferred way to do that would be to let the parent in on the child creation process - you would create a parent behaviour for, say 'reviews', and this parent behaviour would dictate the default parts and behavior of its children. This idea is in part because I would like pages to potentially have their administration page change completely based on their behaviour - I think the best way to do that would be to choose the behavior before being presented with the administration page (so click new -> choose behavior -> edit page). To make this less obstrusive, the parent page could dictate what the allowed children were - so you don't put archive month summarys beneath pages that aren't archive behaviors, and the 'reviews' parent would only allow 'review' children (thus skipping the choose behavior page). Or maybe the child pages say what their parents can be... either/or - if your review child page has it's own behavior, and that behavior is selected before the page object is instantiated, the parts can be selected by the review child behaviour. Simple behaviors that do little more than specify their allowed parents and default parts would be fairly easy to create an admin interface for. Store those in a table and dynamically create their classes on demand. Ruby makes that bit brain-dead easy. But I've yet to actually put any of that into an implementation, so I don't know whether these ideas are actually good or not... 'when I have time'... dammit... too much thinking not enough doing. Daniel. _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
