On Thu, Nov 5, 2009 at 06:43, Arun Reddy <[email protected]> wrote:
Hi Thomas,
On Mon, Oct 12, 2009 at 8:50 PM, Thomas Mortagne <[email protected]>wrote:
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+Import...
- 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
Can we have a Descriptor class for these instead of having these methods inside WikiImporter. Something similiar to MacroDescriptor we can have WikiDescriptor.
WikiDescriptor::getName():String WikiDescriptor::getDescription():String WikiDescriptor::getParametersBeanClass():Class<?>
Sure do the same than macros, it's cleaner and more consistent that way. But it should be WikiImporterDescriptor I think, it's not a descriptor for a wiki ;)
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
-- Best Regards, Arun Reddy _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne