On Sat, Jan 9, 2010 at 06:11, Arun Reddy <[email protected]> wrote:
> Hi,
>
> On Fri, Jan 8, 2010 at 4:58 PM, Thomas Mortagne
> <[email protected]>wrote:
>
>> On Wed, Jan 6, 2010 at 20:22, Arun Reddy <[email protected]> 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 attributes
> ). 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
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 ?
>
>>
>> >
>> > 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.?
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.
>
> >
>> > 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
>> > [email protected]
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >
>>
>>
>>
>> --
>> Thomas Mortagne
>> _______________________________________________
>> devs mailing list
>> [email protected]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>
> --
> Arun Reddy
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
