10 Jan
2010
10 Jan
'10
2:04 p.m.
On Sun, Jan 10, 2010 at 05:57, Arun Reddy <vipunreddy.n(a)gmail.com> wrote:
Hi,
On Sun, Jan 10, 2010 at 4:04 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
No, what i mean is that WikiImporterParser#parse is useless in the
API. The user of the wiki importer should only call
WikiImporter#importWiki(Parameters Class Object, WikiImporterListener)
and receive all needed events for the whole wiki. I don't see the
point of having this WikiImporterParser#parse method at all.
Said that its useless to have WikiImporterParser#parse method. It shouldnt be
exposed to WikiImporter User in API
(or)
not to have it internally, i mean
WikiImporter#importWiki(Parameters Class Object, WikiImporterListener)
makes call to WikiImporterParser#parse internally inside its implementation.
A wiki importer implementation is doing anything it wants internally,
my point is that it should not be part of the public API.
On Sat, Jan 9, 2010 at 06:11, Arun Reddy
<vipunreddy.n(a)gmail.com> wrote:
attributes
The point of extending Listener is to handle document content. For
example a client would receive something like:
beginWikiPage
beginWikiPageRevision
beginDocument
beginParagraph
onWord
onSpace
onWord
endParagraph
endDocument
endWikiPageRevision
endPage
beginDocument -> endDocument are document content events in a generic
format (the event version of XDOM). That way the client receive
everything he needs to reconstruct the whole wiki in a purely generic
form (no specific syntax), it's WikiImporter responsibility to do all
the needed parsing and conversion to send the proper events to send
valid events representing a complete wiki in WikiImporterListener.
Said another way: Listener describe a document content and
WikiImporterListener extends it to describe the whole wiki.
It's not clear in your proposal how you where planning to send the
document content. Is it one of the onProperty ?
Yes, all the document content is handled using onProperty Tag.
But extending Listener and implementing XDOM events makes it more complete
( Its missing in the proposed API ) :)
Hi,
On Fri, Jan 8, 2010 at 4:58 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
> On Wed, Jan 6, 2010 at 20:22, Arun Reddy <vipunreddy.n(a)gmail.com>
wrote:
> Hi
Devs,
>
> I have implemented an API for Wiki Importer.
>
> The main component is org.xwiki.wikiimporter.WikiImporter
> **WikiImporterDescriptor getDescriptor()
> **void importWiki(Object object, WikiImporterListener listener)
> **WikiImporterType getType()
>
> Wiki Call back event listener:
org.xwiki.wikiimporter.WikiImporterListener
> **void beginWikiPage(String pageName, Map<String, String> params)
How Map<String, String> params is used ? If it's supposed to receive
document informations like author, date, etc... i think it's should be
well defined and typed parameters in a WikiPageParameters (otherwise
there would be too much parameters in the method and it would not be
easy to extends) instead of Map<String, String> params for example.
Otherwise i don't see how you can use them if each importer can send
any kind of document metadata. You can keep Map<String, String> params
as custom parameters but we need at least a bunch of known page
metadatas in a WikiPageParameters.
No, not for author or date etc.. Some wiki specific metadata related to
page and
other elements, like Id, ClassName. ( in short element ). As org.xwiki.rendering.Listener follows
Map<String,String> parameters.
I
have followed the same.
In almost all the cases, the metadata ( author,date, comments,
labels/tags
etc.. ) is handled with onProperty() event.
But its a good idea to use WikiPageParameters. I shall implement it.
> > **void beginWikiPageRevision(String pageName, int revision,
Map<String,
> > String> params)
> > **void beginObject(String objectType, Map<String, String> params)
> > **void onProperty(String property, Map<String, String> params, String
> value)
> > **void endObject(String objectType, Map<String, String> params)
> > **void endWikiPageRevision(String pageName, int revision, Map<String,
> > String> params)
> > **void endWikiPage(String pageName, Map<String, String> params)
> > **void beginAttachment(String attachmentName, Map<String, String>
param)
> > **void onAttachmentRevision(String
attachmentName, Map<String, String>
> > params, InputSource input)
> > **void endAttachment(String attachmentName, Map<String, String>
params)
Something is not explicit in your mail: WikiImporterListener extends
org.xwiki.rendering.listener.Listener to send page content events
right ?
The WikiImporterListener doesn't extend
org.xwiki.rendering.listener.Listener , because i never felt the need for
all those methods. I have come up with a custom listener in the lines of
org.xwiki.rendering.listener.Listener
>
> WikiImporter parser for parsing documents (eg: XML ) :
> org.xwiki.wikiimporter.WikiImporterParser
> **void parse(InputSource source, WikiImporterListener listener) throws
> WikiImporterParseException
This sound like an implementation details. From public API user POV
WikiImporter#importWiki(Parameters Class Object, WikiImporterListener
) is enough no need to go deeper, the importer then parse documents
internally the way it wants to. Another reason is that "InputSource
source" would be way too limited: for example I'm thinking of
importers getting resources from another wiki directly online (XMLRPC,
REST, etc...), it could also be a folder containing several files for
each document (like content in a txt and objects in xml files), etc.
Ok, Yes InputSource can't handle all the cases.
Can i use a custom
WikiImporterInputSource extending InputSource class.? ?
I have the second one in my mind.
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Arun Reddy
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
>
> > WikiImporter velocity bridge :
> > org.xwiki.wikiimporter.WikiImporterVelocityBridge
> > **public WikiImporterTypeFactory getWikiImporterTypeFactory()
> > **public WikiImporter getWikiImporter(String wikiImporterType) throws
> > WikiImporterException
> >
> > WikiImporter type factory has methods to handle the supported other
wiki
> > formats/types. :
org.xwiki.wikiimporter.WikiImporterTypeFactory
> > **WikiImporterType createTypeFromIdString(String wikiImporterType)
throws
> > WikiImporterException
> > **List<WikiImporterType> getAvailableTypes() throws
WikiImporterException
> >
> > This is a typical use case in my mind.
> >
> > 1. Get WikiImporterFactory instance with
> > WikiImporterVelocityBridge#getWikiImporterFactory
> > 2. Call the WikiImporterTypeFactory#getAvailableTypes() --> can be
used
> > at UI level to show the supported
types ( MediaWiki XML, XMLRPC
etc
> .. )
> > 3. Select the format type and call
> > WikiImporterVelocityBridge#getWikiImporter(String wikiImporterType)
to
> get
> > selected WikiImporter instance.
> > 4. Use the WikiImporterDescriptor to generate the UI. ( Similiar to
> > MacroDescriptor)
> > 5. User enters all the parameters ( UI )
> > 6. Call WikiImporter#importWiki(Parameters Class Object,
> > WikiImporterListener ) to start the import process. Parameters Class
> has all
> > the required parameters for WikiImporter
> > 7. Parser parses and WikiImporterListener events are fired.
> >
> >
> > The next step would be to create xwiki pages on the fly( one at a
time
-
> at
> > every WikiImporterListener#endWikiPage() event. )
> >
> > Remaining : API to import the generated WikiPages into XWiki
> >
> > Is it good idea to use a component which makes use of document bridge
to
> > import the Wiki Pages, Attachments etc..
into XWiki. If not, what will
be
> the
best way to do it?
Yes you should have a component for that but implemented in a separate
module that depends on xwiki-core because the bridge is too limited
for that so and it will be a pain. We can later refactor the
implementation to use the new model and it's ready.
>
> --
> Arun Reddy
> _______________________________________________
> 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
--
Arun Reddy
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs