Hi devs,
I'd like to disable the WYSIWYG sync plugin (the one that adds
experimental support for real time editing) in the WYSIWYG code till we
clean and refactor it. The main reason is to reduce the size of the
JavaScript code generated by GWT:
641.3 KB when enabled
545.2 KB when disabled
The technical explanation:
The sync plugin uses a diff Java library ported by Ludovic to GWT. This
library uses the generic Object class in lots of places. Instances of
classes defined in this library are passed from the client to the server
and back, and so they have to be serialized and deserialized. When
fields of Object type or List<Object> or Object[] are deserialized on
the client, GWT doesn't know the concrete type and thus generates
JavaScript code to handle every possibility (i.e. all classes
implementing IsSerializable tag interface). This increases a lot the
size of the JavaScript code. Here's the warning we get during GWT
compilation:
http://pastebin.com/m61aa381f
mainly:
[WARN] In order to produce smaller client-side code, 'Object' is not
allowed; consider using a more specific type
To disable the WYSIWYG syntax plugin I have to comment one line of code:
// WysiwygEditorFactory.java
pfm.addPluginFactory(SyncPluginFactory.getInstance());
and to remove an import. GWT compiles to JavaScript only the code that
is really used.
Here's my +1
Thanks,
Marius
Hi Asiri,
This is mostly for you but sending here for others to see and comment
if they want. While working on adding support for wiki macro
visibility I have found the following issues in the existing wiki
macro code:
1) Usage of String for document names instead of DocumentName class.
I've fixed this.
2) Printing logs in all methods instead of sending exceptions on
errors. I've fixed this too.
3) Bad test strategy for testing DefaultWikiMacro. It's not needed to
use RenderingTests with test files. I've fixed this.
4) Missing several tests in DefaultWikiMacro. I have not fixed this.
5) Bad strategy for providing user feedback on macro registration. I
believe we shouldn't implement registration as an event listener and
instead have a Wiki Macro management page with register/unregister
buttons and when clicked the result is printed on the page. This
should probably be done as a replacement of the WikiMacros page in the
wiki macro bridge application. WDYT? I've not fixed this.
6) Programming rights required to access macro params. I have not
fixed this.
7) There was a bug with parameter ordering I have fixed a few weeks
ago but I'm mentionning it here for completeness.
8) Context restoration in DefaultWikiMacro. It's currently not in a
finally block and thus it's possible it's not restored if there are
exceptions raised. I have not fixed this.
9) Missing some comments for complex code portions. For ex in
DefaultWikiMacro for the inline macro stuff. I have not fixed this.
10) Systematic setting of null values not required in lots of place. I
have fixed all I saw.
11) DefaultWikiMacro only executes Macro Transformations but not other
Transformations. I think this is a problem. I have not fixed this.
12) Several classes had full javadoc but the checkstyle config wasn't
set in the POM, thus allowing checkstyle errors to creep in unnoticed.
I have only partially fixed this. Please check all classes that can be
added and fix the few that still have errors.
13) Missing tests for the Event Listener but because of 5) I haven't
added them.
14) Missing at least one functional test to prove everything works.
Thanks
-Vincent
Hi,
I have the need to get the current wiki (which is different from the
wiki defined in the current doc for my use case).
I'd like to add a DAB.getCurrentWiki().
Here's my +1
Thanks
-Vincent
Hi,
I'd like to add:
boolean isDocumentEditable(DocumentName documentName);
And deprecate:
boolean isDocumentEditable(String documentName);
Here's my +1
Thanks
-Vincent
The XWiki development team is pleased to announce the release of XWiki
Enterprise and XWiki Enterprise Manager 2.0.5.
This is the last bug fix and enhancement release for 2.0 branch.
It contains several important bugfixes like support of non ASCII
character in Go to, Search and Document Index or proper UTF8 support
when creating a sub wiki.
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise205
and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM205
Thanks
-The XWiki dev team
Hi,
Wiki macros currently require programming rights and thus are limited
and in addition cannot be created in subwikis by the majority of users.
Since I've now almost finished implementing component isolation I'd
like to agree on what we want for wiki macros.
Proposal:
* Modify the wiki macro class to add a "Visibility" field with 2 values:
- visible only in the current wiki
- visible to everyone
* Visible to everyone will require admin rights
* Make the macro available to a user only if that user has view rights
to the wiki macro page. This is to allow making a wiki macro private
(when testing for example). It also allows making a macro visible only
to a given group of users.
Note: I considered having a "visible only to the current user" value
for the Visibility field but I don't think it means much since if
someone else edit the page and saves it, then suddenly the macro
becomes visible only to that person...
WDYT?
Thanks
-Vincent
The XWiki development team is pleased to announce the release of XWiki
Office 1.0.
Go grab it at:
http://www.xwiki.org/xwiki/bin/view/Main/Download#HXWikiOffice
Summary of features for XOffice 1.0:
- Create new wiki pages
- Open and edit existing wiki pages in Word
- Download and edit attachments
- Upload attachments
- Export Word documents to the wiki
- Wiki Explorer
Main changes since XOffice 1.0 RC1:
- Supported XWiki versions are now: 2.0.4, 2.1 and above
- fixed saving issue for XWiki 2.0 syntax
- faster startup
- fixed focus issues
View detailed release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXOffice10
For more information about XOffice visit:
http://xoffice.xwiki.org/xwiki/bin/view/Main/WebHome
Thanks,
-The XWiki dev team