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 > > > > > 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.? > > > 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
