Hi,
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). > I kind of had a different idea about the streaming api. I don't know why I thought this but what I had in mind was something like: Wiki::hasNextPage():boolean Wiki::getNextPage():WikiPage This is kind of like reading a result set (pull-parsing???) I thought this kind of a api would be more natural but I have no idea if this is even possible to implement for all the wiki export formats out there. If I understood you correct, what you have suggested is something like: WikiImporterListener::onWikiPage(WikiPage) WikiImporter::import(......, WikiImporterListener) This might be viewed as a "push-parsing" mechanism?? Anyway, I'll be glad to know what are the pros & cons of these two approaches. > *** [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. > +1 This will make it possible to define different types of importers with different requirements (rather than restricting them to List<InputStream>) Thanks. - Asiri _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
