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