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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
