[xwiki-devs] OfficeImporter-Wysiwyg-FileUpload
Devs, I've been brainstorming about implementing office importer functionality in wysiwyg where the user will be able to upload a document and have it's content imported into the current page being edited (i.e into the wysiwyg editor). Note that we already have the copy/paste functionality implemented. The first problem I see is that GWT doesn't have a way to upload a file with a usual RPC call. Given the parameters, following is one possible way out of this problem, 1. Define an OfficeImporterServlet which mapps to /xwiki/officeimporter 2. Let the office importer wysiwyg plugin make a POST request to this servlet with a FileUpload widget ( http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/user... ). 3. The servlet will import the document into xhtml and write back the result as the response. 4. Office importer wysiwyg plugin in turn takes the result and put it into the wysiwyg editor. And the second problem arises when there are non-textual content (ex. images) in the document submitted. In this case, office importer servlet must attach these files into the wiki page which is being edited. Now, if the user decides to cancel the whole edit operation just after the import operation, there must be a way to remove those attachments. How can we do this? (For the moment I don't know how to handle this case) Please let me know if you have any comments :) Thanks. - Asiri
Asiri Rathnayake wrote:
Devs,
I've been brainstorming about implementing office importer functionality in wysiwyg where the user will be able to upload a document and have it's content imported into the current page being edited (i.e into the wysiwyg editor). Note that we already have the copy/paste functionality implemented.
The first problem I see is that GWT doesn't have a way to upload a file with a usual RPC call. Given the parameters, following is one possible way out of this problem,
1. Define an OfficeImporterServlet which mapps to /xwiki/officeimporter 2. Let the office importer wysiwyg plugin make a POST request to this servlet with a FileUpload widget ( http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/user... ).
You don't necessarily have to have your own servlet for this, you could attach it to a wiki document, by posting to the "upload" action for the wiki document, with the appropriate field names. I'm doing this in the image plugin with the FileUploadForm. You could even have your own action to post to, similar to the "upload" only that it would invoke the importer plugin for the uploaded file and send back the results, although I'm not really sure this is a good idea, as actions are quite a core part of the wiki, and whose changing requires changes deep down (need to write your action and have it on the server, need to map it in the actions mapping file). Your servlet would require web.xml mapping too, so maybe it's quite the same. Or, in order to get the output back you can: 1. upload the file to the current document and, when the upload call returns, make a second call to the WywisygService to import the uploaded file and send back (x)html. 2. upload the file to an office importer special document, transform it and return it with the upload action result (I need to digg more on this to see how exactly would it be done). This solution would be hard to mix with the uploaded images in the file, as they won't be attached to the correct wiki document upon save, you'd need to move them. Of course, you could also use solution 1. with a special OfficeImporter document as a repository for all files uploaded which need to be imported. In both cases, uploaded attachment could be deleted after import.
3. The servlet will import the document into xhtml and write back the result as the response. 4. Office importer wysiwyg plugin in turn takes the result and put it into the wysiwyg editor.
And the second problem arises when there are non-textual content (ex. images) in the document submitted. In this case, office importer servlet must attach these files into the wiki page which is being edited. Now, if the user decides to cancel the whole edit operation just after the import operation, there must be a way to remove those attachments. How can we do this? (For the moment I don't know how to handle this case)
You couldn't just save the document in which you import the uploaded file? This would solve a couple of problems from the previous point, too. Otherwise, this problem is quite the same for any editing: the user does some edits, image uploads, inserts his / her image and then cancels. The images will stay attached to the page even if the content that uses them won't. One solution, not very clean and which I don't like, but would solve the problem, would be to give them special names which would help you to have a piece of code which could look for all unused such attachments and delete them. Or, with the (x)html content of the imported file, you could return to the importer plugin a list of images attached with that file which you'd delete upon cancel. Or you could just leave them there (could you?), as we do for all edit situations, as I mentioned. Happy coding, Anca
Please let me know if you have any comments :)
Thanks.
- Asiri _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi Anca, You don't necessarily have to have your own servlet for this, you could
attach it to a wiki document, by posting to the "upload" action for the wiki document, with the appropriate field names. I'm doing this in the image plugin with the FileUploadForm.
You could even have your own action to post to, similar to the "upload" only that it would invoke the importer plugin for the uploaded file and send back the results, although I'm not really sure this is a good idea, as actions are quite a core part of the wiki, and whose changing requires changes deep down (need to write your action and have it on the server, need to map it in the actions mapping file). Your servlet would require web.xml mapping too, so maybe it's quite the same.
Or, in order to get the output back you can: 1. upload the file to the current document and, when the upload call returns, make a second call to the WywisygService to import the uploaded file and send back (x)html. 2. upload the file to an office importer special document, transform it and return it with the upload action result (I need to digg more on this to see how exactly would it be done). This solution would be hard to mix with the uploaded images in the file, as they won't be attached to the correct wiki document upon save, you'd need to move them.
Of course, you could also use solution 1. with a special OfficeImporter document as a repository for all files uploaded which need to be imported.
Thanks for the idea :) We could do, 1. Upload the document into XWiki.OfficeImporter (The repository) 2. Have a GWT rpc call such as; String importDocument(String fileName, String targetPage); Here the fileName is the name of the attachment just added to XWiki.OfficeImporter and targetPage would be the name of the current wiki page being edited. As you said, the attached document itself can be deleted when the import is complete. (+ need to workaround name collisions with multiple users, but that's not a big issue IMO). Or you could just leave them there (could you?), as we do for all edit
situations, as I mentioned.
Hmmmm, yes that's possible too. I was wondering if it's not that nice. Let's see if others agree. Thanks. - Asiri
Hi again,
Thanks for the idea :) We could do,
1. Upload the document into XWiki.OfficeImporter (The repository) 2. Have a GWT rpc call such as;
String importDocument(String fileName, String targetPage);
Here the fileName is the name of the attachment just added to XWiki.OfficeImporter and targetPage would be the name of the current wiki page being edited.
As you said, the attached document itself can be deleted when the import is complete. (+ need to workaround name collisions with multiple users, but that's not a big issue IMO).
PS: spotted a small problem. Having two server calls (upload + rpc) is not a good idea because a client might fail in between the calls, leaving the attachments on the server. Note that this doesn't happen if we can have a separate servlet for officeimporter. (or if the upload action can be customized to pass additional parameters and return a result...) I will digg into it further tomorrow. Thanks. - Asiri
Hi Asiri, On Sun, Jan 25, 2009 at 8:24 PM, Asiri Rathnayake < asiri.rathnayake@gmail.com> wrote:
Hi Anca,
You don't necessarily have to have your own servlet for this, you could
attach it to a wiki document, by posting to the "upload" action for the wiki document, with the appropriate field names. I'm doing this in the image plugin with the FileUploadForm.
You could even have your own action to post to, similar to the "upload" only that it would invoke the importer plugin for the uploaded file and send back the results, although I'm not really sure this is a good idea, as actions are quite a core part of the wiki, and whose changing requires changes deep down (need to write your action and have it on the server, need to map it in the actions mapping file). Your servlet would require web.xml mapping too, so maybe it's quite the same.
Or, in order to get the output back you can: 1. upload the file to the current document and, when the upload call returns, make a second call to the WywisygService to import the uploaded file and send back (x)html. 2. upload the file to an office importer special document, transform it and return it with the upload action result (I need to digg more on this to see how exactly would it be done). This solution would be hard to mix with the uploaded images in the file, as they won't be attached to the correct wiki document upon save, you'd need to move them.
Of course, you could also use solution 1. with a special OfficeImporter document as a repository for all files uploaded which need to be imported.
Thanks for the idea :) We could do,
1. Upload the document into XWiki.OfficeImporter (The repository) 2. Have a GWT rpc call such as;
String importDocument(String fileName, String targetPage);
Here the fileName is the name of the attachment just added to XWiki.OfficeImporter and targetPage would be the name of the current wiki page being edited.
As you said, the attached document itself can be deleted when the import is complete. (+ need to workaround name collisions with multiple users, but that's not a big issue IMO).
Or you could just leave them there (could you?), as we do for all edit
situations, as I mentioned.
Hmmmm, yes that's possible too. I was wondering if it's not that nice.
I agree with Anca here. In usual edit situations, the user attachs files and images to the page then chooses whether or not to display them. In many cases the images stay attached to the pages even when not directly displayed to take advantage of the storage facility itself. Therefore, keeping the images added during the Office document import is not a problem. If the users really wants them off, he can delete the attachments afterwards. If there are a lot of images to delete that will take the user some time - but that's an issue with how we handle page attachments management (we could add checkboxes for instance), not with the office import part itself. So I really think you can leave the attachments where they are once uploaded. Another thing I've been wondering about: should we keep a copy of the original office document attached to the wiki page it has been converted to? It could be useful in some cases, when using a wiki page as a displayer for a document that can be edited through webdav in its original format and displayed on a wiki page for quick view... But maybe that makes more sense for presentations than for Word documents. [I know this is akin to thread hijacking - please move this part in another thread if planning a lengthy answer ;-)] Guillaume
Let's see if others agree.
Thanks.
- Asiri _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/
Hi Guillaume, Another thing I've been wondering about: should we keep a copy of the
original office document attached to the wiki page it has been converted to? It could be useful in some cases, when using a wiki page as a displayer for a document that can be edited through webdav in its original format and displayed on a wiki page for quick view... But maybe that makes more sense for presentations than for Word documents. [I know this is akin to thread hijacking - please move this part in another thread if planning a lengthy answer ;-)]
Ok, only now I realized what you meant.... yes this would be great! For an example on a wiki page someone would put: $officeimporter.importDocument($doc.fullName, "test.doc", true) and the return string would be xwiki 2.0 code for test.doc. (the final boolean flag is used to differentiate between html and xwiki2.0) This coupled with webdav would make page editing really easy. There are several issues we need to be concerned about: 1. Requires a live oo server running all the time. (ok) 2. Officeimporter will be invoked each time the page is loaded (not good) 3. Requires webdav ui integration. (ok) My concern is point 2, which is too much of an overhead. WDYT? Thanks. - Asiri
Hi, On Tue, Jan 27, 2009 at 10:30 AM, Asiri Rathnayake < asiri.rathnayake@gmail.com> wrote:
Hi Guillaume,
Another thing I've been wondering about: should we keep a copy of the
original office document attached to the wiki page it has been converted to? It could be useful in some cases, when using a wiki page as a displayer for a document that can be edited through webdav in its original format and displayed on a wiki page for quick view... But maybe that makes more sense for presentations than for Word documents. [I know this is akin to thread hijacking - please move this part in another thread if planning a lengthy answer ;-)]
Ok, only now I realized what you meant.... yes this would be great! For an example on a wiki page someone would put:
$officeimporter.importDocument($doc.fullName, "test.doc", true)
and the return string would be xwiki 2.0 code for test.doc. (the final boolean flag is used to differentiate between html and xwiki2.0)
Exactly :-) But as I stated it, this might make more sense for presentations and spreadsheets than for text since the WYSIWYG editor is meant to let the user edit text in the wiki.
This coupled with webdav would make page editing really easy. There are several issues we need to be concerned about:
1. Requires a live oo server running all the time. (ok) 2. Officeimporter will be invoked each time the page is loaded (not good)
I could see 2 solutions: 1. Caching + a "force refresh" button included in the macro that calls the document (I don't know how hard this is to do) 2. Use the non-filtered xhmtl output to soften the server load a bit User will hit the button repeatedly only in near real-time situations, when they want to see their work online right away. Thus heavy load happens only for a short period of time. When they're done working, the document is cached and it renders as a classic wiki page.
3. Requires webdav ui integration. (ok)
My concern is point 2, which is too much of an overhead.
WDYT?
In any case, that's not a priority. I've got a couple other ideas regarding improvements we could bring to the Office Importer, I'll start a new thread to discuss them. Guillaume
Thanks.
- Asiri _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/
+1 for using the upload action. Anca Paula Luca wrote:
Asiri Rathnayake wrote:
Devs,
I've been brainstorming about implementing office importer functionality in wysiwyg where the user will be able to upload a document and have it's content imported into the current page being edited (i.e into the wysiwyg editor). Note that we already have the copy/paste functionality implemented.
The first problem I see is that GWT doesn't have a way to upload a file with a usual RPC call. Given the parameters, following is one possible way out of this problem,
1. Define an OfficeImporterServlet which mapps to /xwiki/officeimporter 2. Let the office importer wysiwyg plugin make a POST request to this servlet with a FileUpload widget ( http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/user... ).
You don't necessarily have to have your own servlet for this, you could attach it to a wiki document, by posting to the "upload" action for the wiki document, with the appropriate field names. I'm doing this in the image plugin with the FileUploadForm.
You could even have your own action to post to, similar to the "upload" only that it would invoke the importer plugin for the uploaded file and send back the results, although I'm not really sure this is a good idea, as actions are quite a core part of the wiki, and whose changing requires changes deep down (need to write your action and have it on the server, need to map it in the actions mapping file). Your servlet would require web.xml mapping too, so maybe it's quite the same.
Or, in order to get the output back you can: 1. upload the file to the current document and, when the upload call returns, make a second call to the WywisygService to import the uploaded file and send back (x)html. 2. upload the file to an office importer special document, transform it and return it with the upload action result (I need to digg more on this to see how exactly would it be done). This solution would be hard to mix with the uploaded images in the file, as they won't be attached to the correct wiki document upon save, you'd need to move them.
Of course, you could also use solution 1. with a special OfficeImporter document as a repository for all files uploaded which need to be imported.
In both cases, uploaded attachment could be deleted after import.
3. The servlet will import the document into xhtml and write back the result as the response. 4. Office importer wysiwyg plugin in turn takes the result and put it into the wysiwyg editor.
And the second problem arises when there are non-textual content (ex. images) in the document submitted. In this case, office importer servlet must attach these files into the wiki page which is being edited. Now, if the user decides to cancel the whole edit operation just after the import operation, there must be a way to remove those attachments. How can we do this? (For the moment I don't know how to handle this case)
You couldn't just save the document in which you import the uploaded file? This would solve a couple of problems from the previous point, too.
Otherwise, this problem is quite the same for any editing: the user does some edits, image uploads, inserts his / her image and then cancels. The images will stay attached to the page even if the content that uses them won't.
One solution, not very clean and which I don't like, but would solve the problem, would be to give them special names which would help you to have a piece of code which could look for all unused such attachments and delete them.
Or, with the (x)html content of the imported file, you could return to the importer plugin a list of images attached with that file which you'd delete upon cancel.
Or you could just leave them there (could you?), as we do for all edit situations, as I mentioned.
Happy coding, Anca
Please let me know if you have any comments :)
Thanks.
- Asiri _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi All, After discussing with Anca, Marius and Guillaume we have decided to use the following approach, 1. Upload the office document as an attachment to the current wiki page (using the upload action). 2. Make a second rpc call to officeimporter passing it the name of the wiki page and the attachment: Ex: String importDocument(String pageName, String attachmentName); 3. The officeimporter will import the document and return the resulting html fragment which will be inserted into the editor. Any images contained within the document will be attached into the wiki page by the officeimporter. Let us know if you have any comments. Thanks. - Asiri
participants (4)
-
Anca Paula Luca -
Asiri Rathnayake -
Guillaume Lerouge -
Marius Dumitru Florea