[xwiki-devs] [Discussion] Integrating officepreview module into main source tree
Hi Devs, I have almost completed my work on officepreview module and I would like to discuss about integrating it into main source tree (and release it with 2.4M1). There are a couple of things to discuss: 1. officepreview module have to depend on xwiki-core for the time being because with current component approach there is no way of determining the version of an attachment (officepreview module needs to know attachment version). 2. Need a couple of tests - I'm working on this. 3. Where to place the officepreview module in main source tree. My initial idea for (3) was to create a /platform/core/trunk/xwiki-officepreview submodule. However, since officepreview module depends on officeimporter module, I'm not sure if we should create a parent module that would host both of these projects. Another problem lingering in my mind is that with recent changes xwiki-officeimporter module encapsulates two sub modules - a module capable of converting documents from one format to another (this is a generic converter api kind of thing) and another module which is importing office documents into xwiki specific formats (XDOMOfficeDocumentBuilder, PresentationBuilder etc.). I'm not sure if these two modules should be seperated out, but may be that's a separate discussion. Please let me know your comments about above points. Thanks. - Asiri
Hi Asiri and all, On Jun 1, 2010, at 11:28 AM, Asiri Rathnayake wrote:
Hi Devs,
I have almost completed my work on officepreview module and I would like to discuss about integrating it into main source tree (and release it with 2.4M1). There are a couple of things to discuss:
1. officepreview module have to depend on xwiki-core for the time being because with current component approach there is no way of determining the version of an attachment (officepreview module needs to know attachment version).
Shouldn't we add a DAB method for this?
2. Need a couple of tests - I'm working on this.
Asiri, any update on this?
3. Where to place the officepreview module in main source tree.
platform/core IMO for now. Later, all office stuff should be refactored in xwiki-office module probably and be a submodule (or do this now).
My initial idea for (3) was to create a /platform/core/trunk/xwiki-officepreview submodule. However, since officepreview module depends on officeimporter module, I'm not sure if we should create a parent module that would host both of these projects.
Yes good idea.
Another problem lingering in my mind is that with recent changes xwiki-officeimporter module encapsulates two sub modules - a module capable of converting documents from one format to another (this is a generic converter api kind of thing) and another module which is importing office documents into xwiki specific formats (XDOMOfficeDocumentBuilder, PresentationBuilder etc.). I'm not sure if these two modules should be seperated out, but may be that's a separate discussion.
I haven't followed enough the design to reply on this yet. On another point, I'll take care of converting OfficePreviewVelocityBridge to a ScriptService. We need a service name. 2 solutions: Solution 1: ========= $services.office.preview(...) This means 3 build modules: - one for office converter (rename from office import) - one for office preview - one for office velocity (for unifying script services between office converter and office preview). This needs moving OfficeImporterVelocityBridge to a ScriptService too (which we need to do). Solution 2: ========= $services.officepreview.preview(....) + keep using $officeimporter for the office importer WDYT? Thanks -Vincent
Please let me know your comments about above points.
Thanks.
- Asiri
Hi, On Tue, Jun 29, 2010 at 4:00 PM, Vincent Massol <[email protected]> wrote:
Hi Asiri and all,
On Jun 1, 2010, at 11:28 AM, Asiri Rathnayake wrote:
Hi Devs,
I have almost completed my work on officepreview module and I would like to discuss about integrating it into main source tree (and release it with 2.4M1). There are a couple of things to discuss:
1. officepreview module have to depend on xwiki-core for the time being because with current component approach there is no way of determining the version of an attachment (officepreview module needs to know attachment version).
Shouldn't we add a DAB method for this?
+1
2. Need a couple of tests - I'm working on this.
Asiri, any update on this?
I will have the tests ready by this weekend. On another point, I'll take care of converting OfficePreviewVelocityBridge
to a ScriptService.
We need a service name. 2 solutions:
Solution 1: ========= $services.office.preview(...)
This means 3 build modules: - one for office converter (rename from office import) - one for office preview - one for office velocity (for unifying script services between office converter and office preview). This needs moving OfficeImporterVelocityBridge to a ScriptService too (which we need to do).
Solution 2: ========= $services.officepreview.preview(....) + keep using $officeimporter for the office importer
+1 for first solution. Thanks. - Asiri
Hi,
2. Need a couple of tests - I'm working on this.
Asiri, any update on this?
I will have the tests ready by this weekend.
I've committed few test cases and also refactored the code a bit (to make it easy to add tests). Let me know if they look ok. Also note that the officepreview macro (which makes it very easy to consume the officepreview service) is located at one of our customer sites [1]. Thanks. - Asiri [1] https://emc.devxwiki.com/xwiki/bin/view/XWiki/OfficePreviewMacro
On another point, I'll take care of converting OfficePreviewVelocityBridge
to a ScriptService.
We need a service name. 2 solutions:
Solution 1: ========= $services.office.preview(...)
This means 3 build modules: - one for office converter (rename from office import) - one for office preview - one for office velocity (for unifying script services between office converter and office preview). This needs moving OfficeImporterVelocityBridge to a ScriptService too (which we need to do).
Solution 2: ========= $services.officepreview.preview(....) + keep using $officeimporter for the office importer
+1 for first solution.
Thanks.
- Asiri
On Jul 4, 2010, at 7:03 PM, Asiri Rathnayake wrote:
Hi,
2. Need a couple of tests - I'm working on this.
Asiri, any update on this?
I will have the tests ready by this weekend.
I've committed few test cases and also refactored the code a bit (to make it easy to add tests). Let me know if they look ok.
Ok thanks, I'll have a look on Monday morning. I'll also work on doing the ScriptService thingie. We'll need to decide if we want this in RC1 or not since it's not a bug but a new feature.
Also note that the officepreview macro (which makes it very easy to consume the officepreview service) is located at one of our customer sites [1].
our = ? I guess you meant XWiki SAS.
Thanks.
- Asiri
[1] https://emc.devxwiki.com/xwiki/bin/view/XWiki/OfficePreviewMacro
I don't believe this is accessible to anyone and thus shouldn't be seen here on this list. Thanks -Vincent
On another point, I'll take care of converting OfficePreviewVelocityBridge
to a ScriptService.
We need a service name. 2 solutions:
Solution 1: ========= $services.office.preview(...)
This means 3 build modules: - one for office converter (rename from office import) - one for office preview - one for office velocity (for unifying script services between office converter and office preview). This needs moving OfficeImporterVelocityBridge to a ScriptService too (which we need to do).
Solution 2: ========= $services.officepreview.preview(....) + keep using $officeimporter for the office importer
+1 for first solution.
Thanks.
- Asiri
Hi,
Also note that the officepreview macro (which makes it very easy to consume
the officepreview service) is located at one of our customer sites [1].
our = ? I guess you meant XWiki SAS.
Thanks.
- Asiri
[1] https://emc.devxwiki.com/xwiki/bin/view/XWiki/OfficePreviewMacro
I don't believe this is accessible to anyone and thus shouldn't be seen here on this list.
Sorry about that, I should've communicated this privately with XWiki SAS. Thanks, - Asiri
participants (2)
-
Asiri Rathnayake -
Vincent Massol