[wp-trac] [WordPress Trac] #22435: Export API

[WordPress Trac]

#22435: Export API
--------------------------+------------------------------
 Reporter:  nbachiyski    |       Owner:
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Export        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  dev-feedback  |
--------------------------+------------------------------

Comment (by nbachiyski):

 Going deeper, here are some notes on a sample implementations: classes and
 public methods are listed here with some reasoning behind them.

 There are three layers:
  * Export Data
  * XML Generation – takes data and turns it into WXR XML
  * Writer – takes XML and gives it to the user

 In the beginning I tried to make them only 2, but the upper layer class
 was getting huge and also was doing two very different tasks, so I split
 them up.

 {{{{class WP_WXR_Export}}} – represents a set of posts and other site data
 to be exported
 Public methods:
  * {{{__construct( $filters )}}} – creates the object and queries for the
 data specified by the filters.
  * {{{get_xml()}}} – returns the export as a string of XML
  * {{{export_to_xml_file( $file_name )}}}
  * {{{export_to_xml_files( $destination_directory, $filename_template,
 $max_file_size = null )}}}
  * {{{serve_xml( $file_name )}}} – outputs the necessary HTTP headers and
 then the export as XML
  * {{{export_xml_using_writer_class( $writer_class_name, $writer_args )}}}
 – exports the XML data, but uses a custom writer, not one of the above
  * {{{export_using_writer( $writer )}}} –  if we want to use a writer,
 which isn't coupled with the XML generator, we can pass the  writer object
 here directly
  // we have also some methods to get the raw, but structured data
  * {{{post_ids()}}} – the post ids of the posts, which will be exported,
 based on the filters
  * {{{posts()}}} – returns an iterator over the posts, not an array
  * {{{charset()}}}
  * {{{site_metadata()}}} – title, description, language, URLs, etc.
  * {{{authors()}}}
  * {{{categories()}}}
  * {{{tags()}}}
  * {{{custom_taxonomies_terms()}}}
  * {{{nav_menu_terms()}}}

 {{{class WP_WXR_XML_Generator}}} – responsible for generating WXR XML from
 export data (aka {{{WP_WXR_Export}}})
 Public methods:
  * {{{__construct( $export )}}} – it needs to know where to get the export
 data from
  * {{{before_posts()}}} – returns the XML from the start to the posts
 definitions
  * {{{posts()}}} – returns an iterator, which on each iteration returns
 the XML for a post
  * {{{after_posts}}} – returns the XML after the posts definitions
  * more fine-grained access to the XML of different parts in case the
 writer needs it: {{{header}}}, {{{site_metadata}}}, {{{authors}}},
 {{{categories}}}, etc.

 For most of the writers (even for all I've written) the before/after posts
 distinction is good enough, but we'll have the more fine-grained methods,
 so it wouldn't hurt to expose them.

 {{{class WP_WXR_*_Writer}}} – responsible for putting the XML from the
 generator to some useful place – STDOUT, a file, mutliple files, zip file,
 network, whatever.

 {{{class WP_WXR_Base_Writer}}} – abstract base class with default export
 functionality
  * {{{__construct( $xml_generator )}}} – it needs to know where to get the
 XML from
  * {{{abstract protected write( $xml )}}} – writes a small piece of XML
 somewhere
  * {{{export()}}} –  passes all the data from the XML generator to the
 write method

 After writing a couple of writers, I found I wanted to be able to change
 these two main aspects: where am I writing (to a file, to STDOUT, etc.)
 and what's the logic of what I'm writing (just at once, stop when the file
 is too big and start a new one, etc.)

 Feedback on the classes, their relationships, naming, etc. would be very
 much appreciated.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/22435#comment:4>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software