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.
Ruben,
What configuration needs are you thinking of?
Sean
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.
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
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. [email protected] wrote:
Radiant mailing list
Post: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
–
Alexander H.
http://www2.truman.edu/~ah428
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
That’s the thing, though. Page#config renders the ‘config’ part and
then parses the YAML from it.
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.
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
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
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.
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.
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
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
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
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
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.
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: 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.
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.
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.