Re: ini autogeneration ( getPHP_INI_ENTRY.php )

> > 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 ;)) Many but not all. I still think we should simply use the constant table appended to the original message in this thread rather than worry about all of this but if someone feels so inclined to automate then that's good too. > > 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:)]. The code generates ini.xml for each section and this is our current setup anyways but I'm unsure exactly what you mean here (I think we're miscommunicating a little :) Since the current ini.xml's were all done by hand during the split this problem is new. The only master table we have currently lives in the ini_set docs which IMHO should be moved elsewhere as something like chapters/config.all.xml So: en/{extension}/ini.xml (per extension) en/chapters/config.xml (misc) en/chapters/config.all.xml (currently in ini_set docs, a table that links to ini.xml's and lacks descriptions) This is basically already how it's done presently, not proposing anything new here except a new location for the master list and possible references to ini.xml Well, dealing with descriptions is new :) > 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") This would be nice. We could start and end the description section with something like <!-- start description --> ... as it's already separate from the ini tables. AFAICT only config.xml has multiple sections of each. Also, we will want a checkini.php to list which directives lack descriptions although this certainly would not be part of make test. > - 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. Currently all descriptions are listed as a varlisting, isn't that good (and simple) enough? For example: <varlistentry id="ini.zlib.output-compression-level"> <term> <parameter>zlib.output_compression_level</parameter> <type>integer</type> </term> <listitem> <para> Compression level used for transparent output compression. </para> </listitem> </varlistentry> It seems we don't need to introduce anything new here, we should be good to go. In fact, the ini table is a <table> and the descriptions are in <variablelist> format so how convenient is that! I didn't realize this until after reading your words, do you feel this changes things? Regards, Philip