Wez Furlong wrote:
Can you give a less abstract example of what this does in practice? Eg: "a b c" doesn't have much meaning in docbook ;)
I must be tired :)
My problem was this title :
<title>A string with &php; inside</title>
&php; defined as <literal>PHP</literal>.
a = title b = literal
in CVS, it's grabbed as : PHP
with the first patch, it's : A string with PHP
and with the third it's A string with PHP inside
In the patch, I keep the delimiter tag's name in memory ($this->tag_name) that is the first opening tag after the tag with the attribute id and I concatanate all cdatas until I find the delimiter once again.
There's maybe a problem with a structure like this (here a b c is meaningful ;) : <a>text<a>text</a>text</a>, but I doubt we'll face this case (we can't have nested <title>s). Why do you think about it ?
--Wez.
-----Original Message-----
From: Mehdi Achour [mailto:[EMAIL PROTECTED] Sent: 23 May 2004 08:52
To: Mehdi Achour
Cc: [EMAIL PROTECTED]
Subject: [PHP-DOC] Re: [patch] livedocs : Allowing entities in titles
Here's a better patch that solves this issue properly.
example with this string : <a>b<b>a</b>r</a>
before the first patch, the parser was doing this : * start when an opening tag with an id attribute is matched * seeks to the next closing tag, overwriting any previous grabbed data if there is another opening tag before any closing tag is found * stops with the first closing tag
the result was : a
with the first patch I corrected the overwriting problem, but didn't notice the problem with the non-matching closing tag, the result was :
a b
now it's a b c
