On Sun, Jan 10, 2010 at 05:57, Arun Reddy <[email protected]> wrote:
Hi,
On Sun, Jan 10, 2010 at 4:04 AM, Thomas Mortagne <[email protected]>wrote:
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 ?
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 ) :)
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.
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.
?
I have the second one in my mind.
>
>
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
-- Arun Reddy _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne