14 Oct
2009
14 Oct
'09
5:36 p.m.
On Wed, Oct 14, 2009 at 17:22, Arun Reddy <vipunreddy.n(a)gmail.com> wrote:
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Best Regards,
Arun Reddy
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
On Wed, Oct 14, 2009 at 8:41 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
You don't need an event for each property, event are more for
variables things, you can have onAttachment(name, version, content,
etc.). For revisions i already anwser in the previous mail, if you put
the onAttachement inside a begin/endWikiPageRevision you will only
have one version of the attachement for a version of wiki page.
On Wed, Oct 14, 2009 at 17:03, Arun Reddy
<vipunreddy.n(a)gmail.com> wrote:
If you plan to have something like
beginWikiPage(name)
beginObject(type)
onProperty(name, value, ...)
endObject()
beginObject()
onProperty()
endObject()
beginAttachment(name)
endAttachment()
endWikiPage()
+1 it's a good idea, now i'm not sure why you need begin and end for
an attachment, what other events would you have inside it ?
Because even it has few properties and revisions.
Kindly correct me, if am wrong. Hi,
On Mon, Oct 12, 2009 at 10:27 PM, Asiri Rathnayake <
asiri.rathnayake(a)gmail.com> wrote:
> Hi,
>
> Actually in my mind there was more than just this method, i see at least
> > also
> >
> > WikiImporterListener::onWikiPageAttachment(AttachmentName,
InputStream)
> >
> > since having the whole WikiPage with all its attachments in memory
> > make the import not strong enough if you have too big attachments.
> > Making a streaming API is about making every memory consuming part
> > streamed (Actually to be sure maybe also have
> > WikiImporterListener::onWikiPageObject(WikiPageObject) but since XWiki
> > does not support this well internally currently it's less important
> > than attachments).
> >
> > The getNextPage() API is good when you have only one simple kind of
> > data in a plane list but the events based way is more generic and
> > easier to implements for the importer writer IMO since it send the
> > events when he wants.
> >
>
> Ok, Now I understand that importer writers work would be easy if we go
with
> an event based API.
>
> So for Arun this means,
>
> 1. The model you proposed is ok
>
> 2. You need to refine the WikiImporter API so that it takes into account
> what we discussed here. This means:
>
> i) Have a mechanism for defining WikiImporter components with different
> requirements (look at the getParameters() approach suggested by Thomas)
>
> ii) Make the WikiImporter api mode stream oriented. I think you can
start
with
onWikiPage() & onAttachment() events for now.
- Can we have beginWikiPage() followed by endWikiPage()
beginAttachment() and endAttachment() rather than having a single
onWikiPage(),onAttachment() in the WikiImporterListener.
-How to handle revisions - Can we have methods to read those tags too.
one
for WikiPageRevision and other for
AttachmentRevision.
> I think you should start working on a revised proposal with this
> information
> taken into account. In the mean time other developers will comment on
this
> proposal if they have further suggestions.
>
> - Asiri
>
>
> > >
> > >
> > >> *** [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
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Best Regards,
Arun Reddy
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs