12 Oct
2009
12 Oct
'09
11:56 a.m.
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 :
http://gsoc.myxwiki.org/xwiki/bin/view/Import+Export+other+wikis/Wiki+Impor…
- A new Wiki model api ( Wiki, Wiki Page, Wiki Page Revision, Wiki
Attachment ) which adheres to XWiki Standards.
- 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne