Hi Asiri, Asiri Rathnayake wrote: > Hello Devs, > > After few discussions I have revised the new officeimporter API to take into > account the use of DocumentName instead of plain strings for representing > document names. I'll repeat the details of the previous proposal with the > new changes applied: > > Currently we have the following officeimporter API: > > <code> > OfficeImporter::importStream(InputStream is, String documentFormat, String > targetDocumentName, Map params):void > OfficeImporter::importAttachment(String documentName, String attachmentName, > Map params):String > </code> > > Problems with this API: > > * Loosely typed (params, document names) > > * Both of the above methods perform almost the same task. > > * Customizing the import process is implemented in a hackish way. (not > visisble on the API) > > > The new API proposed looks like below: > > <code>
> OfficeImporter::officeToXHTML(byte[] officeFileData, DocumentName > referenceDocument, boolean filterStyles):XHTMLOfficeDocument Can you explain why you replaced InputStream with byte[]? Arrays require contiguous memory locations and loading large arrays into memory is bad IMO. Thanks, Marius > OfficeImporter::xhtmlToXDOM(XHTMLOfficeDocument > xhtmlOfficeDocument):XDOMOfficeDocument > OfficeImporter::officeToXDOM(byte[] officeFileData, DocumentName > referenceDocument, boolean filterStyles):XDOMOfficeDocument > OfficeImporter::buildPresentation(byte[] officeFileData):XDOMOfficeDocument > OfficeImporter::splitImport(XDOMOfficeDocument xdomOfficeDocument, int[] > headingLevelsToSplit, NamingCriterion namingCriterion, DocumentName > baseDocumentName):Map<TargetPageDescriptor, XDOMOfficeDocument> > </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 - > OfficeImporter::officeToXHTML() > > 2. Perform customizations on the XHTMLOfficeDocument - w3c DOM > manipulations. > > 3. Import the XHTMLOfficeDocument into XDOMOfficeDocument - > OfficeImporter::xhtmlToXDOM() > > 4. Perform customizations on the XDOMOfficeDocument (XDOM) - XDOM > manipulations. > > 5. Split the XDOMOfficeDocument into multiple XDOMOfficeDocument instances - > OfficeImporter::splitImport() > > 6. Perform customizations on these child XDOMOfficeDocument instances - XDOM > manipulations. > > 7. Render the XDOMOfficeDocument instances & save them into wiki pages - > XWiki rendering operations. > > I think this interface will make it easy to extend & maintain officeimporter > functionality in the future. > > Along with this, I would also like to refactor the xwiki-refactoring module > a bit to get rid of string based document names from it. > > > This whole refactoring operation would take approximately one day to > complete. And since this operation is not adding any new features, I think > it can be committed on both trunk and 2.0 branch. > > Here's my +1 to all of above. > > Thanks. > > - Asiri > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
