[development] 4.8/5.0: Modules, the install system, and directories

Morbus Iff morbus at disobey.com
Wed Feb 22 16:26:49 UTC 2006


> http://lists.drupal.org/pipermail/development/2006-January/013203.html
> Allie makes convincing arguments.

Hrm. I didn't know of parse_ini_file().
The following works as I'd expect:

----- test.ini
   admin/country/evil = "I am the mastah of eternity!"
   stupid/monkey = "hah"
   [somethign_help]
   wickedno = "yes"
----- test.ini

with the following: print_r(parse_ini_file('./test.ini', true));.

But, there are a few problems with this:

  * We don't get all the capabilities of t(). While we can certainly
    throw a t() around the retrieved string, we can never use %vars
    to include URLs or user data, or what have you. This, I think,
    puts the nail in the idea of help-within-an-ini file.

If we do want to keep file slewing down (and I certainly agree), then 
the .ini file doesn't seem like the strongest choice, because there's no 
logic in it whatsoever (and %vars of t() can be considered logic, since 
most of them in core are using urls() or printing user vars). Likewise, 
there's no other precedence in Drupal that says something "not PHP" is a 
strong choice (our .install files, for instance, are moving away from a 
regular SQL dump and into PHP - can't we assume that we'd eventually 
want to do the same with an .ini file?)

For what it's worth, I don't like .config - it's too actiony
("Let me config that for you..." is a common speech pattern).

-- 
Morbus Iff ( you are nothing without your robot car, NOTHING! )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus


More information about the development mailing list