Radiant::Config

Is there any reason to not be storing configuration values for my
Extension via the Radiant::Config class?

I have been making the keys like
“extensions.extension_name.setting_name”

Am I off-track or on-target?

Loren

Loren,

That is what we will be suggesting going forward. One of my tasks this
week
is to remove support for the ‘config’ page part. Any extension that
wants
to use it will need to load it manually. After I complete that, I will
be
moving the Mailer extension over to using Radiant::Config (with an
importation script, of course). The LDAP extension already uses
Radiant::Config.

Sean

Cool, that sounds great. Makes plenty of sense to me. Is their
anything to say about the convention extensions.extension_name.key?

Thanks!

L

I think we can leave that to personal preference, until such time comes
a
need to constrain the domain. Personally, I use extension_name.key.
But do
what you like.

Sean

On Jan 31, 2007, at 11:12 AM, Sean C. wrote:

Loren,

That is what we will be suggesting going forward. One of my tasks
this week is to remove support for the ‘config’ page part. Any
extension that wants to use it will need to load it manually.
After I complete that, I will be moving the Mailer extension over
to using Radiant::Config (with an importation script, of course).
The LDAP extension already uses Radiant::Config.

Sean

Is there going to be an interface for editing the Radiant::Config via
browser instead of SQL?

~~ Brian

Brian G. wrote:

Is there going to be an interface for editing the Radiant::Config via
browser instead of SQL?

I like to use script/console for editing config values:

% script/console production
Loading production environment

Radiant::Config[‘my.key’] = ‘value’
=> “value”
exit

Ultimately I think we will want something in the interface to handle
this, but I haven’t settled on how to do it yet.

Sometimes it is appropriate to let things go for a while when you aren’t
sure about the best approach.

It would be trivial to implement an editing interface with an extension.


John L.
http://wiseheartdesign.com

Amen and amen. Scaffold-up an extension for managing config values
and call it good until this next release is out then it can be
thought about again once a larger set of Extensions (and hence real
requirements) start to appear.

I’m excited to just ad a config tab right into my Calendar extension
which filters on it’s config parameters only. That’ll be great.

That will be up to the creator of the extension. Regarding the default
values in the database (things like the UI title, subtitle, etc), there
have been no plans made although it would be rather trivial to
implement. It’s just currently not high on the list.

Sean

Question for you all;

My host (Dreamhost) is about to upgrade to 1.2.1. Will 1.2.1 break
0.5.2?

Thanks!
Andrew

It should not, presuming they will keep around the 1.1.6 gem. If you
are
concerned, you could run rake rails:freeze:edge TAG=rel_1-1-6 inside
your
Radiant directory. That will keep the 1.1.6 version associated with
your
instance of Radiant.

Sean