Task #5161

Return type of getImportContentHandler needs to be specified

Added by Karsten Dambekalns almost 12 years ago. Updated about 11 years ago.

Should have
Start date:
Due date:
% Done:


Estimated time:


From the jackalope mailing list:

There is also getImportContentHandler() which in Java returns
org.xml.sax.ContentHandler - what would that be best in PHP terms?

We should define our own content handler that implements an sax like
interface using something like the xml event handlers here.

For the current jackalope phase I suggest to not implement that feature.
Since I currently don't see a use case for us and it appears to be a bigger

I will also leave this as not implemented, but we probably still should
have an idea on what to return from that method. I'd suggest to return a
ready-to-use configured instance of what xml_parser_create() gives you.
You could then do:

$handler = $workspace->getImportContentHandler('/import/root', ImportUUIDBehaviorInterface::IMPORT_UUID_CREATE_NEW);

$fp = fopen($url, 'r');
while(!feof($fp)) {
  $line = fgets($fp, 4096);
  xml_parse($handler, $line);

What do you think?

While I agree, that it needs something event based to make that method useful, using just the sax extension (php.net/xml) of php would be quite limiting. In the javaworld you can do your own sax-push-parser with a class without even having an XML file. With using the xml extension, It just can do xml documents/files

I therefore propose to "invent" a SAX Interface, which can be extended and someone can subscribe to it's events (like in sax), but on the other side, someone can push those events (not like in the sax case).

The interface should be as easy as possible and something like http://java.sun.com/j2se/1.4.2/docs/api/org/xml/sax/XMLReader.html or http://java.sun.com/j2se/1.4.2/docs/api/org/xml/sax/Parser.html but those 2 examples are certainly over-object-ified for PHP.

The first and example implementation of that interface would be a wrapper for the xml/sax extension mentioned above)

I don't know, if I find the time to "invent" something like that (I also didn't find anything on the net for such a beast), but as we won't implement that feature right now, it may be enough to just state: ... interface phpcr_xml_sax or something like that and come up with the actual implementation later.

And IIRC this will not be the only place, where there's a org.xml.sax.ContentHandler is needed.


Updated by Karsten Dambekalns almost 12 years ago

  • Status changed from Accepted to Resolved
  • % Done changed from 0 to 100

Applied in changeset r3363.

Also available in: Atom PDF