On Tue, Oct 21, 2008 at 14:44, Maciek Sokolewicz <[EMAIL PROTECTED]> wrote:
> Hannes Magnusson wrote:
>>
>> On Mon, Oct 20, 2008 at 21:45, Philip Olson <[EMAIL PROTECTED]> wrote:
>>>
>>> On 19 Oct 2008, at 12:41, Hannes Magnusson wrote:
>>>
>>>> Hi all
>>>>
>>>> I created and uploaded a new package on our PEAR-channel, doc.php.net,
>>>> called "pman".
>>>
>>> There is one problem:
>>>
>>>  philip$ pear install doc.php.net/pman
>>>  downloading pman-1.0.0.tgz ...
>>>  Starting to download pman-1.0.0.tgz (3,810,407 bytes)
>>>  ..........done: 3,810,407 bytes
>>>  ERROR: bad md5sum for file
>>> /usr/local/pear/PEAR/docs/pman/man3/DomDocument.xinclude.3.gz
>>>  philip$
>>>
>>> Hannes and I determined it's likely due to a case insensitive file system
>>> because the following exists inside phd/package-pman.xml:
>>>
>>>  <file baseinstalldir="php.net" name="man3/DomDocument.xinclude.3.gz"
>>> role="doc" />
>>>  <file baseinstalldir="php.net" name="man3/DOMDocument.xinclude.3.gz"
>>> role="doc" />
>>>
>>> One for Dom, and the other for domxml. Let's see what a Windows user has
>>> to
>>> say... I use Mac.
>>
>>
>> And as of yet I have no idea how we can fix this.
>>
>> both ext/domxml (PHP4) and ext/dom (PHP5) define the "DOMDocument"
>> class and the "xinclude" method.
>> Fortunately the ext/domxml docs haven't been upgraded to use the new
>> OO-doc-style so there IDs are still "function.domdocument-xinclude"
>> while the ext/dom ID is "domdocument.xinclude" hence not causing any
>> conflicts.
>>
>> However, the unix man-page output format uses the <refname> to
>> generate the filenames, not the IDs, so you can write "pman strpos"
>> rather then "pman function.strpos".
>>
>> Short of renaming the ext/domxml refname to intentionally include an
>> typo I have no idea how we can fix this :(
>>
>> Btw: Since ext/domxml and ext/dom are so alike (both defining the
>> exact same classnames and the only difference in the methodnames are
>> camelCased vs under_scored) the documentation search for end-users
>> (either via php.net/short-syntax-lookup or via the "search" box) is
>> really sucky experience, never exactly knowing if they are browsing
>> the ext/dom or ext/domxml docs :(
>> This problem will partially be fixed by fixing the version
>> information, but then new problem arises: If a user has the
>> domelement->get_elements_by_tag_name page open and sees it is PHP4...
>> how is he supposed to know there is an PHP5 alternative?
>>
>> My vote goes to removing the ext/domxml docs, PHP4 is dead anyway and
>> those so crappy unfortunate needing to read PHP4 code (for whatever
>> reason, upgrading maybe) and check the manual for "WTF is going on"
>> will have to search "the attic" or something....
>>
>> -Hannes
>
> Or perhaps we could make our documentation based on PHP version like the
> mysql manual does. So we have a "different" manual for PHP6, PHP 5(.3), 5.2,
> one for PHP 4, etc. Then we could include /domxml in the PHP4 manual, and
> the dom in the PHP5 and 6 ones. You could add a small dropdown box at the
> top like we have with languages now to choose the PHP version you're looking
> into. You could also have that stored in a cookie via my php.net
> functionality.
> I'm pretty sure phD can be modified to output docs specific to versions if
> we properly assign versions and changelogs to all functionality.

Totally. I would really appreciate semi-version-specific manual, and I
think we've discussed it in the passed...
The actual markup change wouldn't have to be that dramatic, adding few
version attributes here and there would probably do the trick - and
then new options to PhD "--only-php5" "--all-versions"
"--php5-and-greater" or whatever..

The biggest problem would be the naming convention really,
function.strpos-php5.php? or function.strpos.php?version=5? What about
the html chunked output?

-Hannes

Reply via email to