ID:               24861
 Updated by:       [EMAIL PROTECTED]
 Reported By:      tim at zer0-interactive dot com
 Status:           Assigned
 Bug Type:         Documentation problem
 Operating System: N/A
 PHP Version:      Irrelevant
 Assigned To:      goba
 New Comment:

verdy_p, you also submitted a duplicate. What bug do we choose from
multiple issues dealing with the same problem is upon is. It is not the
earliest timestamp we choose, but it is the most relevant bug report.
The xml.in file itself does not solve the problem, since there are no
tools currently supporting the building of the docs with that
structure.

This bug is not forgotten, just noone had the time yet to take care of
it. If you are willing to help, you could equally offer your time as
others do in this project.


Previous Comments:
------------------------------------------------------------------------

[2004-08-09 13:05:17] verdy_p at wanadoo dot fr

This bug is quite old and I reported it 2 years ago:
http://bugs.php.net/bug.php?id=17164
Nothing was done about it, and bug 17164 was forgotten.
Now bug 17164 is closed (it was not bogous as stated now, but is now a
duplicate with this newer bug report).
before this bug was incorrectly reopened here.

The solution proposed here with the xml.in file seems good and replies
correctly to bug report 17164...

------------------------------------------------------------------------

[2004-08-08 19:57:38] [EMAIL PROTECTED]

The suggested and soon to be implemented grouping is here:

  http://cvs.php.net/co.php/phpdoc/RFC/manual.xml.in

Livedocs needs to be able to handle this type of TOC on the index page
(and elsewhere). We are not going to implement support for this in the
DSSSL or XSLT sheets IMHO.

------------------------------------------------------------------------

[2003-07-30 05:03:45] [EMAIL PROTECTED]

I can assure you that such a categorization will be in place, hopefully
in the near future. We are working on a better manual presentation
system for our website (and all mirror sites), which will include
categorized listing of extensions too. This is planned for a long time,
but we need more time to complete the background programs.

Assigning to myself, I will close this bug, when the solution is in
place (despite that I will not implement the solution ;).

------------------------------------------------------------------------

[2003-07-29 17:50:06] tim at zer0-interactive dot com

Description:
------------
This isn't so much a problem with any piece of documentation in
particular, but rather the usability of the documentation as a whole.

Having watched PHP grow over the last few years and trying to keep on
top of the numerous extensions that keep appearing over time, it is
getting increasingly hard to detirmine what each extension is for
without going further into the documentation to read about it.  I would
say that is more of a problem with non *nix developers who may not have
heard of what some of the extensions are and what they are for.

In light of this, I think that it would be beneficial, particularly for
the newbie developer, if the online documentation where organised
slightly differently.  Namely in the area of categorising the function
reference section into high level chunks.

Take for example the following question: what different databases does
php support?  This is not an easy question to answer unless you know
what all the extensions do first when you are reading through the
index.

If it were reorganised slightly so it was something like this:

Database Functions
   . MySQL Server Functions
   . MS SQL Server Functions
   . ODBC Functions
Filesystem Functions
   . Directory Functions
   . File Functions

An addition to this format would be the ability to collapse these
sections on the page so that you do not have this massive list staring
back at you.

The documentation provided so far has been great, but I think the
format of the index is holding it back from growing much further while
still making it easy to locate what you are looking for.  This index
format would bring it into consistency with indexes such as how the
PEAR packages are listing.  A high level category with the actual
packages listing inside those categories.

I believe this indexing solution to accomdate not only for future
growth of the documentation, but also makes it easier to use while
still maintaining the integrity of the current documentation.



------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=24861&edit=1

Reply via email to