[xwiki-devs] [PROPOSAL] OfficeImporter API changes for 2.1

Hi Devs, I've been refactoring OfficeImporter code base to make it more modular and maintainable. With these refactorings I believe we can improve the main OfficeImporter API. Currently OfficeImporter component interface exposes following two methods: <code> void importStream(InputStream documentStream, String documentFormat, String targetWikiDocument, Map<String, String> params) throws OfficeImporterException; String importAttachment(String documentName, String attachmentName, Map<String, String> params) throws OfficeImporterException; </code> Problems with these two methods are; * Loosely typed (params) * Both of them perform almost the same task. There is also a problem with how customizations to the normal import process is implemented. So, I propose we deprecate these two methods and introduce following methods: <code> XHTMLOfficeDocument officeToXHTML(byte[] officeFileData, String referenceDocument, boolean filterStyles) throws OfficeImporterException; XDOMOfficeDocument xhtmlToXDOM(XHTMLOfficeDocument xhtmlOfficeDocument) throws OfficeImporterException; XDOMOfficeDocument officeToXDOM(byte[] officeFileData, String referenceDocument, boolean filterStyles) throws OfficeImporterException; XDOMOfficeDocument buildPresentation(byte[] officeFileData) throws OfficeImporterException; Map<TargetPageDescriptor, XDOMOfficeDocument> splitXDOM(XDOMOfficeDocument xdomOfficeDocument, int[] headingLevelsToSplit, String namingCriterionHint, String baseDocumentName) throws OfficeImporterException; </code> As you can see, these methods are more granular and the responsibilities are well defined. Customizing the import process can be done from the client code. For an example: 1. Make the initial import from office to XHTMLOfficeDocument. 2. Perform customizations on the XHTMLOfficeDocument (w3c DOM). 3. Import the XHTMLOfficeDocument into XDOMOfficeDocument. 4. Perform customizations on the XDOMOfficeDocument (XDOM). 5. Split the XDOMOfficeDocument into multiple XDOMOfficeDocument instances. 6. Perform customizations on these child XDOMOfficeDocument instances. 7. Render the XDOMOfficeDocument instances & save them into wiki pages. (saving can be done in client code) I think this interface will make it easy to extend & maintain officeimporter functionality in the future. For an example, a preview function can be implemented with above methods (which is not possible with the previous interface). WDYT? Here's my +1. Thanks. - Asiri