On Mon, Oct 12, 2009 at 11:56, Thomas Mortagne <[email protected]> wrote: > On Mon, Oct 12, 2009 at 08:48, Arun Reddy <[email protected]> wrote: >> Hi Devs, >> >> As the existing Wiki Importer ( GSOC PROJECT - SANDBOX >> <http://svn.xwiki.org/svnroot/xwiki/sandbox/gsoc/importexport/>) have >> few set backs in architecture, i would like to make a proposal to >> modify and enhance to make it better. > > Great ! > >> >> Here is my proposal : >> >> http://gsoc.myxwiki.org/xwiki/bin/view/Import+Export+other+wikis/Wiki+Importer+Enhancement >> >> - A new Wiki model api ( Wiki, Wiki Page, Wiki Page Revision, Wiki >> Attachment ) which adheres to XWiki Standards.
Here is some quick review comments: General: * this API is not streaming oriented, WikiImporter.import should take listener and not send a full Wiki for example. This api is nice but as a wrapper for the streaming api (like SAX and DOM or XWiki rednering events and XDOM). * Wiki Importer ** you should add some more informationnal methods to use in the UI or to make easier to do a generic tool like: *** String getName() : the pretty name of the importer *** String getDescriptions(): a description of the importer *** [NICE TO HAVE] List<Class<?>> getParameters(): the list of parameters type to provide to the importer, that way you can generate a UI based on it since parameters totally depends on the importer, you could have an importer able to import the wiki from an URL for example using REST/XMLRPC... for the same reason List<InputStream> is not generic enough IMO. You can look at MacroDescriptor for inspiration, we could make it more generic as a list of parameters instead of a list of macro parameters to use it in wiki importer, authenticators, etc. I see this tool as a generic way to get wiki content from any kind of external source, we could even use it to copy a XWiki wiki without having to do an export/import by hand for example. >> >> - Separation of Import process, Parsing the import data into a abstract wiki >> model will be a component. Clients can use it to make their own custom >> implementation. This abstract model is used by the other XWiki component / >> client code (Groovy & velocity ) to load the data into XWiki with standard >> features and little customization (like Preserving history, default names, >> attachments etc.. ). > > +1 > > Always good to separate as much as possible every aspect of the > process in different components. > >> >> >> - Using the existing XWiki model api or xwiki-bridge rather than coming up >> with a new one. >> But the issues here is, i dont have all the things which are needed and it >> has lot more methods which are of no use in import process. Can i proceed >> with a custom wiki model like this. ? > > Main problem is that you need a XDOM based model instead of a String > content based model right ? The current model will definitely don't > fit this, too bad the new model is not advanced enough. Also the > current model is too linked to the storage so it will not be easy to > do a clean stream based process. > > I would say do you own clean custom model and we will see latter for > refactor with the new model. > >> >> >> - As wiki importer process large streams of data, would it be wise to design >> the API more stream oriented and include few stream oriented methods.? > > Big +1 for stream oriented, the "normal" importer should be stream > based also IMO. Denis Gervalle is currently working on making the > whole export process and its dependencies stream oriented (See > http://markmail.org/message/vzfdkteguzselouy). > > It's definitely the way to go. We can always to a wrapper api which is > using the stream based api if we need a not stream based tools but the > other way around is not possible so better to do now the more generic > one. > >> >> >> I would like to have your suggestions on this. >> >> >> Thanks >> -Arun Reddy >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > Thomas Mortagne > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
