# What about **URL:** \ **Category:** Radiant CMS\ **Created:** [January 17, 2007, 3:51am UTC](https://www.ruby-forum.com/t/what-about/82059 "2007-01-17T03:51:39Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 17, 2007, 3:51am UTC](https://www.ruby-forum.com/t/what-about/82059/1 "2007-01-17T03:51:39Z")
It seems that many of the problems with extensions that require some sort of config file are due to cross-platform treatment of text (speacially \s and \t). Wouldn’t it make sense to use not-so-space-sensitive XML files instead of the beloved yml? I know that a big faction of Ruby/Rails users squeel at just the thought of an XML, but really, it’s about pragmatics? So would it be that bad an idea to use XML files for config stuff? Just wondering. ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 17, 2007, 4:03am UTC](https://www.ruby-forum.com/t/what-about/82059/2 "2007-01-17T04:03:40Z")
Ruben, What configuration needs are you thinking of? Sean ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 17, 2007, 4:17am UTC](https://www.ruby-forum.com/t/what-about/82059/3 "2007-01-17T04:17:40Z")
Sean, For instance the config for the Mailer beahvior is a candidate but I’m talking in general (i.e. any extension built that does require some user settings). It does not have to, but it seems to me, from the user’s POV that having “platform-independent” format would make life much easier. In fact, even the database.yml file gave me a few problems (even using the venerable vim) because of spacing. Of course, the database.yml config file is “internal” to RoR (right?) so it can’t be easily substituted with an XML file. Again, these are just ideas (probably not well thought out) to consider that could make Radiant more accessible to everyone who wishes to try it out. ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 17, 2007, 4:27am UTC](https://www.ruby-forum.com/t/what-about/82059/4 "2007-01-17T04:27:43Z")
Ruben D. Orduz wrote: > For instance the config for the Mailer beahvior is a candidate but I’m > talking in general (i.e. any extension built that does require some > user settings). It does not have to, but it seems to me, from the > user’s POV that having “platform-independent” format would make life > much easier. In fact, even the database.yml file gave me a few > problems (even using the venerable vim) because of spacing. Of course, > the database.yml config file is “internal” to RoR (right?) so it can’t > be easily substituted with an XML file. Again, these are just ideas > (probably not well thought out) to consider that could make Radiant > more accessible to everyone who wishes to try it out. We probably should deprecate the config part. I agree that yaml was a poor idea there. – John L. [http://wiseheartdesign.com](http://wiseheartdesign.com) ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 17, 2007, 4:44am UTC](https://www.ruby-forum.com/t/what-about/82059/5 "2007-01-17T04:44:44Z")
What happened to Page#config()? I’d use that because it allows you to change the configuration of an extension through the admin interface. Of course, it has it’s limitations. But I would rather try to find a solution to these issues than relying too heavily on file-system-level-config files. On 1/16/07, Sean C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Radiant mailing list > Post: removed\_email\_address@domain.invalid > Search: [http://radiantcms.org/mailing-list/search/](http://radiantcms.org/mailing-list/search/) > Site: [http://lists.radiantcms.org/mailman/listinfo/radiant](http://lists.radiantcms.org/mailman/listinfo/radiant) – Alexander H. [http://www2.truman.edu/~ah428](http://www2.truman.edu/~ah428) ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 17, 2007, 4:35am UTC](https://www.ruby-forum.com/t/what-about/82059/6 "2007-01-17T04:35:43Z")
Yes, but how is XML better? I’m not sure. Somehow there needs to be a good solution for page-instance-specific configuration that is not related to the content. Maybe some separate ‘metadata’ model is in order? Perhaps with a tree-like structure (explicitly or implicitly)? Sean ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 17, 2007, 4:47am UTC](https://www.ruby-forum.com/t/what-about/82059/7 "2007-01-17T04:47:48Z")
That’s the thing, though. Page#config renders the ‘config’ part and then parses the YAML from it. ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 17, 2007, 6:56am UTC](https://www.ruby-forum.com/t/what-about/82059/8 "2007-01-17T06:56:06Z")
While the use of yaml config page parts is a problem in radiant 0.5.2, I see no reason why any page in mental would be storing configuration in the page parts or config files or any other form of unstructured data. Extending a page to have a metadata table is as simple as: class GroggyArticlePage \< Page has\_one :groggy\_article\_metadata, :foreign\_key =\> ‘page\_id’, :depende delegate :article\_type, :article\_type=, :feature, :feature=, :to =\> :metadata def metadata self.groggy\_article\_metadata ||= build\_groggy\_article\_metadata end def after\_save metadata.save end end class GroggyArticleMetaData end Of course, in order for that to work well, we need a mechanism for editing the editing pages - my page parts extension starts somewhat in that direction, but it’s really not up to scratch yet. Dan. ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 17, 2007, 6:06am UTC](https://www.ruby-forum.com/t/what-about/82059/9 "2007-01-17T06:06:01Z")
Can we store these settings in a table in the DB with a page\_id foreign key? Wouldn’t that circumvent the page-specific problem? We could agree upon a string format for the settings (i.e. comma separated, pipe “|” separated etc) to be stored in. The schema would look something like this: ## id | page\_id | extension\_id | settings | 1 5 1 userName|pass|port|protocol ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 17, 2007, 8:44am UTC](https://www.ruby-forum.com/t/what-about/82059/10 "2007-01-17T08:44:18Z")
Another option is to simply use Ruby in configuration files. ``` Erik. ``` Ruben D. Orduz wrote: > It seems that many of the problems with extensions that require some > sort of config file are due to cross-platform treatment of text > (speacially \s and \t). Wouldn’t it make sense to use > not-so-space-sensitive XML files instead of the beloved yml? I know > that a big faction of Ruby/Rails users squeel at just the thought of > an XML, but really, it’s about pragmatics? So would it be that bad an > idea to use XML files for config stuff? Just wondering. – Erik van Oosten > **[Day to day stuff](http://day-to-day-stuff.blogspot.com/)** > > Experiences from a hard core JVM programmer. Likes to keep things simple. ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 17, 2007, 2:25pm UTC](https://www.ruby-forum.com/t/what-about/82059/11 "2007-01-17T14:25:30Z")
That does not sound bad at all. Simply set the config files as a Ruby class set all the values in a hash table (though it would be nice if we standarize nomenclature and so forth). Though I don’t know if that scheme would still suffer from page-specific problems. ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 17, 2007, 1:38pm UTC](https://www.ruby-forum.com/t/what-about/82059/12 "2007-01-17T13:38:18Z")
On Jan 17, 2007, at 2:29 AM, Erik van Oosten wrote: > Another option is to simply use Ruby in configuration files. This would get my vote. ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 17, 2007, 3:02pm UTC](https://www.ruby-forum.com/t/what-about/82059/13 "2007-01-17T15:02:37Z")
At the moment, I’m less concerned about what the implementation is like (frankly, I’d like the change to be seamless and invisible to extensions). I’d much prefer to see a UI screenshot/comp! (Taking this as a personal PDI if I have time.) Sean ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 17, 2007, 3:09pm UTC](https://www.ruby-forum.com/t/what-about/82059/14 "2007-01-17T15:09:39Z")
Ruben D. Orduz wrote: > That does not sound bad at all. Simply set the config files as a Ruby > class set all the values in a hash table (though it would be nice if > we standarize nomenclature and so forth). Though I don’t know if that > scheme would still suffer from page-specific problems. Radiant is designed for a shared hosting environment. So Ruby configuration for Pages is out. (This is the same reason for radius tags instead of ERB.) – John L. [http://wiseheartdesign.com](http://wiseheartdesign.com) ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 17, 2007, 4:51pm UTC](https://www.ruby-forum.com/t/what-about/82059/15 "2007-01-17T16:51:10Z")
On Jan 17, 2007, at 12:49 AM, Daniel S. wrote: > While the use of yaml config page parts is a problem in radiant > 0.5.2, I > see no reason why any page in mental would be storing configuration in > the page parts or config files or any other form of unstructured data. > Extending a page to have a metadata table is as simple as: > Of course, in order for that to work well, we need a mechanism for > editing the editing pages - my page parts extension starts somewhat in > that direction, but it’s really not up to scratch yet. The complexity of that far exceeds the config page part. The simplicity of YAML and loading a single page part is compelling and makes development simple. I don’t think that it’s a good match for storing large amounts of meta-data generated by the system, but it is good for storing a simple configuration file (such as used for the Virtual Domains Behavior/Extension) provided by the user. Perhaps a dedicated table _might_ be better for that, especially if a specialized interface can be provided, but for both early phases of development of a complex plug in or simple “quick and dirty” extensions used on a single site the config page part is a perfect match. I’d ask that it not be removed until a method that is at least as simple is added. My requests would be for no more than a couple lines of code in the model and a built-in editor. I’d rather I not have to write an editor interface for every single page extension I write, even experiments. ~~ Brian ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 18, 2007, 12:41am UTC](https://www.ruby-forum.com/t/what-about/82059/16 "2007-01-18T00:41:01Z")
Daniel S. wrote: > If it’s meant for an end user > to change, go the extra mile and give them a proper interface to change > it. Absolutely! Once we have an interface, we can talk about the implementation details (which are usually obvious from the UI). I know Radiant isn’t for end-users /per se/, but a friendly UI that makes me feel like I ‘kick ass’ makes the experience that much better. (Excuse me for reading a little too much Kathy Sierra lately!) Sean ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 18, 2007, 12:11am UTC](https://www.ruby-forum.com/t/what-about/82059/17 "2007-01-18T00:11:59Z")
> Perhaps a dedicated table _might_ be better for that, > especially if a > specialized interface can be provided, but for both early phases of > development of a complex plug in or simple “quick and dirty” > extensions used on a single site the config page part is a perfect > match. 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. ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 18, 2007, 12:53am UTC](https://www.ruby-forum.com/t/what-about/82059/18 "2007-01-18T00:53:03Z")
On Jan 17, 2007, at 6:05 PM, Daniel S. 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](http://dev.example.com): development [example.org](http://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. ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 20, 2007, 3:41am UTC](https://www.ruby-forum.com/t/what-about/82059/19 "2007-01-20T03:41:44Z")
Adam, I recently made a post in the same vein. And I would agree that while not copying, per se, is sometime worth looking into more mature products. As a pragmatic person, I don’t believe in re-inventing the wheel, just perfecting it, thus, I think Radiant should at least consider looking into existing solutions and approaches instead of trying to figure out stuff as we go–but that’s up to all the developers and, more importantly, John. ---
**Author:** ![Ruben\_DSOrduz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a88e4f/32.png) [@Ruben\_DSOrduz](https://www.ruby-forum.com/u/Ruben_DSOrduz)\ **Post date:** [January 20, 2007, 3:27am UTC](https://www.ruby-forum.com/t/what-about/82059/20 "2007-01-20T03:27:39Z")
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.