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