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