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 ex
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 configura
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
Daniel Sheppard 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 /
> 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,
On Jan 17, 2007, at 12:49 AM, Daniel Sheppard 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
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.
Radi
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
Can we store these settings in a table in the D
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 1/17/07, Adam Williams <[EMAIL
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.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
S
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-
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
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
That's the thing, though. Page#config renders the 'config' part and
then parses the YAML from it.
> 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 rath
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
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
> We probably
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
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 fa
Ruben,
What configuration needs are you thinking of?
Sean
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-sensitiv
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 squee
20 matches
Mail list logo
