5 Nov
2009
5 Nov
'09
6:43 a.m.
Hi Thomas,
On Mon, Oct 12, 2009 at 8:50 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
On Mon, Oct 12, 2009 at 11:56, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
http://gsoc.myxwiki.org/xwiki/bin/view/Import+Export+other+wikis/Wiki+Impor…
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<?>
list of
On Mon, Oct 12, 2009 at 08:48, Arun Reddy
<vipunreddy.n(a)gmail.com>
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 :
>
> >
> - 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 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.
up
design
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Best Regards,
Arun Reddy
> - 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 > 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 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne