Re: ini autogeneration ( getPHP_INI_ENTRY.php )

> > 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. Hehe, I cannot contribute to this right now, or anytime in the near future... > > 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) So then we are talking about the same thing. I said that we should have the information in one place and the master list should only have pointers [links] instead of the information [descriptions] themselfs. BTW I still think that huge table-like data is for the appendix. Every book has these kind of things in appendixes. > > 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. This is fine with me. The automatic ini update script should be adjusted to this. > 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. I guess this is not high priotity. And it will probably be easier to integrate this check to the generator script itself, as it will need to grep out the descriptions anyway, and it will have live and immediate data on what ini setting has no description... > 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? There is no problem with this format. The generation script should be adjusted to understand it, and extract the descriptions before generating a new file, and then reeject the descriptions into the right places ;) Goba