Hi devs, Due to some critical bugs and missing features, the release was postponed for a long period. Still the development process is way ahead of what was intended for XWord 1.0 This is how the old roadmap looked like: http://dev.xwiki.org/xwiki/bin/view/Design/MicrosoftOfficeAddin#HFirstversio... As you can see XWord 1.0 was intended to be an export to wiki tool and only XWord 1.1 should enable editing wiki pages. Sorry for not keeping you up to date on the mailing list. This is the new roadmap for XWord: - 1.0 M1 - Wiki Explorer - done - Attachment Upload - done - Attachment Download - done - Export word documents - done - Edit/Save wiki pages - done - Save pages with user specified syntax - done - Protect essential pages from editing - done - Export using filtered html - done - Export with non-filtered html - buggy - Deployment and infrastructure - problematic because it uses ClickOnce. - 1.0 M2 - 2-3 weeks from M1 - Solve as many reported bugs - Improve html filters - Introduce the XML-RPC communication mode - Basic macro support(prevent the user from editing macro generated html) - 1.0 RC1 - 1-2 weeks from M2 - Bug fixing - Stable and ergonomic UI - Remove the sever package and rely only on XML-RPC - 1.0 Final - 1-2 - Rock solid UI - Production quality html output and wiki syntax conversion. Please tell me your opinion. Thanks, Florin
Florin Ciubotaru wrote:
Hi devs,
Due to some critical bugs and missing features, the release was postponed for a long period.
Still the development process is way ahead of what was intended for XWord 1.0 This is how the old roadmap looked like: http://dev.xwiki.org/xwiki/bin/view/Design/MicrosoftOfficeAddin#HFirstversio...
As you can see XWord 1.0 was intended to be an export to wiki tool and only XWord 1.1 should enable editing wiki pages. Sorry for not keeping you up to date on the mailing list. This is the new roadmap for XWord: - 1.0 M1 - Wiki Explorer - done - Attachment Upload - done - Attachment Download - done - Export word documents - done - Edit/Save wiki pages - done - Save pages with user specified syntax - done - Protect essential pages from editing - done - Export using filtered html - done - Export with non-filtered html - buggy - Deployment and infrastructure - problematic because it uses ClickOnce.
quite a long M1. You could also think about making it installable anyway (not necessarily through a very nice and easy process -- but with a visible enough warning and appropriate instructions) so that you finally have people using it anyway and helping you on bug report / feature design.
- 1.0 M2 - 2-3 weeks from M1 - Solve as many reported bugs - Improve html filters - Introduce the XML-RPC communication mode - Basic macro support(prevent the user from editing macro generated html) - 1.0 RC1 - 1-2 weeks from M2 - Bug fixing - Stable and ergonomic UI - Remove the sever package and rely only on XML-RPC - 1.0 Final - 1-2 - Rock solid UI - Production quality html output and wiki syntax conversion.
Please tell me your opinion. Thanks, Florin
+1, sounds good. Happy coding, Anca
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Anca, Anca Paula Luca wrote:
Florin Ciubotaru wrote:
Hi devs,
Due to some critical bugs and missing features, the release was postponed for a long period.
Still the development process is way ahead of what was intended for XWord 1.0 This is how the old roadmap looked like: http://dev.xwiki.org/xwiki/bin/view/Design/MicrosoftOfficeAddin#HFirstversio...
As you can see XWord 1.0 was intended to be an export to wiki tool and only XWord 1.1 should enable editing wiki pages. Sorry for not keeping you up to date on the mailing list. This is the new roadmap for XWord: - 1.0 M1 - Wiki Explorer - done - Attachment Upload - done - Attachment Download - done - Export word documents - done - Edit/Save wiki pages - done - Save pages with user specified syntax - done - Protect essential pages from editing - done - Export using filtered html - done - Export with non-filtered html - buggy - Deployment and infrastructure - problematic because it uses ClickOnce.
quite a long M1.
You could also think about making it installable anyway (not necessarily through a very nice and easy process -- but with a visible enough warning and appropriate instructions) so that you finally have people using it anyway and helping you on bug report / feature design.
XWord is installable since December and it is available at: http://incubator.myxwiki.org/xwiki/bin/view/XWord/ The problem is that the it's deployment is not compatible with the common XWiki.org release process and infrastructure.
- 1.0 M2 - 2-3 weeks from M1 - Solve as many reported bugs - Improve html filters - Introduce the XML-RPC communication mode - Basic macro support(prevent the user from editing macro generated html) - 1.0 RC1 - 1-2 weeks from M2 - Bug fixing - Stable and ergonomic UI - Remove the sever package and rely only on XML-RPC - 1.0 Final - 1-2 - Rock solid UI - Production quality html output and wiki syntax conversion.
Please tell me your opinion. Thanks, Florin
+1, sounds good.
Happy coding, Anca
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Florin, On Feb 20, 2009, at 4:43 PM, Florin Ciubotaru wrote:
Hi devs,
Due to some critical bugs and missing features, the release was postponed for a long period.
Still the development process is way ahead of what was intended for XWord 1.0 This is how the old roadmap looked like: http://dev.xwiki.org/xwiki/bin/view/Design/MicrosoftOfficeAddin#HFirstversio...
As you can see XWord 1.0 was intended to be an export to wiki tool and only XWord 1.1 should enable editing wiki pages. Sorry for not keeping you up to date on the mailing list. This is the new roadmap for XWord: - 1.0 M1
What is the release date planned for 1.0M1?
- Wiki Explorer - done - Attachment Upload - done - Attachment Download - done - Export word documents - done - Edit/Save wiki pages - done - Save pages with user specified syntax - done - Protect essential pages from editing - done
What is this?
- Export using filtered html - done
Isn't this already done by the Office importer HTML cleaner? We'd need to find ways so that you can reuse this to prevent code duplication (and it's a complex domain).
- Export with non-filtered html - buggy - Deployment and infrastructure - problematic because it uses ClickOnce. - 1.0 M2 - 2-3 weeks from M1 - Solve as many reported bugs - Improve html filters - Introduce the XML-RPC communication mode
What is this? Any advantage of using XMLRPC vs REST? (I don't have a preference but since we have both I'm wondering).
- Basic macro support(prevent the user from editing macro generated html)
It looks like you'd be recoding what is currently existing in the wysiwyg editor. While this is nice to have it in word, I'm wondering what it's going to cost to maintain the 2 features.
- 1.0 RC1 - 1-2 weeks from M2 - Bug fixing - Stable and ergonomic UI - Remove the sever package and rely only on XML-RPC
What is the "server package"?
- 1.0 Final - 1-2 - Rock solid UI - Production quality html output and wiki syntax conversion.
If you succeed in using the server side version of html/wiki syntax conversion tools then you'll get rock solid stuff with no maintenance need on your side. WDYT? Thanks -Vincent
Hi Vincent, Thanks for the reply. See bellow: Vincent Massol wrote:
Hi Florin,
On Feb 20, 2009, at 4:43 PM, Florin Ciubotaru wrote:
Hi devs,
Due to some critical bugs and missing features, the release was postponed for a long period.
Still the development process is way ahead of what was intended for XWord 1.0 This is how the old roadmap looked like: http://dev.xwiki.org/xwiki/bin/view/Design/MicrosoftOfficeAddin#HFirstversio...
As you can see XWord 1.0 was intended to be an export to wiki tool and only XWord 1.1 should enable editing wiki pages. Sorry for not keeping you up to date on the mailing list. This is the new roadmap for XWord: - 1.0 M1
What is the release date planned for 1.0M1?
This is not established. In terms of development XWord is ready for release. Manual publishing works fine, automatic doesn't. What we need to to is to see if OW2 can be used as a location for the clickOnce binaries and manifests. It also depends if you want CI before or after M1.
- Wiki Explorer - done - Attachment Upload - done - Attachment Download - done - Export word documents - done - Edit/Save wiki pages - done - Save pages with user specified syntax - done - Protect essential pages from editing - done
What is this?
This means that you cannot open in Word some specific pages that provide functionality to the wiki. Eg: The pages in XWiki, Stats or Blog spaces. Note: There is no api for identifying these pages. This was ok for XEclipse as it targets developers and wiki syntax editing, but in the case of XWord which is created for non-technical users, a method to protect these pages is required.
- Export using filtered html - done
Isn't this already done by the Office importer HTML cleaner? We'd need to find ways so that you can reuse this to prevent code duplication (and it's a complex domain).
Word can output html in two modes: filtered or not filtered. The filtered html size is about 10% of the not-filtered html, but it losses data from embedded elements(diagrams, shapes, expressions and charts). Additionally I created filters and adapters that are applied at different stages of the conversion. The steps are: Saving a document to the wiki: Word Supported Format -> WordML <-> HTML -> WikiSyntax Opening a wiki page: WikiSyntax -> HTML <- > WordML [-> Other format] The conversion from and into wiki syntax is done on the server. I can program against all the other data formats and set options on the transformation from one format to another. For this I'm using Word API or custom developed functionalities. IMO this has a better chance of success then a server oriented filter. Note that Word html is different from OOo html, so the filters that could be used for XWord are the filters implemented for the "Paste from Word" feature of the WYSIWYG. If we get these filters to provide high quality bidirectional saving and data preservation, then yes we can use then for XWord.
- Export with non-filtered html - buggy - Deployment and infrastructure - problematic because it uses ClickOnce. - 1.0 M2 - 2-3 weeks from M1 - Solve as many reported bugs - Improve html filters - Introduce the XML-RPC communication mode
What is this? Any advantage of using XMLRPC vs REST? (I don't have a preference but since we have both I'm wondering).
XWord does not depend on a specific implementation for client-server communication. I can be easily changed. What is important is to have a fully featured API. I will create a separate thread for this.
- Basic macro support(prevent the user from editing macro generated html)
It looks like you'd be recoding what is currently existing in the wysiwyg editor. While this is nice to have it in word, I'm wondering what it's going to cost to maintain the 2 features.
I'm only referring to making macro generated content read-only. IMO, this is not nice to have, it's mandatory, as without it, the user will damage every page that contains a macro. Marius: is this implemented on the server or on the client for the WYSIWYG? If it's on the server then it would be great to reuse it for XWord. :) If not, then I see no other option then to do something similar on .net.
- 1.0 RC1 - 1-2 weeks from M2 - Bug fixing - Stable and ergonomic UI - Remove the sever package and rely only on XML-RPC
What is the "server package"?
It's a collection of wiki pages that contain the services used by XWord. In the absence of a fully featured and actual api, velocity + groovy remains the most powerful way of extending or communicating with xwiki. See: http://incubator.myxwiki.org/xwiki/bin/view/XWord/
- 1.0 Final - 1-2 - Rock solid UI - Production quality html output and wiki syntax conversion.
If you succeed in using the server side version of html/wiki syntax conversion tools then you'll get rock solid stuff with no maintenance need on your side.
WDYT?
The html/wiki syntax is already done at the server. Sorry, but I'll give a -1 for Word html cleaning on the server, at least at it's current state.
Thanks -Vincent
Hi Florin, Florin Ciubotaru wrote: [snip]
- Basic macro support(prevent the user from editing macro generated html)
It looks like you'd be recoding what is currently existing in the wysiwyg editor. While this is nice to have it in word, I'm wondering what it's going to cost to maintain the 2 features.
I'm only referring to making macro generated content read-only. IMO, this is not nice to have, it's mandatory, as without it, the user will damage every page that contains a macro. Marius: is this implemented on the server or on the client for the WYSIWYG? If it's on the server then it would be great to reuse it for XWord. :)
It's done on the client-side. At most you can try to use the same technique I use, but I doubt it's going to work in Word. Let's talk about this Monday. Thanks, Marius
If not, then I see no other option then to do something similar on .net. [snip]
Marius Dumitru Florea wrote:
Hi Florin,
Florin Ciubotaru wrote: [snip]
- Basic macro support(prevent the user from editing macro generated html)
It looks like you'd be recoding what is currently existing in the wysiwyg editor. While this is nice to have it in word, I'm wondering what it's going to cost to maintain the 2 features.
I'm only referring to making macro generated content read-only. IMO, this is not nice to have, it's mandatory, as without it, the user will damage every page that contains a macro. Marius: is this implemented on the server or on the client for the WYSIWYG? If it's on the server then it would be great to reuse it for XWord. :)
It's done on the client-side. At most you can try to use the same technique I use, but I doubt it's going to work in Word. Let's talk about this Monday.
OK, thanks.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Feb 20, 2009, at 10:10 PM, Florin Ciubotaru wrote:
Hi Vincent,
Thanks for the reply. See bellow:
Vincent Massol wrote:
Hi Florin,
On Feb 20, 2009, at 4:43 PM, Florin Ciubotaru wrote:
Hi devs,
Due to some critical bugs and missing features, the release was postponed for a long period.
Still the development process is way ahead of what was intended for XWord 1.0 This is how the old roadmap looked like: http://dev.xwiki.org/xwiki/bin/view/Design/MicrosoftOfficeAddin#HFirstversio...
As you can see XWord 1.0 was intended to be an export to wiki tool and only XWord 1.1 should enable editing wiki pages. Sorry for not keeping you up to date on the mailing list. This is the new roadmap for XWord: - 1.0 M1
What is the release date planned for 1.0M1?
This is not established. In terms of development XWord is ready for release. Manual publishing works fine, automatic doesn't. What we need to to is to see if OW2 can be used as a location for the clickOnce binaries and manifests. It also depends if you want CI before or after M1.
For M1 we don't need anything automated. We need to release ASAP so anything releasable should be released. I don't know what clickonce library are.
- Wiki Explorer - done - Attachment Upload - done - Attachment Download - done - Export word documents - done - Edit/Save wiki pages - done - Save pages with user specified syntax - done - Protect essential pages from editing - done
What is this?
This means that you cannot open in Word some specific pages that provide functionality to the wiki. Eg: The pages in XWiki, Stats or Blog spaces. Note: There is no api for identifying these pages. This was ok for XEclipse as it targets developers and wiki syntax editing, but in the case of XWord which is created for non-technical users, a method to protect these pages is required.
I don't understand. If the user has view rights then he should be able to view any page even if they are in the XWiki space. If they have edit rights on the page then they can edit the page.
- Export using filtered html - done
Isn't this already done by the Office importer HTML cleaner? We'd need to find ways so that you can reuse this to prevent code duplication (and it's a complex domain).
Word can output html in two modes: filtered or not filtered. The filtered html size is about 10% of the not-filtered html, but it losses data from embedded elements(diagrams, shapes, expressions and charts). Additionally I created filters and adapters that are applied at different stages of the conversion. The steps are: Saving a document to the wiki: Word Supported Format -> WordML <-> HTML -> WikiSyntax Opening a wiki page: WikiSyntax -> HTML <- > WordML [-> Other format] The conversion from and into wiki syntax is done on the server. I can program against all the other data formats and set options on the transformation from one format to another. For this I'm using Word API or custom developed functionalities. IMO this has a better chance of success then a server oriented filter. Note that Word html is different from OOo html, so the filters that could be used for XWord are the filters implemented for the "Paste from Word" feature of the WYSIWYG. If we get these filters to provide high quality bidirectional saving and data preservation, then yes we can use then for XWord.
Yes I'm talking about the WYSIWYG copy/paste filters. But I think they are basically the same one as for oOo but with additional filtering done (Asiri correct me if that's not correct). In any case since we support copy/paste in the wysiwyg then we already have them or will have them.
- Export with non-filtered html - buggy - Deployment and infrastructure - problematic because it uses ClickOnce. - 1.0 M2 - 2-3 weeks from M1 - Solve as many reported bugs - Improve html filters - Introduce the XML-RPC communication mode
What is this? Any advantage of using XMLRPC vs REST? (I don't have a preference but since we have both I'm wondering).
XWord does not depend on a specific implementation for client-server communication. I can be easily changed. What is important is to have a fully featured API. I will create a separate thread for this.
- Basic macro support(prevent the user from editing macro generated html)
It looks like you'd be recoding what is currently existing in the wysiwyg editor. While this is nice to have it in word, I'm wondering what it's going to cost to maintain the 2 features.
I'm only referring to making macro generated content read-only.
How will a user edit a macro?
IMO, this is not nice to have, it's mandatory, as without it, the user will damage every page that contains a macro.
Yes sure. I was just thinking that you'll end up doing the same thing as the wysiwyg is doing but I don't see any way out if we want to have advanced features in Word. Right now it's macro but later on it'll be support for other Transformation changes which must also be read only, then you need to edit macros, etc. I think this is great from a user POV. I'm just realizing that XWord is going further than what I thought it would do initially. This is good. However it means we'll need to maintain/support it in the future and this means building an MS Office dev team. Right now you're the only one to know .Net and this code. So if we want to go ahead full steam on all features we need to think about how we spread your knowledge to others. I guess one first step is for you to document cleanly the architecture, how to build, how to deploy, dev environment to code, etc.
Marius: is this implemented on the server or on the client for the WYSIWYG? If it's on the server then it would be great to reuse it for XWord. :) If not, then I see no other option then to do something similar on .net.
- 1.0 RC1 - 1-2 weeks from M2 - Bug fixing - Stable and ergonomic UI - Remove the sever package and rely only on XML-RPC
What is the "server package"?
It's a collection of wiki pages that contain the services used by XWord.
In the absence of a fully featured and actual api, velocity + groovy remains the most powerful way of extending or communicating with xwiki. See: http://incubator.myxwiki.org/xwiki/bin/view/XWord/
ok, I see.
- 1.0 Final - 1-2 - Rock solid UI - Production quality html output and wiki syntax conversion.
If you succeed in using the server side version of html/wiki syntax conversion tools then you'll get rock solid stuff with no maintenance need on your side.
WDYT?
The html/wiki syntax is already done at the server. Sorry, but I'll give a -1 for Word html cleaning on the server, at least at it's current state.
WDYM by "its current state"? If you can use the server side cleaning then I'd rather you use it. And if it's not good enough then we need your help/energy to improve it on the server rather than redevelop it in .Net since we also need it for copy/paste in the wysiwyg for example. Or are you talking about something else? Thanks -Vincent
Vincent Massol wrote:
On Feb 20, 2009, at 10:10 PM, Florin Ciubotaru wrote:
Hi Vincent,
Thanks for the reply. See bellow:
Vincent Massol wrote:
Hi Florin,
On Feb 20, 2009, at 4:43 PM, Florin Ciubotaru wrote:
Hi devs,
Due to some critical bugs and missing features, the release was postponed for a long period.
Still the development process is way ahead of what was intended for XWord 1.0 This is how the old roadmap looked like: http://dev.xwiki.org/xwiki/bin/view/Design/MicrosoftOfficeAddin#HFirstversio...
As you can see XWord 1.0 was intended to be an export to wiki tool and only XWord 1.1 should enable editing wiki pages. Sorry for not keeping you up to date on the mailing list. This is the new roadmap for XWord: - 1.0 M1
What is the release date planned for 1.0M1?
This is not established. In terms of development XWord is ready for release. Manual publishing works fine, automatic doesn't. What we need to to is to see if OW2 can be used as a location for the clickOnce binaries and manifests. It also depends if you want CI before or after M1.
For M1 we don't need anything automated. We need to release ASAP so anything releasable should be released. I don't know what clickonce library are.
- Wiki Explorer - done - Attachment Upload - done - Attachment Download - done - Export word documents - done - Edit/Save wiki pages - done - Save pages with user specified syntax - done - Protect essential pages from editing - done
What is this?
This means that you cannot open in Word some specific pages that provide functionality to the wiki. Eg: The pages in XWiki, Stats or Blog spaces. Note: There is no api for identifying these pages. This was ok for XEclipse as it targets developers and wiki syntax editing, but in the case of XWord which is created for non-technical users, a method to protect these pages is required.
I don't understand. If the user has view rights then he should be able to view any page even if they are in the XWiki space. If they have edit rights on the page then they can edit the page.
Yes, first I also thought that view/edit rights should do the trick. But unfortunately, without macro support, edit right is too generic. For example it's ok to have edit right on a current page in the XWiki space end edit it in the wiki editor, but it's not ok to have edit rights and edit it with the wysiwyg/Word. See what I mean?
- Export using filtered html - done
Isn't this already done by the Office importer HTML cleaner? We'd need to find ways so that you can reuse this to prevent code duplication (and it's a complex domain).
Word can output html in two modes: filtered or not filtered. The filtered html size is about 10% of the not-filtered html, but it losses data from embedded elements(diagrams, shapes, expressions and charts). Additionally I created filters and adapters that are applied at different stages of the conversion. The steps are: Saving a document to the wiki: Word Supported Format -> WordML <-> HTML -> WikiSyntax Opening a wiki page: WikiSyntax -> HTML <- > WordML [-> Other format] The conversion from and into wiki syntax is done on the server. I can program against all the other data formats and set options on the transformation from one format to another. For this I'm using Word API or custom developed functionalities. IMO this has a better chance of success then a server oriented filter. Note that Word html is different from OOo html, so the filters that could be used for XWord are the filters implemented for the "Paste from Word" feature of the WYSIWYG. If we get these filters to provide high quality bidirectional saving and data preservation, then yes we can use then for XWord.
Yes I'm talking about the WYSIWYG copy/paste filters. But I think they are basically the same one as for oOo but with additional filtering done (Asiri correct me if that's not correct). In any case since we support copy/paste in the wysiwyg then we already have them or will have them.
- Export with non-filtered html - buggy - Deployment and infrastructure - problematic because it uses ClickOnce. - 1.0 M2 - 2-3 weeks from M1 - Solve as many reported bugs - Improve html filters - Introduce the XML-RPC communication mode
What is this? Any advantage of using XMLRPC vs REST? (I don't have a preference but since we have both I'm wondering).
XWord does not depend on a specific implementation for client-server communication. I can be easily changed. What is important is to have a fully featured API. I will create a separate thread for this.
- Basic macro support(prevent the user from editing macro generated html)
It looks like you'd be recoding what is currently existing in the wysiwyg editor. While this is nice to have it in word, I'm wondering what it's going to cost to maintain the 2 features.
I'm only referring to making macro generated content read-only.
How will a user edit a macro?
What do you mean? The user should not be able to edit the macro in Word. What is wrong right now: The user is editing a wiki page with Word. This page contains a macro, let's say, toc. All he sees in Word is a list with links. When he will save the page to the wiki again, the toc will be overridden by the bulleted list.
IMO, this is not nice to have, it's mandatory, as without it, the user will damage every page that contains a macro.
Yes sure. I was just thinking that you'll end up doing the same thing as the wysiwyg is doing but I don't see any way out if we want to have advanced features in Word. Right now it's macro but later on it'll be support for other Transformation changes which must also be read only, then you need to edit macros, etc.
I think this is great from a user POV. I'm just realizing that XWord is going further than what I thought it would do initially. This is good. However it means we'll need to maintain/support it in the future and this means building an MS Office dev team. Right now you're the only one to know .Net and this code. So if we want to go ahead full steam on all features we need to think about how we spread your knowledge to others. I guess one first step is for you to document cleanly the architecture, how to build, how to deploy, dev environment to code, etc.
Yes, this should mostly go under xoffice.xwiki.org. Where do you think I should put the .net/vsto coding conventions, building, etc. Is it under dev.xwiki.org?
Marius: is this implemented on the server or on the client for the WYSIWYG? If it's on the server then it would be great to reuse it for XWord. :) If not, then I see no other option then to do something similar on .net.
- 1.0 RC1 - 1-2 weeks from M2 - Bug fixing - Stable and ergonomic UI - Remove the sever package and rely only on XML-RPC
What is the "server package"?
It's a collection of wiki pages that contain the services used by XWord.
In the absence of a fully featured and actual api, velocity + groovy remains the most powerful way of extending or communicating with xwiki. See: http://incubator.myxwiki.org/xwiki/bin/view/XWord/
ok, I see.
- 1.0 Final - 1-2 - Rock solid UI - Production quality html output and wiki syntax conversion.
If you succeed in using the server side version of html/wiki syntax conversion tools then you'll get rock solid stuff with no maintenance need on your side.
WDYT?
The html/wiki syntax is already done at the server. Sorry, but I'll give a -1 for Word html cleaning on the server, at least at it's current state.
WDYM by "its current state"?
If you can use the server side cleaning then I'd rather you use it. And if it's not good enough then we need your help/energy to improve it on the server rather than redevelop it in .Net since we also need it for copy/paste in the wysiwyg for example.
Or are you talking about something else?
By its' current state, I mean that it is only designed to work as an import filter. First: I need it to preserve embedded elements data. Second: I have the ability to force Word to output a different/better html then the one provided by copy/paste. I need the html cleaner to work well with this kind of output. Sure, I prefer to have a unified cleaner on the server. But there will always be filters/adapters on the client(not necesarely cleaners). For example: The 'src' and 'href' attributes have different values on XWiki and on a local html file used by Word. The user can open different edit sessions on multiple pages. Each session has an assigned html converter that uses filters for XWiki->Word and Word->XWiki conversion. Each converter has a number of dictionaries assuring the consistency of these attributes and the bijectivity of the operation. I prefer to have high cohesion on this and distribute it as less as possible.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, Florin Ciubotaru wrote:
Vincent Massol wrote:
On Feb 20, 2009, at 10:10 PM, Florin Ciubotaru wrote:
Hi Vincent,
Thanks for the reply. See bellow:
Vincent Massol wrote:
Hi Florin,
On Feb 20, 2009, at 4:43 PM, Florin Ciubotaru wrote:
Hi devs,
Due to some critical bugs and missing features, the release was postponed for a long period.
Still the development process is way ahead of what was intended for XWord 1.0 This is how the old roadmap looked like: http://dev.xwiki.org/xwiki/bin/view/Design/MicrosoftOfficeAddin#HFirstversio...
As you can see XWord 1.0 was intended to be an export to wiki tool and only XWord 1.1 should enable editing wiki pages. Sorry for not keeping you up to date on the mailing list. This is the new roadmap for XWord: - 1.0 M1
What is the release date planned for 1.0M1?
This is not established. In terms of development XWord is ready for release. Manual publishing works fine, automatic doesn't. What we need to to is to see if OW2 can be used as a location for the clickOnce binaries and manifests. It also depends if you want CI before or after M1.
For M1 we don't need anything automated. We need to release ASAP so anything releasable should be released. I don't know what clickonce library are.
- Wiki Explorer - done - Attachment Upload - done - Attachment Download - done - Export word documents - done - Edit/Save wiki pages - done - Save pages with user specified syntax - done - Protect essential pages from editing - done
What is this?
This means that you cannot open in Word some specific pages that provide functionality to the wiki. Eg: The pages in XWiki, Stats or Blog spaces. Note: There is no api for identifying these pages. This was ok for XEclipse as it targets developers and wiki syntax editing, but in the case of XWord which is created for non-technical users, a method to protect these pages is required.
I don't understand. If the user has view rights then he should be able to view any page even if they are in the XWiki space. If they have edit rights on the page then they can edit the page.
Yes, first I also thought that view/edit rights should do the trick. But unfortunately, without macro support, edit right is too generic. For example it's ok to have edit right on a current page in the XWiki space end edit it in the wiki editor, but it's not ok to have edit rights and edit it with the wysiwyg/Word. See what I mean?
- Export using filtered html - done
Isn't this already done by the Office importer HTML cleaner? We'd need to find ways so that you can reuse this to prevent code duplication (and it's a complex domain).
Word can output html in two modes: filtered or not filtered. The filtered html size is about 10% of the not-filtered html, but it losses data from embedded elements(diagrams, shapes, expressions and charts). Additionally I created filters and adapters that are applied at different stages of the conversion. The steps are: Saving a document to the wiki: Word Supported Format -> WordML <-> HTML -> WikiSyntax Opening a wiki page: WikiSyntax -> HTML <- > WordML [-> Other format] The conversion from and into wiki syntax is done on the server. I can program against all the other data formats and set options on the transformation from one format to another. For this I'm using Word API or custom developed functionalities. IMO this has a better chance of success then a server oriented filter. Note that Word html is different from OOo html, so the filters that could be used for XWord are the filters implemented for the "Paste from Word" feature of the WYSIWYG. If we get these filters to provide high quality bidirectional saving and data preservation, then yes we can use then for XWord.
Yes I'm talking about the WYSIWYG copy/paste filters. But I think they are basically the same one as for oOo but with additional filtering done (Asiri correct me if that's not correct). In any case since we support copy/paste in the wysiwyg then we already have them or will have them.
- Export with non-filtered html - buggy - Deployment and infrastructure - problematic because it uses ClickOnce. - 1.0 M2 - 2-3 weeks from M1 - Solve as many reported bugs - Improve html filters - Introduce the XML-RPC communication mode
What is this? Any advantage of using XMLRPC vs REST? (I don't have a preference but since we have both I'm wondering).
XWord does not depend on a specific implementation for client-server communication. I can be easily changed. What is important is to have a fully featured API. I will create a separate thread for this.
- Basic macro support(prevent the user from editing macro generated html)
It looks like you'd be recoding what is currently existing in the wysiwyg editor. While this is nice to have it in word, I'm wondering what it's going to cost to maintain the 2 features.
I'm only referring to making macro generated content read-only.
How will a user edit a macro?
What do you mean? The user should not be able to edit the macro in Word. What is wrong right now: The user is editing a wiki page with Word. This page contains a macro, let's say, toc. All he sees in Word is a list with links. When he will save the page to the wiki again, the toc will be overridden by the bulleted list.
IMO, this is not nice to have, it's mandatory, as without it, the user will damage every page that contains a macro.
Yes sure. I was just thinking that you'll end up doing the same thing as the wysiwyg is doing but I don't see any way out if we want to have advanced features in Word. Right now it's macro but later on it'll be support for other Transformation changes which must also be read only, then you need to edit macros, etc.
I think this is great from a user POV. I'm just realizing that XWord is going further than what I thought it would do initially. This is good. However it means we'll need to maintain/support it in the future and this means building an MS Office dev team. Right now you're the only one to know .Net and this code. So if we want to go ahead full steam on all features we need to think about how we spread your knowledge to others. I guess one first step is for you to document cleanly the architecture, how to build, how to deploy, dev environment to code, etc.
Yes, this should mostly go under xoffice.xwiki.org. Where do you think I should put the .net/vsto coding conventions, building, etc. Is it under dev.xwiki.org?
For me, it can go under xoffice.xwiki.org, at least in a first step. Jerome.
Marius: is this implemented on the server or on the client for the WYSIWYG? If it's on the server then it would be great to reuse it for XWord. :) If not, then I see no other option then to do something similar on .net.
- 1.0 RC1 - 1-2 weeks from M2 - Bug fixing - Stable and ergonomic UI - Remove the sever package and rely only on XML-RPC
What is the "server package"?
It's a collection of wiki pages that contain the services used by XWord.
In the absence of a fully featured and actual api, velocity + groovy remains the most powerful way of extending or communicating with xwiki. See: http://incubator.myxwiki.org/xwiki/bin/view/XWord/
ok, I see.
- 1.0 Final - 1-2 - Rock solid UI - Production quality html output and wiki syntax conversion.
If you succeed in using the server side version of html/wiki syntax conversion tools then you'll get rock solid stuff with no maintenance need on your side.
WDYT?
The html/wiki syntax is already done at the server. Sorry, but I'll give a -1 for Word html cleaning on the server, at least at it's current state.
WDYM by "its current state"?
If you can use the server side cleaning then I'd rather you use it. And if it's not good enough then we need your help/energy to improve it on the server rather than redevelop it in .Net since we also need it for copy/paste in the wysiwyg for example.
Or are you talking about something else?
By its' current state, I mean that it is only designed to work as an import filter. First: I need it to preserve embedded elements data. Second: I have the ability to force Word to output a different/better html then the one provided by copy/paste. I need the html cleaner to work well with this kind of output. Sure, I prefer to have a unified cleaner on the server. But there will always be filters/adapters on the client(not necesarely cleaners). For example: The 'src' and 'href' attributes have different values on XWiki and on a local html file used by Word. The user can open different edit sessions on multiple pages. Each session has an assigned html converter that uses filters for XWiki->Word and Word->XWiki conversion. Each converter has a number of dictionaries assuring the consistency of these attributes and the bijectivity of the operation. I prefer to have high cohesion on this and distribute it as less as possible.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (5)
-
Anca Paula Luca -
Florin Ciubotaru -
Jerome Velociter -
Marius Dumitru Florea -
Vincent Massol