On 24 May 2010 16:00, Hannes Magnusson <hannes.magnus...@gmail.com> wrote:
> On Mon, May 24, 2010 at 03:25, Philip Olson <phi...@roshambo.org> wrote:
>>
>>>
>>> I can't get the errors locally, Considering we already throw away a
>>> LOT of errors regarding xinclude when things go wrong
>>> (print_xml_errors()), I can only suggest excluding the warnings from
>>> the xinclude() call in configure.php.
>>
>> I don't remember exactly why these errors were hidden before, maybe Hannes
>> remembers as he committed them.
>
> We don't care about xi:include errors.
> If they fail then we haven't lost anything - because the data didn't
> exist to begin with.
So, a hack would be to use @$dom->xinclude();
But ...
// xinclude will generate warnings like "XPointer evaluation failed:".
These can safely be ignored.
// But in case any other errors occur, pass them through our error
handler and re-instate the current
// libxml error handling.
$handlingLibxmlErrors = libxml_use_internal_errors(true);
$dom->xinclude();
print_xml_errors();
libxml_use_internal_errors($handlingLibxmlErrors);
could be an option also.
At this stage, I'm wondering why we don't simply collect all the errors ...
<?php libxml_use_internal_errors(true); ?>
and handle them ourselves
<?php print_xml_errors(); ?>
after each $dom call?
> IIRC we decided that the xi:fallback was useless because we didn't
> wan't to say "no inherited methods" (or something along those lines),
> so we simply ignored xi:include errors.
>
> The same thing applies to the new xi:includes, although I don't know
> why they generate different error string.
>
There are 336 xincludes in phpdoc/en. If an xinclude fails the
xfallback is a required child element. As there are no other
xfallbacks (except in CDATA examples), this suggests that all the
xpointer evaluations pass and therefore no errors are generated.
In the event that the xpointer evaluation doesn't return anything, the
"XPointer evaluation failed" warning is always thrown and the
xfallback kicks in. Supplying LIBXML_NOWARNING has no effect (I think
this flag relates only to the XML parser and not the xinclude/xpointer
work - I'm out of my depth with libxml2 code at this stage).
So, capturing the warnings and simply discarding them, just like we do
with other xinclude related warnings (which occur during document
loading) would seem to suffice.
> -Hannes
>
So. What would you like to do.
Related to this is the need to document non inheritable methods (final
private methods). Currently, the only one I've found is
Exception::__clone(). I've not been looking very hard.
<xi:include xpointer="xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.xxxxx')/db:refentry/db:refsec...@role='description']/descendant::db:methodsynopsis[not(@role='procedural')
and (modifier='final') and (modifier='private')])">
<xi:fallback />
</xi:include>
would cover it the xinclude, but I don't know how to wrap this to be
able to add a comment, or to exclude it from the classsynopsis.
Currently, final private methods are documented as part of the class
(http://docs.php.net/LogicException for example).
The __clone() method is neither part of nor callable from any
sub-class of Exception and shouldn't be documented as such.
Admittedly, when I get this all sorted, only non private methods will
be part of classsynopsis, and so we need to handle non inheritables.
Any ideas?
Richard.
--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
