Re: AW: AW: [PEAR-DEV] PACKAGE PROPOSAL: XML_XMLPull

Been having a look at what I can do with XML_Parser and things get a little tricky... On Sat, 13 Sep 2003 21:28:52 +0200, Stephan Schmidt <schst@php-tools.net> wrote:

Hi,

class XML_Pull extends XML_Parser { var $stack = array(); var $i = 0; function &parse() { return @$this->stack[++$this->i]; }

Will be working, but could be done better :-) With large files, you are building a huge array before you get any events back. You can get some memory problems doing this...

As Stephan points out above, with large files you get a huge array, because XML_Parser reads to the end of the file. I'd forgotten the reason why I used the PEAR::XML_SaxFilters IO iterators but this reminds me - they make sure that the array is only built up to the current end of the parsed buffer so no problem with large documents.

I was reffering to the Stream_Var package.

I know what you were talking about, but the streams Harry is using is already in PEAR in his XML_SaxFilters package, take a look at XML/SaxFilters/IO/StringReader.php Stephan

I would like to use Stream_Var but think being only able to work with variables relative to the global scope is a serious problem - how do you parse a string which only lives inside a class method for example? I tried this approach originally (http://www.phppatterns.com/index.php/article/articleview/67/1/11/) and it's great from the end user point of view but I think Wez Furlong will need to modify the way stream_wrapper_register works so that it does something like create an instance of the wrapper class, allowing the string to be stored as a property of the instance perhaps. To without Stream_Var, the other "problem" I have with XML_Parse is that strings are seperate from files (the parse_string() method). How about this - fix the problem Jesus found at the start, ditch the XMLEvent and subclasses to use an array instead, as Alan suggested, and see what you all think from there? Also I'll do my best to use XML_Parser somehow but it's tricky to do so and be able to support XML_HTMLSax, so I can't promise anything. With XML_HTMLSax and the html_parse extension (http://pear.php.net/package- info.php?package=html_parse), that makes three (including Expat) SAX based parsers available - may be XML_Parser could be updated to have one abstract parent and sub classes for each concrete parser? Doing that without breaking the API might be tricky though.