Re: ini autogeneration ( getPHP_INI_ENTRY.php )

Hi! > As we all know, there are three main places where ini > settings exist, they are: > > a) {extension}/ini.xml > b) chapters/config.xml > c) master ini table (currently in ini_set docs) > > It's been a long time since these (c) have been generated, > we need to rerun this soon. I believe the last run used the > mk_ini_set_table.sh script while we now have genPHP_INI_ENTRY.php Yes, AFAIK Jesus rewritten his .sh script to .php so we can use the PHP one... > A few concerns exist: > > 1) Problems occur when ini values have commas in > them (ex. url_rewriter.tags). > > This will require some regex tweaking. Other similar > problems may also exist. Basically we all need to > test this, and make sure all the test_ini.xml entries look > good, and adjust the routine accordingly. This will probably be an easy fix. > 2) Some values are CONSTANTS internal to PHP which are not > available in our environment, so, we need to learn how > to get their actual values. These are for default > ini values. > > I created a list of said constants below*. Instead > of hardcoding them into genPHP_INI_ENTRY.php we > could scour the php sources although this doesn't > appear to be a simple task, some are even defined > in configure.in and not all are in php.ini-dist Well, most of these are in php.ini-dist (like hilghlight colors, safe mode settings, extension dir and the like). So there are few to check for independently. This will probably be a nice regexp stuff ;)) > 3) Dealing with ini descriptions! > > This is for (a) and (b). The descriptions of course > aren't autogenerated so I'm assuming we'll need to split > up ini.xml and config.xml if we want to do this. Maybe > someone has a bright idea for dealing with this. > > All in all we can pretty much perform (c) but the others > require some thought (3). The script currently generates > test_ini.xml for each extension, and a chapters/test_ini.xml > for the rest. And chapters/config.master_test.xml for all. Wouldn't having a master ini set index be better, then presenting the same table elsewhere? [I have not tested the code, so I don't know what it actually generates, I am assuming:)]. For the descriptions, two things comes to mind: - Make the xml generating script intelligent, and replace the contents of the file, instead of rewrite, keeping the descriptions, which should probably be marked with XML comments for the parser to recognize (or placed in a well defined context ie. a para with a role="description") - Use a different XML file to associate descriptions with ini settings. This would be a non-DocBook XML file with associations such as: <ini_settings> <ini_setting name="extension_dir"> Specifies the folder, where extensions are searched for... </ini_setting> </ini_settings> The question here, is if we want to have DocBook markup in descriptions (probably some <variable>, <function> or other reference). That can probably perfectly be solved in XSLT, where we can easily modify the context, and let the styelsheets parse the XML part as DocBook. Positive effect of this include, that we can have the generating script be simple, as there would be no need to guess what part of a file is a description, and for what ini setting. Negative of this solution is that it is not native DocBook and we would probably need one file describing all ini settings to make the processing simple for XSLT, which would be far from our current focus to distribute content to the extension documantations. Goba