[xwiki-devs] [GSoC]Try the Office Importer Plugin
Hi Vincent & all, I finish the clean of the plugin code and write a simple user manual. You can see it in http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter#HQuickStart. All files needed for this plugin can be found in that page http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter, except the openoffice install . Please give some feedback after try the plugin. Any feedback will be very appreciated. This plugin is very initial. It only put out the html code , not xwiki syntax, because the html code to xwiki syntax conversion should be done by XHTMLParser which is not ready yet. Open question: Now the plugin can handle the file which is uploaded to xwiki as a attachment. Do you think it's necessary that the office importer would have the upload feature itself or should provide a XWikiAction something like "bin/importer/Main/page"? Now the plugin can work. However it's a little complicate. If you want to convert a office document 1. you first upload the document 2. copy the attachment name(because the name of document change after upload) 3. edit the page and add the velocity code to use the importer plugin 4. save and view. I think it should be more simple. WDYT -- Sincerely, Wang Ning
Hi Wang,
[snip]
I'm looking forward testing your work !
Now the plugin can work. However it's a little complicate. If you want to convert a office document 1. you first upload the document 2. copy the attachment name(because the name of document change after upload) 3. edit the page and add the velocity code to use the importer plugin 4. save and view. I think it should be more simple.
So do I :-) There is 2 ways we can go about doing this : the page action way and the application way. 1. Page action : we add an "import" action in the menu at the top of the page (and maybe in the WYSIWYG editor as well). When clicking on the button, the user is prompted to choose a compatible file on his machine, then he clicks on "import" (with an interface similar to the one used for uploading attachments). The .../bin/import/Main/... is called, and the content from the file appended at the bottom of the existing page, with a #info('') macro at the top saying something like "The following content has been imported to the page :" 2. Application : we create an OfficeImport application with the following components : a homepage where the user is prompted to import one or multiple documents. The documents are then imported, each creting its own wiki page. Once the importation is complete, the user is prompted to move the documents to their new locations (using the Rename or the copy feature to implement this) The benefits of going the page way is that it's probably more intuitive for users. However it means adding core changes = less flexibility in the long run. And the action bar already has a lot of items ;-) OTOH going the application way woud make the application easier to setup (plugin + XAR), store all the pages in a dedicated place and make it possible to import many documents at once and sort things out at a later stage. However it makes it a bit longer to import a file to a given page and might be less intuitive... WDYT ? Guillaume
On Mon, Jul 7, 2008 at 5:27 PM, Guillaume Lerouge <[email protected]> wrote:
Hi Wang,
[snip]
I'm looking forward testing your work !
Now the plugin can work. However it's a little complicate. If you want to convert a office document 1. you first upload the document 2. copy the attachment name(because the name of document change after upload) 3. edit the page and add the velocity code to use the importer plugin 4. save and view. I think it should be more simple.
So do I :-)
There is 2 ways we can go about doing this : the page action way and the application way.
1. Page action : we add an "import" action in the menu at the top of the page (and maybe in the WYSIWYG editor as well). When clicking on the button, the user is prompted to choose a compatible file on his machine, then he clicks on "import" (with an interface similar to the one used for uploading attachments). The .../bin/import/Main/... is called, and the content from the file appended at the bottom of the existing page, with a #info('') macro at the top saying something like "The following content has been imported to the page :"
This action way is easy to implement as I can get whatever I want to use by using java. But as you said, change the xwiki-core is not a good idea. However, I can get the byte[] data of the source office doument without using attachment.
2. Application : we create an OfficeImport application with the following components : a homepage where the user is prompted to import one or multiple documents. The documents are then imported, each creting its own wiki page. Once the importation is complete, the user is prompted to move the documents to their new locations (using the Rename or the copy feature to implement this)
The application way is good and decouple. However there are some problem too. I want to get the name of the attachment after upload the office document as the name of the document changed by the xwiki.clearName(). But the util.clearName() don't provide the same result. Do I need to add another clearName model in api util? Alternately, I just provide a select type input in the importer page which contain all the attachments in the page for use to select the source attachments.
The benefits of going the page way is that it's probably more intuitive for users. However it means adding core changes = less flexibility in the long run. And the action bar already has a lot of items ;-)
OTOH going the application way woud make the application easier to setup (plugin + XAR), store all the pages in a dedicated place and make it possible to import many documents at once and sort things out at a later stage. However it makes it a bit longer to import a file to a given page and might be less intuitive...
WDYT ?
Guillaume _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Sincerely, Wang Ning
Wang Ning wrote:
On Mon, Jul 7, 2008 at 5:27 PM, Guillaume Lerouge <[email protected]> wrote:
Hi Wang,
[snip]
I'm looking forward testing your work !
Now the plugin can work. However it's a little complicate. If you want to convert a office document 1. you first upload the document 2. copy the attachment name(because the name of document change after upload) 3. edit the page and add the velocity code to use the importer plugin 4. save and view. I think it should be more simple.
So do I :-)
There is 2 ways we can go about doing this : the page action way and the application way.
1. Page action : we add an "import" action in the menu at the top of the page (and maybe in the WYSIWYG editor as well). When clicking on the button, the user is prompted to choose a compatible file on his machine, then he clicks on "import" (with an interface similar to the one used for uploading attachments). The .../bin/import/Main/... is called, and the content from the file appended at the bottom of the existing page, with a #info('') macro at the top saying something like "The following content has been imported to the page :"
This action way is easy to implement as I can get whatever I want to use by using java. But as you said, change the xwiki-core is not a good idea. However, I can get the byte[] data of the source office doument without using attachment.
2. Application : we create an OfficeImport application with the following components : a homepage where the user is prompted to import one or multiple documents. The documents are then imported, each creting its own wiki page. Once the importation is complete, the user is prompted to move the documents to their new locations (using the Rename or the copy feature to implement this)
The application way is good and decouple. However there are some problem too. I want to get the name of the attachment after upload the office document as the name of the document changed by the xwiki.clearName(). But the util.clearName() don't provide the same result. Do I need to add another clearName model in api util? Alternately, I just provide a select type input in the importer page which contain all the attachments in the page for use to select the source attachments.
I don't think you need to go through the save as attachment at all.. You can use the FileUpload plugin... http://svn.xwiki.org/svnroot/xwiki/xwiki-platform/core/trunk/xwiki-core/src/... which allows to retrive a file upload element withough saving it as an attachment.. You retrieve it as a byte[] Ludovic
The benefits of going the page way is that it's probably more intuitive for users. However it means adding core changes = less flexibility in the long run. And the action bar already has a lot of items ;-)
OTOH going the application way woud make the application easier to setup (plugin + XAR), store all the pages in a dedicated place and make it possible to import many documents at once and sort things out at a later stage. However it makes it a bit longer to import a file to a given page and might be less intuitive...
WDYT ?
Guillaume _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Wang Ning wrote:
Now the plugin can work. However it's a little complicate. If you want to convert a office document 1. you first upload the document 2. copy the attachment name(because the name of document change after upload) 3. edit the page and add the velocity code to use the importer plugin 4. save and view. I think it should be more simple.
So do I :-)
There is 2 ways we can go about doing this : the page action way and the application way.
1. Page action : we add an "import" action in the menu at the top of the page (and maybe in the WYSIWYG editor as well). When clicking on the button, the user is prompted to choose a compatible file on his machine, then he clicks on "import" (with an interface similar to the one used for uploading attachments). The .../bin/import/Main/... is called, and the content from the file appended at the bottom of the existing page, with a #info('') macro at the top saying something like "The following content has been imported to the page :"
This action way is easy to implement as I can get whatever I want to use by using java. But as you said, change the xwiki-core is not a good idea. However, I can get the byte[] data of the source office doument without using attachment.
It is true that now it is hard to add new actions in the code, but in the future plugins would be able to provide their own actions, without changing the code. Still, the only changes needed are: - assigning a rights level, but the default one is "edit", which I think is a good level for the import action, so there's no need to change this - registering the action in struts-config.xml, but that is not something hard to do; it is on the same level as registering the plugin in xwiki.cfg
2. Application : we create an OfficeImport application with the following components : a homepage where the user is prompted to import one or multiple documents. The documents are then imported, each creting its own wiki page. Once the importation is complete, the user is prompted to move the documents to their new locations (using the Rename or the copy feature to implement this)
The application way is good and decouple. However there are some problem too. I want to get the name of the attachment after upload the office document as the name of the document changed by the xwiki.clearName(). But the util.clearName() don't provide the same result. Do I need to add another clearName model in api util? Alternately, I just provide a select type input in the importer page which contain all the attachments in the page for use to select the source attachments.
You could simply get the name of the last attachment. Personally, I'd go the action way. It is not as modular and easily-integrable as it should, but in the (1.7-1.8?) future this will change. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi, I've tested the importer.. Installation and running it went fine ! Pretty cool. The documents where well imported in HTML with images attached and converted. Some bugs: - a documents with accents was showing the accents in UTF-8 when my wiki is ISO-8869-1. A conversion needs to be done. Some remarks: - it would be nice that the application can launch OO itself - you also need to write your code so that it can call the web service version of jodconverter - the application way would be nice to demonstrate and test the tool: a file upload, you choose the page and the document is added at the end of the page - one of the features of the conversion should be to convert any OO to HTML or PDF and should be integrated as links next to attachment (view as HTML or view as PDF). Also there could be a macro to integrate the HTML conversion in the middle of the page. Similar to {attach} but would embed the document directly in the page. So you should make sure your API allows to not only convert to wiki but also to any format. Ludovic Wang Ning wrote:
Hi Vincent & all,
I finish the clean of the plugin code and write a simple user manual. You can see it in http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter#HQuickStart. All files needed for this plugin can be found in that page http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter, except the openoffice install . Please give some feedback after try the plugin. Any feedback will be very appreciated. This plugin is very initial. It only put out the html code , not xwiki syntax, because the html code to xwiki syntax conversion should be done by XHTMLParser which is not ready yet.
Open question: Now the plugin can handle the file which is uploaded to xwiki as a attachment. Do you think it's necessary that the office importer would have the upload feature itself or should provide a XWikiAction something like "bin/importer/Main/page"? Now the plugin can work. However it's a little complicate. If you want to convert a office document 1. you first upload the document 2. copy the attachment name(because the name of document change after upload) 3. edit the page and add the velocity code to use the importer plugin 4. save and view. I think it should be more simple.
WDYT
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
All I replies below are going to be consider in my next work. On Mon, Jul 7, 2008 at 7:28 PM, Ludovic Dubost <[email protected]> wrote:
Hi,
I've tested the importer.. Installation and running it went fine ! Pretty cool. The documents where well imported in HTML with images attached and converted.
Some bugs: - a documents with accents was showing the accents in UTF-8 when my wiki is ISO-8869-1. A conversion needs to be done.
I have no idea about the xwiki encoding system but I will learn it. I'll keep this encoding problem in mind. Can you give me some detail suggestion? Thanks very much.
Some remarks: - it would be nice that the application can launch OO itself
I can do this:)
- you also need to write your code so that it can call the web service version of jodconverter
You mean invoke a conversion service in a remote machine? I will create a remote service converter class which implement the abstract converter to do this. Use which converter can be configured in xwiki.cfg
- the application way would be nice to demonstrate and test the tool: a file upload, you choose the page and the document is added at the end of the page
I am planning to do in the application way:)
- one of the features of the conversion should be to convert any OO to HTML or PDF and should be integrated as links next to attachment (view as HTML or view as PDF).
The conversion between many formats is considered but I don't think I can do it know. I will retain some useful interface for this feature. I will public the interface to list for comment. WDYT?
Also there could be a macro to integrate the HTML conversion in the middle of the page. Similar to {attach} but would embed the document directly in the page. So you should make sure your API allows to not only convert to wiki but also to any format.
Yes, this kind of api is my first thought and I implement it. The problem is that, if I use the {import: test.doc} to insert the html code of conversion to the page, the conversion method will be *invoked everytime* when the page refresh. How to deal with this problem. I have not develop a macro but I think I can do it. Can you give me some sample?
Ludovic
Wang Ning wrote:
Hi Vincent & all,
I finish the clean of the plugin code and write a simple user manual. You can see it in http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter#HQuickStart. All files needed for this plugin can be found in that page http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter, except the openoffice install . Please give some feedback after try the plugin. Any feedback will be very appreciated. This plugin is very initial. It only put out the html code , not xwiki syntax, because the html code to xwiki syntax conversion should be done by XHTMLParser which is not ready yet.
Open question: Now the plugin can handle the file which is uploaded to xwiki as a attachment. Do you think it's necessary that the office importer would have the upload feature itself or should provide a XWikiAction something like "bin/importer/Main/page"? Now the plugin can work. However it's a little complicate. If you want to convert a office document 1. you first upload the document 2. copy the attachment name(because the name of document change after upload) 3. edit the page and add the velocity code to use the importer plugin 4. save and view. I think it should be more simple.
WDYT
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Sincerely, Wang Ning
Wang Ning wrote:
All I replies below are going to be consider in my next work. On Mon, Jul 7, 2008 at 7:28 PM, Ludovic Dubost <[email protected]> wrote:
Hi,
I've tested the importer.. Installation and running it went fine ! Pretty cool. The documents where well imported in HTML with images attached and converted.
Some bugs: - a documents with accents was showing the accents in UTF-8 when my wiki is ISO-8869-1. A conversion needs to be done.
I have no idea about the xwiki encoding system but I will learn it. I'll keep this encoding problem in mind. Can you give me some detail suggestion? Thanks very much.
You should read $xwiki.encoding and make sure you convert to that encoding anything that you put in wiki pages (that's not true for attachments).
Some remarks: - it would be nice that the application can launch OO itself
I can do this:)
- you also need to write your code so that it can call the web service version of jodconverter
You mean invoke a conversion service in a remote machine? I will create a remote service converter class which implement the abstract converter to do this. Use which converter can be configured in xwiki.cfg
Yes and we would need this to pass firewalls which means being in HTTP and with proxy settings..
- the application way would be nice to demonstrate and test the tool: a file upload, you choose the page and the document is added at the end of the page
I am planning to do in the application way:)
- one of the features of the conversion should be to convert any OO to HTML or PDF and should be integrated as links next to attachment (view as HTML or view as PDF).
The conversion between many formats is considered but I don't think I can do it know. I will retain some useful interface for this feature. I will public the interface to list for comment. WDYT?
I've commited some code that does it.. I think you should make the code more modular and one calling the other.. Concerting to HTML is just a subset case of conversion.
Also there could be a macro to integrate the HTML conversion in the middle of the page. Similar to {attach} but would embed the document directly in the page. So you should make sure your API allows to not only convert to wiki but also to any format.
Yes, this kind of api is my first thought and I implement it. The problem is that, if I use the {import: test.doc} to insert the html code of conversion to the page, the conversion method will be *invoked everytime* when the page refresh. How to deal with this problem. I have not develop a macro but I think I can do it. Can you give me some sample?
Yes but we can include a cache of the conversion at the wiki level Ludovic
Ludovic
Wang Ning wrote:
Hi Vincent & all,
I finish the clean of the plugin code and write a simple user manual. You can see it in http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter#HQuickStart.
All
files needed for this plugin can be found in that page http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter, except the openoffice install . Please give some feedback after try the plugin. Any feedback will be very appreciated. This plugin is very initial. It only put out the html code , not xwiki syntax, because the html code to xwiki syntax conversion should be done
by
XHTMLParser which is not ready yet.
Open question: Now the plugin can handle the file which is uploaded to xwiki as a attachment. Do you think it's necessary that the office importer would
have
the upload feature itself or should provide a XWikiAction something like "bin/importer/Main/page"? Now the plugin can work. However it's a little complicate. If you want to convert a office document 1. you first upload the document 2. copy the attachment name(because the name of document change after upload) 3. edit the page and add the velocity code to use the importer plugin 4. save and view. I think it should be more simple.
WDYT
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Ludovic Dubost wrote:
- you also need to write your code so that it can call the web service version of jodconverter
You mean invoke a conversion service in a remote machine? I will create a remote service converter class which implement the abstract converter to do this. Use which converter can be configured in xwiki.cfg
Yes and we would need this to pass firewalls which means being in HTTP and with proxy settings..
If you use standard JDK HTTP methods, then the proxy settings would be detected by the JVM, or configured at the JVM level, so there's no need for your code to handle the proxy settings. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Wang Ning wrote:
Also there could be a macro to integrate the HTML conversion in the middle of the page. Similar to {attach} but would embed the document directly in the page. So you should make sure your API allows to not only convert to wiki but also to any format.
Yes, this kind of api is my first thought and I implement it. The problem is that, if I use the {import: test.doc} to insert the html code of conversion to the page, the conversion method will be *invoked everytime* when the page refresh. How to deal with this problem. I have not develop a macro but I think I can do it. Can you give me some sample?
You can look at com.xpn.xwiki.plugin.charts.ChartingMacro, com.xpn.xwiki.plugin.graphviz.GraphVizMacro and com.xpn.xwiki.plugin.svg.SVGMacro (they also contain caching code). -- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (4)
-
Guillaume Lerouge -
Ludovic Dubost -
Sergiu Dumitriu -
Wang Ning