This might come across as sacrilege but I recently installed Drupal 5.0. I would suggest that everybody here do the same... It's got a lot going for it in terms of CMS functionality. I'm personally looking for something in between Radiant and Drupal... But the main point is that the configuration/admin interface is 'kick ass', and that's without any exaggeration.
It might be worth taking a few pointers from their admin interface. I find the current Radiant one a bit cumbersome. On the flipside, I find the Drupal "content creation" interface very cumbersome - so that's why I say I'm looking for something in between. Perhaps the Drupal goals and Radiant goals don't see eye to eye, but I don't see anything wrong with learning from another's success. On 18/01/2007, at 10:51 AM, Brian Gernhardt wrote: > > On Jan 17, 2007, at 6:05 PM, Daniel Sheppard wrote: > >> Yes, but I thought we were talking about the problem that using a >> config >> page part is too complicated and error-prone for an end user. >> >> If it's meant for a developer to change, hard code it, and tell >> developers to change it if they need to. If it's meant for an end >> user >> to change, go the extra mile and give them a proper interface to >> change >> it. > > And my message was a plea to keep the config page part around or > something at least as simple to use from a development point of view > (only a couple lines of code to use, at most). A config page part > may be too error-prone for complex uses, but is perfect for the > simple ones. It's also great for testing an extension before it gets > released. I simply find it too useful, and I'd probably end up > making an extension to add it back in if it was removed. > > Unless a generic configuration system is added, the need to write a > configuration interface for every simple plugin would limit my > interest in developing for Radiant. If a particular extension is > having problems, then fix it to have a better interface. But don't > remove something that's working because it doesn't work in some cases. > > For an example of where it's great is the VirtualDomainsBehavior, as > I mentioned. It's not hard to explain what the following config part > means and I don't see a compelling reason to write a custom interface > for it because of the limited usage it gets: > > ----- 8< ----- > dev.example.com: development > example.org: non-profit > *: main > ----- 8< ----- > > However, a good argument can be made that a central configuration > system would be a good thing for Radiant to have. It would allow for > a consistent interface across all extensions. The extension could > provide a set of global variables and types that would be available > from either the extensions page or a new page dedicated to the task > (good if we add configuration for Radiant there too), and Page types > could provide a set of variables for each page. It would keep > developers from having to design a completely custom interface for > each extension, which is horribly confusing for the users. > > But until that exists, let me use my config page part! > > ~~ Brian > > P.S. I haven't eaten today, so I apologize for any incoherence. > _______________________________________________ > Radiant mailing list > Post: [email protected] > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
