24 Feb
2009
24 Feb
'09
10:58 a.m.
Hi,
Florin Ciubotaru wrote:
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.
Vincent Massol wrote:
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.
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.
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.
On Feb 20, 2009, at 10:10 PM, Florin Ciubotaru
wrote:
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?
Hi Vincent,
Thanks for the reply.
See bellow:
Vincent Massol wrote:
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.
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#HFirstversi…
>
> 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.
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.
ok, I see.
> - 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs